posted on Monday, March 07, 2005 7:39 AM
by
ranjan
The importance of being Extreme with Development Testing
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!
Comments