Test Case

Test Cases - 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.


Test cases for Login function


A typical login scenario consists of successful login with valid credentials, unsuccessful login with invalid credential. Successful login leads a user to the logged in page. Unsuccessful login leads the user to the message “Username or Password incorrect”. (Both these scenarios are imperative for testing. )

A typical login test consists of elements – page Login, Logged in, text fields Username, Password, button SignIn, error messages “username required”, “Password required”, “Username or Password incorrect”.


TC     
Test Step
Test Data
Expected Result
Actual Result
Invoke: Browser
Double click on Browser (As per the Data Sheet) Icon on the Desktop.


Browser - Chrome opens.




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





TC     
Test Step
Test Data
Expected Result
Actual Result
Field: Username
Type in field Username
Username
[Field Username accepts letters, numbers, characters 255 nos.)
[If field Username is left blank –
 login page persists with the typed in Username
Caption “Enter your password” appears below the field Username]





TC     
Test Step
Test Data
Expected Result
Actual Result
Field: Password
Type in field Password
Password
[Field Password accepts letters, numbers, characters 255 nos.)
[If field Password is left blank –
 login page persists with the typed in user name
Caption “Enter your password” appears below the field Password]





TC     
Test Step
Test Data
Expected Result
Actual Result
Checkbox: StaySignedIn
Click on / off check button Stay signed in
StaySignedIn
[Check box Stay Signed In is check On/Off]
[ON – The user stays logged / signed in when one navigates to the URL in test case – Go to: URL (without having to enter username and password again and again)]
[OFF – when one navigates to the URL in test case – Go to: URL, the fields Username and Password are not pre-filled]





TC     
Test Step
Test Data
Expected Result
Actual Result
Button: SignIn
Click button Sign In

[If incorrect user name or password is typed –
login page persists with the typed in Username
Caption “The username or password you entered is incorrect” below the field Password appears]

Page opens in 3 sections – Header, Left, Right

Header section with logged in emailed displayed
Links – , Calendar, Documents, More (on the left side)
Links – Settings, Help, Sign Out (on the right side)
Field – search
Buttons – Search Mail, Search the web
Links – show search options, create a filter
Left sections in 3 sections –

Section 1 with
Menu links – Inbox, Sent Mail, Drafts, Spam, All Mail

Section 2 with
Chat section with recent contacts list and
Links – options, add contact

Section 3 Invite a friend
Right Section contains the list of email in 2 columns
Field – Give  to:
Button – Send invite

Right section displays the email list in 2 columns
Column1 – email address sent from
Column2 – subject of the email



Each element on the page gets a Test Case (unit test / test case). Each element has to be tested individually as well as in combination with other elements (integration test / test set).

Advantage to writing a test case for each element in detail is – write it once and only once, reuse it many times in several scenarios (test sets or scenarios). Example - The field password may be used several times in an application – Registration, Login, Profile change, Send payment etc. Irrespective of which page the field is in, its business rule(s) stay same.

If the business rule(s) change for an Element, the test case belonging to that particular element or function will have to be updated. With this edit, the rest of the test sets, scenarios are reusable as is and valid, eliminating script death. Saving time and resources that could have been spent on updating several test sets and scenarios every time a small change is made.

Since, we have explained to the tester how each element is supposed to function in full, the tester can get creative enough to do their thing rather than depend blindly upon the test case. We covered the business rules, we covered the possible scenarios. 



What does a test cases belong to?

 


Requirement!?!?!  -
The test cases come from requirements
So, it may seem like the test case name should be mapped to the requirements or use cases.

That happens if the requirements change?
The requirements change, new requirements come up, some requirements do not see the light of the day.
Is it practical to change the test case with the changing requirements?
Even with version numbering will it make sense on the long run?

NO


Project!?!?! -
New test cases arise from new projects intended to improve or modify a system
So, it might seem like the test case name should reflect the project which initiated it.

But the projects end at some point. New teams and team mates take over the system maintenance, testing and other improvements.

