Category Whitepapers and Guides
Software testing is still too often seen as a bottleneck within engineering teams. If you were to search for the term ‘software testing bottleneck’, the first result may be from a website called ‘DevOpsDigest’ which states:
“all too often the software testing team, who come in towards the end of the cycle, is labelled as a bottleneck that slows down the process.”
The Agile Manifesto was published in February 2001 and the first edition of the Scrum Guide was published in 2010. Both publications promote collaborative ways of working in order to develop better software. The Scrum Guide goes as far as to describe an ideal cross-functional team.
Given the above, why do we still see comments about testing being left to the end of the Software Development Lifecycle (SDLC)? As teams have adopted Agile practices and ways of working, have we been guilty of persisting with the developer and tester silos, but in a less obvious way?
At ECS Digital, we realise how important automation is to the improvement of a team’s processes and workflows. This includes the implementation of automated tests within a team’s CI/CD (Continuous Integration/Continuous Delivery) pipeline. However, perhaps even more importantly we value the human interactions that occur within teams – especially between traditional tester (QA) and developer roles.
I would like to use this article to describe some of the successes I’ve had when working as a test specialist within a Scrum team. I will also describe how I’ve approached sharing the testing effort reducing waste further down the SDLC.
One of the key things to improving your team’s processes is getting test specialists (and developers) involved as early as possible. This includes when designs are being discussed by Product Owners, Business Analysts, UX specialists and so on.
Testers working on the product design often have a better idea of how everything ties together and are quick to ask questions such as ‘what benefit does this idea bring to the customer?’, ‘how does this effect feature X which does the same thing elsewhere in the product?’ and ‘what data do we have to suggest this is worth developing?’.
By getting the team exposed and involved in asking these types of questions, as well as introducing the sort of critical thinking that testers so often display, it can help to reduce waste further down the development process. Ideas can be refactored before any line of code is written.
Similar to getting testers and developers involved in testing ideas, it’s also important that testers are included in technical design and refinement sessions. Three Amigos sessions are essential to helping the team gain a shared understanding about the work being worked on in the upcoming sprint.
Getting the whole team into a room (or on a call) and visually mapping out the design of the functionality about to be developed can further increase testing knowledge within the team. Testers can gain more of an understanding of the architecture of the system which can greater inform their testing ideas.
Asking questions such as ‘could we test this by doing X?’ gives developers more of an opportunity to get involved in the testing effort. It also helps testers in the team highlight potential testing problems and ways that the team can work together to solve these problems e.g. build a tool to populate rows of data when testing a new database.
The advantage of the team gaining a shared understanding of how the functionality about to be developed should behave is that it removes potential disagreements further in the process. As a tester, I’ve had too many experiences of raising bugs that a developer on my team has disagreed with as it wasn’t specified explicitly in the Acceptance Criteria. With the hope of removing a blame culture, I have found that discussing these ideas up front greatly reduces these situations. They can also reduce wasted efforts by seeing that less bugs are raised as the functionality is deployed into a development or test environment.
Getting developers and testers working together on writing automated tests is where collaboration is probably most likely to succeed.
This can include unit tests as well as integration tests. I used to find value in sitting with developers as they were writing their unit tests. I could add some of my exploratory testing skills into their unit tests e.g. trying out the test running maximum, minimum or boundary values.
In fact, I used to pair with developers to write web service integration tests for similar reasons. If you have considered doing something equivalent, your aim should be to write integration tests as the functional code is being written so that testing doesn’t become a bottleneck when the code is ready to be deployed through your pipeline. By working on these tests together, testers can share their test ideas and in exchange, developers can gain an understanding of the integration test framework and share some of their better coding practices.
Through the adoption of this new working of way, your team is promoting a shared ownership of your automated testing framework, whether it be unit or integration tests. This means that anyone in your team should be able to write or maintain these tests at any point during the SDLC. An added benefit for the modern business who has an ever evolving workforce.
Quality is, or certainly should be, everyone’s responsibility and becomes a valuable piece of your transformation puzzle when built into the product development process earlier than ever before. A few benefits that come from coaching your team to coach in this way; improved communication and relationships within your teams, shorter feedback loops and QA no longer appearing as gatekeepers for quality.
A great number of teams are still treating testing as a phase at the end of the SDLC rather than an activity that occurs throughout a team’s sprint. I hope this article has given you a few ideas on how to encourage all team members to utilise their ‘testing mindset’ and has demonstrated the value of doing so.
If you would like to do some further reading on a collaborative testing effort then I would encourage you to check out ‘Agile Testing’, ‘More Agile Testing’ and ‘Agile Testing Condensed’ by Lisa Crispin and Janet Gregory.
You may also be interested in a keynote I delivered at Nordic Testing Days 2019 – you can watch the recording on YouTube here.
About the author:
Ali Hill began his career testing video games in 2014 before moving into an Agile testing role. He now works as a Delivery Consultant at ECS Digital. He has a passion for learning. Recently Ali has been interested in learning how software testing can flourish in the world of DevOps and Continuous Delivery. Ali can be found talking about technology on Twitter, blogging for ECS Digital or at the Edinburgh Ministry of Testing Meetup or DevOps Playground, both of which he helps to organise. He is also a keen public speaker and can be found speaking at multiple technology conferences throughout the year.
You can find other insights by following the author on twitter!