Main Rules of Designing Test Cases

Designing test scripts or, in other ways, test cases today is a quite popular thing because such tool is necessary for providing complete quality of the developed project. For example, test scripts are used as one of the important forms of creating information database on quality of a product as a result of performed work of finding bugs and flaws. Besides that, designing of test cases is a necessary work on any stage of web product development, regardless of its final format or complexity. In other words, work with test cases is performed both in the process of work with a corporate landing page and in the process of creating multi-page Internet store.

But there is another case when test scripts are not designed or are not permanently. This is despite the fact that we have a good QA department but such documentation is not written. In the worse case, the test cases are designed only nominally, in order to pull the wool over the eyes of a client or directors of a company.
But still, regardless the amount of work done by a company, work with test scripts is obligatory in the professional training of any tester.
Next, we will overview the main rules of designing and using such technical documentation.

The Strategy of Writing a Classical Tests Case

Generally, testing any software component requires performing a whole complex of various actions which consist of particular actions which are always performed during development and testing of any project. Hence, any testing includes setting requirements, engineering and designing test cases. And in future – conducting project analysis on the basis of determined requirements.

Checked Template

In fact, any test case should be designed according to the previously determined template which is used by a team during checking all results. Right in such a way, we can hugely simplify the process of work of product development.
So, a classical test case should have the following structure:

  • Action;
  • Expected result;
  • Actual result;

Mentioned items is an obligatory minimum, which you must follow during the work with test scripts. But in some cases, it will be better to widen a set of analyzed components. For example, a test case may include such points as “depth” of script coverage, testing priority, including a case in automated tests, Id of a found bug (error), etc.
A good example of such logic is:

ActionExpected ResultActual Result
Open a “Register” pageA “Register” page must be openedThe action is made (passed)

Available Types of Test Cases

According to the expected result, all test scripts are divided into negative and positive:

  • The negative test case is run both with correct and incorrect data (at least 1 incorrectly set value) and its target is to test determined validation in certain parts of a product and also find out that performed function is not performed during the work of this validator;
  • The positive script is run only on the basis of correct data and checks whether a product is correctly activated on determined function.

A Classical Structure of a Test Case

In the net, you can find numerous possible variations which differ from each other by approaches used. But still, we can define a particular “skeleton”.

Pre ConditionsA set of necessary actions which turn a product into a good state, on which basis we can perform testing. Or a list of performed conditions, testing of which tells us that a system is quite ready for basic testing.
Test Case DescriptionA set of necessary actions which turn a product into a good state, on which basis we can perform testing. Or a list of performed conditions, testing of which tells us that a system is quite ready for basic testing.
Post ConditionsA set of actions which transform developed advances into their primary state.

Necessary Requirements to Test Cases

  • The complete absence of dependence from each other. As performed tests can in future include new requirements or be transformed, it’s very important to avoid dependence or otherwise, you will have a dilemma of testing of not-connected things;
  • Clear description and good chances for finding the bugs;
  • Detailed but not complete information. For example, if you need to run the whole process of authorizing, a test case should include a password and a login.
  • Simple detection of faults. A found bug should be clear;
  • Following the conditions, determined before.

Advantages of Test Cases

  • They require fewer skills from QA than the ones needed for working with other types of testing;
  • They allow to quickly measure a test coverage;
  • Stably performed tests allow to monitor the quality of a build during the whole process of release;
  • Work with test cases is the most structured approach to testing;
  • Executing test scripts doesn’t require numerous additional testing, analytics or work with specialized specifications which will hugely decrease a time of a tester;

Disadvantages of Test Cases

  • Test cases limit “work imagination” of a tester;
  • They allow a person to get used to one template where there is one right decision;
  • Performing the testing of the same type is enduring which decreases a tester’s attention;
  • Test scripts limit tester’s knowledge on the developed product.

It’s Not Enough to Just Understand a Project or Who Should Design Test Cases

Designing scripts is a very complex process which needs a complete concentration and attention to details. It’s not enough to just understand a project and easily write something or type something on a keypad. The whole process is important in itself.
It usually consists of:

  • Good communication between development departments, managers, and users for collecting a whole set of data for performing QA-analysis;
  • Properly set priorities which can separate the more important from the less important;
  • Ability to perform decomposition, in order to test each feature;
  • Ability to work with test design mock-ups;
  • Ability to express the thoughts of a user and properly deliver them to directors or a client.

In fact, we can design numerous test scripts which can’t be executed by a tester or which can help to find trivial problems and flaws. Only the right one will allow to completely decrease the number of tests which should be performed in order to find serious problems in a product. It’s the most important moment in designing test cases.

Useful Recommendations for Testers

To conclude, we will tell about some useful advice:

  • Start testing as soon as possible, before the end of the first sprint;
  • Firstly execute positive tests and only then – negative;
  • Start with simple testing. Use the typical client’s data to interfere with the created environment. Even if this test won’t be passed on such data, try to test not obvious steps;
  • Perform all negative and complex testing only after you end up with simple testing;
  • Divide a product into composite parts and create for each one its list of testing (checklists);
  • Monitor update of the test as soon as a bug has been found of functionality settings have been changed.

About the Author

Inna Vasylenko has about 4+ years of experience in creating test cases, test scenarios and preparing test data. Her primary expertise is the development of software testing documentation in Testmatick – company.

Leave a Comment

Pin It on Pinterest