Agile teams deliver continuously. Which means;
- Code must be integrated continuously
- Code must be tested continuously
Each story is integrated to the master or develop branch once competed. Ideally small code increments are integrated to master/develop as progress is made within a story.
Each story is tested immediately. First with unit tests, then with integration tests and lastly with acceptance tests. This accomplishes the following;
- Developers are writing tests when the algorithm or process is still fresh in their minds.
- Developers are able to examine external dependencies immediately and change/update code as necessary.
- Developers are able to fail fast if any issue is identified through broken tests.
- Product owners are able to see the end result of the story and give quick feedback.
Each added test (unit/integration/acceptance) helps to build a regression test suite for the product. This enables teams to implement new features and fix technical debt by refactoring without any fear of breaking existing functionality. This is a powerful notion, and frees developers to move fast with new feature implementation and defect fixes. This in tern increases team velocity.
All team members write tests. This includes acceptance tests as well. The QA engineers on the team guides the team on testing strategy and formulates best practices. There is no wall between development and QA. Its one team. Both developers and QA engineers bare responsibility for the quality of the product. If they do not work together agile teams will fail. This is a fact.
All tests are written as automated tests when possible. There are some tests that needs human intervention. That is inevitable. But these should be kept to a minimum. Existing testing frameworks enable developers to automate even the most complex tests. Manual QA is used to perform value added tests, it is never used for repetitive tests.
All tests are run on every code integration. This includes unit, integration and acceptance tests. Teams can use a continuous integration server like Jenkins to run these tests. These tests can be performed in multiple steps. Each step giving the developer and the team increasing confidence on the integrated code.
Continuous integration server dashboard is displayed prominently on the team area. It is monitored frequently for failures. All test failures are inspected immediately and fixes are integrated to master/develop in a timely manner. If that is not possible plans to revert the changes must be made. The idea is to keep the tests stable and green as possible. If tests are left broken the team cannot be confident enough to integrate more code changes to master/develop and leads to decreased velocity.
Teams that follow this recipe will have an improved chance of producing quality code continuously. Product Owners will be happy about the increased team velocity. Developers will be happy about the confidence to make changes. Business will be happy about the increased quality of the product.