I guess since we have manual QAs, there's less motivation to get away from manual testing as it's literally their job description. Not to say we aren't wasting time and money still. I do find other devs and I still need to spend a lot of time ourselves manually sanity checking things.
That all does sound like my dream end goal, though, thanks for the responses.
Nah, red flag is certainly accurate in my case.
We really don't have a strong hierarchy of engineering leaders. Devs are all pretty much equal. EM is extremely hands-off, but also prefers to hire inexperienced developers to "train them up" (which seem like contradictory ideas...). So we we have a very free-for-all development process after work is assigned. And of course very few (zero?) devs really want to start doubling estimates for quality that no one seems to care strongly about.
(The saving grace here, if you can call it that, is that it's very easy to go around leadership and do whatever you want with the dev process, so long as you can do it yourself. So perhaps what I should do is add stricter code coverage checks on the services primarily worked by me as a way to protect me from myself, and maybe convince some others to join in.)
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 more or less the thoughts I typically hear online, and all makes sense. What I tend to notice interviewing people from big(ger) companies than mine (mostly banks), it sounds like testing for them is mostly about hitting some minimum coverage number on the CI/CD. Probably still has big benefits but it doesn't seem super thoughtful? Or is testing just so important that even testing on autopilot has decent value?
I get that same feeling with frontend testing. Unit testing makes sense to me. Integration testing makes sense but I find it hard to do in the time I have. But frontend testing is very daunting. Now I will only test our data models we keep in the frontend, if I test anything frontend.
Was there any event that prompted more investment into testing? I feel like something catastrophic would need to happen before anyone would consider serious testing investment. In the past (before I joined) there were apparently people who tried to get Selenium suites but nothing ever stuck.
I think nobody sees value in improving something that is more or less "good enough" for so long. In our legacy software, most major development is copy+paste and change things, which I guess reduces the chance of regressions (at the cost of making big changes much, much slower). I think we have close to 100 4k line java files copied from the same original, plus another 20-30 scripts and configs for each...
We are doing a "microservices rewrite" that interfaces with the legacy app (which feels like a death march project by now), and I think it inherited much of the testing difficulties of the old system, in part due to my inexperience when we started. Less code duplication, but now lots of enormous JSONs being thrown all over the network.
I agree that manual testing is not enough, but I can't seem to get much agreement. I think I do get value when I write unit tests, but I feel like I can't point to concrete value because there's not an obvious metric I'm gaining. I like that when I test code, I know that nobody will revert or break that area (unless they remove the tests, I suppose), but our coverage is low enough that I don't trust them to mean the system actually works.
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).
You can start by using plain, semantic HTML and grabbing a classless CSS with a license you like. (Check out this list.)
It's good enough for a simple app or site, and it's honestly impressive how good something can look with just this. It's the "plain t-shirt and jeans" of web design.
Great advice, you two. Have a bunch of kids and teach them APL, Actionscript, and Autohotkey. On it!
:)
Thanks for the response. I agree that the project's big boss has an impressive ability to BS on the greatness of our project, and it may be enough to push the project past the finish line.
It seems you put a lot of weight on the project's "triumph." If the project fizzles out or fails spectacularly, does that not make you more of "the fool who couldn't do it and didn't know when to quit?" I don't think I'd hold it against my coworkers for leaving if they think it would improve their situation. (And doesn't a sound project plan account for the fact that you may lose people every so often?)
Interesting note about small job market though. I only have a ~20 person IT department without much churn so it feels quite small to me still. How do you see this reputation spreading? Just the diaspora of former coworkers is wide enough that most/many companies tend to have someone who knows / has heard of you?
Yes, considering it as a paid education always helps. I don't really think of anyone here as a mentor, so I usually have to study on my own to learn what I need, and I still tend to regret most design decisions I make. And there's just that looming feeling that everything I've worked on is ultimately worthless. But I guess all of this is just part of the software development job, ha.
Interesting that you say jumping damages the personal image, since it seems what most others here advocate. This job gives me good perspective, so I still wouldn't want to go elsewhere without convincing myself that it's a meaningful improvement.
I agree that I tend to enjoy my personal projects far more than anything at my company. My typical problem is that I burn out quickly once I get really into anything long term. And frustratingly, I tend to want to work my own projects most when my work gets most stressful.
I guess it's just hard not to get attached to something you spend so many hours working (and unintentionally thinking) of. But this sounds wise advice.
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.