SOFTWARE

QUALITY
ENGINEERING
(SQE)
Test Case Development
1
 STLC -
2 SOFTWARE
TESTING LIFE
CYCLE PHASES
 Software Testing Life Cycle (STLC) is defined as a
sequence of activities conducted to perform Software Testing.
 Contrary to popular belief, Software Testing is not a just a
single activity. It consists of a series of activities carried out
methodologically which help to certify your software product.

3
 1) Requirement Analysis
 During this phase, test team studies the requirements
from a testing point of view to identify the testable
requirements.
 The QA team may interact with various stakeholders
(Client, Business Analyst, Technical Leads, System
Architects etc.) to understand the requirements in detail.
 Requirements could be either Functional (defining what
the software must do) or Non Functional (defining
system’s quality attributes )

4
 2) Test Planning
 Typically, at this stage, a Senior QA manager
determines effort and cost estimates for the project
and prepare and finalize the Test Plan.
 In this phase, Test Strategy is also determined.

5
 3) Test Case Development
 This phase involves the creation, verification and
rework of test cases & test scripts.
 Test data is identified/created and is reviewed and
then reworked as well.

6
 4) Test Environment Setup
 Test environment decides the software and hardware
conditions under which a work product is tested.

7
 5) Test Execution
 During this phase, the testers carry out the testing
based on the test plans and the test cases prepared.
 Bugs are to be reported back to the development
team for correction and retesting is performed.

8
 6) Test Cycle Closure
 Testing team meet, discuss and analyze testing
artifacts to identify strategies that have to be
implemented in the future, taking lessons from the
current test cycle.
 The idea is to remove the process bottlenecks for
future test cycles and share best practices for any
similar projects in the future.

9
 TEST
DOCUMENTATIO
10
N IN
SOFTWARE
TESTING
What is Test Documentation?
 Test documentation: In writing records of artifacts
created before or during the testing of software.
 It is a complete suite of documents that allow you to
describe and document test planning, test design,
test execution, test results that are drawn from the
testing activity.

11
 TEST
DOCUMENTATIO
12
N IN
SOFTWARE
TESTING
Metrics of Test Documentation
Testing
Description
Metric
It is a high-level document which describes principles,
Test policy methods and all the important testing goals of the
organization.
Test A high-level document which identifies the Test
strategy Levels/Types to be executed for the project.
A test plan is a complete planning document which
Test plan contains the scope, approach, resources, schedule, etc. of
testing activities.
Requireme
nts This is a document which connects the requirements to the
Traceability test cases and vice versa
Matrix

Test Test scenario is module or sub-module of a software system

13
Scenario which could be verified by one or more Test cases.
Testing
Description
Metric

It is a group of input values, execution preconditions,

Test Case expected execution post-conditions and results. It is
developed for a Test Scenario.

Test Data is a data which is used to execute the test

Test Data
case.

Defect report is a documented report of any flaw in a

Defect
Software System which fails to perform its expected
Report
function.

Test Test summary report is a high-level document which

Summary summarizes testing activities conducted as well as the
Report test result. It is also referred as Test Closure Report
14
15
WHAT IS TEST
SCENARIO?
What is Scenario Testing?
A Test Scenario is defined as any
functionality that can be tested. It is also
called Test Condition or Test Possibility.

16
17
WHAT IS TEST
SCENARIO?
Example: Test Scenario for e-commerce Application
 For an eCommerce Application, a few test scenarios would be
 Test Scenario 1: Check the Login Functionality

18
 Possible Test Cases against the Test Scenario 1 would be:
o TC_1.1: Check system behavior when valid email id and password is
entered.
o TC_1.2: Check system behavior when invalid email id
and valid password is entered.
o TC_1.3: Check system behavior when valid email id
and invalid password is entered.
o TC_1.4: Check system behavior when invalid email id
and invalid password is entered.
o TC_1.5: Check system behavior when email id and password are left
blank and Sign in entered.
o TC_1.6: Check Forgot your password is working as expected
o TC_1.7: Check system behavior when valid/invalid phone number
and password is entered.
o TC_1.8: Check system behavior when "Keep me signed" is checked
19
 Test Scenario 2: Check the Search Functionality

 Test Scenario 3: Check the Product Description Page

20
 Test Scenario 4: Check the Payments Functionality

21
 Test Scenario 5: Check the Order History

22
 Apart from these 5 scenarios here is the list of all other
scenarios
6. Check Home Page behavior for returning customers
7. Check Category/Product Pages
8. Check Customer Service/Contact Pages
9. Check Daily Deals pages

23
CLASS ACTIVITY 4: WRITE TEST
CASE FOR A TEST SCENARIO
 You can do it either individually or can make a group of 2-4
people.
 Tear a page out and write your course name and section,
complete ID, and full name on it.
 Statement: Visit Next Slide

24
CLASS ACTIVITY 4: WRITE TEST CASE FOR A TEST SCENARIO

 Statement: Identify two unique test cases against each

payment option mentioned in the GUI given below.
 Write Test case ID and Test Case Description only.

25
 CLASS ACTIVITY 4: SOLUTION
 For the payment method Credit Card:
 TC_1.1: Check the system behavior when radio button of credit
card is clicked and VISA card option is selected.
 TC_1.2: Check the system behavior when radio button of credit
card isn’t clicked and customer tries to select ‘master card’
option.
 For the payment method Debit Card:
 TC_1.3: Check the system behavior when radio button of debit
