Melissa is starting out her talk by talking about balance and the idea that a pendulum ultimately seeks balance. Radical swings will be met with radical swings in the opposite direction but over time momentum and movement will cause the pendulum to slowly reach a balanced momentum (and under the right conditions, keep moving in that direction).
Testers often find themselves being that pendulum. We are always having to move and adapt and learn and those movements can teach us a lot, give us our fair share of frustrations, and also help us grow and learn how to be effective. That's great but effective for what? What is our purpose as a tester? Why are we ultimately really here? We can do a number of things and our role can change dramatically. As we sometimes can get overloaded with tools and tooling and less on an actual testing and user advocacy focus, the goal is to keep in mind how to "get that balance right"
There's a lot of us who shift our focus from being testers, being automation developers, being build managers, being customer support specialists, being system administrators, being accessibility advocates, being security analysts, focusing on Localization or Internationalization, etc. Often times we are a jack of all trades by necessity. We don't often really get to be an expert in any of those areas. I often laugh at the fact that my formal role is as a Senior Automation Engineer when easily a majority of my time is doing anything and anything not specifically focused on automation. This can both be good (as in I have the ability to do a lot of things and I can be effective in a lot of areas) and bad (I never really got a good head of steam to get something working in a truly effective manner).
What happens when you are that "lone tester" on a team. How can you strike a balance? I have become interested in Alan Page and Brent Jensen's "Modern Testing" principles that they discuss frequently on the A/B Testing podcast. In many ways, the biggest enemy of my striking a balance isn't the demands on my time, it's how I specifically respond to them. Why am I doing the testing and detailed test cases? Because I'm the tester. Am I the only one able to test? Of course not. Then why am I not encouraging others to test and get involved in the testing process? Probably because I'm standing in the way.
It's also a little bit myopic to think that I am the only one doing testing. What unit tests are in place? Why are they there? What do they do? More to the point, what do they *not* do? Is it possible that we are duplicating effort and not even aware of it? Have we done a basic risk assessment to see if we are actually hitting areas that matter the most? do we even know what areas actually matter to our customers? We can learn a lot from interacting with developers and seeing what they have put in place. I remember a little over a decade when I was reading James Whittaker's book "How to Break Software" and I read and considered his first recommendation: "Look at the code and find any error handling message that has been created. Figure out how to surface every one of those messages at least once". I attempted this and I found a tremendous number of issues. Why? because the error handling had issues in and of itself. Had I not tried this approach, I may never have uncovered these issues.
Ultimately, it comes down to realizing that we are often the ones most guilty of that wild pendulum swing. There are more efficient ways to do things. There are more effective uses of our time. We have the ability to change the narrative. Perhaps the first step is to stop being our own worst enemy ;).
No comments:
Post a Comment