The document provides an overview of the software testing life cycle (STLC) which includes test planning, test development, test execution, result analysis, defect management, and summarized reports. It then describes each phase in more detail, outlining key activities, participants, and deliverables. For example, test planning involves preparing test strategies and plans, estimating effort, and identifying risks. Test development consists of writing test cases and scripts, setting up environments, and reviewing test artifacts. The document also defines common testing terms like test plans, test cases, defect priority and severity levels.

1. QA –Testing Material 1
www.TransformToIT.com Prepared By: A.B Reddy
STLC (Software Testing Life Cycle)
 Test Planning
 Test Development
 Test Execution
 Result Analysis
 Defect Management
 Summarized Reports
Test Planning:
 Preparation of QA or Test Strategy
 Prepare Test Plans
 Plan for Resources
 Effort Estimation
 Plan for the training needs
 Evaluation of tools & technologies
 Risks & Mitigation
Participants: Test Manager and Test Lead
Deliverables: Test Strategy Document, Test Plan Document
Test Development
 Preparation of Test scenarios from real time Business Scenarios or combine collection of Uses cases and
derive test Scenario out of it.
 Derive positive and Negative Test cases and write down Test Conditions
 Preparation of test Data
 Review of Test cases
 Decide Test cases for Automation (Automation)
 Develop Test Scripts (Automation)
 Setup Test environment
1. Developer Environment (Developer develop code and perform Unit test on this)
2. QA Environment (Replica of Client Environment)
3. Staging (or) implementation Environment (Production Like Environment with Production data
and External Connections)
4. Production Environment (Live Environment)
Above all are Ideal Environments, but in reality no. of Environments may vary For Example
If Technical Leadership decided to have one exclusive Environment for Integration testing they will come up with
integration QA Environment along with QA Environment
If Business Users decided they want one exclusive environment for them they request to build End User
Environment for User Acceptance Testing …etc
Participants: Test Lead and Testers (Test Case Designers and Test Case Executioners)
Deliverables: Test Case Documents, Test Data
Conduct Test Readiness Review meeting before to starting Execution

2. QA –Testing Material 2
www.TransformToIT.com Prepared By: A.B Reddy
Environment Team will provide Test Environment Readiness; expected figure is 100% to start execution, Test
Team need to provide Test Case Design readiness to start the Execution
Test Execution
o Perform Manual Execution of Test cases with provided Test data Input (Manual testing)
o Executioner need to follow appropriately Pre-Condition and Post-Condition of the test cases.
Sometimes there should be dependency like; test case 1 is the pre-condition of the test case2. So
make sure Test case1 is already executed before starting the Execution of testcase2.
Testcase1: Registration of User
Testcase2: Login to the website with Existing User
o Perform Automated scripts Execution.(Automated Testing)
o Monitor the Automation run and perform error handling manually if test script Struck
With runtime Error
Participants: Testers (Test Executioners)
Deliverables: Test Case Results (Before Analysis)
Result Analysis
Result Analysis is crucial step to judge the Application Fault. In the Test Case Execution
If Test case Actual result doesn’t match with Expected Result:
Verify that test case has been written as per the requirements, some times there may be test case
problem or requirements might have changed after the test case has been designed.
If Test case Expected Result matches with requirement.
Executioner should double check the Actual Behavior by executing test case one more time.
If Still “Actual Result” mismatches with “Expected Result”.
Verify is there any test Environment problem (note that many cases environment will be fine).
If Test Environment is Fine
Next step will be double check the test data provided, whether data matching with the test case
requirement.
If test Data is also Fine then Executioner analysis confirms that Fault is Application side,
Executioner must mark the “Test Case Result” Column in test Case as “Failed”
Executioner need to start gathering details to file a Defect.
Participants: Test Leads and testers
Deliverables: Test Case Result Reports (after Analysis)
Defect Tracking
Before creating new Defect ,perform Duplicate Defect Check (make sure the same Application defect hasn’t been
filed by others )
• File new defect and associate enough information to help developer for further analysis
Information can be
o Detailed Steps to reproduce the Defect, Actual result and Expected Result
o Snapshot of the User Interface Screen or Database Result Set when Error Occurred
o Error Log of any Server
• Assign Defect to Developer, if don’t know about exact developer then Assign to Development Lead later
he can route to appropriate person.
• Defect Follow-up with Developer

