For quite a bit of time now, I've no longer considered myself anti-automation. But I've still been pro-exploratory testing, very heavily. I've believed, and had evidence in my project to support it, that the exploratory testing mindset is what my programmer heavy team has been missing.
I don't find same problems over an over again. I don't test in the same ways. I take each change as a unique thing. I encourage creating test automation, but leave the hands-on work on that for my programmers. There is many of them, and just one of me.
With this approach, we've succeeded well. We've learned to release daily. We work well together. Much of my knowledge of exploratory testing has rubbed on the programmers, and they test better than before.
Recently, I've made a decision to move on from my current organization and today I believe I'm only days away from completing that decision into an action. My organization has been aware of my intentions, as the two years I promised them has turned into 4,5 wonderful years with an amazing team and product.
Simultaneously, the programmer side is going through a major change. Out of my 7 programmer colleagues, 1 moved to another business area "temporarily" half a year ago. The temporary became permanent, and 3 more people will move. And as a result of this making all of us consider our choices, 1 more programmer made a personal decision to try working with another company. So my programmer colleagues are down from 7 to 2. Quite a change.
Now the low level of test automation is becoming painful. Programmer know-how is lower and mistakes when moving to new areas and introducing new people are more likely.
Seeing a deadline to my availability makes me rethink my test strategic choices in hindsight. With the choices I made on emphasizing the exploratory and distributing that skill, I did not prepare the product well for the future now at hand. The documentation I've created will be helpful for a new tester joining in. But while I'm gone, the ability to release with the level of quality we've grown accustomed to will go down.
If I made a strategic choice of encoding as much of my knowledge into test automation, would the product have better chances of future? Would that have changed the success of the past? I can't really know.
One thing I know: I want to focus in my next job more into the idea of the product doing great without me. And that is going to mean a clear focus in figuring out how do I better balance exploratory testing and creating test automation together. It's about balancing short-term and long-term benefits. It's about balancing what I love doing and what I feel needs to be done.
I'm still proud of being a good tester as in delivering good information. I'm just admitting that right now I will be better when I start codifying more of that wisdom into test automation.
I'm delighted to realize that the last month is still my opportunity to codify one of the most complicated areas in our product, printouts. My focus is now on ensuring the product has the best chances to continue being amazing without my contribution and automation plays a big role in that.
For any of you non-programming testers out there: I was one of you just a few years ago. Mob programming and strong-style pairing made me comfortable working with code even through I was saying I'm not interested. My exploratory testing skills still make me special. Putting that together with automation makes me better. Choices in the order in which you learn are arbitrary. Learning anything takes time and focus. Starting somewhere enables you to look through your choices in hindsight, and take note on things you want to change for future.
I don't find same problems over an over again. I don't test in the same ways. I take each change as a unique thing. I encourage creating test automation, but leave the hands-on work on that for my programmers. There is many of them, and just one of me.
With this approach, we've succeeded well. We've learned to release daily. We work well together. Much of my knowledge of exploratory testing has rubbed on the programmers, and they test better than before.
Recently, I've made a decision to move on from my current organization and today I believe I'm only days away from completing that decision into an action. My organization has been aware of my intentions, as the two years I promised them has turned into 4,5 wonderful years with an amazing team and product.
Simultaneously, the programmer side is going through a major change. Out of my 7 programmer colleagues, 1 moved to another business area "temporarily" half a year ago. The temporary became permanent, and 3 more people will move. And as a result of this making all of us consider our choices, 1 more programmer made a personal decision to try working with another company. So my programmer colleagues are down from 7 to 2. Quite a change.
Now the low level of test automation is becoming painful. Programmer know-how is lower and mistakes when moving to new areas and introducing new people are more likely.
Seeing a deadline to my availability makes me rethink my test strategic choices in hindsight. With the choices I made on emphasizing the exploratory and distributing that skill, I did not prepare the product well for the future now at hand. The documentation I've created will be helpful for a new tester joining in. But while I'm gone, the ability to release with the level of quality we've grown accustomed to will go down.
If I made a strategic choice of encoding as much of my knowledge into test automation, would the product have better chances of future? Would that have changed the success of the past? I can't really know.
One thing I know: I want to focus in my next job more into the idea of the product doing great without me. And that is going to mean a clear focus in figuring out how do I better balance exploratory testing and creating test automation together. It's about balancing short-term and long-term benefits. It's about balancing what I love doing and what I feel needs to be done.
I'm still proud of being a good tester as in delivering good information. I'm just admitting that right now I will be better when I start codifying more of that wisdom into test automation.
I'm delighted to realize that the last month is still my opportunity to codify one of the most complicated areas in our product, printouts. My focus is now on ensuring the product has the best chances to continue being amazing without my contribution and automation plays a big role in that.
For any of you non-programming testers out there: I was one of you just a few years ago. Mob programming and strong-style pairing made me comfortable working with code even through I was saying I'm not interested. My exploratory testing skills still make me special. Putting that together with automation makes me better. Choices in the order in which you learn are arbitrary. Learning anything takes time and focus. Starting somewhere enables you to look through your choices in hindsight, and take note on things you want to change for future.
