Defect/Bug Life Cycle

Defect Life Cycle:
  • Defect life cycle, also known as Bug Life cycle is the journey of a defect cycle, which a defect goes through during its lifetime.
  • It varies from organization to organization and also from project to project as it is governed by the software testing process and also depends upon the tools used.
  • Defect Life Cycle is a cyclic process, which describes how a defect or bug passes through different stages from the identification stage to the Fixing stage. it begins when a tester finds or logs a bug and it ends when the bug is fixed.
  • If Developer reject a defect understand the reason why defect is rejected , if developer is correct we can close the defect or else we can discuss it with test lead or project lead and than reopen the defect.

Some of the familiar values used for defects, during their life cycle are :
  • New : New defect is reported.
  • Open : The developer is currently working on the defect.
  • Fixed : The code changes are completed and the defect is resolved .
  • Deferred : Developers will fixed the defect later.
  • Duplicate : The defect is same like one of the previous defect. When previous is fixed it also fixed.
  • Retest : the tester starts the task of retesting the defect to verify if the defect is fixed or not.
  • Rejected : Developers did not accept the defect .
  • Close : After re test if defect is working correctly .
  • Reopen : After re test if defect is still exist then we reopen the defect.
  • Not a Bug : If the defect does not have an impact on the functionality of the application, then the status of the defect gets changed to “Not a Bug”.
  • There are others of course, and some groups might use combinations of these values (such as Closed-Fixed, Closed-WontFix, etc.).

Defect Report | Priority and Severity

Defect Report: 

  • If application is not working as expected we can report that as defect in defect report. 
  • A defect report is a document that has concise details about what defects are identified, what action steps make the defects show up, and what are the expected results instead of the application showing error (defect) while taking particular step by step actions.
  • Defect Reporting, Defect Tracking, and Status Tracking is called Defect Management. Some companies use Manual Process (Excel workbook), and some companies use Tool-based processes for Defect Management. 
  • Defect Management Tools Examples: Bugzilla / Issue-Tracker / PR-Tracker etc.

Important fields of a Defect Report template:

  • Defect Id :  It is a unique number for every defect we found while testing.
  • Summary :  Full description of the defect .
  • Detected By : Name of the tester who found the defect .
  • Assigned to :  Currently the defect is assign to whom. When a tester found a defect the it has to assign to any developer.
  • Severity : Severity defines how impactful a bug can be to the system. It can values either high or medium or low specifies the seriousness of the defect.
  • Priority : Priority indicates how soon the bug should be fixed. It can values either high or medium or low specifies the importance of the defect or functionality. The defect are fixed based on priorities .
  • Status :  Defect Status in defect life cycle is the present state from which the defect or a bug is currently undergoing. The goal of defect status is to precisely convey the current state or progress of a defect in order to better track and understand the actual progress of the defect lifecycle. 
  • Build version : It show currently build version in which we are testing. We  can check this from release note document. 
  • Module : In which module the defect is found.
  • Environment :  The defect is found in which environment like : Test environment, UAT or Production environment.
  • Defect Type :  Specify the type of defect like functional , network , data , performance or UI ( User Interface) etc.
  • Reproduceable : It has value either YES or NO:
                YES: Every time the defect is occurring .
                NO: Most of the time its working correctly, only few cases it is failing and not able to reproduce  
  • ( If the defect is non reproduceable we can take screen shot of the defect and report it along with the defect.)
  • Reproduce Steps : Specify the navigation steps to reproduce the defect.

Test Execution Process | Environment setup

Test Execution:

  • Test execution is the process of executing the test cases and comparing the expected and actual results.
  • After developers finish the coding and give the build to the tester , tester will conduct the testing and validate the application as per the requirement.
  • The developers will prepare the below document and give to the testing team during the build release :