3. QA –Testing Material 3
www.TransformToIT.com Prepared By: A.B Reddy
o If Developer has concerns about opened defect, if he has concerns tester may explain and
convince about the defect to resolve his concerns.
o If Developer corrected code and fixed the defect, Tester need to re-test and Close the defect.
Participants: Test Leads, Test managers and testers
Deliverables: Defect Reports
Summarized Reports
• Prepare Test Case Result Documents
• Create Defect Reports :Total how many no of bugs identified….etc
• Create Test Case Reports :
About Test Execution: Total how many no of cases executed
About Pass Percentage: How many test cases Passed as result of Total test cases, based on this
report Management takes the decision about postponement of the Release
Participants: Test Leads and managers
Deliverables: Metric Documents and Reports
Test Strategy Document
A Test Strategy document is a high level document and normally developed by project manager. This document
defines “Testing Approach” to achieve testing objectives. A test strategy is an outline that describes the testing
portion of the software development cycle. It is created to inform project managers, testers, and developers about
some key issues of the testing process. This includes the testing objective, methods of testing new functions, total
time and resources required for the project, and the testing environment.
The test strategy describes how the product risks of the stakeholders are mitigated at the test-level, which types
of test are to be performed, and which entry and exit criteria apply.
The test strategy is created based on development design documents. The Test Strategy is normally derived from
the Business Requirement Specification document. The system design document is the main one used and
occasionally, the conceptual design document can be referred to. The design documents describe the
functionalities of the software to be enabled in the upcoming release. For every set of development design, a
corresponding test strategy should be created to test the new feature sets.
This is a standard approach to prepare test plan and test strategy documents, but things can vary company-to-
company. Some companies include the “Test Approach” or “Strategy” inside the Test Plan, which is fine and it is
usually the case for small projects. However, for larger projects, there is one Test Strategy document and different
number of Test Plans for each phase or level of testing.
Components of the Test Strategy document
Scope and Objectives
Business issues
Roles and responsibilities
Communication and status reporting
Test deliverability
Industry standards to follow
Test automation and tools
Testing measurements and matrices

4. QA –Testing Material 4
www.TransformToIT.com Prepared By: A.B Reddy
Risks and mitigation
Defect reporting and tracking
Change and configuration management
Training plan
Test Plan
A test plan is a general document for the entire project that defines the scope, approach to be taken, and the
schedules of intended testing activities. It identifies test items, the features to be tested, the testing tasks, who
will do each task and any risks requiring contingency planning.
The Test Plan document on the other hand, is derived from the Product Description, Software Requirement
Specification SRS, or Use Case Documents.
The Test Plan document is usually prepared by the Test Lead or Test Manager and the focus of the document is
to describe what to test, how to test, when to test and who will do what test.
The test planning can be done, well before the actual testing commences and can be done in parallel with the coding and
design phase.
The inputs for forming test plan are
 Project plan
 Requirement spec. Doc.
 Architecture and design document.
Test Plan (IEEE 829 format)
• Test Plan Identifier – Test Plan Unique Number
• References – have any references
• Introduction – about Current Project
• Test Items – Names of Modules or functionalities of Current Project
• Software Risk Issues - Identify and Present Risks Involved.
• Features to be Tested – Names of Functionalities to be tested in this test plan
• Features not to be Tested - Names of Functionalities not to be tested in this test plan
• Approach- Test Approach to be followed – like Unit, integration, Bugs calculation etc
• Entry Criteria- SRS review done , Establish test environment , receive Build from developers
• Item Pass/Fail Criteria- Define the Pass/Fail Criteria
• Suspension Criteria- When Interrupt testing -When major defect found, Test Environment Abounded etc
• Test Deliverables – List of testing docs (Test scenarios, test cases, Automation Plan, Results and Defect
Logs)
• Environmental Needs- Stable Environment Provided with minimum Components, pass the sanity Check

5. QA –Testing Material 5
www.TransformToIT.com Prepared By: A.B Reddy
• Staffing and Training Needs- names of testers in the current project and required number of training
sessions to understand project requirements
• Responsibilities- Work allocation to testers Module wise etc.
• Schedule- Dates and Times when Testing to be started.
• Planning Risks and Contingencies- List out Risks , and Risk mitigation
• Approvals- Required signatures of the Leads and Managers to make test plan effective
What is a Test Case?
A test case is a set of conditions or variables and inputs that are developed for a particular goal or objective 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. Every
requirement or objective to be achieved needs at least one test case. Some software development methodologies
like Rational Unified Process (RUP) recommend creating at least two test cases for each requirement or
objective; one for performing testing through positive perspective and the other through negative perspective.
Test Case Structure
A formal written test case comprises of three parts -
Information
Information consists of general information about the test case. Information incorporates Identifier, test
case creator, test case version, name of the test case, purpose or brief description and test case
dependencies.
Activity
Activity consists of the actual test case activities. 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
Results are outcomes of a performed test case. Results data consist of information about expected
results and the actual results.
A Test Case will consist of information such as requirements testing, test steps, verification steps, prerequisites,
Actual result, Expected result etc. A set of inputs, execution preconditions, and expected outcomes developed for
a particular objective, such as to exercise a particular program path or to verify compliance with a specific
requirement.

