Following the successful QA testing of a user story, its status was upgraded to code merging and eventually to done. This approach proved effective for the initial two sprints, each lasting two weeks. However, by the third sprint, a significant obstacle emerged. The number of user stories in QA status had skyrocketed, and the team's velocity was heavily reliant on the tester's ability to test rapidly. As scrum velocity is directly tied to the number of user stories released per sprint, it became clear that QA testing was hindering the release process.

Overcoming the Testing Bottleneck through Strategic Resource Allocation

In an effort to mitigate this issue, additional testers were temporarily reassigned from other scrum teams to assist with user-story testing. While this increased the team's velocity, it introduced complexity in synchronizing efforts between teams. When a tester was reassigned to support another team, it had a detrimental impact on their original team's velocity. Although we managed to test more user stories over several sprints, we inadvertently created a significant problem for other teams. The gain of a single scrum team came at the expense of the entire company, prompting us to discontinue tester sharing.

A Pivotal Realization

It soon became apparent that the path forward lay in collaborative testing. The tester trained the team on smoke testing user stories at the UI level. Discussions ensued about risk-based software testing [1-2], testing for rapid feedback [1-2], prioritizing critical test cases, and iteratively testing the remainder. For user stories lacking a UI component, unit testing [3-5] and API-level testing were introduced [1-2]. As unit testing evolved and each developer performed a minimum set of smoke tests whenever applicable, our bottleneck was alleviated, although not entirely eliminated. Our velocity improved, but there remained considerable room for growth.

Reverting to Inefficient Practices

The team's mindset was that all members should contribute to testing to enhance velocity. Whole-team testing was viewed as a temporary solution to overcome our challenges, rather than a development best practice that should form the foundation for the team's growth and improvement. When the velocity issue began to improve, the team reverted to their old habits. Testing was once again primarily the responsibility of the tester. In sprints with fewer story points planned, the team either took on more user stories or performed bug fixing. The bottleneck of QA-based testing began to resurface.

Transforming Testing: From Bottleneck to Development Excellence

A profound shift in mindset occurred when the team recognized testing as an indispensable best practice, rather than a temporary solution. Following comprehensive training, education, and retrospective meetings, team members assumed ownership of testing responsibilities in the long run. It was acknowledged that testing was an integral aspect of every individual's role, albeit with varying levels of involvement and expertise. The goal was to tailor testing activities to maximize individual productivity and team performance.

Unit testing evolved from a desirable activity to a mandatory one, guided by principles outlined in [3-5]. It became the norm to write unit tests to detect bugs early and enhance the overall software quality. Factors such as code's internal quality [3] became a regular topic of discussion. Code reviews also became a standard practice, leading to one of the primary drivers of our team's growth: test-case reviews. These reviews could be conducted between developers or between a tester and a developer.

Technical Breakthroughs

Initially, test-case reviews were introduced as a training exercise where the tester guided developers on best testing practices. Key questions addressed included: What are the different approaches to creating test cases based on testing objectives? How to determine the level of detail in a test case, the number of test steps, and the scope of testing.

Developers began sharing their code with the tester, explaining the underlying principles and testing strategies. They also demonstrated how user interface interactions could be translated into code-level interactions. As the tester was responsible for reviewing test cases, she required a high-level understanding of the code, which developers provided by training her on the programming language fundamentals.

Developers refined their testing skills, adopting best practices for efficient and effective testing. The tester, in turn, gained a deeper understanding of coding basics, making her an ideal candidate for a software development role in testing.

Once developers were confident in writing and executing their test cases, they took over test-case reviews, which were incorporated into code reviews. Each user story included reviewed test cases, and the team eventually reached a point where test cases at any level (unit, API, UI) were reviewed by anyone in the team.

Fostering Unity and Collaboration

The introduction of test-case reviews had a profound impact on the team's interpersonal dynamics, prompting a constructive reevaluation of the traditional roles of software testing and development. This led to a reassessment of the boundaries between these two disciplines, sparking questions about where software testing begins and ends, and where software development starts and concludes. Is it always beneficial to maintain a clear distinction between the two? The test-case review process ignited thought-provoking discussions and debates, cultivating a deeper understanding of the commonalities and differences in perspectives among team members.

Conclusion

What began as an initiative to address the team's velocity bottleneck evolved into a best practice in software development. This transformation led to a collective growth and learning experience for the entire team, as individual members developed and improved through shared goals, challenges, and achievements. The team's mentality and bonding grew stronger, driven by a shared sense of purpose and motivation to learn from one another.

Test-case reviews played a vital role in this transformation, facilitating constructive interactions and knowledge sharing between developers and testers. By leveraging the test-case artifact and the need for collaborative testing, test-case reviews became the catalyst for improved team bonding and performance.

References

1. Agile Testing: A Practical Guide for Testers and Agile Teams, Lisa Crispin and Janet Gregory, 2008
2. More Agile Testing: Learning Journeys for the Whole Team, Janet Gregory and Lisa Crispin, 2014
3. Test-Driven Development: By Example, Kent Beck, 2002
4. The Art of Unit Testing, 2nd Edition, Roy Osherove, 2013
5. Effective Unit Testing, Lasse Koskela, 2013