Agile is recognised for delivering viable products with speed and confidence, and for favouring user-centric features rather than simply a ‘belief’ of a user’s need. With agile, users are included throughout the journey, and ceremonies such as show and tells keep the project team focused on needs-based delivery.
But ironically for professionals in the change business, an almost universal resistance to change becomes apparent whenever the word ‘agile’ is uttered. Generally, an impression has been unfairly formed that by journeying to agile, key roles become redundant.
The truth is far from it – even small changes, implemented as part of the journey to agile, can improve the quality of an IT project.
Changing opinions
Traditional software delivery – waterfall – tends to view testing as a manual activity which takes up a large chunk of project time. Therefore testing is often seen to be a bottleneck that should be crammed into the delivery’s closing weeks.
Agile debunks this perception. By implementing continuous delivery, testing time appears to be reduced even though it isn’t. Throughout the delivery, testing runs in parallel with development, resulting in the effort being spread evenly throughout the project.
> See also: The agile concept ‘fail fast’ gets bad press but is misunderstood
What continuous delivery doesn’t do is reduce quality – it simply builds quality in from day one, through ongoing analysis, development and testing.
Also while Waterfall generally places teams in silos, defining manual processes and rigid job roles, agile challenges these boundaries without breaking them. Teams are formed by multi-disciplined players that add cross-functional value to the product they develop. This encourages collaboration and fosters a natural test driven development.
Introduce small changes
A journey to agile doesn’t need to be completed overnight. Small changes can be made without massively impacting roles or dramatically changing them.
One quick win is to alter the way that testing is thought about. For example, ensuring that test effort is properly estimated within the Sprint, and then redefining the Definition of Done as development and test reach completion will have an immediate positive effect.
Teams can be conditioned to think that testing has to be built in to each small release by using small automated tests through continuous integration. Gradual changes to workflow on task management tools (either electronic or manual) will help further and will contribute to building quality from the outset.
Another small change which is easily implementable is easy access to key artefacts such as the Test Strategy and Approach. These documents vital because they point the test team in the right direction, ensuring understanding, and fostering an ability to articulate key principles and information.
If managed correctly, Stand-ups can single-handedly improve communications. Introducing a 10-minute Stand-up meeting at the beginning of each day maintains focus while helping to nurture the mentality of a ‘one-team one-product’ blended cell.
Again, Stand-ups are a small change which are easily implemented and not too disruptive, but be cautious – they shouldn’t evolve into sit-down finger-pointing sessions.
Output
One of the most common misconceptions of Agile is that documentation and planning are not required.
While test scripts should still be written (they are vital for articulating what the test does, what its outcomes are, and what should happen should the test fail), there is no requirement to write detailed scripts, especially on a greenfield development, where pages and apps change on a frequent basis.
The key is ‘necessary and sufficient’ documentation. Give enough information – but never too much. If this means providing comments or tags in the script, or using a Wiki or task management tool to form a picture, then so be it. The key is to build a picture.
Quality standards
Software testing is the same as software development. Both should abide by the same standards, especially around automation. By ensuring that foundations are solid, quality builds on top of quality. Peer reviews and exposure to code quality tools will introduce standards and develop the right ethos.
Companies often ask: ‘what is the quality of my application?’ In truth, testers can simply provide a pass rate when attempting to answer this question. It’s a given that 100% coverage will never be achieved, so the pass rate only relates to the percentage covered. And that only relates to that particular build and the number tests that have been run on that particular software version.
Analysing the question becomes complicated, and it becomes difficult to answer convincingly.
> See also: Have we lost the art of ‘agile’?
Time should be spent defining the metrics that are useful to stakeholders, and applying them consistently across the delivery. In itself, this builds confidence with the testing activity and the wider product.
Bringing it to the left
The quicker a test engineer gets exposed to code, the better. While this is a fundamental fact which most professionals generally agree with, organisations do not actively look to achieve this. Techniques which foster this, for example, ‘Three Amigos’ or ‘Rubber Ducking’ (or even both!) should be employed.
Agile is a philosophy. Players need to adopt a particular mindset and way of working. Without the understanding of what is trying to be achieved and why, the journey will be challenging. Agile fosters quality from the outset. Most of the journey is completed before any physical or structural changes to processes take place.
For testers, the journey to Agile does not have to be treacherous! It is an opportunity for personal development and growth, enabling creativity and fostering the principle that it allows testers to do what they do best: Test!
Sourced from Cassy Calvert, Test Services Manager, BJSS
