Showing posts with label good Test case. Show all posts
Showing posts with label good Test case. Show all posts

Thursday, April 30, 2009

hOW TO wRITE gOOD tEST CASES

What is a good test case?
  • Accurate - tests what it’s designed to test
  • Economica - no unnecessary steps
  • Repeatabe, reusabe - keeps on going
  • Traceabe - to a requirement
  • Appropriate - for test environment, testers
  • Sef standing - independent of the writer
  • Sef ceaning - picks up after itsef
Types of test cases
  • A rose by any other name smells as sweet
  • Step-by-step or word/action instructions
  • Table, matrix
  • Script for record/playback or performance test
  • All need the same structure (anatomy)
Anatomy of a test case
  • Statement of purpose, what is being tested
  • Method, how it will be tested
  • Setup, environment, data
  • Steps - actions and expected results, implied in atable or matrix
  • Proofs, files, printouts, reports, screen grabs(optional)
Improving testability - language
  • Testability = easy to test
  • Use active case, do this, do that
  • System displays this, does that
  • Simple, conversational language
  • Exact, consistent names of fields, not generic
  • Don’t explain Windows basics
Improving testability - length
  • 10-15 steps or less, unless user cannot savework
  • Uniform time to test
  • Wide range of testers
  • Pros and cons of cumulative cases
  • Order of cases follows business scenarios
The seven most common mistakes
  • Making cases too long
  • Incomplete, incorrect, or incoherent setup
  • Leaving out a step
  • Naming fields that changed or no longer exist
  • Unclear whether tester or system does action
  • Unclear what is a pass or fail result
  • Failure to clean up
Test Case Checklist
Quality Attributes
  • Accurate - tests what the description says it will test.
  • Economical - has only the steps needed for its purpose
  • Repeatable, self standing - same results no matter who tests it.
  • Appropriate - for both immediate and future testers
  • Traceable - to a requirement
  • Self cleaning - returns the test environment to clean state
Structure and testability
  • Has a name and number
  • Has a stated purpose that includes what requirement is being tested
  • Has a description of the method of testing
  • Specifies setup information - environment, data, prerequisite tests, security access
  • Has actions and expected results
  • States if any proofs, such as reports or screen grabs, need to be saved
  • Leaves the testing environment clean
  • Uses active case language
  • Does not exceed 15 steps
  • Matrix does not take longer than 20 minutes to test
  • Automated script is commented with purpose, inputs, expected results
  • Setup offers alternative to prerequisite tests, if possible
  • Is in correct business scenario order with other tests
Configuration management
  • Employs naming and numbering conventions
  • Saved in specified formats, file types
  • Is versioned to match software under test
  • Includes test objects needed by the case, such as databases
  • Stored as read
  • Stored with controlled access
  • Stored where network backup operates
  • Archived off-site