What exactly constitutes a good requirement is always subjective to some degree, but in most cases, as software testing engineers you will know a good one when we see it. You shouldn’t be concerned with less than perfect requirements as long as you understand them and know how they’re understood by the stakeholders and project team - and you can test them accurately.

Once requirements have been received by the testing team they can be used for identifying and writing tests. As the process of identifying and creating tests begins, it quickly becomes apparent whether or not requirements are good enough, since the major part of identifying and writing tests is gaining an early understanding of the requirements.

The software testing managers generally plan to have resources available to a project as soon as possible, even if the project doesn’t have a need for them until later. A lack of requirements doesn’t mean testers can’t plan tests. Of course, it’s difficult to know what to test when you don’t know the requirements. However this shouldn’t stop you from sketching them out.

Start with any related documentation that talk about the system being built or modified. From there communicate with anyone who will talk to you who you think may potentially, provide some enlightenment.

If the requirements analysts are available, talk to them - try to get a sneak preview of requirements.

Talk to stakeholders. Of course, if you do, make sure not to step on the toes of the requirements analysts and make sure it doesn’t look like a duplication of effort from the point of view of the stakeholder.

Document your requirements sketches in Use Cases or scenarios. Use these initial Use Cases to get feedback from people who know about the requirements. From there you can identify potential tests, sketch out Test Cases, and even get an idea of how tests may be implemented.

Yes, this is starting early and working against artifacts that are not the requirements, but this is a start, and you will be acting in a proactive fashion. If you’re wrong, you can always change things, once the formal analysis is underway. If you do your job correctly, and communicate as much as you can, you most likely won’t be far off the mark anyway and, in fact, may be able to contribute to the completion of the requirements.

What can and should be done when encountering poor requirements depends on the environment. It is important to do whatever it takes to continue to move forward quickly.

In order to get requirements accepted and changed quickly, suggest revisions and specific changes directly to the requirements managers. This way you know exactly how the requirement will look if it is accepted and you can continue with your activities of creating tests. If your suggestion or interpretation is off base, tweak your test to compensate. But more often than not your interpretation will be accepted if you did your homework.

This requirements help shouldn’t be considered doing someone else’s job either.

What should be your attitude as a Tester?
it doesn’t matter who is ultimately responsible for the requirements as long as they work.

How should you deal with this situation?
Make informal changes to requirements and document them. Write your interpretation of the questionable requirements using input from the requirements managers, stakeholders, or anyone who can help clarify. Document your interpretation and make it known that this is only an interpretation in order to move forward.

The interpreted requirements can be used to identify and build tests. As tests are executed, the tests can be presented to the stakeholders to show the interpretation of what is being tested. Most likely the interpretations will create more discussions that help clarify everyone’s understanding of the meaning of the requirements. Then, changes to tests to reflect clarifications can be made as needed.

Remember: Always take the bull by the horns.

Many More Articles on Software Testing Approaches 

If you want to keep track of further articles on Software Testing, I suggest you to subscribe my RSS feed. You can also Subscribe by E-mail and get All New articles delivered directly to your Inbox.