Thursday, July 25, 2019

Telling what testers do in simple terms

As I was browsing facebook, I read a comment from a friend on testing stating there are three things all testers need to learn: automating, exploring and telling what we're doing in simple terms.

I find that automating and exploring are activities within the exploration when you know how to write code and can make thoughtful decisions on documenting with code or using throwaway code to extend your reach. Yet both these two things are so wide and varied that you can spend a lifetime learning how to get really good in them, and listing microskills within them would probably be more helpful. I know both of the two already, but I don't know all of them. How could I better show what I do and don't know?

The really fascinating part though was the third key thing my friend called for: telling what we're doing as testers. Explaining our worth. Explaining what we've done, what we'll do and why it takes more than 10 minutes. People's ideas of how testing happens are often so shallow that testing != testing.

Talking about what is going on in testing isn't simple and straightforward. And talking about status isn't a skill we all have equally developed.

I was explaining this on a ride today. If you imagine testing is like painting wall, you can expect that the work depends on the circumstances of doing the work. A breaking brush will make your progress slower, and you may not know all things that happen as you are just getting started. There can be nooks that require more effort. You could stop at any time, leaving an artistic impression. You could approach the painting in many ways. But if you leave a corner undone, it would at least be good if you can tell the others a heads up, rather sooner than later that you'll be running out of time and don't see yourself getting there. If you notice a part of the surface being harder to work on, make others aware of the surprises and allow them to pitch in and help with some of the parts.

Describing something invisible is much harder. Yet we see the same troubles over and over again on talking about what we're doing. We need to be getting better at explaining what we're doing in simple terms. And at minimum, we need to stop assuming people don't want to hear anything but a binary done vs. not done. 

1 comment:

  1. Couldn't agree more on actually telling what we do in simple terms. I came upon some pretty good examples of needing to do so with my 15 year old daughter's friends. There is too much time spent on philosophical phrases and repeating things in terms only those who actually work in software development would even understand - and often these terms are used incorrectly by testers to begin with. I have started to explain what I do in simple terms, I have written it out and even posted an article on linkedin over it. We can only add value to our teams and organizations if they understand what we do. And, equally important, we can only pass the testing baton on if we can get the next generation to even consider the job. Perhaps by doing this the next generation will purposefully go into this field instead of falling into it as many have.