Testing = slow? Yeah, that's by design, you dipshit.

Sign in<br>Subscribe

Can you tell I'm mad? Here goes:<br>Software testing is always done within constraints, the biggest ones usually being time and budget. Arbitrary deadlines usually put the most pressure on testing, and the allure of taking a shortcut by expediting testing has surely been observed by many of you, my dear readers.<br>This often takes shape in the form of managers breathing down your neck, asking "what's taking so long", "why is testing so slow", "can we save time somewhere?".<br>This, frankly, is dumb. Testing is slower than businesses want, for a reason!<br>Let's go back to the basics: why test?<br>What is the point?<br>Ostensibly, most companies spend money on testing because not doing any of it carries too much risk. Apparently enough risk to warrant the expenditure. But yeah, this expenditure "hurts" because you never know whether it was needed or no. If testing is done and not much trouble was found, in hindsight you could have skipped it. If testing has been done, but problems still happen, then what the hell did those testers do?!<br>This is one of the core problems in testing that I, and no one else, can solve.<br>But, it has been tried, by evil people. The Factory School wants you to believe that there is a magic testing process™️that will assure that your software is working as intended. Test plans and test cases are created, according to ISO standards.<br>This is good marketing because this is exactly what business leaders want to hear.<br>It's also a trap for testers. We cannot deliver on this promise. You cannot associate yourself with a certain quality standard, the absence of bugs, the completion of testing. You shouldn't assure anything. You shouldn't sign off on a release. When shit goes down in production (and it always does to some degree, especially in this LLM coding era), you are now the scapegoat.<br>Automation hype started fr<br>The method of the Factory School is now the most widely known test approach, even among non-testers, and this was the first strike against good testing. Then came DevOps.<br>I'm not against DevOps at all, but we shouldn't be blind to its problems. We now got a testing culture that was all about automation (to a larger degree than it was before).<br>Automate everything, including testing. A test that's not in a pipeline might as well not exist.<br>But yeah, this is a pipedream. Not everything can or should be automated in testing. I still found loads of problems when I focused on integration testing. But....this type of testing that I was still doing, dinosaur that I am, is slow.<br>The focus on speed ramped up. Did it pay off, to some degree? Sure did!<br>At my client at the time, we could release the backend services multiple times per day, and that was largely possible because we had a nice pipeline full of automated tests that gave a sense of security. The word "sense" is doing heavy lifting here because sometimes it still went wrong! No matter. Quick rollback, quick fix, new attempt. It was less costly to make mistakes because it was often quite easy to fix. Combine that with canary releasing and good observability and I'm not surprised at all that the business was very happy with the state of things.<br>But.<br>BUT.<br>For bigger, newer projects that added new functionality which required code to be written across multiple systems this is not good enough. You still need good old fashioned testing that truly focuses on finding problems.<br>This type of testing is slow.<br>Testing cannot prevent problems from occuring in production, nor can it prove that the product is bug free, and yet we start our mission to do as much of that as we can anyway. This is not a "follow this checklist" type of work. To do this well you need skills.<br>Risk analysis, domain knowledge, technical knowledge, test design knowledge, communication skills, to name a few things. It takes time to do all the tasks that are needed for deep testing. It's also highly rewarding and fun (if you like thinking, at least).<br>And when you inevitably find problems, the team needs time to fix those.<br>This might threaten the deadline of the project and this is when managers start breathing down your neck.<br>Look, buddy. I'm trying to do my work here. You wanted testing done for a reason (I think?), and now you're surprised that it takes the time it takes? You want me to take shortcuts? As a context-driven tester, I am highly aware of my constraints. I'm doing away with as much fluff as a I can by not spending tons of time on creating artifacts. But, I'm not keen on tossing away all my work standards because of bad project management on your part.<br>Testing slows you down, on purpose! It's methodical, meticulous. I thought that's what you wanted. The slowness is not a flaw! Software is a credence good, highly dependent on reputation. Skip or shortcut on testing enough times, and you'll piss away all the goodwill you have among your user base.<br>Uno reverse, bitches<br>Sometimes, the call is coming from...