Test Case Writing Best Practices

Recently I gave training on Test Case Writing Best Practices - somewhat surprising rite:)even i feel the same but i did it:D................
Anyways just thought of penning down the discussed points which was useful for me as well...
As a tester i felt these are the some of the most important points to be taken care before you go ahead with writing test cases or implementation..

Details Required Before Writing Test Cases

-Read Specification and Requirements Carefully
-Be clear with the design and the implementation details
-Analyze and Identify all possible scenarios
-Identify the test environments and test types
-Should have detailed information related and affected areas of the requirement
-Should be clear of behavior under failure condition(invalid input, boundary values etc)

Improving Testability (Easy to Test)- Language

-Use Active Case say Do This, Do That
-System Display this, Do That
-Simple Conversational Language
-Exact, consistent names of fields, not generic
-Don’t explain windows basics
-10-15 steps or less. In case of integration test cases try to provide references instead of explaining the functionality again and again
-Always update your test case with the new build
-Follow Naming Convention – Naming Convention helps you to differentiate between function, control, dbname etc . It help in easy identification of different controls, functions, Labels , hyperlink etc.
Note: The naming conventions and practices may vary from project to project.

Naming Conventions

-The scenario/test case for different module should be mentioned in a single worksheet in a single file. The name of the excel file should be TypeofTesting_ModuleName
-Module names should be in Capitals and Bold
-Screen Names should be bold and have camel notation i.e., the first word in capital letters and rest all in small letters.
-All the objects like textbox, listbox,Checkbox,radio buttons etc should be in italics and bold
-The link names should be mentioned in Italics, bold and underline below the word e.g.,' Sign Out’ link should be mentioned as ‘Sign Out’
-Database table name should be in caps e.g.,Emp_Details table name should be EMP_DETAILS

Test Case Attributes

-Test Case Id – Must be Unique across the application
-Test case description - The test case description must be very brief
-Test Case Priority – Priority of the test case
-Test case Type – To identify the type of test case
-Precondition – what should be present in the system, before the test can be executed
-Assumption or Dependencies – (Helps to identify related code or functionalities and features)
-Test Inputs - The test input is nothing but the test data that is prepared to be fed to the system
-Validation Input – step by step instructions on how to carry out the test
-Expected Result– How the system must react based on the test steps
-Actual Result – The actual output
-Post Conditions – State after the test case is executed
-Execution Result(Pass/Fail) – Your actual result based on expected and actual result
-Build Number – To keep track of results

General Guidelines

-Write test cases before implementation of requirement
-Test cases are written for all the requirements. Test case should map to current requirement and should not be an enhancement to the application.
-Follow a standard template for all test cases
-Use very simple English and general words
-Format followed( Alignment, Naming convention etc) by test cases should be uniform for the entire application
-All the scenario/Test Case should be easily understandable,clear and to the point
-Highlight important points by making text bold or assigning it a color or writing it in different font
-You may add sections to a group of test cases to make it more informative
-You may use double quotes for a particular display text
-Maintain the test cases in a flow so that execution order is maintained and time is saved. Whenever a new scenario/test case is been added between two existing one it should be named after the previous scenario/Test case Id with decimal places ie.,if we have added new scenario between ID ST-SA–BKG-0015,then new scenario ID will be ST-SA-BKG-0015.1
-Use bullet points for different steps
-Specify Test case type and priority which would help in determining whether to run the test case in specific scenario or not(Shortage of time etc)
-The prerequisite for the scenario/test case should be mentioned before the test case
-Use a mix of both ‘positive and negative’ tests
-Provide test data(if possible)
-Write in details SQL Queries(it will save time while executing)
-Add reference to bugs or requirement as per your needs
-Defect ID of a Scenario/TestCase should match the Defect ID submitted against the defect in Defect Tracking System
-Add some notes in case you want to convey additional information or explain the test case with example in case the scenario is not much clear
-You can use build number next to your result to keep a track of results or determining defect density

Note:Test case should be such that any person going to execute it or read it gets a clear picture of what needs to be done without needing any explanations


To conclude i would like to tell you that there is no hard and fast rule for writing a good test cases but there are some steps which if followed makes your test cases more readable and informative.........
I hope this post will help you in improving your test cases writing skills.........