Dedicated QA vs. Developer/Engineering Testing

With changes in development testing methodologies, people often wonder if Engineering teams will ultimately replace Quality Assurance (QA) teams by incorporating QA responsibilities into the development lifecycle. This debate has been ongoing within the software industry for years. Inevitably, the question boils down to whether testing should be accomplished by separate and dedicated Quality Assurance (QA) teams or whether testing should become more embedded into the Engineering development process to deliver the best possible application. 

This debate is complex and requires an understanding of how these distinct roles, and testing strategies, have evolved.

How QA Roles Have Changed

The changing roles of the QA team and the evolution of software development go hand-in-hand. Previously, testers on QA teams were not required to have a lot of development experience. Their focus was to make sure that the software functioned as designed.

Approaches such as Waterfall SDLC methodologies influenced old QA models, where work flows downhill and testing occurs after development.

As SLDC moved towards agile methodologies, the QA tester’s role shifted to operate as an integrated function within development teams earlier in the development process. Testing is also now performed by many people on a team, including developers. This shift aims to automate testing as much as possible, supporting newer CI/CD Dev/Ops models where software is continually integrated and deployed into production to meet demanding cycles.

QA testers are now expected to be more knowledgeable about the development process so that automated testing fits in with current CI/CD structures.

That said, there is still a debate as to whether or not the QA tester’s role has a place in Development. 

Shift Left

The QA tester’s role has shifted dramatically because they now work under a “shift left” methodology. If we look at the process of a project moving forward from left to right, “left” refers to the earlier stages. So, under this methodology, testing begins much earlier in the process of development. 

To adequately implement a “shift left” philosophy for software quality assurance, testing occurs at the earliest possible stages. 

This change in testing has led to a simultaneous shift in the roles of engineers and QA professionals. Let’s look at the advantages and disadvantages of testing by QA professionals versus developers doing evaluation and testing.

Pro Dev Testing

• Developers, by default, have a much more intimate understanding of their code compared to QA testers. Already, they do a lot of testing as they build their code. With this in mind, incorporating testing into the development process makes a certain amount of sense.
• As developers write code, they can build unit testing modules directly into the code to ensure that by the time a piece of software has moved through the DevOps lifecycle, it has already been tested against most scenarios. If done correctly, this is a very efficient way to test code. Building testing modules into code requires that a fair process is in place to ensure that testing occurs throughout the entire process. Once done, this module can perform some of the duties required from a QA tester.  
• Most developers want to push out quality and error-free code and take the necessary steps to ensure this happens, even if this means performing tasks usually attributed to QA. 

Pro QA Approach

• Productivity deadlines often drive developers; each mistake that is made might further slow them down. When you have a deadline approaching, you simply don’t have the time to build and run numerous development tests. Furthermore, unit testing is often seen as too complicated, and it can be challenging to create repetitive processes that can be reused for multiple modules. 
• QA engineers typically have a broader knowledge of the regression of an application. They can see how everything fits together as a whole. Developers are at a disadvantage when testing their own code because they often work on narrow segments of a codebase. They may understand the individual parts of code they worked on, but not necessarily other elements and how they work as a whole. 
• Developers want their code to work. This is ultimately counterintuitive when the point of testing is to make it fail. On the other hand, QA teams use a unique set of tools that make up for these shortcomings. Built into the QA mentality is a willingness to make things fail. Unlike developers who operate from making things work, QA engineers are more willing to push software to its limits. This difference in perspective makes QA testers uniquely positioned to ensure code works no matter the circumstances. 
• Finally, QA professionals are more likely to try and think how an actual user of the software will think: they think and act like customers. During the testing process, their input may prove to be invaluable because of this. 

Combination – A Quality Engineering (QE) Model

However, the answer may lie somewhere in the middle of a pure QA or blended Dev/QA option. What’s needed is to transition from separate QA and Development teams to a more cohesive model where testers and developers work collaboratively. An approach that is commonly referred to as the Quality Engineering (QE) model. 

With the advances in CI/CD tools and reporting software, such as Airbrake, it becomes possible to integrate testing into the entire development process. Many companies have essentially removed the distinction between developers and testers.

Here’s how it works: Developers do most of their own testing; however, they are supplemented by a team of QA testers who provide frameworks and complete testing within the development process.

In QE, testers create specialized automated test cases that work directly with code built by developers. It might even make sense to have developers write these tests, with testers providing input and feedback on testing scripts. 

In addition to this, developers can write many unit-test cases for their code, making it possible for deployment to occur rapidly for individual modules. However, there does need to be a concerted effort to organize tests into a cohesive whole. New development must not break old code, so a solid library of integration and regression tests, organized by QA testers, is necessary for maintaining quality code.

One fundamental necessity for developing a QE model is automation. Whereas traditional QA has been manual, testers now require specialized development know-how to adapt to CI/CD models of rapid deployment. QA engineers working under a QE model should aim towards becoming engineers themselves. This way, testers will be able to think more like developers while learning how to use advanced tools to ensure the entire product works well. By becoming engineers themselves, QA testers will be able to improve the quality of the process and validate the end results to ensure the product remains viable. 

Throughout the entire product lifecycle, QA and engineers should work together. By integrating QA testers into the development process, it becomes possible to implement effective “shift-left methodologies.” Furthermore, by maintaining QA principles, you can ensure that the final product is functional as a user expects. And the whole team can also expect fewer “cleanups” with a QE process.  

Ultimately, the end goal should be to move from a QA model to a QE model. With the latter, you can ensure that your applications are running more smoothly during the development process, reducing the time it takes to bring a quality product to the marketplace.

Conclusion

The question shouldn’t be, “Should a QA team or an engineering team handle testing.” Instead, you should ask yourself, “Am I using a QE model?” Using a QE model for testing is the most effective way to implement a “shift-left” methodology during the development process. The end product will require less “cleanups” and allow you to deploy quality code quickly.