TEST

SCENARIOS &
TEST CASES
TEST SCENARIO
 A Test Scenario is defined as any functionality that can be tested. It is a
collective set of test cases which helps the testing team to determine the
positive and negative characteristics of the project.
 Test Scenario gives a high-level idea of what we need to test.
TEST CASE
 A Test Case is a set of actions executed to verify a particular feature or
functionality of your software application.
 A Test Case contains test steps, test data, precondition, postcondition
developed for specific test scenario to verify any requirement.
 The test case includes specific variables or conditions, using which a
testing engineer can compare expected and actual results to determine
whether a software product is functioning as per the requirements of the
customer.
EXAMPLES OF TEST
SCENARIO
For an eCommerce application, a few test scenarios would be:
 Test Scenario 1: Check the Search Functionality
 Test Scenario 2: Check the Payments Functionality
 Test Scenario 3: Check the Login Functionality
EXAMPLES OF TEST
CASE
Test cases for the Test Scenario “Check the
Login Functionality” would be:
 Check system behavior when valid email id and
password is entered.
 Check system behavior when invalid email id and valid
password is entered.
 Check system behavior when valid email id and invalid
password is entered.
 Check system behavior when invalid email id and
invalid password is entered.
EXAMPLES OF TEST
CASE
 Check system behavior when email id and password are
left blank and Sign in entered.
 Check Forgot your password is working as expected
 Check system behavior when valid/invalid phone
number and password is entered.
 Check system behavior when “Keep me signed”
is checked
 Test scenarios are mostly
single line statement that tells
what should be tested
BEST
PRACTICES
OF CREATING Scenario description should be
A TEST simple and easy to understand
SCENARIO
A careful assessment of the
stated requirements should be
done
 Test Cases should be transparent and straightforward

Create Test Case by keeping the end user in the mind

BEST
PRACTICES Avoid test case repetition

OF You need to make sure that you will write test cases to
CREATING check all software requirements mentioned in the
specification document
TEST CASES
Never assume functionality and features of your software
application while preparing a test case

Test Cases must be readily identifiable

POSITIVE TESTING
 Positive testing, many times referred to as “Happy path testing” is
generally the first form of testing that a tester would perform on an
application.
 It is the process of running test scenarios that an end user would run for
his use.
 Positive testing entails running a test scenario with only correct and valid
data.
 A test case to demonstrate the requirement has been achieved, often
referred to as a positive test case.
NEGATIVE TESTING
 Negative testing commonly referred to as error path testing or failure
testing is generally done to ensure the stability of the application.
 Negative testing is the process of applying as much creativity as possible
and validating the application against invalid data.
 This means its intended purpose is to check if the errors are being shown to
the user where it’s supposed to or handling a bad value more gracefully.
 Another test case, reflecting an unacceptable, abnormal, or unexpected
condition or data, to demonstrate that the requirement is only achieved
under the desired condition, referred to as a negative test case.
EXAMPLE OF POSITIVE
TESTING
 There is a text box in an
application which can accept only
numbers. Entering values up to
99999 will be acceptable by the
system and any other values apart
from this should not be
acceptable.
 To do positive testing, set the valid
input values from 0 to 99999 and
check whether the system is
accepting the values.
EXAMPLE OF NEGATIVE
TESTING
 Negative testing can be performed
by entering characters A to Z or
from a to z. Either software system
should not accept the values or else
it should throw an error message
for these invalid data inputs.
 In both the testing, the following
needs to be considered:
 Input data
 An action which needs to be
performed
 Output Result