Manual Software Testing Training Part-9

Overview

The video covers four areas of manual software testing: the defect life cycle, deciding when to stop testing, testing metrics, and the tester’s responsibilities and core testing principles.

1. Defect (Bug) Life Cycle

A defect moves through statuses as it is reported, investigated, fixed, and verified. The exact workflow can vary by organization and defect-tracking tool.

A typical flow is:

1. New: A tester reports a defect and records its details.
2. Open/assigned: The defect is reviewed and assigned for investigation or fixing.
3. Rejected or returned: Developers may reject a report if it is invalid, cannot be reproduced, is a duplicate, or needs more information. The reason should be clarified rather than leaving the status unexplained.
4. Fixed: The developer changes the software and marks the defect as fixed.
5. Retested: The tester verifies the fix in an updated build.
6. Closed: If the issue is resolved, the tester closes it.
7. Reopened: If the problem still occurs, the tester reopens it and the process continues.

Other possible statuses include duplicate, deferred, and not reproducible. Testers should understand the status and reason for each defect. A defect marked “fixed” still needs to be verified.

2. Test Closure and Deciding When to Stop

Test closure is the final phase of the software testing life cycle. The broader testing sequence presented in the video is:

• Requirements analysis
• Test planning
• Test design and test-case preparation
• Test-environment setup
• Test execution
• Defect reporting and tracking
• Test closure

Testing should not stop simply because the team hopes the application has no bugs. Exhaustive testing is generally impossible. Instead, the team reviews the agreed exit criteria and remaining risks.

Before closure, the team should review testing status with relevant stakeholders, including testing and development representatives. Considerations include whether planned testing is complete, what has passed or failed, whether important defects have been fixed, and whether any remaining minor defects affect the customer or business.

A key deliverable is a test closure report. It consolidates relevant testing information—such as the test plan, scenarios or cases, execution results, and defect reports—for management or the customer.

3. Software Testing Metrics

Metrics help management understand testing progress and results. The instructor recommends collecting the underlying data first, then calculating and reporting metrics, commonly as percentages.

Examples of data to collect include:

• Total requirements and test cases
• Test cases executed, passed, failed, or blocked
• Defects by severity
• Defects reported by customers
• Defects found at different testing stages

Metrics discussed include:

• Test execution percentage: Test cases executed ÷ total test cases × 100
• Pass percentage: Test cases passed ÷ test cases executed × 100
• Fail percentage: Test cases failed ÷ test cases executed × 100
• Blocked percentage: Blocked test cases compared with the relevant test-case total
• Defect density: Defects identified ÷ requirements
• Defect removal effectiveness: A comparison of defects found before release with defects found later, including by customers
• Defect leakage: Defects that escaped earlier testing and were found in later testing or by customers
• Defect rejection ratio: Invalid defect reports compared with all reported defects
• Customer complaints: Complaint counts tracked over a period as an indicator of customer experience

The subtitle transcription is unclear in places, so some metric definitions—especially the exact denominators—are not fully recoverable. Teams should use consistent definitions when reporting them.

4. Tester Responsibilities

The tester’s work extends beyond executing test cases. Responsibilities across the project include:

• Understanding the requirements and functional specifications
• Identifying what needs testing and developing test scenarios and test cases
• Spending adequate time on test planning and design, since misunderstandings at this stage can lead to missed defects
• Checking that the test environment is ready before execution
• Executing tests and recording results
• Reporting defects clearly, tracking their statuses, and verifying fixes through retesting
• Sharing regular progress updates, including completed work, outstanding work, and delays
• Participating in team meetings and communicating testing status
• Providing testing results and relevant information to management to support release decisions

5. Seven Principles of Software Testing

1. Testing shows the presence of defects, not their absence. Testing can reveal problems, but cannot prove that software is completely defect-free.
2. Exhaustive testing is impossible. It is impractical to test every input, condition, and combination, so testing must be prioritized.
3. Test early. Testing should begin as early as practical, including during requirements work, to catch misunderstandings and defects sooner.
4. Defects cluster together. A relatively small number of modules may contain a large share of the defects, so areas with a history of problems may need extra attention.
5. Beware the pesticide paradox. Repeating the same tests indefinitely may stop uncovering new defects. Test cases and data should be reviewed and updated as the software changes.
6. Testing is context-dependent. The appropriate test approach depends on the application and its intended use.
7. Absence of errors is a fallacy. Even software with few known defects may fail to meet user needs or business requirements.

Speakers and Sources

• One unnamed instructor/narrator presents the training.
• Developers, testers, managers, and customers are discussed as project roles or stakeholders; no separate named speakers are identifiable in the subtitles.