Friday, April 11, 2014

Tester could help not waste developer and user time


I find it funny that I get upset for calling developers bad testers, but reading James Whittaker's latest post http://blogs.msdn.com/b/jw_on_tech/archive/2014/04/11/stop-testing-like-its-1999.aspx just feels so out of context for me that I don't even care.

But it does prompt me to write a post, that I was thinking of before reading it, on something I learned at work today.

I had been invited today to meet up with a team of business users that use a particular area of the product we're building. My invite there was the first with that particular group, and the meeting was long due, postponed for various reasons.

The meeting opened up with the business users apologizing for their lack of time for us - for the meeting, for using the product, for providing feedback if they ever found time to use it. They were swamped with other work, and this product while useful, wouldn't be their only way of getting the job done.

We discussed the needs for upcoming development work, and I asked many questions to understand their needs better. Others from the development team seemed focused on listing features, negotiating their order and coming up with a design the business users appear to accept. Digging to their actual needs, we completely changed the ideas for that area. As the discussion happened late for one part, reimplementation would happen. But on two other parts, we feel more comfortable on the likelihood of making the feature helpful for its purpose.

Then we talked about getting the product into use to get feedback. As I briefly summarized what we had covered on our testing in the team, I heard the sighs of relief that the interruptions to their already busy schedules might be less than their used to - without a tester around.

It could be that our developers are not quite as updated as ones James Whittaker seems to talk about. At least our users are smaller in numbers, and very much bothered when they get to be used as testers, regardless of the ease of reproducing and pace of fixing. Bugs make them use time on something and that time would be of more value used elsewhere. Context matters.

The testers of today might have different set of skills - even without coding - than the testers of 1999. I find myself to be a catalyst that help us start some of the difficult conversations that we finish together with a better understanding. And have noticed many others identifying themselves as testers to bring in a similar approach. Back in 1999, I would not have expected all testers to be active explorers. Nowadays, the button clicking robots who fall asleep arriving to work still exist somewhere, but deserve to go extinct. James Whittaker did not seem to talk of that crowd, though. But I get the feeling he thinks of the types that insist on all bugs being equal and not learning what information is valuable. Perhaps that's why I felt disconnected reading the post - there's another species of testers I don't even relate to?




No comments:

Post a Comment