Do you feel there are many back-and-forths between developers and QAs within your team?
The frustrating cat-and-mouse games within SW development teams are pretty usual. The most common ones are between developer and verification roles (e.g., testers, code reviewers, etc.). As discussed in the earlier post, teammates working on the same challenge separately, tend to come to quite different solutions.
For example, developers and testers typically approach user stories from different perspectives. Developers identify behaviors to make them work, while the testers identify behaviors resolved to prove that there are no issues. Working in isolation, they, most probably, identify most behaviors equally. Those cases will pass the verification (if implemented correctly, of course).
However, there are cases uniquely identified by either of the parties. Now, those are the problematic ones!
Cases identified by testers but unidentified by developers will come back as bugs. Testers know pretty early that they would test those cases. Without letting developers know what will be verified, chances are that bugs will be reported.
A similar goes for the cases identified by developers but missed by the testers. Their nature is a bit different, though. They might not be discovered until their later manifestation (e.g., in production, or when it is expensive to correct them). They are similar to traps being planted!
This common dysfunction leads to expensive back-and-forths, unnecessary reworks, and dangerous code in production.
Do you want to reduce unnecessary back-and-forts within your team and improve the quality of results?
Favoring individual work and work in isolation over team collaboration has serious downsides.
At least it leads to:
▶️ Lower quality of the outputs (e.g., more bugs)
▶️ Subpar design decisions
▶️ Wasteful development process
▶️ Issues with knowledge sharing and building team knowledge
Providing opportunities for solving problems collaboratively, not only reduces the occurrence of traps and bugs but also tends to improve overall design decisions.
The illustration of developer-tester interaction provides a way of implementing continuous brainstorming within an SW development team:
Not only are the identified behaviors (implemented as functional paths through code) known to all teammates involved in the activity but also, through the exchange, new behaviors are frequently identified.
By doing so, developers will no longer miss the implementation of the behaviors to be tested. Nor will testers miss behaviors they haven’t thought of themselves.