Test Case:
The
testing quality depends on,
·
Mood
of the TE
·
Testing
is not consistent
·
Varies
from person to person
So,
we write test cases.
Test
case is a document which covers all possible scenarios to test all the
feature(s).
It
is a set of input parameters for which the s/w will be tested. The SRS are
numbered so that developers and testing team will not miss out on any feature.
When
do we write test cases?
Customer
gives requirements – developer start developing and they say they need about 4
months to develop this product – during this time, testing team start writing
test cases – once it is done, they send it to test lead who reviews it and adds
some more scenarios – developers finish developing the product and the product
is given for testing – the test engineer then looks at the test cases and
starts testing the product – the TE never looks at the requirements while
testing the product – thus testing is consistent and does not depend on the
mood and quality of the test engineer.
The
list of values derived to test the Amount text field is – Blank, -100, hundred,
100, 6000, Rs100, $100, $+?, 0100, Blankspace100, 100.50, 0, 90
When
writing test cases, actual result should never be written as the product is
still being developed. Only after execution of test cases should the actual
result be written.
Why
we write test cases?
·
To have better test coverage – cover all possible scenarios and
document it, so that we need not remember all the scenarios
·
To have consistency in test case
execution –
seeing the test case and testing the product
·
To avoid training every new engineer
on the product –
when an engineer leaves, he leaves with lot of knowledge and scenarios. Those
scenarios should be documented, so that new engineer can test with the given
scenarios and also write new scenarios.
·
To depend on process rather than on
a person
Let’s
say a test engineer has tested a product during 1st release, 2nd
release and has left the company for the 3rd release. As this TE has
mastered a module and has tested the application rigorously by deriving many
values. If that person is not there for 3rd release, it becomes
difficult for the new person – hence all the derived values are documented, so
that it can be used in feature.
When
developers are developing the 1st product (1st release),
TE writes test cases. In the 2nd release, when new features are
added, TE writes test cases. In the next release, when features are modified –
TE modifies test cases or writes new test cases.
