Software product success.
This post is a test automation case study, but at a higher level.
We’ll talk about it in terms of defining the problem, and then discuss the objective (what we proposed to do to solve the problem), the strategy (how we went about doing it) and the tactics (how we executed the strategy). Since this happened in the real world, we’ll also identify the constraints within which we had to operate.
Too many companies don’t document their requirements.
Worse still, too many companies over-document their requirements.
Testing software is more than just manually banging around (also called monkey testing) and trying to break different parts of the software application. Unit testing is testing a subset of the functionality of a piece of software. A unit test is different from a system test in that it provides information only about a particular subset of the software. In our previous Foundation series post on black box and white box testing, we used the inspections that come bundled with an oil change as examples of unit tests.
Now that we’ve gathered all these requirements, how do we determine which ones to do first?
The less we know about our client’s business, the more the requirements appear to be equivalent. We’ll talk about three different approaches to prioritizing requirements.
1. Classical. Let stakeholders assign priority to the requirements.
2. Exhaustive. Explore every nuance of prioritization and its application to requirements.
3. Value-based. Let ROI drive the decisions. (hint: this is the best one – scroll down if you’re in a real hurry)
4. [bonus]. A look at how 37signals prioritizes features for their products.
Previously, we talked about brainstorming as one of the best elicitation techniques for gathering requirements. Here are some details about how to facilitate a general brainstorming session with a group of people in 5 easy steps (and then another 5 easy steps). Seven to ten people is a good number […]
Lauren Arbittier Davis recently started Alkali Marketing, a boutique marketing outsourcing company here in Austin. I’ve personally worked with Lauren over much of the past decade, and couldn’t be more excited about her company! When Tyner Blain is ready to build awareness (beyond our current viral approach), Alkali is who […]
We previously stressed the importance of understanding why something is a requirement. Unfortunately, we can’t just ask “why why why?!” until we reach the end of the chain. This won’t be any more effective for us now than it was when we were in kindergarden. Eventually, our listeners will get frustrated, or worse, defensive.
Interviewing, Brainstorming, Documenting Use Cases, Prototyping, and Analyzing Documents are our top-five tips. Read more for details
Should I use black box testing or white box testing for my software?
You will hear three answers to this question – black, white, and gray. We recently published a foundation series post on black box and white box testing – which serves as a good background document. We also mention greybox (or gray box) testing as a layered approach to combining both disciplines.
Given those definitions, let’s look at the pros and cons of each style of testing.