0% found this document useful (0 votes)
20 views99 pages

STE Output Pract 1

STE output pract 1 (1)
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
20 views99 pages

STE Output Pract 1

STE output pract 1 (1)
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 99

lOMoARcPSD|34814445

lOMoARcPSD|34814445

Experiment No: 02
Title of Experiment Design test cases for purchase order management based on system specification.

Q. Design Test Case for Inventory Management System based on System


Specification.

Test Test Case Actual Input Expected Actual Status


Case ID Name Output Output

TC_01 Mobile Mobile Number = It should not It is not pass


Number "abcdefghij" accept the data. accepting
the data.

TC_02 Mobile Mobile Number It should accept It is pass


Number ="1234567890" thedata. accepting
the data.

TC_03 Email Email Address = It should not It is not pass


Address "[email protected] accept the data. accepting
m" the data.

TC_04 Email Email Address It should accept It is pass


Address ="[email protected] thedata. accepting
om" the data.

Downloaded by Deep Patel


lOMoARcPSD|34814445

TC_05 Quantity Quantity = "ab" It should not It is not pass


accept the data. accepting
the data.

TC_06 Quantity Quantity = "05'" It should accept It is pass


the data. accepting
the data.

TC_07 Email Email Address It should not It is not pass


Address ="abc@pqrs" accept the data. accepting
the data.

TC_08 Mobile Mobile Number = It should not It is not pass


Number "123456780" accept the data. accepting
the data.

TC_09 Quantity Quantity = "123" It should not It is not pass


accept the data. accepting
the data.

TC_10 Quantity Quantity = "0" It should not It is not pass


accept the data. accepting
the data.

Downloaded by Deep Patel


lOMoARcPSD|34814445

Downloaded by Deep Patel


lOMoARcPSD|34814445

Experiment No: 03 DEPARTMENT OF COMPUTER


Title of Experiment ENGINEERING
Design test cases for a Calculator to verify its function.

Q. Design test cases for a Calculator to verify its function.

Test Test Case Name Actual Input Expected Actual Output Stat
Case Output us
ID

TC_01 Number Input "123467891234567 Take input Takes input Pass


" Successfully Successfully
TC_02 Number Input "123467891234567 Do not take Does not take Pass
891234" input input

TC_03 Arithmetic Add " 50 + 50 " " = 100 " " = 100 " Pass
operation
(Addition)
TC_04 Arithmetic Add " 0 + 0 " "=0" "=0" Pass
operation
(Addition)
TC_05 Arithmetic Add " "= "= Pass
operation 123456789123456 1,23,45,67,89,12 1,23,45,67,89,12
(Addition) 7+ ,34,567 " ,34,567 "
123456789123456
7"
TC_06 Arithmetic Sub " 50 - 50 " "=0" "=0" Pass
operation
(Subtraction)
TC_07 Arithmetic Mul " 50 * 50 " " = 2500 " " = 2500 " Pass
operation(Multip
lication)

Downloaded by Deep Patel


lOMoARcPSD|34814445

TC_08 Arithmetic Mul " 50 * 0" "=0" "=0" Pass


operation(Multip
lication)
TC_09 Arithmetic Div " 50 / 50 " "1" "1" Pass
operation
(Division)
TC_10 Arithmetic Div " 0 /5 0 " "0" "0" Pass
operation
(Division)
TC_11 Arithmetic Div " 50 / 0 " Display "Cannot Displays "Cannot Pass
operation Divide By Zero" Divide By Zero"
(Division)

TC_12 Scientific " sin 90 " "1" "1" Pass


operation (Sin)
TC_13 Scientific " cos 0 " "1" "1" Pass
operation (Cos)
TC_14 Scientific " tan 45 " "1" "1" Pass
operation (Tan)
TC_15 Scientific "π" " " Pass
operation (π) 3.14159265359 3.14159265359
" "

TC_16 Negative and " 2 + 2 + (-2) +(-2) " "0" "0" Pass
Positive
TC_17 Negative and " 2 - 2 - (-2) " "2" "2" Pass
Positive
TC_18 Negative and "-2-2" " -4 " " -4 " Pass
Negative
TC_19 Negative and " 2 - 2 - (-2) " "2" "2" Pass
Positive

TC_20 Logarithm " Log2 8 " "3" "3" Pass


TC_21 Trigonometry " sin 0 + cos 90 " "1" "1" Pass
TC_22 Trigonometry " sin 90 + cos 0" "1" "1" Pass
TC_23 Trigonometry " sin 0 + tan 0 " "0" "0" Pass
TC_25 Trigonometry " cos 0 + tan 0 " "1" "1" Pass

Downloaded by Deep Patel


lOMoARcPSD|34814445

Downloaded by Deep Patel


lOMoARcPSD|34814445

Experiment No: 04 DEPARTMENT OF COMPUTER


Title of Experiment ENGINEERING
Test various functionality of railway reservation system.

Test Test Case Actual Input Expected Actual Output Status


Case Name Output
ID
TC_01 Username " Username = It should accept It accepted the Pass
tanmay6626 " the data data
TC_02 Password " Password It should accept It accepted the Pass
=Tanmay6626 " the data data
TC_03 Confirm " Confirm Password = It should accept It accepted the Pass
Password Tanmay6626 " the data data
TC_04 First Name " First Name = Tanmay It should accept It accepted the Pass
" the data data
TC_05 Middle " Middle Name It should accept It accepted the Pass
Name =Rajesh " the data data
TC_06 Last Name " Last Name = Thakur It should accept It accepted the Pass
" the data data
TC_07 Date of " Date of Birth = It should accept It accepted the Pass
Birth 11/12/2000 " the data data
TC_08 Gender Click on Male It should accept It accepted the Pass
the data data
TC_09 Mobile " Mobile Number = It should accept It accepted the Pass
Number 9821006626 " the data data
TC_10 Email ID " Email ID = It should accept It accepted the Pass
[email protected] the data data
m"
TC_11 Next Button Click on Next Button It should go to It is going to Pass
and fill all details next page of next page of
Registration and Registration and
Send OTP on sends OTP on
Mail ID and Mail ID and
Phone Number Phone Number

TC_12 Username " Username = It should accept It accepted the Pass

Page | 1

Downloaded by Deep Patel


lOMoARcPSD|34814445

tanmay6626 " the data data


TC_13 Password " Password It should accept It accepted the Pass
=Tanmay6626 " the data data
TC_14 Login Click on Login Button It should go It is going to Pass
Button to next page next page and
and ask for asking for OTP
OTP
TC_15 Mobile OTP " Mobile OTP = It should accept It accepted the Pass
269591" the data data
TC_16 Email OTP " Email OTP = 956438 It should accept It accepted the Pass
" the data data
TC_17 Verify User Click on Verify User It should It is prompting Pass
prompt Congratulation’s
Congratulation’s dialog box
dialog box and logged in
log in
TC_18 Plan my Click on Plan my It should go to It is going to Pass
Journey Journey next page next page
TC_19 From Click on From Button It should go It is going to Pass
Button to next page next page and
and show Showing search
Search station
Station

TC_20 Search " Search Station = It should It accepted Pass


Station Mumbai Central accept the data the data and
(MMCT) " and go to going to
(Search (Search
Station) section Station) section
TC_21 Search " Search Station = It should accept It accepted the Pass
Station Delhi (DLI) " the data and go data and going
to Plan my to Plan my
Journey page Journey page
TC_22 Date Click on First date It should show a It is showing the Pass
section and click on calendar calendar
select Date
TC_23 Date Click on second date It should show a It is showing the Pass
section and click on calendar calendar
select date
TC_24 Search Train Click on Search Train It should go to It is going to Pass
Button Button next page and next page
show all and showing
available train all available
train
TC_25 Train Select any available It should It is showing Pass
selection train and select availability of availability of
Sleeper coach seats and book seats and book
now option now option
TC_26 Class Select any suitable It should go to It is going to Pass
selection class and Click Book next page and next page and
now get confirmation getting
Downloaded by Deep Patel
lOMoARcPSD|34814445

Page | 2

Downloaded by Deep Patel


lOMoARcPSD|34814445

of booking from conformation


user from user

TC_27 Add Click on Add It should go to It is going to Pass


Passenger Passenger Button next page next page
Button
TC_28 Name " Name = Tanmay " It should accept It accepted the Pass
the data data
TC_29 Age " Age Between 05 to It should accept It accepted the Pass
Between 05 125 = 18 " the data data
to 125
TC_30 Gender Click on Male It should accept It accepted the Pass
the data data
TC_31 Select Birth " Select Birth It should accept It accepted the Pass
Preference Preference = SIDE the data data
UPPER "
TC_32 Select " Select Concession It should accept It accepted the Pass
Concession Type = General " the data data
Type
TC_33 Done Click on Done It should go to It is going to Pass
confirmation confirmation
page page
TC_34 Edit Click on passenger It should go to It is going to Pass
Passenger edit page edit page
TC_35 Age " Age Between 05 to It should accept It is showing Pass
Between 05 125 = 65 " the data and Option for
to 125 show Option for Senior Citizen
Senior Citizen Concession
Concession
TC_36 Option for Select any Concession It should accept It is accepting Pass
Senior type the data the data
Citizen
Concession

Page | 3

Downloaded by Deep Patel


lOMoARcPSD|34814445

Page | 5

Downloaded by Deep Patel


lOMoARcPSD|34814445

Experiment No:
Title of Experiment
05 DEPARTMENT OF COMPUTER
Validate login procedure for E-Commerce application
ENGINEERING
Test Test Case Actual Input Expected Output Acutal Output Statu
Case Name s
TC_01 Mobile Mobile Number Invalid Mobile Invalid Mobile Pass
Number = "abcd" Number Number
Registration
TC_02 Mobile Mobile Number Invalid Mobile Invalid Mobile Pass
Number = "123" Number Number
Registration
TC_03 Mobile Mobile Number Invalid Mobile Invalid Mobile Pass
Number = "' .';''/ " Number Number
Registration
TC_04 Mobile Mobile Number Invalid Mobile Invalid Mobile Pass
Number = "9372973" Number Number
Registration
TC_05 Mobile Mobile Number Valid Mobile Valid Mobile Pass
Number = Number Number
Registration "9372973077"

TC_05 OTP 1 Invalid OTP Invalid OTP Pass


Verification
TC_06 OTP 123 Invalid OTP Invalid OTP Pass
Verification
TC_07 OTP '.';''/ Invalid OTP Invalid OTP Pass
Verification
TC_08 OTP 123456789 Invalid OTP Invalid OTP Pass
Verification
TC_09 OTP abcd Invalid OTP Invalid OTP Pass
Verification

Downloaded by Deep Patel


lOMoARcPSD|34814445

TC_10 OTP 3720 Valid OTP Valid OTP Pass


Verification

TC_10 Search Bar Search Bar = Could not find any Could not find any Pass
"12345678" matches matches
TC_11 Search Bar Search Bar = Could not find any Could not find any Pass
"@,./;'[]" matches matches
TC_12 Search Bar Search Bar = Should not search Does not search Pass
"Blank Space" anything anything
TC_13 Search Bar Search Bar = Display all the Displays all the items Pass
"a" items containing containing letter 'a'
letter 'a'
TC_14 Search Bar Search Bar = Display all the Display all the shirts Pass
"Shirt" shirts

