Your next build arrives at…

Does this sound familiar? You are on a bus stand waiting for the next bus and you don’t know when it will arrive. You look around and find no schedule hanging out and all other passengers are clueless as you are. You ask the one standing at the stop and who looks to you as a frequent traveler on that bus route: “sir, do you know when the next bus will arrive?”. The old man smiles and answers “Any time. May be 5 minutes and may be two hours depending upon how lucky you are 🙂 “.

Bus arriving at a bus stop

Original photo at: http://instring.com/2009/06/02/sf-solar-bus-stop-technology/

Now does this sound familiar? You are on a release cycle and you are waiting for next build. You look around and find no schedule in any of the project pages and all other team members are clueless as you are. You ask one of the senior members of the team who looks to be seasoned with multiple release cycles: “sir, do you know when the next build arrives?”. The old man smiles and answers: “Any time, May be in next hour and may be in two weeks depending upon Project Manager’s mood 🙂 “.

This uncertainty leaves you in a “no planning zone”. If you are waiting for the bus, you cannot walk to the nearby shop to grab a sandwich or a cup of coffee fearing that you might miss the bus. And if you are waiting for the build, you may stop yourself running your next test plan fearing what happens if next build arrives.

So as team members, testers, programmers, project managers how can we remove this uncertainty? “Make a Build schedule”. Compare it as if you are planning to operate a bus route and this will help decide how many buses (builds) you should ply:

–        Are there any rush hours? The build schedule cannot be the same for the entire release cycle

–        How many passenger you expect? What is the defect removal efficiency of the team and how quickly new defects are being logged?

–        Do you see over-crowded stops? The schedule can be such that it puts the testing team to wait too long for the next build. Or it can be too quick such that overheads (like build download and deployment, test data creation) are killing most of the time.

–        And so on…

How is the bus schedule on your route? And how is the build schedule on your project? Share your thoughts.

3 responses to “Your next build arrives at…”

  1. Sohail says :

    Well, it used to be two builds a week in my prior organization (a well defined span for routine testing). The factor of uncertainty used to arise when priority builds were produced. However, this was practiced when release was to be finalized with frozen backlogs. (Justified and fair enough).
    Currently, we suffer the “Hodgepodge” schedules where no one knows nothing about release and all of the sudden release of patch is announced promptly (becomes very nasty to handle)

    Like

  2. H Hamid says :

    I agree! It is such a wonderful practice to define a build schedule at team level. I have worked in both the situations where everyone knew when the next build is expected and when you have no idea if the build will arrive in a week, a month or a couple of months or even more. As a test engineer, I would definitely prefer the first one for better planning and preparation.

    Like

Trackbacks / Pingbacks

  1. The rate of change | Knowledge Tester - May 1, 2013

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s