Latent Defect

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 6
At a glance
Powered by AI
The key takeaways are latent defects, masked defects, test coverage techniques, and components of a defect report format.

A requirement traceability matrix is a document that records the mapping between high-level requirements and test cases in the form of a table to ensure all requirements are covered.

The different phases of the software testing life cycle are requirement analysis, test planning, test case development, environment setup, test execution, and test cycle closure.

 Latent defect: A latent defect is an existing defect that has not caused a

failure because the sets of conditions were never met


 Masked defect: It is an existing defect that has not caused a failure
because another defect has prevented that part of the code from being
executed

57. Mention what are the different types of test coverage techniques?

Different types of test coverage techniques include

 Statement Coverage: It verifies that each line of source code has been
executed and tested
 Decision Coverage: It ensures that every decision in the source code is
executed and tested
 Path Coverage: It ensures that every possible route through a given part
of code is executed and tested

The basic components of defect report format includes

 Project Name
 Module Name
 Defect detected on
 Defect detected by
 Defect ID and Name
 Snapshot of the defect
 Priority and Severity status
 Defect resolved by
 Defect resolved on

A test harness is configuring a set of tools and test data to test an application in
various conditions, it involves monitoring the output with expected output for
correctness.
Q-1. What Is Requirement Traceability Matrix?
Answer.
Requirement Traceability Matrix (RTM) is a document which records the mapping
between the high-level requirements and the test cases in the form of a table.

That’s how it ensures that the Test Plan covers all the requirements and links to their
latest version.

Risk analysis is the process of identifying the hidden issues that may derail the
successful delivery of the application. It also prioritizes the sequence of resolving the
identified risks for testing purpose.

Following are some of the risks that are of concern to the QA.

1. New Hardware.
2. New Technology.
3. New Automation Tool.
4. The sequence of code delivery.
5. Availability of test resources for the application.

1. Master Test Plan contains all the test scenarios and risks prone areas of the
application. Whereas, Test Plan document contains test cases corresponding
to test scenarios.
2. Master Test Plan captures each and every test to be run during the overall
development of application whereas test plan describes the scope, approach,
resources and schedule of performing the test.
3. MTP includes test scenarios to be executed in all the phases of testing that
run during the complete life cycle of the application development. Whereas, a
separate Test Plan exists for each phase of testing like Unit, Functional, and
System which contains the test cases related to that type only.
4. Only for big projects, we need a Master Test Plan which requires execution
in all phases of testing. However, preparing a basic Test Plan is enough for
small projects.
 Unit testing
 Integration testing
 Regression testing
 Shakeout testing
 Smoke testing
 Functional testing
 Performance testing
1. Load testing
2. stress testing
3. Endurance testing
 White box and Black box testing
 Alpha and Beta testing
 System testing

Entry criteria – It is a process that should run when a system begins. It includes the
following artifacts.
 SRS (Software Requirement Specification)
 FRS (Functional Requirement Specification)
 Use case
 Test-Case
 Test-plan
Exit Criteria – It signals when the testing should complete and when should the
product be ready to release. It includes the following artifacts.
 Test Summary Report
 Metrics
 Defect Analysis report

 Cohesion is the degree which measures the dependency of the software


component that combines related functionality into a single unit whereas
coupling represents the binding of related functionality into a different unit.
 Cohesion deals with the functionality that relates to different process within a
single module whereas coupling deals with how much one module is
dependent on the other modules within the product.
 It is a good practice to increase the cohesion between the software whereas
coupling is discouraged.
Why Does Software Have Bugs?

 Miscommunication.
 Programming errors.
 Timeline pressures.
 Change in requirements.
 Software complexity.

Stubs

1. Used in Top down approach


2. Top most module is tested first
3. Stimulates the lower level of components
4. Dummy program of lower level components
Driver

1. Used in Bottom up approach


2. Lowest modules are tested first.
3. Stimulates the higher level of components
4. Dummy program for Higher level component

Stubs are used in top down testing approach, when you have the major module
ready to test, but the sub modules are still not ready yet. So in a simple language
stubs are "called" programs, which are called in to test the major module's
functionality.

For eg. suppose you have three different modules : Login, Home, User. Suppose
login module is ready for test, but the two minor modules Home and User, which are
called by Login module are not ready yet for testing.
At this time, we write a piece of dummy code, which simulates the called methods of
Home and User. These dummy pieces of code are the stubs.

On the other hand, Drivers are the ones, which are the "calling" programs. Drivers
are used in bottom up testing approach. Drivers are dummy code, which is used
when the sub modules are ready but the main module is still not ready.

Taking the same example as above.Suppose this time, the User and Homemodules
are ready, but the Login module is not ready to test. Now since Home and User
return values from Login module, so we write a dummy piece of code. This code is
known as driver.

STLC:

 Requirement Analysis
 Test Planning
 Test Case Development
 Environment Setup
 Test Execution
 Test Cycle Closure

Req. Analysis:
In this step Quality Assurance (QA) team understands the requirement in terms of what
we will testing & figure out the testable requirements. If any conflict, missing or not
understood any requirement, then QA team follow up with the various stakeholders like
Business Analyst, System Architecture, Client, Technical Manager/Lead etc to better
understand the detail knowledge of requirement.

 Test Planning

Test Planning is most important phase of Software testing life cycle where all testing
strategy is defined. This phase also called as Test Strategy phase. In this phase
typically Test Manager (or Test Lead based on company to company) involved to
determine the effort and cost estimates for entire project. This phase will be kicked off
once the requirement gathering phase is completed & based on the requirement
analysis, start preparing the Test Plan.

 Test Case Development

The test case development activity is started once the test planning activity is finished.
This is the phase of STLC where testing team write down the detailed test cases. Along
with test cases testing team also prepare the test data if any required for testing. Once
the test cases are ready then these test cases are reviewed by peer members or QA
lead.

 Environment Setup

Setting up the test environment is vital part of the STLC. Basically test environment
decides on which conditions software is tested. This is independent activity and can be
started parallel with Test Case Development. In process of setting up testing
environment test team is not involved in it. Based on company to company may be
developer or customer creates the testing environment. Mean while testing team should
prepare the smoke test cases to check the readiness of the test environment setup.


 Test Execution

Once the preparation of Test Case Development and Test Environment setup is
completed then test execution phase can be kicked off. In this phase testing team start
executing test cases based on prepared test planning & prepared test cases in the prior
step.

 Test Cycle Closure

Call out the testing team member meeting & evaluate cycle completion criteria based on
Test coverage, Quality, Cost, Time, Critical Business Objectives, and Software. Discuss
what all went good, which area needs to be improve & taking the lessons from current
STLC as input to upcoming test cycles, which will help to improve bottleneck in the STLC
process. Test case & bug report will analyze to find out the defect distribution by type
and severity. Once complete the test cycle then test closure report & Test metrics will be
prepared. Test result analysis to find out the defect distribution by type and severity.

You might also like