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.
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.
