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 -> Maintainability Of Test Cases -> The Number Of Expected Results Inside One Test CaseThe new Test Case with Credit Card looks good: it’s nicely formatted, it’s data-driven, and it includes useful test attributes. The problem is that the Web site, and especially the part called “User Interface” (UI), is subject to frequent changes.
Example
The “Login” button from Step 9 can easily be renamed “Sign-in.” Hence, if we have three test cases, we have to make three changes. But what if we have 500 test cases where the “Login” button is mentioned, and what if these test cases are scattered among many test suites – like my former classmates are scattered throughout the world? You might say, “Not a big deal. It’s easy to guess.” But as time goes by, we could have hundreds of small changes like that! Gradually, our test cases will either start to lose their practical value (because of the difficulty in executing them), or they will start to consume too much time for maintenance.
So, the name of the issue is “maintainability”; i.e., the simplicity and ease of changing a test case to reflect changes in the software. If we don’t think about test case maintainability, we aren’t thinking about tomorrow.
Now, let’s split the steps of the Test Case with Credit Card into logical modules:
LOGICAL MODULE | TEST CASE STEPS |
1. Create new user. | 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. |
2. Login. | 6. Go to https://main.sharelane.com. 7. Paste user email into textbox “Email”. 8. Enter password into textbox “Password”. 9. Press button “Login”. |
3. Find a product. | 10. Enter search keyword into textbox “Search”. 11. Press button “Search”. |
4. Add product to Shopping Cart. | 12. Press button “Add to Cart”. |
5. Generate Credit Card | 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. |
6. Do Checkout. | 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”. |
7. Get Order ID. | 24. Write down order id: ___. |
8. Query DB. | 25. Run SQL1 |
Let’s see how we can make this test case more maintainable:
1. Create new user
We do have to tell tester how to create new user account using test tool Account Creator (Test Portal>Helpers>Account Creator), but why shall we put the same steps over and over again every time when new account needs to be created? Instead, what if we:
– select blocks of the steps which will be repeated in many test cases,
– put those blocks into an external document and
– put a reference to that external document in those test cases where our steps used to be.
For example:
Using this approach, we can save ourselves enormous effort, because if test case steps have to be changed, we need to make that change in ONE place only! How cool is that!
BTW
ShareLane -> Create New Account is a link to the corresponding Web page located on Intranet* site Test Portal. See Test Portal>More Stuff>QA KnowledgeBase>Create New Account.
*internal company network
2. Login
It’s easy to guess where to enter email/password and which button to press to login. So, we can get rid of unnecessary steps (Steps 6, 7, 8, 9).
Note that we aren’t testing the login process here – we have separate test cases for that. Now we are simply using login as one of the steps to execute our Test Case with Credit Card.
3. Find a product
An approach from section “2. Login” above is applicable here too.
What else can we do here? Let’s say that someone accidentally deleted book “Great Expectations” from the DB. What shall we do now? Blame the world for being unfair and whine that we are blocked? No.
ShareLane -> We simply prevent that situation by looking into DB table “books” to see available book titles (Test Portal>DB>Data>books). So, during test case execution we’ll just search for a keyword from any title available in table “books”. Let’s create a QA KnowledgeBase article for that: Find Search Keyword (Test Portal>More Stuff>QA KnowledgeBase>Find Search Keyword)
4. Add product to Shopping Cart
An approach from section “2. Login” above is applicable here too.
5. Generate Credit Card
ShareLane -> Let’s create QA KnowledgeBase article Generate Credit Card (Test Portal>More Stuff>QA KnowledgeBase>Generate Credit Card).
6. Do Checkout
ShareLane -> Let’s create QA KnowledgeBase article Do Checkout (Test Portal>More Stuff>QA KnowledgeBase> Do Checkout).
7. Get Order ID and 8. Query DB. Let them be.
Let’s recap the measures we took to improve the maintainability of test cases:
1. Make the test case data driven.
2. Don’t include steps for obvious, easy-to-guess scenarios.
3. Don’t give concrete details if they don’t matter during the execution of the test case-e.g., the search keyword.
4. Take repeated scenarios, move them into QA Knowledge Base, and put a link to that QA KB page into the test case.
IDEA: Payment can be made by Visa | TC ID | ССPG0001 | |
Priority | 1 | ||
SETUP and ADDITIONAL INFO
Go to Test Portal>More Stuff>QA KnowledgeBase to “See QA KB“ In order to run SQL1 go to Test Portal>Helpers>DB Connect Utility. SQL1: 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): 02/03/2005/I.Newsome | Reason: modified steps to improve test case maintainability | ||
1. Create New Account (See QA KB) 2. Login 3. Find Search Keyword (See QA KB) 4. Do search 5. Add found book to the Shopping cart. 6. Generate Credit Card (See QA KB) 8. Write down order id: _______ 9. Make DB query: SQL1 | 10 | ||
BTW
For execution:
– Test cases can be printed out on paper.
– Test cases can be viewed on a monitor as opened MS Word or MS Excel files (or whatever files we use for test cases).
– Test cases can be viewed on a monitor as a part of special test case management software.
Remember, Create New Account, Find Search Keyword, Generate Credit Card and Do Checkout are an HTML links. If you have printed out the test case, you cannot click the link (and you might have problems understanding that it is a link, especially if the printout is in black and white). To solve this problem, you can format those links in a special way.
For example,
– use special font formatting (bold/italic/underline/font type/font size) and/or
– use magic words that will follow EVERY reference to QA Knowledge Base, like “See QA KB”.
So, your link would look like: Do Checkout (See QA KB). 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 -> Maintainability Of Test Cases -> The Number Of Expected Results Inside One Test Case
