Saturday, July 2, 2016

The appearance of anti-automation

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.

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 Quill
There'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.

1 comment:

  1. I started working on XP teams back in 2000. My 2nd XP team did TDD, but they did no testing beyond that. When their customers were unhappy with the delivered features, they hired me. One tester for about 30 programmers.

    I already knew the value of guiding development with business-facing tests as well as doing TDD, but the team didn't understand why they should bother automating any tests other than the unit tests. Most teams I knew at that time had the same attitude. As a tester, it was extremely difficult to convince the team to take responsibility for quality and for all testing activities. Part of that responsibility is automating regression tests so that there is time for other necessary testing such as exploratory testing.

    With support from the coach, I got the team to agree that a few programmers would act as testers each iteration. The first iteration, we did manual functional testing - that's all we had time for.

    The second iteration, I passed out the list of the manual tests from the first iteration. I explained that each iteration, this list of manual regression tests would grow longer and longer. They had not previously understood why they should automate these tests, but now they got it - otherwise they'd be spending more and more time doing manual testing each release.

    Nowadays, I find that a lot more programmers who practice TDD understand the value of ATDD/SBE/BDD (business-facing tests guiding development) as well as the value of exploratory testing. So it is much easier to get buy-in from them to automate functional regression tests and other tests that are better automated. But there are still a lot of teams out there who aren't allowed the time to do this kind of automation.

    Some testers have the skills to do automation, but IME, without the whole team taking responsibility for this, the automation won't be robust and valuable long-term. Yes, as a tester I need technical skills to collaborate with other technical team members. I actually like doing automation. But the programmers who write production code are much better at writing test code than I am.

    IMO, a lot of testers fear automation, because they think they'll be forced to do it themselves without having appropriate skills or any time to learn those skills. So when a "thought leader" in the testing world says "automation is bad", they jump onto that bandwagon, safe from needing to think about automating tests. If they end up spending all their time doing regression testing, or if their product suffers from lots of bad regressions getting into production, I feel sorry for them.