TC_14 Filter Filter = "Men" Display all the men Displays all the men Pass
relaed items relaed items
TC_15 Filter Filter = Display all the Displays all the Pass
"Categories = Tshirts Tshirts
Tshirts"
TC_16 Filter Filter = Display no output Displays no output Pass
"Categories =
126354"
TC_17 Filter Filter = Display no output Displays no output Pass
"Categories =
';.[@"

Downloaded by Deep Patel


lOMoARcPSD|34814445

Experiment No: 06
Title of Experiment Testing Functionality of Web page

Downloaded by Deep Patel


lOMoARcPSD|34814445

Exercise:

1. Prepare the test case to test your college website for any 5 links.
2. Execute the above test case created in question 1 by performing
appropriate operations and verify result.

Test Test Case Actual Input Expected Output Acutal Output Status
Case Name
TC_01 Home > Click on It should redirect to It redirects to Pass
Academics Computer Computer Compute r
Engineering Engineering page Engineering page Pas
TC_02 Home > Click on First It should redirect to It redirects to First Pass
Computer Year Syllabus First Year Syllabus Year Syllabus page
Engineering page
> First Year
Syllabus
TC_03 Home > Click on Second It should redirect to It redirects to Pass
Computer Year Syllabus Second Year Second Year
Engineering Syllabus page Syllabus page
> Second
Year
Syllabus
TC_04 Home > Click on Third It should redirect to It should redirect to Pass
Computer Year Syllabus Third Year Syllabus Third Year Syllabus
Engineering page page
> Third Year
Syllabus
TC_05 Home > Click on It should redirect to It redirects to Pass
Academics Electrical Electrical Electrical
Engineering Engineering page Engineering page
TC_06 Home > Click on First It should redirect to It redirects to First Pass
Electrical Year Syllabus First Year Syllabus Year Syllabus page
Engineering page
> First Year
Syllabus
TC_07 Home > Click on Second It should redirect to It redirects to Pass
Electrical Year Syllabus Second Year Second Year
Engineering Syllabus page Syllabus page
> Second
Year
Syllabus

Downloaded by Deep Patel


lOMoARcPSD|34814445

TC_07 Home > Click on Third It should redirect to It should redirect to Pass
Electrical Year Syllabus Third Year Syllabus Third Year Syllabus
Engineering page page
> Third Year
Syllabus
TC_08 Home > Click on It should redirect to It redirects to Pass
Academics Information Information Information
Technology Technology page Technology page
TC_09 Home > Click on First It should redirect to It redirects to First Pass
Information Year Syllabus First Year Syllabus Year Syllabus page
Technology page
> First Year
Syllabus
TC_10 Home > Click on Second It should redirect to It redirects to Pass
Information Year Syllabus Second Year Second Year
Technology Syllabus page Syllabus page
> Second
Year
Syllabus
TC_11 Home > Click on Third It should redirect to It should redirect to Pass
Information Year Syllabus Third Year Syllabus Third Year Syllabus
Technology page page
> Third Year
Syllabus
TC_12 Home > Click on It should redirect to It redirects to Pass
Student Life Student Life Student Life page Student Life page
TC_13 Home > Click on It should redirect to It redirects to Pass
Placement Placement Placement page Placement Page
page
TC_14 Home > Click on Online It should redirect to It redirects to Online Pass
Online Payment Online Payment Payment Page
Payment page
page
TC_15 Home > Click on Latest It should redirect It redirects to Latest Pass
Latest Updates to Latest Updates Updates Page
Updates page
page
TC_16 Home Click on Project It should redirect to It redirects to Project Pass
>Project Outline Project Outline Outline Page
Outline page page
TC_17 Home > Click on Who It should redirect to It redirects to Who Pass
Who are we are we Who are we page are we Page
page

Downloaded by Deep Patel


lOMoARcPSD|34814445

TC_18 Home > Click on Alumni It should redirect to It redirects to Alumni Pass
Alumni page Alumni page Page
TC_19 Home > Click on It should redirect to It redirects to Pass
Contact Us Contact Us Contact Us page Contact Us Page
page
TC_20 Home > Click on Notice It should redirect to It redirects to Notice Pass
Notice Board Notice Board page Board Page
Board page

3. Prepare test case for any website which sends OTP on your email
address/ mobile number.
Test case for any GitHub Sign up

Test Test Case Actual Input Expected Output Acutal Output Statu
Case Name s
TC_0 Email anuragDubey Should not allow Does not Pass
1 Email allow Email
TC_0 Email 451224 Should not allow Does not Pass
2 Email allow Email
TC_0 Email [email protected] Should allow Email Does allow Pass
3 m Email
TC_0 Usernam anruag Display ‘Not Displays ‘Not Pass
4 e available’ available’
TC_0 Usernam 1224 Display ‘Username Displays Pass
5 e should include ‘Username
alphabets, should
numbers’ include
alphabets,
numbers’
TC_0 Usernam anruag=3933 Should allow Does allow Pass
6 e username username
TC_0 Password 1234 Display ‘Enter Displays Pass
7 strong password’ ‘Enter strong
password’
TC_0 Password password@123 Should allow Does allow Pass
7 password password
TC_0 Continue Click on Continue Should accept all Does accept Pass
8 the data and all the data
redirect to email and redirect
verification page to email

Downloaded by Deep Patel


lOMoARcPSD|34814445

verification
page
TC_0 OTP 0000 Display ‘Invalid Displays Pass
9 OTP’ ‘Invalid OTP’
TC_1 OTP 5461 Should redirect to Does redirect Pass
0 home page of to home page
github of github

Downloaded by Deep Patel


lOMoARcPSD|34814445

Experiment No: 07
Title of Experiment Design test case for control and decision making statements.

Downloaded by Deep Patel


lOMoARcPSD|34814445

1. Can we test the relational operator? Validate your answer


