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.
Wow 😲
It’s not that hard to setup GitHub or GitLab to make sure all the unit tests run for each PR.
If you use something else for version control, check if they offer a similar CI feature. If not, setup Jenkins.
I’m an SRE at a big tech company, so part of my job is to make sure CI infrastructure is readily available to our Dev partners. But I’ve worked at smaller companies before (10 or less SWEs) and even they had a Jenkins instance.
This is a bright red flag to me. If I worked for a company that didn’t have CI, the first thing I would do is set it up. If I wasn’t allowed to take the time required to do that, I would quit…
We do have CI (Azure DevOps), we aren’t that insane. Though to be fair, it’s relatively recent. The legacy app has a build pipeline but no tests. We got automated deployments to lower environments set up about a year back.
My main project has build pipelines as well, Spring Boot “microservices” (probably a red flag given our size and infrastructure) with code coverage around 40-60% mostly unit tests. But I’m the only dev that really writes tests these days. No deployment pipelines there though as the SysAdmin is against it (and only really let us do the legacy app reluctantly).
Ok. So if you have the infra already, it’s really just a matter of actually writing the tests. That can be done incrementally.
40%-60% unit test coverage is honestly not too bad. But if the company’s bottom line rests on this code, you probably want to get that up. 100% though isn’t really worth it for application code, but it is definitely worth it for library code.
One thing where I work is that all commits must be reviewed before being merged. A great way to improve coverage is to be that guy when people send you PRs.
Ehh to be fair, none of the code with coverage is in use by anyone. It’s a constantly delayed project that I kind of doubt will last more than a few months in production if it ever gets there. The primary app has no tests, and the structure probably would require dedicated effort to make testable. Most logic goes through this sort of “god object” that couples huge models very tightly with the database. It’s probably something that can be worked around in a week or so, but I never spend much time on that project.
I’m not sure if I want to be that guy though, slowing everyone down when scrum master and managers are already constantly complaining about everything going over estimates. (Even if poor testing is part of the problem…) I could maybe get a couple devs to buy in on requiring tests on new code, definitely not QA or my EM though. Last time tried to grandstand over testing, I got “XYZ needs this ready now, I’ll create a story for next sprint to write tests.” … 4+ sprints ago, and still sitting there. I just don’t really know how to advocate for this without looking like an annoying asshole, after trying for so long.
This is a bigger problem than tests.
You’re presenting a solution for a problem that the team either does not see as important or doesn’t think exists at all.
You need to demonstrate the value the solution can bring to them on their terms.
You mean things going over estimates or SM/EM complaining about it?
Definitely it’s a known issue, and I think people think it’s semi-important. Feels like every other standup has a spiel from the EM about “we need to test things, stop breaking things, etc.”.
Whenever I argue on their terms though, I quickly “lose”, because business terms seem to be, “agree to everything from the business, look busy, and we will have time for IT concerns (i.e., testing) when we are done with business projects for the year (i.e., never).”
If I want any meaningful change, I think it will need to be be something I work around management on.
The combination is bad.
If you see it as an argument, you’re not going to make headway. I would also question your assumption that you are correct about what their terms are. By this, I mean are you sure you understand what they value and prioritize? People often say that something is important, but show that something else is even more important.
It may need to start that way, but getting the team to buy in will take building trust. Which might be eroded down due to the consistent failure to meet estimates.
I’m not really sure what there is to do about that, then. My own project is already is about to hit 3 years on something that was intended to be <1 year total, due to constant scope creep. Nothing bad seems to ever come out of the delays though, so I tend to ignore most of the complaints.
I don’t really see it as that. “Discussion” is more what I try to do. But you are correct that I don’t think I can argue on their terms.
Probably not exactly, but my point is that the priorities technical leadership says we value (quality, scalability, fast iterations), run counter to what we actually prioritize. I often ask why we prioritize Project X over Project Y and the answer is almost always a variation of:
Which is why I said our priorities are more about appearing busy and important than anything else. (My own project isn’t even wanted by most business users. It was spearheaded by the VP of IT as a huge technical modernization effort despite doing almost nothing to improve or get away from the legacy system it is “replacing”.) So I think the reason I have such trouble getting buy-in is that better testing runs counter to IT’s true priorities, even if it provides business value.
Perhaps. But trust is already pretty darn low for that very reason.
Maybe it’s time to start looking at other employers. The culture there doesn’t seem to fit with your values.