Creating testable stories
In writing a well-defined story, the story follows the INVEST model. In this acronym, ‘T’ stands for being ‘Testable’. It means that the story should be written in a way that can be tested. Writing testable stories helps to conclude the development. A story should be completely and accurately tested to be marked as ‘Done’.
When something new is introduced into the product, it should be included in the test plan. Testing time estimation should be high enough to cover the uncertainties.
Collaborating with customers and developers
One of the principles of Agile development is constant collaboration with customers. From a testing point of view, testers need to collaborate with customers or their representatives to explore stories in detail. Through the examples that are given by customers, testers can write acceptance tests. Though this is usually done in iteration planning, testers may need to contact customers to ask questions from them to write the tests at the beginning of the iteration. It starts with examples and the tester turns these into high level tests. The designed tests should cover both intended and unintended behaviour of the code. Testers can ask customers to review high-level tests as well.
Testers should review high-level tests and requirements with programmers as well to make sure programmers know how to develop the story and start coding. From the other side, collaborating with programmers helps to identify high risk parts of the code for the testers. Programmers can help testers to focus on these areas from a technical point of view and design detailed test cases. This practice provides the opportunity of mutual learning between testers and programmers as well.
Test cases as documentation
High level tests and executable tests need to be documented along with the requirements. The documentation should be updated as the requirements may change at the beginning or during iterations. One of the benefits of including executable tests in the requirement document is to remove the possibility of any argument on the desired output of the code.
Contrary to the traditional idea that the Agile values and principles do not advocate documentation, usable documentation is a powerful tool and the point of further reference for all team members from an Agile perspective. Team members may use Wiki as a flexible documentation option and refactor it over time to better show the hierarchy of the subjects. But team members may invest time on finding more powerful tools for their documentation.
Recommended Further Reading
The following materials may assist you in order to get the most out of this course: