Real people, real devices, on-demand.
A test plan is document outlining the goals, resources, and processes entailed in testing a software or hardware product. Why is this important? Prior to beginning a testing phase, it’s important to know which features will be tested, the specific tasks involved, which personnel will be involved at each step, and details about the testing environment.
Test plans are more commonly associated with automated, as opposed to manual testing, and can be broken down into various subtypes. Master test plans are higher-level plans that cover all other tests involved. There are then level-specific plans for unit testing, integration testing, system testing, and acceptance testing. You may find type-specific plans that focus on security or performance.
Here you state the purpose of the test plan. This is where you would identify the plan level, i.e. master plan or level-specific.
These are the items that appear within the scope of your test plan; this is what you’re testing.
Identify the risks and complexities inherent in the product you are testing.
This entails a description of features to be tested from a user’s point of view (i.e. non-technical descriptions). This differs from the list of test items above.
This is your overall strategy for the test plan, which should match the level of the plan. It will include details such as special tools used for testing, the metrics to be assessed, and the forms of regression testing to be executed.
In other words, what is the completion criteria for the test plan. At a master level, are all subsequent level plans completed? At a smaller level, must all unit tests be completed? A specified percentage?
Set a criteria for when to pause a test if not operating properly or finding expected results.
Concrete deliverables include: test plan document, test cases, test design specifications, tools and their outputs, simulators, static and dynamic generators, error logs and execution logs, problem reports and corrective actions.
If there are future portions of the software to be tested that do not fit within the scope of current testing, they may be worth sharing so as to prevent confusion (i.e. “this feature doesn’t seem complete”).
Is hardware required? What software (device/browser) specifications are required? How will the test data be shared? How will it be presented?
Is there any training necessary for testers to complete the planned testing?
Who is in charge? Roles? Assign accountability for the different stages of the plan.
It’s important to make realistic and valid estimates of the required test plan timeline.
Are there any risks associated with completing the project? Lack of personnel resources? Hardware availability? Potential changes?
Who is designated to acknowledge the project as complete and allow it to proceed onto the next level? This may differ from unit-level to master-level teams.
As you can see, creating a test plan is a relatively involved process that takes time, and likely multiple parties, to satisfy completely. However, having a clear plan from the outset of a testing process can pay dividends in organization, tracking, and efficiency.
That said, test plans are primarily a requirement of running test cases. One alternative to this is guided exploratory testing, which primarily utilizes manual, human testing. In this case, testing instructions can be written out briefly in plain English, highlighting broad to specific instructions surrounding a particular user flow or product that is being tested. You can read more about this type of testing here.
Internal QA can be expensive and time consuming. Here is how crowdtesting can help.
