Random Blog

Monday, February 5, 2007

Its all about quality

Very often while making a software- we tend to forget the whole purpose behind the effort- that is to deliver a (quality) product.

While its conceptually possible to make a software with zero bugs- its as unlikely as possible that it will have ever happen
A probabilistic uncertainty in fact.

But we can all try...

IMO- this is what is needed

1) Its the quality and not the quantity of testing that matters.
Its not about bombarding the application with zillion tests.Its about intelligently drafting a QA strategy and executing it successfully.

2) The QA team needs to understand the technology and the design
to better explain with an example: Consider a product which uses home grown component library .A bug in the library may cause some features of the application to malfunction. After the defect has been identified and fixed- the QA team cannot test it successfully unless they knew where the problem was and how it was fixed.

3) Think like customers
Know your customers. Think like them. When testing - test not as QA determined to complete the testing- but as customers using the application with only one aim- finish today's task and go home.Th end users are not using the product to blow it apart. They simply want to be able to do what they want to do.

2 Comments:

Blogger Shailender said...

Well said Rajiv. I totally agree. When I see fan boys of Unit testing believe that one of the best practices of software writing is to write unit test and increase coverage. Don't get me wrong, it is important to write tests but I am talking about fan boys who just overdo it. Many techies take more pride in stating how much test coverage they have on their projects rather then stating how less bugs they have or how reliable the product is and how users find it useful and have great experience. I find it amusing because increase in code coverage does not necessarily tranlate into good quality. Sure it helps if tests are designed well but testing each simple method call for the sake of increasing coverage is counter productive.
The purpose of testing is to reduce the impact of change and increase reliability and to make sure that software does what it is supposed to do. And the purpose of all this is to reduce the cost for business to write and maintain the software.
So when every single method has an associated unit test, every single change means rewriting the unit test as well. And in real world where changes keep happening, it significantly increases the cost. So the answer is not 'No Unit tests' or 'Tons of unit tests' but sensible unit tests combined with funtional tests as you mentioned. Engineers should not just check in code to repositories if their unit tests pass as many do.

February 16, 2007 at 7:43 PM  
Blogger RN said...

True- unit testing is important and indispensible- but doesn't displace wholistic testing where you dont think like a programmer who knows the code but a user who just wants to do his job.

February 17, 2007 at 5:59 AM  

Post a Comment

Subscribe to Post Comments [Atom]

<< Home