How to Write a Test Case For each test case that is in the test scenario, document the following:

Script #/Name See comments above I generally number test scripts based on the test scenario, so if I had scenario X, then the first test script would be X.1, the second X.2, etc Script Description Description: Testing Requirements This is vital for a variety of reasons. First, from a planning perspective you need to validate that all requirements are covered by test scripts. Also, when a requirement changes I know, this hardly ever happens you need to know which test scripts may need to be updated. Setup List all steps that should be taken prior to executing the test case these might include initializing data, checking for required test data, other test scripts that should be executed first, specific hardware/software that should be used, etc Post Test Actions Along with setup steps, there may be steps that should be taken after the test case is executed. Script Steps This is the heart of the test script for each step list the action the tester should take, then document the expected result. Do not make the mistake of including desired outcomes/expected results in the test action column. The more precise and clear you are in your documentation, the less room for questions or tester interpretation during execution. I also have a pass/fail column listed a lot of people also like to put defect #s here as well, but I dont (I prefer to track the test script # against the defect in the defect tracking database, not the other way around). Test Execution This section should certainly be tweaked for your specific test needs, but this is a good starting point. Here you track who did the test, which test phase it was executed in, which test id was utilized, when the test was executed, and what was the status (passed, passed with minor errors, failed, critical failure, etc whatever statuses you utilize). Notes Of mine Test Case For each test case that is in the test scenario, document the following:

Script #/Name See comments above I generally number test scripts based on the test scenario, so if I had scenario X, then the first test script would be X.1, the second X.2, etc Script Description Description. Testing Requirements This is vital for a variety of reasons. First, from a planning perspective you need to validate that all requirements are covered by test scripts. Also, when a requirement changes I know, this hardly ever happens you need to know which test scripts may need to be updated. Setup List all steps that should be taken prior to executing the test case these might include initializing data, checking for required test data, other test scripts that should be executed first, specific hardware/software that should be used, etc Post Test Actions Along with setup steps, there may be steps that should be taken after the test case is executed. Script Steps This is the heart of the test script for each step list the action the tester should take, then document the expected result. Do not make the mistake of including desired outcomes/expected results in the test action column. The more precise and clear you are in your documentation, the less room for questions or tester interpretation during execution. I also have a pass/fail column listed a lot of people also like to put defect #s here as well, but I dont (I prefer to track the test script # against the defect in the defect tracking database, not the other way around). Test Execution This section should certainly be tweaked for your specific test needs, but this is a good starting point. Here you track who did the test, which test phase it was executed in, which test id was utilized, when the test was executed, and what was the status (passed, passed with minor errors, failed, critical failure, etc whatever statuses you utilize).