SRN (software release note)
DD (Deployment Document)
  • Tester deploy the build in test environment a per the instruction in the release document note .
  • The build is deployed in the test environment either by tester or developer or n/w team. 

  • As we know after build release 1st test should be performed is sanity test .
  • After Sanity test is pass we will continue test execution and validate all the functionality.
  • Test execution can be done either manual aur automation.
  • Testing performed by tester without using any tools is called manual testing.
  • Testing conducted with the help of tool is called automation testing.
  • During execution validate all the test cases and specify actual result and status.
  • If the status is fail we can report that as defect to the developers.

SRN (software release note)

  • A release note refers to the technical documentation produced and distributed alongside the launch of a new software product or a product update.
  • It briefly describes a new product or specific detail level changes included in a product update.
  • A software release notes template is a simple document that companies use to document any changes to their product. Elements of release notes template are like : 
  • Build version , build location , requirement in build , Precondition , environment , deployment steps , known issue , defect files , prepare by               

Requirement Traceability Matrix

Traceability Matrix:

  • In this document the test cases are mapped to the corresponding requirement to ensure the coverage of test cases, to find any gap between requirement and test cases.
  • It is also known as Requirement Traceability Matrix (RTM) or Cross Reference Matrix (CRM).
  • It is prepared before the test execution process.
  • This document is designed to make sure that each requirement has a test case. 
  • The test engineer will prepare TM for their respective assign modules, and then it will be sent to the Test Lead. Then test lead consolidate all and prepare one TM document for project.

Goals of Traceability Matrix:

  • It allows you to see if a requirement is fully documented or not. A requirement traceability matrix can even call attention to missing requirements. 
  • It ensures that the software completely meets the customer's requirements.
  • A traceability matrix can help in the effort to provide proper and consistent documentation for your team. 
  • It helps in detecting the root cause of any bug.

Types of Traceability Matrix:

The traceability matrix can be classified into three different types which are as follows:  

  • Forward Traceability
  • Backward or reverse Traceability
  • Bi-directional Traceability

Forward Traceability:

Forward traceability is used to map the requirements to the test cases.

  • Not only this will establish that every requirement is being tested from top to bottom, but it will also assist in confirming that a project’s trajectory is sound. 
  • The main objective of this is to verify whether the product developments are going in the right direction.

Backward or reverse Traceability:

You can make a backward traceability matrix by mapping test cases with the requirements. 

  • The reverse or backward traceability is used to check that we are not increasing the space of the product by enhancing the design elements, code, test other things which are not mentioned in the business needs. 
  • The main objective of this that the existing project remains in the correct direction.

Bi-directional Traceability:

Bidirectional traceability essentially combines forward and backward traceability into one document. 

  • This type is useful because it establishes that each requirement has relating test cases. 
  • It also evaluates the modification in the requirement which is occurring due to the bugs in the application.


Test Case Review Process and Guidelines

 Test Case Review : 

  • Test case review process is an important process to follow in software testing. Test case should be effective and also follow the standards to write test case.
  • After preparation of the test cases review are conduct to ensure the completeness and correctness of the test case, proper flow, and maximum test coverage.
  • The test lead or project manager have to approve the test cases.
  • During this review process, if the reviewer found any mistake, he/she writes it in a separate document, which is known as Review document and sends it back to the author.

Test Case Review Techniques : 

  • Self-review: This is carried out by the tester who wrote the test cases. By looking at SRS/FRD, he/she can see if all of the requirements are met or not.
  • Peer review:  Before test lead the test cases reviewed by another team member who is not familiar with the system is called peer review. Maker and Checker are two other names for the same thing.
  • Supervisory review: This is done by a team lead or project manager who is higher in rank than the tester who wrote the test cases and has an extensive understanding of the requirements and system.

