ISO 9001:2000 Certified

“ A set of test inputs, execution conditions, and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement.” (IEEE) In General a test case basically is a brief statement of something that should be tested

“ A set of test inputs, execution conditions, and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement.” (IEEE)

In General a test case basically is a brief statement of something that should be tested

The basic objective of writing test cases is to validate the testing coverage of the application. If you are working in any CMMI company then you will strictly follow test cases standards. So writing test cases brings some sort of standardization and minimizes the ad-hoc approach in testing.

The basic objective of writing test cases is to validate the testing coverage of the application. If you are working in any CMMI company then you will strictly follow test cases standards. So writing test cases brings some sort of standardization and minimizes the ad-hoc approach in testing.

Find defects Maximize bug count Block premature product releases Help managers make ship / no-ship decisions Minimize technical support costs Assess conformance to specification Conform to regulations Minimize safety-related lawsuit risk Find safe scenarios for use of the product Assess quality Verify correctness of the product Assure quality

Find defects

Maximize bug count

Block premature product releases

Help managers make ship / no-ship decisions

Minimize technical support costs

Assess conformance to specification

Conform to regulations

Minimize safety-related lawsuit risk

Find safe scenarios for use of the product

Assess quality

Verify correctness of the product

Assure quality

Information Objectives Test Attributes Testing Styles / Paradigms

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)

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)

Easy to determine the result Tests are viewed one after the other in quick succession, usually in groups of several hundred to a thousand. As such, it is important that the results be easy to interpret. Quick to determine the result The tests should need no more than a few seconds to convey their results to the tester. Self explanatory The tests should not need an understanding of the specification to be used. Short Tests should be very short (a paragraph or so) and certainly not require scrolling on even the most modest of screens, unless the test is specifically for scrolling or paginating behaviour. Valid Unless specifically testing error-recovery features, the tests should all be valid. Cross-platform Test should be as cross-platform as reasonably possible, working across different devices, screen resolutions, paper sizes, etc. Exceptions should document their assumptions. Note: Properly written test cases helps both testers as well as developers while execution and debugging

Easy to determine the result

Tests are viewed one after the other in quick succession, usually in groups of several hundred to a thousand. As such, it is important that the results be easy to interpret.

Quick to determine the result

The tests should need no more than a few seconds to convey their results to the tester.

Self explanatory

The tests should not need an understanding of the specification to be used.

Short

Tests should be very short (a paragraph or so) and certainly not require scrolling on even the most modest of screens, unless the test is specifically for scrolling or paginating behaviour.

Valid

Unless specifically testing error-recovery features, the tests should all be valid.

Cross-platform

Test should be as cross-platform as reasonably possible, working across different devices, screen resolutions, paper sizes, etc. Exceptions should document their assumptions.

Note: Properly written test cases helps both testers as well as developers while execution and debugging

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.

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.

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

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 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

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

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 understable,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 [ contd…]

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 understable,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

[ contd…]

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

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

There’s no simple formula or prescription for generating “good” test cases. There are tests that are good for your purposes , for bringing forth the type of information that you’re seeking. Given a purpose, we can evaluate tests as better or worse along several dimensions , in terms of how they advance that purpose. Many test groups stick with a few types of tests. To achieve the broad range of value from our tests, we have to use a broad range of techniques, consciously selected to help us achieve our information goals.

There’s no simple formula or prescription for generating “good” test cases.

There are tests that are good for your purposes , for bringing forth the type of information that you’re seeking.

Given a purpose, we can evaluate tests as better or worse along several dimensions , in terms of how they advance that purpose.

Many test groups stick with a few types of tests. To achieve the broad range of value from our tests, we have to use a broad range of techniques, consciously selected to help us achieve our information goals.