Enroll into QATUTOR Video Course on 

Useful Attributes Of The Test Case

Lecture 3 - Test Cases and Test Suites -> Quick Intro -> Test Case Structure -> Results Of The Test Case Execution -> Useful Attributes Of The Test Case -> Data-Driven Test Cases

In addition to essential parts like expected result and procedure, test case can have a number of useful attributes that make our lives easier:

            Unique ID




            Revision History


This is an extremely important attribute. A test case without an ID is like a house without an address. The test case ID should be unique, not only within the concrete test suite which contains that test case, but also within all test suites inside the company. The rationale for this is that, as time goes by, it will be necessary to keep test case statistics; update, remove, or move test cases between test suites, etc.


The test case priority reflects how important this test case is. The priority is graded from 1 to n, with 1 being the highest priority. I think that it’s rational for 4 to be the lowest priority.

For example, the test case that checks if the Make Payment button works must be P1, and the test case that checks the color of the Web link “Contact” is P4.

Why do we need to prioritize test cases? Let’s assume that we have two test cases, P1 and P3. We have time enough to execute only one of them. Which one do we pick? P1, of course!

Test case prioritization is especially important during regression testing, i.e. testing of old functionalities (we’ll talk about regression testing a lot in this Course).

Question: How do we assign a test case priority?

Answer: As a rule, the author of the test case decides the importance of the thing being checked by that test case.


This is a description of what we check for a particular test case.


In the Test Case with Credit Card, ER is “10.” What info do we get by looking at “10”? Nothing except two digits. However, the developers of www.sharelane.com have developed the following process to create a code for the result of a transaction:

ShareLane -> – The first digit corresponds to the internal id of the credit card: “1” for Visa, “2” for MasterCard, and “3” for AmEx (see table cc_types: Test Portal>DB>Data>cc_types)

– The second digit is the success code: “0” for a successful transaction, and “1” for a failed transaction.

Now we have the full understanding what “10” means: the transaction with Visa was successful.

The problem is that even the author of the Test Case with Credit Card can forget what “10” means, because in the end, everything is perishable and forgettable (except, of course, high school sweetheart Anna V.) That’s why at the beginning of a test case its author should put in human language the following phrase: “Payment can be made by Visa,” so everyone who must execute that test case will immediately understand what is being tested.


A culinary recipe consists of two parts:

1. A list of ingredients

2. Instructions on how to fry, steam, or bake lucky guys from number 1.

The first part of a recipe is needed to enable a chef to

– see beforehand AND

– in one place

all the necessary components of the recipe and have them ready once the time comes to prepare it. This is a very practical first step.

The setup part of a test case can include:

– Information about existing (also called “legacy”) user accounts or instruction on how to create a new user account.

– Data used in the test case; e.g. default password for testing.

– SQL queries (also called “SQL statements“); i.e., commands used to interact with the database (DB). SQL (pronounced “sequel”) stands for Structured Query Language.

– Comments to help the tester; e.g., instructions about where to get the software needed for the test case execution (e.g. Windows software to connect to the DB).

– Other items that can ease the execution and maintainability of the test case (we’ll talk about maintainability in a minute).


In order to have data about the birth and history of the modifications for each test case, we create a mini-journal of any changes where we record: When, Who, Why and What.


Created (date/name) – when the first version of this test case was created and who created it.

Modified (date/name) – when any change to the test case took place and who was responsible for the change

Reason – why the test case was changed and what was changed

You can view/download a test case template (as well as all the other documents mentioned in this Course) from Downloads on qatutor.com.

Let’s create the Test Case with Credit Card using all mentioned test case attributes:

IDEA: Payment can be made by Visa






Password: “1111” (this is default unchangeable password for all user accounts)

Search keyword: “expectations”

!!!Go to Test Portal>Helpers>DB Connect Utility to run SQL query below.


            select result from cc_transactions where order_id = <order id>;

Created (date/name):11/17/2004/O.Ferguson

Reason: new way to verify that credit card transaction was successful.

Modified (date/name):


ShareLane ->

1. Go to https://main.sharelane.com.

2. Click link “Test Portal”.

3. Click link “Account Creator”.

4. Press button “Create new user account”.

5. Copy email to the clipboard.

6. Go to https://main.sharelane.com.

7. Paste user email into textbox “Email”.

8. Enter password into textbox “Password”.

9. Press button “Login”.

10. Enter search keyword into textbox “Search”.

11. Press button “Search”.

12. Press button “Add to Cart”.

13. Click link “Test Portal”.

14. Click link “Credit Card Generator”.

15. Select needed card from drop-down menu.

16. Press button “Generate Credit Card”.

17. Copy card number to the clipboard.

18. Go to https://main.sharelane.com.

19. Click link “Shopping cart”.

20. Press button “Proceed to Checkout”.

21. Select appropriate value from drop down menu “Card Type”.

22. Paste card number into text box “Card Number”.

23. Press button “Make Payment”.

24. Write down order id: ___.

25. Run SQL1


Next ->

Lecture 3 - Test Cases and Test Suites -> Quick Intro -> Test Case Structure -> Results Of The Test Case Execution -> Useful Attributes Of The Test Case -> Data-Driven Test Cases