A common theme of what many testers (me included) want to talk about is the negative impacts of automation. I'm at a point where I've definitely come to terms with the idea that automation is a good thing. I've grown to see that my old fight against it was a reason for failing and work hard, most of the time, to work against my natural instinct giving test automation time and focus it needs to become great. Time to fight is time away from improving. And I know that I can help improve it, significantly.
One of the ways this revelations of mine shows is that within the organizer group of European Testing Conference, we have decided not to accept anti-automation talks. We all know it has limits and negatives. But we want our focus to be on finding ways around the problems, practical solutions, insights and ways forward.
One of the calls with four proposals included a talk that I felt belonged in the category we wouldn't feel like giving stage to, yet the even short discussion with Jan-Jaap Cannegieter was inspiring. He introduced me to a book by Nicholas Carr called Glass Cage and it's core message of how automation is making us more stupid, forgetting how to do the things without automation.
I work with a team highly divided on our focus on automation. And a regular discussion with the person focused on testing through automation is on *how are we testing this*. The discussion as such is not the interesting part, but the pattern of how that discussion goes. The reliance on code to see what it does, the inability to talk on level of concepts or even remember what has been covered on high level without looking at the code is evident. The same question asked on ones with exploration approach starts with areas, features and only last details that could or could not be documented.
It would seem tempting to say that automation is making us stupid. It would feel tempting to say it reduces our ability to see our testing, and to explain our testing conceptually, while adding to ability to cover our asses showing the exact detail of what is covered that I personally find the least relevant.
Jan-Jaap made a point of us forgetting with the extensive focus on automation how to talk about coverage and test techniques. Yet, I just few days ago had a fascinating and insightful discussion on someone else submitting on Test-Driven Development, giving insightful examples of how TDD has made them test with several positive tests and cover more ground of the actual solution domain.
So have we forgotten what it is to test? Where do the new generation of automation first testers learn that? Clearly many of them haven't, and get very easily fooled by opportunity cost of doing the best thing possible only in the automation context optimizing for long-term.
Then again, looking at the 120 submitters and 200 topics proposed for European Testing Conference. Not a single one on a practical use of a test technique to analyze a problem for coverage. Not a single one teaching how you test. We found some hidden in the talks of process and company experience, but not on the active submissions.
Perhaps the problem isn't automation. Perhaps it's the way we talk of testing - as in not talk of it. With a few notable differences.
Share more of how you test. That is valuable and interesting. It's not automation that makes us worse at testing, it'd our choice of letting the automation (and the programming problem of it) to take all focus and stopping our talk around the domain: how do we test.
My hope with automation is on the programmers who no longer need to use their learning power on the details of scripting, solving (through learning) the higher level problems of domain. But every day, I feel less inclined to believe in the tester-turned-automators. They need to amp up learning in a balanced way to restore my faith.
