Test Scenario

Example 1: Test Scenario for eCommerce Application

For an eCommerce Application, a few test scenarios would be

Test Scenario 1: Check the Login Functionality

In order to help you understand the difference Test Scenario and Test Cases,
specific test cases for this Test Scenario would be

1. Check system behavior when valid email id and password is entered.

2. Check system behavior when invalid email id and valid password is entered.
3. Check system behavior when valid email id and invalid password is
entered.
4. Check system behavior when invalid email id and invalid password is
entered.
5. Check system behavior when email id and password are left blank and Sign
in entered.
6. Check Forgot your password is working as expected
7. Check system behavior when valid/invalid phone number and password is
entered.
8. Check system behavior when “Keep me signed” is checked
As evident, Test Cases are more specific.

Test Scenario 2: Check the Search Functionality

Test Scenario 3: Check the Product Description Page

Test Scenario 4: Check the Payments Functionality

Test Scenario 5: Check the Order History
Apart from these 5 scenarios here is the list of all other scenarios

 Check Home Page behavior for returning customers

 Check Category/Product Pages
 Check Customer Service/Contact Pages
 Check Daily Deals pages

Example 2:  Test Scenarios for a Banking Site

Test Scenario 1: Check the Login and Authentication Functionality

Test Scenario 2: Check Money Transfer can be done

Test Scenario 3: Check Account Statement can be viewed

Test Scenario 4: Check Fixed Deposit/Recurring Deposit can be created

Example 2

What Is A Test Scenario?

Consider a hypothetical situation: There is a vast ocean. You have to travel across the
ocean from one seashore to another. For example, from Mumbai, India Seashore to
Colombo, Srilanka seashore.
The mode of travel you can opt for are:
(i) Airways: Take a flight to Colombo

(ii) Waterways: Prefer a ship to travel to Colombo

(iii) Railways: Take a train to Srilanka

 Now for the Test Scenarios: Traveling from Mumbai seashore to Colombo seashore is a
functionality that is to be tested.
The Test Scenarios include:
 Traveling by Airways,
 Traveling by Waterways or
 Traveling by Railways.
These test scenarios will have test cases.

Test cases that can be written for the above Test Scenarios include:
Test Scenario: Travelling By Airways
Test cases can include scenarios like:
1. The flight is as per the scheduled time.
2. The flight is not as per the scheduled time.
3. An emergency situation has ensued (heavy rainfall and storm).
In the same way, a separate set of test cases can be written for other remaining scenarios.

Now let’s get to the technological test scenarios.

Anything that can be tested is a Test Scenario. Thus we can state that any software
functionality that is under test can be divided into multiple smaller functionalities and can be
termed a ‘Test Scenario’.
Before delivering any product to the client, the quality of the product needs to be appraised
and evaluated. Test scenario aids in assessing the functional quality of a software application
that is in conformance with its business requirements.

A tester scenario is a process wherein the tester tests a software application from an end-user
perspective. The performance and quality of the software application are thoroughly assessed
before implementation in the production environment.

Importance Of Test Scenario

 One Test Scenario can have multiple ‘Test Cases’. It can be figured as a big panoramic
image and test cases are the small parts that are important to complete the panorama.
 It is a single line statement and test cases comprise step-wise description to complete
the purpose of the test scenario statement.
 Example:
Test Scenario: Make the payment for the cab service availed.
This will have multiple test cases as stated below:
(i) Payment method to be used: PayPal, Paytm, Credit/Debit Card.
(ii) The payment done is successful.
(iii) Payment done is unsuccessful.
(iv) The payment process aborted in between.
(v) Not able to access payment methods.
(vi) The application breaks down in between.
 Test Scenarios thus assist in evaluating the software application as per the real-world
situations.
 Test scenarios when determined, help in bifurcating the scope of testing.
 This bifurcation is termed prioritization which helps in determining the important
functionalities of the software application.
 Prioritized testing of the functionalities, assists to a great extent in the successful
implementation of the software application.
 As the test scenarios get prioritized, the most important functionalities can be easily
identified and tested on priority. This ensures that the majority of the crucial
functionalities are working fine and defects related to it are duly captured and rectified.
 Test scenarios determine the business process flow of the software and thus end-to-end
testing of the application is possible.

Example 3

Example of Test scenarios

Here we are taking the Gmail application and writing test scenarios for different
modules which are most commonly used such as Login, Compose, Inbox, and
Trash

Test scenarios on the Login module

o Enter the valid login details (Username, password), and check that the home page is
displayed.
o Enter the invalid Username and password and check for the home page.
o Leave Username and password blank, and check for the error message displayed.
o Enter the valid Login, and click on the cancel, and check for the fields reset.
o Enter invalid Login, more than three times, and check that account blocked.
o Enter valid Login, and check that the Username is displayed on the home screen.

Test scenarios on Compose module

o Checks that all users can enter email ides in the To, Cc, and Bcc.
 o Check that the entire user can enter various email ids in To, Cc, and Bcc.
