Ask Experienced Devs

1233 readers

2 users here now

Icon base by Delapouite under CC BY 3.0 with modifications to add a gradient

founded 1 year ago

MODERATORS

Ategon

Possibly stupid question: is automated testing actually a common practice? (self.ask_experienced_devs)

submitted 6 months ago by yournameplease to c/ask_experienced_devs

60 comments fedilink hide all child comments

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.

you are viewing a single comment's thread
view the rest of the comments

[–] ericjmorey 2 points 6 months ago (1 children)

You mean things going over estimates or SM/EM complaining about it?

The combination is bad.

Whenever I argue ... , I quickly “lose”,

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.

If I want any meaningful change, I think it will need to be be something I work around management on.

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.

[–] yournameplease 1 points 6 months ago (1 children)

The combination is bad.

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.

If you see it as an argument

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.

are you sure you understand what they value and prioritize

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:

"We can't let IT be the reason the Project X is late."
"The business thinks we've been working on Project X a long time (often not true) so we need to show progress."
"Project X was promised for Release Z so it needs to get done over anything else."

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.

[Trust] might be eroded down due to the consistent failure to meet estimates.

Perhaps. But trust is already pretty darn low for that very reason.

[–] ericjmorey 3 points 6 months ago

Maybe it's time to start looking at other employers. The culture there doesn't seem to fit with your values.