with justification.
Answer: Yes, we can test the relational operators.
Examle:
Code:
import java.util.Scanner;
public class Test {
public static void main(String[] args) {
Scanner sc = new Scanner(System.in);
System.out.print("Enter first
number: "); int a = sc.nextInt();
System.out.print("Enter second
number: "); int b = sc.nextInt();
if (a > b) {
System.out.println(a + " is greater than " + b);
} else {
System.out.println(b + " is greater than " + a);
}
sc.close();
} }

Test case:

Test Test Case Actual Input Expected Output Actual Output Status
Case Name
TC_01 Greater a = 10 20 is greater than 20 is greater than Pass
than b = 20 10 10
TC_02 Greater a = 30 30 is greater than 30 is greater than Pass
than b = 20 20 20

Downloaded by Deep Patel


lOMoARcPSD|34814445

Exercise:

1. Generate the test case to check the program written for Even and
Odd numbers.
Code:
import java.util.Scanner;

public class Test {


public static void main(String[] args) { Scanner sc = new Scanner(System.in);

System.out.print("Enter a number: "); double a = sc.nextDouble();

if (a % 2 == 0) {
System.out.println(a + " is an Even Number");
} else {
System.out.println(a + " is an Odd Number ");
}

sc.close();
}

Test case:

Test Test Case Actual Input Expected Output Actual Output Status
Case Name
TC_01 Even or Odd Enter a 12 is an Even 12 is an Even Pass
number:12 Number Number
TC_02 Even or Odd Enter a 13 is an Odd 13 is an Odd Pass
number: 13 Number Number

Downloaded by Deep Patel


lOMoARcPSD|34814445

2. Execute above test case in Question 1 by entering following inputs


and verify results.
Input – 4, 7, 2.5, 8.1

Test case:

Test Test Case Actual Input Expected Output Actual Output Status
Case Name
TC_01 Even or Odd Enter a 4 is an Even 4 is an Even Pass
number:4 Number Number
TC_02 Even or Odd Enter a 7 is an Odd 7 is an Odd Pass
number: 7 Number Number
TC_03 Even or Odd Enter a 2.5 is an Odd 2.5 is an Odd Pass
number: 2.5 Number Number
TC_04 Even or Odd Enter a 8 is an Even 8 is an Even Pass
number: 8 Number Number
TC_05 Even or Odd Enter a 1 is an Odd 1 is an Odd Pass
number: 1 Number Number

Downloaded by Deep Patel


lOMoARcPSD|34814445

3. Generate the test case to check the program written for printing the day
of week

import java.util.Scanner;

public class Test {


public static void main(String[] args) { Scanner sc = new
Scanner(System.in);

System.out.print("Enter a number: "); int weekday = sc.nextInt();

switch (weekday) { case 1:


System.out.println("Monday"); break;
case 2:
System.out.println("Tuesday");
break; case 3:
System.out.println("Wednesday"); break;
case 4:
System.out.println("Thursday"); break;
case 5:
System.out.println("Friday"); break;
case 6:
System.out.println("Saturday"); break;
case 7:
System.out.println("Sunday"); break;
default:
System.out.println("Please enter weekday number between 1-
7.");
}
sc.close();
}}

Downloaded by Deep Patel


lOMoARcPSD|34814445

Test case:

Test Test Case Actual Input Expected Output Actual Output Status
Case Name
TC_01 Day of Enter a Monday Monday Pass
week number: 1
TC_02 Day of Enter a Tuesday Tuesday Pass
week number: 2
TC_03 Day of Enter a Wednesday Wednesday Pass
week number: 3
TC_04 Day of Enter a Thursday Thursday Pass
week number: 4
TC_05 Day of Enter a Friday Friday Pass
week number: 5
TC_06 Day of Enter a Saturday Saturday Pass
week number: 6
TC_07 Day of Enter a Sunday Sunday Pass
week number: 7
TC_08 Day of Enter a Please enter Please enter Pass
week number: 0 weekday weekday number
number between 1-7.
between
1-7.
TC_09 Day of Enter a Please enter Please enter Pass
week number: b weekday weekday number
number between 1-7.
between 1-7.
TC_010 Day of Enter a Please enter Please enter Pass
week number: # weekday weekday number
number between 1-7.
between
1-7.

Downloaded by Deep Patel


lOMoARcPSD|34814445

4. Create the test cases for following algorithm and write the ‘Expected
Outcome’ and ‘Actual Outcome’ in following table by executing the code.
Code:
#include<stdio.h>
#include<conio.h>

void main() {
int length; int count;
printf("Enter Length: "); scanf("%d", &length);

printf("Enter Count: "); scanf("%d", &count);

while(count <= 6) {
if (length >= 100){ length = length - 2;
} else {
length = count * length;
}
count = count + 1;
}

printf("Lenght = %d", length);


}

Test case:
Test Count Length Expected Output Actual Output
Case
1 5 101 594 594
2 5 99 493 493
3 7 99 99 99
4 0 0 0 0

Downloaded by Deep Patel


lOMoARcPSD|34814445

Downloaded by Deep Patel


lOMoARcPSD|34814445

Experiment No: 08
Title of Experiment Prepare Test plan for an identified Mobile Application

Downloaded by Deep Patel


lOMoARcPSD|34814445

Exercise:

1. Prepare test plan along with the test case to check the
any chatting application.
2. Prepare the test summary report for the application used in Quest

Downloaded by Deep Patel


lOMoARcPSD|34814445

Test Plan
Swiggy Version 3.77.1

Version: 1.0

Created: 19/11/2021
Last Updated: 19/11/2021

Revision and Signoff Sheet

Downloaded by Deep Patel


lOMoARcPSD|34814445

Document History

Version Date Author Description of Change

1 1/11/2021 Anurag Dubey Draft

2 1/11/2021 Vinay Savla Draft


3 12/11/2021 Sahil Makhijani Draft - Reviewed
4 12/11/2021 Kuber Dhure Draft - Reviewed

Approvers List
Approver / Approval /
Name Role
Reviewer Review Date
Vijay Patil Project Manager
Supriya Kadam Test Lead
Meenakshi Khamkar Test Lead
Anurag Dubey Technical Lead

Reference Documents -
Version Date Document Name
1.0 WHATSAPP Version 2.21.23.17

Downloaded by Deep Patel


lOMoARcPSD|34814445

Table of Contents

1. INTRODUCTION........................................................................................................9
1.1. Purpose...............................................................................................................9
1.2. Project Overview................................................................................................9
1.3. Audience............................................................................................................9
2. TEST STRATEGY.....................................................................................................10
2.1. Test Objectives.................................................................................................10
2.2. Test Assumptions.............................................................................................10
2.3. Test Principles..................................................................................................11
2.4. Data Approach..................................................................................................12
2.5. Scope and Levels of Testing............................................................................12
2.5.1. Exploratory...........................................................................................12
2.5.2. Functional Test.....................................................................................12
TEST ACCEPTANCE CRITERIA......................................................12
TEST DELIVERABLES......................................................................13
MILESTONE LIST..............................................................................13
2.5.3. User Acceptance Test (UAT)...............................................................14
TEST DELIVERABLES......................................................................14
2.6. Test Effort Estimate.........................................................................................14
3. EXECUTION STRATEGY........................................................................................15
3.1. Entry and Exit Criteria.....................................................................................15
3.2. Test Cycles.......................................................................................................16
3.3. Validation and Defect Management.................................................................16
3.4. Test Metrics......................................................................................................17
3.5. Defect tracking & Reporting............................................................................18
4. TEST MANAGEMENT PROCESS..........................................................................18
4.1. Test Management Tool.....................................................................................18

Downloaded by Deep Patel


lOMoARcPSD|34814445

4.2. Test Design Process.........................................................................................19

4.3. Test Execution Process....................................................................................20


4.4. Test Risks and Mitigation Factors....................................................................22
4.1. Communications Plan and Team Roster..........................................................22
4.2. Role Expectations.............................................................................................22
4.2.1. Project Management.............................................................................23
4.2.2. Test Planning (Test Lead)....................................................................23
4.2.3. Test Team.............................................................................................23
4.2.4. Test Lead..............................................................................................23
4.2.5. Development Team..............................................................................23
5. TEST ENVIRONMENT.............................................................................................24

Downloaded by Deep Patel


lOMoARcPSD|34814445

1. INTRODUCTION

1.1. Purpose

This test plan describes the testing approach and overall framework that will drive the testing of
the WHATSAPP application. The document introduces:

 Test Strategy: rules the test will be based on, including the givens of the project
(e.g.: start / end dates, objectives, assumptions); description of the process to set up
a valid test (e.g.: entry / exit criteria, creation of test cases, specific tasks to
perform, scheduling, data strategy).
 Execution Strategy: describes how the test will be performed and process to
identify and report defects, and to fix and implement fixes.
 Test Management: process to handle the logistics of the test and all the events that
come up during execution (e.g.: communications, escalation procedures, risk and
mitigation, team roster)

1.2. Project Overview

WhatsApp Messenger is a cross-platform instant messaging application that allows iPhone,


BlackBerry, Android, Windows Phone and Nokia smartphone users to exchange text, image,
video and audio messages for free. WhatsApp is especially popular with end users who do
not have unlimited text messaging.

Audience

 Project team members perform tasks specified in this document, and provide input
and recommendations on this document.
 Project Manager Plans for the testing activities in the overall project schedule,
reviews the document, tracks the performance of the test according to the task
herein specified, approves the document and is accountable for the results.
 The stakeholders’ representatives and participants (individuals as identified by the
PM or Leads) may take part in the UAT test to ensure the business is aligned with
the results of the test.
 Technical Team ensures that the test plan and deliverables are in line with the
design, provides the environment for testing and follows the procedures related to
the fixes of defects.
 Business analysts will provide their inputs on functional changes.

Downloaded by Deep Patel


lOMoARcPSD|34814445

2. TEST STRATEGY

2.1. Test Objectives

The objective of the test is to verify that the functionality of WHATSAPP works according to the
specifications.

The test will execute and verify the test scripts, identify, fix and retest all high and medium
severity defects per the entrance criteria, prioritize lower severity defects for future fixing.

The final product of the test is twofold:

 A production-ready software;
 A set of stable test scripts that can be reused for Functional and UAT test execution.

2.2. Test

Assumptions Key

Assumptions

 Production like data required and be available in the system prior to start of
Functional Testing

General

 Exploratory Testing would be carried out once the build is ready for testing
 Performance testing is not considered for this estimation.
 All the defects would come along with a snapshot JPEG format
 The Test Team will be provided with access to Test environment via VPN
connectivity
 The Test Team assumes all necessary inputs required during Test design and
execution will be supported by Development/BUSINESS ANALYSTs
appropriately.
 Test case design activities will be performed by QC Group
 Test environment and preparation activities will be owned by Dev Team
 Dev team will provide Defect fix plans based on the Defect meetings during each
cycle to plan. The same will be informed to Test team prior to start of Defect fix
cycles
 BUSINESS ANALYST will review and sign-off all Test cases prepared by Test
Team prior to start of Test execution
 The defects will be tracked through BUGZILLA only. Any defect fixes planned
will be shared with Test Team prior to applying the fixes on the Test environment
 Project Manager/BUSINESS ANALYST will review and sign-off all test
deliverables

Downloaded by Deep Patel


lOMoARcPSD|34814445

 The project will provide test planning, test design and test execution support
 Test team will manage the testing effort with close coordination with Project
PM/BUSINESS ANALYST
 Project team has the knowledge and experience necessary, or has received
adequate training in the system, the project and the testing processes.
 There is no environment downtime during test due to outages or defect fixes.
 The system will be treated as a black box; if the information shows correctly online
and in the reports, it will be assumed that the database is working properly.

Functional Testing
 During Functional testing, testing team will use preloaded data which is available
on the system at the time of execution
 The Test Team will be perform Functional testing only on WHATSAPP

UAT

 UAT test execution will be performed by end users (L1, L2 and L3) and QC Group
will provide their support on creating UAT script.

2.3. Test Principles

 Testing will be focused on meeting the business objectives, cost efficiency, and
quality.
 There will be common, consistent procedures for all teams supporting testing
activities.
 Testing processes will be well defined, yet flexible, with the ability to change as
needed.
 Testing activities will build upon previous stages to avoid redundancy or
duplication of effort.
 Testing environment and data will emulate a production environment as much as
possible.
 Testing will be a repeatable, quantifiable, and measurable activity.
 Testing will be divided into distinct phases, each with clearly defined objectives
and goals.
 There will be entrance and exit criteria.

Downloaded by Deep Patel


lOMoARcPSD|34814445

2.4. Data Approach

 In functional testing, WHATSAPP will contain pre-loaded test data and which is used
for testing activities.

2.5. Scope and Levels of Testing

2.5.1. Exploratory

PURPOSE: the purpose of this test is to make sure critical defects are removed
before the next levels of testing can start.

SCOPE: First level navigation, dealer and admin modules

TESTERS: Testing team.

METHOD: this exploratory testing is carried out in the application without


any test scripts and documentation

TIMING: at the beginning of each cycle.

2.5.2. Functional Test

PURPOSE: Functional testing will be performed to check the functions of


application. The functional testing is carried out by feeding the input and
validates the output from the application.

Scope: The below excel sheet details about the scope of Functional test. Note:
The scope is high level due to changes in the requirement.

TESTERS: Testing Team.

METHOD: The test will be performed according to Functional scripts, which


are stored in Selenium.

TIMING: After Exploratory test is completed.

TEST ACCEPTANCE CRITERIA


1. Approved Functional Specification document, Use case documents must
be available prior to start of Test design phase.
2. Test cases approved and signed-off prior to start of Test execution
3. Development completed, unit tested with pass status and results shared
to Testing team to avoid duplicate defects
4. Test environment with application installed, configured and ready to
use state

Downloaded by Deep Patel


lOMoARcPSD|34814445

Sign-off Readiness

Approved Functional Specification Document Development completed & unit tested


Approved Use cases Application deployed and system ready for testing on Test env
Approved Test cases Production like data is available to test all functionalities.
Defect fixes planned based on Defect triage (Unit Testing) and

TEST DELIVERABLES

Sr.No. Deliverable Name Author Reviewer

Project Manager/
1. Test Plan Test Lead Business
Analyst’s

Business
2. Functional Test Cases Test Team
Analyst’s Sign off

Test Lead/
Logging Defects in
3. Test Team Programming
BUGZILLA
Lead

Test Team/ Test Test Lead/ Project


4. Daily/weekly status report
Lead Manager

5. Test Closure report Test Lead Project Manager

MILESTONE LIST
The milestone list is tentative and may change due to below reasons

a) Any issues in the System environment readiness


b) Any change in scope/addition in scope
c) Any other dependency that impacts efforts and timelines

Downloaded by Deep Patel


lOMoARcPSD|34814445

2.5.3. User Acceptance Test (UAT)

PURPOSE: this test focuses on validating the business logic. It allows the end
users to complete one final review of the system prior to deployment.

TESTERS: the UAT is performed by the end users (L1, L2 and L3).

METHOD: Since the business users are the most indicated to provide input
around business needs and how the system adapts to them, it may happen that
the users do some validation not contained in the scripts. Test team write the
UAT test cases based on the inputs from End user (L1, L2 and L3 users) and
Business Analyst’s.

TIMING: After all other levels of testing (Exploratory and Functional) are
done. Only after this test is completed the product can be released to
production.

TEST DELIVERABLES

Sr.No. Deliverable Name Author Reviewer

Business
1. UAT Test Cases Test Team Analyst’s Sign
off

2.6. Test Effort Estimate

This document lists out all the activities that have to be performed by the QC team and estimates
how many man-hours each activity is going to take.

New_Detailed
DRFT Test
estimate v1.xlsx

Downloaded by Deep Patel


lOMoARcPSD|34814445

3. EXECUTION STRATEGY

3.1. Entry and Exit Criteria

 The entry criteria refer to the desirable conditions in order to start test execution;
only the migration of the code and fixes need to be assessed at the end of each
cycle.
 The exit criteria are the desirable conditions that need to be met in order proceed
with the implementation.
 Entry and exit criteria are flexible benchmarks. If they are not met, the test team
will assess the risk, identify mitigation actions and provide a recommendation. All
this is input to the project manager for a final “go-no go” decision.
 Entry criteria to start the execution phase of the test: the activities listed in the Test
Planning section of the schedule are 100% completed.
 Entry criteria to start each cycle: the activities listed in the Test Execution section
of the schedule are 100% completed at each cycle.

Test Technical
Exit Criteria Notes
Team Team

100% Test Scripts executed

95% pass rate of Test Scripts

No open Critical and High severity


defects

95% of Medium severity defects have


been closed

All remaining defects are either cancelled


or documented as Change Requests for a
future release

All expected and actual results are


captured and documented with the test
script

All test metrics collected based on reports


from BUGZILLA

All defects logged in BUGZILLA

Downloaded by Deep Patel


lOMoARcPSD|34814445

Test Closure Memo completed and


signed off

Test environment cleanup completed and


a new back up of the environment

3.2. Test Cycles

o There will be two cycles for functional testing. Each cycle will execute all the
scripts.
o The objective of the first cycle is to identify any blocking, critical defects, and
most of the high defects. It is expected to use some work-around in order to
get to all the scripts.
o The objective of the second cycle is to identify remaining high and medium
defects, remove the work-around from the first cycle, correct gaps in the
scripts and obtain performance results.
 UAT test will consist of one cycle.

3.3. Validation and Defect Management

