Agile is an iterative development methodology that encourages an entire project team to participate in every aspect of development. The project’s requirements evolve as the iterations progress through collaboration between the customer and the self-organizing teams. The Agile methodology doesn’t set coding and testing apart as two separate functions but weaves them together incrementally so that they can inform each other throughout the process.
Agile presents an innovative departure from traditional, sequential life-cycle models like the V-model, and other iterative ones like RUP. Testers who are aware of these differences can work more efficiently and effectively. The Agile models differ in integration between testing and development activities, work products, naming convention, entry and exit criteria used at various levels of testing, tool usage, and how independent testing is utilized.
Agile testing is a team effort. If each individual is siloed, working on their own, the project becomes a series of parts that may or may not harmonize. But an Agile team can achieve quality and success by working together to fulfill a common, collaborative objective. It’s not “My work”, “your work”, or “his Work”. In an Agile team, all you will hear is, “our work”, as in: “We have completed our Work”.
Given the fast-paced, quickly-evolving nature of Agile project teams, as Agile testers, we must be able to learn new things and adapt to changes. This gives us the enticing opportunity to expand our skillsets. No longer are we just a part of the testing team – we’re working alongside developers, project managers, and more. By continuously collaborating with these teammates, we can increase our business acumen, domain knowledge, or technical skills. Plus, we can help our development team or customers by examining the features from various perspectives, making them aware of any problems or issues that may arise.
The optimal strategy is to focus our testing efforts on the areas where defects arise most frequently. We’ve found that this is the best way to achieve proper testing coverage within a limited time period, resources, and budget.
In the book "Growing Agile", coaches Greaves and Laing created their version of a Testing Manifesto, as a quick summary of an ideal mindset for thinking about Agile testing.
Testing throughout over testing at the end:
Testing is not a phase, it’s an ongoing activity. it starts at the very beginning of the development process when the user stories are written, along with coding, documentation and everything else. And it happens consistently with every new modification and addition. This way, you won’t be overwhelmed at the end.
Preventing bugs over finding bugs:
This means clarifying requirements before anyone writes a single line of code, making sure everyone – from the customer to the developer to the tester – have exactly the same understanding of how the project should work. In doing so, we can prevent bugs by just asking questions.
Testing understanding over checking functionality:
In Agile, testers should be the customer’s representatives. They must deeply understand their users’ needs and desires, as well as what they are trying to achieve with the product. Using this knowledge, they can ensure that each feature meets the customers’ actual needs, not just the specification, or even what they asked for.
Building the best system over breaking the system:
There is a common belief that testers are exclusively engaged in destruction, but this is only half true. Yes, a tester can try to destroy something, but there’s a lot more to the job. One should remember the main goal – to create a product that has value and performs its functions as intended. That is why simple positive tests, like reproducing actual user actions, are of top priority.
Team responsibility for quality over the tester's responsibility:
Testers cannot improve quality on their own. It’s a team effort. Testers determine the level of quality and inform the stakeholders, but it takes the entire team to make the necessary improvements.
Testers, developers, and business stakeholders – including the Product Owner, Project Manager, and scrum master – all have a role in testing. Developers perform unit tests as they develop features from the user stories. Testers then test those features. Business stakeholders also test the stories during implementation. Business stakeholders might use written test cases, but they also might simply experiment with the feature in order to provide fast feedback to the development team.
At Blink22, collaboration is part of our culture. There are no isolated workers here. Everything we do is part of a team, so the Agile methodology fits perfectly. By testing throughout the entire project, our teams can operate more efficiently and deliver deployment-ready applications with exceptional value.
