Monday, March 07, 2005 - Posts

The importance of being Extreme with Development Testing

posted Monday, March 07, 2005 7:39 AM by ranjan
  When developing a product, one of the most important problems that a development team has to tackle is the fear of the unknown. While both services and products concentrate on an act of automation for the end user, in contrast with a service that serves a single company, a product focuses on enhancing productivity of a totally unknown set of customers.
A product development team has to understand that each of their small actions will have a tremendous effect, with (hopefully) thousands of users reacting. If going in the positive direction, the team can really help out the users to high productivity and quality through automation of an activity.  On the other hand, a simple flaw in the product can make a lot many customers feel miserable about the whole idea of automating a process.  

Importance of Developer Testing and TDD


The foremost feature of any software product is its quality. The development team must ensure perfection of their code. They must never be complacent about the quality of their product. Traditionally, it has been the responsibility of qualified and experienced Quality Engineers to ensure the perfection levels of a software product. There are basic flaws in this being the only quality ensuring process which is followed, and these are because

•    A Quality Analyst directs his/her attention to only the functional aspects of the end-result.

•    A Quality Analyst cannot make sure of extensibility in design. Though quality and extensibility sound unrelated, they have a very deep cause-effect relationship. An inextensible product can be totally flawless, and pass all quality measures, failing some later on enhancement requests, demanding a change in design. Thus a design perspective is wanted.

•    A Quality Analyst has no idea what the code looks like. With the highly dynamic nature of personnel developing a software product, it has become very important for a developer to ensure universal understanding of the code they write. What can be achieved with proper comments and refactoring never (and should not) bothers a Quality Analyst.

•    A Quality Analyst can only test the product through its GUI. When the team wants to expose the central API of the product to 3rd parties to develop enhancements, or decides to customize the GUI for an important customer, a completely new set of use cases come into picture. A Quality Analyst can only test all these if provided a GUI, which not only is time consuming, but unneeded in the wake of new development tools provided for White Box Testing.

•    An automated Regression Testing marathon, does not dig any deeper, as a QA totally depends on the UI of a product.

 The most productive option to tackle these flaws is to encourage developers to test their code, feature by feature, following TDD. It is of utmost importance that all features are broken down to the lowest possible granule and then each granule tested. This is roughly equivalent to checking each brick while building a house, which is what the owner, would love the builder to do.

Breaking complex features into small units enables a developer to understand the expectations perfectly. When a test passes on a unit, it gives confidence to the developer that he/she can build over this brick.  And it is imperative that the development team will identify design flaws that might result into redesign much earlier, or at the least encourage an extensible design. Automated regression of persisted unit tests ensures much higher quality than the regular GUI testing tools, and what better if both of them are used together!
with 0 Comments