Some of the teams that claim to be doing “Agile” aren’t.
Compressing the schedule, throwing out the documentation, and coding up to the last minute is not Agile. Agile methods are above all sustainable.
Agile teams really do need testers, but they don’t need is QA acting as a Quality Police.
Nine Principles for testing on Agile teams:
1. Testing Moves the Project Forward.
The adversarial relationship that some organizations foster between testers and developers must be replaced with a spirit of collaboration.
2. Testing is NOT a Phase!
Agile teams test continuously. Continuous testing is the only way to ensure continuous progress.
3. Everyone Tests.
On traditional projects, the independent testers are responsible for all test activities. In Agile, getting the testing done is the responsibility of the whole team. Testers execute tests, and developers do too.
4. Shortening Feedback Loops
Feedback loop is the time between when a programmer writes a line of code and when someone/something executes that code and provides information about how it behaves.
Short feedback loops increase Agility. On Agile projects the software is ready to test almost from the beginning.
Agile projects favor automated tests because of the rapid feedback they provide.
Manual testing, particularly manual exploratory testing, is still important. However, Agile teams typically find that the fast feedback afforded by automated regression is a key to detecting problems quickly, thus reducing risk and rework.
5. Keep the Code Clean.
This principle is an example of the discipline that Agile teams have.
6. Lightweight Documentation.
Instead of writing verbose, comprehensive test documentation, Agile testers:
- Use reusable checklists to suggest tests
- Focus on the essence of the test rather than the incidental details
- Use lightweight documentation styles/tools
- Capturing test ideas in charters for Exploratory Testing
- Leverage documents for multiple purpose
7. Using One Test Artifact for Manual and Automated Tests.
The test could be executed manually, but more importantly that same test artifact becomes an automated test.
8. “Done Done,” Not Just Done.
In traditional environments that have a strict division between development and test,
it is typical for the developers to say they are “done” with a feature when they have implemented it, but before it is tested.
Agile teams don’t count something as “done,” and ready to be accepted by the Product Owner or Customer until it has been implemented and tested.
9. Test-Driven Development.
In traditional environments, the requirements and design come first, and the tests follow. And executing those tests happens at the end of the project. This is a “testlast” approach.
However, tests provide concrete examples of what it means for the emerging software to meet the requirements. Defining the tests with the requirements, rather than after, and using those tests to drive the development effort, gives us much more clear done criteria and shared focus on the goal. This test-first approach can be seen in the TDD and ATDD practices.
Six Practices:
1. Automated Unit / Integration tests.
2. Test Driven Development (TDD).
3. Automated System-Level Regression Tests.
4. Acceptance Test Driven Development (ATDD = Discuss -> Distill -> Develop -> Demonstrate).
5. Exploratory testing.
6. Version tests WITH code (Source control repository includes source code, unit tests, and system tests).