BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
It may be the most widely held belief about the software lifecycle: Getting requirements right sets the course for software that does what it's meant to do. Getting requirements wrong begins a path to project failure.
For software testers, requirements have always been about wanting more. The more requirements are defined up front, the more thoroughly testers can verify the application's range of functions. More is also better when it comes to the level of detail defined within individual requirement specs. But as QA pros have long lamented, key details are often missing, which leads to vague requirements that are difficult to test.
For software testers, the idea that more is better, when talking about requirements, is deeply held. Recently I've seen signs that may turn this conventional wisdom on its head. A new truth is emerging: Maybe less is more when it comes to specifying requirements at the outset of the software lifecycle.
Is this is just a case of bowing to a reality QA pros have had to live with for a long time? Or is there more going on here?
I think it's something bigger. Yes, software teams are rethinking what makes sense for requirements. But more momentous is how the very role of testers is being redefined, making them more important players in the software lifecycle. In this edition of Quality Time, I explore this change.
Requirements: Is less more?
Scanning the agenda for the StarEAST conference, scheduled for May 4 - 9 2014 in Orlando FL, I came across this description for a tutorial led by software test expert Lloyd Roden:
"Requirements are essential for the success of projects ― or are they? As testers, we often demand concrete requirements, specified and documented in minute detail. However, does the business really know what they want early in the project?"
In his course description, Lloyd Roden, who heads a UK-based consultancy of the same name, goes on to say that "detailed requirements can damage and hinder the progress of testing."
Really? Detailed requirements hinder testing? That's an about face for software pros, who believe that the more detail a requirement includes the better it is.
Then I came across a recent article published on SoftwareQuality.com that concurs with Roden's point. In an article on the advantages of using fewer user stories, Mary Gorman and Ellen Gottesdiener, co-principals of EBG Consulting, make the case that too many user stories (essentially "requirements" in Agile development) impede the progress of software projects. "It's not a contest to see how many user stories you can write. Not everything needs to be a user story," they say.
So maybe, when it comes to managing requirements in the software lifecycle, less is more?
Testers take a leading role
Here's what I think is happening. If the role of the software tester is simply to validate requirements, the "more" mindset is the right mindset. The more requirements software testers validate, the harder they are working. And the more detail a requirement includes, the easier it is for the tester to validate.
But all testers know that this perception of their role is outmoded, that delivering great software takes more than just verifying that the requirements work.
What does the software tester's role entail today? Test expert Lisa Crispin, a regular contributor to our pages, said it best when she described the tester's role as helping business people figure out the right things to deliver. "The truth is that business stakeholders may be wrong about what features [an application needs]." Testers have to take a leadership role in those decisions, she said.
Don't just do what they say
All QA pros know, testing the requirements as they are specified, no less and no more – will not result in the best possible software. It will simply result in well-tested requirements. In this scenario, the "more" mentality around requirements makes sense.
Simply testing requirements is far easier than what's being asked of software testers today. But it's also less interesting, less creative and less ambitious. It requires rote skills, not insightful thinking. It's sort of like working the assembly line instead of helping design the best car.
In my next column, I'll talk about what skills it takes to deliver top quality software today. Let me know what you think.