TESTERS AND TEST MANAGERS often complain of having no requirements to test

against. At the outset, let’s dispel a myth. When they say there are no requirements,
they mean there is no requirements documentation. Surely the software could not have
been developed out of nowhere. There must be people out there who contributed
towards conceiving, designing, and building the software. They must have the bits and
pieces documented somewhere or at the least have them in their heads.

But how can the information in their heads be made available to testers? I have been
involved in software testing activities for more than four years now, and I too have been
frustrated by not having the right tools to do my job. So I thought about it for a while.
What are the strengths of testers? We are notorious for asking cheeky questions, aren’t
we? So, by capitalizing on our abilities to probe, explore, dig, and ask the right
questions, I created a tool myself by doing some reverse engineering —a tool that
makes requirements appear right before your eyes.

Step 1: Conjure Up Some Background Information

First things first—explore the software and try to understand its purpose and functions.
If earlier versions of the software in question are available, study them to get a better
understanding. If it is an existing product, scan through the defect reports, production
defects, and resolutions. Defect reports usually contain details about a broken
functionality. When there is not enough documentation available about the intended
functionality, defect reports are a good source.

Request (insist) to be invited to the meetings and discussions of the development team.
Some things may sound like Greek and Latin initially. Hang in there. Be focused. Your
mission is to learn as much as you can. Gather information about similar software, and
identify the features that typically go into the software. Browsing the Internet is one way
to get started with the information gathering process. For example, if you are testing a
Web-enabled order processing system or an enterprise information portal, you might
want to gather information on other products that are available.

Step 2: Create the Magic Table

All of this exploring and gathering will eventually raise a plethora of questions. Question
all the obvious and not so obvious functionalities. Do not assume anything and do not
leave any stone unturned. What you need to do now is crucial—document the questions.

Your questions will be definitely related to some aspect of the software. For example,
let’s assume that you are testing GUI-based software. Start by creating a table with four
columns (see Figure 1):

1. Screen/Window Name.
2. Object Name
3. Functionality Questions
4. Comments from Experts (Don’t forget this column!)

Fill it with a comprehensive list of all the screens/windows. Beside each screen/ window,
list every object or anything you had a question about that relates to that
screen/window. Every window and every object will have some functionality attached to
it. Based on the understanding you gained from exploring the software and doing the
comparative study (Step 1), try to write the functionality that you think is attached to
each of these objects. If the expected functionality is not clear, write “Not clear.” If you
have specific questions, include those questions under the functionality questions
column.

Have the key features that you identified in your study of similar products been
considered/implemented in the current software? If not, why? Was it done intentionally
to make the Software stand out or was it missed due to oversight? Write these questions
in the functionality questions column. The aim is to correlate questions to objects.

Step 3: Ask the Experts to Supply the Magic Words

You need to get those questions answered and your understanding verified. For any
object that you do not have questions on, phrase your understanding as a functionality
question. Circulate the table of questions to the technical gurus, the conceptual
designers, the business representatives, the developers—basically to everyone on the
team who could shed some light. Ask them to provide their answers, thoughts, and
interpretations for each row of the table. Have them list their responses in the
comments column.

Responses may not always be prompt, but remember, perseverance always pays. Send
reminders and frequently follow up. If this doesn’t work, offer to schedule a meeting to
walk through the issues/questions with them quickly. Try the divide-and-conquer
approach —instead of sending all the questions to everyone, send a subset of the
questions to each expert based on his/her area of expertise. If none of these approaches
works, seek the help of the higher-ups, and convince them that it is important to collate
this data in order to deliver a quality product. Urge the managers to communicate this to
all parties.

Step 4: Do a Little Sleight of Hand

Consolidate the answers, organize and categorize the comments, and get the consensus
of the group. Based on the answers provided for the queries by the experts, update the
functionality in the table (see Figure 2). Include every comment from each of the
experts. To keep from getting confused, process all the answers from each expert in
turn. At this stage, there may be many overlaps and disagreements among experts. You
may need to apply an iterative process if there are disagreements. Call for meetings, if
required.

Be persistent and persuasive, and persevere until all the queries are addressed and
disagreements are resolved. Eventually, you will get concurrence from the expert group.
Note the name of the expert who provided clarification on a specific functionality/
question in the comment column. This will help you follow up in the future.

Presto!

You now have a pseudo requirements document (but how “pseudo” is it, really?)
prepared by the test team, with the consent of all the players in the game. You can take
pride in a job well done. I have shared a table template that worked for me. You can use
the same template or improvise on it. The idea is to capture all relevant information in a
tabular format, and to keep this table updated if and when changes creep in.

Remember, this process can also be adopted when requirements are available but are
not very well defined. Initially, a lot of time and effort went into this, but soon the other
players realized the importance of defining the requirements clearly, and believe me, the
situation is a lot different now. Should you adopt this approach too? I think that it’s at
least worth a try. Good luck!

Figure 1: Magic Table in the making

Screen/Window
Name Functionality Questions Comments
Name
What types of inputs are
acceptable?
User Name Text
Login
box
How many characters
should be accepted?
What types of inputs are
acceptable?

Password textbox Display asterisks upon

text entry?

How many characters?

On clicking, display
Home page if username
and password are valid

Login button Display error if either is

invalid

What are the error

messages to be displayed?
Response time for
What is the acceptable
Home page/error
response time for Login?
display

Figure 2: The Magic Table

Screen/Window
Name Functionality Comments
Name
Login UserName Text Accept Alphanumeric Based on
box input of 12 characters. inputs from
Brian and
 Display “Enter only
alpha numeric values
without spaces or special Alan
characters” error if
spaces and special
characters are entered.
Accept up to 6
alphanumeric values,
Based on
spaces and special
Password inputs from
characters.
textbox Brian and
Alan
Display asterisks upon
entry of values
On clicking, display
Home page if username
and password are valid.

Display “ Enter Valid

Username” error if Based on
Login button username entered is inputs from
invalid Beth

Display “ Enter Valid

Password” error if
password entered is
invalid
Response time
Home page or Error Based on
for Home
page should be displayed inputs from
page/error
within 10 seconds Judy
display