paint-brush
How Agile Teams Shorten SDLC Using DevTestOpsby@katalon
125 reads

How Agile Teams Shorten SDLC Using DevTestOps

by KatalonDecember 31st, 2021
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

DevTestOps aims to end the lasting bad blood between the development and testing teams. The DevTest approach is similar to other topologies like DevSecOps, which emphasizes more on the “Sec,” or security matters. Developers build the software and QA engineers search for risks to verify that everything works. The lesson to learn from NASA’s Mars Climate Orbiter (MCO) is that the lack of collaboration from the start led to the project going all to waste waste.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - How Agile Teams Shorten SDLC Using DevTestOps
Katalon HackerNoon profile picture

DevTestOps and DevOps – Not Just Another Hype

Don’t worry. DevTestOps isn’t another new term to create turbulence in our IT and DevOps world.

Similar to other topologies like DevSecOps, which emphasizes more on the “Sec,” or security matters, DevTestOps stresses the aspect of continuous testing and CI/CD in DevOps.

At the same time, to uphold the culture of saying “no” to working in silos, the DevTest approach specifically aims to end the lasting bad blood between the development and testing teams.

The QA and Dev Conflict Before DevTestOps

QA engineers vs Developers

“Testers and developers are the best of friends,” said no one ever.


When DevTestOps was still an unfamiliar term, this disconnection was sadly formed from the contrasting technical expertise and objectives that each party holds: developers build the software and testers search for risks to verify that everything works.


And this just brings them back to the same old loop: developers spending hours on end writing the code, QA engineers dreading over the tickets of bugs they have to log and both seeing each other as human-form punching bags when it repeats.


Moreover, the duty of code quality can slowly be forgotten in the developers’ minds as they know their work would be tested either way.


It seems like there isn’t a way out of this conundrum – and letting developers entirely test their own code is not an option.

Inattentional blindness and cognitive biases

There’s something called inattentional blindness, or author bias, a symptom that causes a creator to overlook the faults in their own piece of work.


Over the course of developing code, developers build a certain familiarity or cognitive bias with their work, leading them to perform revisions with the expectation that everything already works as they have planned.


What they really need are testers to act as a pair of fresh eyes and use the software or application with a testing mindset. Unfortunately, this pops up a different issue for the testers’ side – independent testing.


With the type of expertise that testers hold, ranging from technical perspectives to cognitive biases, the typical flow leaves QA engineers to be involved only after the development team has finished coding.

The lesson to learn from NASA’s Mars Climate Orbiter (MCO)

NASA’s Mars Climate Orbiter (MCO)

You might have heard of the 1998 NASA Mars Climate Orbiter (MCO) incident. A year after its launch in 1998 to become a weather satellite and better learn about Mars, the MCO lost its signal to ground control. Lost in space, the team was able to determine that the cause of the failure was due to miscommunication about the units of measurements used by the engineers in the navigation team and the designer of the spacecraft.


With one function calculating everything in millimeters and meters, and another in inches, feet, and pounds, the lack of collaboration between the two teams from the start led to the project going all to waste.


If they had worked more closely together and agreed on the metric system to be used in the pre-development phases, perhaps humans would’ve had the chance to know if Mars was habitable and aliens existed.


In the software development world, testers should not be left out on activities such as:


  • Stakeholder or client meetings
  • Process of drafting the user story
  • Functional or non-functional requirement specifications
  • Division of tasks and enhancements

Benefits of The DevTestOps Approach

Faster delivery cycle and reduce bug escapes

Popular platforms such as GitHub or Jenkins now act as an additional safety net before delivering builds to testing teams. Whenever a commit is made to the central repository, automated regression, unit and integration tests are instantly triggered.


In terms of collaboration within the development department, CI tools decrease the likelihood of merge conflicts (a.k.a merge hell) and integration defects.


The weight of worrying about damaging bugs left undiscovered until later stages can now be taken off QA’s shoulders. Given that the majority of regression issues are spotted beforehand, testers are able to further expand test coverage with exploratory testing of the software with countless scenarios.

Help teams craft the right automation toolchain

Interoperability and adaptability are key when building the right toolsets for your team – both in DevOps and DevTestOps.


Open-source solutions might be free with self-taught materials online, but chances are they would require a high level of programming expertise. This is ideal if your team has a large number of experienced programmers to code everything from scratch and has the effort to maintain the framework and workarounds to integrate with CI/CD.


As for commercial tools, despite having to increase your spending on licenses, offer teams ready-to-use software, access to devoted customer support for members at all levels to quickly onboard and productivity-centric functionalities for larger-scale projects.


Here are a couple of popular tools for different types of testing needs:


  • Unit testing frameworks: xUnit, Jest, Mocha
  • Static code analysis: SonarQube, ReSharper
  • API testing: Postman, SoapUI, Swagger
  • End-to-end testing: Katalon Studio, Selenium
  • Test reporting: Katalon TestOps, Allure, ReportPortal

Best DevTestOps Testing Practices for Agile Teams

Going Agile has been the go-to strategy for modern testing teams. Whether a startup firm or a world-renowned organization, optimizing time-to-market and ensuring customer satisfaction are where the lines always cross.

Microservices and CI/CD

Following a microservices-based architecture offers an opportunity to entangle the struggle of trying to manage an application or software as a whole.


By keeping services loosely coupled and split into manageable workloads, changes and iterations can easily be made without pushing back deployment schedules.


A single Git repo in CI is broken down into smaller builds, making automated tests lighter and faster in generating feedback to developers. The result? More production-ready code.


On the other hand, due to the incremental number of pipelines and interdependencies, the microservices journey poses challenges with the complexities in the management and testing process; integration testing and suite-level acceptance testing are said to be the most prominent.

This once again calls for QA teams to monitor and understand the architecture from its root to maximize the coverage of test cases and identify the core causes of any arising issues.

How testers and developers apply DevTestOps with Katalon

Testers shouldn’t work like security scanners at the mall – only beeping when an unpaid item passes by without concern about the rest of their surroundings.


The minute developers put their hands on and begin the programming process, they need to know that bugs have already been created. Aside from the must-have CI automated unit and integration tests, or static code analysis, developers need to be able to quick-check the key functionalities using test automation tools.


With the scripting and low-code features of Katalon Studio, developers can choose the Record & Playback option to generate automated smoke tests with minimal effort, and run them against the build before letting it enter the QA environment.


Some other highlights in Studio are:



On the testers’ side, you can pass down the common mistakes that developers often encounter, and offer automated tests with reusable workflows for developers to run end-to-end tests. It really is a win-win situation for both teams without adding any major changes to the working process.

Can you see the friendship forming here? Your conversations will move from work, like helping you understand more the internal logic of their code to come up with corner and edge cases, to pointing out user story and regression risks.


But to centralize all of your DevOps testing activities, TestOps is a test orchestration platform that connects all of your ecosystem compartments together and makes collaboration much easier. It offers:


  • Native CI integrations with Jenkins, Azure DevOps, CircleCI
  • Advanced reports to understand Studio test failure ASAP
  • Historical data to identify trends in execution time, flakiness rate, and staleness
  • Jira and Slack integration to stay posted on all tickets and tasks


Now you know. It’s not impossible to make these two departments work well together. Just get the right mindset, skills and toolsets for us to all live in harmony again.