Last few weeks, my twitter feed has seen increasing amount of people recommending a series on Netflix called Queen's Gambit. The series is awesome, highly recommended, and focuses on two things: substance abuse and chess. My inspiration for testing comes from the latter.
Watching the series and doing a bit of research, I learned that queen's gambit is a chess opening: one of the first moves a chess player starting with white can open with. queen's gambit is popular, has attacking prowess, and puts pressure on opponent to defend correctly. It offers a pawn as sacrifice for control of the center of the board, and the sacrifice is made in search of a more advantageous position.
Gambit - a game opening - is a word I was blissfully unaware of until I watched the series last weekend.
You may already guess, my interest in chess is superficial. My interest lies with exploratory testing. With the conference season at it's peak, my twitter timeline also displays anti-automation takes from prominent people in testing. Talking about a dichotomy of exploratory testing and automation is anti-automation. Because really, the only reason these two are sometimes considered separate is (lack of) skill. Skill in testing (for the programmers) and skill in programming (for the non-programmers). Skill limits what openings for the collaborative game of testing in software development you have available.
So I call for a new opening move for exploratory testing: the automationist's gambit. Learn every day about both testing and programming, and treat them as mutually supportive activities embedded in the same, growing individual no matter how many testing years they have under their belt.
You can't automate well without exploring. While you create that code, you will look at what goes on around you and acquire understanding, and report things you consider wrong.
You can't explore well without automating. If you don't have automation to document with, to extend your reach with and then throw away to avoid maintaining it, your reach is limited.
Failing test automation in an invitation to explore. Exploring provides you ideas of what to document in your automation, or where to reach that you could not by hand. Automation serves as a magnifying glass for the details you need to check to know what works and what only appears to work. Automation serves as the web of the spider to call you in to see what it caught this time.
Exploring without programming is common but it is not the only way. So I offer you consideration of learning the automationist's gambit. Test automation makes you a stronger explorer. And this option is available for those who are just starting their careers just as much as it is available for seasoned professionals. Try using the anti-automation energy to learning the skill you are missing and see if useful automation has an increased chance for emerging. It has for me.
Automationist's gambit is like queen's gambit. It's not about becoming an automator. It is about enabling the automator by sacrificing something that is on the way: your need to warn people that automation isn't all encompassing. Trust me, the managers already know and you are not helping them or yourselves presenting as anti-automation person.
Doing is one thing. Doing together is another. I'm all for collaboration skill that enables us in performing the automationist's gambit as a pair that is stronger than an individual could be.