card is clicked and a valid card option is selected from the
dropdown list.
 TC_1.4: Check the system behavior when radio button of debit
card isn’t clicked and customer tries to select a valid card
option from dropdown list.
26
27
HOW TO WRITE
TEST CASES?
What is a Test Case?
Test Scenario Vs Test Case
 A Test Case is defined as a set of actions executed to verify a
particular feature or functionality of the software application.
 Test Scenario Vs Test Case
 For a Test Scenario like: Check Login Functionality, there are
many possible test cases:
 Test Case 1: Check results on entering valid User Id &
Password
 Test Case 2: Check results on entering Invalid User ID &
Password
 Test Case 3: Check response when a User ID is Empty &
Login Button is pressed, and many more……

28
 Let’s create a Test Case for the scenario: Check Login
Functionality

29
 Step 1) A simple test case for the scenario would be:

Test Test Case Description

Case ID
TC_1.1 Check the system behavior when valid email and password are
entered

30
 During test execution time, the tester will check expected
results against actual results and assign a pass or fail status.

Test Case Test Case Test Data Expected Actual Pass/Fail

ID Descriptio Result Result
n
TC_1.1 Check the Email: abc_ Login Login was Pass
system xyz@email. should be successful
behavior com successful
when valid Password:
email and lNf9^Oti7^
password 2h
are entered

31
 Your test case -may have a field like:
 Pre - Condition Preconditions define prerequisites that
must be met before the system can begin executing the test
case.
 For our test case, a pre-condition would be to the user must
have signed up.

32
 Your test case -may have a field like:
 A test case may also include Post - Conditions which
specifies anything that applies after the test case completes
successfully. Post-conditions can describe:
 Something observable to the user (in the case of ATM cash
withdrawal; the system displayed an account balance).
 Physical outcomes (the ATM has dispensed money and printed a
receipt).
 Internal system state changes (the account has been withdrawn
by the amount of a cash withdrawal, plus any transaction fee.

33
34
HOW TO WRITE
TEST CASES?
The format of Standard Test Cases
Test Test Test Steps Test Data Expected Actual Pass/Fail
Case ID Description Results Results
TC_1.1 Check the 1. Go to site: E-mail = User should As Pass
system http://demo.c abc_xyz@e Login into Expected
behavior when om mail.com an
valid email 2. Enter E- Password application
and password mail =
are entered pass_abc_
3. Enter
xyz
Password
4. Click
Submit
TC_1.2 Check the 1. Go to site E-mail= User should As Pass
system http://demo.c abc_xyz not Login Expected
behavior when om Password into an
invalid email 2. Enter E- = application
and password mail pass_abcx
are entered yz1212
3. Enter
Password
4. Click
This entire table may be created in Word, Excel or any other Test management tool. That's all
Submit 35
to Test Case Design
 TEST CASE
36
TEMPLATE
FORMATS
Test case fields and description
37
38
39
40
41
HOW TO WRITE
TEST CASES?
Best Practice for writing good Test Case
Test-Case Template Document
 1. Test Cases need to be simple and transparent
 2. Create Test Case with End User in Mind
 3. Avoid test case repetition
 4. Do not Assume
 5. Ensure 100% Coverage
 6. Test Cases must be identifiable
 7. Implement Testing Techniques
 8. Peer Review

 Test-Case Template Document

42
 WHAT IS
43 REQUIREMENTS
TRACEABILITY
MATRIX (RTM)?
 Requirement Traceability Matrix

It is a document that maps and traces user

requirement with test cases and vice versa.
 The main purpose of Requirement Traceability Matrix
is to see that all test cases are covered so that no
functionality should miss while doing Software
testing.

44
45
 WHAT IS
46 REQUIREMENTS
TRACEABILITY
MATRIX (RTM)?
Types of Traceability Matrix
 Forward Traceability: In ‘Forward Traceability’ Requirements
are mapped to the Test cases. It ensures that the project
progresses as per the desired direction and that every
requirement is tested thoroughly.

 Backward Traceability: The Test Cases are mapped with the

Requirements. Its main purpose is to determine that no extra
unspecified functionalities are added.

47
 Bi-Directional Traceability (Forward + Backward): A
Good Traceability matrix has references from test cases to
requirements and vice versa (requirements to test cases). This
is referred to as ‘Bi-Directional’ Traceability. It ensures that all
the Test cases can be traced to requirements and each and
every requirement specified has accurate and valid Test cases
for them.

48
 WHAT IS
49 REQUIREMENTS
TRACEABILITY
MATRIX (RTM)?
How to create Requirement Traceability Matrix?
 Let's understand the concept of Requirement Traceability
Matrix through a Online Banking Project.
 Let suppose, the following table is our Business Requirement
Document or BRD for online banking project.

 Here the scenario is that the customer as well as

manager shall be able to login to the banking website
with the correct password and user id through login
page.

50
51
 While the below image is our Technical Requirement
Document (TRD).

 Let's Go Ahead and create RTM in Testing

 Step 1: Our sample Test Case is:
 "Verify Login, when correct ID and Password is entered, it
should log in successfully"

52
 Step 2: Identify the Technical Requirement that this test case
is verifying. For our test case, the technical requirement is T94
is being verified.

 Step 3: Note this Technical Requirement (T94) in the Test

Case.

53
 Step 4: Identify the Business Requirement for which this TR
(Technical Requirement-T94) is defined.

 Step 5: Note the BR (Business Requirement) in Test Case

 Step 6: Do above for all Test Cases. RTM in testing is Ready!

54