Tuesday, July 19, 2005

Testing is easy, what’s the big deal?

Deepak had come down for an interview at a top MNC. He sat down in a chair, glanced around the conference hall.

“Actually,” He confessed, “even though I’m here for an interview for the testing position, I really want a job in development.” He gave his interviewer, Satish, a conspiratorial smile. “I’ve been in testing for two years,” He explained, “and I think I’ve pretty much done it all at this point. I’m ready to move on.”

Satish, who had been in testing for four times as many years and felt as if he’d just scratched the surface, was taken aback. Hmmm, he thought. Let’s see how good he is. Standing at an empty whiteboard, Satish sketched a dialog box with four fields and a button. He labeled the fields and then stepped back. “Here’s a form from a functional system. Given what you see, what tests would you want to run?” Satish handed him the pen in case he wanted to draw his ideas on the board.

“Well,” Deepak began without moving from his seat, “I’d try some boundary conditions, some negative tests, a use case or two, and I’d be done.” He looked very satisfied with his answer. Satish smiled. “And you’d be done?”

Deepak frowned as he thought for a moment, and then smiled in return. “Yup. I’d be done.” Satish’s smile dissolved. “Deepak, most of the candidates we have through here would have filled that whiteboard with tests. You’ve barely begun to explore the testing problem I posed to you.” Satish paused to let his criticism sink in.

“Want to try again?”

Deepak came up with a few more tests, but not many. He had no idea what Satish was looking for, and He didn’t particularly appreciate his attitude.

Testing is easy, He thought. What’s the big deal?

The big deal isn’t how many tests Deepak surfaced as much as his attitude toward testing. He thinks he already knows all there is to know. Satish, on the other hand, recognizes that professional growth can take a lifetime. He knows that no matter how long he spends in the testing field, he’ll still have more to learn. He takes time to nurture his skills, grow his abilities, and feed his mind. As a result, Satish will continue to progress in his testing career. Deepak’s career stalled after just two short years, while Satish is continuing to grow professionally and personally. How can you assure your continued professional growth?

Testing is almost infinite - Avoid contentment
Deepak was quite satisfied with his answer to Satish’s testing problem. He felt that he’d covered everything. But since testing is an almost infinite problem, no answer would be complete. Deepak had fallen into the trap of complacency. Testers like Satish know that no matter how many clever tests they’ve already thought up, there are more tests they could be running and that testing is infinite.



Consider the above example. How many test cases can you think you can write for this?
If we want to write one test case for each and every path that the above flowchart shows, there are 10 to the power of 14 possible paths! If we execute one test per millisecond, it would take 3.17 years to test this program!!

Whenever there is a lot of testing to be done and not enough time to do the testing, we have to prioritize so that at least the most important things get done. In testing, there's never enough time or resources. In addition, the consequences of skipping something important are severe. In such a scenario, we have to prioritize and make out how to find the most important bugs first.So prioritization has received a lot of attention. The approach is called Risk Driven Testing, where Risk has very specific meaning.
We have to prioritize testing by Risk. That makes sure that we're doing the most important things first. But we also need to allow some time to get some coverage of the less risky features and usage scenarios. Risk drives good testing!!!

Study Bugs
Satish has more than a passing curiosity about bugs. He seeks to understand them:
· Why did the software behave that way?
· How can I search out related bugs in other areas?
· What was the root cause?

It’s good if you study the bugs that have already been found in the software you’re testing. It’s even better if you study other people’s bugs, too. The next time you get together with a group of testers, swap bug stories. Meetings with other team members provide an ideal forum for a friendly chat about bugs with other testers working on different kinds of software.

No matter how long you spend in the testing field, you’ll still have more to learn.

1 comment:

Ahamad said...

The number of paths in the above example diagram are 10 to the power of 14 and NOT 1014!!!

Could not put in the superscript format.