6. QA –Testing Material 6
www.TransformToIT.com Prepared By: A.B Reddy
Test Case Template & Example:
Defect Life Cycle

7. QA –Testing Material 7
www.TransformToIT.com Prepared By: A.B Reddy
Description of Various Stages:
1. New: When the bug is posted for the first time, its state will be “NEW”. This means that the bug is not
yet approved.
2. Open: After a tester has posted a bug, the lead of the tester approves that the bug is genuine and he
changes the state as “OPEN”.
3. Assign: Once the lead changes the state as “OPEN”, he assigns the bug to corresponding developer
or developer team. The state of the bug now is changed to “ASSIGN”.
4. FIXED: Once the developer fixes the bug, he has to assign the bug to the testing team for next round
of testing. Before he releases the software with bug fixed, he changes the state of bug to “TEST”. It
specifies that the bug has been fixed and is released to testing team.
5. Deferred: The bug, changed to deferred state means the bug is expected to be fixed in next releases.
The reasons for changing the bug to this state have many factors. Some of them are priority of the bug
may be low, lack of time for the release or the bug may not have major effect on the software.
6. Rejected: If the developer feels that the bug is not genuine, he rejects the bug. Then the state of the
bug is changed to “REJECTED”.
7. Duplicate: If the bug is repeated twice or the two bugs mention the same concept of the bug, then one
bug status is changed to “DUPLICATE”.
8. Verified: Once the bug is fixed and the status is changed to “TEST”, the tester tests the bug. If the bug
is not present in the software, he approves that the bug is fixed and changes the status to “VERIFIED”.
9. Re-Opened: If the bug still exists even after the bug is fixed by the developer, the tester changes the
status to “REOPENED”. The bug traverses the life cycle once again.
10. Closed: Once the bug is fixed, it is tested by the tester. If the tester feels that the bug no longer exists
in the software, he changes the status of the bug to “CLOSED”. This state means that the bug is fixed,
tested and approved.
Severity
What is Severity?
Defines Impact Level of the Defect on the System, the importance of defect with respect to functionality
point of view.
Severity Levels
• 1. Critical - The defect results in the failure of the complete software system, of a subsystem, or of a software unit
(program or module) within the system.
2. Major - The defect results in the failure of the complete software system, of a subsystem, or of a software unit
(program or module) within the system. There is no way to make the failed component's, however, there are
acceptable processing alternatives which will yield the desired result.
3. Average - The defect does not result in a failure, but causes the system to produce incorrect, incomplete, or

8. QA –Testing Material 8
www.TransformToIT.com Prepared By: A.B Reddy
inconsistent results, or the defect impairs the systems usability.
4. Minor - The defect does not cause a failure, does not impair usability, and the desired processing results are
easily obtained by working around the defect.
5. Exception - The defect is the result of non-conformance to a standard, is related to the aesthetics of the
system, or is a request for an enhancement. Defects at this level may be deferred or even ignored.
Priority
What is Priority?
Defines how soon the defect needs to be fixed as per business needs and priorities.
Priority Levels
1. Resolve Immediately - Further development and/or testing cannot occur until the defect has been repaired.
The system cannot be used until the repair has been effected.
2. Give High Attention - The defect must be resolved as soon as possible because it is impairing
development/and or testing activities. System use will be severely affected until the defect is fixed.
3. Normal Queue - The defect should be resolved in the normal course of development activities. It can wait until
a new build or version is created.
4. Low Priority - The defect is an irritant which should be repaired but which can be repaired after more serious
defect have been fixed.
5. Defer - The defect repair can be put of indefinitely. It can be resolved in a future major system revision or not
resolved at all.
Examples:
High priority and high severity: The application crashes whenever a person attempts to submit valid input on
the registration page.
High priority and low severity: The content entered in the Terms of Use are not correct and could potentially
lead to legal consequences.
High severity and low priority: A system crash is an example for high severity but suppose that occurs when
user enters extreme unrealistic Data, which isn’t happen in Production.
Ex: The application crashes whenever a person enters 1500+ chars in a “phone number” text box.
Low severity and low priority: There is a slight misspelling on one of the FAQ pages.

9. QA –Testing Material 9
www.TransformToIT.com Prepared By: A.B Reddy
Defect Metrics
• Cost of a defect : Total effort spent on Testing/Total no of defects
• Testing Efficiency : No. of test cases/No. of defects
• Defect Density : No. of defects per 1000 lines of code
• Defect Closure Rate : How much time takes to close a defect
Sample Defect:

10. QA –Testing Material 10
www.TransformToIT.com Prepared By: A.B Reddy