TEST PROCESS

The test process is the backbone of testing. It is not there to turn testers into form-filling machines. It lets the team know what testing is based on, how far coverage has reached, which risks remain and when the plan needs to change.

The test process sits inside the SDLC, but its activities do not stand in a one-way queue. Analysis can reveal a missing requirement and send planning back for a change; execution can find a new risk and send the team back to design more cases. Monitoring and control run throughout rather than waiting for their turn.

The concept

The test process is a set of activities for test planning, monitoring, analysis, design, implementation, execution and completion. Depending on the project, one person may do several activities or the team may share them.

The concrete activities are:

The names sound like seven railway stations, but in reality they overlap and repeat. The test process is not private tester business either: developers, BAs, Product Owners and operations people all create input for it or use its output.

Typical question: What is the test process?

Typical question: What are the steps in the test process?

The test process in a sprint

If you have forgotten what an Agile Scrum sprint looks like, go back to Agile and Waterfall. I will recap a little and fold the test process into it.

Planning phase

Sprint Planning decides the amount of work and the time available—the sprint plan. The test plan is created alongside the Project Plan, or at least within the planning phase.

The Test Plan takes input from the Project Plan, Requirements and Acceptance Criteria. Its structure is covered in Test Plan.

Daily Scrum

After planning, work begins. Daily Scrums take place while Test Monitoring and Control continues through to Test Execution.

Test Monitoring and Control

This is a real activity, but its life cycle does not follow the same sequence as the others. It is a continuing activity from after Test Planning until the test process ends.

Inputs:

• Test Plan.
• Review and test results.
• Exit Criteria created in the Test Plan.

Outputs:

• Monitoring reports and, possibly, corrective action for deviations from the original test process.

Test Analysis

This is where testers officially begin studying requirements and asking questions to clarify them, as described in Clarifying a requirement.

Test Analysis can start very early, as soon as there is enough test basis to read. Test Monitoring and Control runs alongside it to watch progress and adjust. It is not a gate that gives a tester permission to finish clarifying requirements.

Inputs:

• SRS — Software Requirements Specification: a document usually written by the BA. It is often called a requirements specification. “Software” is not always a precise prefix because the product may not be software.
• Detailed Design: the product design document, at high and low levels. Developers will know this family of document better.
• Prototype (or mock-up or sketch): BAs will be familiar with the usual Figma mock-up. More precisely, this can mean:
  1. Prototype: an interactive version without real product functionality. For example, a spending-statistics prototype needs hard-coded screens, not a database, data retrieval or real calculations.
  2. Mock-up: a drawing made with dedicated software such as Figma. A skilled designer may add animation and review it with the customer. It has no functionality; it is simply an animated drawing.
  3. Sketch: a hand drawing, possibly made in simple software with much less effort than Figma, mainly to show the customer that the frontend direction matches their vision.

Output:

Test Condition: simply, a list of things in the product that can be tested. On a login screen these include the username field, password field, CAPTCHA and Login button. Test conditions cover three aspects of each item: UI (display), State (state) and Function (function).

Test Design

This is the stage where testers design tests. Specifically, we design test cases, group them into test suites and may group test cases into test scenarios from the actor's point of view.

Here, design means creating a broad test case without the exact execution details: a general action and its result. This is a High Level Test Case, for example:

User successfully logs in using the correct username and password combination

The article High-Level Test Cases and RTM explains the writing style. During high-level test-case design, apply test design techniques; see Test Design Techniques.

Inputs:

• SRS — Software Requirements Specification.
• Detailed Design.
• Prototype, mock-up or sketch.
• Test Conditions.

Output:

• High Level Test Cases.

Test Implementation

This step creates low-level test cases by taking the high-level case and adding concrete details: how to execute it, where to execute it, with what, and so on.

A low-level test case follows a template so people on the test team can read and understand one another's cases. For writing one, see Writing Your First Test Case.

Inputs:

• SRS — Software Requirements Specification.
• Detailed Design.
• Prototype, mock-up or sketch.
• High Level Test Case.

Output:

• Low Level Test Cases.

Test Execution

This is simply the step where test cases are executed. Log bugs and send them to development, work with developers to retest them and make sure they are fixed. Test Execution continues until all test cases have run or testing time runs out—if that is what the plan says.

To make sure test cases are correct before execution, they must go through review.

Inputs:

• Low Level Test Cases.
• The completed system or product under test.
• Test Execution Tool.

Outputs:

• Bug Log.
• Test Report.

Test Completion

At the final stage, testers usually prepare reports for the lead:

• Test Summary Report: a summary of the test process, including test cases executed, passed, failed and not executed. It is often a milestone report at the end of Integration, System or Acceptance Testing.
• Task report: usually daily or weekly, not both. It tells the test team what each person has done, is doing and will do, and lets the lead track progress.

Test Completion cares about the Test Summary Report. Task reports happen during testing and resemble a Daily Scrum, but are internal to the test team.

Input:

• Reports.

Outputs:

• Completion report.
• Software baseline — the final version of the software product.

Review phase

The Review phase is basically the Demo. The tester's work is mostly done; leads and BAs work with the customer to demonstrate the product. If the customer is unhappy with its current state, the work moves to the next sprint.

In short, a tester's participation in a sprint looks like this:

• During planning, leads help plan and the Test Lead creates the Test Plan. At the same time, testers read and understand requirements and ask the BA and customer questions.
• Once there is a Test Plan, testers work within the development process, log tasks and report what needs doing, then start writing test cases.
• Writing test cases takes time and may hit problems, so report them in Daily Scrums. When the cases are ready, they go through review and, if all is well, into Test Execution.
• Test Execution can also hit problems, which belong in Daily Scrums. Testers log bugs, send them to developers and work together to improve product quality.
• At the deadline or once Exit Criteria are met, move to Test Completion, create the reports and send them to the lead.
• Finally comes Review. If there are no problems, move to the next sprint; otherwise carry the unfinished work forward and keep track of it for the next sprint.
• Retrospective is the last step. It helps the test team understand what went well, what did not and how to improve. It can also be skipped or reduced to an email exchange.

Typical question: What are the outputs of each step in the test process?

Typical question: How does a tester participate in a sprint?

References

• ISTQB Certified Tester Foundation Level Syllabus v4.0.1