By Markus Albrecht
Over the last few years I’ve had more opportunities to pair with developers whilst being part of the testing team at Nimble Approach. During this post I want to explore what I think enables effective pairing between developers and testers, and what it means for the quality and overall delivery of software.
Shift the Testing Left
This concept is not new, but it’s served me well. The sooner I can examine the solution under test, the easier it is to fix any potential issues. I have found that having the capability to spin up a local instance of the software with all its dependencies is critical to enabling fast feedback.
This is not something that’s always possible, however it’s always worth having a conversation with the team to see if it is something that can be leveraged.
How Does This Enable Pairing Between Developers and Testers?
Testing locally gives me a greater degree of control of exactly what I am testing and when I test. I like to conduct a lot of my functional testing on the feature branch that the developers are currently using. This means that when I discover something of particular interest, it is easier for us to look at it together, because we are both looking at the same version of the code.
In addition, there is no waiting for the code to be merged and deployed to a test environment. Something which can save a lot of time.
By pairing using the feature branch, the triage and implementation of simple defects can be done there and then. This instantly improves the quality of the code.
Even in the event of discovering more complex defects. The act of running tests and debugging the code as a pair gives the developer greater context and understanding of the problem. Thus, helping them solve the issue.
What Does This Mean for Detect Reports?
Defect reports are time consuming to write and even the most skilfully crafted ones can be open to interpretation.
Of course, this problem can be overcome by triaging the defect once the report has been written. While this process achieves the desired outcome, it is lengthy, far from efficient and a far cry from triaging and fixing defects via pairing.
Whilst I do not create a defect report unless necessary, there are occasions where one may need to be logged. Some examples might include:
- It is determined during pairing that further feedback is required by other members of the team who are not immediately available.
- The defect is deferred and a record of it is needed to ensure it is not forgotten.
- Organisational requirements such as all defects being logged for legal, compliance or other reasons.
How Does Pairing Improve Your Team?
One of the best things I have noticed about pairing is the relationships I have built with members of my team. Yes, I learnt more about the solution being developed, but the increased interaction meant I also learnt a lot about my colleagues. Both on a personal and professional level.
As I paired with different members of my team, we began to communicate better with one another and ultimately work more cohesively.
This is particularly important to me, especially now the pandemic has made face to face interaction much harder.
What Have I Taken Away from These Experiences?
- Testing locally on feature branches provides faster feedback and speeds up the development cycle.
- Pairing with developers whilst testing allows defects to be fixed faster and provides better understanding of the solution being developed.
- The number of defects that need to be logged is drastically reduced. Providing more time to perform further testing, whilst spending less time on administration.
- Pairing with colleagues increases communication, builds relationships and makes for a more cohesive team.
Want to see how your developers and testing teams can work better together? Get in touch and lets talk.
