How to write a complete Test case? Following
are few tips to write a complete test case.
For begining, a few sentence to
clarify what are the test cases and test scenarios and how they are different
and in what order must exist. Starting from the end, let us answer the question
“why?”. Test case is a description, a recipe for tester, dealing with how to
test a given functionality and how to check whether this works correctly.
Looking at the structure, we can identify types of relationship: Test scenario
-> test case -> Test Step. Starting from the end again, because it will
be easier, I can write:
- Test Step – specifies an action to perform, and the
expected response of the test application. For example: Action : Type the
password in the password box, Expected result: Your password should be
dotted / hidden.
- Test Case – a list of test steps. Also defines the
environmental situation and may link to related bugs, requirements etc.
- Test Scenario – usually comes directly from business
requirements or userstory. Management tools often ignore test scenario for
linkage with a list of the requirements. Scenario contains a list of test
cases and often their sequence.
As you can see, varies between a
test case scenario is significant, and often the two concepts are confused.
How to ensure the quality of the test cases are created? How to manage their life cycle? How to deliver them quickly and when developers need it ?
How to ensure the quality of the test cases are created? How to manage their life cycle? How to deliver them quickly and when developers need it ?
1. Template – need one and complete template for creating test cases.
We can create it in a text editor, spreadsheet or buy or customize the tool. I
have written about this in the context of the JIRA.
2. Descriptive and specific – you need a short, concise title and description. Should
clearly define the purpose and scope of their operations. We are writing to all
testers, not only for yourself, use simple language, complicated language
figures are not popular here. Use rather imperative, therefore “Write abc and
press enter” not “I am writing abc, and pressing Enter.”
3. Reusable – one and the same test case can be used in many scenarios.
Let us remember that! Creating a new item, we must imagine a different kind of
use case of our work. I also imagine that test step could be reused, so pay
your attention at this level too.
4. Atomic – the greatest tester nightmare struggled with the manual
testing is a test case, which is too long and doing too much dependency checks.
Person carrying out a process must have a sense of progress, otherwise is
bored, reducing its vigilance, and motivation. Tester may have to perform 100
test cases and do them in one day, but it can also have their 10 and do it for
a week. Let us create test case, which can be performed up to several minutes,
and gain the favor of the other fellow testers, among the satisfied, we can
also include those who write automation scripts.
5. Positive and negative – the next important thing is the order of creation. What
to do when the project manager requests a set of test cases on the day
following approval of an implementation plan? Usually we do not say that he
wanted only the beginning of positive tests, those which check whether the
functionality exists and acts in accordance with the requirement. Give him as
such set as soon as possible, then we can deal with the preparation of a
negative description situation and the relationship between other requirements.
To sum up: Positive -> Negative -> Relationships
6. Refactor – if you already done your job we have to remember that
applications are changing and the changes in the test cases should follow this
process. We can version it, using clone and change method for a given version
number. Head of the tests should determine how many past versions we support
and we should care enough about our current collection of test cases.
7. Test data – there are moments in which along the correct execution of
the test we have to provide some data, which usually (if they are too complex
to be described in the text) are attached as binary files. We need to analyze
whether it is easier to provide test data or may be easier to add the
appropriate test steps.
8. Setup and tear down – if the test case requires the initial configuration, call
a particular component, we need to take this into account in the zero step. It
is also important to cleanup in the last step like in unit testing or
automation, but I believe that during the test manual is worth to preserve this
good practice.
