Skip Navigation

Possibly stupid question: is automated testing actually a common practice?

Referring more to smaller places like my own - few hundred employees with ~20 person IT team (~10 developers).

I read enough about testing that it seems industry standard. But whenever I talk to coworkers and my EM, it's generally, "That would be nice, but it's not practical for our size and the business would allow us to slow down for that." We have ~5 manual testers, so things aren't considered "untested", but issues still frequently slip through. It's insurance software so at least bugs aren't killing people, but our quality still freaks me out a bit.

I try to write automated tests for my own code, since it seems valuable, but I avoid it whenever it's not straightforward. I've read books on testing, but they generally feel like either toy examples or far more effort than my company would be willing to spend. Over time I'm wondering if I'm just overly idealistic, and automated testing is more of a FAANG / bigger company thing.

46

You're viewing a single thread.

46 comments
  • My context: I'm in a small ~30 software company. We do various projects for various customers. We're close to the machine sector, although my team is not. I'm lead in a small 3-person developer team/continuous project.

    I write unit tests when I want to verify things. When I'm in somewhat low, algorithmic, coding behavior, interfacing areas.

    I would write more and against our interfaces if those were exposed to someone or something. If it needs that stability and verification.

    Our tests are mainly manually (mostly user-/UI-/use-interface-centric), and we have data restrictions and automated reporting data consistency validations. (Our project is very data-centric.)

    it’s not practical for our size and the business would allow us to slow down for that

    Tests are an investment. A slowdown in implementing tests will increase maintainability and stability down the line. Which could already be before delivering (reviews, before merge or before delivery issues being noticed).

    It may very well be that they wouldn't even slow you down, because they could lead you to a more thought out implementation and interfacing. Or noticing issues before they hit review, test, or production.

    If you have a project that will be maintained then it's not a question of slowing down but of are you willing to pay more (effort, complexity, money, instability, consequential dissatisfaction) down the line for possibly earlier deliverables?

    If tests would make sense and you don't implement them then it's technical debt you are incurring. It's not sound development or engineering practice. Which should require a conscious decision about that fact, and awareness on the cost of not adding tests.

    How common automated testing is - I don't know. I think many developers will take shortcuts when they can. Many are not thorough in that way. And give in to short-sighted time pressure and fallacy.

46 comments