 It is expected that the testers execute all the scripts in each of the cycles described
above. However it is recognized that the testers could also do additional testing if
they identify a possible gap in the scripts. This is especially relevant in the second
cycle, when the Business analyst’s join the TCOE in the execution of the test, since
the BUSINESS ANALYSTs have a deeper knowledge of the business processes. If
a gap is identified, the scripts and traceability matrix will be updated and then a
defect logged against the scripts.
 The defects will be tracked through BUGZILLA only. The technical team will
gather information on a daily basis from BUGZILLA, and request additional
details from the Defect Coordinator. The technical team will work on fixes.
 It is the responsibility of the tester to open the defects, link them to the
corresponding script, assign an initial severity and status, retest and close the
defect; it is the responsibility of the Defect Manager to review the severity of the
defects and facilitate with the technical team the fix and its implementation,
communicate with testers when the test can continue or should be halt, request the
tester to retest, and modify status as the defect progresses through the cycle; it is
the responsibility of the technical team to review BUGZILLA on a daily basis, ask
for details if necessary, fix the defect, communicate to the Defect Manager the fix
is done, implement the solution per the Defect Manager request.

Downloaded by Deep Patel


lOMoARcPSD|34814445

Defects found during the Testing will be categorized according to the bug-reporting tool
“BUGZILLA” and the categories are:

Severity Impact
1 (Critical)  This bug is critical enough to crash the system, cause file
corruption, or cause potential data loss
 It causes an abnormal return to the operating system (crash or a
system failure message appears).
 It causes the application to hang and requires re-booting the
system.
2 (High)  It causes a lack of vital program functionality with workaround.

3 (Medium)  This Bug will degrade the quality of the System. However there
is an intelligent workaround for achieving the desired
functionality - for example through another screen.
 This bug prevents other areas of the product from being tested.
However other areas can be independently tested.
4 (Low)  There is an insufficient or unclear error message, which has
minimum impact on product use.
5(Cosmetic)  There is an insufficient or unclear error message that has no
impact on product use.

3.4. Test Metrics

Test metrics to measure the progress and level of success of the test will be developed and shared
with the project manager for approval. The below are some of the metrics

Report Description Frequency

Test To report on % complete, % Pass, % Fail Weekly / Daily


preparation (optional)
& Defects severity wise Status – Open, closed, any
Execution other Status
Status

Daily To report on Pass, Fail, Total defects, highlight Daily


execution Showstopper/ Critical defects

status

Downloaded by Deep Patel


lOMoARcPSD|34814445

Project Project driven reporting (As requested by PM) Weekly – If project


Weekly team needs weekly
Status update apart from
report daily and there is
template available
with project team to
use.

3.5. Defect tracking & Reporting -

Following flowchart depicts Defect Tracking Process:

4. TEST MANAGEMENT PROCESS

4.1. Test Management Tool


QA Manager Lifecycle Management is the tool used for Test Management. All
testing artifacts such as Test cases, test results are updated in the qaManager
Lifecycle Management.
 Project specific folder structure will be created in qaManager to manage
the status of this project.

Downloaded by Deep Patel


lOMoARcPSD|34814445

 Each resource in the Testing team will be provided with Read/Write access
to add/modify Test cases in qaManager.
 During the Test Design phase, all test cases are written directly into
qaManager. Any change to the test case will be directly updated in
the qaManager.
 Each Tester will directly access their respective assigned test cases and
update the status of each executed step in qaManager directly.
 Any defect encountered will be raised in BUGZILLA linking to the
particular Test case/test step.
 During Defect fix testing, defects are re-assigned back to the tester to verify
the defect fix. The tester verifies the defect fix and updates the status directly
in BUGZILLA.
 Various reports can be generated from BUGZILLA to provide status of Test
execution. For example, Status report of Test cases executed, Passed,
Failed, No. of open defects, Severity wise defects etc.

4.2. Test Design Process

Establishing Incorporating
Understanding
Traceability Matrix in qaManager
Preparation ofPeer Review ofReview Test casesTest casescomments in
Requirements test cases

 The tester will understand each requirement and prepare corresponding


test case to ensure all requirements are covered.
 Each Test case will be mapped to Use cases to Requirements as part
of Traceability matrix.
 Each of the Test cases will undergo review by the BUSINESS
ANALYST and the review defects are captured and shared to the Test
team. The testers will rework on the review defects and finally obtain
approval and sign-off.
 During the preparation phase, tester will use the prototype, use case
and functional specification to write step by step test cases.
 Testers will maintain a clarification Tracker sheet and same will be shared
periodically with the Requirements team and accordingly the test case
will

Downloaded by Deep Patel


lOMoARcPSD|34814445

be updated. The clarifications may sometimes lead to Change Requests or


not in scope or detailing implicit requirements.
 Sign-off for the test cases would be communicates through mail by
Business Analyst’s.
 Any subsequent changes to the test case if any will be directly updated
in qaManager.

4.3. Test Execution Process

Raise defects for Participate in


Execute each ofMark Status as Send the daily Complete the
the failed test cases in qaManager Defect Triage cycle and explain the defects
the test step in Pass/Fail in test caseqaManager status report to Test Lead test execution of all the test cases

