|
Agile Testing as if People Mattered As a test professional in waterfall, I was used to getting the code much later and buggier than I expected and being under tremendous pressure to finish my testing before the go-live date hit. Then one day, I found out that there was a better way. Testers could be involved much earlier in the lifecycle, they could participate in requirements and design decisions as they happened, and the code could actually be unit tested before I received it! Heaven? Nope, agile.
|
|
|
Two Cheers for Ambiguity Some people dismiss words such as skill, diversity, problems, and mission as being too ambiguous to be useful. But one tester's ambiguity is another tester's gauge for assessing consensus on a project and how to achieve that consensus.
|
|
|
A Story About User Stories and Test-Driven Development: Into the Field Drawing on real events from the authors' combined experience, this story picks up where it left off in the November 2007 issue and follows a fictional team as it encounters some of the pitfalls of using test-driven development.
|
|
|
A Story About User Stories and Test-Driven Development: The Setup While "testing" is part of its name, many TDD pundits insist TDD is not a testing technique, but rather a technique that helps to focus one's design thinking. Drawing on real events from the authors' combined experience, this story follows a fictional team as it encounters some of the pitfalls of using test-driven development.
|
|
|
The Forgotten Side of Quality Our perception of quality includes objective and subjective factors. In this week's column, Jeff Patton explains the difference between the two and proposes we forget those differences so we can start viewing the two as equals.
|
|
|
Practical Software Sizing with Testable Requirements A new strategic project is in the design stages-how much will it cost? Your application requirements are constantly growing-what is the impact? System testing is scheduled soon-how much time and what resources will we need? And how do you get the answers? Measurement. Although software developers are often collecting measures of defects, earned value, variances, etc., the most fundamental measure-how big is the system?-is usually lacking. Lines of code and function points are established sizing measures but both have limitations that have prevented their widespread acceptance. Karen Johns presents testable requirements, an alternative sizing measure that can help you meet these challenges and more. Learn from Karen what testable requirements are and how to use them to size your software systems.
|
Karen Johns, Mosaic, Inc.
|
|
Prioritization Puzzles: Practices for Prioritizing Product Requirements Not all requirements are created equal, so to make smart choices about which product requirements you should explore and implement-or whether you should delve into them at all-you need to prioritize them. Many teams do not prioritize properly and waste time specifying requirements that are never delivered. Why spend time and energy on requirements you won't use? In this week's column, Ellen Gottesdiener answers the question by detailing how and when requirements should be dealt with.
|
|
|
The Whorfian Hypothesis Benjamin Whorf hypothesized that the language we speak constrains the thoughts we can have. Learn how a well-developed organizational vocabulary can help increase the quality of your products.
|
|
|
When Requirements Collide Could it be that not every set of business requirements has the customer's best interest in mind? Karl Wiegers had always believed that implemented software functionality should enable users to accomplish their goals and help the business achieve its objectives. But a recent experience with a less-than-helpful parking meter system suggested to him that conflicts sometimes might exist between business and user requirements.
|
|
|
Know What's at Stake Everyone knows the importance of well-defined functional requirements. We want our products to work, don't we? But how many of us are paying as much attention to defining our non-functional requirements? In this historically focused feature, we learn from past mistakes the potentially disastrous results of inadequately tested NFRs.
|
|