Is it useful to learn about the project?
Is there any value to learning about an ancient project?
Absolutely Not


What does a test case belong to?

A Test case always belongs to the product.


Projects come and go.
Requirements come, change and die,
But the core product is forever (As long as it lasts)

Summary

  1. Test cases belong to the product.
  2. Test cases aim to test the specification as per a requirements
  3. Test cases are a result of a project initiated.
  4. But test cases belong to a product.
The Average life of software is 7 years.
A test case we create today is the guide for the uses, testers, developers, project managers, etc. to understand the functionality and purpose of a system.
The need to study the high level requirements, business cases, use cases etc, can eb eliminated with one well written test cases.
This is a necessary art that is taken for granted.




Test Case Naming Conventions


The name of the test case should identify the product it belongs to. A company may have only one product currently, but there is every change the company could introduce new products. It is good to be prepared for changes.

First part of the test case

       The first part of the test case should mention the product it belongs to.
For example a test case for Microsoft Power Point could be -
          MS_PPT  or PPT.
For example a test case for Microsoft Excel could be -
          MS_XL or XL.
For example a test case for Microsoft Word could be -
          MS_Wd or Wd.
G_GM.  or GM. for Google Mail
G_GC.  or GC. for Google Calender
G_GD.  or GD. for Google Documents
G_GMap.  or GMap. for Google Maps

Second part of the test case

For example a test case for Microsoft Word could be -
          MS_Wd_mHome or Wd.mHome
G_GM_mInbox  or GM.mInbox for Google Mail's Inbox

Third part of the test case

For example a test case for Microsoft Word could be -
          MS_Wd_mHome_gClipboard or Wd.mHome.gClipboard
mHome = menu Home
gClipboard = group Clipboard

Fourth part of the test case

For example a test case for Microsoft Word could be -
          MS_Wd_mHome_gClipboard_iCut or Wd.mHome.gClipboard_Cut
mHome = menu Home
gClipboard = group Clipboard
iCut = icon Cut

Examples for MS-PPT

Ms.PPT.Invoke
Ms.PPT.mHome_iCut
Ms.PPT.mHome_iCopy
Ms.PPT.mHome_iFormatPainter
Ms.PPT.mHome_iPaste
Ms.PPT.mHome_iPaste_oPaste
Ms.PPT.mHome_iPaste_oPasteSpecial
Ms.PPT.mHome_iPaste_oPasteAsAHyperlink
Ms.PPT.mHome_iPaste_oPasteDuplicate


Sample Test Case


 Test case for invoking a URL

Typical test case

Test Step
Expected Result
Go to URL – https://www.google.com/
Page loads successfully
Or
Page throws no errors

Revised test case

Test Step
Expected Result
In chrome browser incognito.
Go to URL – https://www.google.com/
 Or
Go to URL –
QA1 = http://qa1.com
QA2 = http://qa2.com
Prod = http://prod.com
Stage = http://stage.com
Page opens with title – Google
Header consists of -
·         Links - +You or +(Username), Gmail, Images
·         Buttons - [app group buttons], Sign in (blue)
Body consists of -
·         Logo – Google
·         Text Field – with placeholder text Say “OK   Google”
·         Buttons – Google Search, I’m feeling Lucky
Footer consists of –
·         Links – Advertising, Business, About, Privacy, Terms, Settings

A simple Go to URL – (something) suffices.
All the information we need to test and verify in one location. Described simply.

Test case for navigation

Test Step
Expected Result
Go to URL – https://www.google.com/
Page opens with title – Google

We already have verified the page elements in the main test case. We are using this step for navigation only. It is ideal to do some verification. Verifying the title of a page is the best and simplest verification to do. So, do it.

Test case for Logging

Typical test case

Test Step
Expected Result
Login with valid user ID and password
Logged in successfully
Login with invalid User ID
Not logged in

