requirements management
 |
Jelly Beans and Defect Classification: Different Strategies for Success When there’s a bowl of jelly beans, some people grab a few at random, but most of us have favorites. If you're crafty and have flexible standards, you can maximize consumption by adjusting your criteria as colors dwindle. Classifying defects should not be like choosing jelly beans; you need firm standards. |
|
 |
The Word “Automation” Has Led Us Astray The misunderstanding that automation for software quality is just doing what humans do (i.e., manual testing), but faster and more often, causes business risk. Unless you’re very clear, the quality measure is incomplete. The word automation distracts from the real value: measuring quality. |
|
 |
Testing Nonfunctional Requirements in an Agile Lifecycle As organizations embrace agile, requirements become a challenge because they must be considered and validated in each (short) sprint. Ideally, nonfunctional requirements should be a continuous focus throughout the project. Here are some ways to better address NFRs in an agile development lifecycle. |
|
 |
Five Techniques for Creating Testable Requirements Documenting user requirements is always a challenging phase in software development, as there are no standard processes or notations. However, communication and facilitation skills can make this activity easier. Here are five techniques for converting user stories into testable requirements. |
|
 |
Why Testers Should Get Involved in Requirements Engineering Testers use requirements as the basis of test cases, review them for testability, and often participate in general requirements reviews or inspections. However, many testers have little knowledge of requirements engineering. Erik van Veenendaal provides five critical success factors to get started. |
|
 |
Maintaining Testable Requirements and Acceptance Criteria Once a testable requirement or acceptance criteria have been “created,” there is a tendency to assume that the task can be considered completed. Because that may or may not be true, it is better to continue to pay attention to testability. Here are four ways to maintain testable requirements. |
|
 |
Creating Testable Requirements and Acceptance Criteria Testable requirements, or acceptance criteria, are the communication of an expectation between its originator and potential stakeholders. Many testers struggle with this starting point. But once you succeed, you know the processes that can build and test a system implementing “good” requirements. |
|
 |
The Cost of Delay for Not Shipping on Time The cost of delay is the way to think about the revenue you can lose plus the cost of continued development. When you delay your release and don’t ship on time, you miss the revenue from the maximum sales times. Shipping on time isn't always easy, but it's easy to see why you need to. |
