this post was submitted on 24 Jun 2024
441 points (98.0% liked)
Asklemmy
43846 readers
880 users here now
A loosely moderated place to ask open-ended questions
Search asklemmy ๐
If your post meets the following criteria, it's welcome here!
- Open-ended question
- Not offensive: at this point, we do not have the bandwidth to moderate overtly political discussions. Assume best intent and be excellent to each other.
- Not regarding using or support for Lemmy: context, see the list of support communities and tools for finding communities below
- Not ad nauseam inducing: please make sure it is a question that would be new to most members
- An actual topic of discussion
Looking for support?
Looking for a community?
- Lemmyverse: community search
- sub.rehab: maps old subreddits to fediverse options, marks official as such
- [email protected]: a community for finding communities
~Icon~ ~by~ ~@Double_[email protected]~
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
The shift was around 2018 or so. It was talked about on qa forums and conferences. It likely was talked about at conferences that management go to, but I can't confirm that. It seems like you must work in a specialized industry. 1 QA to 4 devs is about the standard. And they keep up by cutting corners. The effort required to creat test automation to test a feature is on par with the effort to create the feature. And then you have to add in old tests that need to be maintained. No way one person can cover 4 and not cut corners.
The company that takes the risks gets the product out before those that don't. And the ones who get lucky not to have a major thing tank them win in the end. That is just how the system works.
No no no. They do not set the ratio like it is knowing they will purposefully do a bad job. Anyone with half a brain can explain to a board why that's a bad idea and the risk around it. Do you have any proof at all that companies knowingly build up a dept that will cost them a bunch of money and only prevent issues sometimes? No, that's absurd. I have seen first hand as a developer, a QA resource cover up to 5 people without issues. I have managed teams, still do, that have a 1:4 ratio and keep up. It can be done and has been, just because you've not experienced it doesn't make it impossible.
Yes, this company taking some risk like in a movie, beeting them to market. And what if their solution causes massive issues due to QA not catching some critical bugs due to cutting corners. They forever lose that entire market. They company could be out of business instead of being able to still compete in that space. No investor would risk money like that. Where are you getting these ideas from?
https://www.abc.net.au/news/2024-07-19/technology-shutdown-abc-media-banks-institutions/104119960. They didn't even test the update before pushing it. And the company will still exist in a month. They will take a stock hit, might lose some customers, but in the end it will just be a blip.
Jesus dude, your still on this, I wrote off this convo forever ago.
This will destroy Crowdstrike. They will not exist in a year. This is not "just a blip" lol. Many companies have collapsed over much more than this.
You make so many assumptions. How do you know they didn't test it? How do you know a wrong build didn't go out? You're entire stance is based on assumptions fed by anecdotes from limited experience.
Remember solarwinds... that was supposed to destroy them to. Still here though.
You seemed surprised companies would risk a catastrophic bug because it would destroy them. But this will be the evidence that it won't. And yes, the most likely cause was that the copy process failed somewhere along the line. But testing hashes of the update against what you actually tested is part of qa. And clearly testing didn't happen somewhere critical.
Simple. Been a QA, worked with QAs, been to conferences with QAs. We tell the boss we can't cover the whole thing, they say just cover the most important stuff. The general advice from veteran QAs is to not even say that to the boss. They know, and they can't get more resources. So veteran QAs advise others to get a feel for how much time you can spend on a thing before they start complaining that you are holding it up. Then work within that timeframe. As long as nothing major gets through it's all good. Your view is one of survivor bias. Nothing big got through, but that doesn't mean it was completely tested. Its good enough, untill it isn't. Side note, I've seen product managers close bugs, not because they weren't bugs, but because they were bad enough, compared to features they thought would sell more software. This was an outlier, usually they just wait a few years and mass close everything that is X years old. That, I have personally seen everywhere I have worked.
My view is survivor bias sure.
And you're view is based on anecdotes and assumptions. Things you've seen that you assume applies to the entire industry because you've worked in QA. Well I've worked at multiple companies, in roles from product to engineering, working myself up to the level of CTO. I talk to other CTOs and understand how their teams run and fail. I have to make decisions that keep our tech going and deal with consequences when they aren't. So forgive me if I don't put a ton of stock in your statement that "quality doesn't matter" when I've had multiple conversations with executives and multiple experiences that prove that to be false.
Bottom line is, I've told you my point of view, you disagree, that's fine. You don't work for me, I don't need to worry about it. If you truly think quality doesn't matter and that's working for you, have at it.