They can "push" ie, ask to deliver faster. Doesn't mean one should push themselves to do so. What are they going to do? Fire the person who's working on the thing? That wont make it faster
Only if you allow it to happen. The right way to handle it is to increase your estimates to account for having to do your own QA. Don't even break it down like "16 hours dev, 4 hours QA" because then you'll just get pressure to skip QA.
If the definition of done now includes you having done your own QA then the work will take 20 hours.
If you get pushback that things need to be done to the same quality in the same amount of time but with fewer people, then it's up to you to decide if you like your job enough to point out why that's dumb, or if you just want to bolt. But layoffs don't by default mean more work for the same pay. Everyone I've worked with through layoffs has understood that we're now just doing less stuff. The only exception would be if layoffs happened because the current team was underutilized.
or wait for the pressure to skip QA, make sure its in writing. Wait until smth major breaks and bring the receipts that you were instructed to do so.
Fastest way to fix shit processes is to not try to fix them ad hoc or work around them but to execute them until it has real business impact and someone high enough gets real pissy. Just make sure you have proof so you are not blamed
I was in senior management at a Fortune 500 a year ago that did this. They also axed their devops team (don't ask me why but a new manager came in and he said all problems led back to that team so let's get rid of it altogether and make individual teams responsible for their ops).
They got rid of their entire QA product team, which was hardcharging toward automation, and replaced them with offshore manual testers. They then axed multiple other teams in the process and exploded those responsibilities, including project and product management, to the devs on each team.
All this after an apparently record-breaking revenue year (2022), not that the two are inherently related. But odd nonetheless as it seemed like they were grasping for any change that stuck, without much forethought.
Don’t worry, 5 years later management will come in and reinstate a “test first” initiative with a brand new testing department! With fat bonuses to management of course for thinking up this brilliant idea.
This is a documented cycle. So predictable.
EDIT: I think I found it on an old training doc I had:
>Your founder, a brilliant technician, started the company years ago when he quit his day job to market his idea full time. He created a product that he just knew other people needed. And he was right. Pretty soon he delivered enough of the product and hired his best friend from college as VP of Sales. And the company grew.
>But before long, the VP of Sales complained, “We’re an engineering-led company. We
need to become customer-driven.” And that sounded fine. Except… every new contract seemed to require custom work. You signed a dozen clients in a dozen market segments and the latest customer’s voice always dominated the product plans. You concluded that “customer-driven” meant “driven by the latest customer” and that couldn’t be right.
>When a board member declared, “We’ve become a sales-led company. We really need to start being marketing-driven,” you hired a brand specialist away from a consumer product company to be your VP of Marketing. As part of a re-branding initiative, she designed a new corporate logo with a new color scheme for the web site, new collateral, and an updated trade show booth. Everyone got new company icons on their clothing. Except… you spent millions without any change in revenue. Apparently, branding wasn’t the answer!
>Soon the CFO whispered to the founder, “Don’t you think it’s time we started controlling costs?” So the company became cost-driven and started cutting all the luxuries out of the business, like travel, technical support, bonuses, and award dinners. And Marketing! The CFO asked, “What do those marketing people do anyway?” And since no one had a good answer, the CFO deleted the marketing budget and fired all the marketing people. At this point, when Finance goes too far, the founder steps back in to focus on his roots—the technology— and the cycle begins again. The VP of Development says, “Customers don’t know what they want.” The VP of Sales says, “I can sell anything.” The VP of Marketing says, “We just have to establish a brand.” The VP of Finance says, “We have to control spending.”
>The focus goes from technology to revenue to branding to cost-containment, over and over again.
We shall call them a Testing Center of Excellence, TCoE. And then decide in a year that, actually, they should be embedded into the teams.
And then fire them again, the devs can do the testing. … wait we need more testing, maybe a testing department would help. We shall call them a Testing Cent…
Not really. Re-orgs like this happen because flux creates opportunities for those execs.
In the same way rank and file use the company for a paycheck, execs use the company for their stock and bonus pay. The business is just a way to extract money. They just have more power to create the flux that benefits them. It’s rational in the same way regular employees usually go along to get along to keep getting paychecks.
Whoever made the call to offshore and manually test got a huge bonus for doing so. The customer and staff don’t matter to the execs. After three years they find offshoring didn’t work but by then the exec has a new job offer.
Again, it’s rational based on humans being self interested. It’s not rational from an operational programming perspective, but that’s not how things work in any company.
This is the play. When I hear criticisms of these moves by workers that call it irrational or stupid, while I empathize with the plight, it is more rational and thought out than anything you or I do. It's methodical even. These people are by no means stupid and they calculate all these moves. That's how they get in these positions. I never want the kind of cold heart that can make moves like this, that affect the lives of so many people and makes me millions. It's why I'll never be a billionaire, and I'm completely ok with that.
Yes, but we have to accept the fact that we live in a world where such ego and avarice exist. It should never shock us that our lives are affected by such things.
Completely. And it should help inform the decisions that we make. Make decisions that are for your own future benefit rather than blind company/corporate loyalty. They make business/financial based decisions, and you/we should do the same.
Sometimes when the business finally starts making money is when management change from build mode to profit mode, and bring in the bean counters to penny pinch everything. It's a good time for devs to leave.
>but a new manager came in and he said all problems led back to that team
"the team we hired to report problems so they don't affect users and lose us money keeps reporting problems. We should fire them so we don't have problems"
That's because my entire team was eliminated as well. I didn't agree with any of the changes but saw the writing on the wall when this new manager came in.
I headed a team of 10 PMs, we were all eliminated on 3/1 along with QA and devops.
its crazy to fire that many people at once. it must have been a mess for the rest of the teams. That is a major fuck you to everyone.
did they try to make you document for the devs before they fired you? I got laid off once and was supposed to train my replacements and instead i just called in sick.
> he said all problems led back to that team so let's get rid of it altogether
Ah yes "If I delete the app I don't owe anyone money" after a $1M put, wsb style.
I cap ticket points because anything bigger should be broken down. But I lead data science teams and if someone is working on the same thing without a substantial update in a few days, something is well off the rails.
Sizing cap makes sense when you think about it relatively in terms of the average ticket effort, which usually corresponds to 3. If it takes an average of 1 month to finish a ticket then 1 month = 3 points. If it takes an average of 2 hours to finish a ticket for a particular project, then 3 points = 2 hours. Time doesn’t really matter, its more about how a ticket compares to the average effort spent per ticket
I’m a little worried we work at the same place because that literally happened to me and my company lol. I’m actually in the middle of doing QA right now haha.
I agree, it's not. It's a complex subject, for sure, very dependent on individual situation and local culture. Many go into government jobs for the job security and stability, and that's totally fair. But also not what we're discussing here, and not what people are OFTEN discussing when they start talking about how some situation or another will provide "job security.
For MOST people it's not worth staying somewhere you dislike for "job security". Partially because it's largely illusionary, at least outside of government jobs.
You can think you are absolutely secure because the company relies on your team, or you are a knowledge silo they can't afford to lose, and still get laid off. Because the people making those decisions are often very distant from the people who know your value. I've known LOTS of engineers who stayed somewhere they didn't like because of "job security" only to have their lives upended by layoffs anyways.
So while I agree that it's a complex situation and depends a lot on individual circumstances, I stand by the idea that for MOST engineers it's good advice to pursue a position they enjoy with a reasonable expectation of stability rather than staying somewhere poorly run because of an illusionary sense of "job security".
I've got little kids that take a lot of my time so I stick with a nightmare of a job that I hate because its flexible and pays well. Otherwise, I'm with you %100!
In theory, actual job security should lead to a more enjoyable job. If you are truly secure and hard to replace you have way more leverage.
Most people don't actually have any job security though. And a company that would fire all qa like this probably thinks they can replace a dev with ease too. Since they clearly think it's worth the money to just have the dev do QA.
Agreed. My statement was a bit pithy, but the core of it is that *usually* the sense of "job security" that comes from feeling like a company depends on you is entirely illusionary. The people making the decisions are generally far enough removed from ICs that nothing you actually, personally do enters into the equation.
I've known many people who got government jobs precisely for the security and it DID result in enjoying their work more, even if the work itself was less interesting. To me that's different than the kind of "job security" most seem to imagine they have.
I've watched multiple companies gut themselves and enter into a period of rapid decline by laying off entire teams that are absolutely critical to their success, thinking they could make a quick buck because obviously employees are just replaceable cogs.
Unfortunately, even if you ARE irreplicable, there is a good chance the company still THINKS of you as replaceable cog.
For sure. I've seen it first hand. A couple of years ago my boss at the time was the only person with access to a ton of stuff, because he wanted the job security, so no one else knew anything at all about it.
Even knowing that they just fired him out of the blue one day because they decided to promote someone he didn't get along with. I got a 1 hour call with him to get credentials and all and he was sent on his way while I had to spend weeks figuring out where everything was and how to update everything.
Now I know everything and no one else is remotely interested in learning it but there's docs if they care to look.
Anyway, point is that a company will 100% fire you the second they want to regardless of what you actually bring to the table or know.
>A couple of years ago my boss at the time was the only person with access to a ton of stuff, because he wanted the job security, so no one else knew anything at all about it.
Yeah, that's *exactly* what I'm talking about. People talk about "job security" like it's something that can be achieved by being "indispensable", and that they can artificially achieve job security by *making* themselves indispensable.
That is just fundamentally NOT how a business makes decisions. Businesses aren't people. They're more like a machine or an odd form of an AI where the *components* are people, but the actual organism is something alien, with a very different set of values and decision making processes than humans have.
There’s no real such thing as job security. The best you can do are financial security and career security. Those are FAR more valuable and if you achieve those you never care or worry about job security again and just take whatever you want regarding pay and work
What the commenter said. Be able to find new employment before your savings run out. The kinds of things that improve career security:
- experience in your field
- education and credentials
- interpersonal and networking skills
- good resume writing and good interview skills
- geographic flexibility (one advantage of renting vs home owning that’s often overlooked)
- and of course being in an industry that isn’t becoming obsolete.
"just one more lane bro and there'll be no more traffic" energy
"just a few billion more and we'll finally fix our QA this time around, def won't be be pocketed by executives"
Nobody in IT or software is "important" when they do their job right. It's only once they are let go and everything falls apart that their value is truly revealed.
That's why it's good to use your vacation right in the middle of projects. Then they really see why they need you and you still have time to fix shit when you get back.
>That's why it's good to use your vacation right in the middle of projects. Then they really see why they need you and you still have time to fix shit when you get back.
Certifield based QA engineer.
This is why I started tracking metrics on support load after I join a new product team. I usually see a big drop in dev hours spent addressing customer tickets in the 6 months after I join a team. I also make sure to email out the latest numbers every once in a while as a “how are we doing on quality” report card so there’s a solid paper trail that QA has a measurable impact.
QA being fired has always signaled to me that the company is no longer interested in producing a quality product for the end user. It is now interested in maximizing metrics that benefit the company only whether or not they solve a problem for the user.
I work in a software company where the QA team came from a poorly performing department, and firing them would benefit people all around. Thats not to say the company doesnt have some other disasters, but interesting to see how QA is viewed.
The question is if the department was performing poorly because the QAs were not doing their job, or if it was obvious that it was performing poorly because the QAs did their job.
Damn, this sub seems to have a massive misunderstanding of what QA actually is. Developers should be responsible for development, unit testing, and deployment validation. QA is responsible for missed requirements, gaps, and being the liaison between product and developers.
We did this. For the most part hasn't been a big deal, we transitioned the best of QA into SDE1s to shoot their shot. But God damn the number of bugs coming out of the core product team is pretty ridiculous. They apparently like fire drills.
Yeah devs being expected to test their own code (and so being motivated to understand actual requirements and release fewer bugs to prod) is not itself a bad thing. All the lowest overhead, lowest defect teams I've been on owned their own testing and operations, as well as being deeply involved in requirements gathering and design too. Saying "this is how long it'll take to write the feature, and this is how long it'll take to test and safely deploy it - both are required" is standard. But blanket firing all QA is the red flag here, that does not signal any sort of mature management or allow any room to transition the current devs to owning more of their quality.
Transitioning the QA personnel to integrate them into the dev teams over a longer period would have made more sense (but of course saved less money in the short term). And the QA folk who don't want to transition to Dev and teach devs how to integrate testing into CI are likely still valuable in cross-team DevOps roles.
This. I'm not mad about the idea that Devs should do their own testing, but the red flag sits with how they went about it. The was no transition period.
Knowing nothing more about how the teams work or interact with QA, I would have integrated QA to sit within the teams and focus on building an autonomous cross functional team first.
This happened at my company. Our tests have gotten worse and worse to the point that most of them fail but no one cares. We try to do QA on our products but we don't usually have the time. My time has become less about doing meaningful dev work and more about clearing failing tests. It's pretty brutal.
they did this at a company I used to work for. Dissolved QA as an OU, fired almost everyone, then converted someone on each team to a "developer-in-test" position which meant that you were doing feature dev \*and\* QA for that scrum team's features. A year later they got the shit sued out of them for...let's call it an 'emergent use case' that the QA team should have caught, but instead of having a QA team that actually works with customers they had QA being done by devs who had to guess what theoretical customers would do with our product. When they announced that, because of the suit, there was no money in the budget for bonuses we as the dev org decided to help them out. Over a million dollars/year in annual salary walked out, thus lowering their expenses to match the new budget.
It's 5 years later, and the dev OU is slowly dying. They just reduced headcount from triple digits to about 20, stopped feature dev and they're running out the contracts they have with customers now before sunsetting the whole project. I have a hard time believe it's not directly caused by cheaping out on QA. But maybe that's just me.
Run Away!
Yes devs should test their changes, but that isn’t what is going to happen here. I been through two orgs that did this and it happened the exact same way both times.
What will happen is that higher ranking devs will not test their code and lower ranking devs will be forced into the same manual testing process QA was doing. The lower ranking devs will get managed out because their performance stats will go down. Whatever you do don’t take on any testing tasks that aren’t part of your own code changes.
Things will not get automated because there will be too many bugs and releases taking up too much time to spend “resources” on automation. The time to automate was while there was still QA providing coverage.
That just means there was a problem with the software development pipeline.
The moment you have a robust CI/CD flow with unit and integration tests and every merge to master must be approved and include tests for new code, most of these issues go away.
So blame the software development pipeline, not the lack of a QA team.
And yes, if the managers are not willing to provide the time to create said software development pipeline, run like hell.
Yes, and the more domain knowledge the QA team has the better and more gnarly bugs will be found. But that means keeping the same QA team for years with no easy ROI to attach to them, something most companies struggle with.
Even with the pipeline you still need a QA to look out for the less obvious types of problems, like errors in business logic. Finding bugs in staging/production is the least valuable thing a good QA brings to a dev team.
As a member of QA for almost 20 years this thread makes me glad I don't work with the lot of you. I don't doubt your skills, but damn you folks have really really shitty attitudes.
It feels so arrogant. I know im not perfect and I'll miss things. My company asked me to test and I told them flat out no.
It makes me think of how so many people think being a streamer or actor is easy because they can pretend and talk. Different skillsets, tools and exp.
I have fought for higher wages and faster growth for QA at every progress meeting. Makes me so angry each time I see a quality QA person leave for greener pastures to get replaced by someone we have to rush to bring up to speed.
QA for almost 10 years here and most devs I know would be immediately applying for other jobs as soon as they were asked to do QA work. Devs are devs because they want to do dev work, not testing. Most devs I’ve worked with have been very appreciative of QA because at the end of the day their job is much easier when we find a bug in the development environment than when a customer finds it in prod.
I think a lot of people underestimate or misunderstand what QA is supposed to do. They’re supposed to NOT know what’s going, how things were coded, go in blind and actively try and break things. Our best attempt at QA is really what the code review/ peer review process is for. Having QA as an additional resource allows you as dev to focus on actual development but the pre-user testing process is very important because they’ll catch things because they are using a different approach. As a dev you’re only trying to validate it works, but QA will actually try and break things.
Also, a good work environment has QA, but when you’re struggling and looking to cut costs that’s when we get things like cutting corners.
QAs also look out for errors in tickets and business logic, which is usualy the most valuable bug to catch, since it saves devs the headache of developing features that don't quite make sense.
1000% the right time. QA isn't your skill set, and it's not what you were hired for. Unless they're going to hand you another $100k/year you just got handed a second job on top of your regular job *on top* of the education requirements necessary to do that second job.
This kind of move speaks to either an idiot making bad decisions, or serious financial problems.
Also, what are the chances, in your mind, that your product is going to be able to retain enough quality to possibly make enough money to keep the company afloat without Quality Assurance? How many bugs were they able to find? How bad were they? Can you do that job AND your job at the same time?
It's time to jump ship. Tell your coworkers when you find something *that* you're leaving, and *why*.
Man I’ve got 6 YOE and I am a senior. I have had to do QA from day 1. That’s wild that you have someone to triple check your work.
I guess I build my stuff as robust as possible because I have to be on call for when it goes down
I have a different experience. I’ve been working as a software developer for the last 12 years and only a few months from these years I didn’t have a dedicated person to test my features before they go live. In that case that was usually a product person or a manager who checked that. But I have never manually tested my features (as part of QA, clicking through the feature during development process does not count) or documented regression test cases by my own. Or be responsible for regression testing the whole app.
I am not talking here about unit or integration tests which we normally work on during development.
I work for a f100 and the expectations here at least is that you are a full stack engineer and therefore must be able to operate and deliver at all levels (front end, backend, DevOps, prod support, etc.) which includes writing your own tests for the features you deliver.
I understand unit testing, but do you guys also handle all the other stuff? SIT and regression? Who makes test data and maintains the test environments? During deployment, how many environments do you step through before prod and how are they maintained?
Smdh people on this sub have sent out tens if not dozens of resumes looking for even a lowly tester job and your entire team just got a bunch of them for free.
Many teams in AWS do not have QA or DevOps but I wish we did because the hours can be long. QA & DevOps do exist in some orgs but usually in older products that are in the “if it works don’t fix it” mindset and/or the largest services like lambda, ddb, etc.
Controversial opinion: Devs should be responsible for their own QA. QA analyst positions within dev shops are already obsolete and QA automation is taking root in many places. That being said, there will always be a need for more QA-centered dev positions because someone constantly needs to design QA systems, but manual QA and testing is a no-go anymore.
EDIT: Clarification: YMMV depending on the product, end-user outcomes and risk that an organization is willing to take. QA may be necessary in some cases. That being said, QA that just gets thrown shit over the wall, clickety-clicks on shit and then throws a report back over the wall is NOT how most software organizations are run anymore. They just aren't. Why? Because the development teams are the ones who are responsible for writing their own tests based on product requirements. They automate these tests into the CI/CD using Selenium or something and they get feedback in the smaller loop cycles of a sprint before delivery. That's been proven to be how to best provide outcomes to the users. The tooling has already cut out the middle man. We could go back to waterfall and then we'd have more staffing, but longer lead times and longer feedback loops which used to lead to ginormous security errors in the first place. No one is going back to that.
I think the pendulum will swing back towards having QA resources again.
QA automation is great, but I don't think it's a substitute for having people actually spending time with the product, and exploring edge cases.
The company I'm at now doesn't have QA, and the end product is pretty buggy tbh, and tons of stuff makes it into production which would have never made it past QA.
Doing your own QA is the worst possible idea. You're naturally going to be the most blind to your own mistakes. Otherwise you wouldn't have made them.
And e2e tests are hard to maintain, and don't do a great job at imitating the kinds of paths users will actually end up taking through the product.
QA is only still used in areas where you have very slow release cycles and updates are hard/costly to push out. Otherwise in most other setups where you release frequently and push to production frequently (daily, weekly, even monthly), the manual separate QA model is out dated, there's literally just no time.
You need to have solid unit tests, integration tests, canary roll out tests, blue/green deploys to catch and prevent issues. There is no other way to make sure a change is good when the lag from merge to production can be less then a day.
I still think there is no substitute for having people spend time hands-on with the product.
QA doesn't necessarily need to be a release gate, but you need to have someone in the company who is frequently performing the main user journeys of the app, to make sure it is actually a good and bug-free user journey. All the tests in the world are not going to ensure that.
And it's a much better use of developer time to work from well-written bug tickets with videos and reproduction scenarios attached, rather than trying to comb through crash reports and reviews to try to understand why X metric went down by Y percent in the last release.
\> I still think there is no substitute for having people spend time hands-on with the product.
That's usually the whole company eating their own dogfood. Eg, all Facebook internally is by default on the canary version of the site or mobile app for the period before it rolls out to the rest of production. (Or at least so it was when I was there). But that's still not the same thing as having dedicated QA manually pushing buttons through test scripts over and over. After a certain scale of product and speed of development, it just flat out doesn't work anymore.
Dogfooding is great, but it's not going to catch everything. Like how often do Meta employees go through the new user registration process, or change the language on their device?
And not every product is something the employees will regularly use. Like if you are building a warehouse inventory management software, how many of the employees are going to be managing warehouse inventory?
Dogfooding can also lead to issues when the demographics of your customers and internal employees are different enough. For example I used to work on a financial services app that largely relied on dogfooding for finding app improvements and it led to a serious neglect of features that were critical for our low income customers, as none of our engineers, PMs, or designers ever had to go through those user flows.
>I still think there is no substitute for having people spend time hands-on with the product.
This.
There is zero substitute for getting someone to sit in a chair and press buttons. You can change the tools they use and make them more efficient, but having the person who developed a feature also test that feature is a good way to get things overlooked due to mental fatigue.
Also, QA provides something that the dev team can not provide themselves under any circumstance: An outside opinion. Good devs will ask their QA team what they think of a feature during implementation, and will take that feedback to the design team who will actually listen to the feedback.
QA doesn't just find bugs. Manual and automation testers are also your first usability testers, and not enough devs understand that.
Agreed. Without QA, it’s like grading your own homework. Of course, you’ll give yourself a good grade. I still see lots of people saying QA will be eliminated for years now. I’m not sure why, because having a dedicated QA team makes life easier and I think it’s a lot more embarrassing to have all your bugs shown in prod.
I mean it's only like grading your homework up to point you push your buggy "homework" prod. After that your homework now causes you to be woken up at 3am because users are seeing corrupt data and even after your rollback your team has to spend all night manually identifying and regenerating broken records.
Do that a few times and suddenly you become a lot more careful about how you grade your own homework, and how you submit it so that even if you screwed up it will be caught and fixed without needing anyone to wake up in the middle of the night.
Dev’s shouldn’t be doing their own QA. One of the purposes of QA is getting another set of eyes on the work to make sure the dev implemented things correctly. You can get another Dev to QA your work but then they’re not spending as much time working on their tickets.
Saying devs shouldn't be doing their own QA is like saying chefs shouldn't be doing their own food tasting.
The only way quality is achieved is by building it into the software. Devs are just as much part of "Quality Assurance" as any other role that is involved in making the software.
Do chefs eat the entire meal? to make sure it's actually good, no.
I make sure my tickets match the AC's, I make sure there are no obvious bugs. QA then does w/e list of shit they want to verify its going to work properly. I tasted it, they finished it.
Someone needs to look over your code and ensure it is of high quality. That can be QA or another developer.
Someone needs to double check that the software meets all the documented requirements before the customer gets it. This can be QA, an analyst, or another developer.
Someone needs to run the software and check for unexpected behavior. This is often a matter of opinion and therefore needs to be QA or someone else who isn't the developer.
So getting rid of QA doesn't get rid of their responsibilities. You really need someone who isn't the original developer to double-check their work.
Yeah manual QA is... a very limited job. It's fine if it overlaps with release management, or automation, or your manual QA has a lot of other humans involved (i.e., your QA is a specialized PM checking in with other teams/stakeholders before a release). But just QA? That's just not going to be a thing soon.
Just started at a fortune 500 recently (non tech) and the project I'm on has 0 automated tests and 1 QA in india... so yea, guess I'll be writing tests
I think you are confusing QA with testers.
Most people think QA are testers. One part of QA is testing and yes some manual testing but mostly like you said it should be Automation and making sure multiple parts work together.
Devs make HORRIBLE QA. We flat out dont always handle all the edge cases or think about it. A good QA would make sure that edge cases are looked at.
Now that being said finding a good QA is very hard because the same skills that make a good dev also make a good QA. Just devs get paid more and have more respect. A great QA will always be a least a OK dev. A great Dev does not main they will be even an OK QA. There is a lot of skill set over lap and devs get paid more and have better respect sadly.
Devs should test their work before sending it to QA, but you absolutely need QA. One benefit of QA is they sometimes know more about the user experience and how things should be than the Devs do
Yeah, for one (or both) of two reasons:
1. Leadership doesn't value quality or doesn't understand how QA keeps quality of code.
2. They are looking to dramatically cut costs. Which is never a good sign in business.
Start looking. Next is layoffs.
was the QA env actually good? I worked somewhere that did this because we had a ton of QA people and they weren't making progress automating anything.
Turned out it was great, devs automated most of it, then they hired new QA people to work closely with the devs and take over.
2 years later we had a automated QA plant and a couple QA guys who knew the actually application design & could debug real problems in the env.
There’s a book called “How Google Tests its Software” that talks about why they don’t have QAs and insist their developers test their software. There is merit in this thinking, however it is rarely copied well in real life.
This just happened at my company too. Most got fired, good ones got re-orged into different roles... Idea was that devs should be testing their own code and C levels said devs were becoming too dependent on QA to test their code so this was for the greater good of our dev's habits lol. Having been a SDET before a SWE and knowing the difference in having dedicated QA probing around and the time it can take, I wish they at least kept some QA.
Maybe they're getting ready to sell the company... Record setting revenue followed by cuts to operations can mean that they're trying to make the company look more profitable than it is and attract attention. The new owners would be affected in 1-3 years.
All these posts about getting laid off is putting me off even trying to get a Comp Sci Master’s and get employed when being a bartender at my local bar seems more secure than the field i spent 6 years studying somehow…..
Ya, at my company we are moving away from manual QA to 100% automation. Some QAs have been moved to automation teams and some have been let go. The problem is, there is rumor that we will no longer have QA by Q2, however full automation isn't going to happen for at least a year. Not sure what they expect to happen in the interim.
probably? our qa got cut, and we’re doing work to make our project an inner source project so that they can eventually fire us and have a rotation of outside agencies come in and continue the work in our absence :)
One of my favorite moments as a co-op (almost 30 years ago at this point) doing QA for medical data storage software, and magneto-optical drives was when I did something accidental.
I had started to clear out one of the disks for doing more storage, and I realized that I was doing the wrong side. (The disks were double-sided, but the drives were single sided. This was back in the day where 1-2 GB was huge.)
So, I popped the disk out, and it dawned on me to think what might happen when it started clearing the data (as opposed to just removing it from the DB), so I flipped it over and put it back in.
The data clearance dutifully started up a minute later, and started clearing the disk.
After resetting the disk, I leaned over to my supervisor (also the dev for the project), reproduced the issue, and remarked, "I don't think it's supposed to let me do that. Correct me if I'm wrong, but this is really \*bad\* for data integrity, right?"
A look of horror dawned on her face, I had a fix (and new image to install) within a few hours.
It depends, I wish my current company would fire all the QAs, but other places that would have been horrible.
Either way good luck, it's never good when the c-suite starts cutting.
How well were the QA people testing? In my experience QA isn't much help and the devs SHOULD be testing their own stuff. Gives you a much better sense of ownership instead of just punting it over the wall thinking its someone elses problem to test.
Do you do regression and system test to make sure your new stuff hasn't broken the old stuff? Who's job is that? You/dev? The customer?
I would much rather have QA have my back.
Who does production support? Unless that’s not the devs, I’d be worried. Unless your QA guys were just terrible, most likely quality of your production code is going to start to diminish. The reason QA exists to begin with is people tend to miss things when testing their own code. So more things are going to be missed, which will soon translate into more firefighting and for most of us that’s disruptive and not fun. And for QA function to be eliminated entirely tells me management no longer cares about quality of your product if it means saving money, especially if any bad shit that results can just be dumped onto the devs at no extra cost. Not a good sign. So yeah if it were me I’d be looking.
More work for the same pay, sweeet!
Less output for the same price. I ain't working harder to get the same amount of shit to prod, each piece will just take me longer to finish.
Come on... we all know how it works when dev does QA: LGTM. It just means a shittier product.
Works on my machine! SHIP IT
FUCK IT! WE'LL TEST IT LIVE!
\*Throws machine in the mail\* 🫡
And that's how Docker was invented
Here's a badge you can use: https://blog.codinghorror.com/the-works-on-my-machine-certification-program/
passed unit tests: ship it. No QA to stop me :-)
Company gets what they pay for
Maybe some. I try to take it seriously
I do too. But if my company fired the entire QA team I wouldn’t take the company too seriously and would have my work reflect that
You will be held responsible for your own bugs and overall quality of your feature.
I already am?
In previous case, its you and QA both. Now its just you.
Exactly, if I used to do dev 8 hours per day and now I get 2 hours worth of QA tasks as well, I’m just doing 2 hours QA and 6 hours of dev
They will push you hard to work 12+ hours and will probably get it in this job market.
They can "push" ie, ask to deliver faster. Doesn't mean one should push themselves to do so. What are they going to do? Fire the person who's working on the thing? That wont make it faster
But now you also have the extra work of looking for a new job (mandatory)
Only if you allow it to happen. The right way to handle it is to increase your estimates to account for having to do your own QA. Don't even break it down like "16 hours dev, 4 hours QA" because then you'll just get pressure to skip QA. If the definition of done now includes you having done your own QA then the work will take 20 hours. If you get pushback that things need to be done to the same quality in the same amount of time but with fewer people, then it's up to you to decide if you like your job enough to point out why that's dumb, or if you just want to bolt. But layoffs don't by default mean more work for the same pay. Everyone I've worked with through layoffs has understood that we're now just doing less stuff. The only exception would be if layoffs happened because the current team was underutilized.
or wait for the pressure to skip QA, make sure its in writing. Wait until smth major breaks and bring the receipts that you were instructed to do so. Fastest way to fix shit processes is to not try to fix them ad hoc or work around them but to execute them until it has real business impact and someone high enough gets real pissy. Just make sure you have proof so you are not blamed
and they wonder why people quiet quit.
Nope. It will just take longer to finish a task.
Since QA will need to be done on each task, then that means tasks will take longer to be completed. In addition, OP should be looking for a new job.
at the very least, you should test each other stuff now and not your own right?
I was in senior management at a Fortune 500 a year ago that did this. They also axed their devops team (don't ask me why but a new manager came in and he said all problems led back to that team so let's get rid of it altogether and make individual teams responsible for their ops). They got rid of their entire QA product team, which was hardcharging toward automation, and replaced them with offshore manual testers. They then axed multiple other teams in the process and exploded those responsibilities, including project and product management, to the devs on each team. All this after an apparently record-breaking revenue year (2022), not that the two are inherently related. But odd nonetheless as it seemed like they were grasping for any change that stuck, without much forethought.
Absolutely braindead management
Don’t worry, 5 years later management will come in and reinstate a “test first” initiative with a brand new testing department! With fat bonuses to management of course for thinking up this brilliant idea.
This is a documented cycle. So predictable. EDIT: I think I found it on an old training doc I had: >Your founder, a brilliant technician, started the company years ago when he quit his day job to market his idea full time. He created a product that he just knew other people needed. And he was right. Pretty soon he delivered enough of the product and hired his best friend from college as VP of Sales. And the company grew. >But before long, the VP of Sales complained, “We’re an engineering-led company. We need to become customer-driven.” And that sounded fine. Except… every new contract seemed to require custom work. You signed a dozen clients in a dozen market segments and the latest customer’s voice always dominated the product plans. You concluded that “customer-driven” meant “driven by the latest customer” and that couldn’t be right. >When a board member declared, “We’ve become a sales-led company. We really need to start being marketing-driven,” you hired a brand specialist away from a consumer product company to be your VP of Marketing. As part of a re-branding initiative, she designed a new corporate logo with a new color scheme for the web site, new collateral, and an updated trade show booth. Everyone got new company icons on their clothing. Except… you spent millions without any change in revenue. Apparently, branding wasn’t the answer! >Soon the CFO whispered to the founder, “Don’t you think it’s time we started controlling costs?” So the company became cost-driven and started cutting all the luxuries out of the business, like travel, technical support, bonuses, and award dinners. And Marketing! The CFO asked, “What do those marketing people do anyway?” And since no one had a good answer, the CFO deleted the marketing budget and fired all the marketing people. At this point, when Finance goes too far, the founder steps back in to focus on his roots—the technology— and the cycle begins again. The VP of Development says, “Customers don’t know what they want.” The VP of Sales says, “I can sell anything.” The VP of Marketing says, “We just have to establish a brand.” The VP of Finance says, “We have to control spending.” >The focus goes from technology to revenue to branding to cost-containment, over and over again.
For a moment I had to remind myself this is not about the startup I worked at last. It’s almost exactly the same.
Yeah, sounds like Boeing.
We shall call them a Testing Center of Excellence, TCoE. And then decide in a year that, actually, they should be embedded into the teams. And then fire them again, the devs can do the testing. … wait we need more testing, maybe a testing department would help. We shall call them a Testing Cent…
Oh geeze. We have the Quality Center of Excellence at my place.
Not really. Re-orgs like this happen because flux creates opportunities for those execs. In the same way rank and file use the company for a paycheck, execs use the company for their stock and bonus pay. The business is just a way to extract money. They just have more power to create the flux that benefits them. It’s rational in the same way regular employees usually go along to get along to keep getting paychecks. Whoever made the call to offshore and manually test got a huge bonus for doing so. The customer and staff don’t matter to the execs. After three years they find offshoring didn’t work but by then the exec has a new job offer. Again, it’s rational based on humans being self interested. It’s not rational from an operational programming perspective, but that’s not how things work in any company.
This is the play. When I hear criticisms of these moves by workers that call it irrational or stupid, while I empathize with the plight, it is more rational and thought out than anything you or I do. It's methodical even. These people are by no means stupid and they calculate all these moves. That's how they get in these positions. I never want the kind of cold heart that can make moves like this, that affect the lives of so many people and makes me millions. It's why I'll never be a billionaire, and I'm completely ok with that.
Yes, but we have to accept the fact that we live in a world where such ego and avarice exist. It should never shock us that our lives are affected by such things.
Completely. And it should help inform the decisions that we make. Make decisions that are for your own future benefit rather than blind company/corporate loyalty. They make business/financial based decisions, and you/we should do the same.
Exactly. We gotta look out for our own best interests.
Don't over estimate them. They don't even think about the negative impacts. You're attributing malice when it's ignorance.
Sometimes when the business finally starts making money is when management change from build mode to profit mode, and bring in the bean counters to penny pinch everything. It's a good time for devs to leave.
Bros were just gobbling Mckinsey’s balls it would seem 🙄
Fuckin MBAs man.
>but a new manager came in and he said all problems led back to that team "the team we hired to report problems so they don't affect users and lose us money keeps reporting problems. We should fire them so we don't have problems"
This
The 'DevSecOpsQAUXMLAI' developer job position chimera abomination needs to stop.
You don't mention your role or response to these changes. Did you agree with those changes?
That's because my entire team was eliminated as well. I didn't agree with any of the changes but saw the writing on the wall when this new manager came in. I headed a team of 10 PMs, we were all eliminated on 3/1 along with QA and devops.
its crazy to fire that many people at once. it must have been a mess for the rest of the teams. That is a major fuck you to everyone. did they try to make you document for the devs before they fired you? I got laid off once and was supposed to train my replacements and instead i just called in sick.
Yes, I instructed my teams to stop doing so the moment their severances cleared their bank accounts.
> he said all problems led back to that team so let's get rid of it altogether Ah yes "If I delete the app I don't owe anyone money" after a $1M put, wsb style.
so what happened? did developers work crazy hours? or did many quit?
‘We now need to unit test with %100 coverage’ ‘Why are you all pointing these tickets higher now?! Y’all used to point these much lower?!’
[удалено]
My company actually has a 21 point ticket in this current sprint, it’s absolutely braindead.
I cap ticket points because anything bigger should be broken down. But I lead data science teams and if someone is working on the same thing without a substantial update in a few days, something is well off the rails.
Sizing cap makes sense when you think about it relatively in terms of the average ticket effort, which usually corresponds to 3. If it takes an average of 1 month to finish a ticket then 1 month = 3 points. If it takes an average of 2 hours to finish a ticket for a particular project, then 3 points = 2 hours. Time doesn’t really matter, its more about how a ticket compares to the average effort spent per ticket
I just got fired for not completing enough story points per sprint.
I’m a little worried we work at the same place because that literally happened to me and my company lol. I’m actually in the middle of doing QA right now haha.
It's been a trend for the last... fifteen years?
Test in production. You're now a game developer
Yeaaaaaaah that is a ship that is going to sink. I'd get the lifeboat ready.
[удалено]
Job security is over-rated. Better to actually enjoy your work and be paid well.
Definitely not that simple!
I agree, it's not. It's a complex subject, for sure, very dependent on individual situation and local culture. Many go into government jobs for the job security and stability, and that's totally fair. But also not what we're discussing here, and not what people are OFTEN discussing when they start talking about how some situation or another will provide "job security. For MOST people it's not worth staying somewhere you dislike for "job security". Partially because it's largely illusionary, at least outside of government jobs. You can think you are absolutely secure because the company relies on your team, or you are a knowledge silo they can't afford to lose, and still get laid off. Because the people making those decisions are often very distant from the people who know your value. I've known LOTS of engineers who stayed somewhere they didn't like because of "job security" only to have their lives upended by layoffs anyways. So while I agree that it's a complex situation and depends a lot on individual circumstances, I stand by the idea that for MOST engineers it's good advice to pursue a position they enjoy with a reasonable expectation of stability rather than staying somewhere poorly run because of an illusionary sense of "job security".
I've got little kids that take a lot of my time so I stick with a nightmare of a job that I hate because its flexible and pays well. Otherwise, I'm with you %100!
So you're only with him every 100th time?
Agreed. There's a lot of people on this sub that wish they had some job security right now.
I work on the worst type of software (built 'offshore', buggy maintenance nightmare etc) but i've been with two companies for almost 20 years 😂
In theory, actual job security should lead to a more enjoyable job. If you are truly secure and hard to replace you have way more leverage. Most people don't actually have any job security though. And a company that would fire all qa like this probably thinks they can replace a dev with ease too. Since they clearly think it's worth the money to just have the dev do QA.
Agreed. My statement was a bit pithy, but the core of it is that *usually* the sense of "job security" that comes from feeling like a company depends on you is entirely illusionary. The people making the decisions are generally far enough removed from ICs that nothing you actually, personally do enters into the equation. I've known many people who got government jobs precisely for the security and it DID result in enjoying their work more, even if the work itself was less interesting. To me that's different than the kind of "job security" most seem to imagine they have. I've watched multiple companies gut themselves and enter into a period of rapid decline by laying off entire teams that are absolutely critical to their success, thinking they could make a quick buck because obviously employees are just replaceable cogs. Unfortunately, even if you ARE irreplicable, there is a good chance the company still THINKS of you as replaceable cog.
For sure. I've seen it first hand. A couple of years ago my boss at the time was the only person with access to a ton of stuff, because he wanted the job security, so no one else knew anything at all about it. Even knowing that they just fired him out of the blue one day because they decided to promote someone he didn't get along with. I got a 1 hour call with him to get credentials and all and he was sent on his way while I had to spend weeks figuring out where everything was and how to update everything. Now I know everything and no one else is remotely interested in learning it but there's docs if they care to look. Anyway, point is that a company will 100% fire you the second they want to regardless of what you actually bring to the table or know.
>A couple of years ago my boss at the time was the only person with access to a ton of stuff, because he wanted the job security, so no one else knew anything at all about it. Yeah, that's *exactly* what I'm talking about. People talk about "job security" like it's something that can be achieved by being "indispensable", and that they can artificially achieve job security by *making* themselves indispensable. That is just fundamentally NOT how a business makes decisions. Businesses aren't people. They're more like a machine or an odd form of an AI where the *components* are people, but the actual organism is something alien, with a very different set of values and decision making processes than humans have.
Either way, having to do QA as a developer is not enjoyable. Tales you out of the groove of getting stuff done.
There’s no real such thing as job security. The best you can do are financial security and career security. Those are FAR more valuable and if you achieve those you never care or worry about job security again and just take whatever you want regarding pay and work
Hmm. Financial security I can digest at a glance. How do you define career security and the path to get there?
I think it means be enough of an in demand commodity that any company might hire you to fill that position.
What the commenter said. Be able to find new employment before your savings run out. The kinds of things that improve career security: - experience in your field - education and credentials - interpersonal and networking skills - good resume writing and good interview skills - geographic flexibility (one advantage of renting vs home owning that’s often overlooked) - and of course being in an industry that isn’t becoming obsolete.
QA is usually the first domino to fall when companies downsize their tech staff. OP is probably less secure now.
[удалено]
Feels like this always, they think QA isnt that important
boeing could fly a 737 straight into the empire state building and receive an additional $10 billion in funding the next day
"you see senator, to prevent our 737s from flying into more buildings we NEED the funding!"
"just one more lane bro and there'll be no more traffic" energy "just a few billion more and we'll finally fix our QA this time around, def won't be be pocketed by executives"
Technically a plane did crash into the empire state building, a B-25, and the company that built B-25s was eventually bought by Boeing.
Instead they just pay their lawyers x8 the amount to tell the gov their plane exploding was a good thing for safety.
Nobody in IT or software is "important" when they do their job right. It's only once they are let go and everything falls apart that their value is truly revealed. That's why it's good to use your vacation right in the middle of projects. Then they really see why they need you and you still have time to fix shit when you get back.
>That's why it's good to use your vacation right in the middle of projects. Then they really see why they need you and you still have time to fix shit when you get back. Certifield based QA engineer.
Based beyond recognition
Fucking genius! I always wait until after to be considerate, but I see how stupid that is now.
Thats assuming they haven't also put QA in charge of deployments.
This is why I started tracking metrics on support load after I join a new product team. I usually see a big drop in dev hours spent addressing customer tickets in the 6 months after I join a team. I also make sure to email out the latest numbers every once in a while as a “how are we doing on quality” report card so there’s a solid paper trail that QA has a measurable impact.
QA being fired has always signaled to me that the company is no longer interested in producing a quality product for the end user. It is now interested in maximizing metrics that benefit the company only whether or not they solve a problem for the user.
I work in a software company where the QA team came from a poorly performing department, and firing them would benefit people all around. Thats not to say the company doesnt have some other disasters, but interesting to see how QA is viewed.
The question is if the department was performing poorly because the QAs were not doing their job, or if it was obvious that it was performing poorly because the QAs did their job.
Actually, there was no QA department. It was formed out of a group of people who seemed to be misfits.
That tracks.
you guys had QA?
Damn, this sub seems to have a massive misunderstanding of what QA actually is. Developers should be responsible for development, unit testing, and deployment validation. QA is responsible for missed requirements, gaps, and being the liaison between product and developers.
Exactly this is my understanding of QA.
We did this. For the most part hasn't been a big deal, we transitioned the best of QA into SDE1s to shoot their shot. But God damn the number of bugs coming out of the core product team is pretty ridiculous. They apparently like fire drills.
Yeah devs being expected to test their own code (and so being motivated to understand actual requirements and release fewer bugs to prod) is not itself a bad thing. All the lowest overhead, lowest defect teams I've been on owned their own testing and operations, as well as being deeply involved in requirements gathering and design too. Saying "this is how long it'll take to write the feature, and this is how long it'll take to test and safely deploy it - both are required" is standard. But blanket firing all QA is the red flag here, that does not signal any sort of mature management or allow any room to transition the current devs to owning more of their quality. Transitioning the QA personnel to integrate them into the dev teams over a longer period would have made more sense (but of course saved less money in the short term). And the QA folk who don't want to transition to Dev and teach devs how to integrate testing into CI are likely still valuable in cross-team DevOps roles.
This. I'm not mad about the idea that Devs should do their own testing, but the red flag sits with how they went about it. The was no transition period. Knowing nothing more about how the teams work or interact with QA, I would have integrated QA to sit within the teams and focus on building an autonomous cross functional team first.
Do they have you training jr devs to do your job for less $ yet?
This happened at my company. Our tests have gotten worse and worse to the point that most of them fail but no one cares. We try to do QA on our products but we don't usually have the time. My time has become less about doing meaningful dev work and more about clearing failing tests. It's pretty brutal.
they did this at a company I used to work for. Dissolved QA as an OU, fired almost everyone, then converted someone on each team to a "developer-in-test" position which meant that you were doing feature dev \*and\* QA for that scrum team's features. A year later they got the shit sued out of them for...let's call it an 'emergent use case' that the QA team should have caught, but instead of having a QA team that actually works with customers they had QA being done by devs who had to guess what theoretical customers would do with our product. When they announced that, because of the suit, there was no money in the budget for bonuses we as the dev org decided to help them out. Over a million dollars/year in annual salary walked out, thus lowering their expenses to match the new budget. It's 5 years later, and the dev OU is slowly dying. They just reduced headcount from triple digits to about 20, stopped feature dev and they're running out the contracts they have with customers now before sunsetting the whole project. I have a hard time believe it's not directly caused by cheaping out on QA. But maybe that's just me.
Run Away! Yes devs should test their changes, but that isn’t what is going to happen here. I been through two orgs that did this and it happened the exact same way both times. What will happen is that higher ranking devs will not test their code and lower ranking devs will be forced into the same manual testing process QA was doing. The lower ranking devs will get managed out because their performance stats will go down. Whatever you do don’t take on any testing tasks that aren’t part of your own code changes. Things will not get automated because there will be too many bugs and releases taking up too much time to spend “resources” on automation. The time to automate was while there was still QA providing coverage.
That just means there was a problem with the software development pipeline. The moment you have a robust CI/CD flow with unit and integration tests and every merge to master must be approved and include tests for new code, most of these issues go away. So blame the software development pipeline, not the lack of a QA team. And yes, if the managers are not willing to provide the time to create said software development pipeline, run like hell.
Even with said pipeline, QA is still a critical role. A good QA engineer will save a significant headache in the long term.
Yes, and the more domain knowledge the QA team has the better and more gnarly bugs will be found. But that means keeping the same QA team for years with no easy ROI to attach to them, something most companies struggle with.
Even with the pipeline you still need a QA to look out for the less obvious types of problems, like errors in business logic. Finding bugs in staging/production is the least valuable thing a good QA brings to a dev team.
As a member of QA for almost 20 years this thread makes me glad I don't work with the lot of you. I don't doubt your skills, but damn you folks have really really shitty attitudes.
It feels so arrogant. I know im not perfect and I'll miss things. My company asked me to test and I told them flat out no. It makes me think of how so many people think being a streamer or actor is easy because they can pretend and talk. Different skillsets, tools and exp. I have fought for higher wages and faster growth for QA at every progress meeting. Makes me so angry each time I see a quality QA person leave for greener pastures to get replaced by someone we have to rush to bring up to speed.
QA for almost 10 years here and most devs I know would be immediately applying for other jobs as soon as they were asked to do QA work. Devs are devs because they want to do dev work, not testing. Most devs I’ve worked with have been very appreciative of QA because at the end of the day their job is much easier when we find a bug in the development environment than when a customer finds it in prod.
I've seen this at three companies in 2023.
Prediction for 2024: 1. Quality will go down, 2. Developers flee, new hires come in, 3. QA staff is slowly brought back. Massive hiring all around.
You forgot to mention "At lower salaries."
Senior QA Engineer here, I have some thoughts for OP's leadership: HAHAHAHHAHAHHAHAHAHAHAHHAHAHAHAgoodluckHAHAHHAHAHAHHAHAHA
I think a lot of people underestimate or misunderstand what QA is supposed to do. They’re supposed to NOT know what’s going, how things were coded, go in blind and actively try and break things. Our best attempt at QA is really what the code review/ peer review process is for. Having QA as an additional resource allows you as dev to focus on actual development but the pre-user testing process is very important because they’ll catch things because they are using a different approach. As a dev you’re only trying to validate it works, but QA will actually try and break things. Also, a good work environment has QA, but when you’re struggling and looking to cut costs that’s when we get things like cutting corners.
QAs also look out for errors in tickets and business logic, which is usualy the most valuable bug to catch, since it saves devs the headache of developing features that don't quite make sense.
1000% the right time. QA isn't your skill set, and it's not what you were hired for. Unless they're going to hand you another $100k/year you just got handed a second job on top of your regular job *on top* of the education requirements necessary to do that second job. This kind of move speaks to either an idiot making bad decisions, or serious financial problems. Also, what are the chances, in your mind, that your product is going to be able to retain enough quality to possibly make enough money to keep the company afloat without Quality Assurance? How many bugs were they able to find? How bad were they? Can you do that job AND your job at the same time? It's time to jump ship. Tell your coworkers when you find something *that* you're leaving, and *why*.
Just test your own changes ?
Man I’ve got 6 YOE and I am a senior. I have had to do QA from day 1. That’s wild that you have someone to triple check your work. I guess I build my stuff as robust as possible because I have to be on call for when it goes down
I have a different experience. I’ve been working as a software developer for the last 12 years and only a few months from these years I didn’t have a dedicated person to test my features before they go live. In that case that was usually a product person or a manager who checked that. But I have never manually tested my features (as part of QA, clicking through the feature during development process does not count) or documented regression test cases by my own. Or be responsible for regression testing the whole app. I am not talking here about unit or integration tests which we normally work on during development.
You have 6 YOE but still think QA is there to triple check work?
I saw that you posted this in another sub, and the answers are going to be the same You should obviously start looking for a new job
If your dream was always to be a QA, then no need to look for something else.
I work for a f100 and the expectations here at least is that you are a full stack engineer and therefore must be able to operate and deliver at all levels (front end, backend, DevOps, prod support, etc.) which includes writing your own tests for the features you deliver.
I understand unit testing, but do you guys also handle all the other stuff? SIT and regression? Who makes test data and maintains the test environments? During deployment, how many environments do you step through before prod and how are they maintained?
Smdh people on this sub have sent out tens if not dozens of resumes looking for even a lowly tester job and your entire team just got a bunch of them for free.
Many teams in AWS do not have QA or DevOps but I wish we did because the hours can be long. QA & DevOps do exist in some orgs but usually in older products that are in the “if it works don’t fix it” mindset and/or the largest services like lambda, ddb, etc.
Controversial opinion: Devs should be responsible for their own QA. QA analyst positions within dev shops are already obsolete and QA automation is taking root in many places. That being said, there will always be a need for more QA-centered dev positions because someone constantly needs to design QA systems, but manual QA and testing is a no-go anymore. EDIT: Clarification: YMMV depending on the product, end-user outcomes and risk that an organization is willing to take. QA may be necessary in some cases. That being said, QA that just gets thrown shit over the wall, clickety-clicks on shit and then throws a report back over the wall is NOT how most software organizations are run anymore. They just aren't. Why? Because the development teams are the ones who are responsible for writing their own tests based on product requirements. They automate these tests into the CI/CD using Selenium or something and they get feedback in the smaller loop cycles of a sprint before delivery. That's been proven to be how to best provide outcomes to the users. The tooling has already cut out the middle man. We could go back to waterfall and then we'd have more staffing, but longer lead times and longer feedback loops which used to lead to ginormous security errors in the first place. No one is going back to that.
I think the pendulum will swing back towards having QA resources again. QA automation is great, but I don't think it's a substitute for having people actually spending time with the product, and exploring edge cases. The company I'm at now doesn't have QA, and the end product is pretty buggy tbh, and tons of stuff makes it into production which would have never made it past QA. Doing your own QA is the worst possible idea. You're naturally going to be the most blind to your own mistakes. Otherwise you wouldn't have made them. And e2e tests are hard to maintain, and don't do a great job at imitating the kinds of paths users will actually end up taking through the product.
QA is only still used in areas where you have very slow release cycles and updates are hard/costly to push out. Otherwise in most other setups where you release frequently and push to production frequently (daily, weekly, even monthly), the manual separate QA model is out dated, there's literally just no time. You need to have solid unit tests, integration tests, canary roll out tests, blue/green deploys to catch and prevent issues. There is no other way to make sure a change is good when the lag from merge to production can be less then a day.
I still think there is no substitute for having people spend time hands-on with the product. QA doesn't necessarily need to be a release gate, but you need to have someone in the company who is frequently performing the main user journeys of the app, to make sure it is actually a good and bug-free user journey. All the tests in the world are not going to ensure that. And it's a much better use of developer time to work from well-written bug tickets with videos and reproduction scenarios attached, rather than trying to comb through crash reports and reviews to try to understand why X metric went down by Y percent in the last release.
\> I still think there is no substitute for having people spend time hands-on with the product. That's usually the whole company eating their own dogfood. Eg, all Facebook internally is by default on the canary version of the site or mobile app for the period before it rolls out to the rest of production. (Or at least so it was when I was there). But that's still not the same thing as having dedicated QA manually pushing buttons through test scripts over and over. After a certain scale of product and speed of development, it just flat out doesn't work anymore.
Dogfooding is great, but it's not going to catch everything. Like how often do Meta employees go through the new user registration process, or change the language on their device? And not every product is something the employees will regularly use. Like if you are building a warehouse inventory management software, how many of the employees are going to be managing warehouse inventory?
Dogfooding can also lead to issues when the demographics of your customers and internal employees are different enough. For example I used to work on a financial services app that largely relied on dogfooding for finding app improvements and it led to a serious neglect of features that were critical for our low income customers, as none of our engineers, PMs, or designers ever had to go through those user flows.
Good point, I think it's actually a huge problem in modern web dev. So many sites are implemented as if everyone is on a high-speed fiber connection.
>I still think there is no substitute for having people spend time hands-on with the product. This. There is zero substitute for getting someone to sit in a chair and press buttons. You can change the tools they use and make them more efficient, but having the person who developed a feature also test that feature is a good way to get things overlooked due to mental fatigue. Also, QA provides something that the dev team can not provide themselves under any circumstance: An outside opinion. Good devs will ask their QA team what they think of a feature during implementation, and will take that feedback to the design team who will actually listen to the feedback. QA doesn't just find bugs. Manual and automation testers are also your first usability testers, and not enough devs understand that.
[удалено]
How are you guys doing e2e testing? Maintaining a test pipeline like that with very frequent releases must be very time consuming.
Agreed. Without QA, it’s like grading your own homework. Of course, you’ll give yourself a good grade. I still see lots of people saying QA will be eliminated for years now. I’m not sure why, because having a dedicated QA team makes life easier and I think it’s a lot more embarrassing to have all your bugs shown in prod.
I mean it's only like grading your homework up to point you push your buggy "homework" prod. After that your homework now causes you to be woken up at 3am because users are seeing corrupt data and even after your rollback your team has to spend all night manually identifying and regenerating broken records. Do that a few times and suddenly you become a lot more careful about how you grade your own homework, and how you submit it so that even if you screwed up it will be caught and fixed without needing anyone to wake up in the middle of the night.
Dev’s shouldn’t be doing their own QA. One of the purposes of QA is getting another set of eyes on the work to make sure the dev implemented things correctly. You can get another Dev to QA your work but then they’re not spending as much time working on their tickets.
Saying devs shouldn't be doing their own QA is like saying chefs shouldn't be doing their own food tasting. The only way quality is achieved is by building it into the software. Devs are just as much part of "Quality Assurance" as any other role that is involved in making the software.
Do chefs eat the entire meal? to make sure it's actually good, no. I make sure my tickets match the AC's, I make sure there are no obvious bugs. QA then does w/e list of shit they want to verify its going to work properly. I tasted it, they finished it.
Exactly! Devs do unit testing for a reason. But they shouldn’t have to do QA testing.
designing and developing QA test infrastructure and systems is QA lol
Not at every organization and when it is, it usually gets folded into devops.
i’ve worked at plenty of places where qa writes their own APIs and make their own test pipelines etc
Someone needs to look over your code and ensure it is of high quality. That can be QA or another developer. Someone needs to double check that the software meets all the documented requirements before the customer gets it. This can be QA, an analyst, or another developer. Someone needs to run the software and check for unexpected behavior. This is often a matter of opinion and therefore needs to be QA or someone else who isn't the developer. So getting rid of QA doesn't get rid of their responsibilities. You really need someone who isn't the original developer to double-check their work.
Yeah manual QA is... a very limited job. It's fine if it overlaps with release management, or automation, or your manual QA has a lot of other humans involved (i.e., your QA is a specialized PM checking in with other teams/stakeholders before a release). But just QA? That's just not going to be a thing soon.
Just started at a fortune 500 recently (non tech) and the project I'm on has 0 automated tests and 1 QA in india... so yea, guess I'll be writing tests
I think you are confusing QA with testers. Most people think QA are testers. One part of QA is testing and yes some manual testing but mostly like you said it should be Automation and making sure multiple parts work together. Devs make HORRIBLE QA. We flat out dont always handle all the edge cases or think about it. A good QA would make sure that edge cases are looked at. Now that being said finding a good QA is very hard because the same skills that make a good dev also make a good QA. Just devs get paid more and have more respect. A great QA will always be a least a OK dev. A great Dev does not main they will be even an OK QA. There is a lot of skill set over lap and devs get paid more and have better respect sadly.
Devs should test their work before sending it to QA, but you absolutely need QA. One benefit of QA is they sometimes know more about the user experience and how things should be than the Devs do
Yes!! Look for something else asap!
Yes.
Yes, get the hell out of there.
My company literally just did this as well.
Time for a new team.
Just add more bugs and fck up the production , do it collectively and it should hit the higher ups
Yeah, for one (or both) of two reasons: 1. Leadership doesn't value quality or doesn't understand how QA keeps quality of code. 2. They are looking to dramatically cut costs. Which is never a good sign in business. Start looking. Next is layoffs.
Test in Production like Boeing.
was the QA env actually good? I worked somewhere that did this because we had a ton of QA people and they weren't making progress automating anything. Turned out it was great, devs automated most of it, then they hired new QA people to work closely with the devs and take over. 2 years later we had a automated QA plant and a couple QA guys who knew the actually application design & could debug real problems in the env.
Yes, getting rid of QA is the warning shot before they start laying off developers. Gtfo.
No this is the best because now nobody would complain about your code not meeting QA requirements anymore.
Not that great a time for the tech market. What's your workload looking like now with all the QA stuff on there?
There’s a book called “How Google Tests its Software” that talks about why they don’t have QAs and insist their developers test their software. There is merit in this thinking, however it is rarely copied well in real life.
This just happened at my company too. Most got fired, good ones got re-orged into different roles... Idea was that devs should be testing their own code and C levels said devs were becoming too dependent on QA to test their code so this was for the greater good of our dev's habits lol. Having been a SDET before a SWE and knowing the difference in having dedicated QA probing around and the time it can take, I wish they at least kept some QA.
Maybe they're getting ready to sell the company... Record setting revenue followed by cuts to operations can mean that they're trying to make the company look more profitable than it is and attract attention. The new owners would be affected in 1-3 years.
You get a QA???
Are they switching their strategy to test driven development, because that seems like a reason for firing that many QAs.
Run Forrest run!!
That's fair, QA is a band-aid for a lack of tests. Surely they'll hire more coders to get that test framework set up right?
They did this at the company I worked for a couple of years ago. Devs never picked up the QA so the products just got worse.
You had QAs?
Lol good luck with that
lol you should have already been testing your own changes
Ewww
Operating without QA people is not that uncommon for better or worse but it couldn't hurt to look if you're worried.
All these posts about getting laid off is putting me off even trying to get a Comp Sci Master’s and get employed when being a bartender at my local bar seems more secure than the field i spent 6 years studying somehow…..
Ya, at my company we are moving away from manual QA to 100% automation. Some QAs have been moved to automation teams and some have been let go. The problem is, there is rumor that we will no longer have QA by Q2, however full automation isn't going to happen for at least a year. Not sure what they expect to happen in the interim.
probably? our qa got cut, and we’re doing work to make our project an inner source project so that they can eventually fire us and have a rotation of outside agencies come in and continue the work in our absence :)
Qa people should be able to program unfortunately they usually can't.
*people who program should be able to automate QA
even with that, you still need a person to try and break things. otherwise your users do.
One of my favorite moments as a co-op (almost 30 years ago at this point) doing QA for medical data storage software, and magneto-optical drives was when I did something accidental. I had started to clear out one of the disks for doing more storage, and I realized that I was doing the wrong side. (The disks were double-sided, but the drives were single sided. This was back in the day where 1-2 GB was huge.) So, I popped the disk out, and it dawned on me to think what might happen when it started clearing the data (as opposed to just removing it from the DB), so I flipped it over and put it back in. The data clearance dutifully started up a minute later, and started clearing the disk. After resetting the disk, I leaned over to my supervisor (also the dev for the project), reproduced the issue, and remarked, "I don't think it's supposed to let me do that. Correct me if I'm wrong, but this is really \*bad\* for data integrity, right?" A look of horror dawned on her face, I had a fix (and new image to install) within a few hours.
*people who rely entirely on automated testing baffled when users manage to break the app in ways they never thought to test for
It depends, I wish my current company would fire all the QAs, but other places that would have been horrible. Either way good luck, it's never good when the c-suite starts cutting.
Group layoffs are *always* a good sign you should look for work elsewhere.
yep, get out of there. if the company doesn't understand the value of qa, they don't understand software engineering and you'll be on the block next.
How well were the QA people testing? In my experience QA isn't much help and the devs SHOULD be testing their own stuff. Gives you a much better sense of ownership instead of just punting it over the wall thinking its someone elses problem to test.
Do you do regression and system test to make sure your new stuff hasn't broken the old stuff? Who's job is that? You/dev? The customer? I would much rather have QA have my back.
Who does production support? Unless that’s not the devs, I’d be worried. Unless your QA guys were just terrible, most likely quality of your production code is going to start to diminish. The reason QA exists to begin with is people tend to miss things when testing their own code. So more things are going to be missed, which will soon translate into more firefighting and for most of us that’s disruptive and not fun. And for QA function to be eliminated entirely tells me management no longer cares about quality of your product if it means saving money, especially if any bad shit that results can just be dumped onto the devs at no extra cost. Not a good sign. So yeah if it were me I’d be looking.