Our story so far ... Tom Tester paged through the story descriptions in the iteration backlog. The vendor report shall list vendors in the order of percentage they met their monthly sales quota. "What if the vendor hasn't yet reported their monthly sales?" Tom wondered. "Or what if it's a provisional vendor that doesn't have a set quota? We've got a few cases like that." He turned to the next description: The sales manager shall be notified of all vendors below 50 percent of quota. "Notified in what way? Isn't the vendor report a form of notification? How can I test this?"
Sitting a few feet away, Paula Programmer began to implement the Item Profitability report. The profitability of each SKU in inventory shall be calculated according to the SKU Accounting document on the accounting department fileserver. She looked at the fileserver directory and saw a number of files. SKU Accounting 2010, SKU Accounting 2011, SKU Accounting-proposed, SKU Accounting-Jane, SKU Accounting-Harry. The one with the latest timestamp was SKU Accounting-Jane, and Jane was the VP of accounting. That must be the right one. Right on page one it clearly said, Item profitability is the sum of selling prices for the SKU, divided by the sum of item cost, minus 100 percent. Paula closed the file, thinking "That was easy," without reading the section on page three: Special calculations for profitability of SKUs used as loss leaders. She was already programming. "For 'sum of item cost,' I can just multiply 'current cost' by the number of items sold," Paula thought. "I should be done with this story by this afternoon."
Alan Analyst fretted over his notes. Sally Security Auditor had been emphatic that customer details for medical device purchases be protected from easy access. Did these purchase details also need to be encrypted in the database? Could they even do that and still provide the access needed by customer support when the customer called in for help? "I'd better specify encryption; better safe than sorry. The programmers will come back and tell me if it can't be done," Alan thought.
"I wonder when the security team will make the decision as to which categories of products should be treated as 'sensitive'? Perhaps I should just reference their specification document. Surely they'll have it finished soon." Alan turned his attention to the unanswered questions regarding marketing tests.
Software development can be a tough and lonely business.
The Three Amigos to the Rescue
One for all, and all for one. We'll have a better shot at getting the right system sooner if we collaborate.
The Three Amigos are the essential stakeholders of the system being developed: The business (or product owner, in Scrum terms), the developer, and the tester. These three represent the viewpoints of what the system is intended to do, what can and cannot be implemented, and what might go wrong or be misunderstood.
These three viewpoints represent orthogonal ways of looking at the system, and I strongly recommend having at least three people involved. I's true that some people are good at seeing things from more than one of these viewpoints. It's tempting to theorize that you can get the same results with fewer people. In actual practice, though, it's hard to give multiple viewpoints their due at the same time. Having different people for each viewpoint will help reduce the number of important points missed.