Test Case Structure

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

The problem with a test case having only the expected result is that this piece of information (expected result) alone might not be sufficient to perform the test case execution. In the case of a large bottle of Sapporo, we can just unzip the backpack and look inside. In the case of software, as a rule, we need an instruction on how to reach an actual result.

You should have QATUTOR Membership to view this page. Please, login or sign up. If you are already logged in, try refreshing this page.

Example

Our red-hot start-up, www.sharelane.com, has a new employee; let’s call him Samuel Pickwick. Some friendly fellow hands him the following one-line test case:

“Payment can be made by Visa.”

Mr. Pickwick’s brain immediately generates two perfectly reasonable questions:

– “How can I do testing if I don’t have a Visa card and don’t know where to get one?”

– “How can I be sure that a payment was really made even if I had that Visa card?”

One thing that is more or less clear is the purchase process (create new account and log in, find a book to buy, put it into the shopping cart, do checkout), but even with this common knowledge, the test case execution will be stuck at the point where the tester enters credit card information.

In other words, that test case cannot be executed by Mr. Pickwick without someone helping him.

This situation sucks because:

– It adds even more stress to Mr. Pickwick’s first days at his new company.

– Mr. Pickwick MUST interrupt the work of other tester (-s) to get the information he needs.

 Here is another example.

Example

Our red-hot start-up, www.sharelane.com, has a new employee; let’s call him Samuel Pickwick. Some friendly fellow hands him the following test case:

ShareLane ->

1. Go to http://main.sharelane.com/cgi-bin/main.py.

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 http://main.sharelane.com/cgi-bin/main.py.

7. Paste user email into textbox “Email”.

8. Enter “1111” into textbox “Password”.

9. Press button “Login”.

10. Enter “expectations” 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 “Visa” from drop-down menu.

16. Press button “Generate Credit Card”.

17. Copy card number to the clipboard.

18. Go to http://main.sharelane.com/cgi-bin/main.py.

19. Click link “Shopping cart”.

20. Press button “Proceed to Checkout”.

21. Select “Visa” 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. Click link “Test Portal”.

26. Click link “DB Connect Utility”.

27. Make database query:

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

Expected result: “10”

In our last example (we’ll refer to it as “Test Case with Credit Card”), the expected result (ER) was preceded by steps that were supposed to give the test case executor an actual result (AR). These steps can be also called the “procedure“.

Here is an analogy for you:

– The procedure is a set of steps on a staircase.

– The expected result is a certain object we are supposed to find if we climb to the top of that staircase.

– The actual result is what we actually find when we reach the top of the staircase.

Brain positioning

If we apply the computer science concept of input/output, we’ll have this:

– The procedure is the instruction about input.

– The execution of the procedure is the act of input.

– The expected result is the expected output.

– The actual result is the actual output. Next ->

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