Sunday, October 29, 2017

Yes, I am a manual tester and ...

In my team, we have two testers and our interests and contributions couldn't be more more different. While I like to refer to myself as an exploratory tester, most people around me think of me as a manual tester. I try very hard not to correct their terminology, but I often use the improv Yes and... rule to add to what others say.

Yes, I'm a manual tester and I create disposable automation.
Yes, I'm a manual tester and we just addressed some major issues that would have been next to impossible to spot without thinking hard around the product.
Yes, I'm a manual tester and while my hands are on the keyboard, the software as my external imagination speaks to me.

The practice of avoiding correcting people's established terminology is not "help to cheapen and demean the craft"(1). That practice is focusing on what matters, and what matters is us collaborating, creating awesome stuff.

I might not have always liked the terms manual and automated testing, but I can live with with established vocabulary. Instead of changing the vocabulary, I prefer changing people's perceptions. And the people who matter are not random people on twitter, but the ones I work with, create with, every office day.

Looking at the two testers in my team, I can very easily see why I'm the "manual tester" - I think best with hands on keyboard, using the product as my external imagination. I prefer to bias myself to experiencing much of the testing as the users would - using the product. Even when I test with code, I prefer to bias myself on using the APIs as users would. The mechanism of running the test - manual - leaves me time and focus to think well with the product giving me hints on where to go next.

Similarly, I can easily see why the other test is automated tester. Their focus is on getting a program, unattended to run the tests. They too think hard (often with less of an external imagination due to focusing on coding around a problem) while creating the script to run, and are all the time, with each test, forced to focus on the details. So their tool and approach of choice biases them to experience the product as a program can. The mechanism of running the test - automated, eventually - leaves them time to do more automated tests. Or rather, try to figure out why the ones created are failing, again.

Together, we're awesome. If we were more inclined to move between the roles of manual and automated tester, we'd be more awesome individually. But as it stands now, we have plenty of bugs to find that automation couldn't find: they are about aiming for the wrong scope. The person doing automation could find them, if all their energy wasn't going into the details of how hard automating a Windows GUI application can be. So right now we're lucky to have two people, with different focuses.

I wrote this inspired by this - Reference (1):

So here. I just cheapened and demeaned the craft. Except I didn't. The word policing is getting old. The next generation of manual testers can just show how awesome we are, giving up the chains of test cases and thinking well with our hands on they keyboard and our brains activated.

Imagine what would work be like if we stopped policing the word choices and approached communication with a yes and -attitude.

6 comments:

  1. The inverse of word policing, the rejection of word policing, is also word policing. Insisting on using or changing one term over/for another for its own sake is the same from either side, it's just demanding preference. Instead of fighting over word policing maybe we should look at the intent of both sides of the argument. I'd assume that Michael's intent is pure enough - to encourage testers to feel empowered by their possibilities and reduce confusion and to change perceptions. Your intent is, I also assume, pure enough - to reduce wasteful conflict, meet testers' needs of identity, and to change perceptions. Maybe if we stopped policing the word policing and approached the intent of both sides with a positive assumption we could hand to testers both the power of understanding why terminology matters, then let them choose their own words to define themselves. After all, if the name doesn't matter, and it's what the name change means that matters, then I don't see the harm in educating about perception from both directions and letting the testers find their own identity.

    ReplyDelete
    Replies
    1. I speak of what I do in my company. You make your own choices of how you behave. I write of my experiences. The most judgmental thing I think I'm saying in this article is that it is pompous to claim that using a term is demeaning the craft.

      You educate all you like. But when you educate me, I choose to listen to others with my limited ability to listen to people.

      Delete
  2. Good post. The latest craze of test automation is not so much adding to the test domain, but trying to eliminate a role on a team. It wont work, but we have a ways to go before most employers realize that reality. I am not saying some automation is not usefull, especially unit tests, but I think excessive UI automation costs much more than they provide benefits.

    ReplyDelete
  3. I would prefer a "yes, but..." response.
    Yes, but manual testing is the only form of testing. Testing is a manual process which cannot be automated. If you're testing, you're a tester. If you're writing scripts or tools you're a developer.

    ReplyDelete
    Replies
    1. Using but language you can bring the other person down, while and language builds on (and accepts) what the other said.

      Delete