My experience of modern software dev projects, has been that business requirements generally start as discussion, which are quickly translated into development requirements. What I believe modern QA professionals bring to modern software development projects, is ability to reverse engineer requirements based on sound software testing principles, and ongoing discussions with project management.Â

The best way to start a discussion is a question. “Why does the customer want this software?” If no-one can answer this question, the team must be developing to their own requirements, based on initial “suggestions” from the client. QA is in a unique position, as QA is the conduit between management and technical, in the course of release cycles.

The customer is very likely to be unaware of all their requirements, as the initial sell can sometimes cloud/warp their real requirements. The advantage of QA is that the drive behind our test requirements is to have a complete picture of what an application is supposed to be doing, and that it is doing what everyone expects it to be doing. Raising issues doesnt just have to be coding issues, it can be requirements issues that require a business decision.

Where testers can fall down, is losing themselves in the development cycle, and effectively losing track of the bigger picture of the project. Not a failure of testers, but of test management, a role considered a luxury, rather than necessity, these days.