That development teams should pursue a standard of high quality is non-negotiable. While a few teams may be able to get away with some buggy UI here and there, with the importance of privacy and security, along with the complexities of different technology, few teams can get away with software that has major/many issues in it.
The big question for many teams though is who is primarily responsible for assuring that quality. Those words alone will probably lead many to jump to the conclusion of the QA person, or software tester, directly in the team. However, if any team is looking to build a proper culture of quality, it starts with every member of the team taking responsibility for the quality of not just their own work, but that of the entire team. What odes this look like? Essentially it means every person in the team should perform testing n their software regularly, continue to reduce testing tech debt backlog items, assist in ensuring automation is delivered and addressing issues and finding ways to improve.
Now, some might ask what the role of the QA/testing people are the team are then. Well, they still represent the “testing” experts in the team and are responsible for driving the testing strategy with the team and should obviously form a large part of the testing and automation effort. But they should not be the only ones do it nor be solely responsible for it In fact, if anything, the entire team should take responsibility for poor software quality and the testers should be the ones driving the changes to right the job, not taking the blame for it.
This means that it is up to the Business Analysts and Product Owners to write better requirements, work to mitigate defects in the design phase and take part in testing yourself to ensure the end product matches your expectations. It’s up to developers to write better code, design better systems, take accountability for defects and improving their unit and component tests. Plus, as the coding experts in the teams, if they can help with other forms of automation when their tester can’t get to it, they should. Even Scrum Masters and managers should get it on the act to assure quality wherever they can.
A good software tester is a person who can create a test strategy for the team, get them to all rally behind it and then ensure that the appropriate testing is done across unit, competent, integration, performance, etc is done by the appropriate person and time, along with putting the automation in place to do so. They are the experts who should know how to implement all of these testing activities but not be the one doing all of them. They are the individuals who look at the potential risks to quality in the team, ensure they are mitigated effectively while digging deeper into issues and defects to better understand them and come up with strategies to prevent them in the future.
What about automation and technical testing?
The above description makes testing sound more like a manual and leadership role, which is almost in contradiction to the increased technical expectations we should be having on testers? It may sound that way, but the reality is that in order for a tester to do this effectively, they should have an intricate technical understanding of the system under test, its constraints, dependencies and understanding of how to automate them. A tester that can contribute to the automation effort is even more valuable and if they can monitor pipelines, dig deeper into issues and identify technical resolutions on behalf of the team, even more so.
Automation remains an important strategy to driving continuous and fast delivery and teams need to play in this space effectively. Thought in this case its not just a matter of quantity, but quality, as a good tester will push as many of the automated tests into a unit level and ensure that any integration or frontend automation is kept as minimal as possible, while still hitting all the critical areas. There is also no excuse for poor test design, and this remains the case for any automation effort just as it does for any other form of testing. However, again, this is not just the testers responsibility, but that of the entire team who should take guidance from their resident tester, but not exclusively rely on them from an execution perspective.
It’s all about the team
So, don’t ever think that you can divert any form of responsibility about software testing and quality to another person in the team. Quality is a collective responsibility and if you played any role in the software development and design process, you should be involved in the testing of it. Yes, teams need strong technical testers to do this effectively but don’t expect them to assure the quality for you. That’s your job too.