The Test Automation Mindset
I recently wrote an article for Better Software magazine about building a test automation strategy. The overriding themes in this strategy are involving all members of the technical team, layering tests throughout the technology stack, and using this approach to design better software and catch simple problems earlier in the development cycle.
In my experience, this strategy works to make software with fewer issues. But doing it requires a shift in mindset. Automation is a technical problem, and most technical problems are solvable. Mindset is a people problem, and that is much more difficult. How can we make that mindset change happen?
My basic philosophy around software is that if you want it to work, you need to test it. Let’s go deeper than that, though.
Software development efforts are often series of loops. We learn what we need to make, build something, learn more, and then make course corrections to build something that is more in line with what the customer wants. There are more loops between technical staff and the build, test, fix, and retest cycles.
Many of my projects have flowed like this: Developers write some code—and build some unit tests, if I’m lucky—but we don’t talk about them, and then eventually I get a build to test. That build usually has a slew of easy-to-find problems: array overflows from text fields, date fields that will throw JavaScript errors in the browser with bad data, and forms that just plain don’t work. I sift through the problems, document what I find, and wait for a new build.
Driving development through testing speeds this up.
I don’t always start with a test, but it is nice when possible. I might write a new test to verify that a save method is called when I click the Save button. After that, we implement the save method. But what about the things that are being saved, you ask? We can test those, too—data permutations, HTTP response, and keys and values in the JSON body. Instead of waiting for a big batch of new code to build, we build constantly.
The bugs that remain do not involve fiddling with data and watching the browser crash. Usually these will be more complex problems that require skilled and deeper testing—testing that you actually have time to perform now.
The question of whether or not you want to build tests is also a question of how many times you want to work on a piece of code. If you are okay with slow feedback and being forced to revisit a code base several times for rework, maybe automation isn’t necessary. If you want to build something and have it be in shippable condition by the time you commit your code and get a green build, then you probably want to drive development with tests.
Creating a mindset shift in testing throughout the entire development organization requires internalizing that idea. Something that feels slow right now will actually be faster and create more sustainability for your development team in the long term.
