Monday, January 24, 2011

I started a new testing assignment a couple of weeks ago.  It's good to get busy after a couple of months of idleness.

But there are things that concern me.  There is so much documentation to read – this is because the test team has in some ways been brought in last it feels … or at least my bit of the test team.

There is a 150 page test plan to plough through.  For anything that we want to think about tests – we have a business requirements document, a user case, an analysis document and a coding design document.

It's interesting in a way, as coming fresh into this environment I'm feeling that in a way having too much documentation can be as bad as having none-at-all.  And in this project's case is even worse.

Why?  One of the reasons is as testers we've been told business analysts and developers are “too busy” and not to be disturbed except by email questions.  This means we're unable to get any questions answered “in real time”, with usually a 2-day turn around time.

I have concerns when I start to hear the words “too busy”.  They're actually my most hated words on projects when I hear someone talk about being “too busy”.  There's almost an office expectation that when someone goes around saying they're “too busy” that they must be adding incredible value to the company.  I actually think the reverse is true.

If a key link in a project is “too busy” it means there are going to be a lot of people on a project who get sidelined or dead ended.  This isn't good.

It also reeks of self-importance.  I feel in a way that when we're told that developers and business analysts are “too busy”, we're actually being told that testing is really of less importance, weight and priority in the scheme of things on a project.

Of course there's a flip side to this – there are people who try and get work done, but they'd get so much more done if there were less interruptions.  I know I used to work occasional Saturdays and achieve in two hours just phenomenal amounts just due to the lack of distractions.  I've also known team leaders have lunch in their car in the car park as having it at their desk, they never get a break from people.

When you dismiss someone with “I'm too busy”, you're just putting a barrier to them.  Here I think are better ways of managing this,

  • stand ups/daily meetings – call them what you will, but it gives a daily forum, and set time for people to be “approachable”
  • “I'm in the middle of something right now – can we meet at 11?”.  You're getting them to acknowledge that you're busy right now, but there's a time you can catch up later.  You get to finish what you're doing, and they get their issue resolved.  There's compromise of both parts – you're going to have to give up time, they're going to have to just wait a little for a response.
  • “I'm off to a meeting – but James is up to speed, and should be able to help you”.  Hopefully not one person has domain knowledge, it should be spread amongst your team.  Another member of staff should be able assist your co-worker.

The difference between these statements and the “too busy” dismissal is that (a) it communicates that you're in the middle of something but crucially (b) contains a compromise to resolve the issue your co-worker brings to you.

Would be nice to consign the words “too busy” to the medieval period of software development ...