I am passively recruiting, meaning I look for the people that think of testing differently. This creates an interesting frame for the conversations I have.
The first point of entry is the willingness to explore a mutual future together, and I don't do that by reading your CV. I do that by having a conversation. In that conversation, I am not testing for the right answers, I am searching for boundaries of identity, potential and true willingness for a mutual journey.
Many people with 20 years of testing experience come out of that 30 minutes smiling, curious, but also with breaking what they thought they knew about testing. You need to break things to build them up in a different structure.
What I start with is asking people what they see in their future with testing role, grounded to what they have learned in the past. Not reiterating what their CV would say, but talking about what would be a mutually happy and valuable route forward in their mind.
I often hear things like this:
- modernization to automation
- technical automation architecture leadership
- transformations, delivery management
- good practices and processes
Essentially, these are about power over telling people what to do. I tend to call them out as abstract, and push the next stage to testing of a tiny application. After all, if you plan on telling others how, having good ideas about that how is kind of essential.
I flash our e-primer, now within the Capture the Bugs feedback application. I tell them I want to know what they want to know, and that I want them to test this application. And then we iterate.
The iteration can take us anywhere:
- a lot of people make claims like they see a bug when they don't, and struggle to explain what lead them to a conclusion
- too many people want to try text field with numbers and special characters, without any connection to the domain
- a lot of people don't know how to learn a domain when they don't yet know what they don't know
- sometimes we discuss the risk of long text, the boundaries and the architecture's impact to relevance of information you could find if you go big
There are things that I always bring in:
- test automation that enables us to test things we couldn't easily by hand if only we had better ideas
- using AI not to generate test cases but to generate the bug lists - the result we are trying to achieve here
For people with traditional testing experiences and idea of exploratory testing as random clicking, the level of intent, learning and sensemaking I require feels surprising. They see that indeed the thing I ask as testing is nothing like the testing they have 20 years of experience with.
Failing with the exercise is the beginning. The possible journey together builds on what you do with having been shown there is something else, and concluding that what I was asking for was not that unreasonable - especially since AI of today can deliver 32/65 problems known in that application with three prompts: "Test this" (finds 4), "Do better" (finds 29), "I know 65, can't you do better" (finds 32). Elizabeth Hendrickson was half joking when she said yesterday in conversation after her talk that asking AI to explore does not need a separate skill, her book "Explore it" is part of a law suit with illegal use of copyrighted materials as training data. She already taught it with best of what she got.
On realizing the change we need in the field to move to think about testing differently and finally letting go of that test case obsession, another framing I really liked came from a group discussion with Lisa Crispin. The group at large was not happy with the book title "Taking testing - seriously?", and from a light rant lead to a true insight channeled through Lisa:
If we took software development seriously, that would already include quality. Creating that separation isn't helping us learn.
We have a real challenge when AI already today does better than many of our testers. And I am recruiting people who can help me change that, with ideas of what making that change while making it solid business entails.
I found one and she started a month ago. I found one more, and I'm building up the right runway for learning together. And I am looking for more people who I can drop into the frame. They need to have ideas of how things are different in collaborative software development that we take seriously. They need to figure out sociotechnical systems, virtuous and vicious loops, and make impact with feedback.
Every conversation, whether it was a crossing of paths or aligning them is worth the time. Taking up the invite is a prerequisite for some potentially good learning.
