Page History
...
There have been many contributions on this topic, including the by Brian Marick & Lisa Crispin).
While the Testing Manifesto shows us how to look at testing in an Agile context and the mindset changes from "old ways" of looking at testing, the Agile Testing Quadrants provide a different perspective: what kinds of testing and tests are there are, how can they be grouped, their purpose/fit and how to choose which testing to perform at any moment based on the quadrants and the risks we want to mitigate.
The Testing Manifesto
...
Automated tests can run as many times as you wish during the whole development life cycle and their results can be tracked at the Test Plan level.
The code of automated tests can be linked to Test entities and reviewed, as you would do for user stories or bug fixes. Even during PRs, you can obtain a testable asset and execute tests against it (automated or not).
...
Xray provides the means to all team members, including anyone performing testing, to participate on the review of work items, discuss and clarify them before they're committed and their implementation starts.
Avoiding bugs right from the start is essential to avoid high bug fix costs.
Although we may not be focused on "finding bugs," if they arise we need to make sure they're found ASAP. Having automated testing, starting with unit tests and going the upper layers, is essential to find bugs and fix them right away.
...
As an example, BDD and Cucumber based Scenarios can help on building the right system, by involving testers, developers and customers.
Promoting collaboration between all "stakeholders" in any of the issues being worked on is essential to build the best system. Testers can provide valuable feedback besides authoring and executing tests and this feedback may be provided, or even given to them, on any of the work items.
...
Thus, by having coverage information always present, on the issues being worked out and also on the Agile Boards where team members manage and track their progress, everyone can see their real status (e.g. OK, NOK), which also makes everyone responsible for taking actions in order to make sure they are OK (i.e. properly tested).
Agile Testing Quadrants
by Brian Marick & Lisa Crispin) provide a way to group different kinds of testing in 4 quadrants. This approach considers whether they are business or technology facing, and whether they are mostly used to support the team and guide development or to critique the product.
Quadrants are numbered although their number is just a mere reference to be used between team members.
The idea is to continuously assess risks and to mitigate them focusing on the quadrant(s) that can better target those risks.
Quoting Lisa Crispin: "Consider where the highest risk might be and where testing can add the most value.".
