What if a product under development was not given its due importance for quality? “No quality” is a very dreadful situation – I am not going to even get there – I am saying even “lack of quality” is a dangerous situation to be in. Today while being agile is important, end users are giving utmost importance to quality than ever before. They are ready to participate in the development process and be aware of specific feature cuts than having it all, with quality not up to the mark. What is noteworthy here is:
- This is not quality just at an implementation level. This is quality at an ideation, design, UX, architecture level
- This is not quality just at a functional level. This is quality at a performance, security, accessibility, usability, globalization level
- This is not quality at a simple desktop level. This is quality at a mobile, cloud, multi device level
That said, the software testing fraternity should exercise this visibility with care. They cannot and should not take undue advantage of all the importance to enforce a very stringent software testing strategy where the only goal is quality assurance and testing. They need to be savvy in understanding and translating a top down strategy that weighs in quality with other core parameters including time, feature set, cost, and competition, to ensure a right balance across the board. And for this to happen, the key result areas (KRAs) for quality need to be created with a holistic understanding of quality goals weighed against other product development goals. A tightly coupled digital transformation solution that enables each of these individual areas including quality assurance and testing to operate independently and interdependently is the best way forward.
While I say lack of quality is dangerous, a planned lack of quality in favour of the larger goals, may often be an acceptable solution. Herein a planned lack of quality is conscious decisions around what bugs are ok not to fix, what areas can take less focus on, where automation can lag, what tests need not be part of regression suite, how can we be optimal in test suite execution, what combinations can be dropped off a test execution matrix, what devices can take on just a smoke coverage instead of full coverage etc. These help the team and users understand that as guardians of quality we understand not just quality but also its positioning in the overall product development ecosystem to give each area its deserved focus. Once this mature understanding is established not just at the top management level but even at the team level, there is overall acceptance and seasoned application over time on what we cannot compromise on and what we can afford to live with. And clearly we then take the onus in explaining this to the entire team right from Sprint planning meetings – this gives quality a new found respect, definition and acceptance amongst not just internal stakeholders, but even the external stakeholders, who are the end users.