Monday, July 28, 2014

Experience on how to turn testing into not fun

I'm back from vacation, with new energy and the old love for my profession in testing. Testing is great, it's fun, it's challenging. Except when it isn't.

I started off with (re)testing a small feature I had noted that didn't work in so many ways just before my vacation. Instead of us getting the feature finished and a feeling of mutual success on making a delivery, I was told that it would be fixed while I was gone. Well, some of it was fixed, but in general it still doesn't work. The users could not do valuable work with it. It doesn't work in real scenarios.

I talk with the developer to hear that the stuff I had reported before are "special cases" - relevant to the user, but all requiring logic he just hasn't yet implemented as he thought it would be special. I mention the new problems and they are deemed "weird behaviors" - we do agree. I'm concerned of the severity of the issues for the end user, blocking the delivery of added value. The developer seems to be concerned with the technical challenge of it, how could the code do things like that. I just know it does, from experience.

I ask if the developer tested the feature himself, if he actually uses it and he tells me he does. The blatant difference in our experience calls out for pairing to test it, to share the experience. With the new energy, I'm about to suggest that.

But, just before I suggest pairing (which isn't a normal way for us to work, sadly) the developer points out that he has started working on another task that will take him days to weeks and that he will not look into the "weird behaviors" before he's done with the other work. I remember again what really frustrates me - unfinished features waiting in inventory. Features that don't improve while they wait, features that get more broken when they are "fixed" after weeks of wait time. And the repeated experience of testing something that doesn't work for me, but presumably always works for the developer.

Waiting sucks. Finding easy bugs sucks. Not collaborating sucks. This isn't testing, this is starting testing again and again being blocked right in the beginning. Testing would be great. I hope I get to do more of that soon.


  1. That sounds awful! I hope everything gets kicked in to shape soon!

  2. Perhaps you might investigate the opinions of others while you are waiting? Are the special cases or weird behaviors something that your business customer might have an alternative view - perhaps one of value? Might people who support your products have an alternative view to these cases or behaviors?

    My point is the developer is one person on a team with an opinion. There are others who might see value in having these cases and behaviors reviewed for business value rather than just coding challenges.

    1. I have investigated other opinions before I started waiting, it's a continuous process. Getting answers from non-developers just happens to be a lot easier thing for me that getting the developers to understand that their choices have a (negative) impact on the stuff we should try to accomplish together.

      I find that externalizing responsibility of thinking about the system away from the developers causes bugs. If the developer doesn't understand what he's about to develop, how could I think that he ends up developing the right thing?