Straight up, no ice….

You know the way sometimes, a post, or even a comment on a post gets you thinking. A recent comment by Phil Kirkham on Georgia Motoc’s blog got my subconscious brain working overtime. So much to the point where I feel compelled to put finger to keyboard and write about it.
I had always been a fan of positive praise before negative feedback. As the bearer of bad news (like many software testers), I though this was an effective way of cushioning the impact of what I wrote or said.

So, when Georgia Motoc wrote  a post on feedback discussing the ‘Praise Sandwich’ I was surprised how negative Phil was on the approach. However his comment and  his link (indirectly to a post by Art Petty ) really got me thinking of how I communicate with developers. It made me realise that the positive feedback I was providing was more for my benefit than for the software developer.

Here is some Art’s original post:

5 Reasons Why the Sandwich Technique is a Truly Bad Practice:

  • It is a crutch that is solely for the benefit of the giver, not the receiver.
  • It obfuscates the real message.
  • It confuses the receiver by watering down the key message.
  • It destroys the value of positive feedback by linking it with the negative. Don’t forget that positive feedback is a powerful tool for reinforcing the right behaviors and the sandwich technique devalues this tool.
  • It is insulting to the receiver and borderline deceitful. “Bob, you did a great job on XYZ, but .” It’s like a pat on the back followed by a sucker punch followed by another pat on the back.

I have a real reason why I have changed my attitude to this:

When I’m on a short term assignment (which is often)  I don’t have time or the need to cultivate deep relationships with software developers. What is important is that the bugs I find are communicated in a clear and concise manner. That’s what I am paid for.

The praise sandwich is not necessary and more importantly it does not provide best value to my client.  This is something I learnt on James Bach’s course and has stuck with me. What ever you do ask yourself, “Is what I’m doing right now adding value for my customer”.

BlogRoll offshore

Observations on Offshoring your Software Testing

Have you noticed that there is something about having people nearby that instills a sense of confidence in the work being performed?  There is something about having a tester in the same country as you that generates security.

So it was with a bit of reluctance that I took on a job that had an offshore element to it.

I was surprised to discover the quality of the work that came back from the offshore team. They found many bugs outside their scope of work. Their testing was thoughtful and thorough.

However, one of the hardest things I found I had to deal with is the lack of visibility on the testing.  I am utterly dependent on the only tangible evidence provided to me through  test scripts and defects in the shared test management system. I don’t get to see the testers in action…

So, despite the knowledge that good testing is being performed, I am still very uneasy when badly written test scripts are created, or if the process is not followed.

I don’t know, perhaps this says more about myself than the testing being performed. After all, I personally have never been a fan of extremely detailed test scripts.  Perhaps the lack of contact and visibility brings out the micro-manager in me, turning me into a process Nazi.

So am I being unfair? Perhaps. It’s made me realise how important it is to be accurate and succinct in your reporting, especially when a client has little visibility on your work.