 Once all Test cases are approved and the test environment is ready for
testing, tester will start an exploratory test of the application to ensure
the application is stable for testing.
 Each Tester is assigned Test cases directly in qaManager.
 Testers to ensure necessary access to the testing environment, BUGZILLA
for updating test status and raise defects. If any issues, will be escalated to
the Test Lead and in turn to the Project Manager as escalation.
 If any showstopper during exploratory testing will be escalated to the
respective development team for fixes.
 Each tester performs step by step execution and updates the executions
status. The tester enters Pass or Fail Status for each of the step directly
in BUGZILLA.
 Tester will prepare a Run chart with day-wise execution details
 If any failures, defect will be raised as per severity guidelines in
BUGZILLA tool detailing steps to simulate along with screenshots
if appropriate.
 Daily Test execution status as well as Defect status will be reported to
all stakeholders.
 Testing team will participate in defect triage meetings in order to
ensure all test cases are executed with either pass/fail category.
 If there are any defects that are not part of steps but could be outside
the test steps, such defects need to be captured in BUGZILLA and map
it

Downloaded by Deep Patel


lOMoARcPSD|34814445

Risk Prob. Impact Mitigation Plan

SCHEDULE  The testing team can control the


Testing schedule is tight. If the preparation tasks (in advance) and
start of the testing is delayed due the early communication with
to design tasks, the test cannot be High High involved parties.
extended beyond the UAT  Some buffer has been added to the
scheduled start date. schedule for contingencies, although
not as much as best practices advise.
RESOURCES Holidays and vacation have been
Not enough resources, resources estimated and built into the schedule;
Mediu
on boarding too late (process High deviations from the estimation could
m
takes around 15 days. derive in delays in the testing.

DEFECTS Defect management plan is in place to


Defects are found at a late stage ensure prompt communication and fixing
of the cycle or at a late cycle; of issues.
defects discovered late are most
Mediu
likely be due to unclear High
m
specifications and are time
consuming to resolve.

SCOPE Scope is well defined but the changes are


Mediu
Scope completely defined Medium in the functionality are not yet finalized
m
or keep on changing.
Natural disasters Teams and responsibilities have been
spread to two different geographic areas.
In a catastrophic event in one of the
Low Medium
areas, there will resources in the other
areas needed to continue (although at a
slower pace) the testing activities.
Non-availability of Independent Due to non-availability of the
Test environment and Mediu environment, the schedule gets impacted
High
accessibility m and will lead to delayed start of Test
execution.
Delayed Testing Due To new During testing, there is a good chance
Issues that some “new” defects may be
identified and may become an issue that
Mediu
High will take time to resolve.
m
There are defects that can be raised
during testing because of unclear
document specification. These defects

Downloaded by Deep Patel


lOMoARcPSD|34814445

can yield to an issue that will need time


to be resolved.
If these issues become showstoppers, it
will greatly impact on the overall project
schedule.
If new defects are discovered, the defect
management and issue management
procedures are in place to immediately
provide a resolution.
 against the test case level or at the specific step that issue was
encountered after confirming with Test Lead.
 This process is repeated until all test cases are executed fully
with Pass/Fail status.
 During the subsequent cycle, any defects fixed applied will be tested and
results will be updated in BUGZILLA during the cycle.

As per Process, final sign-off or project completion process will be followed

4.4. Test Risks and Mitigation Factors

4.1. Communications Plan and Team Roster

4.2. Role Expectations

The following list defines in general terms the expectations related to the roles directly involved
in the management, planning or execution of the test for the project.

Roles Name

1. Project Manager Vijay Patil


2. Test Lead Vinay Savla
3. Business Analyst Arfia Shaikh
4. Development Lead Sahil Makhijani
5. Testing Team Kuber Dhure
6. Development Team Devesh Vengurlakar
7. Technical Lead Anurag Dubey

Downloaded by Deep Patel


lOMoARcPSD|34814445

4.2.1. Project Management

 Project Manager: reviews the content of the Test Plan, Test Strategy and
Test Estimates signs off on it.

4.2.2. Test Planning (Test Lead)

 Ensure entrance criteria are used as input before start the execution.
 Develop test plan and the guidelines to create test conditions, test cases,
expected results and execution scripts.
 Provide guidelines on how to manage defects.
 Attend status meetings in person or via the conference call line.
 Communicate to the test team any changes that need to be made to the test
deliverables or application and when they will be completed.
 Provide on premise or telecommute support.
 Provide functional (Business Analysts) and technical team to test team
personnel (if needed).

4.2.3. Test Team

 Develop test conditions, test cases, expected results, and execution scripts.
 Perform execution and validation.
 Identify, document and prioritize defects according to the guidance
provided by the Test lead.
 Re-test after software modifications have been made according to the
schedule.
 Prepare testing metrics and provide regular status.

4.2.4. Test Lead

 Acknowledge the completion of a section within a cycle.


 Give the OK to start next level of testing.
 Facilitate defect communications between testing team and technical /
development team.

4.2.5. Development Team

 Review testing deliverables (test plan, cases, scripts, expected results, etc.)
and provide timely feedback.
 Assist in the validation of results (if requested).
 Support the development and testing processes being used to support the
project.

Downloaded by Deep Patel


lOMoARcPSD|34814445

 Certify correct components have been delivered to the test environment at


the points specified in the testing schedule.
 Keep project team and leadership informed of potential software delivery
date slips based on the current schedule.
 Define processes/tools to facilitate the initial and ongoing migration of
components.
 Conduct first line investigation into execution discrepancies and assist test
executors in creation of accurate defects.
 Implement fixes to defects according to schedule.

5. TEST ENVIRONMENT

The following mobile operating systems are supported:

 iOS 9.0 to iOS 11.0


 Android 4.3 to 9.0

Hardware Requirements for Mobile Testing

The following hardware is required to support mobile testing:


CPU

 Intel Core i7 2.4 GHz or AMD equivalent


Memory

 Cloud or Remote Mobile Tests: 4GB


 Local Simulators: 8GB

6. APPROVALS

The Names and Titles of all persons who must approve this plan.

Signature:

Downloaded by Deep Patel


lOMoARcPSD|34814445

Name: Vijay Patil

Role: Project Manager

Date: 14/11/21

Signature:

Name: Supriya Kadam

Role: Test Lead

Date: 14/11/19

Downloaded by Deep Patel


lOMoARcPSD|34814445

3. Prepare test plan for any food application with test cases.

Downloaded by Deep Patel


lOMoARcPSD|34814445

Test Plan
Swiggy Version 3.77.1

Version: 1.0
Created: 14/11/2021
Last Updated: 14/11/2021
lOMoARcPSD|34814445

Downloaded by Deep Patel


([email protected])
lOMoARcPSD|34814445

Revision and Signoff Sheet


Document History

Version Date Author Description of Change

1 1/11/2021 Anurag Dubey Draft

2 1/11/2021 Vinay Savla Draft


3 12/11/2021 Sahil Makhijani Draft - Reviewed
4 12/11/2021 Kuber Dhure Draft - Reviewed

Approvers List
Approver / Approval /
Name Role
Reviewer Review Date
Vijay Patil Project Manager
Supriya Kadam Test Lead
Meenakshi Khamkar Test Lead
Anurag Dubety Technical Lead

Reference Documents -
Version Date Document Name
14/11/21 SWIGGY FOOD DELIVERY APP
1.0
VERSION 3.77.1

Downloaded by Deep Patel


lOMoARcPSD|34814445

Table of Contents

1. INTRODUCTION........................................................................................................9
1.1. Purpose...............................................................................................................9
1.2. Project Overview................................................................................................9
1.3. Audience............................................................................................................9
2. TEST STRATEGY.....................................................................................................10
2.1. Test Objectives.................................................................................................10
2.2. Test Assumptions.............................................................................................10
2.3. Test Principles..................................................................................................11
2.4. Data Approach..................................................................................................12
2.5. Scope and Levels of Testing............................................................................12
2.5.1. Exploratory...........................................................................................12
2.5.2. Functional Test.....................................................................................12
TEST ACCEPTANCE CRITERIA......................................................12
TEST DELIVERABLES......................................................................13
MILESTONE LIST..............................................................................13
2.5.3. User Acceptance Test (UAT)...............................................................14
TEST DELIVERABLES......................................................................14
2.6. Test Effort Estimate.........................................................................................14
3. EXECUTION STRATEGY........................................................................................15
3.1. Entry and Exit Criteria.....................................................................................15
3.2. Test Cycles.......................................................................................................16
3.3. Validation and Defect Management.................................................................16
3.4. Test Metrics......................................................................................................17
3.5. Defect tracking & Reporting............................................................................18
4. TEST MANAGEMENT PROCESS..........................................................................18
4.1. Test Management Tool.....................................................................................18
4.2. Test Design Process.........................................................................................19
4.3. Test Execution Process....................................................................................20
4.4. Test Risks and Mitigation Factors....................................................................22

Downloaded by Deep Patel


lOMoARcPSD|34814445

4.1. Communications Plan and Team Roster..........................................................22


4.2. Role Expectations.............................................................................................22
4.2.1. Project Management.............................................................................23
4.2.2. Test Planning (Test Lead)....................................................................23
4.2.3. Test Team.............................................................................................23
4.2.4. Test Lead..............................................................................................23
4.2.5. Development Team..............................................................................23
5. TEST ENVIRONMENT.............................................................................................24

Downloaded by Deep Patel


lOMoARcPSD|34814445

7. INTRODUCTION

7.1. Purpose

This test plan describes the testing approach and overall framework that will drive the testing of
the SWIGGY application. The document introduces:

 Test Strategy: rules the test will be based on, including the givens of the project
(e.g.: start / end dates, objectives, assumptions); description of the process to set up
a valid test (e.g.: entry / exit criteria, creation of test cases, specific tasks to
perform, scheduling, data strategy).
 Execution Strategy: describes how the test will be performed and process to
identify and report defects, and to fix and implement fixes.
 Test Management: process to handle the logistics of the test and all the events that
come up during execution (e.g.: communications, escalation procedures, risk and
mitigation, team roster)

7.2. Project Overview

Swiggy Online food delivery application a cross-platform instant food ordering application
that allows iPhone, BlackBerry, Android, Windows Phone and Nokia smartphone users to
order food from any restaurants online. Swiggy is especially popular with end users for
ordering of food and also tacks the food making and delivery process online.

Audience

 Project team members perform tasks specified in this document, and provide input
and recommendations on this document.
 Project Manager Plans for the testing activities in the overall project schedule,
reviews the document, tracks the performance of the test according to the task
herein specified, approves the document and is accountable for the results.
 The stakeholders’ representatives and participants (individuals as identified by the
PMO Leads) may take part in the UAT test to ensure the business is aligned with
the results of the test.
 Technical Team ensures that the test plan and deliverables are in line with the
design, provides the environment for testing and follows the procedures related to
the fixes of defects.
 Business analysts will provide their inputs on functional changes.

Downloaded by Deep Patel


lOMoARcPSD|34814445

8. TEST STRATEGY

8.1. Test Objectives

The objective of the test is to verify that the functionality of SWIGGY works according to the
specifications.

The test will execute and verify the test scripts, identify, fix and retest all high and medium
severity defects per the entrance criteria, prioritize lower severity defects for future fixing.

The final product of the test is twofold:

 A production-ready software;
 A set of stable test scripts that can be reused for Functional and UAT test execution.

8.2. Test

Assumptions Key

Assumptions

 Production like data required and be available in the system prior to start of
Functional Testing

General

 Exploratory Testing would be carried out once the build is ready for testing
 Performance testing is not considered for this estimation.
 All the defects would come along with a snapshot JPEG format
 The Test Team will be provided with access to Test environment via VPN
connectivity
 The Test Team assumes all necessary inputs required during Test design and
execution will be supported by Development/BUSINESS ANALYSTs
appropriately.
 Test case design activities will be performed by QA Group
 Test environment and preparation activities will be owned by Dev Team
 Dev team will provide Defect fix plans based on the Defect meetings during each
cycle to plan. The same will be informed to Test team prior to start of Defect fix
cycles
 BUSINESS ANALYST will review and sign-off all Test cases prepared by Test
Team prior to start of Test execution
 The defects will be tracked through BUGZILLA only. Any defect fixes planned
will be shared with Test Team prior to applying the fixes on the Test environment
 Project Manager/BUSINESS ANALYST will review and sign-off all test
deliverables

Downloaded by Deep Patel


lOMoARcPSD|34814445

 The project will provide test planning, test design and test execution support
 Test team will manage the testing effort with close coordination with Project
PM/BUSINESS ANALYST
 Project team has the knowledge and experience necessary, or has received
adequate training in the system, the project and the testing processes.
 There is no environment downtime during test due to outages or defect fixes.
 The system will be treated as a black box; if the information shows correctly
online and in the reports, it will be assumed that the database is working properly.

Functional Testing
 During Functional testing, testing team will use preloaded data which is available
on the system at the time of execution
 The Test Team will be perform Functional testing only on SWIGGY

UAT

 UAT test execution will be performed by end users (L1, L2 and L3) and QA
Group will provide their support on creating UAT script.

8.3. Test Principles

 Testing will be focused on meeting the business objectives, cost efficiency, and
quality.
 There will be common, consistent procedures for all teams supporting testing
activities.
 Testing processes will be well defined, yet flexible, with the ability to change as
needed.
 Testing activities will build upon previous stages to avoid redundancy or
duplication of effort.
 Testing environment and data will emulate a production environment as much as
possible.
 Testing will be a repeatable, quantifiable, and measurable activity.
 Testing will be divided into distinct phases, each with clearly defined objectives
and goals.
 There will be entrance and exit criteria.

Downloaded by Deep Patel


lOMoARcPSD|34814445

8.4. Data Approach

 In functional testing, SWIGGY will contain pre-loaded test data and which is used for
testing activities.

8.5. Scope and Levels of Testing

8.5.1. Exploratory

PURPOSE: the purpose of this test is to make sure critical defects are removed
before the next levels of testing can start.

SCOPE: First level navigation, dealer and admin modules

TESTERS: Testing team.

METHOD: this exploratory testing is carried out in the application without


any test scripts and documentation

TIMING: at the beginning of each cycle.

8.5.2. Functional Test

PURPOSE: Functional testing will be performed to check the functions of


application. The functional testing is carried out by feeding the input and
validates the output from the application.

Scope: The below excel sheet details about the scope of Functional test. Note:
The scope is high level due to changes in the requirement.

TESTERS: Testing Team.

METHOD: The test will be performed according to Functional scripts, which


are stored in Selenium.

TIMING: After Exploratory test is completed.

TEST ACCEPTANCE CRITERIA


1. Approved Functional Specification document, Use case documents must
be available prior to start of Test design phase.
2. Test cases approved and signed-off prior to start of Test execution
3. Development completed, unit tested with pass status and results shared
to Testing team to avoid duplicate defects
4. Test environment with application installed, configured and ready to use
state

Downloaded by Deep Patel


lOMoARcPSD|34814445

Sign-off Readiness

Approved Functional Specification Document Development completed & unit tested


Approved Use cases Application deployed and system ready for testing on Test env
Approved Test cases Production like data is available to test all functionalities.
Defect fixes planned based on Defect triage (Unit Testing) and

TEST DELIVERABLES

S.No. Deliverable Name Author Reviewer

1. Test Plan Test Lead Project Manager/


Business Analyst’s

2. Functional Test Cases Test Team Business Analyst’s


Sign off

3. Logging Defects in Test Team Test Lead/


BUGZILLA Programming
Lead

(4. Daily/weekly status report Test Team/ Test Test Lead/ Project
Lead Manager

5. Test Closure report Test Lead Project Manager

MILESTONE LIST
The milestone list is tentative and may change due to below reasons

d) Any issues in the System environment readiness


e) Any change in scope/addition in scope
f) Any other dependency that impacts efforts and timelines

8.5.3. User Acceptance Test (UAT)

PURPOSE: this test focuses on validating the business logic. It allows the end
users to complete one final review of the system prior to deployment.

Downloaded by Deep Patel


lOMoARcPSD|34814445

TESTERS: the UAT is performed by the end users (L1, L2 and L3).

METHOD: Since the business users are the most indicated to provide input
around business needs and how the system adapts to them, it may happen that
the users do some validation not contained in the scripts. Test team write the
UAT test cases based on the inputs from End user (L1,L2 and L3 users) and
Business Analyst’s.

TIMING: After all other levels of testing (Exploratory and Functional) are
done. Only after this test is completed the product can be released to
production.

TEST DELIVERABLES

S.No. Deliverable Name Author Reviewer

1. UAT Test Cases Test Team Business


Analyst’s Sign off

8.6. Test Effort Estimate

This document lists out all the activities that have to be performed by the QA team and estimates
how many man-hours each activity is going to take.

New_Detailed
DRFT Test
estimate v1.xlsx

9. EXECUTION STRATEGY

9.1. Entry and Exit Criteria

 The entry criteria refer to the desirable conditions in order to start test execution;
only the migration of the code and fixes need to be assessed at the end of each
cycle.
 The exit criteria are the desirable conditions that need to be met in order proceed
with the implementation.

