Latent Defect 4t3n3c

 

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. 2. 3. 4.

Used in Bottom up approach Lowest modules are tested first. Stimulates the higher level of components 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 : , Home, . Suppose module is ready for test, but the two minor modules Home and , which are called by 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 . 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 and Homemodules are ready, but the module is not ready to test. Now since Home and

return values from 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 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 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 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.