Monday, November 19, 2007

Alchepo Guide to Software Quality Assurance

Face it. Most teams don't have time to do a proper quality check on their products, instead most depend on "trust". Its impossible to expect the Guru programmer to check everyone's source code to look for flaws and potential problem. Its equally insane to expect amature programmers to code like a pro equally.
So how does one implement quality inspection on the code? In many cases, its the end product that is installed and tested in a given time. Although end product testing is a must, i am talking about other stages where quality can be enforced and not just the end stage.

Here are some of my suggestion, mostly based on William Edwards Deming's key recommendations and paraphrased. Who is he? If you study on how Japan manufacturing and quality rose from the ashes, you will know who this person is. http://en.wikipedia.org/wiki/W._Edwards_Deming

One of the important rule you have to remember is :-

- Substitute personal supervision with.. Statistics.
This means you must ask your programmers for proof of quality instead of "have u tested it?" etc. For eg, ask him/her to run a set of tests and show u the result of those tests on his routine/function.
One alchepo way is to also record down the memory usage and handles of the program by simply running the task manager and recording the usage of that process before/during/after the tests are conducted. This simple practise ensures that no crazy leaks occur in the program which will result in those popular scenario where the program runs perfectly in day 1, but crashes in a week.
This should be conducted whenever they perform unit test on their new routine/program.

- Diverse data testing
One of the most evident proof of an amature programmer is when he/she says "it runs ok on my machine" where else it crashes just after deployment on the first client pc.
The product/routine must be tested in as diverse scenario as possible, you dont really need an infinite number of pc's to do this, just some range of diff setup. For eg, a new setup with no service pack or on Virtual pc, and some end users pc you have in your office with loads of rubbish loaded. Better still is the industry practise of providing a beta testing to selected clients or public.

This is by no means a complete or even decent article on software assurance, but if your team have no proper method anyway, these 2 steps alone will secure ur eternal gratitude to this blog . ;-)

No comments:

Post a Comment