There are ALWAYS Requirements

Occasionally, I hear the question - "How can I design test cases, if I don't have a Requirements Document?"

But, there are ALWAYS requirements - even if they are not formally documented. They may take some time to discover and list, but they exist. Here's one approach to finding those "hidden" requirements.

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. For example:

• Must run on platforms x,y,z (perhaps because those platforms have always been supported)
• Must use abc database
• Must be able to process n records in m seconds
• Must be at least as fast as release n - 1
• Must not consume more memory (or other resources) than release n - 1
• Must not crash
• Must not corrupt data
• Must use standards relevant to the platform (standard Windows UI, for example)
• Must be consistent with relevant laws, regulations or business practices
• Must not have any misspellings
• Must be grammatically correct
• Must incorporate the company's usual look-and-feel
• Must be internally consistent
• Must work in particular locales
• Must be complete when expected by the stakeholders (perhaps for some event, such as a Beta)

If it's a web site or application, some additional requirements might include:

• Must not be missing any images
• Must not have any broken links copyrightjoestrazzere
• Must bascially work the same in all browsers which are officially supported by the company

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.

Solicit input from anyone who is a stakeholder in the project. Share everything you find with everyone and revise it as needed.

Does the product have a Help file or a User Guide? If so, that's a good source of requirements.

Do Sales materials exist for the product? Certainly the product should do what these materials say that it does.

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.

Ideally, all of these issues have already been considered and written into the formal Requirements documentation which is handed to you. But if not, don't give up. Dig in and discover!

(also see: http://strazzere.blogspot.com/2010/04/checklist-for-good-requirements.html )

added 10/20/09:

As Catherine Powell points out in her excellent blog, even without specific requirements, software must also be "a good citizen". (http://blog.abakas.com/2009/10/good-citizen.html)

She defines the term as:

"Software that is a good citizen behaves in a manner consistent with other software, with regard to interaction with other assets with which it interacts."

And she elaborates this way- Software that is being a good citizen does:

• support logging in a common format (e.g., NT Event logs, etc)
• use centralized user or machine management (e.g., Active Directory or NIS)
• does automatic log rolling
• can be configured to start on its own after a power outage or other event
• can be disabled or somehow turned off cleanly (to allow for maintenance, etc)

Software that is being a good citizen does not:

• log excessively (at least, except maybe in debug, which should be used sparingly)
• create excessive traffic on infrastructure servers (DNS, Active Directory, mail, firewall, etc)
• send excessive notifications (e.g., a notification for every user logging in would probably be overkill)