In this case – what is a valid user ID and what is an invalid User ID? Unrequested? Invalid chars? What does logged in successfully mean? How can we be sure we verified log in correctly.

Revised test case

Test Step
Expected Result
(Blank fields)
Leave fields User ID and Password blank. Click button Sign In
Error messages appear in Red Font – Enter your email, Enter your password
Refresh the page
Error messages do not show anymore.
Type anything in the field User ID (asdgkdf) Leave the field Password blank.
Click button Sign In     
Error message appear in Red Font –
Enter your password

Refresh the page
Error messages do not show anymore.
(invalid credentials)
Type in the field User ID
(example1, example2, etc.)
Type in field  Password  (asdfggdg34@#$)
Click button Sign In     
Error message appear in Red Font –
The username or password you entered is incorrect
Refresh the page
Error messages do not show anymore.
(Registered credentials)
Type in the field User ID
[SELECT userID, userKey FROM Users]
Type in field  Password  
[userKey = 12, use password Pass1;
userKey = 13, Use password Af14!!]
Click button Sign In     
Page appears with Title - Inbox (number of emails, if any) – (email) – Gmail
Header elements…..
Left Nav…..
Footer elements….
Body elements ……
Go back one page
Same page persists.
Login page with login fields does not show up


Navigation test case


Test Step
Expected Result
Log in as System Administrator
[SELECT userID, userKey FROM Users WHERE userKey = 7] or
Or  [Users.xlsx > tab – 2015 ]
Page appears with
Title - Inbox (number of emails, if any) – (email)   – Gmail

Comments

Post a Comment

Popular posts from this blog

A Testers Life

Image
There is a plethora of examples explaining about a Developer's life. It is time to show the QA in the same "light". I am a QA and only some of these are my experiences. Which ones can you relate to? This is what they think QA are like This is what we wish QA could be like My first day on the job - I am introduced. Product training for QA I am trying to find my way through SharePoint It has always been like this. It's not a bug, don't log a ticket for it, the existing QA tell me. (Or maybe they do not want to admit that they missed a big fucking bug.) This is how Devs are trained about the project. This is how QAs are trained about the project I finally get my build to test. It is 5:00 pm Friday I am not given access to anything, but I am expected to test Setting up Test Data Smoke Testing (it usually never detects the fire or smoke till we get to production and a customer reports it. But it sounds good.) Trying to
Read more

Lots of Work

Image
“Working so hard” “There is a lot of work to do” “Such a big application” “So many bugs”  "Too much work load"  "Not enough time" What should it really mean to the person hearing it? – Nothing. I have seen members take loads of work and not bat an eye and do it with ease. I have also seen members take little work and make it look big and stress out and stress others out. I have also seen organizations that plan and work smart. I have seen organizations that plan to work really, really hard. I am not here to explain the right way of doing things. Whatever floats your boat!! Lol But, when people talk about a lot of work, it reminds me of the Woody Allen movie – Annie Hall There is a scene in the movie with a psychiatrist. The conversation goes like this - Alvy's psychiatrist : How often do you sleep together? Annie's psychiatrist : Do you have sex often? Alvy Singer : Hardly ever. Maybe three times a week.
Read more

Vanilla Ice Cream caused General motors to not start

Vanilla Ice Cream that puzzled General motors’!!!! An Interesting Story Never underestimate your Clients' Complaint, no matter how funny it might seem! This is a real story that happened between the customer of General Motors and its Customer-Care Executive. Pls read on..... A complaint was received by the Pontiac Division of General Motors: 'This is the second time I have written to you, and I don't blame you for not answering me, because I sounded crazy, but it is a fact that we have a tradition in our family of Ice-Cream for dessert after dinner each night, but the kind of ice cream varies so, every night, after we've eaten, the whole family votes on which kind of ice cream we should have and I drive down to the store to get it. It's also a fact that I recently purchased a new Pontiac and since then my trips to the store have created a problem..... You see, every time I buy a vanilla ice-cream, when I start back from the store my car won
Read more