Test Case - Best Practice

The average life of software is 7 years.

The test case we create today is the guide for the next seven years for the users, testers, developers, PMs etc. to understand the functionality and purpose of the system. It eliminates the need to look at the requirements, use cases, business cases, code, high level test cases etc to understand a system or software.

Test cases mention the regular user actions needed to perform an action according to the requirements. The same test cases also intend to test if the action can be performed without any foreseen or unforeseen results.

[For every action there is an equal and opposite reaction. [Laws of motions, NEWTON]]

1.   For every Test step there is an specific Expected result. EX: Flip the switch upward. Light bulb in the center of the room turns on. (The expected result is specific, it doesn’t say room illuminates, it says a certain bulb turns on)

2.    Simple English please. (I had coffee vs. I had a hot caffeinated beverage vs. I had some black drink vs. I had mine at home). We know what we are talking about, we would like for the other person listening to us to know about it in a certain way we think would be cool. More importantly we need for the other person to know what exactly we are talking about.

3.   Picture speaks a thousand words. If there is any chance, do give a visual picture. It will pay off in the long run. If there is not visual, do give a thousand words if necessary.

4.  It is said that in an expected result the words “Should, Would, Could, will and Must” may not be used because we QA do not believe in them (based on our experience anyway).  EX: Browser must open vs. Browser opens. Here company culture may be followed and adopted accordingly.

5.   Radio Buttons, Check boxes, Fields, columns must be mentioned by name and type. Ex: Check the radio button "I won a lottery". Use Bold, Italics, Underlines, ‘quotes’ and “quotations” at your disposal to mention specific types of function or data.

6.   Be specific when asking a user action. EX: “Enter a valid email ID” vs. “Enter in field email ID = First.Last@gmail.com”. The user / tester may or may not know what a valid email ID is or not. (that means no suggesting “use wild cards” either)

7.   A standard Test case has Step No., Test Step, Expected Result, Actual Result, Pass / Fail. Including a column for test data is a very good practice. This will make editing test data a breeze.

Sample Web Elements

Web Page Elements –

Text fields require inputting data

Drop down lists require selecting data

Links & Buttons require clicking on

Menus & Submenus require hovering on or clicking on

Check boxes require Click ON or OFF

Radio buttons require Click ON

Captions generated requiring verification.

Example Test Steps –

Type in field something

Click open the drop down list something and select (As per the data sheet)

Click on button something

Check ON or OFF checkbox something

Sample Test Case –

Test Step	Test Data from column name	Expected Result	Actual Result
Type in Address bar and press enter or (Go to URL)	URL	Gmail LogIn Webpage opens in 2 sections Section 1 with Caption "Sign in to Gmail with your Google Account" Fields UserName and Password Check box Stay signed in Button Sign In Link "Can’t access your account?" Section 1 with Caption "New to Gmail? It’s free and easy." Button Create an account Links "About Gmail" “ New features!”

The above test case is just for calling the URL and verifying the page that gets loaded. (One test case for each action). 

Note: I understand that we are used to writing "Page loads successfully" or "Page loads without errors". We are only starting to define what  "successful" and " no errors" actually means. Instead of saying test this. We are explaining how to test. 


That's all folk! Take this and make this yours and make it better. But keep it simple, it always works.