Common mistakes which are check during Test Case Review  : 

  • Incomplete Test Cases. Missing negative test cases. No Test Data. Inappropriate/Incorrect Test data.
  • Spelling errors can sometimes cause a lot of confusion or make a statement difficult to grasp.
  • While review process, it is very important to check whether all the standards and guideline are properly followed.
  • If proper template is followed then it becomes easy to add/modify test cases in future and test case plan looks organized.
  • If the grammar is incorrect, the test case can be misinterpreted, leading to incorrect findings. 
  • Test cases should have a very simple language which is easy to understand.
  • Replication: It refers to the duplicate test cases removal. It is possible that two or more test cases test the same thing and can be merged into one, this would save time and space.
  • Test case which are uselessness due to change in requirements or some modifications. Such test cases must be removed.

Test Case Repository  : 

  • A test case repository is a centralized location where all the baseline test cases (written, review, and approved) are stored.
  • Test repository comprises test cases that encompass all key possibilities of permutations and combinations in workflow execution and transaction, ensuring that all variations in system and user interactions are covered.
  • A test case repository is used to store the approved test cases only.
  • Any test engineer wants to test the application, then he/she needs to access the test case only from the test case repository.
  • If we do not require any test case, we can drop them from the test case repository.
  • Each version have a separate test case repository.

Test Design Testing Techniques

 Test Design Testing Techniques :

  •  BAV (Boundary Value Analysis )
  •  ECP (Equivalence Class Partition)
  •  Decision Table Based Testing
  •  State Transition
  •  Error Guessing Testing

1. BAV (Boundary Value Analysis):

  •  The technique specify  to validate the boundary validation.
  •  It is based on testing at the boundaries.
  •  We will be testing both the valid and invalid input values in the BVA.

 Conditions are like :

              Min                       Max 

            Min-1                     Max-1

            Min+1                    Max+1

The above 6 conditions are enough.

BAV (Boundary Value Analysis ) Example:

Password field accept 6-32 character then we only test for :-

       Min : 6                Max  : 32

      Min-1 : 5             Max-1 : 31

      Min+1 : 7            Max+1 : 33

These 6 conditions are enough for password field testing.

2. ECP (Equivalence Class Partition):

  • The technique specify to test for valid and invalid combination.
  •  The idea behind this technique is to divide a set of test conditions into groups or sets that can be considered the same.
  •  It  is a black-box testing technique or specification-based testing technique in which we group the input data into logical partitions called equivalence classes.

ECP Example:

Any mail id field accepts alpha and numeric data :

        Valid Data                                      Invalid Data

           A – Z                                           All special character 

           a – z 

           0 – 9 

If a Text field accept 1000 -1500 the partition should be:

         Valid Data                                      Invalid Data 

         1000 – 1500                                   a – z 

                                                                   A – Z

                                                                  Numbers < 1000

                                                                  Numbers > 1500

                                  All special character

3. Decision Table Based Testing:

  • Decision table testing is a software testing technique used to test system behavior for different input combinations.
  • In this methodology the various input combinations and the accompanying system behavior (Output) are tabulated.
  • This is a systematic approach. 
  • Decision Table Testing is a Black Box test design technique (behavioral or behavior-based technique).
  • When a system has complex business rules, then the decision table testing technique helps in identifying the correct test cases.

Example:  How to Create a Login Screen Decision Base Table

Let's make a login screen with a decision table. A login screen with User id and Password Input boxes and submit button.

The condition is simple if the user provides correct username and password the user will be redirected to the homepage. If any of the input is wrong, an error message will be displayed.

T –  Make sure to use Correct username/password

F – Incorrect username/password

E – An error message is displayed

H – The home screen is displayed

Interpretation:

 Case 1 – Username and password both were correct, and the user navigated to homepage

 Case 2 – Username was correct, but the password was wrong. The user is shown an error message.

 Case 3 – Username was wrong, but the password was correct. The user is shown an error message.

 Case 4 – Username and password both were wrong. The user is shown an error message.

While converting this to test case, we can create 2 scenarios :

First one :

Enter correct username and correct password and click on Submit button, and the expected result will be the user 