o Compose a mail, send it, and check for the confirmation message.
o Compose a mail, send it, and check in the sent item of the sender and the inbox.
o Compose a mail, send it, and check for invalid and valid email id (valid format), check
the mail in sender inbox.
o Compose main, discard, and then check for conformation message and check-in draft.
o Compose mail click on save as draft and check for the confirmation message
o Compose mail click on close and check for conformation save as drafts.

Test scenarios on Inbox module

o Click on the inbox, and verify all received mail are displayed and highlighted in the
inbox.
o Check that a latest received mail has been displayed to the sender email id correctly.
o Select the mail, reply and forward send it; check in the sent item of sender and inbox of
the receiver.
o Check for any attached attachments to the mail that are downloaded or not.
o Check that attachment is scanned correctly for any viruses before download.
o Select the mail, reply and forward save as draft, and check for the confirmation
message and checks in the Draft section.
o Check all the emails are marked as read are not highlighted.
o Check all mail recipients in Cc are visible to all users.
o Checks all email recipients in Bcc are not visible to the users.
o Select mail, delete it, and then check in the Trash section.

Test scenario on Trash module

o Open trash, check all deleted mail present.
o Restore mail from Trash; check-in the corresponding module.
o Select mail from trash, delete it, and check mail is permanently deleted.

Positive or negative classification of test scenarios/cases

Test design process is 3 fold:

 Identify requirements
 Write test scenarios (one line pointers of what to test)
 Design detailed instructions on how to test (test cases)
When writing test scenarios, we classify them into positive and negative conditions. (When you think
about it, is it really important to make this classification? If yes, what purpose does it serve? We have to
test them all anyways, isn’t it?) It beats me too, for the most part. But I think it is an attempt to establish
adequate coverage and helps to establish that we are testing both the happy and alternate paths the
system is supposed to handle. Please comment below, if you know of any other reasons why this is
done.

Now, let’s look at a few requirements, write test scenarios and perform the classification.
#1) Login: A user who enters correct credentials gets into the system. If the credentials are incorrect,
access is denied and an error message is displayed.
#2) View products: Let’s assume there is an online catalog of all the products available in the system
and it displays them all in a list when “View products” link is clicked.
#3) Logout: When clicked on this link, the user is logged out.
I am going to write few Test scenarios for these requirements.
Table A: The right way
Test scenario ID Test scenario description Positive/Negati

TS_login_01 Validate if the user logs in successfully if the credentials entered are correct Positive

TS_login_02 Validate if the user is not allowed access when the credentials entered are incorrect Negative

TS_ViewProduct_01 Validate if all the items are listed when View products link is clicked Positive

TS_logout_01 Validate if the already logged in user is signed out of the system when logout is Positive
clicked

However, sometimes I see the Test scenario written like this.

Table B: Entries marked Red are invalid test scenarios.

Test scenario ID Test scenario description Positive/Negati

TS_login_01 Validate if the user logs in successfully if the credentials entered are correct Positive

TS_login_02 Validate if the user is not allowed access when the credentials entered are incorrect Negative

TS_ViewProduct_01 Validate if all the items are listed when View products link is clicked Positive

TS_ViewProduct_02 Validate if the all the items are not listed when view products link is clicked Negative

TS_logout_01 Validate if the already logged in user is signed out of the system when logout is Positive
clicked

TS_logout_02 Validate if the user does not log out when logout link is clicked Negative

For login’s successful case, there is an equal and opposite case when it won’t be successful. Not all
requirements are supposed to be that way and for them, there is really no compulsion to write a
negative scenario.
Bottom line: Not every requirement should have negative cases.
At this point, if you are thinking “How will I know” or “I’m still not sure”, here is a simple cheat sheet that
will help.

If there is one generalization we can make about applications is that they are dynamic. The input (data,
clicks, etc.) that we provide will cause the application to be a certain way and generate a certain output.

A simple correlation between the input and output variables will make this easy to comprehend.

Let us try the following for login:

Input Output Positive/Negative

Correct (correct login info) Correct (User logged in) Positive

Incorrect (incorrect login info) Correct (An error message) Negative

Correct (correct login info) Incorrect - Login fails Bug/Defect

Incorrect (incorrect login info) Incorrect (system logs them in) – “Oh, the horror!” :) Bug/defect

So, you see from the above table, we can say that we categorize the primary flow as positive and the
alternate flow (also the correct behavior of the application) is marked as negative.

The last two cases in red are in fact, bugs. Testing is about validation of requirements and when they
don’t work as intended, we find bugs. Since we don’t go validating for defects, the last two cases are
invalid.

Following the same line of thought and applying it to logout and view products, here is what you will
get.

Input Output Positive/Negative

Logout (click) Correct - Logs out Positive

Logout (click) Incorrect - Stays signed in Bug/defect

View products (click) Correct - Displays products Positive

View products (click) Incorrect (not list or incorrect list display) Bug/defect

As you can see, for these requirements, there isn’t a possibility to supply an incorrect input. Therefore,
there need not be negative test scenarios/cases written