STE Manual
STE Manual
STE Manual
ENGINEERING
Experiment No: 01
Title of Experiment Design test cases for purchase order management based on system specification.
Test Test case Actual input Expected output Actual output Status
case name
id
TC_01 Username Enter Username = It should accept the It accepted the pass
" abcde123" username username
TC_02 Username Enter Username = It shouldn’t accept the It didn’t accept the pass
"abcde" username username
TC_03 Username Enter Username = It should accept the It accepted the pass
"abcdef1234567 89 username username
"
TC_04 Username Enter Username = It shouldn’t accept the It didn’t accept pass
"abcdefg12345678 9" username the username
TC_05 Username Enter Username = " It should accept the It accepted the pass
abcde@123" username username
TC_06 Username Enter username It should accept the It accepted the pass
="abcde123" username username
TC_07 Username Enter username It shouldn’t accept the It didn’t accept the pass
="123abcde" username username
TC_08 Username Enter username It shouldn’t accept the It didn’t accept the pass
="abcde 123" username username
TC_09 Password Enter password It should accept the It accepted the pass
="accept12 password password
TC_10 Password Enter password It shouldn’t accept the It didn’t accept the pass
= "accept" password password
TC_11 Password Enter It should accept the It accepted the pass
password="accept @1" password password
TC_12 Password Enter password="copy It shouldn’t accept the It didn’t accept the pass
paste" password password
TC_13 Password Enter password="acc1 It shouldn’t accept the It didn’t accept the pass
2" password password
TC_14 Submit 1) Username="ab cde It should proceed to It proceeded to pass
123". next page next page
Password="ac cept
123".
Click on Submit button
TC_15 Submit Username="abcd e123". It shouldn’t proceed to It didn’t proceed to pass
Password="acc ept ". next page next page
Click on
Submit button.
TC_16 Submit Username="ab cde ". It shouldn’t proceed to It didn’t proceed to pass
Password="afv k uh". next page next page
Click on
Submit button.
TC_17 Submit Username= " nvgg". It shouldn’t proceed to It didn’t proceed to pass
Password="hvs gu gs". next page next page
Click on Submit button.
TC_18 Clear Username="ab cde123". It should clear the It cleared username pass
Password="acc ept123". username and and password
Click on Clear button. password
TC_19 Clear Username="". It should clear the It cleared username pass
Password="". username and and password
Click on Clear button. password
2. Test cases for purchase order system.
TC_13 review 1) Select the It should review the It is reviewing the pass
product product.2) Click on product product
review product
button.
It should prompt the It is prompting
TC_14 review 1)click on review message of “First the message pass
product product button select product"
1)Select the product.
TC_15 Submit 2)Enter the quantity. It should generate It is generating the pass
3) Add the order id order id
product.
4) Click on submit
button.
1)click on submit It should prompt the
TC_16 Submit button message of “Fill the it is prompting the pass
details". message
Practical Related Question
Answer:
1. Finding Errors
- Testing is process of executing a program with an intention of finding an error.
2. Creating good test cases
- A good test case is one that has a high probability of finding yet undiscovered error.
3. Quality Improvement
- Defects are fixed by developer, so quality is improved
Anwer: For designing test cases, a tester who is performing test cases needs a
software requirement specification to design test cases.
3) Static vs dynamic testing
Static testing gives assessment of code Dynamic testing finds bugs in the
and documentation software application
Static testing involves checklist and Dynamic testing involves test cases for
process to be followed. execution.
It is performed in the early stage of the It is performed at the later stage of the
software development. software development.
When to start ?
1. Testing starts from requirement phase and continues till the end of
SDLC(software development lifecycle)
2. SDLC testing can be started from requirement gathering phase and last till
the development of the software.
3. however it also depends on the development model that is being used for
ex. in waterfall model testing is conducted in testing is performance at the
end of every increment
When to stop?
1. Unlike when to start testing , it is difficult to determine when to stop.
testing is never ending process, and no one can say that any software is
100% tested.
following other aspect which should be considered to stop the testing
A. Testing deadline
C. Bug rate falls below a certain level and no high priority bugs are found
D. Management Decision
a. statement/line coverage
b. branch coverage
c. condition coverage
d. function coverage.
DEPARTMENT OF COMPUTER
ENGINEERING
Experiment No: 02
Title of Experiment Design test cases for purchase order management based on system specification.
Answer:
Experiment No: 03
Title of Experiment 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_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)
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_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
Answer: The key features to be tested in Black Box Testing are as follows:
Requirements
Boundary Value Analysis
User Documentation
Decision table
Equivalence Partitioning.
Answer: The sources of knowledge for Black Box Testing are as follows:
User Requirements
System Requirement Specification
Design Documentation
Experiment No: 04
Title of Experiment Test various functionality of railway reservation system.
Page | 1
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 to It is going to Pass
Button next page and next page and
ask for OTP asking for 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 to It is going to Pass
Button next page and next page and
show Search Showing search
Station station
TC_20 Search " Search Station = It should accept It accepted the Pass
Station Mumbai Central the data and go data and going
(MMCT) " to (Search to (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 and
show all showing all
available train 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
Page | 2
of booking from conformation
user from user
Page | 3
Practical Related Questions
2. What are different test methodologies that shall be applied while testing
railway reservation system? Justify.
Page | 4
3. Give the significance of system testing in railway reservation system.
Page | 5
DEPARTMENT OF COMPUTER
ENGINEERING
Experiment No: 05
Title of Experiment Validate login procedure for E-Commerce application
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_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 =
';.[@"
Practical Related Questions
1. What are the security threats for E-Commerce Systems?
Answer: The various security threats for an E-Commerce System are as follows:
2. List various authentication protocols that can be used in providing security for
E-Commerce System
Answer: Various encryption techniques that can be used to provide storing login
credentials are as follows:
Experiment No: 06
Title of Experiment Testing Functionality of Web page
Stress testing helps teams define issues that only become visible under
peak load conditions.
During this type of system validation, QA specialists simulate loads that
exceed reasonable estimates to test the performance of web application.
Stress testing prepares the maintenance team for extreme situations and
helps establish triggers of system shutdown for proactive management.
Stress tests can also help you uncover the following:
Synchronization and timing bugs
Interlock problems
Priority problems
Resource loss bugs
Memory leaks
Data loss & corruption
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 Syllabus
Engineering Syllabus page 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 Syllabus
Engineering Syllabus page page
> Second
Year
Syllabus
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 Syllabus
Technology Syllabus page 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 to It redirects to Latest Pass
Latest Updates 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
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
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
DEPARTMENT OF COMPUTER
ENGINEERING
Experiment No: 07
Title of Experiment Design test case for control and decision making statements.
2. For any decision statement what will be the possible outcomes while writing
the test cases.
Answer: Whenever there are two or more possible exits from the statement
like an IF statement, a DO-WHILE or a CASE statement it is known as decision
because in all these statements there are two outcomes, either TRUE or FALSE.
Alternatively, you can say that control statement IF has been evaluated both to
TRUE and FALSE
3. Can we test the relational operator? Validate your answer with
justification.
Answer: Yes, we can test the relational operators.
Example:
Code:
import java.util.Scanner;
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
Exercise:
1. Generate the test case to check the program written for Even and Odd
numbers.
Code:
import java.util.Scanner;
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
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
3. Generate the test case to check the program written for printing the day of
week.
Code:
import java.util.Scanner;
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();
}
}
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 between 1-7.
1-7.
TC_09 Day of Enter a Please enter Please enter Pass
week number: b weekday weekday number
number between between 1-7.
1-7.
TC_010 Day of Enter a Please enter Please enter Pass
week number: # weekday weekday number
number between between 1-7.
1-7.
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);
while(count <= 6) {
if (length >= 100){
length = length - 2;
} else {
length = count * length;
}
count = count + 1;
}
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
DEPARTMENT OF COMPUTER
ENGINEERING
Experiment No: 08
Title of Experiment Prepare Test plan for an identified Mobile Application
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
Test Plan
Swiggy Version 3.77.1
Version: 1.0
Created: 19/11/2021
Last Updated: 19/11/2021
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
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
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
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)
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.
2. TEST STRATEGY
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.
A production-ready software;
A set of stable test scripts that can be reused for Functional and UAT test execution.
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
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.
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.
2.4. Data Approach
In functional testing, WHATSAPP will contain pre-loaded test data and which is used
for testing activities.
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: The below excel sheet details about the scope of Functional test. Note:
The scope is high level due to changes in the requirement.
TEST DELIVERABLES
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
MILESTONE LIST
The milestone list is tentative and may change due to below reasons
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
Business
1. UAT Test Cases Test Team Analyst’s Sign
off
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
3. EXECUTION STRATEGY
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
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.
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).
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.
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
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.
Establishing Incorporating
Understanding Traceability Preparation of Peer Review of Review
Requirements Matrix in Test cases Test cases comments in
qaManager 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
Risk Prob. Impact Mitigation Plan
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.
S Roles Name
N
0
.
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
4.2.1. Project Management
Project Manager: reviews the content of the Test Plan, Test Strategy and
Test Estimates signs off on it.
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).
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.
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.
5. TEST ENVIRONMENT
6. APPROVALS
The Names and Titles of all persons who must approve this plan.
Signature:
Name: Vijay Patil
Date: 14/11/21
Signature:
Date: 14/11/19
3. Prepare test plan for any food application with test cases.
Test Plan
Swiggy Version 3.77.1
Version: 1.0
Created: 14/11/2021
Last Updated: 14/11/2021
Revision and Signoff Sheet
Document History
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
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
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
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)
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.
8. TEST STRATEGY
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.
A production-ready software;
A set of stable test scripts that can be reused for Functional and UAT test execution.
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
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.
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.
8.4. Data Approach
In functional testing, SWIGGY will contain pre-loaded test data and which is used for
testing activities.
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: The below excel sheet details about the scope of Functional test. Note:
The scope is high level due to changes in the requirement.
TEST DELIVERABLES
(4. Daily/weekly status report Test Team/ Test Test Lead/ Project
Lead Manager
MILESTONE LIST
The milestone list is tentative and may change due to below reasons
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
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
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
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.
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).
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.
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
status
Establishing Incorporating
Understanding Traceability Preparation of Peer Review of Review
Requirements Matrix in Test cases Test cases comments in
qaManager 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.
As per Process, final sign-off or project completion process will be followed
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.
S Roles Name
N
0
.
1. Project Manager Vijay Patil
2. Test Lead Vinay Savla
3. Business Analyst Arfia Shaikh
4. Development Lead Sahil Makhijani
S Roles Name
N
0
.
5. Testing Team Vinay Savla
6. Development Team Devesh Vengurlekar
7. Technical Lead Anurag Dubey
Project Manager: reviews the content of the Test Plan, Test Strategy and
Test Estimates signs off on it.
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).
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.
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.
The Names and Titles of all persons who must approve this plan.
Signature:
Date: 14/11/21
Signature:
Date: 14/11/21
DEPARTMENT OF COMPUTER
ENGINEERING
Experiment No: 10
Title of Experiment Generate Defect report for Library Management System.
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 > 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
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 "[email protected] accept the data
" 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
Expected It should display the image of some college logo.
Results
Attachme
nts
Experiment No: 11
Title of Experiment Validating Defect report for ATM Machine.
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)
Actual Result The actual result you received when you followed the steps.
Status The
Fixed Build Build version of the product where the defect was fixed (e.g.
Version 1.2.3.9)
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_04 Mini Statement Select mini statement It should print It is printing the Pass
in Other functions the mini mini statement
statement
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.
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
DEPARTMENT OF COMPUTER
ENGINEERING
Experiment No: 12
Title of Experiment Executing Test Case to Generate Defect Report for Login.
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
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
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.
DEPARTMENT OF COMPUTER
ENGINEERING
Experiment No: 14
Title of Experiment Design and run test cases for MS Word application using an
automation tool