Expert Manual Testing Strategies: Free Course Part 5

What is Un-Installation Testing?

• Checking whether we are able to uninstall the software from the system successfully (or) not is called Un-Installation Testing

What is Compatibility Testing?

• Checking whether the application is compatible with different software and hardware environment or not is called Compatibility Testing.

What is Exhaustive Testing?

• Exhaustive testing is a test approach in which all possible data combinations are used for testing. Exploratory testing includes implicit data combinations present in the state of the software/data at the start of testing.

What is Performance Testing?

• Performance testing is a non-functional testing technique performed to determine the system parameters in terms of responsiveness and stability under the various workloads. Performance testing measures the quality attributes of the system, such as scalability, reliability and resource usage.

Performance Testing Techniques:

• Load testing - It is the simplest form of testing conducted to understand the behavior of the system under the specific load. This will result in measuring important business critical transactions and load on database, application server, etc.,
• Stress testing - It is carried out to find the upper limit capacity of the system and also to determine how system performs if the current load goes above expected maximum level.
• Soak testing - Soak Testing is also known as endurance testing, performed to determine the system parameters under continuous expected load. During Soak tests the parameters such as memory utilization is monitored to detect memory leaks, other performance issues. The main aim is to discover the system's performance under sustained use.
• Spike testing - Spike testing is performed by increasing the number of users suddenly by a very large amount and measuring the performance of the system.The main aim is to determine whether the system will be able to sustain the workload.

EXPLAIN STLC (SOFTWARE TESTING LIFE CYCLE)

            Software Testing Life Cycle (STLC) is a sequence of specific activities conducted during the testing process to ensure software quality goals are met. STLC involves both verification and validation activities. Contrary to popular belief, Software Testing is not just a single/isolate activity, i.e., testing. It consists of a series of activities carried out methodologically to help certify your software product. STLCstands for Software Testing Life Cycle.

STLC Phases

There are following six major phases in every Software Testing Life Cycle Model

(STLC Model):

• Requirement Analysis
• Test Planning
• Test case development
• Test Environment setup
• Test Execution
• Test execution report

Requirement Analysis :

Requirement Analysis is the first step of Software Testing Life Cycle (STLC). In this phase quality assurance team understands the requirements like what is to be tested. If anything is missing or not understandable then quality assurance team meets with the stakeholders to better understand the detail knowledge of requirement.

Test Planning:

Test Planning is most efficient phase of software testing life cycle where all testing plans are defined. In this phase manager of the testing team calculates estimated effort and cost for the testing work. This phase gets started once the requirement gathering phase is completed.

Test Design:

The test team starts with test case development activity here in this phase. Testers prepares test cases, test scripts (if automation), and test data.Once the test cases are ready then these test cases are reviewed by peer members or team lead.

Test Execution:

The test team starts executing the test cases based on the planned test cases. If a test case result is Pass/Fail then the same should be updated in the test cases.

The defect report should be prepared for failed test cases and should be reported to the Development Team through a bug tracking tool for fixing the defects.

Defect Tracking :

Defect tracking is the process of identifying, isolating and managing the defects.

The bug life cycle is also known as the Defect life cycle. In the Software Development Process, the bug has a life cycle. The bug should go through the life cycleto be closed.

New

• When a tester finds a new defect. He should provide a proper Defect document to the Development team to reproduce and fix the defect. In this state, the status of the defect posted by the tester is “New”
• Assigned Defects that are in the status of New will be approved (if valid) and assigned to the development team by Test Lead/Project Lead/Project Manager. Once the defect is assigned then the status of the bug changes to “Assigned”

Open

• The development team starts analyzing and works on the defect fix

Fixed

• When a developer makes the necessary code change and verifies the change, then the status of the bug will be changed as “Fixed” and the bug is passed to the testing team.

Test

• If the status is “Test”, it means the defect is fixed and ready to do test whether it is fixed or not.

Verified

• The tester re-tests the bug after it got fixed by the developer. If there is no bug detected in the software, then the bug is fixed and the status assigned is “verified.”

Closed

• After verified the fix, if the bug is no longer exits then the status of the bug will be assigned as “Closed.”

Reopen

• If the defect remains the same after the retest, then the tester posts the defect using the defect retesting document and changes the status to “Reopen”. Again, the bug goes through the life cycle to be fixed.

Duplicate

• If the defect is repeated twice or the defect corresponds to the same concept of the bug, the status is changed to “duplicate” by the development team.

Deferred

• In some cases, the Project Manager/Lead may set the bug status as deferred. If the bug found during the end of the release and the bug is minor or not important to fix immediately. If the bug is not related to the current build. If it is expected to get fixed in the next release.The customer is thinking to change the requirement.In such cases the status will be changed as “deferred” and it will be fixed in the next release.

Rejected

• If the system is working according to specifications and the bug is just due to some misinterpretation (such as referring to old requirements or extra features) then the Team lead or developers can mark such bugs as “Rejected”.

-:THANK YOU :-