First Things First

Continuing the discussion about our distilled experience in test automation, we will continue our discussion, starting with the basics. Anyone who can type a semi-colon, can write code. Writing code is easy. Writing good code is not. And writing good code which can test other code is even more difficult. Common mistakes to avoid when embarking on the test automation journey are:

 A. BUFD (Big Up Front Design)

In today’s ever evolving world, it has never helped developers to create huge design artifacts in the very beginning only to dis-mantle, re-do, re-work and waste lot of time (and money) in the process. This holds true even more for test code. Investing great amount of time in designing and creating testing frameworks which are not immediately put to use in a live test script is bound to put pressure on the test engineers as time-lines shrink and delivery deadlines converge. Result will be beautiful, unusable test code and, even with good deal of investment in test-automation, poorly tested application. Needless to say this will result in a spiral situation further worsening as budgets will be questioned by stake-holders and will shrink since it will be very difficult to demonstrate value-add from code which is still in the kitchen. No customer will pay for a dish as long as it is in kitchen!

B. NUFD (No Up Front Design)

This is contradictory to BUFD, but equally catasthropic. Directly jumping into creating test scripts without thinking through aspects of maintainability, “extensibility