Downloaded by Deep Patel


lOMoARcPSD|34814445

 Entry and exit criteria are flexible benchmarks. If they are not met, the test team
will assess the risk, identify mitigation actions and provide a recommendation. All
this is input to the project manager for a final “go-no go” decision.
 Entry criteria to start the execution phase of the test: the activities listed in the Test
Planning section of the schedule are 100% completed.
 Entry criteria to start each cycle: the activities listed in the Test Execution section
of the schedule are 100% completed at each cycle.

Test Technical
Exit Criteria Notes
Team Team

100% Test Scripts executed

95% pass rate of Test Scripts

No open Critical and High severity


defects

95% of Medium severity defects have


been closed

All remaining defects are either cancelled


or documented as Change Requests for a
future release

All expected and actual results are


captured and documented with the test
script

All test metrics collected based on reports


from BUGZILLA

All defects logged in BUGZILLA

Test Closure Memo completed and


signed off

Test environment cleanup completed and


a new back up of the environment

Downloaded by Deep Patel


lOMoARcPSD|34814445

9.2. Test Cycles

o There will be two cycles for functional testing. Each cycle will execute all the
scripts .
o The objective of the first cycle is to identify any blocking, critical defects, and
most of the high defects. It is expected to use some work-around in order to
get to all the scripts.
o The objective of the second cycle is to identify remaining high and medium
defects, remove the work-around from the first cycle, correct gaps in the
scripts and obtain performance results.
 UAT test will consist of one cycle.

9.3. Validation and Defect Management

 It is expected that the testers execute all the scripts in each of the cycles described
above. However it is recognized that the testers could also do additional testing if
they identify a possible gap in the scripts. This is especially relevant in the second
cycle, when the Business analyst’s join the TCOE in the execution of the test, since
the BUSINESS ANALYSTs have a deeper knowledge of the business processes. If
a gap is identified, the scripts and traceability matrix will be updated and then a
defect logged against the scripts.
 The defects will be tracked through BUGZILLA only. The technical team will
gather information on a daily basis from BUGZILLA, and request additional
details from the Defect Coordinator. The technical team will work on fixes.
 It is the responsibility of the tester to open the defects, link them to the
corresponding script, assign an initial severity and status, retest and close the
defect; it is the responsibility of the Defect Manager to review the severity of the
defects and facilitate with the technical team the fix and its implementation,
communicate with testers when the test can continue or should be halt, request the
tester to retest, and modify status as the defect progresses through the cycle; it is
the responsibility of the technical team to review BUGZILLA on a daily basis, ask
for details if necessary, fix the defect, communicate to the Defect Manager the fix
is done, implement the solution per the Defect Manager request.

Defects found during the Testing will be categorized according to the bug-reporting tool
“BUGZILLA” and the categories are:

Severity Impact
1 (Critical)  This bug is critical enough to crash the system, cause file
corruption, or cause potential data loss
 It causes an abnormal return to the operating system (crash or a
system failure message appears).

Downloaded by Deep Patel


lOMoARcPSD|34814445

 causes the application to hang and requires re-booting the


It
system.
(High) It causes a lack of vital program functionality with workaround.
(Medium) This Bug will degrade the quality of the System. However there is
an intelligent workaround for achieving the desired functionality - for exam
This bug prevents other areas of the product from being tested. However o

There is an insufficient or unclear error message, which has minimum i
There is an insufficient or unclear error message that has no impact on prod
4 (Low) 

5(Cosmetic)

9.4. Test Metrics

Test metrics to measure the progress and level of success of the test will be developed and shared
with the project manager for approval. The below are some of the metrics

Report Description Frequency

Test To report on % complete, % Pass, % Fail Weekly / Daily


preparation (optional)
& Defects severity wise Status – Open, closed, any
Execution other Status
Status

Daily To report on Pass, Fail, Total defects, highlight Daily


execution Showstopper/ Critical defects

status

Project Project driven reporting (As requested by PM) Weekly – If project


Weekly team needs weekly
Status update apart from
report daily and there is
template available
with project team to
use.

Downloaded by Deep Patel


lOMoARcPSD|34814445

9.5. Defect tracking & Reporting -

Following flowchart depicts Defect Tracking Process:

10. TEST MANAGEMENT PROCESS

10.1. Test Management Tool


qaManager Lifecycle Management is the tool used for Test Management. All
testing artifacts such as Test cases, test results are updated in the qaManager
Lifecycle Management.
 Project specific folder structure will be created in qaManager to manage
the status of this project.
 Each resource in the Testing team will be provided with Read/Write access to
add/modify Test cases in qaManager.
 During the Test Design phase, all test cases are written directly into
qaManager. Any change to the test case will be directly updated in
the qaManager.
 Each Tester will directly access their respective assigned test cases and
update the status of each executed step in qaManager directly.
 Any defect encountered will be raised in BUGZILLA linking to the
particular Test case/test step.

Downloaded by Deep Patel


lOMoARcPSD|34814445

 During Defect fix testing, defects are re-assigned back to the tester to verify
the defect fix. The tester verifies the defect fix and updates the status directly
in BUGZILLA.
 Various reports can be generated from BUGZILLA to provide status of Test
execution. For example, Status report of Test cases executed, Passed,
Failed, No. of open defects, Severity wise defects etc.

10.2. Test Design Process

Establishing Incorporating
Understanding
Traceability Matrix in qaManager
Preparation ofPeer Review ofReview
Requirements Test casesTest casescomments in
test cases

 The tester will understand each requirement and prepare corresponding


test case to ensure all requirements are covered.
 Each Test case will be mapped to Use cases to Requirements as part
of Traceability matrix.
 Each of the Test cases will undergo review by the BUSINESS
ANALYST and the review defects are captured and shared to the Test
team. The testers will rework on the review defects and finally obtain
approval and sign-off.
 During the preparation phase, tester will use the prototype, use case
and functional specification to write step by step test cases.
 Testers will maintain a clarification Tracker sheet and same will be shared
periodically with the Requirements team and accordingly the test case
will be updated. The clarifications may sometimes lead to Change
Requests or not in scope or detailing implicit requirements.
 Sign-off for the test cases would be communicates through mail by
Business Analyst’s.
 Any subsequent changes to the test case if any will be directly updated
in qaManager.

Downloaded by Deep Patel


lOMoARcPSD|34814445

10.3. Test Execution Process

Raise defects for Participate in


Execute each ofMark Status as Send the daily Complete the
the failed test cases in qaManager Defect Triage cycle and explain the defects
the test step in Pass/Fail in test caseqaManager status report to Test Lead test execution of all the test cases

 Once all Test cases are approved and the test environment is ready for
testing, tester will start a exploratory test of the application to ensure
the application is stable for testing.
 Each Tester is assigned Test cases directly in qaManager.
 Testers to ensure necessary access to the testing environment, BUGZILLA
for updating test status and raise defects. If any issues, will be escalated to
the Test Lead and in turn to the Project Manager as escalation.
 If any showstopper during exploratory testing will be escalated to the
respective development team for fixes.
 Each tester performs step by step execution and updates the executions
status. The tester enters Pass or Fail Status for each of the step directly
in BUGZILLA.
 Tester will prepare a Run chart with day-wise execution details
 If any failures, defect will be raised as per severity guidelines in
BUGZILLA tool detailing steps to simulate along with screenshots
if appropriate.
 Daily Test execution status as well as Defect status will be reported to
all stakeholders.
 Testing team will participate in defect triage meetings in order to
ensure all test cases are executed with either pass/fail category.
 If there are any defects that are not part of steps but could be outside the
test steps, such defects need to be captured in BUGZILLA and map it
against the test case level or at the specific step that issue was encountered
after confirming with Test Lead.
 This process is repeated until all test cases are executed fully
with Pass/Fail status.
 During the subsequent cycle, any defects fixed applied will be tested and
results will be updated in BUGZILLA during the cycle.

Downloaded by Deep Patel


lOMoARcPSD|34814445

As per Process, final sign-off or project completion process will be followed

10.4. Test Risks and Mitigation Factors

Risk Prob. Impact Mitigation Plan

SCHEDULE  The testing team can control