Should be navigated to homepage.

Second one from the below scenario: 

  • Enter Correct username and incorrect password and click on Submit button, and the expected result will be the user should get an error message.
  • Enter incorrect username and incorrect password and click on Submit button, and the expected result will be the user should get an error message.
  • Enter incorrect username and correct password and click on Submit button, and the expected result will be the user should get an error message.

As they essentially test the same rule.

4. State Transition:

  • State transition testing helps to analyze behavior of an application for different input conditions.
  • In this test outputs are triggered by changes to the input conditions or changes to 'state' of the system.
  • In other words, tests are designed to execute valid and invalid state transitions.
  • Testers can provide positive and negative input test values and record the system behavior. It is the model on which the system and the tests are based.
  • It is a black box testing which is used for real time systems with various states and transitions involved.

When to Use State Transition?

  • This can be used when a tester is testing the application for a finite set of input values.
  • When we have sequence of events that occur and associated conditions that apply to those events
  • This will allow the tester to test the application behavior for a sequence of input values. 

When to Not Rely On State Transition?

  • When the testing is not done for sequential input combinations.
  • If the testing is to be done for different functionalities like exploratory testing.

Example:

Let’s consider an Login page function where if the user enters the invalid password three times the account will be locked.

In this system, if the user enters a valid password in any of the first three attempts the user will be logged in successfully. If the user enters the invalid password in the first or second try, the user will be asked to re-enter the password. And finally, if the user enters incorrect password 3rd time, the account will be blocked.

In the table when the user enters the correct PIN, state is transitioned to S5 which is Access granted. And if the user enters a wrong password he is moved to next state. If he does the same 3rd time, he will reach the account blocked state.

5. Error Guessing Testing:

  • Testing is conducted by performing invalid operations and validate the error massage is displaying or not .
  • The Error massage should meaningful to understand.
  • It is a type of testing method in which prior experience in testing is used to uncover the defects in software. It is an experience based test technique in which the tester uses his/her past experience or intuition to gauge the problematic areas of a software application.

Example:

  • We need to test a program which read’s a file. What happen if the program gets a file which is empty OR  The file does not exist??? 
  • Enter blank space into text fields
  • Use max limits of files to be uploaded

Please watch below video for more details:

All you need to know about test cases

 Test Case Design 

  • Test case design refers to how you set-up your test cases. It is important that your tests are designed well, or you could fail to identify bugs and defects in your software during testing.
  • It is responsibility of a tester to design the test cases.
  • To design the test cases tester should :
  • Understand the requirement 
  • Identify the scenario
  • Design the test case 
  • Review the test case 
  • Update the test case based on review 

How to create good test cases 

  • Test Cases need to be simple steps, transparent and easy to understand.
  • Each and every test case should be traceable and it should be linked to “Requirement ID”.
  • Test cases should have only necessary and valid steps(Brief And Short) .
  • Implement Testing Techniques – Positive And Negative Test Cases
  • Test cases should be written in such a way that it should be easy to maintain.
  • Test cases should cover the usability aspects in terms of ease of use.
  • Different set of test cases should be prepared for the basic performance testing like multi-user operations and capacity testing.
  • Test cases for Security aspects should be cover for example user permission, session management, logging methods.

Test cases Design Format:

Follow below steps to create Test cases 

Test Case Id : It is a unique number to represent each test cases. It’s good practice to follow some naming convention for better understanding and discrimination purposes. Like   Tc_proj_module_number(001)

For example: Tc_Yahoo_Inbox_001

Test Scenario :  A Test Scenario is defined as any functionality that can be tested. It is a collective set of test cases which helps the testing team to determine the positive and negative characteristics of the project. Test Scenarios are derived from test documents such as BRS and SRS.

Test Cases : A Test Case is a set of actions executed to verify a particular feature or functionality of your application. Test Cases are focused on what to test and how to test. Test Case is mostly derived from test scenarios.

