Almost everything has evolved, reshaped and been taken to a different level in software development. It’s highly likely that we are no more approaching the product development/software development the same way that we would have been 10 years back. A lot of enterprises embraced the Agile movement that guided and emphasized the left over right.
At a high level, we are developing in short cycles, adding value in continuously, demonstrating value addition to the stakeholders, being receptive to their candid feedback.
That being the drive at high level, internal engineering practices went thru vivid changes notably
Silo functional team members vs cross functional team members
Managers planning vs whole team planning games
Weekly status reports vs daily standups
PUSH vs PUSH work units
Large big bang release vs shorter incremental releases and supporting practices
UAT testing at the end vs continuous usability testing
One Performance at the end vs continuous performance testing
and so on..
Plenty of changes have been forced at the engineering level, these are not mere changes in terminologies and ceremonies but require significant shift in mindset.
While there are plenty of motivation to transform the teams and help adopt Agile practices, most of them tend to be focusing on developer practices such as Whole team planning, Test Driven Development, Simple design, Pair programming, Continuous Integration, Continuous delivery etc, where do the Quality engineering practices fit in? no more specialist testers, testers learn to develop code, do developers learn those needed testing skills? What do we do to prevent bugs, detect bugs early in the cycle and how do we transform those traditional quality engineering practices into Agile, what would be the role of a tester in an Agile team..many more questions..
If you have questions somewhere along the lines, please read Agile Testing by Janet Gregory. They talk about a lot of good practices can be adopted by Agile teams to build quality in.
Amongst many great thoughts, one of the most interesting factor is that Quality != Testing
They remind the Underlined goal that ultimately we need to make sure our implementation meets our intention which meets the business need on a continuous basis.
This is a wonderful goal, how do we accomplish that..looks like we need 360 degree check on everything we do? How can we do this with every sprint?
Further reading on that book will guide us towards achieving this goal. However, some highlights that I like
Quality is about making sure that the team shares common understanding about the problem space. Team collaboration, ask right questions to the PO and understands before committing. This is something not new, what quality has to do here? Correct question but the emphasis here is to think beyond a story during planning, think like an eco-system and how this little story could affect the eco system, think like this little story is part of the bigger puzzle board and the importance of making it right, think about chain reactions that this little change could trigger and try to identify those end-user workflows that this story contributes or affects and hence derive those testing scenarios. So at the end of the planning meeting, the entire team would have talked about the story, especially, beyond design and coding, understood how an end-user’s action could cross this functionality, what an end-user would do before and after and essentially help the whole team to understand the problem space. When time comes, it’s highly likely that someone will write code and someone else might write tests but towards the same goal. Potentially, tests can be designed, written even before the code is ready. Upfront Test design and test case development could potentially help the developer and prevent bugs. Chances of finishing the story with desired quality within the sprint is high rather than deferring the test automation to the subsequent sprint. Of course, Automation plays a role here but Automation with appropriate intend plays a greater role.
These are partly my takes from that book from Quadrant 2. There are other Quadrants
Quad 3 – talks more about the importance of applying quality practices from Customer/end-user perspective and asking hard questions to your product
Quad 4 – talks about how Tools and technologies helps to apply quality practices from customer/end-user perspective
We started practicing Quadrant 2 in some of our projects and seeing great value..