{"id":649,"date":"2013-06-05T22:06:40","date_gmt":"2013-06-06T05:06:40","guid":{"rendered":"http:\/\/angryweasel.com\/blog\/?p=649"},"modified":"2013-06-06T07:26:51","modified_gmt":"2013-06-06T14:26:51","slug":"coding-testing-and-the-a-word","status":"publish","type":"post","link":"https:\/\/angryweasel.com\/blog\/coding-testing-and-the-a-word\/","title":{"rendered":"Coding, Testing, and the “A” Word"},"content":{"rendered":"

I frequently go days at work without writing code. On many days, I do \u201ctypical\u201d test activities (seeing what works, what doesn\u2019t work, etc.) Some days I\u2019m debugging all day. Other days, I\u2019m sifting through the perl and batch scripts that bolt our build process together. On other days, I\u2019m managing projects, tweaking excel, or trying not to cause too many problems in SQL. This afternoon, at least after lunch, was coding time \u2013 and probably the first extended code time I\u2019ve had in a few weeks.<\/p>\n

Without too many boring details, I had a backlog item to write a service to automatically launch a memory analysis tool and periodically take snapshots of memory allocations in specified processes. The memory analysis tools (which I also wrote<\/s> adapted from another project) work really well, but need a lot of manual intervention in order to get accurate data. I wrote a quick \u201cspec\u201d on my whiteboard, wrote tests as I went along, and in about four hours I had it up and running successfully. I\u2019m confident that the service will make it much easier for our team to find and isolate memory issues. To me, writing this tool was a testing activity<\/i>. It doesn\u2019t test anything, but certainly makes testing of the product much easier.<\/p>\n

On my drive home, I was pondering the universe (and my day) and remembered that there\u2019s a sad bit of truth in the software world. It\u2019s a fallacy that causes great confusion. It promotes poor strategies, bad hiring decisions, and endless confusion among management, contributors, and consultants. It may very well be the most misunderstood word in the world of software. It\u2019s the \u201cA\u201d word that is practically ruining testing.<\/p>\n

Automation.<\/p>\n

Yes \u2013 as much as I hate them, I used a one word paragraph. I did it because the abuse and misuse of \u201cautomation\u201d in testing is causing too many smart people to do too many dumb things. That said, I suppose an explanation is in order.<\/p>\n

Once upon a time, someone noticed that testers who knew how to code (or coders who knew how to test) were doing some wicked-cool testing. They had tools and stress tests and monitoring and analysis and they found great bugs that nobody else could find \u2013 \u201cTest Developers\u201d were all the rage\u2026so we (the industry) hired more of them. Not much later (and possibly simultaneously), someone else decided that testers who could code could automate<\/i> all of the tasks that the silly testers who didn\u2019t code used<\/i> to do. Instead of finding really cool bugs, coding testers were now automating<\/i> a bunch of steps previously done manually. Not to be left out, UI automation frameworks began to sprout, with a promise that \u201canyone can automate \u2013 even a tester<\/i>.\u201d Now, test teams can spend the bulk of their time maintaining and debugging tests that never should have been automated in the first place.<\/i><\/p>\n

And that was the first step into darkness.<\/p>\n

This mindset, although common, kills me: <\/p>\n