Precondition :  The condition to be satisfied to test the requirement. Conditions that need to meet before executing the test case.

Priority :  The importance of the test case is called priority. It is a parameter to decide the order in which defects should be fixed. Priority means how fast defect has to be fixed.

Test Steps :   Test Steps describe the execution steps. To execute test cases, you need to perform some actions. Each step is marked pass or fail based on the comparison result between the expected and actual outcome.

Test Data:  It is data created or selected to satisfy the execution preconditions and inputs to execute one or more test cases. We need proper test data to execute the test steps.

Expected result :  The output result as per customer requirement (As per SRS or FRS). The result which we expect once the test cases were executed. 

Post Condition :  Conditions that need to achieve when the test case was successfully executed.

Actual Result :  The output result in the application once the test case was executed. Capture the result after the execution. Based on this result and the expected result, we set the status of the test case.

Status :  The status as Pass or Fail based on the expected result against the actual result. If the actual and expected results are the same, mention it as Passed. Else make it as Failed. If a test fails, it has to go through the bug life cycle to be fixed.

Other important fields of a test case template:

Project Name: Name of the project the test cases belong to.

Module Name: Name of the module the test cases belong to.

Reference Document: Mention the path of the reference documents (if any such as Requirement Document, Test Plan , Test Scenarios, etc.,)

Author (Created By) : Name of the Tester who created the test cases.

Date of Creation: When the test cases were created.

Date of Review: When the test cases were reviewed.

Reviewed By: Name of the Tester who created the test cases.

Executed By: Name of the Tester who executed the test case.

Date of Execution: When the test case was executed.

Comments: Include value information which helps the team.

Please refer below video on test cases:

Please refer below video on real time test case template:

Test Strategy Vs Test Plan

Test Strategy:

  • A test strategy is an outline that describes the testing approach of the software development cycle. 
  • Test strategy is a set of guidelines that explains test design and determines how testing needs to be done.
  • The creation and documentation of a test strategy should be done in a systematic way to ensure that all objectives are fully covered and understood by all.
  • It should also frequently be reviewed, challenged and updated as the organization and the product evolve over time.

Test Strategy Vs Test Plan:

Test Plan

Test Strategy

A test plan for software project can be defined as a document that defines the scope, objective, approach and emphasis on a software testing effort.

Test strategy is a set of guidelines that explains test design and determines how testing needs to be done.

 

Test plan include- Introduction, features to be tested, test techniques, testing tasks, features pass or fail criteria, test deliverables, responsibilities, and schedule, etc.

Test strategy includes- objectives and scope, documentation formats, test processes, team reporting structure, client communication strategy, etc.

Test plan is carried out by a testing manager or lead that describes how to test, when to test, who will test and what to test

A test strategy is carried out by the project manager. It says what type of technique to follow and which module to test

Test plan narrates about the specification.

Test strategy narrates about the general approaches.

It is done to identify possible inconsistencies in the final product and mitigate them through the testing process.

It is a plan of action of the testing process on a long-term basis.

 

It is used on a project level only.

It is used on an organizational level.

Test plan can change.

It is used by multiple projects and can be repeated a lot of times.

It is used by one project only and is very rarely repeated.

Test strategy cannot be changed.

 

Test planning is done to determine possible issues and dependencies in order to identify the risks.

It is a long-term plan of action. You can abstract information that is not project specific and put it into test approach


Please refer below video more details:

What is Test Planning and How to Create Test Plan?

Test Planning:

  • Initially when we get the project it is responsibility for a test lead or senior tester to prepare the test plan for the project.
  • A test plan is the foundation of every testing effort.
  • A Test Plan refers to a detailed document that catalogs the test strategy, objectives, schedule, estimations, deadlines, and the resources required for completing that particular project. 
  • A good test plan clearly defines the testing scope and its boundaries. You can use requirements specifications document to identify what is included in the scope and what is excluded.
  • By creating a clear test plan all team members can follow, everyone can work together effectively.

