QASymphony / Blog / 5 Ways Companies Don’t Drive Agile Methodology into Agile Testing
5 Ways Companies Don’t Drive Agile Methodology into Agile Testing
Agile development is becoming the industry standard. Atlassian’s JIRA is arguably the most widely adopted tool for managing Agile development, even development teams that do not fully adhere to the Agile manifesto incorporate Agile-like concepts into their development methodology.
However, what is not as common in development teams is a thoughtful understanding of how agile development will impact testers and testing teams. From my perspective, there are 5 core agile beliefs that testing teams overlook. Below I’ve compared these beliefs via traditional testing approaches and agile testing methods.
1) Simplicity, or the art of maximizing the amount of work not done, is essential.
Traditional testing approach: Let’s say development is rolling out a new feature and you begin with a sanity test just to see that the general look and feel of the requirement has been fulfilled. If the feature appears to work as desired, you would need to go back and recapture those details to create your manual scripted test case.
Agile testing approach: Maximize the amount of work not done by recording the sanity test and creating the manual scripted test case directly from the recording of the sanity test.
2) At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Traditional testing approach: Formal periodic waterfall-style management reports. Information on test results is infrequent, limited, and “hoarded” by management.
Agile testing approach: Dashboards with real time results and stats available to everyone on the team to “see as they go.” At any time, developers, testers and clients have visibility into what is happening throughout the process, fostering an inclusive problem-solving culture.
3) Communication is best made face to Face.
Traditional testing approach: With distributed testing and development teams in various locations, frequently oceans apart, most teams have devised elaborate processes and methods for collecting defect data that are at best inefficient and at worst inadequate for properly reproducing the errors encountered.
Agile testing approach: The easiest way to show a defect is to have the developer look over the tester’s shoulder. Session capture tools that capture robust but portable data – especially that can be accessed from a central repository by anyone in the world — is the next best thing to having the right people together in the same room at the same time.
4) Deliver software with a preference for a shorter release times.
Traditional testing approach: Sprints are designed around stories and features that can be completed by development within an agreed upon time box. Agile teams can be derailed by a false belief that testing time is constant from sprint to sprint, regardless of the features being delivered. Time to test is not factored enough into Sprint-thinking.
Agile testing approach: Integrate test design earlier by taking a more active role in helping to craft the sprint. Testers can provide input and insight into determining what can realistically get done – and delivered — across sprints. Contribute to shorter timeframes by insisting that development is acceptance test driven and test design is integrated earlier in the process.
5) Continuous attention to technical excellence and good design enhances agility.
Traditional testing approach: Many testing teams feel locked into testing methodologies, either hemmed in by software investments geared to outdated methodologies or too busy testing to re-evaluate their processes and tools.
Agile testing approach: Good design and technical excellence also applies to testing. Drive better outcomes by empowering testers with information and visibility. Integrating test case design into development creates smarter testing. The earlier you make your impact in the process, the sooner you will create better outcomes.
If your testing approach and technology are not allowing you to provide intelligent, analytical real time feedback to development, are you truly getting the benefits of Agile you could be?
Kevin Dunne is a product specialist for QASymphony, striving to ensure the continued success of existing and prospective members of the qTest community. Having acted as a tester in his previous jobs, he enjoys interacting with customers on a daily basis to keep current on the latest trends and tools in the testing world. He is always eager to hear what others think about the industry – feel free to drop him a line at firstname.lastname@example.org or connect with him on LinkedIn: www.linkedin.com/pub/kevin-dunne/36/b73/ba7/