Software Release: False Alarms, Stress before the Deadline, and, Prospering Bugs

I did my first false alarm! 

We are working on this integration project for way longer than we thought to work. Bugs kept appearing, or, coming back to life. Finally, on our _4th_ final testing cycle (all cycles before failed), we got a build with a good feeling that it may be the release candidate build. Maybe it was the historical day with test plans actually passing! 

After a delayed release all the team is tired: developers lose hope to fix bugs and leave them for further releases, testers want to start testing something new as it gets a bit repetitious, and, everyone in general feels a bit low. Every new bug is way more painful if the deadline for release is coming up. Here comes the psychological crisis: developers feel like their coding is still not working after all this time and are a bit bitter on that, while testers…. Testers don’t get any support for finding bugs at this stage, a new bug is like a curse that nobody wants to have (even if it is silently valued: having in mind that the issue won’t be there after the release after the fix). But as I talked in previous post – being a software tester can give you a lot of psychology lessons, too! 

Also, when release is nearby every bug matters. If there comes a serious bug to be fixed in this release – you must react as soon as possible, let all the development and test team know about it. 

So, I did. I was testing a so called 0 bugs build today, and, well… one bug which had to be fixed in this build seemed to reproduce. It was weird that one case of it was fixed and another wasn’t, but I was trying to be very quick and inform the team about recurring issue. I sent an e-mail saying ‘BAD NEWS. This bug reproduces. I’m sorry!’. 

After I sent it and I reopened a bug (which was very painful as it was our release candidate and it was not anymore a real release candidate), I got concerned. How come it was fixed for one case, but not for the other… I ended up re-checking, re-installing everything and making my machine as fresh as possible. For my biggest horror: it actually was fixed, and, before my machine was not clean enough (had some left influence from previous builds). I wanted to bury my head into the ground: I just wrote a response to that e-mail I sent ‘Nevermind, False Alarm, I’m so sorry’. Dev lead replied that ‘It feels that release is coming… ‘. 

However, I actually found a real issue later on. This time I first checked a few times before filing it. And, well, it’s horrible, but, I destroyed the dream that this build was a release candidate. But it’s my job and it’s better to find it now than after the release. 

So, some bugs must be fixed, but… there are loads of bugs that are ‘pushed’ to the further releases as at the stage before the release date it’s too risky to fix them: may ruin something else and cause harm. That’s how we get those bugs that are always there, everyone is aware of them, and… they keep getting pushed for the further releases. 

Image

Advertisements

2 thoughts on “Software Release: False Alarms, Stress before the Deadline, and, Prospering Bugs

  1. Nice sharing of experience.
    The pace at which development teams are working, at times it is a hard decision to let the team know about the findings or wait for few more ‘double checks’ first. I agree to your thought on not creating false alarm, but still think that information sharing shouldn’t be delayed too much to perform all the checks.

    • Hey, Majd,

      Thanks for your comment!
      Yes, it is a bit tricky before the release: you must react quick, but also not too quick in order to avoid making false alarms.
      Some will happen time after time – for sure, as it may take loads of time to re-check everything again and better to tell everyone before you re-checked.
      However, always try to consider other factors which may influence it when you’re in a hurry. There is enough of stress before the release anyways, no need to put more with false alarms. 🙂

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