The steps to prepare the test plan :-

  •      Criteria
  •      Prepare test plan 
  •      Get approval

1.  Criteria:-

  • To prepare test plan the test lead /senior tester should have the below details:
  • Development schedule 
  • Project release date
  • Services to be provided to customer 
  • Understand the project requirement
  • Understanding of the complexity of the project
  • Scop of testing
  • No. of resources required
  • Type of testing to be conducted 

2. Prepare Test Plan :

  • A Test Plan is a detailed document that describes the test strategy, objectives, schedule, estimation, deliverables, and resources required to perform testing for a software product.
  • The test plan serves as a blueprint to conduct software testing activities as a defined process, which is minutely monitored and controlled by the test manager.

Test Plan document has the below details :

  • Introduction
  • Features to be tested ( In scope)
  • Features not to be tested (Out of scope)
  • Pass/ Fail criteria
  • Entry and Exit criteria
  • Approach
  • Schedule 
  • Test factor
  • Recourses
  • Training plans
  • Configuration management
  • Test Deliverable
  • Test Environment
  • Risk and Mitigation Plan
  • Approval 
3. Prepare Test Plan : Once test plan is ready it should be approved from test manager

Lets talk about different sections on a test plan in detail:

Introduction :-  Specify the purpose / Requirement of the project.

Feature to be tested :- Specify the requirement which is need to be tested.

Feature not to be Tested :- Specify the requirement which is out of the scope of testing. We dose not need to test.

PASS / FAIL Criteria (Suspension Criteria):-  If the below criteria is satisfied we can suspend the build from testing:

  • The build is not deployed 
  • The sanity test is fail
  • The build is unstable 
  • Wrong build is given 

(Note: If the build is suspended the developer have to immediately resolve the issue and give the modified build)

Entry and Exit Criteria:-  Specify the condition to start and stop the testing . for every level of testing there is entry and exit criteria 

    For example :-

System testing Entry Criteria :-

  • Integration testing should be completed 
  • All the major defect found in the integration test should be fixed 
  • The test environment should be ready , Required access should be provided
  • The Development should be completed (All Coding part)

System testing Exit Criteria :-

  • All the functionalities are tested 
  • No new defect are found
  • No risk in the project 
  • All the defects are fixed 
  • The testing scheduled are completed 

Approach :-  Specify the process followed in the project like

 Planning   Design   Execution  Reporting

Schedules:-  Specify the testing . The testing scheduled are prepared based on development schedules. 

Resources :-  Specify the list of team, resources and there responsibilities like testing team, development team, project managers etc. 

Training plans :- Specify any training plan is required for the resources.

Configuration Management :-  Specify hoe to manage all the project related documents , codes, testing documents etc.so these documents are accessible to all the team members.

There are tools are available like : 

VSS  Visual source safe

CVS   Concurrent version system for configuration management.

The tool provide security, version control (Each time the documents are updated a new version is created )

Test Deliverables :-  Specify the list of documents to be submitted to the customer during testing or after testing Documents are like :

  • Test Plan
  • Test Case documents 
  • Test execution result
  • Defect report 
  • Review report
  • Test summary report etc.

Test Environment :-  Specify the Hard ware configuration details, the additional software required in the test environment to access the application and conduct the testing.

Risk And Mitigation Plan:- Specify the challenges in the project and the solution to resolve the challenges.

The different risks are : 

  • Required documents are not available 
  • Estimations are not correct
  • Delay in project deliverables
  • Lack of skilled resources 
  • Lack of team coordination's ETC.

Approval :- After preparation of the plan the project manager and customer have to review and approve the plan.

Note :- During the planning phase it is the responsibility of test lead to recruit the tester based on the skills required for the project .

Please refer the below video for more details on test plan:

