So what do you know about chameleons? They are those cool little reptiles that have prehensile tails, grippy claws, tongues that can shoot out beyond the length of their entire bodies. Neat but, what? Oh, right, they are often capable of selective camouflage, as in when I say that they are often capable, I mean they are really good at it. It's an evolutionary advantage if you don't want to be eaten ;).
To this end, the goal of a "testing chameleon" is to fit in effectively with the organization and to be effective in the organization. That means it is likely that the tester(s) are going to be the ones who will need to adapt the most and be the most open to change and chaos to be effective and beneficial to an organization.
I've had more experiences being a Lone Tester, often as a practical tactic being embedded in a functional team for an extended period. Also, I have had experience being the Lone Terter period, as in my company had a single tester, and I was it. That's a wild place to be (and I'm using wild as in the uncharted and unnavigated sense, not the "party animal" way ;) ). Often that means I get to put on several hats and sometimes balance several hats on my head at the same time. In addition to being a tester, I have also been tech support, rapid response, administration, ops, customer advocate, and trade show demonstrator. About the only thing I haven't done or been is direct sales, and frankly, I'm okay with that!
One of the most valuable skills a tester can bring to the table is advocacy. As a teacher of the BBST Bug Advocacy course for AST (and actually about to wrap up a session of that class this week), I encourage testers to consider themselves an advocate first and an operator second. We don't test by just working with the software. We can test with our words. We can test with our input and questions. That doesn't mean we insert ourselves into every situation but it does mean that we assert a bit of effort and inquiry as early as possible in the development process. I often go back to a phrase Jon Bach said at a Rose City SPIN meetup session about a decade ago where he said one of the most effective times we have as a tester is in the initial development workshops when stories are first being proposed. Jon encourages people to "provoke the requirements". That sounds bold and brash but really what it means is, "we should be testing as soon as these conversations start". If a requirement is set, we need to know what it means, how it will be accomplished (as much as possible at that point), and how we might be able to effectively perform the testing we need to do). This is the absolute best time to address testability.
Ultimately, testing goes beyond the tester and while we may lead the charge in that regard, our ultimate goal is to make sure that effective testing is done, whether or not we specifically do the testing in question. We may ultimately find ourselves being a resource others use to do effective testing and we can be coaches and cheerleaders rather than hands-on button-pushing. That experience will vary from team to team but it's definitely a possibility. Don't fear it :).
No comments:
Post a Comment