Testing Without Requirements

A Practical Approach
Member Submitted

Many a times, a tester has to perform his job with minimum documented requirements or in worst case, no requirements at all. Such a situation not only makes a tester's work difficult but also makes planning and estimation almost impossible and considerably reduces Return of Investment from the QA department. In this write-up, I try to explore the situation of testing without requirements, its impact on whole software process and how effectively a tester can perform his work.

Impact of testing with no requirements
Let's consider an ideal case in which a tester gets Software requirements well on time i.e. at Design and Analysis stage in the Software Life Cycle. In this situation the tester’s job will begin with reviewing the requirements. A lot of defects are uncovered at this stage as requirements are verified for ambiguity. This forms the base for creation of test cases. In the next stages, the test cases are derived from requirements and then execution of test cases takes place followed by analysis of results.

But the irony is that, this situation does not always exist for a tester. Testing is still considered to be simply as a separate phase in Life cycle rather than being accepted in each phase of life cycle. In this case, testing starts at the tail end of the Development process just few weeks before actual release. Testing in these conditions often makes life of QA department miserable and causes the below listed effects:

  • As overall product knowledge is not documented in this case and is confined only to a few people, there is big task for QA i.e. extracting the information regarding product from developers, Product Management, Marketing and other concerned people. Most of the time these people are tied up with their work and unavailable. Testers hardly get to interact with them when most required.
  • QA department’s role in overall product life cycle becomes quite less. QA people are often spotted asking questions to concerted people regarding product's features. In this case, QA is often referred to as " Questions & Answers" rather than " Quality Assurance".
  • As testers are always chasing Product Management, Developers, this gives rise to unnecessary feeling to these people that they are superior to QA and hence respect for QA guys is compromised.
  • Defect Migration increases i.e. the defects that were supposed to be found much earlier in the life cycle are found quite late. In this case, as the tester's knowledge regarding the product is gained over the period of time depending upon the clarifications received. By the time, tester gains good knowledge to test overall scenarios, the product is already nearing release. It is at this time most of the high priority bugs are found and lot is left for customer to find. This affects Return of Investment in a big way.
  • Estimation of efforts, resources and planning in general becomes difficult. As requirements are not there, it is difficult to decompose the functionality and hence, the division of functionality becomes tougher and it changes a lot during testing life cycle.
  • Most of the times, testers and Developers are out of sync regarding the functionality. It often happens that the tester logs a bug and developer does not agree to it and there is a long argument between the two. As requirements are not documented properly, the perception of testers and developers regarding the functionality often differs. It can be best viewed in Defect Tracking System database. Often Bugs in this situation would have a long history of confrontations regarding the way, Software "should" work.
  • The number of "AS-DESIGNED" defects in the defect database increases considerably. The tester logs the Bug but it turns out to be as per design. This may go against tester's appraisal, if management evaluates tester from number of valid bugs entered.
  • Automation of test cases becomes infeasible. As test cases are created quite late, practically there is no scope of automation. The Huge investment, organization makes on acquiring the automation tools licenses goes waste, as there is no effective use


About the author

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!