What is Software Testing Life Cycle?

The Software Testing Life Cycle (STLC) is a term that refers to the process of testing software. The Software Testing Life Cycle (STLC) is a set of actions that are carried out during the testing process to guarantee that software quality objectives are satisfied.

Any Project has to follow the below phases from beginning of a project to end of the project in Testing :

  • Requirement Analysis
  • Test Planning 
  • Test Case Design 
  • Test Execution
  • Defect Reporting And Tracking
  • Test Closer 

1. Requirement Analysis :- It is tester’s responsibility

  • Study the requirements
  • Identify types of tests to be performed
  • Prepare RTM
  • Automation feasibility analysis

2. Test Planning :- It is test lead’s responsibility

  • Understand the project
  • Scop of testing
  • Identify the resource
  • Schedules
  • Deliverables
  • Approach
  • Effort Estimations

3. Test Case Design :- It is Tester’s Responsibility

  • Design/Script the Test cases 
  • Review testcases
  • Update test cases based on review and baseline test cases
  • Create test data 

4. Test Execution :- It is tester’s responsibility

  • Setup test environment
  • Execute tests as per plan
  • Document test results

5. Defect Reporting and Tracking:- It is Tester’s Responsibility

  • Report defect to developers 
  • Map defects to test cases in RTM
  • Re-test the defect fixes
  • Track the status of defect to closure

6. Test Closer :- It is tester and Test Lead’s responsibility

Stop testing based on :-

  • All functionalities are tested 
  • No new defect are found
  • Schedule are conducted 
  • No risk in the project
  • Test Closure Report

Please watch below video on STLC process:

Monkey and Gorilla Testing

Monkey Testing

  • Monkey testing is a type of software testing in which a software or application is tested using random inputs with the sole purpose of trying and breaking the system. 
  • Monkey testing tests the whole system, There are no rules in this type of testing.
  • Monkey testing is usually implemented as random, automated unit tests.
  • Monkey testing is also known as Random testing, Fuzz Testing or Stochastic Testing.
  • Monkey testing is a crucial testing method that is done to authenticate the functionality of the product application. 
  • Monkey testing is a kind of black box testing.

Gorilla Testing

  • Gorilla testing is a software testing technique that repeatedly applies inputs on a module to ensure it is functioning correctly and that there are no bugs. 
  • Gorilla testing is a manual testing procedure and is performed on selected modules of the software system with selected test cases.
  • Gorilla testing is not random and is concerned with finding faults in a module of the system.
  • Gorilla Testing is also known as Torture Testing, Fault Tolerance Testing or Frustrating Testing.
  • Gorilla Testing is a manual testing and it is repetitively performed.
  • Gorilla testing is a kind of white box testing.

Difference between monkey and gorilla testing:

Monkey

Gorilla

Monkey testing is a type of software testing which is performed based on some random inputs without any test cases and checks the behaviour of the system and confirms whether it crashes or not.

Gorilla Testing is a type of software testing which is performed on a module based on some random inputs repeatedly and checks the module’s functionalities and confirms no bugs in that module.

In Monkey Testing, no test case is used to test the application as it is a part of random testing.

It is performed repeatedly as it is a part of manual testing.

The Monkey Testing approach is primarily used in System Testing.

The Gorilla Testing approach is mainly used in Unit Testing.

Monkey testing is implemented on a whole system.

Gorilla testing is implemented on few selective components of the system.

No software knowledge is required in order to execute the monkey testing.

It requires minimum software knowledge in order to execute the gorilla testing.

The main objective of Monkey Testing is to check whether system crashes or not.

The main objective of Gorilla testing is to check whether the module is working properly or not.

Monkey testing is also known as Random testing, Fuzz Testing or Stochastic Testing.

Gorilla Testing is also known as Torture Testing, Fault Tolerance Testing or Frustrating Testing.

