443 Blog Two - Test Automation

The semester is about halfway over now, and for my second blog I chose the blog post “Test Automation – The Bitter Truth” by Mr Slavchev. It has a lot of good insight about one of our course topics I find interesting, test automation. The post argues that what teams call “test automation” is usually automated checking, not true testing. The author explains that automated scripts only execute predefined checks, lack human judgment, and bring their own maintenance costs and bugs. The post stresses that automation is a tool that supports testers, not a replacement for critical, exploratory human testing. Importantly, he also makes an important clarification, automated testing isn't entirely automated. In reality, it is more like tool assisted testing. Quoting the blog post directly, Slachev says "we use tools to assist our testing, that’s it, we don’t want to replace it, or get rid of it".

As someone new to software testing, yet working with it for my capstone project, I selected this piece because it presents a few practical caveats that I will need to consider, in that test suites need maintenance, tests can be buggy, and automation changes the nature of testing work rather than removing it. We have yet to get to testing automation in our course, and while I have been looking into it personally for my capstone I mentioned earlier, this is the first blog post I have found that serves as a sort of "reality check", presenting realistic  hurdles of the practice that I will definitely come across. 

I learned that automated tests are another codebase that requires the same discipline as production software: design, code review, debugging, and maintenance. This reframes automation as a more conventional dev task to me, which makes it feel somewhat more intuitive. The article also helped me understand the limits of automation for exploratory, usability, and context-sensitive checks that require human judgment. Going forward, I will prioritize writing maintainable, focused automated checks that target stable functionality and avoid brittle end-to-end scripts that duplicate application complexity. I will treat automation as part of the development lifecycle, putting the development through the same checks; code review, proper development principals, etc. Finally, I have begun to see automated testing as a way to free up time for exploratory testing, allowing for me to act as the "human" side of things, while the automated test covers the more general aspects.