Testing schedule is tight. If the the preparation tasks (in
start of the testing is delayed due advance) and the early
to design tasks, the test cannot be communication with involved
extended beyond the UAT High High parties.
scheduled start date.  Some buffer has been added
to the schedule for
contingencies, although not as
much as best practices advise.
RESOURCES Holidays and vacation have been
Not enough resources, resources estimated and built into the
Mediu
on boarding too late (process High schedule; deviations from the
m
takes around 15 days. estimation could derive in delays
in the testing.
DEFECTS Defect management plan is in
Defects are found at a late stage place to ensure prompt
of the cycle or at a late cycle; communication and fixing of
defects discovered late are most issues.
Mediu
likely be due to unclear High
m
specifications and are time
consuming to resolve.

SCOPE Scope is well defined but the


Scope completely defined Mediu changes are in the functionality
Medium
m are not yet finalized or keep on
changing.
Natural disasters Teams and responsibilities have
been spread to two different
geographic areas. In a
catastrophic event in one of the
Low Medium
areas, there will resources in the
other areas needed to continue
(although at a slower pace) the
testing activities.

Downloaded by Deep Patel


lOMoARcPSD|34814445

Risk Prob. Impact Mitigation Plan

Non-availability of Independent Due to non availability of the


Test environment and Mediu environment, the schedule gets
High
accessibility m impacted and will lead to delayed
start of Test execution.
Delayed Testing Due To new During testing, there is a good
Issues chance that some “new” defects
may be identified and may
become an issue that will take
time to resolve.
There are defects that can be
raised during testing because of
unclear document specification.
These defects can yield to an
Mediu issue that will need time to be
High resolved.
m
If these issues become
showstoppers, it will greatly
impact on the overall project
schedule.
If new defects are discovered, the
defect management and issue
management procedures are in
place to immediately provide a
resolution.

10.5. Communications Plan and Team Roster

10.6. Role Expectations

The following list defines in general terms the expectations related to the roles directly involved
in the management, planning or execution of the test for the project.

Roles Name

1. Project Manager Vijay Patil


2. Test Lead Vinay Savla
3. Business Analyst Arfia Shaikh
4. Development Lead Sahil Makhijani

Downloaded by Deep Patel


lOMoARcPSD|34814445

Roles Name

5. Testing Team Vinay Savla


6. Development Team Devesh Vengurlekar
7. Technical Lead Anurag Dubey

10.6.1. Project Management

 Project Manager: reviews the content of the Test Plan, Test Strategy and
Test Estimates signs off on it.

10.6.2. Test Planning (Test Lead)

 Ensure entrance criteria are used as input before start the execution.
 Develop test plan and the guidelines to create test conditions, test cases,
expected results and execution scripts.
 Provide guidelines on how to manage defects.
 Attend status meetings in person or via the conference call line.
 Communicate to the test team any changes that need to be made to the test
deliverables or application and when they will be completed.
 Provide on premise or telecommute support.
 Provide functional (Business Analysts) and technical team to test team
personnel (if needed).

10.6.3. Test Team

 Develop test conditions, test cases, expected results, and execution scripts.
 Perform execution and validation.
 Identify, document and prioritize defects according to the guidance
provided by the Test lead.
 Re-test after software modifications have been made according to the
schedule.
 Prepare testing metrics and provide regular status.

10.6.4. Test Lead

 Acknowledge the completion of a section within a cycle.


 Give the OK to start next level of testing.

Downloaded by Deep Patel


lOMoARcPSD|34814445

 Facilitate defect communications between testing team and technical /


development team.

10.6.5. Development Team

 Review testing deliverables (test plan, cases, scripts, expected results, etc.)
and provide timely feedback.
 Assist in the validation of results (if requested).
 Support the development and testing processes being used to support the
project.
 Certify correct components have been delivered to the test environment at
the points specified in the testing schedule.
 Keep project team and leadership informed of potential software delivery
date slips based on the current schedule.
 Define processes/tools to facilitate the initial and ongoing migration of
components.
 Conduct first line investigation into execution discrepancies and assist test
executors in creation of accurate defects.
 Implement fixes to defects according to schedule.

11. TEST ENVIRONMENT

The following mobile operating systems are supported:

 iOS 9.0 to iOS 11.0


 Android 4.3 to 9.0

Hardware Requirements for Mobile Testing

The following hardware is required to support mobile testing:


CPU

 Intel Core i7 2.4 GHz or AMD equivalent


Memory

 Cloud or Remote Mobile Tests: 4GB


 Local Simulators: 8GB

Downloaded by Deep Patel


lOMoARcPSD|34814445

12. APPROVALS

The Names and Titles of all persons who must approve this plan.

Signature:

Name: Vijay Patil

Role: Project Manager

Date: 14/11/21

Signature:

Name: Supriya Kadam

Role: Test Lead

Date: 14/11/21

Downloaded by Deep Patel


lOMoARcPSD|34814445

DEPARTMENT OF COMPUTER
ENGINEERING

Subject: Software Testing Subject Code: 22518


Semester: 5 Course: CO5I-A
Laboratory No: Name of Subject Teacher: Supriya Angne
Name of Student: Anurag Dubey Roll Id: 19203A0013

Experiment No: 10
Title of Experiment Generate Defect report for Library Management System.

Practical Related Questions


1. Compare Defect, Error and failure.
Answer:

Compariso Defect Error Failure


n basis

Definition The Defect is the An Error is a If the software


difference between mistake made in has lots of
the actual the code; that's defects, it leads to
outcomes and why we cannot failure or causes
expected outputs. execute or failure.
compile code.

Raised by The Testers identif The Developers The failure finds


y the defect. And it and automation by the manual
was also solved by test test engineer
the developer in engineers raise through
the development the error. the development
phase or stage. cycle.

Downloaded by Deep Patel


lOMoARcPSD|34814445

Different Different type of Different type -----


types Defects are as of Error is as
follows: below:
Based on priority: o Syntactic
o High Error
o Medium o User

o Low interface
And based on the error
severity: o Flow

o Critical control
o Major error
o Minor o Error

o Trivial handling
error
o Calculation
error
o Hardware
error
o Testing Error

Reasons The below reason The reasons for Following are


behind leads to having some of the
the defects: an error are as most important
Giving incorrect follows: reasons behind
and wrong Errors in the the failure:
inputs. Dilemmas code. Environmental
and errors in the The Mistake of condition
outside behavior some values. System usage
and inside If a developer is Users
structure and unable to Human error
design. compile or run a
An error in coding program
or logic affects the successfully.

Downloaded by Deep Patel


lOMoARcPSD|34814445

software and Confusions and


causes it to issues in
breakdown or the programming.
failure. Invalid login,
loop, and syntax.
Inconsistency
between actual
and expected
outcomes.
Blunders in
design or
requirement
actions.
Misperception
in understanding
the
requirements of
the application.

Way to With the help of Below are ways The way to


prevent the the following, we to prevent prevent failure ar
reasons can prevent the Errors: e as follows:
the Defects: Enhance the Confirm re-
Implementing software quality testing.
several innovative with system Review the
programming review and requirements and
methods. programming. revisit the
Use of primary and Detect the issues specifications.
correct software and prepare a Implement
development suitable current protective
techniques. mitigation plan. techniques.
Peer review Validate the Categorize and

Downloaded by Deep Patel


lOMoARcPSD|34814445

It is executing fixes and verify evaluate errors


consistent code their quality and and issues.
reviews to evaluate precision.
its quality and
correctness.

2. Describe different status of Defects.


Answer:
 New: When a new defect is logged and posted for the first time. It
is assigned a status as NEW.
 Assigned: Once the bug is posted by the tester, the lead of the
tester approves the bug and assigns the bug to the developer team
 Open: The developer starts analyzing and works on the defect fix
 Fixed: When a developer makes a necessary code change and verifies the
change, he or she can make bug status as “Fixed.”
 Pending retest: Once the defect is fixed the developer gives a particular
code for retesting the code to the tester. Since the software testing
remains pending from the testers end, the status assigned is “pending
retest.”
 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.”
 Reopen: If the bug persists even after the developer has fixed the bug,
the tester changes the status to “reopened”. Once again the bug goes
through the life cycle.
 Closed: If the bug is no longer exists then tester assigns the status
“Closed.”
 Duplicate: If the defect is repeated twice or the defect corresponds to
the same concept of the bug, the status is changed to “duplicate.”
 Rejected: If the developer feels the defect is not a genuine defect then it
changes the defect to “rejected.”

Downloaded by Deep Patel


lOMoARcPSD|34814445

 Deferred: If the present bug is not of a prime priority and if it is expected


to get fixed in the next release, then status “Deferred” is assigned to such
bugs
 Not a bug: If it does not affect the functionality of the application then the
status assigned to a bug is “Not a bug”.

3. Describe various defects reporting process with example.


Answer: Defect reporting process in Medium Scale Organization is:

Defect reporting process in Large Scale Organization is:

Downloaded by Deep Patel


lOMoARcPSD|34814445

Downloaded by Deep Patel


lOMoARcPSD|34814445

Exercise

1. Generate online library management system with the help of following


website. Perform at least 4 tests for same. Prepare defect report for
library management system
https://librarika.com/

Test Test Case Name Actual Input Expected Actual Output Statu
Case Output s
TC_0 Home > Features Click on Features It should It redirects to Pass
1 redirect to features page
features page

TC_0 Home > Plans Click on Plans It should t redirects to Pass


2 redirect to Plans page
Plans page
TC_0 Home > Upgrade Click on Upgrade It should It redirects to Pass
3 redirect to Upgrade page
Upgrade page
TC_0 Home > Articles lick on Articles It should It redirects to Pass
4 redirect to Articles page
Articles page

TC_0 Home > Discover Click on Discover It should It redirects to Pass


5 redirect to Discover pag
Discover page

TC_0 Home > FAQ's Click on FAQ's It should It redirects to Pass


6 redirect to FAQ's page
FAQ's page

TC_0 Home > Create Free Click on Create Free It should It redirects to Pass
7 Library Library redirect to Create New
Create New Library page
Library page

TC_0 Home > Create Free Library Nickname = It should It accepts the Pass
8 Library "VPLib" accept the data
data

TC_0 Home > Create Free Library Name = It should It accepts the Pass
9 Library "Vidyalankar accept the data
Polytechnic Library" data

Downloaded by Deep Patel


lOMoARcPSD|34814445

TC_1 Home > Create Free Library Type = "College It should It accepts the Pass
0 Library library" accept the data
data

TC_1 Home > Create Free Library Library Email It should It accepts the Pass
1 Library = accept the data
"[email protected] data
"
TC_1 Home > Create Free Library Password = It should It accepts the Pass
2 Library "vplib@03" accept the data
data

TC_1 Home > Create Free Confirm Password = It should It accepts the Pass
3 Library "vplib@03" accept the data
data

TC_1 Home > Create Free Country = "India" It should It accepts the Pass
4 Library accept the data
data

TC_1 Home > Create Free Click on I agree, please It should It creates a Pass
5 Library create my library create a Librar
Library

Defect Report:
ID Def_01
Project Librarika
Product https://librarika.com/
Release v1.0
Version
Module Home Page>Image in div
Detected V1.1
Build
Version
Summary First image not found
Descriptio The First image in the sequence is not found.
n
Steps to 1) Open the website
Replicate 2) Scroll down till the parallax ends
Actual It does not display the logo of a particular college.
Results

Downloaded by Deep Patel


lOMoARcPSD|34814445

Expected It should display the image of some college logo.


Results
Attachme
nts

Remarks Causes inconvenience to the user.


Defect Low
Severity
Defect Low
Priority
Reported Anurag Dubey
By
Assigned Supriya Angne
To
Status Assigned

Downloaded by Deep Patel


lOMoARcPSD|34814445

DEPARTMENT OF COMPUTER
ENGINEERING

Subject: Software Testing Subject Code: 22518


Semester: 5 Course: CO5I-A
Laboratory No: Name of Subject Teacher: Supriya Angne
Name of Student: Anurag Dubey Roll Id: 19203A0013

Experiment No: 11
Title of Experiment Validating Defect report for ATM Machine.

Practical Related Questions


1. Define Defect Deduction Percentage.
Answer: Defect Deduction Percentage: The number of defects found by a test
phase, divided by the number found by that test phase and any other means
afterwards.

2. Describe Defect Reporting Process.


Answer:

 Defect Reporting in software testing is a process in which test managers


prepare and send the defect report to the management team for
feedback on defect management process and defects’ status.
 Then the management team checks the defect report and sends
feedback or provides further support if needed.
 Defect reporting helps to better communicate, track and explain defects
in detail.
 The management board has right to know the defect status.
 They must understand the defect management process to support you
in this project.
 Therefore, you must report them the current defect situation to
get feedback from them.

Downloaded by Deep Patel


lOMoARcPSD|34814445

3. Describe Defect Report Template.


Answer:
ID Unique identifier given to the defect. (Usually Automated)

Project Project name.

Product Product name.

Release Version Release version of the product. (e.g. 1.2.3)

Module Specific module of the product where the defect was detected.

Detected Build Build version of the product where the defect was detected
Version (e.g. 1.2.3.5)

Summary Summary of the defect. Keep this clear and concise

Description Detailed description of the defect. Describe as much as


possible but without repeating anything or using complex
words. Keep it simple but comprehensive.

Steps to Step by step description of the way to reproduce the defect.


Replicate Number the steps.

Actual Result The actual result you received when you followed the steps.

Expected The expected results.


Results

Attachments Attach any additional information like screenshots and logs.

Remarks Any additional comments on the defect.

Downloaded by Deep Patel


lOMoARcPSD|34814445

ID Unique identifier given to the defect. (Usually Automated)

Defect Severity Severity of the Defect.

Defect Priority Priority of the Defect.

Reported By The name of the person who reported the defect.

Assigned To The name of the person that is assigned to analyze/fix the


defect.

Status The

Fixed Build Build version of the product where the defect was fixed (e.g.
Version 1.2.3.9)

Downloaded by Deep Patel


lOMoARcPSD|34814445

Exercise

1. Use ATM machine system simulator with the help of following website.
Perform at given task and generate test case. Prepare defect report for
ATM machine system.
Task
i. Enter Pin number of 4 digits.
ii. Select Amount to be withdrawn.
iii. In other functions, Check for Balance on Screen
iv. In other functions, Print Mini Statement
v. Verify functionality of Change Pin number.
vi. Verify withdrawal of amount excess of 5000.

https://www.motc.gov.qa/en/ditoolkit/migrant-workers/cash-
machinesimulator-atm

Test Case:

