Friday, July 22, 2011

Testing and the Cassandra syndrome

What a stressful week!

We’re now a couple of days from formal User Acceptance Testing for our new product, and we have a limited 2 week window.

In an ideal world we’d have had an early version of the software to run preliminary tests on.  But there was only one machine available, and the priority was both to give this first to marketing and then to training because “testing wasn’t due to formally begin until a week later”.

This made for quite a frustrating experience, as I tried to explain to management the importance of testing getting an early look at it.  But I wasn’t really listened too – I was told as our window was so tight, it would “just have to work first time”.

It actually made me quite angry – this was project management by desperation, and flew in the face of everything I knew.  There would be defects I said, as in my experience projects always had defects.  It’s one of the fundamentals of testing “test early” but management were insisting on a rigid waterfall interpretation of “test at the end”.

My feeling of this is much like Sun Tzu who said that,

“a victorious army first obtains the conditions for victory, then seeks to do battle.”

Basically I interpret this as before you formally test, you test informally anyway to know the overall quality of your product and when if it’s ready.

In software there’s often a “can do” attitude of we can do anything.  Unfortunately this sometimes becomes as the above comment “we’re so stretched for time, it has to work first time”.  Everyone is optimistic it can be done.

This is where the Cassandra curse comes in.  Cassandra was an Oracle blessed with the power of divination.  But after a fall out with Apollo, she was cursed that her prophesies would never be believed.  And so she could see the future but was powerless to prevent the disaster she knew was coming.

This is something I think too many testers feel.  When many managers and developers feel “hey it’ll all work first time”, testers are all too experienced that often it doesn’t.  They know this because it’s their job to deal with things when they fail, and they’re expert at working the problems.  In all my development experience, I’ve only ever had one thing work first time (ironically it was also the most complicated thing I wrote, a search algorithm).

Problem is it’s hugely demotivating to be ignored or disbelieved when you try and warn a project there are problem ahead.

We finally managed our preliminary tests today – a couple of big issues, but a whole host of mediums one as well.  Perhaps too many to address in the time left.

But hey, that’s why they call me Cassandra ….


  1. Was there any evidence from past projects that you could have used to back up your Cassandra premonitions of doom ?
    But I think all testers have been in this situation where HDD is being used - Hope Driven Development

  2. I empathize with you testsheepnz! I suspect there isn't a tester reading this that hasn't been through the same or similar experience. I work in a HDD environment (I've always enjoyed your humour Phil, I think I told you that once). testsheepnz, it can be demotivating as you mention, this is true; however I take the negative and turn it into a positive by tweaking my approach and communication. It stretches my professional growth and garners respect among peers. Attitude goes a long way; attitude is everything, especially when trying to improve process. Sometimes my ideas are adopted, and sometimes they aren't (knowing when to relax is important to retaining sanity). Speaking for my test environment, when time to ship is looming, and testing time is compromised, in the end, as long as management knows I poured 110% into testing, and my documentation is bullet-proof (should any crises arise post-release~ha ha), that is all I can do. I do hope for your sake and the customers' that your dev team does allow for more time in the future; keep asking, don't give up, just tweak the approach. Maybe if you play the money card (bugs cost x amount more $ to fix post-release) might help, hard to say. Perhaps you already have :) Best wishes for a great release.

  3. Massive sympathies.

    The words it "it just has to work" will just about always result in "OMG, why did it fail!?"

    I remember telling a release manager years ago, that we could test and communicate all the issues now or we could live with the shouting and hair-pulling after go-live. The go-live was not moved, development worked right up to the wire and there was no build released to testing.

    That release manager runs a credit union right now.

    Perhaps if you made them the sort of list that Laura suggests above: Risks of not testing and the costs of each risk, it may open the eyes of your project management. For instance: Application cannot be launched, users cannot use it, users lose faith and move to competitor, loss of revenue and market share for our company.

    Tell those senior to you that you are not recommending testing to protect your job, you are recommending it to save their jobs. After all, who wants to be the one known as the wo/man who didn't sign the Beatles?

  4. Thanks guy - my that was therapy wasn't it?

    I think one of the problems is if you have a project manager who doesn't have enough experience of the software lifecycle you just sound like a doom-monger.

    I am in the same situation ironically with two project managers who are both inexperienced in software. One however will listen to (not just my) input, and hence we make progress.

    It's the project manager who won't listen though where I feel myself tensing for a crash ...

  5. "this was project management by desperation"

    Sounds like project management by ignorance. Or an ostrich project management. Things getting hard and stressful? Bury head in the sand and hope for the best!

  6. Nicely explained. Here you described the well written article from your in-depth knowledge. Truly impressive and nice information

    Java Training in Chennai Core Java Training in Chennai Core Java Training in Chennai

    Java Online Training Java Online Training JavaEE Training in Chennai Java EE Training in Chennai

  7. Quickly Solve Cassandra's Bugs and Errors with Cognegic's Cassandra Technical Support
    Ensure, in the event that you think or experience any kind of specialized issues with respect to Cassandra, the primary spot is to unravel these issues is Cognegic's Apache Cassandra Support or Cassandra Customer Service. Our expert specialists are here to settle your issues which avoid you to work with your Cassandra Database. We have very gifted and experienced specialized specialists who have earlier long periods of involvement in a similar space. One thing more, on the off chance that you are not happy with our administrations then we give unconditional promise moreover.
    For More Info:
    Contact Number: 1-800-450-8670
    Email Address-
    Company’s Address- 507 Copper Square Drive Bethel Connecticut (USA) 06801