Requirement Management

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. 2. 3. 4.

Screen/Window Name. Object Name Functionality Questions 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

Login

Name

Functionality Questions

User box

Name

Text

Password textbox

Comments

What types of inputs are acceptable? How many characters should be accepted? What types of inputs are acceptable? 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 Home page/error display

What is the acceptable response time for Login?

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

Password textbox

Display “Enter only alpha numeric values without spaces or special characters” error if spaces and special characters are entered. Accept up to 6 alphanumeric values, spaces and special characters. Display asterisks upon entry of values On clicking, display Home page if username and password are valid.

Login button

Display “ Enter Valid Username” error if username entered is invalid

Alan

Based on inputs from Brian and Alan

Based on inputs from Beth

Display “ Enter Valid Password” error if password entered is invalid Response time for Home page/error display

Home page or Error page should be displayed within 10 seconds

Based on inputs from Judy