Should developers take ownership of the quality assurance process? Well, what a question! We'll sit back for a few minutes while you rattle off the ‘for' and ‘against' arguments in your head or get into a discussion with your coworker.

At least we can agree on one thing. At a very basic level, most software projects generally follow a similar format:

• Devs write code
• Code is merged into a centralized repo for the project
• Project source code is compiled and built for deployment

Following CI/CD, it looks a bit different. Things become automated. Dev changes are integrated as they are developed - that's Continuous Integration. Then, artifacts are built and deployed through manual decision - that's Continuous Delivery - or the process is automated, which is Continuous Deployment. Continuous Deployment is risky because bugs can be sent straight to production with a single commit, not to mention critical regressions that cause other features to stop working. But that's not to say Continuous Deployment should be avoided since it has the potential to deliver benefits such as faster fault isolation, high feature velocity, and shorter release cycles.

For CI/CD to work, good testing needs to be in place. Nay, excellent testing needs to be in place. But the big question is: who should be doing this testing, and when? Let's take a look at why testing should not be moved into the existing workflow of developers.

To test, or not to test

Now, we're not saying developers should never test anything - that would be crazy! After all, if every piece of code a dev wrote was sent straight to a tester, that would be a waste of everyone's time. The code needs to compile correctly and achieve the intended result. It's safe to say that at a minimum, developers should request code reviews from others on the team, in addition to unit testing their own code. Identifying bugs during code reviews also helps ensure that the right unit tests are set up. Developers are invaluable to the process of CI/CD, and there is absolutely room for them to participate in testing. But should they do it all?

QA is here to help

This is where QA and Test Engineers come in. They have a different mindset and outlook while testing and are usually closer to understanding the end-user's requirements. The testing team is important to processes like full integration testing and regression testing, making sure that the final product works according to the overall requirements determined by various roles (product managers, executives, etc.), in addition to the assumptions and expectations of the end user. This helps ensure a larger test coverage area and verifies real-world usage of the product beyond the developer's tests that usually focus on technical errors.

When QA processes are brought in at an earlier stage, the benefits increase almost exponentially. Virtuoso enables organizations to shift left by allowing testers to create tests in line with requirements and wireframes before the product is even created. This way potential defects in the product design are discovered before significant investment is made, and resources are allocated more efficiently since developers will start coding from requirements that have been carefully designed and refined - and conveniently, the authored tests are ready to be executed from the minute that developers release code. This means that testers can continue using Virtuoso in tandem with developers so that everyone can do their part and validate that all requirements are covered and features are functional as the product is built. This in turn allows testers to help developers be more efficient and validate their code against requirements as soon as possible. At the same time, developers can help testers by highlighting any areas in tests where improvements can be made for better and faster test execution.

Shifting ownership of QA from developers to a dedicated QA team means more focused time for devs and less dealing with critical issues that weren't addressed earlier on during the planning, analysis, and design stages along with the ability to keep track of testing as code is built and deployed. Teamwork makes the dream work!

Keep testing out of the dev workflow

It's easy enough to say that QA should be doing the bulk of testing work. But what are the benefits, if any? Is it really that hard for developers to author and run tests?

No, but also yes. Developers can certainly do it but to the detriment of your software development life cycle. Here are just a few reasons why:

• Developers are a valuable resource - the more time they spend on testing, the less time they have for coding. Shifting the burden of responsibility for testing to the developers changes the focus of the team. Skeptical and in the mood to test this out? Have your developers write test code for other developers. It won't be long before they ask for QA resources because they don't have time to do the rest of their jobs anymore - or even worse, they might just cut down on the testing scope and scrap a business-critical part of the QA process because they don't have time to do it.
• Developers can be subjective. When testing belongs to developers, they own a big part of the development cycle. Although this might sound like a good idea, it creates a subjective bias of requirements and how the product should work.
• Developers know their code. It's likely that they will simply test around problem areas, likely unknowingly - this again comes down to the fact that developers who are testing their code do so subjectively.
• Developers are not close to the end user and might have a different set of expectations and interpretation of requirements to those of the actual users. This is especially true if the planning and design stages did not have a clear set of requirements from which the product was created.
• There is little motivation for developers to test their own work beyond just limited technical testing and basic functionality tests. After all, nobody wants to burn down the house they built. On the other hand, QA testers enjoy the hide-and-seek game and often experience immense satisfaction when discovering issues and bugs in the application.
• Allowing developers to deploy to production directly without first going through a QA process could take up valuable resources in the long run. Having customers do end-to-end testing could lead to a vicious cycle of fixes, iterations, reiterations, and business interruptions that take up valuable resources and rack up high costs. This is not to say that is always the case. Of course, if you are, say, a streaming giant with millions of users paying small subscription fees, then yes, this is a manageable approach. However, SaaS companies that work primarily with business-critical applications, companies that have fewer users paying larger fees, and customer-centric companies simply don't have that luxury and would benefit most from a thorough testing process spearheaded by qualified test engineers.

Not recommended

With all of this in mind, it's not the best idea to move testing into the existing workflow of developers. Having your customers do end-to-end testing could be a liability, and the greater the average deal size within your organization, the greater the risk. Allowing developers and testers to work hand-in-hand during CI/CD is a more fruitful approach that minimizes this risk. Virtuoso allows you to harness the power of collective teamwork from the start of the SDLC in a structured way that provides oversight over every part of the QA process while freeing up developers and letting testers do more of what they love: testing!

Organizations that want to make the most out of their setup and achieve true CI/CD should aim to shift ownership of testing from developers to a designated tester, or team of testers - and the earlier, the better! Transformation through test automation as early as possible will be more effective than having developers take on the role of testing as part of their workflow. And if you want to see that transformation with your own eyes, you need look no further than our free trial! Two weeks of Continuous Testing goodness for you to try out with no restrictions.