Software Testing Life Cycle

(STLC)-01
By
MadhukarQAIT
• Agenda:
• What is STLC?
• Phases in STLC?
• Testing team hierarchy?
• Testing Life cycle phases w. r. to Development activities
• STLC:
• STLC stands for Software (System) Testing Life Cycle
• STLC describes end to end activities performed by separate testing team to
accomplish testing activities for a project
• Whereas STLC is one of the activity in SDLC
Note:
Lifecycle: The sequence of changes from one form to other forms
• Following are the phases involved in STLC
• 1. Test Initiation
• 2. Test Planning
• 3. Test Design/Test Case Design
• 4. Test Execution
• 5. Defect Reporting & Defect Tracking
• 6. Test Closure
• Testing Team hierarchy:
• S/w Test Engineer (STE/SDET) (0 to 3 Yrs of Exp.)
• Senior Software Test Engineer (SSTE) (3 to 6 Yrs)
• Test Lead (TL) (7 to 10 Yrs. )
• Test Manager (TM) ( 12+ Yrs. )
• Testing process:
 STLC part-02
1. Test Initiation
- Project Management Plan
- Test Strategy doc

By
MadhukarQAIT
• STLC:
• STLC describes end to end activities performed by separate testing team to accomplish testing activities for a
project
• Following are the phases involved in STLC
• 1. Test Initiation
• 2. Test Planning
• 3. Test Case Design
• 4. Test Execution
• 5. Defect Reporting & Defect Tracking
• 6. Test Closure
• 1. Test Initiation:
• After getting a new project for testing (i.e. Agreements are completed(SOW)), then TM will initialize
testing activities by analyzing following factors:
• i. Application Analysis: using requirement doc. (BRS & FRS) application functionalities will be
analyzed
• ii. Risk Analysis: possible Risks at test environment will be analyzed
• In general there are 4 types of risks at Test environment, they are
• Resource Risk: availability of TE’s for a project
• Technology Risk: problems which are related to H/w and S/w
• Scheduled Risk: factors which may effect scheduled activities will be analyzed
• Support Risk: availability of clarification team for TE’s
• iii. Efforts Estimation:
• Based on size of project/function points TM will analyze required Time, Resources and cost to
validate application
• After analyzing those factors TM will prepare Project Management Plan
and Test Strategy document
• **A project management plan:
• It is a formal & approved document that defines how the project is
executed, monitored and controlled while testing the project
• **Test Strategy doc:
• It is a high level test document which is prepared early stages of
testing
• *It describes brief description about testing approach, available
resources and standards to be followed during testing w. r. to Organization
• Information in test strategy will be uniform throughout the project (i.e.
static doc
 STLC-part3
2. Test Planning
-Test Plan doc.
By
MadhukarQAIT
• Agenda:
• Who is responsible for Test Planning?
• What is Test Plan doc?
• Components in Test Plan document?
• What are the responsibilities of Test Lead?
• Test Planning:
• During this phase Test Lead along with the some sr. members in a project
will be involving to design the test plan doc
• Test Plan doc prepared based on the scope of current release
• Information in Test Plan will be changes based on CR received from client
(i.e. Dynamic Doc)
• What is Test Plan doc?
• **Test Plan describes the scope, approach, resources and schedule of testing
activities.
• It identifies test items, the features to be tested, the testing tasks, required test
environment, who are responsible and any risk and mitigations…etc.
• In simple TP defines what to test?, how to test?, who to test? And when to test?.
• This document is in the format of word which is available in share point
• **For successful S/w testing a clear Test plan doc is an essential
• Components in Test Plan doc:
• 1. Title: name of the project
• Ex: HDFC bank system test plan v1.0
• 2. History of the TP Doc:
• It describes author of TP, Reviewed by, Reviewed on, Type of modification, Approved by…
etc.
• 3. Introduction:
• i. Project Overview: It defines the brief description about the project , that means for which
project we are designing test plan doc
• ii. Purpose of TP:
• It describes objective or intension of Test plan doc
• iii. Referred Doc: describes inputs to prepare Test plan doc
• Ex: BRS and FRS
• 4. **Scope:
• a. In scope: it describes possible testing activities under current test plan doc
• Ex: functionality testing, UI testing, usability testing, compatibility testing…etc
• b. Out of Scope: it describes testing activities which are not covered under current test plan
• Ex: Unit testing, Integration testing, performance testing..etc 
•  5. Features to be tested:
• It defines the features or functionalities which we need to test in the project in current release
• Ex: Admin module
• 6. Features not to be tested:
• It defines the features or functionalities which we need not to test in the project in current release
• It depending on the out of scope knowledge
• Ex:
• As per the client requirement we need to test 150 requirements in an application out of 200 requirements in
current release. In that case we need to specify the requirements which we need to test in the current release
in features to be tested and requirements which we need not to be test which will be specify that features not
to be tested
• Ex: Banker module and Customer module
• 7.**Entry and Exit Criteria:
• a. Entry Criteria: it describes when to perform Test execution(i.e. Dynamic testing)
• Following are the factors we consider in Entry Criteria:
• All the Test cases are prepared and Reviewed
• Build should deployed at Test Environment staging server
• Build should passed BVT (i.e. Build is stable)
• Test Environment set-up provided
• **b. Exit Criteria: it describes when to close testing for a project
• Following are the factors will be considered in Exit criteria:
• All the Test cases should be executed at least once
• Certain percentage of TC’s should be passed like 90-95%
• Defects which are identified those status either “Closed” or “Deferred”
• Defects ratio less than acceptance level
• Budget and time constrains when overflows
• When UAT is completed and client satisfied
• After analyzing above factors, if majority of the factors are satisfied then TL along with TM will stop testing
activities for that project
• **8. Suspension and Resumption criteria:
• a. Suspension Criteria:
• It defines when to suspend the testing activities in a project
• In following scenarios we can suspend Test cases execution
• When build failed in Build Acceptance Test
• When there is a Change Request from client
• When we identified Showstopper/Critical/Fatal defect
• Environment issues (Application is not opening, Application is not closing…etc)
• Exceptions (Java Exception Error, null pointer exception error, page not found error…etc)
• Application crashes (Application suddenly closing, application is hanging …etc
• b. Resumption Criteria: it describes when we can resumed/continue Test execution
• Ex:
• When patch file released for rejected build
• When Requirements are refined and base-lined based on CR acceptance or rejection
• When critical defects got fixed
• When environment issues got resolved
• When exceptions got cleared
• When application crashes got resolved
• 9. Testing approach:
• It defines the testing types which we need to perform in the project in current release
• Ex:
• UI testing  to verify Look-N-Feel of application
• Usability testing To verify user friendliness of application
• Functionality testing  to verify functional behavior
• Note:
• The testing types which we are performing will be different from one application to another
• Compatibility testing and performance tastings are mandatory for web based applications but not required for windows
based applications
• It describes required testing techniques in order to validate test factors in application
• 10. Test Environment:
• It is also called as Test Bed
• A testing environment is a setup of software and hardware for the testing
teams to execute test cases. In other words, it supports test execution with
hardware, software and network configured.
• 11. Roles and Responsibilities:
• It defines the resources (Employees) who is working in the project resources includes offshore team, onshore
team, BA team, Project manager and client
• Ex: Resources
• It describes name of the TE’s and allocated Task
• Offshore : 30
• Onshore: 1
• BA: 3
• PM:
• Client
• 12. Schedule:
• It describes timelines to perform each testing activity
• ** 13. Risks and mitigations:
• It describes possible problems at test environment and solutions for those
problems
• Ex: sometimes application may not accessible from staging server they
provide Network team information
• **14. Test Deliverables:
• It describes documents which we need to prepare during testing in order to deliver for a
client at end of testing
• Ex:
• Test cases review Report
• Test summary Report
• Test Execution report
• Defect profiles
• 15. Training Needs:
• It describes required training sessions for associated TE’s for a project (i.e.
KT’s)
• After preparation of Test Plan document, TL will conduct review on TP
along with some of the Sr. TE’s, if TP is finalized then that will be
delivered to all the associated TE’s for a project
 STLC-part4
5. Test Design/TC Design-1
- Test case
-Use Case
-Test Scenarios
By
MadhukarQAIT
• Agenda:
• What is Test Case?
• What is Use Case?
• What is Test Scenario?
• Difference among the Use Case, Test Scenario and Test case?
• Test Case:
• A TC describes validation procedure of a specific requirement in
application
• A TC consist set of steps or sequence of steps with user actions and
subsequent response from the system
• In general after necessary training sessions (i.e. KT’s) TE’s are the
responsible to prepare test cases
• Inputs to prepare test cases:
i. Requirement documents like BRS & FRS
ii. Use Case doc
iii. UI Design doc
iv. Test Scenarios
• What is Use Case?
• Use Case describes functional behaviour from users prospective in terms
of “Actors action” and “System response”
• It is an optional document, whenever requirements are not clear or
complex then only we will get use case doc
 Use case for “Create new Branch by an
Administrator”
Actor Action System Response
1. Actor login 2. System displays Admin module
3. Actor select Branches 4. System Displays Branches details page
5. Actor clicks new Branch 6. System Displays “New Branch” Entry page
7. Actor Enters necessary fields with valid data 8. System displays a message “New Branch
and clicks Submit Created successfully with Branch ID” with “Ok”
Button

9. Actor enters necessary fields with valid data 10. System clears all fields.
and clicks Reset.
11. actor enters necessary fields with valid data or 12. System closes the new branch entry page and
with out entering any fields clicks Cancel displays branches details page.
 GUI/UI Design doc:

• It contains model of the application (i.e. Prototypes/Blueprint)

• Prototypes will help to foresee the future implementation of the
application
• What is Test Scenarios:
• It describes a Test Condition or Requirement or functionality which we need to
validate in application
• A Test Scenario can have one or more number of test cases
• Advantages of TS:
• Based on Test scenarios we can able to identify possible number of test cases need to
be drafted
• With help of test scenarios we can provide complete test case coverage for a project
 ***Difference among the Use case, Test
Scenario and Test case
Use Case Test Scenario Test Case
It describes functional behavior It describes Test condition or It describes validation procedure
from users point of view Requirements which we need to of specific requirement in
validate Application

How system need to work? Which we need to Test? How we need to test?
• Website: www.madhukarqait.com
• Mail Id: [email protected]
• YouTube Channel: MadhukarQAIT
 STLC-part5
5. Test Design/TC Design-2
-What is Test Scenario?
-Identifying Test Scenarios based on
-Prototypes
-use case doc
-Requirements By
MadhukarQAIT
• Agenda:
• What is Test Scenario?
• Advantages of Test scenarios
• How to identify Test scenarios based on
• Requirements
• Use case
• Prototypes
• What is Test Scenarios:
• It describes a Test Condition or Requirement or functionality which we need to
validate in application
• A Test Scenario can have one or more number of test cases
• Advantages of TS:
• Based on Test scenarios we can able to identify possible number of test cases need to
be drafted
• With help of test scenarios we can provide complete test case coverage for a project
• Who will identify Test scenarios?
• In general TL will identify Test scenarios, but sometimes he may ask TE’s also to
identify test scenarios
• Q: Is that test scenarios are mandatory for a project?
• No, some projects without Test scenarios directly we prepare test cases if that
project developing in Agile scrum methodology
• As per standards for medium and large projects Test scenarios will be identified
then only we can prepare test cases
• Types of Test scenarios:
• In general we identify 3 types of Test scenarios for a project, they are
• 1. GUI/UI related Test scenarios
• 2. Usability related Test scenarios
• 3. Functionality related Test scenarios
 STLC-part6
3. Test Design/TC Design-04
TC Template with Real-time
implementation
By
MadhukarQAIT
• Agenda:
• About TC Template
• Components in TC Template?
• What is Priority in TC?
• How to provide priority for a TC?
• How to write Real-time TC using TC Template
• Test Case Template:
• In general every Organization will maintain their own template to derive
test cases
• Template means which have some pre-defined components
• Following are the components in TC template:
• 1. Project: name of the project
• 2. Module: name of the module
• 3. Created By: author of test cases (i.e. TE name)
• 4. Created On: on which date TC’s are prepared
• 5. Reviewed By: name of the person who is responsible to conduct review on TC’s
• 6. Reviewed on: on which date review conducted on TC’s
• 7. Referred Doc: I/p to derive test cases
• 8. TC ID/Name: name of the TC which should be unique for entire project
• Syntax:
• TC01_ProjectName_ModuleName_FunctionalityName
• 9. TC Description: it describes purpose or core-intension of the Test case
• 10. **Priority:
• *Priority defines importance of the TC during execution
• *Priority derived based on importance/criticality of the functionality w. r. to client business needs
• There can be 3 levels of priorities
• High (P0) {frequently used functionalities}
• Medium (P1) {sometimes only used functionalities}
• Low (P2) {rarely used functionalities}
• 11. Step Name: it describes number of steps in a TC
• A TC may have one or more steps
• Ex: Step 1, step 2….
• 12. Step Description: it describes user operation to be performed on AUT during Test execution
• 13. Test Data: it describes data or values which we use to validate application
• Note:
• Some test cases, Test data is not mandatory
• 14. Expected Result: it describes expected behavior of the application w. r. to user operation
• Expected result will be drafted from user Requirements (i.e. FRS)
• Note:
• in general a Step in a TC should describe at least one user operation and subsequent response
from the system
• 15. Actual Result: it describes Actual behavior of AUT/SUT
• Actual Result will be drafted from AUT
• 16. Status: it describes step status in terms of Pass/fail
• Note:
• Actual Result and Step status we provide during test execution
Requirements Traceability
Matrix (RTM/TM)
By
MadhukarQAIT
• Agenda:
• Review on TC’s?
• What is RTM?
• Components in RTM
• How to prepare RTM with practical example
• TC’s Review:
• After preparation of Test cases, review will be conducted to check
correctness and completeness of the Test cases in order to validate
application
• **Requirements Traceability Matrix (RTM/TM):
• **Using RTM we can identify all the requirements are covered or not with
written Test cases
• In general TC doc. alone is difficult to understand all the requirements are
covered or not, with written test cases
• RTM can be prepared by mapping each test case to the corresponding Test
Scenario/Requirement in Excel sheet or in Quality Center
• RTM can be prepared by TL/TE
• Components in RTM:
• Requirement ID
• Test scenarios
• TC ID/Name
• TC Description
• TS  Test Scenario
• TC  Test case
• Tower network Coverage
• Ex:
• Create RTM for “Employee Search” page
• Subscribe My YouTube channel: MadhukarQAIT
• Contact Mail ID: [email protected]