Test Test Case Name Actual Input Expected Actual Output Status
Case Output
TC_01 Pin Number Enter 4 digit pin-1234 It should It accepts the Pass
accept the pin pin and
and proceed proceeds to the
to the main main page
page.

TC_02 Withdraw Select amount - 2000 It should It is Pass


withdraw the withdrawing
money the money

TC_03 Balance on screen Select Balance on It should It is displaying Pass


screen in other display the the balance on
functions screen balance on screen
screen balance
on screen

TC_04 Mini Statement Select mini statement It should print It is printing the Pass
in Other functions the mini mini statement
statement

Downloaded by Deep Patel


lOMoARcPSD|34814445

TC_05 Change Pin Select Change Pin in It should ask It is asking for Pass
other functions for the new the new pin
pin and and changed It
change it with with the old
the old one. one.

TC_06 Withdrawal Select Cash It should allow It is not Pass


withdrawal option the user to displaying the
select option to
denomination select
of 5000. denomination
of 5000.

Downloaded by Deep Patel


lOMoARcPSD|34814445

Defect Report
ID Def_01
Project Cash Simulator Cash (ATM)
Product https://www.motc.gov.qa/en/ditoolkit/migrant-workers/cash-machine-simulator-atm
Release v1.0
Version
Module Home Page> Our Programs > Digital Inclusion tools
Detected V1.1
Build
Version
Summary Limited denomination options in cash withdrawal function, restricting cash withdrawal
only till 3000.
Descriptio No option of withdrawing of amount excess of 3000
n
Steps to 1) Open the website
Replicate 2) Select our programs
3) Proceed to Digital Inclusion tools and select
cash machine simulator (ATM)
4) Select language and skip to simulator
5) Enter the card
6) Select the account type
7) Go to Other functions and select cash withdrawal
Actual It has displaying limited options of denominations in cash withdrawal option.
Results
Expected It should add more options in denominations in withdrawal function or it should take
Results amount input from the user.

Downloaded by Deep Patel


lOMoARcPSD|34814445

Attachme
nts

Remarks Causes inconvenience to the user in terms of limited cash withdrawal options.
Defect High
Severity
Defect High
Priority
Reported Anurag Dubey
By
Assigned Supriya Angne
To
Status Assigned

Downloaded by Deep Patel


lOMoARcPSD|34814445

DEPARTMENT OF COMPUTER
ENGINEERING

Subject: Software Testing Subject Code: 22518


Semester: 5 Course: CO5I-A
Laboratory No: Name of Subject Teacher: Supriya Angne
Name of Student: Anurag Dubey Roll Id: 19203A0013

Experiment No: 12
Title of Experiment Executing Test Case to Generate Defect Report for Login.

Practical Related Questions


1. What is the significance of encryption while saving password in database?
Answer:
 Encryption scrambles your password so it's unreadable and/or
unusable by hackers.
 That simple step protects your password while it's sitting in a
database, and it offers more protection as your password zooms
across the internet.

2. Give the significance of POST method while performing operations on


web based
Answer:
 POST is a request method supported by HTTP used by the World
Wide Web.
 By design, the POST request method requests that a web server
accept the data enclosed in the body of the request message, most
likely for storing it.
 It is often used when uploading a file or when submitting a
completed web form.

Downloaded by Deep Patel


lOMoARcPSD|34814445

3. Define step to write a defect report for given application


Answer: `
1. State the platform version.
2. Login and examine data.
3. List any non-standard configuration setting with values.
4. State the workflow direction through application.
5. Research to narrow down the root cause and get beyond the
defect symptom:
 Define who, what, where, when and how you got found the defect.
 Scan error logs.
 Execute database queries.
6. Add support documentation:
 Screenshots.
 Stop recording files.
 Video.
 Database query results.
7. Format all texts for reliability of easy understanding. Stick to known
familiar format.

Downloaded by Deep Patel


lOMoARcPSD|34814445

Exercise:

1. Use Login system simulator with the help of following website. Perform
given task and generate test case. Prepare defect report for Login system.
 Task
1. Enter invalid user name.
2. Enter invalid password.
3. Enter password with only 3 characters.
4. Enter user name as "invitado" and password as "hgm2015".
5. https://codepen.io/opensoorce/pen/KQmvd

Test Test Case Actual Input Expected Output Acutal Output Status
Case Name
TC_01 To enter Enter It should not It does not accept Pass
invalid username as accept invalid username and
username “abcdefg” username. throws a message
saying “Please
enter correct
username and
password”
TC_02 To enter Enter It should not It does not accept Pass
invalid password as accept invalid the password and
password “pass@45” password. throws message
saying
“Please enter
correct username
and password”.
TC_03 To enter Enter It should not It does not accept Pass
password password accept three password and
with three with three character invalid throws message
characters characters as password. saying “Please
only “abc” enter correct
username and
password”.
TC_04 To test Enter It should accept It accepts valid Pass
whether it username as valid username and
accepts “invitado” usernameand password and
valid and password password throws message

Downloaded by Deep Patel


lOMoARcPSD|34814445

username as saying “Valid


and “hgm2015” please wait”
password

2. Consider any web base system which provides login procedure.


Perform following tests for same. Prepare defect report for Login
System.
 Task
1. Verify forgot password link.
2. Test user name as "STEPR" and password as "STEPR".
 Verify captcha for given system
Test case for any GitHub Sign up

Test Test Case Name Actual Input Expected Output Acutal Output Statu
Case s
TC_0 To test forgot Clink on It should send Forgot Pass
1 password link forgot forgot password password link
password link link to is received
and enter registered email and on
registered address which clicking the
email. will allow you link leads you
to create a new to a site where
password you enter your
new password
and on
submitting
password is
changed.
TC_0 Functionality Checks It should check It is checking Pass
2 of close button functionality functionality of functionality
of close close button. of close
button. button.
TC_0 To test In username It should not It shows an Pass
3 username as enter”STEPR accept message
“STEPR” and ” and username and saying
password as password password. “password
“STEPR” as”STEPR” length should

Downloaded by Deep Patel


lOMoARcPSD|34814445

be 6 to 126
characters”
TC_0 To verfiy the Displayed It should not It does not Pass
4 captcha for the captcha is accept wrong accept the
given system “5Bn35” and captcha captcha and it
entered is shows the
“5Bn30” message as
“invalid
captcha” and a
new captcha is
now placed
TC_0 To verfiy the Displayed It should not It accepts Pass
5 captcha for the captcha is accept wrong captcha and it
given system “2A031” and captcha proceeds
entered is further to next
“2A031” details.

Downloaded by Deep Patel


lOMoARcPSD|34814445

DEPARTMENT OF COMPUTER
ENGINEERING

Practical Related Questions


1. Compare any two software testing tools used in automation testing.
Answer:
Features
Katalon Selenium TestComplete UFT (QTP)
Studio

Test Cross- Cross- Windows Windows


developme platform platform
nt platform
Application Web Web apps Windows Windows
under test and desktop, desktop,
mobile web, web,
apps mobile apps mobile apps
Scripting Java/Groov Java, C#, JavaScript, VBScript
languages y Perl, Python,
Python, VBScript,
JavaScript, JScript,
Ruby, PHP Delphi,
C++, and C#
Programmi Not Advanced Not required. Not required.
ng skills required. skills needed Recommended Recommended

Downloaded by Deep Patel


lOMoARcPSD|34814445

Recommen to integrate for for


ded for various advanced advanced
Subject: Software Testing Subject Code: 22518
Semester: 5 advanced tools Course: CO5I-Atest scripts test scripts
Laboratory No: test scripts Name of Subject Teacher: Supriya Angne
Name of Student: Anurag Dubey Roll Id: 19203A0013
Learning Medium High Medium Medium
curves
Experiment No: 14
TitleEase of
of Experiment Easy to and
Design set run test
Require
cases for MS Easy
Wordtoapplication
setup Easyanto setup
using
installation automation
up and run tool installing and run and run
and use and
integrating
various tools
Script Quick Slow Quick Quick
creation
time
Object Built-in XPath, Built-in Built-in
storage object UI Maps object object
and repository, repository, repository,
maintenan XPath, detecting smart object
ce object re- common detection and
identificatio objects correction
n
Image- Built-in Require Built-in support Built-in
based support installing support,
testing additional image-based
libraries object
recognition
Continuous Popular Various Various CI tools Various CI
integration CI tools CI tools (e.g. Jenkins, tools (e.g.
s (e.g. (e.g. HP Quality Jenkins, HP
Jenkins, Jenkins, Center) Quality
Teamcity) Cruise Center)
Control)
Downloaded by Deep Patel
lOMoARcPSD|34814445

Downloaded by Deep Patel


lOMoARcPSD|34814445

Product Ticketing Open source Dedicated staff, Dedicated


support support, community community staff,
community community
License Freeware Open source Proprietary Proprietary
type (Apache 2.0)
Cost Free Free License and License and
maintenance maintenance
fees fees

2. List some advantages and disadvantages of Automation testing.


Answer:
Advantages of Automated Testing:
1. Automated testing improves the coverage of testing as
automated execution of test cases is faster than manual
execution.
2. Automated testing reduces the dependability of testing on the
availability of the test engineers.
3. Automated testing provides round the clock coverage as automated
tests can be run all time in 24*7 environment.
4. Automated testing takes far less resources in execution as compared
to manual testing.
5. It helps to train the test engineers to increase their knowledge
by producing a repository of different tests.

Disadvantages of Automated Testing:


1. Automated testing is very much expensive than the manual testing.
2. It also becomes inconvenient and burdensome as to decide who
would automate and who would train.
3. It has limited to some organisations as many organisations not prefer
test automation.
4. Automated testing would also require additionally trained and
skilled people.

Downloaded by Deep Patel


lOMoARcPSD|34814445

5. Automated testing only removes the mechanical execution of


testing process, but creation of test cases still required testing
professionals.

3. Enlist the different factors which are determining the effectiveness


of Automation testing.
Answer:
1. Build a dedicated team
Test automation is a dedicated and focused activity to consider, and cannot
be mixed. So, it is important to bring a dedicated team on board for the
same.
2. Selecting the tool
It is important to select a tool that is compatible with the organization and
the people who would be involved in the process.
3. Finding the right tool is just the beginning
The tool cannot be implemented everywhere, as it might not cover
every scenario. But if blended with the right strategy and skill sets, the
tool will provide the expected results.
4. Blend every aspect together for desired results
It is advisable to begin the automation process by creating the test case in
a manual format - collect all the requirements and testing data to build the
automation plan.
5. Know your software/application
This will help implement the tool effectively and enable the right third-
party integrations. This will ensure effective automation even in the future.
Moreover, it will help identify any possible defects, memory leaks,
performance issues, scalability issues, and more.
6. Automation cannot be done for everything
You will have to loop in and recruit the right processes that can meet the
desired goals.

Downloaded by Deep Patel


lOMoARcPSD|34814445

4. State some good coding practices while automation.


Answer: `

1. Always use test design patterns and principles


2. Never use Thread.sleep() unless there are specific test requirements
3. Do not run ALL tests across ALL target browsers
4. Separate your tests from your test automation framework
5. Make your test automation framework portable
6. Name your tests wisely
7. Use soft assertions if you need to make a list of related checks on the
same web page
8. Take screenshots for failure investigation
9. Make tests simpler instead of adding comments
10. Follow the “green tests run” policy

11. Use data-driven instead of repeated tests

12. All tests should be independent

13. Setup detailed automation tests reporting

Downloaded by Deep Patel

You might also like