Definition: It is a step by step procedure right from collecting the requirements testing the product and handling over to the customers.
- SYSTEM STUDY:Whenever Customer gives requirement that will go through by the Manager/Test Lead. To understand the complicity of the requirement.
- TEST PLAN: Depending on that they will prepare Test Plan in which they write all necessary things required while testing.
- TEST DOCUMENT:These document is handed over to the Test Engineer in which they have mentioned what things need to be done while testing.
- we go for Read/Review/Understand requirement depending on that we write Test Scenarios where we write end to end flow of an application which is high level Test Document.
- This Document need to be converted to Low Level Document called as Test Case.
- After writing test cases we send it to the Test Case Reviewer for approval process goes until both (Author & Review) satisfies. Then it send to the Test Lead for Approve.
- Test Cases are stored in the centralize location called as Test Case Repository.
- we prepare RTM so that we don’t miss out any Test Case for any Requirement
- We go for Test Execution and execute all the test cases.
- While testing we may encounter some bugs that need to be fixed by the developers this process goes until the product stable this is known has Defect Tracking
- After completing the execution we prepare Test Execution Report which talk about the stability of the product which is handed over to the customer.
- Then Manager/Test Lead call a retrospect meeting where we discuss that do the Test Engineer got any problems in Test Plan, things need to be done in the next release.
BUG LIFE CYCLE:
Definition: The complete life cycle of a bug right from the stage it was found, fixed, retested and close.
- As soon as we get a bug the status is new or open.
- This bug is reported to the concert person by changing to assign.
- The developer first go-through the bug then reproduce and they do the necessary code changes & change the status to fixed.
- The Test Engineer need to Re-test the fixed bug and change the status according i.e. close if the bug is fixed properly or Re-open if the bug is still exist.
- This process continues until the bug is fixed & closed.
Note: – Whom to assign the bug
- Developers : – If we know who has developed that module.
- Developer Team: – If we don’t know the developer who has developed the module.
- Test lead : – We don’t have any contact with the development team.
Other Status of bug:
- Invalid / Rejected : – When the Test Engineer wrote a wrong Bug Report because of Misunderstanding Requirement then the developer will give status as Invalid –>Test Engineer Misunderstanding Requirement. –>Developer Misunderstanding Requirement
- Duplicate : – Same bug has been reported multiple times –> Dependent Modules –> Common features
- Not Reproducible:- Developer accept the bug but not able to Reproduce due to some reasons.
- Deffered : – The bug has been postponed to the future release due to time.
- Can’t fixed : – When developer accepting the bug and able to reproduce as well but can’t do the code changes due to some constraints.
- No technology support. — –>Bug is in core of code. –>Cost of fixing bug is more than keeping it.
- RFE (Request for Enhancement): – Suggestion given by the Test Engineer for the improvement of the application.
BUG REPORT TEMPLATE:
Regression Testing type 1: –
Whenever there are new Release for some project then we go for Regression Testing because the new feature may affect the old features in the previous releases.
Regression Test Cases:- These are the Test Cases of the old releases Text Document which need to be Re-executed
Challenges of Regression Testing:
- Identify Impact Area
- Time Constraint
- Test Cases Increases Release by Release
- Less Resources
- No Accuracy
- Repetitive Task
- Monotonous Task
Types of Regression Testing:
- Unit Regression Testing : – Check any changed unit [No Impact Area]
- Regional Regression Testing: – Check Changes + Impact Area
- Full Regression Testing : – Testing changes+complete and old features.
Impact Area is analysed by:
- Customer (Business Knowledge)
- Developer (Code Knowledge)
- Test Engineer (Product Knowledge)
Because if single person do he may not cover all the impact area so we include all this person so that we may cover maximum impact area.
Whenever we get new features (Modifying Features) we will analysis the impact area while same time the Developer also prepare the impact area (document) and customer also given impact area document so that we can achieve maximum impact analysis. All this document given to the Test Lead to consolidate. Then Test Lead take the help of RTM and pick the necessary Test Case from the Test case Repository and those files placed in the Regression Test Suit. Meanwhile we are working on the new features when the new features are stable then check the impact area using the test case until it is stable for old features + new features.
Regression Testing Type 2: –
Whenever Bug fixed we retest the bug and if there is any dependent module we go for a Regression Testing.
Questions on Regression Testing:
What is Regression Testing?
Retesting or Re-executing the old features or test cases to make sure that changes due to enhancement or bug fixes has not affected the existing functionality is known as Regression Testing.
When Regression Testing?
Whenever there are code changes due to enhancement or bug fixes.
Why we do Regression Testing?
To make sure existing features are not effecting due to changes.
How to do Regression Testing?
We prepare Regression Test Suit then Auto-machine Testing Process.
Who will do Regression Testing?
Auto-machine Test Engineer.
Differences of Re-Testing and Regression Testing:
Re-Testing: – Bug + Fix à Re-Testing bug only (No impact Area)
Regression Testing: – Bug + Fix à Re-Testing + Impact Area