Thoughts on Best Practices

Whole of June I was on a consulting assignment at a company in Wall Street. Right from the project initiation, our sales team has mentioned about our newly achieved CMMi Level5 certification on every available opportunity. I was also proud that I am associated with something big. During the last few years, our SQA team which works for maintaining and upgrading all these, have enlightened me on the great certifications that we are preparing for.

In one of the casual discussions with the client, the CMMi came up again and I started explaining to him in detail, the great processes that we religiously follow because we are CMMi Level 5. After listening for some time, he asked me “So, how do I benefit from your certification?”

What a stupid question to ask! Doesn’t he understand that I follow a lot of “processes”? Why can’t he appreciate all the effort that goes in to the system to prepare all those matrices and analyzing them? Did he not get a chance to have a look at our “quality site” that lists an ever growing list of processes? Even with all these questions in mind, I was struggling for an answer.


As testers, what are we delivering to our client if we have a CMMi Level X certification? Does Carnegie Mellon Institute hold the key to quality, which they distribute on a retail basis? What is the best testing practice that every testing company in the world should follow? It triggered my curiosity.

I was searching for best practices, searched on Google, I got many. Talked to friends, I got still more. I looked at our company’s quality site. I got still more. There cannot be so many best practices! Something is seriously wrong.

Yes. There cannot be so many best practices. But are there any? Unfortunately, the answer is “NO”. I came to agreement with some of the best names in the industry as to “There are no best practices in software testing. There are only good practices”.
I am sure, I have experienced it, even though never formalised the thought, that every project needs a different focus, a different approach and a different set of heuristics. Only difference is that now I understand it as a reality. Probably the only process that is relevant to all projects is to find the processes that suits the project. The ones that fits into the context. This revelation has lead to one good thing: I got attracted to the context driven school.


More about it later.

Testing Test Readiness

Qualifying a build for test is not easy always. A build that is not “ready” for test, pushed into the test environment can eat a considerable amount of your testing effort thus upsetting the test estimates as well as schedules.

There of course cannot be a universally applicable way to test the test readiness of a build before it gets deployed in the test environment. But, carefully planned smoke tests prior to acceptance of a build for testing can considerably save the time and effort that goes into testing. In a perfect world, developers unit test their code before they deliver the build. But unfortunately we all live in a world that is far less than perfect. We do need to test; we also need to test whether the build is ready for the test. Probably this is one of the most important instances where the testers “refuse to test”.

It therefore becomes important that the selection of tests for smoke testing (the test readiness test) should be appropriate and well representative. There can be a core test set and a supplementary test set based on bug history, testers error guessing capability, prior experience with this or similar applications etc. Some of these tests may retire during successive cycles.

It is a good idea to automate the core test set to reduce the cycle time. You may even want to share the smoke test suite with the developers so that they know what you are looking for. It is always a good idea to brainstorm before arriving at the core smoke test set.

I found some interesting thoughts on smoke testing here...