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:
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.
Now, we’re not saying developers should never test anything - that would be crazy! After all, if everything 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?
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. QA roles are 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/team of test engineers 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 dreamwork!
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:
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.
What do you think? Feel free to join our conversations on Twitter.