A couple of weeks ago I went sailing with my family. We were all happy to meet and get a chance to sail together on a beautiful sunny day. Things changed however after an hour or so…. With slow winds and a wavy sea, there were soon some people who were feeling sea sick. Actually, the only one feeling fine, other than myself, was the one still recovering from a dislocated shoulder, and so I found myself with a not-so-functional crew and more than that, a not-so-happy crew.
Quick decision and we were back to the marine, enjoying a relaxed time with food and drinks, on shore. Everyone feeling good and happy again, everyone together – which was the purpose to start with.

In previous “Sailing with testers” posts, we’ve discussed what to check before it happens, how to handle the events when it happens, and what should (and can) be done to be ready for any scenario. Now let’s see how can we get our testing team to be ready, and also be… happy.

Be attentive to your testing team

The same situation happens sometimes in a testing project. You, as the skipper (oops, the manager), plan the testing, the schedules and you set the goals. But while your team is working and testing accordingly, things change. Some of the testers might be unhappy with the project – for various reasons, others might be affected by them, resulting a team not functioning at its best.
Here’s where you need to be attentive. Not force the issue, but check how you can perhaps meet your goals, and on time, just with a new approach. Check why are there testers that aren’t happy:

  • Is it personal?
  • Maybe they were not introduced to the project properly and therefore have no commitment to it?
  • Perhaps the work load isn’t clever enough, leaving some with too much (and not happy) and other too bored (and not happy also)?

There can be many reasons, but it is up to you to notice it, find the reasons and make the decisions on how to resolve it. No point in keep sailing, and in the same direction, when things go wrong. It is you responsibility as the manager, to make sure testers are feeling right, are happy with their work. At the end of the day, it works best for the project, which is the main goal of course.

Shuffle and reshuffle

Remember that crew guy, recovering from a dislocated shoulder? Well, he was always the expert for the sails (main and jib) on the yacht, knowing how to raise and lower them, how and when to adjust them to the wind. I hardly had to give him instructions when sailing together. But without him, I found myself in trouble. Now I need to take care of the sails, among all other duties, and work with someone who has never done it before. Doable, but takes much more time, and needs much more attention.
The same can happen within your testing team. Take that tester, who is your security testing expert. He know exactly how to test, what to test, and can get it done on time. He knows the people from the IT group, and can get them to help with for anything he needs to do his job. That’s an asset.

But what if he is out?
And time for security testing has come?

This is why you need to make sure you have a few testers familiar with each of the testing areas. They don’t necessarily need to become experts, but it would be great if they practice it from time to time.

If your expert is around at that time, they’ll be able to quickly get help and training, learn from him. Then, when he’s gone, they at least have the basics to start with.
So shuffle and reshuffle your testers between different aspects of your testing projects, and make sure you have no dependencies on any one expert.

Otherwise, you’ll find yourself sailing without your main sail…