I've been thinking about the perception of anti-automation in the context-driven testing. Knowing people who identify as context-driven, it just seems weird we're labeled as anti-automation.
However, there would appear to be two things going on that can generate this kind of perception. 1) Believing automating is not something every tester must do 2) Believing in discuss first intellectual process of deciding.
Believing automating is not something every tester must do
Our systems and applications are insights turned into code. To build a system that solves a problem with code, the code is a must. I don't think anyone is denying that.
If there were people who can really well do all kinds of things in the process of turning insights into code, we'd probably love to fill in our positions with those people. Agile community has been a place for me to meet some of these exceptional individuals, who work well both in the business and technical domain - deep and wide into both.
Most of the individuals, myself included, don't seem to have all the bits together in one package. Especially people who are just getting started in software development, there's many corners from which to start tacking things.
To simplify, I call non-programming testing a corner. I call programming another corner. I call business analysis, UX, performance, security, younameit also corners. Each corner has their deep knowledge with almost a lifetime worth of stuff to look into.
And if the software industry doubles every five years, half of us have less than 5 years of experience. Half of us have just a start of a corner. We need to bring a team together to have a full view into the puzzle.
Even with years behind us, we're different individuals with different interests. The joy of discovery through manual testing can be definitive, and the struggles related to automation might not feel like stuff I need to personally do."Just like you can't make a movie with only actors, you can't make a project with only code contributions." - @fureigh #wsc2016conf— Sarah Mei (@sarahmei) June 17, 2016
I've seen exceptional business testers who never write a line of code or even read code. It's a shame if people who want to do code want to take away the people who care for the system but not the code it consists of. But its also a shame if we don't let testers who want to code do just that.
People who want to be commodity are different story. Unskilled people who can come and go are just not the people I think of here.
Believing in Discuss First intellectual process of deciding
The other thing that I feel I'm seeing feels like a bigger obstacle. A lot of people seem to still be missing a core agile lesson about experimentation with regards to the way we work.
I see too much of someone suggesting automation, and getting tramped on with intellectual arguments showing how it is not worth it and how there are other options to do the same thing. We discuss first, analyze to death. We think we know, when we actually haven't done it.
"It's in the doing of the work we discover the work that needs to be done" -Woody QuillThere's a lot of great working examples. They are not "automate all testing", but some relevant helpful part of it. With all the choices, sometimes we just don't get started. And sometimes to get started, we start a discussion first that will eat away the energy of doing things.
There's no shame in experimenting: trying something, learning it's not helping quite as we thought and learning other ideas that would still take us forward.
Like testing isn't one thing, test automation isn't one thing. And good stuff emerges only if we let it grow. We need to let go of the need of analysis, and learn through discovery.
That would seem to be how my brain works. I think I know more than I do. I need to give things a chance. Time boxing, doing something small is great.
