Tuesday, January 22, 2008

Functional Testing Template - One that works

I have seen a lot of templates around for capturing functional testing test cases but I have not been happy with many of them - so I started an exercise to take the good aspects of many of them and come up with a testing template that works. I have been using this template for close to 6 months now and it is working very well so I decided to publish it so that others can benefit from it. I have published the template using Google Docs and have opened the template to changes. Before going any further lets first open the template.

Functional Testing Template

(http://spreadsheets.google.com/ccc?key=pa7wK2WZheXh4MmuoIWCPJA&hl=en)

The key requirements for me were the following
  1. Easy to understand and use
  2. Should contain a status sheet that will give me the exact position of the testing phase
  3. Have clear definitions for everything such as severity, status and priority
  4. Come up with a consistent naming convention for the test cases
  5. Be able to organize the test cases
Let me start by explaining what the sheets in the template contain
  • Status - Gives an overall status of the application. There should be one row for each page/screen that is being tested.
  • Page 1 - Each page/screen in the application will have one sheet for all the test cases that are specific for that page.
  • Application - All the test cases that are application specific but not related to any one page in particular go in this sheet.
  • Test Data - Any test data that needs to be created for the test cases to run needs to be specified in this sheet.
  • Glossary - This sheet explains the meaning of all the severities, priorities, status, test case naming convention and so on.

Page Sheet

This sheet along with the application sheet are the most important sheets in this template. This sheet captures all the test cases related to the page being tested. For each page/screen in the application being tested we need to have one sheet in the excel sheet. This sheet is broken up according to what is being tested in the page. These sections are
  • Navigation - Test cases for all the links on this page that takes the user away from this page.
  • User Interface - look and feel - Test cases related to how the page should look and behave. What is the size and shape of the various controls, images and so on.
  • Dropdowns and Look Ups - Default values in any of the drop downs or lookup controls.
  • Functionality - Functionality of the page, hiding and showing of sections of the page
  • Error Handling - System errors - Test cases for system errors such as no DB connection or fatal errors.
  • Error Handling - Mandatory field checks - Test cases related to mandatory fields checking
  • Error Handling - Field type checks - Test cases related to values that can be given in fields such as checking for alphabets in a phone number, date validation, etc
  • Error Handling - Business Rules checks - Test cases related to business rules on a page such as checking if the username is already existing and so on.
If there are no test cases for a section then we just write "There are no test cases". This way we are ensuring that we are capturing all the test cases. Sometimes we may find that a page has something that is not covered but is specific to that page so we just add a new section. What we have attempted to do through this template is to come up with a process to make sure we capture all the test cases in a consistent and precise manner.

Application Sheet

In this sheet we capture all the test cases that are across the application. Here we have the following sections. When writing the page test cases we try to keep out test cases related to access and permissions. The reason is because this has to be tested at an application level.
  • Application Security - All test cases related to login and logout. Unauthorized access checks and so on.
  • Role Based Security - After the user logs in based on their role they can do and cannot do certain actions. This web page attempts to capture all the test cases related to this.
  • Transaction Based Security - Based on the action the user is doing they may be some some checking that needs to be done. Test cases related to this needs to be captured here.

4 comments:

Anonymous said...

Hi ,

I'm Rakesh from hyderabad working as a s/w tester. I want to learn more abt functional testing for different types of architectures. If u have test cases or any material which shows a directions for it please send me.
my email id is rakeshkamaraju@gmail.com

Sudeep D'Souza said...

As far as I am aware it does not matter what kind of architecture you are developing on - in all the cases the functional testing is exactly the same. If you are doing white box testing then you will have to be aware of the architecture but in functional testing you mostly do black box testing and it really does not matter what the underlying architecture is.

Anonymous said...

Hi Sudeep

Thank you for sharing this information, I am unable to download or review the link to the spreadsheet, maybe you could help by posting a new one?

Great article by the way.

Regards
Aria.Wijaya@hotmail.com

Sudeep D'Souza said...

@anonymous : Can you let me know what is the error you are getting when you click on the link.