We had just completed our daily, and a developer in the team had mentioned they would demo the single integration test they had included. Input of values to Kafka, output a stream, and comparing transformation in the black box between the input and output. I felt a little silly confirming my ideas of what was included in the scope thinking everyone else was most likely already absolutely clear on the architecture but I asked anyway. And as soon as I understood, I knew I had a gem of a developer in the team. From that one test (including some helper functions and the entire dockerized environment, I had the perfect starting point for the exploratory testing magic I love. But also, I realized I could so easily just list the things pairing with the dev, and we could fix and address the problems there might be together. Probably, I could also step away and see the developer do well and just admire the work. That's when I realized: I had finally landed a team where I would not get away with the traditional ideas of what testing would look like.
This week I have been interviewing testers and the experience forces me to again ponder what I search for, and how would I know I have found something that has potential. Potential is the ability and willingness to learn, and to learn requires wanting to spend time with a particular focus.
Interviewing reminded me of the forms of bad ideas:
- the developer who does not enjoy testing as the problem domain
- the tester who has not learned to program, think in architectures nor work well with business people (the *established exploratory tester*)
- the test automator who made particular style of programming manual tests to automation scripts their career (the *unresultful automator*)
- the total newbie who wants to escape testing to real work as soon as they can
- Test systems engineer
- Contemporary exploratory testing specialist