Capturing a test case as soon as its born

Abhimanyu Grover
April 8, 2011

ABC Company is a hypothetical profitable small sized software development company with 30 employees. Their workflow is pretty simple:


1. Capture requirements
2. Plan
3. Code
4. Test
5. Pack/Deploy

They do pretty well with all the processes. Their last project was a big success and now they are getting ready with the new project. While they were on their Phase 2, i.e. planning, Robert, their junior developer while reading requirements went through ‘CSV Upload’ feature. From the idea he concluded that this should handle both types of CSV files – one with the headers and one without. So while testing, he established, both such files should be checked. He checks with his senior developer, who agrees and says he’ll keep that in his mind. But as all of us know, our mind is terrible at remembering things, the release date came near and software was marked ready to be shipped. Now a day before delivery, buyer is shown full featured demo of the product. The not-so-computer-savvy buyer makes a CSV file real quick in an excel file without the headers to check the great CSV Upload feature and suddenly identifies that it is not making any sense. Add 4-5 instances like this and they’ll surely delay a day or two in your project.

So the point is: do you see how a ‘test case’ plays an important role? Apart from that, how important it is to capture a test case as soon as it has taken birth in a team member’s brain. We think, very important. Because it happens only while working on requirements, planning and coding that you are so deep down the project and have most insight about a project. That’s exactly when you should start thinking about test cases. But Robert didn’t do it – why? Because he had no platform to fill in the piece of information he had in his brain, where others could see and act on it. So what do people like Robert often do when they don’t know what to do? Sometimes they talk and sometimes they forget about it – even if they talk, chances are that piece of information is still lost because that’s not in a system others rely on. There’s also another article on why you should involve everybody in your team in testing.

Now hypothetically, lets say meanwhile in ABC Company, they discussed and figured out that they need some sort of control or management over testing. They started using Test Collab. Every team member was instructed to post in a test case as soon as they thought of it. During the end of each phase, seniors would review the reported test case, and give a go ahead. Before testing, senior developers would arrange test in sequential order, and assign them to testers. They also configured their bug tracking tool with Test Collab, which meant that instant a failure is reported, the whole development team will be informed of the failed test. CEO and other managers go through the stats produced by Test Collab and can easily conclude if their testing is slightly growing to take more time, or if the staging instance of software they have deployed has suddenly a lot of failures.

Testing automatically will become more interesting and fun once a process is standardized.

Do you already capture test cases right after they’re born? Let us know.