There are three types of Monkey Testing i.e. Dumb Monkey Testing, Smart Monkey Testing and Brilliant Monkey Testing.

While there is no such different types of Gorilla Testing available.

The implementation of Monkey testing does not require any planning or preparation.

The Gorilla testing cannot implement without any preparation or planning.

Please refer below video on monkey and gorilla testing:

Complete Software Testing Hierarchy | Software Testing Levels |Different Testing Types with Details

Complete Software Testing Hierarchy

Software Testing Hierarchy
Please refer the below video on Complete Software Testing Hierarchy:

Retesting and Regression Testing

 Re-testing

  • Testing the same functionality with different combination of input data is called retesting.
  • Retesting essentially means to test something again.
  • In simple words, Retesting is testing a specific bug after it was fixed. 
  • Retesting ensures that the issue has been fixed and is working as expected.
  • It is a planned testing with proper steps of verification
  • In some cases the entire module is required to be re-tested to ensure the quality of the module.

Why and when we perform Retesting

  • Retesting is used when there is any specific error or bug which needs to be verified.
  • It is used when the bug is rejected by the developers then the testing department tests whether that bug is actual or not.
  • It is also used to check the whole system to verify the final functionality.
  • It is used to test even the entire module or component in order to confirm the expected functionality.

Advantages

  • Retesting ensures that the issue has been fixed and is working as expected.
  • It improves the quality of the application or product
  • It requires less time for verification because it’s limited to the specific issue or any particular feature.
  • If the tester has knowledge of the source code, it becomes very easy to find out which type of data can help in testing the application effectively.

Disadvantages

  • It requires new build for verification of the defect.
  • Once the testing is started then only the test cases of retesting can be obtained and not before that.
  • The test cases for re-testing cannot be automated.

Regression Testing

  • If any changes are done in the existing build this test is conduct on the modified build to verify the changes are working correctly or not and because of this changes there are no side effect.
  • In Regression Test the change functionality + dependent functionality are tested .
  • The purpose of the regression testing is to find the bugs which may get introduced accidentally because of the new changes or modification.
  • This also ensures that the bugs found earlier are NOT creatable.
  • This helps in maintaining the quality of the product along with the new changes in the application.

When To use Regression Testing

  • Any new feature is added to an existing feature.
  • The codebase is fixed to solve defects.
  • Any bug is fixed
  • Changes in configuration.

Advantages

  • It helps the team to identify the defects and eliminate them earlier in the software development life cycle.
  • It ensures continuity of business functions with any rapid change in the software.
  • Regression testing can be done by using the automation tools.
  • It helps us to make sure that any changes like bug fixes or any enhancements to the module or application have not impacted the existing tested code.

Disadvantages

  • If regression testing is done without using automated tools then it can be very tedious and time consuming because here we execute the same set of test cases again and again.
  • Regression testing has to be performed for every small change in the code as even a small portion of code can create issues in the software.
  • It takes time to complete the tests and this slows down the agile velocity.
  • It's expensive and the cost is hard to justify. 

Re-testing vs Regression Testing:

Re-Testing

Regression Testing

Retesting is about fixing specific defects that you've already found.

Regression testing is about searching for defects.

Retesting is done only for failed test cases.

Regression testing is performed for passed test cases.

Retesting is used to ensure the test cases which failed in last execution are fixed.

Regression testing is to ensure that changes have not affected the unchanged part of product. 

Verification of bugs are included in the retesting.

Verification of bugs are not included in the regression testing.

Retesting is of high priority so it’s done before the regression testing.

Regression testing can be done in parallel with retesting.

Retesting the test cases cannot be automated.

Regression testing test cases can be automated.

In case of retesting the testing is done in a planned way.

In case of regression testing the testing style is generic.

Test cases of retesting can be obtained only when the testing starts.

Test cases of regression testing can be obtained from the specification documents and bug reports

Please refer the below video on complete video on Retesting and Regression Testing: