Its an interesting word to try and define, but that is not the point of the post, so I am going to clarify in what terms I am using it. In providing software for someone to use, quality means that the application or program does what the user wants it to do, is as free from defects as it can realistically be, is usable, does not cause the user to get cross or frustrated but to satisfy their needs. I’m aware people will disagree, so i may take this up as a separate post!
In software delivery teams, Quality is often alluded to as meaning ‘there’s no bugs in the code and the acceptance criteria in the user story (I am using Agile as an example here) have been met’. It is also very often left as the Tester’s job in the team to ensure that Quality has been met.
I have a huge problem with this. Quality cannot be tested in, so what is the point in leaving the tester to find out if something doesn’t work as it should. Is that not the same as leaving the stable door open and then asking the tester to see if the horse in is there, and the raise the alarm if it has gone missing?
The most sensible things is to make product Quality a TEAM goal. Quality is everyone’s responsibility:
- The Product Manager working with the team to promote quality in every task.
- The Business Analyst in writing the user story must work with business stakeholder to question anything that would appear to make the user journey more complex than it need be, highlighting improvements in the proposals.
- The Business Analyst in walking through the story with Developer and Tester to explain what is requires, and answer any questions, so there is a common understanding (the 3 amigos discussion).
- Developers must write good code, fully unit tested and integration tested before performing a demo to the tester.
- The Tester must exercise tests to cover the delivered code, to regression test, to perform exploratory testing around the story – are there any potential pitfalls or problem areas, and to execute performance and security tests.
- The Team then perform a demo to the end user/stakeholder, and there should be no surprises. The delivered software meets their requirements, is robust and does not break!
It is basic common sense to not expect the very last person to look at the software to be the only person responsible for the quality of what has been delivered, unless the team likes to spend time rewriting code, missing deadlines and seeing a high turnover of bored and frustrated testers!
So, if you are reading this and am one of those testers who are expected to ‘do quality’ yourself, take heart. Things are changing, expectations are changing, and if your organisation will not accept the inevitable, then you have 3 choices: 1) Stay, and moan, 2) Give up and leave, 3) Stay and educate the team. Find a developer and BA who share your opinions on Quality. Work with them and use the success to show the rest of the team how much better and quicker the turnover was without rewriting and rushing to meet the deadline. Offer to work with the more reluctant team members, point out the issues that you would term as ‘quality’ issues, and they will start to understand and learn from you.
If you are reading this as a PM, BA or developer, please do not leave the tester in your team to bear the overall responsibility. Remember that in football, if the goalie lets in a goal, its a team failure – midfield and defence failed to do their jobs and left the goalie to do all the work!