LOGIN | REGISTER NOW | SUBSCRIBE
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 7/1/2009 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
Is the mystery Borland suitor Serena?
Borland software is considering an offer from another company after a preliminary deal with MicroFocus. Is Serena the new company?
06/30/2009 01:55 PM EST

Windows 7 - An eBayer's dream product?
Windows 7 pre-orders can make people money on eBay.
06/29/2009 03:48 PM EST

Know thine cloud provider
Cloud computing require companies to understand compliance and regulation. Third parties will play a big role in regulated industries.
06/29/2009 02:58 PM EST

 

Microsoft Worldwide Partner Conf.
7/13/2009 to 7/16/2009
New Orleans
Microsoft

OSCON (Open Source Convention)
7/20/2009 to 7/24/2009
San Jose
O'Reilly Media

XBRL Technology Workshop & Summit
7/28/2009 to 7/30/2009
Santa Clara
XBRL US

ACM SIGGRAPH
8/3/2009 to 8/7/2009
New Orleans
ACM SIGGRAPH

OpenSource World (formerly LinuxWorld)
8/12/2009 to 8/13/2009
San Francisco
IDG World Expo


 
print Printable version 
Most Read Latest News Blog Resources
Kapow automates website data retrieval
Kapow Technology's Web Data Server 7.0 can be used to create modules that navigate through...

COBOL’s future lies in the clouds
After 50 years of use in businesses, COBOL is still lingering around mainframes. But the s...

Oracle's Fusion 11g lays groundwork for ERP platform
Fusion's components are standards-based and integrated, but some abilities are lost if non...

Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter

Testing Without Requirements—Impossible?


By Edward J. Correia
June 26, 2007 — 
As crazy as it sounds, there are actually teams of software testers that perform their job without the slightest clue of what the application under test is supposed to do. How is this possible?

It isn't ideal, of course, but it's often the case, says Prakash Sodhani, a quality control specialist with a global IT services organization. "Lack of documentation during project execution is a frequent occurrence," says Sodhani, who holds numerous degrees and testing certifications. "With the competitive nature of business growing and time to market declining, businesses are more concerned with getting something out in the market than about following a standard process."

Less than ample documentation also can be blamed on changing user requirements, on-the-fly development, legacy systems for which documentation is lost or destroyed, and extremely large or expansive systems. "A large system may not be documented well enough for the tester to form complete test scenarios."

And some systems aren't documented at all. "But as a tester, you are expected to test the system anyway. This can pose a great risk, as requirements will never be clearly understood by the test team," Sodhani says. This can lead to a product that the testers can't test and that end users didn't expect. "Developers sometimes even cite incorrect system functionality as the expected behavior," says Sodhani. "A tester's job depends on the accuracy of available documents. So asking a tester to test with no documentation is the same as asking them to guess."

So what should a tester do when faced with testing without requirements? "Even with the lack of documents, there are certain things that can help us to do efficient testing. It doesn't substitute for having documents available, but at least helps us ship a product with a reasonable level of confidence."

Sodhani asks us to consider the following two companies:

Tradition Inc. assigns its business analysts to meet with users and gather and document their requirements for a new application. From the user meetings and requirements documents, a UI team prepares screenshots of the expected user interface screens. At the same time, the development team prepares technical design documents based on the requirements documents. The test and QA teams are given the requirements documents and screenshots and asked to develop test artifacts, a test plan, test cases and other documents. A detailed report is prepared at project completion.

A second company, ScrumCo, has its development and testing team meet once a day for 15 minutes. In the daily meetings, each team member explains what's been done since the last meeting, what (if anything) has impeded their progress, and what they plan to do until the next meeting. The daily meetings are used in place of documentation.

Features to be implemented in ScrumCo's application are discussed at the meetings, and plans are modified as appropriate during subsequent meetings. What limited documentation that is created consists only of feature names with one or two brief lines of description. At project completion, an informal report is prepared documenting the project.

Which one of these scenarios is most like your situation? In which company would you as a tester feel more comfortable? Obviously, Tradition Inc. stands out with a better process, says Sodhani; documents are created at each step of the project, everyone understands what is expected and can refer to documentation as needed.

If ScrumCo is most like your situation—and even if it's not—here are three essential testing objectives and ways to help you achieve them.

1. Find out what to test
"This is the first and most important thing to do," advises Sodhani. "In the meetings, you will be getting feature names and maybe a short description. Find out what you are supposed to test, figure out the exact requirements and prioritize them. To do thorough testing, you will need more information than initially supplied to you."

One key to solving this problem is to listen. "Your active listening qualities as tester can come to your rescue. In daily meetings, listen to everyone very closely. Sometimes, you can learn about a person's qualities just by listening. Once I have a tentative list, I pick a question to ask and go down my list one by one. I prefer to use e-mail or instant messenger to ask my first question. Sometimes you can guess if the person is willing to answer your questions just by their initial response to your ping."

It's also important, Sodhani says, to craft your questions carefully. Be sure you're not asking about something that's already been covered or documented and that you simply missed. "You have to realize that everyone has work of their own, so ask intelligent questions. Once you've figured out who will be the most helpful, one of your biggest hurdles is out of the way."

2. Figure Out How Much to Test
"Sit with users and others who might know more about the functionality you will be working on." This can't replace a formal requirements specification, adds Sodhani, but it might help you figure out how much functionality you need to cover.

"In one project, where I was relatively new, I started to find defects like a field accepting special characters and cut/paste not working. In my next meeting I was told not to worry about these kinds of defects. However, I was never told what defects to worry about!" In this type of scenario, it may be impossible to determine the total testing coverage needed.

Again, it's important to ask intelligent questions. Discover and test as much functionality as you can, and ask whether any defects you find are important enough to warrant further attention. If not, make a note and move on.

3. Know Whom to Ask
"This can be most frustrating of all, as you find yourself running around trying to find answers." Remember, people are busy, and might not be as inclined to help as you would think. Even more difficult is if you're assigned work on a project that was started some time ago. "In this case," Sodhani says, "you not only have to figure out what happened last time it was tested, but also how it is going to be related to something happening now."

Taking the initiative can be a good thing, particularly if it's meant to help you learn something. And in a company like ScrumCo, it may be the only option available for discovering what you need to do your job quickly.

"I liked what a friend of mine did in a similar situation," Sodhani says. "His supervisor would assign defects to testers who were most familiar with the functionality in the defect. My friend asked to be assigned defects with functionality he was not familiar with. This helped him learn quite a lot that he might not have otherwise."


Share this link: http://www.sdtimes.com/link/30804
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading