Test Planning in Agile
Test planning the planning of the activities necessary for testing a solution. A test plan is defined as a document detailing the objectives, target market, internal beta team, and processes for a specific beta test for a software or hardware product.
The structure of a Test plan
The traditional Test plan document contains the following:
- Scope – This defines the scope of the testing. This is based on the understanding of the requirements. Unclear and poorly defined requirements can result in a badly delivered scope.
- Out of scope – In as much as it is important to define what we want to cover, it is as equally important to understand what we cannot or do not want to include in the scope of the test.
- Assumptions – Any assumption that are known that will contribute to the success of the testing is documented in this section.
- Types of tests – Identification of what tests are needed. E.g. Unit testing, functional testing, non-functional testing, exploratory testing, automation, integration testing etc.
- Schedules – This is an attempt of time-boxing the activities needed to cover a successful test. This includes schedules for test scenario definition, definition of test cases, test data, environment set-up, execution and cycles.
- Role and responsibilities – What are the roles and who gets to execute them?
- Deliverables – What is the expected test artefact outcome?
- Environment requirement – Where is the testing going to occur and is that environment capable of handling the tests? Is there enough test data, can it behave the same as a production environment, can it take enough load etc.
- Tools – Identify tools that are needed to carry out the testing. These can be easily identified once we know what types of tests will be executed.
- Bug management – What is the plan when a problem is found? Who gets to attend to it? How is it reported to that person?
- Risk management – The idea here is to identify any risks pertaining to the scope, what is the likelihood of those risks coming to life and how are they going to be managed should they occur.
- Definition of done – This is important. Defining what done means is important so to know when to stop otherwise the process can continue in an infinite loop.
The majority of these items can only be determined accurately based on a known set of requirements. The Test plan is then done either in parallel with the software requirements specification or once the Software Requirements Specification (SRS) is completed and agreed upon. In a traditional project management approach the deadline is set and understood therefore the schedules defined in the test plan need to fall within in that understanding. The appropriate candidate to compile a test plan is a member of the testing team. Though some of the items in the plan might need input from different people outside the testing team. It is important that this output is owned by the testing team.
Recommended Further Reading
The following materials may assist you in order to get the most out of this course: