It is important to verify that the software
- performs its basic functions as intended,
- is able to gracefully handle an abnormal situation.
The entire testing effort
can be basically generalized
into two categories:
- positive testing paths
- and negative testing paths.
Testing aimed at showing software works.
This is also known as “test to pass”.
The first form of testing
that a tester would perform on an application
running test scenarios
that an end user would run for their use
with only correct and valid data.
If a test scenario doesn’t need data,
running the test exactly the manner
in which it’s supposed to run
to ensure that the application is meeting the specifications.
Happy Path Testing and Smoke Tests
basic, non-extensive software testing practice,
where you put the code developed so far
through fundamental, ‘happy path’ use cases
to see if the system breaks.
featuring no exceptional or error conditions.
Happy Path Testing
(Subset of Positive Testing)
is a well-defined test case
using known input,
which executes without exception
and produces an expected output.
- Happy day scenario
- sunny day scenario
- golden path
E.g., the happy path for a function
validating credit card numbers
would be where
none of the validation rules raise an error,
thus letting execution continue successfully to the end,
generating a positive response.
In use case analysis,
there is only one happy path,
but there may be any number
of additional alternate path scenarios
which are all valid optional outcomes.
If valid alternatives exist,
the happy path is then identified
as the default
or most likely positive alternative.
In contrast to the happy path,
process steps for
- alternate paths
- and exception paths
may also be documented.
Alternate Path Testing
Sometimes there may be more than one way
of performing a particular function or task
with an intent
to give the end user more flexibility
or for general product consistency.
This is called alternate path testing
which is also a kind of positive testing.
In alternate path testing,
the test is again performed to meet its requirements
but using the different route than the obvious path.
The test scenario would even consume
the same kind of data
to achieve the same result.
Negative Testing/ Unhappy Path
is done to ensure the stability of the application
applying as much creativity as possible
while testing the application against invalid data.
(Although sometimes negative testing is referred to as
testing aimed at showing software does not work.
Also known as “test to fail”.)
- unhappy paths
- sad paths,
- rainy day
- exception paths
- error path testing
- failure testing
- to check if the errors are being shown to the user
where it’s supposed to,
- or handling a bad value more gracefully.
Example of negative testing for a pen:
(The basic motive of the pen is to be able to write on paper)
- Change the medium that it is supposed to write on, from paper to cloth or a brick and see if it should still write.
- Put the pen in the liquid and verify if it writes again.
- Replace the refill of the pen with an empty one and check that it should stop writing.
Happy Path vs. Sad Path vs. Bad Path
Sometimes test cases are categorized into:
- Happy Path
E.g., Entering proper user name and password in the login page.
- Sad Path
(scenarios which do not take us further and get stuck)
E.g., Entering wrong password and username.
- Bad Path
(don’t fetch any results and makes us lost)
Entering the junk characters in the username
Sources: Wikipedia, h2kinfosys.com, softwaretestinghelp.com