1

My client doesn't have a full requirement document but they want their software delivered anyway.

How should I go about designing tests for the client, and how should I test their product?

I would appreciate examples using something basic like a login page or forgot password module.

2
  • There really isn't enough information in your question for us to give a good answer. Please look at sqa.stackexchange.com/help/how-to-ask and review some of the high-vote questions to see what this community regards as a good question, then edit your question accordingly
    – Kate Paulk
    Commented Apr 24, 2017 at 11:22
  • @ Kate --My question is the client is not having complete requirement what they want, but they need some product. In this scenarios what test method and test type I need to follow Commented Apr 24, 2017 at 11:56

2 Answers 2

4

But, there are ALWAYS requirements - even if they are not formally documented. They may take some time to discover and list, but they exist.

First, look for general requirements and work to document them. Some of these requirements come from previous versions of the application, some come from generally accepted usage.

Then, interview the project manager or developers and find out what they intend to do with this release. Document the intentions and use them as requirements.

Sometimes, writing all of this up as assumptions can go a long way toward gaining a consensus as to the "real requirements" you can use to test against.

Once the system is at all testable, do some exploratory testing. As you find "undocumented features", add them to the list of topics to be discussed.

Find out if the product is internally consistent. (This is an area I find to be very useful) Even if I know nothing at all about a product, I assume it must be consistent within itself, and within the environment in which it must operate.

Look for external standards within which the product must operate. If it is a tax or accounting program - tax law must prevail and generally accepted accounting principles must apply.

see: There are ALWAYS requirements

2
  • 2
    I would also review the most recent bug lists to get a feel for what areas of the product are most prone to bugs, which also tells me which areas of the product are most accessed by the end users. If mutliple platforms and versions are supported, the bug list would also indicate that. Commented Apr 25, 2017 at 18:32
  • @LauraHensleyCTFLCMT - good point! If the product to be tested already exists, you should always look over the bug list. Lots of good "requirements" clues there. Commented Apr 25, 2017 at 18:33
3

How do I test when I have incomplete requirements?

Like you normally would.

You'll never have complete requirements, there will always be some information missing or things you don't know ahead of time. That's one of the reasons why we test.

How should I go about designing tests for the client, and how should I test their product?

Requirements testing is just one technique for testing. There are many others, like functional testing, scenario testing, performance testing, load testing, domain testing, etc. Any good job of testing will involve many techniques, not a singular one.

You need to make your own decisions and ask questions to determine what your information objective is. Once you understand what information you are after you can decide how to test and what techniques you'll use.

2
  • @ Chris ... Thanks for your info. Here my scenario is client having the only minimal amount of requirement but they need product, They are not worried about what output is going to get. I need to know what test model need to follow in this case Commented Apr 25, 2017 at 7:55
  • @Anand sorry, what you said makes no sense. If they are not worried about the output, then you don't need to test. Commented Apr 25, 2017 at 19:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.