Google

Friday, June 10, 2005

Use Test Cases to Clarify Requirements

How can you as a tester reduce the problems caused by inadequate requirements processes earlier on in the lifecycle ? Finding bugs earlier reduces the amount of rework for developers and allows the testers focus more on acceptance level testing.

Failed tests and re-execution of tests often result from vague requirements. Here are a couple of quick-win strategies for improvements in the requirements area. It are small gradual steps, below the management radar (no approval required) with benefit for developers, testers, and other members of the team.

Direct your attention to answering the question "What happens when ..."

When you define a test case:
  • Identify input states and then specify the expected outcome. In the process of developing system level test cases, you can easily identify poorly documented requirements whether it’s ambiguous input conditions, missing information, or unspecified expected outcome. Pinpoint where requirements fail to describe the outcome.
  • Complete the test descriptions by replacing missing information with reasonable assumptions and indicate this as such. This is of enormous assistance to the manager or lead developer, who then merely has to approve the modified description rather than schedule resources to complete the product definition.
  • Share the information with developers, previews what tests are planned, give them the opportunity to bullet-proof their code if necessary.
These shortcut actions are not sufficient to comply with CMM or other quality standards, it is not really requirements management, important boundary/performance/configurations may be overlooked, they do not present you the big picture, neither a full description of system behaviour. However see them as a jumpstart to process improvement, you have to start somewhere and it provides a baseline for future improvements.

Find this and other paractical strategies for testers in the article: Quick Start to Quality - Five Important Test Support Practices, by Louise Tamres at StickyMinds.

To learn more about writing use cases: Writing Effective Use Cases, by Alistair Cockburn, Addison-Wesley 2001.

2 Comments:

Blogger dghnfgj said...

Youth is warcraft leveling not a time of life;warcraft leveling it is a wow lvl state of mind; wow power level it is not power leveling amatter of World of warcraft Power Leveling rosy cheeks, red wrath of the lich king power leveling lips and supple knees;WOTLK Power Leveling it is a matter of thewill,wlk Power Leveling a quality of buy aoc gold the imagination,aoc gold a vigor of the emotions; it is thefreshness of the deep springs wow gold of life. Youth means a tempera-mental maplestory mesos predominance of courage over timidity, of the appetite formaple story mesos adventure over the love of ease. wow gold This often existsin a man of 60 more than a boy of 20. Nobody grows old merely by anumber of years.

Saturday, February 07, 2009 3:22:00 AM  
Blogger قمم التميز said...

شركة غسيل مكيفات بالرياض
شركة غسيل مكيفات اسبلت بالرياض
افضل شركة تنظيف مكيفات بالرياض
تنظيف مكيفات بالرياض
اسعار شركات تنظيف مكيفات بالرياض

Sunday, September 17, 2017 11:57:00 AM  

Post a Comment

Read more about Software Quality at the <<Software Quality Weblog Home