Making the transition to agile testing can be a perplexing challenge, especially for test teams that have relied heavily on manual regression testing or have not yet automated their tests. In many cases, testers may excel at exploratory testing but do not automate their processes. Furthermore, they might wait for a finished product before beginning testing. So, how can a test team effectively transition to agile testing, keep pace with technological advancements, and ensure they are contributing to the agile development process?
The challenge often lies in a fundamental shift in mindset and approach. Agile development teams are expected to deliver a functional product in every iteration. While they may not be obligated to release, the software must reach a certain level of quality. This means that the traditional view of testing as a phase that occurs after development is completed needs to evolve. Testing in agile is not just about finding defects; it’s about managing risks.
Testing provides critical insights into the product being developed. It doesn’t guarantee perfection, but it does determine whether the product aligns with the intended goals. To achieve this, testing should be aligned with the product itself. For instance, if the product has a graphical user interface (GUI), testing should involve interactions with the GUI. However, testing from the GUI perspective can be time-consuming.
A practical approach to address this is to develop tests incrementally, as features are built. This way, you don’t need to wait until the entire product is ready for testing, and you can gather valuable information about the product under test as you progress.
The key issue often arises when the team doesn’t collectively own the concept of “done.” Without a clear and shared understanding of what constitutes a “done” feature or story, testers may appear slow because they cannot complete their testing until the entire system is integrated. To address this, teams should establish a collaborative definition of “done” that reflects their specific product, consumers, and challenges.
This definition of “done” should consider factors such as code review, unit testing, system-level testing, and GUI testing. It should be tailored to the unique needs and risks of the product. For some teams, this may mean that a feature is considered “done” when developer tests are completed, and system tests are created and executed under the GUI, with periodic GUI-based checking.
The definition of “done” is not one-size-fits-all; it’s a reflection of the product’s complexity and risks. Teams must consider the consequences of launching a product without specific types of testing to determine what is necessary in each iteration to achieve a release-ready product.
Unforeseen Domino Effect: The Ripple of Consequences
In essence, the transition to agile testing is not just about changing processes; it’s about a fundamental shift in mindset. It requires a shared understanding of when a feature or story can be considered “done.” By aligning this definition with the product’s unique requirements, test teams can effectively contribute to the agile development process while ensuring the software’s quality and reliability.
Once you’ve outlined your expectations for an iteration, it’s natural to think about incorporating testing.
Similarly, when a testing team aims for the “perfect” test framework for their project, it can be a noble aspiration. However, the challenge lies in not always knowing what the perfect framework entails until the project nears completion. If you wait until the project is finished to incorporate testing, you risk doing it too late in the development cycle.
Instead of striving for an impeccable test framework from the outset, consider constructing a “just-good-enough” framework initially, with plans to refine it iteratively. This approach provides the testing team with enough automation to kickstart their efforts while allowing room for adjustments and improvements as the project progresses. It avoids the pitfalls of being locked into a framework that may no longer align with evolving project needs, which can be costly in terms of time and resources.
It’s essential to recognize that testers, much like consumers of a product, may not be able to articulate precisely what they want or need in a test automation framework until they have hands-on experience with it. Therefore, starting with a flexible and adaptable framework allows testers to better understand their requirements as they work with it, leading to more effective and efficient automation solutions.
Reaching ‘Done’: The Collaborative Journey in Agile Development
Imagine a scenario where a story requires the involvement of two programmers and one tester. The developers work together to create the feature collaboratively, while simultaneously, the tester adapts the tests, adds necessary automation, or integrates the tests into an existing automation framework. However, what if you’re transitioning to agile and haven’t yet established a framework? In that case, one or more of the programmers can team up with the tester to create a suitable framework and incorporate the tests for this functionality.
There’s no rule stating that programmers cannot assist testers in establishing test frameworks, writing test scripts, or even creating tests to expedite the completion of a story. When there’s a shared understanding of the team’s definition of “done,” it only makes sense for team members to support one another in achieving that definition.
This approach fosters a spirit of collaboration and collective responsibility within the team. It acknowledges that in agile development, the success of a story isn’t solely the responsibility of one role but a collective effort where team members contribute their expertise to ensure that each piece of work meets the criteria for being considered “done.”
Conclusion
In conclusion, the journey towards comprehending what “done” means in agile development is one of collaborative effort and adaptability. Building a “just-good-enough” testing framework, especially during the transition to agile, underscores the importance of teamwork and mutual support within the development team.
When programmers and testers work hand in hand to bring stories to completion, regardless of whether it involves creating test frameworks, writing scripts, or crafting tests, it strengthens the collective ownership of quality. Agile development thrives on the principle of shared responsibility, where every team member contributes their skills and knowledge to ensure that each piece of work aligns with the team’s definition of “done.”
Ultimately, the synergy between programmers and testers, along with their dedication to achieving a common goal, paves the way for successful and efficient agile development. It’s a testament to the power of collaboration in delivering high-quality software products that meet both functional and quality standards.
