Deliverables Of Software Testing Team

Test deliverables are documents shared with stakeholders during software development. This section covers:

Open Full-Size Diagram ↗

Deliverables Of Software Testing Team

• Software Testing Strategy
• Software Testing Plan
• Software Test Scenarios and Test Cases
• Software Test Metrics
• Product Metrics
• Process Metrics
• Software Test Documentation
• Software Testing Reports
• Daily Test Status Reports
• Incident Reports
• Final (Test Project Closure) Test Status Report

Software Testing Strategy

A test strategy is a roadmap for a project’s testing activities. Break the work into smaller, clearly defined processes. The strategy helps the team estimate the time, effort and resources needed, and supports planning, management and progress tracking.

Software Testing Plan

A test plan defines the overall testing strategy, environment and testing levels. It explains how results will be analyzed and which metrics will be used. It also records exit criteria for each phase and estimates of testing effort and cost.

Open Full-Size Diagram ↗

Software Testing Plan

Software Test Scenarios and Test Cases

A test scenario describes a hypothetical situation for evaluating the software in a structured way. It can be complex, like a story. A test case gives direct instructions about what to do, which input to provide and which output to expect. Test cases are generally one-line statements, while a scenario gives the tester a broader situation to explore.

Open Full-Size Diagram ↗

Software Test Scenarios and Test Cases

Cem Kaner described scenario testing in 2003 as a way to explore realistic situations. Detailed test cases still record steps, input data and expected results, and maintaining that detail can take more effort.

Test cases tell the tester directly what to do and how to test the software.

Open Full-Size Diagram ↗

Software Test Scenarios and Test Cases

Software Test Metrics

A software metric is a unit of measurement used to evaluate an attribute of software. Test metrics assess quality and indicate how ready a system is during development. Why measure? We can improve only what we can measure, because measurable things are controllable. Decisions in each development phase are made after reviewing metrics from the previous phase. Test metrics fall into two groups:

1. Direct measures, or base metrics: Raw data gathered by a test analyst to show project status, such as the number of test cases created or executed.
2. Indirect measures, or calculated metrics: Base data converted into more useful project information, such as the percentage completed or the percentage of test coverage.

Product Metrics

Product metrics guide quality improvement. Regular evaluation helps the team identify needed corrections to product characteristics in time. These metrics measure:

• Size
• Complexity
• Design aspects
• Performance
• Quality

Process Metrics

Process metrics identify opportunities to improve how work is done, saving time and effort. Compare results with the process’s intended target to assess progress. Tracking testing activities can improve a project’s efficiency and effectiveness. In software development, process metrics cover:

• Software Development
• Software Maintenance
• Software Testing

Software Test Documentation

Test documentation records testing activities before or during testing. Important documents include:

• Test Plan
• Test Scenario
• Test Case
• Traceability Matrix

Software Testing Reports

The following reports support your testing work:

• Daily Test Status Reports
• Incident Reports
• Final (Test Project Closure) Test Status Report

Daily Test Status Reports

Daily status reports keep the test team, project stakeholders and program stakeholders informed. The project manager can see daily defect counts, executed cases and each tester’s work. Include:

1. How many test cases were planned for the day?
2. How many were executed?
3. How many defects did the team report?
4. How many defects were critical?
5. Where can detailed reports, including the Defect and Test Execution Sheet, be found?

Incident Reports

Incident reports coordinate testing and development. Incident management records:

• A comparison of actual and expected results
• The reason for a failed test’s deviation: faulty automation, a poor test case or an actual software failure

Prepare an incident report for an actual failure. Include these details:

• Identification
• What is the ID for each report?
• What is the test object?
• Version of Software Application under Test
• Test environment details, including hardware and software
• Name of the developer who needs to assess and resolve the incident
• When was the failure observed?
• Classification
• Status
• Severity
• Priority
• Requirement
• Cause
• Problem Description
• Description of the problem
• Details of the test case
• Tester's comments
• Developer's comment after change
• Any references

Final (Test Project Closure) Test Status Report

The test lead prepares a project closure report when exit criteria are met or testing is complete. Stakeholders and clients then review it. Include the successfully executed test cases and any outstanding defects scheduled for resolution after deployment.