January 11, 2008

Faster builds increases testing time

Being a rapid tester, I try to invest in automating areas of my testing effort or using tools where the task requires muscle over mind. This accelerates my testing and allows me to utilize my frequent time crunch more effectively. Since testing time scarcity is a regular phenomenon, the R&D and selection of tools or to write code for such tasks is another challenge. In this post I will outline one case where my efforts paid off. Of course, there were cases where I reached a dead end after weeks of R&D and prototypes, but I will share that in another day.

My company develops a web application, that takes a significant time to build (compile) and deploy it to the application server. Usually a tester would get the latest source from the version control system, build it, and deploy it on the test server. This part was already automated with Apache Ant. Ant is primarily a build tool that runs XML scripts for doing all sorts of stuff, and is platform independent.

Even then, there are a few things the tester needs to do:

  1. Inform the other testers that the application is being updated and they will need to temporarily stop the testing on the server.
  2. Start the entire build process and monitor the progress at certain intervals, to see if it is completed. It is irritating when you return to the console to find that the build broke 6 minutes ago.
  3. Inform the other testers that the application is ready for testing.
Although these tasks are not directly linked to testing, they are a prerequisite. If you are doing this a few times during the day, you can imagine the idle time of the tester executing the build process. Also, the longer he delays noticing the end of a build process, the longer everyone has to wait for the deployed application.

It would be great to be automatically notified when a build is starting or ended or broke. Then all the testers can go about their other tasks, such as following up on reported problems, writing session sheets (for Session Based Test Management). So I preferred notification through instant messengers since we all use that for communication.
Some clarifications:
  • Jabber = Your google talk IDs are actually Jabber user IDs. So you are basically using a Jabber server to do instant messaging using google talk. You can host your own Jabber servers for intranet instant messaging.
  • Spark = A jabber messenger. We use it with our own hosted Jabber server.
The solution I am providing, can even be used for MSN, Yahoo and AIM.

So here is what I did. I found a way that Ant will:
  1. Notify all the testers in spark before the build process starts.
  2. Sleep for 30 seconds so that it can be terminated if any tester requests it, and wants to delay deploying the latest updates.
  3. Execute the entire build process.
  4. Notify all the testers in spark that the application is ready for testing with the latest updates.
  5. Notify all the testers in spark if there is a build error.
To do this I used imtask and ant-contrib, which are 3rd party libraries for Ant. Imtask has a jabber task to be used in Ant, to send instant messages to Jabber. It also supports instant messaging for MSN, Yahoo and AIM users. ant-contrib has the try/catch tasks I used in Ant to handle build errors.

Finally, for those who are interested, here is the code snippet from my build.xml that I run with Ant:

<taskdef name="jabber" classname="com.tfftech.ant.taskdefs.im.jabber.JabberTask" />
<taskdef resource="net/sf/antcontrib/antcontrib.properties"/>

<target name="all.with.notification" description="Let me handle it from here. And I will let you know when I am done!">
<antcall target="send.message">
<param name="param.message" value="${message.buildstarting}"/>
<echo message="*******Going to sleep for a while so that the build process can be stopped if necessary...*******"/>
<sleep seconds="30"/>
<echo message="*******Starting build process...*******"/>

<trycatch property="failure.message">
<antcall target="all"/>

<antcall target="send.message">
<param name="param.message" value="${message.onsuccess}"/>
<echo message="*******SOMETHING WENT HORRIBLY WRONG!*******"/>
<echo message="*******PROBLEM: ${failure.message}"/>

<antcall target="send.message">
<param name="param.message" value="${message.onfailure}"/>

<fail message="*******There was a PROBLEM. Stopping build process...*******"/>

<target name="send.message">
<jabber host="${jabber.server}" secure="true" from="${login.username}" password="${login.password}" message="${param.message}">


  1. Great !
    Its really nice to know about the Technique.

    Best wishes.

  2. thanks for sharing such tools.
    you can try continuum, which comes with build in im and email notificiation.

    i don't know whether you are using this technique or not. let's setup a issue tracker (where that issue tracker can create ticket by receiving email from a specific address.) (i know trac does) .

    now whenever you got a new build ready, your system will throw an email to the tracker. where tracker will create a new ticket for testing. and an email will be delivered to all associated testers.

    i think this has much better control over your task and responsiblity .

    best wishes,
    (*i am writing in lower case, because i am gonna make it a brand ;))

  3. Hi,

    That was a nice article and very informative.

    Another approach also is that the dev/testing team can discuss with the configuration/build team and come out with a kind of timetable stating when the actual build starts say like " everyday at 5pm there is a buid, which would take 1hr".

    So when the build is completed the config team sends a mail to testing/dev team informing them to start their testing.

    Again this depends on the size of the application/resource etc.

    So during this time the tester could do someother activities like updating test cases/test data etc.

    Also your blog is crisp, clear & neat and very neatly structed.

    Nice work....enjoyed reading your articles....since i too am passionate about testing.