Software Testing
Software testing is the process of evaluation a software item to detect differences between given input and expected output.
Systems Development Life Cycle
SDLC is a process used by a systems analyst to develop an information system, including requirements, validation, training, and user (stakeholder) ownership. Any SDLC should result in a high quality system that meets or exceeds customer expectations, reaches completion within time and cost estimates, works effectively and efficiently in the current and planned Information Technology Infrastructure
Types
waterfall, Agile Software development, spiral, rapid prototyping, incremental,synchronize and stabilize
Software Testing Life cylce is as follows:
1. Test Plan Prepation ( Prepare Test Plan based on Project Summary Document and SRS document)
2. Test Specifications Prepration(Test cases preparation based on Requirement document,use cases,mockup-links(in web based testing) etc)
3. Test Execution
To Perform Manual or Automation based on client requirement and software stability
a. Manaul Testing
b. Automation Testing
4. Defect Reporting and Tracking
Software Testing Life Cycle consists of six (generic) phases:
1. Test Planning
2. Test Analysis
3. Test Design,
4. Construction and verification
5. Testing Cycles
6. Final Testing and Implementation
7. Post Implementation.
In Test Planning following are the major tasks:
1. Defining scope of testing
2. Identification of approaches
3. Defining risk
4. Identifying resources
5. Defining Time Schedule
In Test Analysis : creating test case formats and test cases itself . Develop functional validation matrix based on Business Requirements to ensure that all system requirements are covered by one or more test cases, identify which test cases to automate, begin review of documentation, i.e. Functional Design, Business Requirements, Product Specifications, Product Externals etc. We also have to define areas for Stress and Performance Testing.
In Test Design : Test plans, cases and Functional validation matrix which were developed in the analysis phase are revised and finalized,Finalzes which test cases to automate and begin writing scripts for them. Test data is prepared. Test environment is prepared.
Construction and verification :complete all the test plans, test cases, complete the scripting of the automated test cases, Stress and Performance testing plans needs to be completed. Support the development team in their unit testing phase. And obviously bug reporting would be done as when the bugs are found. Integration tests are performed and errors (if any) are reported.
Testing cycles :complete testing cycles until test cases are executed without errors or a predefined condition is reached. Run test cases --> Report Bugs --> revise test cases (if needed) --> add new test cases (if needed) --> bug fixing --> retesting (test cycle 2, test cycle 3….).
Final Testing and Implimentation :execute remaining stress and performance test cases, documentation for testing is completed / updated, provide and complete different matrices for testing. Acceptance, load and recovery testing will also be conducted and the application needs to be verified under production conditions.
There are six types of testing:
5. Regression Testing
6. Beta Testing
Unit Testing
The control program is tested first. Modules are integrated one at a time. Emphasize on interface testing
Advantages:
Disadvantages:
Validating an application or Web site conforms to its specifications and correctly performs all its required functions. This entails a series of tests which perform a feature by feature validation of behavior, using a wide range of normal and erroneous input data. This can involve testing of the product's user interface, APIs, database management, security, installation, networking, etc
Disadvantages:
Testing conducted to evaluate a system or component at or beyond the limits of its specified requirements to determine the load under which it fails and how Often Stress Testing is performed using the same process as Performance Testing but employing a very high level of simulated load.
Performance Testing
Performance testing can be applied to understand your application or web site's scalability, or to benchmark the performance in an environment of third party products such as servers and middleware for potential purchase. useful to identify performance bottlenecks in high use applications. generally involves an automated test suite as this allows easy simulation of a variety of normal, peak, and exceptional load conditions.
Usability Testing
Testing to verify a product meets customer specified requirements.
Regression Testing
Similar in scope to a functional test, a regression test allows a consistent, repeatable validation of each new release of a product or Web site. Such testing ensures reported product defects have been corrected for each new release and that no new quality problems were introduced in the maintenance process.
Disadvantages:
To decide how much of a subset to use and which tests to select .
Beta Testing
Testing when development and testing are essentially completed and final bugs, problems need to be found before the final release. Beta Testing is typically done by end-users or others, not by programmers or testers
Other Types of Testing
Black Box Testing
Testing without knowledge of the internal workings of the item being tested. Tests are usually functional.
Compatability Testing
Testing to ensure compatibility of an application or Web site with different browsers, OSs, and hardware platforms. Compatibility testing can be performed manually or can be driven by an automated functional or regression test suite.
System Testing
Testing conducted on a complete, integrated system to evaluate the system's compliance with its specified requirements. System testing falls within the scope of black box testing, and as such, should require no knowledge of the inner design of the code or logic.
White Box Testing
Testing based on an analysis of internal workings and structure of a piece of software. Also known as Structural Testing and Glass Box Testing.
Security testing
If your site requires firewalls, encryption, user authentication, financial transactions, or access to databases with sensitive data, you may need to test these and also test your site’s overall protection against unauthorized internal or external access.
Mutation Testing
Mutation testing is a method for determining if a set of test data or test cases is useful, by deliberately introducing various code changes (‘bugs’) and retesting with the original test data/cases to determine if the ‘bugs’ are detected.
Sanity testing
Typically an initial testing effort to determine if a new software version is performing well enough to accept it for a major testing effort, For example, if the new software is crashing systems every 5 minutes, bogging down systems to a crawl, or destroying databases, the software may not be in a ‘sane’ enough condition to warrant further testing in its current state.
Database Testing
Database testing done manually in real time, it check the data flow between front end back ends. Observing that operations, which are operated on front-end is effected on back-end or not.
Load Testing
It verifies the performance of the server under stress of many clients requesting data at the same time.
Alpha Testing
Testing of an application when development is nearing completion, Minor design changes may still be made as a result of such testing. Alpha Testing is typically performed by end-users or others, not by programmers or testers.
System Testing
Upon completion of integration testing, the Test Team will begin system testing. During system testing, which is a black box test, the complete system is configured in a controlled environment to validate its accuracy and completeness in performing the functions as designed. The system test will simulate production in that it will occur in the “production-like” test environment and test all of the functions of the system that will be required in production. The Test Team will complete the system test. Prior to the system test, the unit and integration test results will be reviewed by SQA to ensure all problems have been resolved. It is important for higher level testing efforts to understand unresolved problems from the lower testing levels. System testing is deemed complete when actual results and expected results are either in line or differences are explainable/acceptable based on client input.
Testing Methods
There are different methods which can be use for Software testing. This chapter briefly describes those methods.
Black Box Testing
The technique of testing without having any knowledge of the interior workings of the application is Black Box testing. The tester is oblivious to the system architecture and does not have access to the source code. Typically, when performing a black box test, a tester will interact with the system's user interface by providing inputs and examining outputs without knowing how and where the inputs are worked upon.
Test case is a set of conditions or variables and inputs that are developed for a particular goal to be achieved on a certain application to judge its capabilities or features.
It might take more than one test case to determine the true functionality of the application being tested. Some software development methodologies like Rational Unified Process (RUP) recommend creating at least two test cases for each requirement or objective; one for positive perspective and the other, negative perspective
Test Case Structure
New
This is the first stage of bug life cycle in which the tester reports a bug. The presence of the bug becomes evident when the tester tries to run the newly developed application and it does not respond in an expected manner. This bug is then send to the testing lead for approval.
Open
When the bug is reported to the testing lead, he examines the bug by retesting the product. If he finds that the bug is genuine, he approves it and changes its status to 'open'.
Assign
Once the bug has been approved and found genuine by the testing lead, it is then send to the concerned software development team for its resolution. It can be assigned to the team who created the software or it may be assigned to some specialized team. After assigning the bug to the software team, the status of the bug is changed to 'assign'.
Test
The team to which the bug has been assigned works on the removal of bug. Once, they are finished with fixing the bug, it is sent back to the testing team for a retest. However, before sending the bug back to the testing team, its status is changed to 'test' in the report.
Deferred
If the development team changes the status of the bug to 'deferred', it means that the bug will be fixed in the next releases of the software. There can be myriad reason why the software team may not consider fixing the bug urgently. This includes lack of time, low impact of the bug or negligible potential of the bug to induce major changes in the normal functioning of the software.
Rejected
Although, the testing lead might have approved the bug stating it as a genuine one, the software development team may not always agree. Ultimately, it is the prerogative of the development team to decide if the bug is really genuine or not. If they doubt the presence or impact of the bug, then they may change its status to 'rejected'.
Duplicate
If the development team finds that the same bug has been repeated twice or there are two bugs which point to the same concept, then the status of one bug is changed to 'duplicate'. In this case, fixing one bug automatically takes care of the other bug.
Verified
If the software development team sends the fixed bug back for retesting, then the bug undergoes rigorous testing procedure again. If at the end of the test, it is not found then its status is changed to 'verified.'
Reopened
If the bug still exists, then its status is changed to 'reopened'. The bug then traverses the entire of its life cycle once again.
Closed
If no occurrence of bug is reported and if the software functions normally, then the bug is 'closed.' This is the final stage in which the bug has been fixed, tested and approved.
Review is an evaluation of a said product or project status to ascertain any discrepancies from the actual planned results and to recommend improvements to the said product. The common examples of reviews are informal review or peer review, technical review, inspection, walkthrough, management review.
Priority is the level of business importance, which is assigned to a defect found. On the other hand, severity is the degree of impact, the defect can have on the development or operation of the component or the system.
What is verification? validation?
Verification(Quality Control) typically involves reviews and meetings to evaluate documents, plans, code, requirements, and specifications. This can be done with checklists, issues lists, walkthroughs, and inspection meetings. Validation(Quality Assurance) typically involves actual testing and takes place after verifications are completed. The term 'IV & V' refers to Independent Verification and Validation.
Defect Life Cycle
Stage 1, defects are found and reported.
Stage 2, defects are reviewed and delegated.
Stage 3, defects are debugged and removed.
Stage 4, removed defects are confirmed.
Stage 1: Defects are found and reported by the testing team
Software released to testing
After the development team have developed the software and is ready for testing, the software is then released to the testing team. Items released to testing generally include Software Requirement Specification (SRS), Software Design Specification(SDS), application source code (for code walkthroughs and inspections), executable application and any third party libraries that may be required to make the application work.
Testing team prepare and setup the testing environment; install the application and any required third party libraries.
Testing team start testing
Once the application is installed, members of the testing team will start testing the application based on the Test Procedures. The activities may include Functional Testing, Non-Functional Testing, Performance Testing, etc.
Defects may be found
During testing testers may find defects either in the application or in the documents
e.g. test procedure.
If a defect is found, either in the application (source code) or in the document, a
defect report form is filled and passed on to the test team lead or test manager for
review. (There is a detailed explanation on what to include in the defect form in this
article: Defect Reporting).
Stage 2: Defects are reviewed and delegated
Defects get reviewed first by test team lead for any obvious mistakes by the testers,
such as missing information on the defect form (see Defect Reporting) and then
reported to software development manager for further review.
A meeting is scheduled which includes members of the development team and
testing team to discuss the validity, severity and priority of the defects.
At this stage, defects are categorized into three different states:
Not a defect
Defect will be fixed
Defect won’t be fixed in this release
Stage 3: Defects are debugged and removed
Fixing defects
After the meeting and agreed actions, the software development manager delegates
defects to different developers in the team.
For defects that are not going to be fixed in the current version of the software, an
impact analysis must be performed to identify any potential failures that may occur as
a result of the existing defects in the system.
Developers will analyse the source code to identify the root cause and ultimately
remove the defect.
Stage 4: Removed defects are confirmed
Confirmation Testing and Regression Testing
The “Fixed” version of the software will be released to the testing team and testers will start to test the “fixed” software. At this stage, two types of testing are performed by the testers: confirmation testing and regression testing.
Based on the outcome of the confirmation testing, the “fixed” defects are either confirmed as fixed (defect is removed) or not fixed (defect still exists).
For defects that are fixed, their status is changed to fixed and can be closed.
For defects that are not fixed, i.e. they still exist in the system, they go round the cycle again, i.e. are reported to the development team, gets reviewed by the development team, faults are removed, a new version of software is released to testing for confirmation + regression testing and so on.
This cycle is repeated until all the defects (that were decided to be fixed in the current version) are fixed and verified by testers.
Software testing is the process of evaluation a software item to detect differences between given input and expected output.
Systems Development Life Cycle
SDLC is a process used by a systems analyst to develop an information system, including requirements, validation, training, and user (stakeholder) ownership. Any SDLC should result in a high quality system that meets or exceeds customer expectations, reaches completion within time and cost estimates, works effectively and efficiently in the current and planned Information Technology Infrastructure
Types
waterfall, Agile Software development, spiral, rapid prototyping, incremental,synchronize and stabilize
Software Testing Life cylce is as follows:
1. Test Plan Prepation ( Prepare Test Plan based on Project Summary Document and SRS document)
2. Test Specifications Prepration(Test cases preparation based on Requirement document,use cases,mockup-links(in web based testing) etc)
3. Test Execution
To Perform Manual or Automation based on client requirement and software stability
a. Manaul Testing
b. Automation Testing
4. Defect Reporting and Tracking
Software Testing Life Cycle consists of six (generic) phases:
1. Test Planning
2. Test Analysis
3. Test Design,
4. Construction and verification
5. Testing Cycles
6. Final Testing and Implementation
7. Post Implementation.
In Test Planning following are the major tasks:
1. Defining scope of testing
2. Identification of approaches
3. Defining risk
4. Identifying resources
5. Defining Time Schedule
In Test Analysis : creating test case formats and test cases itself . Develop functional validation matrix based on Business Requirements to ensure that all system requirements are covered by one or more test cases, identify which test cases to automate, begin review of documentation, i.e. Functional Design, Business Requirements, Product Specifications, Product Externals etc. We also have to define areas for Stress and Performance Testing.
In Test Design : Test plans, cases and Functional validation matrix which were developed in the analysis phase are revised and finalized,Finalzes which test cases to automate and begin writing scripts for them. Test data is prepared. Test environment is prepared.
Construction and verification :complete all the test plans, test cases, complete the scripting of the automated test cases, Stress and Performance testing plans needs to be completed. Support the development team in their unit testing phase. And obviously bug reporting would be done as when the bugs are found. Integration tests are performed and errors (if any) are reported.
Testing cycles :complete testing cycles until test cases are executed without errors or a predefined condition is reached. Run test cases --> Report Bugs --> revise test cases (if needed) --> add new test cases (if needed) --> bug fixing --> retesting (test cycle 2, test cycle 3….).
Final Testing and Implimentation :execute remaining stress and performance test cases, documentation for testing is completed / updated, provide and complete different matrices for testing. Acceptance, load and recovery testing will also be conducted and the application needs to be verified under production conditions.
There are six types of testing:
- Unit Testing
- Integration Testing
- Functional and System Testing
- Stress Testing
- Performance Testing
- Usability Testing
5. Regression Testing
6. Beta Testing
Unit Testing
- Individual components are tested.
- It is a path test.
- To focus on a relatively small segment of code and aim to exercise a high percentage of the internal pat.
- The main disadvantage is the test value may not cover all possible values.
- Testing in which modules are combined and tested as a group.
- Modules are typically code modules, individual applications, client and server applications on a network, etc. Integration Testing follows unit testing and precedes system testing.
- Top-down Integration Test
- Bottom-up Integration Test
The control program is tested first. Modules are integrated one at a time. Emphasize on interface testing
Advantages:
- No test drivers needed.
- Interface errors are discovered early.
- Modular features aid debugging
- Test stubs are needed.
- Errors in critical modules at low levels are found late.
- Allow early testing aimed at proving feasibility
- Emphasize on module functionality and performance
- No test stubs are needed Errors in critical modules are found early.
Disadvantages:
- Test drivers are needed Interface errors are discovered late.
Validating an application or Web site conforms to its specifications and correctly performs all its required functions. This entails a series of tests which perform a feature by feature validation of behavior, using a wide range of normal and erroneous input data. This can involve testing of the product's user interface, APIs, database management, security, installation, networking, etc
Disadvantages:
- The need for explicitly stated requirements.
- Only cover a small portion of the possible test conditions.
Testing conducted to evaluate a system or component at or beyond the limits of its specified requirements to determine the load under which it fails and how Often Stress Testing is performed using the same process as Performance Testing but employing a very high level of simulated load.
Performance Testing
Performance testing can be applied to understand your application or web site's scalability, or to benchmark the performance in an environment of third party products such as servers and middleware for potential purchase. useful to identify performance bottlenecks in high use applications. generally involves an automated test suite as this allows easy simulation of a variety of normal, peak, and exceptional load conditions.
Usability Testing
- Usability testing is an effort to ascertain the degree to which software has met the usability needs of its intended user base
- Usability is difficult to evaluate and measure
Testing to verify a product meets customer specified requirements.
Regression Testing
Similar in scope to a functional test, a regression test allows a consistent, repeatable validation of each new release of a product or Web site. Such testing ensures reported product defects have been corrected for each new release and that no new quality problems were introduced in the maintenance process.
Disadvantages:
To decide how much of a subset to use and which tests to select .
Beta Testing
Testing when development and testing are essentially completed and final bugs, problems need to be found before the final release. Beta Testing is typically done by end-users or others, not by programmers or testers
Other Types of Testing
Black Box Testing
Testing without knowledge of the internal workings of the item being tested. Tests are usually functional.
Compatability Testing
Testing to ensure compatibility of an application or Web site with different browsers, OSs, and hardware platforms. Compatibility testing can be performed manually or can be driven by an automated functional or regression test suite.
System Testing
Testing conducted on a complete, integrated system to evaluate the system's compliance with its specified requirements. System testing falls within the scope of black box testing, and as such, should require no knowledge of the inner design of the code or logic.
White Box Testing
Testing based on an analysis of internal workings and structure of a piece of software. Also known as Structural Testing and Glass Box Testing.
Security testing
If your site requires firewalls, encryption, user authentication, financial transactions, or access to databases with sensitive data, you may need to test these and also test your site’s overall protection against unauthorized internal or external access.
Mutation Testing
Mutation testing is a method for determining if a set of test data or test cases is useful, by deliberately introducing various code changes (‘bugs’) and retesting with the original test data/cases to determine if the ‘bugs’ are detected.
Sanity testing
Typically an initial testing effort to determine if a new software version is performing well enough to accept it for a major testing effort, For example, if the new software is crashing systems every 5 minutes, bogging down systems to a crawl, or destroying databases, the software may not be in a ‘sane’ enough condition to warrant further testing in its current state.
Database Testing
Database testing done manually in real time, it check the data flow between front end back ends. Observing that operations, which are operated on front-end is effected on back-end or not.
Load Testing
It verifies the performance of the server under stress of many clients requesting data at the same time.
Alpha Testing
Testing of an application when development is nearing completion, Minor design changes may still be made as a result of such testing. Alpha Testing is typically performed by end-users or others, not by programmers or testers.
System Testing
Upon completion of integration testing, the Test Team will begin system testing. During system testing, which is a black box test, the complete system is configured in a controlled environment to validate its accuracy and completeness in performing the functions as designed. The system test will simulate production in that it will occur in the “production-like” test environment and test all of the functions of the system that will be required in production. The Test Team will complete the system test. Prior to the system test, the unit and integration test results will be reviewed by SQA to ensure all problems have been resolved. It is important for higher level testing efforts to understand unresolved problems from the lower testing levels. System testing is deemed complete when actual results and expected results are either in line or differences are explainable/acceptable based on client input.
Testing Methods
There are different methods which can be use for Software testing. This chapter briefly describes those methods.
Black Box Testing
The technique of testing without having any knowledge of the interior workings of the application is Black Box testing. The tester is oblivious to the system architecture and does not have access to the source code. Typically, when performing a black box test, a tester will interact with the system's user interface by providing inputs and examining outputs without knowing how and where the inputs are worked upon.
Test case is a set of conditions or variables and inputs that are developed for a particular goal to be achieved on a certain application to judge its capabilities or features.
It might take more than one test case to determine the true functionality of the application being tested. Some software development methodologies like Rational Unified Process (RUP) recommend creating at least two test cases for each requirement or objective; one for positive perspective and the other, negative perspective
Test Case Structure
- Information incorporates Identifier, test case creator, test case version, name of the test case, purpose or brief description and test case dependencies.
- Activity contains information about the test case environment, activities to be done at test case initialization, activities to be done after test case is performed, step by step actions to be done while testing and the input data that is to be supplied for testing.
- Results data consist of information about expected results and the actual results.
New
This is the first stage of bug life cycle in which the tester reports a bug. The presence of the bug becomes evident when the tester tries to run the newly developed application and it does not respond in an expected manner. This bug is then send to the testing lead for approval.
Open
When the bug is reported to the testing lead, he examines the bug by retesting the product. If he finds that the bug is genuine, he approves it and changes its status to 'open'.
Assign
Once the bug has been approved and found genuine by the testing lead, it is then send to the concerned software development team for its resolution. It can be assigned to the team who created the software or it may be assigned to some specialized team. After assigning the bug to the software team, the status of the bug is changed to 'assign'.
Test
The team to which the bug has been assigned works on the removal of bug. Once, they are finished with fixing the bug, it is sent back to the testing team for a retest. However, before sending the bug back to the testing team, its status is changed to 'test' in the report.
Deferred
If the development team changes the status of the bug to 'deferred', it means that the bug will be fixed in the next releases of the software. There can be myriad reason why the software team may not consider fixing the bug urgently. This includes lack of time, low impact of the bug or negligible potential of the bug to induce major changes in the normal functioning of the software.
Rejected
Although, the testing lead might have approved the bug stating it as a genuine one, the software development team may not always agree. Ultimately, it is the prerogative of the development team to decide if the bug is really genuine or not. If they doubt the presence or impact of the bug, then they may change its status to 'rejected'.
Duplicate
If the development team finds that the same bug has been repeated twice or there are two bugs which point to the same concept, then the status of one bug is changed to 'duplicate'. In this case, fixing one bug automatically takes care of the other bug.
Verified
If the software development team sends the fixed bug back for retesting, then the bug undergoes rigorous testing procedure again. If at the end of the test, it is not found then its status is changed to 'verified.'
Reopened
If the bug still exists, then its status is changed to 'reopened'. The bug then traverses the entire of its life cycle once again.
Closed
If no occurrence of bug is reported and if the software functions normally, then the bug is 'closed.' This is the final stage in which the bug has been fixed, tested and approved.
Review is an evaluation of a said product or project status to ascertain any discrepancies from the actual planned results and to recommend improvements to the said product. The common examples of reviews are informal review or peer review, technical review, inspection, walkthrough, management review.
Priority is the level of business importance, which is assigned to a defect found. On the other hand, severity is the degree of impact, the defect can have on the development or operation of the component or the system.
What is verification? validation?
Verification(Quality Control) typically involves reviews and meetings to evaluate documents, plans, code, requirements, and specifications. This can be done with checklists, issues lists, walkthroughs, and inspection meetings. Validation(Quality Assurance) typically involves actual testing and takes place after verifications are completed. The term 'IV & V' refers to Independent Verification and Validation.
Defect Life Cycle
Stage 1, defects are found and reported.
Stage 2, defects are reviewed and delegated.
Stage 3, defects are debugged and removed.
Stage 4, removed defects are confirmed.
Stage 1: Defects are found and reported by the testing team
Software released to testing
After the development team have developed the software and is ready for testing, the software is then released to the testing team. Items released to testing generally include Software Requirement Specification (SRS), Software Design Specification(SDS), application source code (for code walkthroughs and inspections), executable application and any third party libraries that may be required to make the application work.
Testing team prepare and setup the testing environment; install the application and any required third party libraries.
Testing team start testing
Once the application is installed, members of the testing team will start testing the application based on the Test Procedures. The activities may include Functional Testing, Non-Functional Testing, Performance Testing, etc.
Defects may be found
During testing testers may find defects either in the application or in the documents
e.g. test procedure.
If a defect is found, either in the application (source code) or in the document, a
defect report form is filled and passed on to the test team lead or test manager for
review. (There is a detailed explanation on what to include in the defect form in this
article: Defect Reporting).
Stage 2: Defects are reviewed and delegated
Defects get reviewed first by test team lead for any obvious mistakes by the testers,
such as missing information on the defect form (see Defect Reporting) and then
reported to software development manager for further review.
A meeting is scheduled which includes members of the development team and
testing team to discuss the validity, severity and priority of the defects.
At this stage, defects are categorized into three different states:
Not a defect
Defect will be fixed
Defect won’t be fixed in this release
Stage 3: Defects are debugged and removed
Fixing defects
After the meeting and agreed actions, the software development manager delegates
defects to different developers in the team.
For defects that are not going to be fixed in the current version of the software, an
impact analysis must be performed to identify any potential failures that may occur as
a result of the existing defects in the system.
Developers will analyse the source code to identify the root cause and ultimately
remove the defect.
Stage 4: Removed defects are confirmed
Confirmation Testing and Regression Testing
The “Fixed” version of the software will be released to the testing team and testers will start to test the “fixed” software. At this stage, two types of testing are performed by the testers: confirmation testing and regression testing.
Based on the outcome of the confirmation testing, the “fixed” defects are either confirmed as fixed (defect is removed) or not fixed (defect still exists).
For defects that are fixed, their status is changed to fixed and can be closed.
For defects that are not fixed, i.e. they still exist in the system, they go round the cycle again, i.e. are reported to the development team, gets reviewed by the development team, faults are removed, a new version of software is released to testing for confirmation + regression testing and so on.
This cycle is repeated until all the defects (that were decided to be fixed in the current version) are fixed and verified by testers.