Losing is not how you lose. The way you lose is by winning so easily that you don’t learn things. In order to win, you have to lose a lot. Perhaps you have to lose the most.
– Northernlion
One thing that video games ever rarely capture is acknowledging when the player has won. Sure there are win states and lose states, but those ever rarely map to a players own definition of winning and losing. This spans beyond the scope of video games and into sports and any other form of competition as well.
That’s because win-conditions are easily created and agreed upon through quantitative measures (kick the most goals, finish the fastest etc.), but a qualitative account of winning and losing is highly subjective and varies depending on the day and probably the mood someone is in at the time. Sometimes, all it takes to “win” in any activity is to have a good time and unwind, other times it might be to deepen your understanding of the activity you are doing and your relation to it. Sometimes its about aiming for something so unachievable that all you can really do if fail. But you learn from that failure and in doing so, get a little closer to truly winning. I get a lot of that in testing.
I think the path forward in stepping into the testing industry is to face failure with a positive mindset. Testers seek out failure, we are also challenged by failure. We need to learn from failure. But the only way we fail, the only way we win, is by being inquisitive and daring to shoot our thoughts out into public space and watch to see how they either sink or swim.
The one certainty we testers are afforded is that we will always receive an answer at some point to the question “Did we catch all the bugs that mattered?” Someone is going to spot that bug. Log that ticket. And that is going to be an opportunity to learn from and understand if the bug(s) that were missed belong to a larger family of bugs that had not been accounted for. An opportunity to assess where our weaknesses lie and how we might evolve them into strengths.
Testers truly fail when:
- Confronted with overwhelming complexity they shy away and say its too hard
- Important bugs evade them and rather than adapting their approach, choose to ignore those bugs
- They unquestioningly take the path of least resistance
- They fail to define their craft for themselves
Insanity is doing the exact… same fucking thing… over and over again expecting… shit to change…
– Vaas, Far Cry 3
If there is one thing we can say about Vaas, he was definitely insane. After 3 attempts of trying to kill Jason in different wacky styles, not once did he confirm Jason’s death. Never checked his pulse or anything else like that. He failed his own definition really, which is kind of ironic. I think the definition of insanity is a little more nuanced than this, but one important principle it does highlight is the importance of variability. You aren’t going to learn a great deal of anything if you never vary your approach. Certainly, environmental variables might play a factor in providing a different outcome, but I have typically found approaching a problem from different angles elucidates a solution much faster.
The key is being comfortable with failure and understanding the likelihood of it. Learning to fail gracefully and recognizing when you have failed. When you are well acquainted with failure, you start to win more. Keeping this in mind helps me interface with some of the testing heavyweights I have come to respect and helps build up enough confidence to challenge them on their assertions and ideas. More often than not, I’ll fail, but I’ll learn a helluva lot in the process.
greyheuristic.com 