If you’ve never been part of a stressful software development project, you obviously haven’t been in testing for very long. So many of the world’s most cherished software products are the result of hours and hours of pure hell. It’s true, and you know it.

See if you can relate to any of the following:

  • The client isn’t 100% sure about what he wants. Every day, he has an awesome new feature he’d like your team to incorporate. And review after review, he offers the world’s vaguest feedback, asking if you could add more “pop,” “pizzazz,” or some other equally unhelpful, nondescript term. The client is sometimes elated, sometimes distraught (usually for reasons beyond your control). But you have to deal with these mood swings. Oh – and you’re just on day 3 of a 5-month build.
  • You and the development team go round after round of debugging, during which, you alternate with variations of, “I don’t know what you mean. It works perfectly on my end. Can you try it again?” On some days, it’s as if you’re not even speaking the same language. Your development team becomes annoyed by all the back and forth. And they have to work furiously to incorporate the client’s changes and your software testing feedback.
  • Over time, the feedback and changing priorities bring everyone down. Management is under pressure (because of the client). You’re under pressure (because of management). And everyone kind of hates everyone else. Ah yes! And finally, your on-site servers crash, potentially erasing hours of hard work and robbing everyone of precious coding time.

I think most of us have experienced situations like these and worse. They make for great stories further down the road (much further). But while they’re happening, it’s sometimes difficult to grasp the humor of it all. This is especially true when all the bad things that can go wrong do go wrong at the exact same time. It’s as if the 1s and 0s are self-aware, secretly plotting to inflict optimal damage on us primitive biological life-forms.

When you have this perfect storm of events, it’s easy to start pointing fingers. The client blames the firm. The developers get mad at the testers. The testers blame the developers. Both blame outdated IT infrastructure and obsolete development and testing management tools. Management blames everyone.

The situation can become pretty toxic.

I wouldn’t even pretend to know who is right and who is wrong – every case is so different. I’m willing to state that the responsibility and blame are usually shared. I’ll even go as far as saying that they are shared equally 90% of the time.

So how do we learn from these mistakes?

If you’ve been following this blog, you probably already know that I put a lot of stock in SaaS software testing tools in general, and Testuff’s suite in particular.

We’ve documented time and time again how choosing the right software testing management tools can reduce costs, increase productivity, and help you create better, faster, and cheaper products.

But I’ll be the first to admit that having better tools won’t necessarily solve the problems outlined above. Yes, having a SaaS software testing platform protects you from system crashes. And yes, you can more easily share results and compare scripts with the development team since you both have access to the same tests at the same time. So in a way, having great tools can help you meet your targets.

However, there’s no piece of technology that can completely remove management pressure. And no gadget can prevent a client from changing his mind the next day.

So no, I don’t think superior solutions, software testing management tools included, are the end-all be-all. They can help – a lot. And you should make sure you have the best platforms your budget can support. But sometimes you need something more.

What do I recommend?

  1. Involve all stakeholders from the very beginning. I realize that some firms like to add in buffers between the client and development team, but it really reduces redundancy and confusion when you have everyone on the same page on Day 1 (see my earlier post about this).
  2. Build better lines of communication. Abandon the traditional concept of having all the different departments in, well, different departments. When there’s confusion about a particular fix, think about how much easier it becomes if you can simply walk over to the developer at the next table and recreate the error on his or her screen. By removing the “us vs. them” mentality, you create a more constructive and cooperative working environment. This has immediate benefits to you, but it also helps the company and client as well.
  3. Place all mission critical staff on equal footing. If you can’t get a product out the door without a certain department’s help, that department is important. By definition. Make sure that all of the relevant actors in that department have the resources they need to get the job done.
  4. Training, training, and more training. I won’t bore you with the details here (since we’ve covered this topic a lot), but continued education will help everyone in the company. If you play your cards right, you may be able to get your boss to foot the bill for extra classes.

These are strategies we’ve employed at Testuff, but they’re by no means exhaustive. Think of it as a starter list.

The real goal of this post is to invite comments down below. Share your horror stories. Laugh a little bit. And tell us about any successful or unsuccessful ideas you’ve implemented to make your testing environment more streamlined and productive.

0 0 vote
Article Rating