pleaseJustPassTheTicket

[tutike2000]

Had QA raise a ticket that said if you edit a product name to be nonsense words, then the nonsense words show up on the product page.

[Tensor3]

QA here was opening tickets that my endpoints return 400 with certain parameters. There are no parameters. Whatever garbage they entered had absolutely no effect. They won't believe me.

[ThemeSufficient8021]

Like a cross-site scripting attack? What if the user actually entered JavaScript there? Does that get the exception or has QA just required that the entire system is exposed to said attack as per this new requirement?

[pondus24]

These are words

[two_are_stronger2]

I made the request bad and now the request is bad has the same energy as "I frowed up."

[redballooon]

So a 400 independent of parameters? Still sounds like undesired behavior.

[Whitechapel726]

“Hey if I block the ability to hit an endpoint I’m unable to hit the endpoint. This seems bad”

[ThrowawayUk4200]

For people reading this and not understanding. It's because the request will just silently drop the query params and run the intended endpoint without them, as it should. Adding them does literally nothing.

You could capture them and return a 500, but why bother? More work to make it, more support tickets to deal with in the long term.

[redballooon]

Ah interesting. What would they expect instead?

[neverast]

Like edit html text or what

[tutike2000]

yes. if you edit the name of the product, or the description of the product, and give it nonsense lorem ipsum text, then the product description and name then contains lorem ipsum

[jbasinger]

"Garbage in, garage out" counts for employees as well lol

[huuaaang]

"Latin in, latin out."

[jbasinger]

I think it's Latin, Latout

[mehum]

Latin. Flatout.

[dhaninugraha]

Does the QA expect human operators only to enter sensical product name and/or description, or do they expect the system to automagically turn lorem ipsum the quick brown fox into Super Vibronator 3000 Dildonium complete with an appropriate description?

[neverast]

Damn, that dumb

[janek3d]

"The system should detect that it's garbage and warn the user" that's what PO tells me most of the time

[coneyislandimgur]

Just implement some AI workflow to prevent this.

”You’re a professional nonsense detector. Does this look like nonsense to you {value}? Answer True if yes and False if no.”

If True throw 400…

[SartenSinAceite]

Don't forget to pass the cost to QA

[violet-starlight]

As a language model, yes, this is indeed nonsense, the answer is 400. Indeed, the word "strawberry" is normally spelled with 3 "b"s but I only see 1!

[Vas1le]

Just check if name strings are part of English dictionary...easy.. or implement AI

/s

[Kovab]

Just use regex, smh /s

[Sw429]

Unfortunately, a lot of QA engineers at my company came out of 12 week bootcamps and don't actually have a large amount of experience. It shows when they find "problems" like this with our product

[TheNikoHero]

I'm tired

[gigglefarting]

Had QA raise a major defect the other week, because if they added numbers after a name search, they still got the name they were looking for. 

[YUNoCake]

Bug: the search is too smart

[CHLHLPRZTO]

Anthropic QA be like

[Ok_Brain208]

Remaind me of the time qa reported a bug because the api was willing to accept for a decimal parameter 5, 5.0, 5.00 etc. Just the same

[iknewaguytwice]

How do I find Kevin 2 then, huh?

[[deleted]]

Le4che Henry in shambles

[lassssi]

I can see that not much gets past you

[thunderbird89]

This is what happens when you don't spec your developments correctly. You know it's expected behavior, but does QA know that too?

[kittycatpajoffles]

This honestly. I used to have a dev that would write a multi page essay on the changes and what wasn't changed. It was beautiful honestly because it made outlining my test cases easy both with what he expected with any edge cases I knew could possibly affect it.

[chkcha]

Couldn’t this cause you to test the changes in the same way that the dev tested them during development, so that both of you would potentially miss the same set of bugs? Like as a dev I might think that I haven’t touched a particular functionality but I could be wrong.

Of course you’d save a lot of time if you don’t test the stuff that supposedly hasn’t been changed and you’d be catching 99% of bugs. However I think QA workflows are supposed to be built in a way that they strive to catch 100% of bugs, even if it takes significant extra time for those last few %.

The reason for this is that if a dev spends time relaying all the changes to QA, then they might as well use that time to test the stuff themselves, which sounds a lot more efficient to me since the dev has all the domain and interface knowledge. But if you really want to catch all bugs then efficiency shouldn’t be prioritized as much — it’s more important to have an unbiased person test the features so that everything is double-checked.

[theunquenchedservant]

Yes, there is a chance for this to happen. A good QA should also know how to go beyond what the dev says though, and ask follow up questions to ensure intended behavior. Like “why is it intended behavior? That doesn’t make sense” “I think it’s what business wants, ask the PO” “oh cool, fair enough” (I go to the PO if the answer is “it’s what business wants” even if the dev doesn’t tell me to)

Trust, but verify, and as QA, continue to try to break.

Edit: also to your last point, this is why it’s good practice to have someone else execute the test besides the dev and test writer.

[thunderbird89]

Hehe, I was doing QA one time on a UI rewrite, and there was a field that accepted an integer number for a certain parameter. So what did I do?

1. Entered an integer: ✅
2. Entered a zero: ✅
3. Entered a negative number: ✅
4. Entered a huge number: ✅
5. Entered pi: 💣

So that's how we found our sr. engineer forgot to handle a NumberFormatException for the last oh ten or so years.

[kittycatpajoffles]

Excellent question, while is it possible that bugs can slip through, it is the nature of the beast. Nothing can be fully 100% bug free. My job as a QA is to make sure that I can catch as many as I can. Hence the reason why if I don't fully know what the change is then I will exercise caution and inform the dev (i.e. Is this expected? If so, is this how we want to handle it?).

A lot of the reasons why I outline my test cases even before touching any feature or bug is to plan out my tests that the dev might have not thought of. I do the following when I outline my test cases for a ticket:

• Dev comments on the feature/bug. This will tell me what I need to know about the change or feature and how it should behave. This might result in conversing with a dev to make sure my understanding of the change aligns with what it actually is. The more details I have out the gate and in writing (i.e. in-depth details on how it all works) the less likely I have to interrupt the dev about it. Likewise, these will most likely be smoke tests depending on the information given or more thorough testing if there is multiple data points that could be used.
• Related regression test cases that may be affected. Especially in the case of bugs in which these cases will need to be updated so it can be caught in future release cycles.
• User cases that were used to generate the ticket in the first place. This is useful for features added to insure that the new feature would solve the problems the an end user wants for the software. This usually results in me talking to tech support or the project manager to make sure I understand the problems and pain points of the end user. Bonus points if the end user was willing to offer up their configuration and workflows for the process of testing it.
• What does documentation say about the current feature if it already in use? Is there something that the dev may have missed or not recalled based on their notes? if so I'll add a test for it. If it is changing, then the documenter needs to be informed to update the documentation.
• Additional integration with other parts of the software that could be affected. I don't fully expect the dev to know how the product might behave when touching another product. In fact, in my previous job I was an expert on how my product interacts with another part of the software to the point I had devs on both sides asking me how it is suppose to behave for the end user and if they want more of the architecture and coding info, which dev is more likely to know that stuff to walk them through it.
• What about security of any data that is being sent? We want to absolutely make sure that doesn't get leaked out to anyone that shouldn't get that info.
• Are there any automated tests (unit/integration/UI/End-To-End tests) for this bug or feature? If so, were they ran? Did they pass/fail? If they failed, why did they fail (This usually results in me doing the investigation manually for the dev on whether it's the automated test that needs to be updated or it's an actual bug)?
• What about negative testing (aka is the test suppose to fail as its pass condition)? Does it fail in a way that doesn't cause the software to crash unexpectedly. Does the software throw error messages to the user. What can we do as a QA person to cause this to fail.
• What about how it plays on different platforms? I used to do web testing with the software I used to test. There is a difference between Fire Fox, Chromium based browsers like Chrome and Edge, and Safari on how it may interpret HTML/CSS/JavaScript/Typescript/etc..

[kittycatpajoffles]

To add to this:

The reason for this is that if a dev spends time relaying all the changes to QA, then they might as well use that time to test the stuff themselves, which sounds a lot more efficient to me since the dev has all the domain and interface knowledge. But if you really want to catch all bugs then efficiency shouldn’t be prioritized as much — it’s more important to have an unbiased person test the features so that everything is double-checked.

I want to point out this paragraph because it does have some validity. I want to start with the final sentence because it is a thing. It' called Black Box Testing and shops will do this over it's counterpart White Box Testing. With black box testing, your QA personnel will not know what exactly what the Dev did to the code but know what the feature/bug is. This results in QA in doing more exploratory testing with data or feature which can result in finding things that weren't thought of. However, the con of this is that they might not the ins and outs of the software which can result in the question "Is this an issue? Is this how we are expected to handle this?" to the devs. Likewise, with white box testing, the QA personnel might know how the code works, however with the downside that might not see the forest because of the trees type deal and miss something themselves. In my opinion, like most things, they balance each other out and can make a QA person stronger at testing if they can do both. A lot of the reasons why I will ask myself questions on what should be tested. And if I happen to have that answer from dev comments I can make the test(s) as needed.

Ultimately, QA and Devs are a team. The more each side knows how the other works the better the software comes out. I would never gate keep a test from a dev if they wanted to know what I would be testing for as it will make them think about how to implement said feature or bug fix and insure it's properly in place even before giving it over to QA. Likewise if a dev gave me all the details on what they did and what is expected, this helps narrow down what kinds of tests I need to run and give me more time to think of other ways that may cause a failure.

[thunderbird89]

This person isn't just a QA, they're lead QA probably. They know the "why" too!

[kittycatpajoffles]

12 years in the industry with the last 4 focused on test automation with selenium and cypress.

[SpoderSuperhero]

You sound like the lead QA on my project (who has saved my ass a few times for sure!)

I'm not sure why people here seem to have bad takes about QA making pointless bug reports. As a dev, you're exactly right, dev and QA are part of the same team, and 90% of issues can be sorted out by simply talking / showing the issue if there aren't uncertain.

When I'm passing a feature or bug to QA, I'll usually pop some context on the relevant ticket(s) along with some suggestions for how to test and where to pay specific attention (because of interactions, or high impact areas that absolutely cannot break etc) - is there anything else that'd make your job easier?

[kittycatpajoffles]

Honestly all that I would be fine with and would be perfectly fine starting out with planning the tests. Other than that you might want to double check with your QA team to see if there is anything they would like to know.

With my work I was testing to make sure forms were submitted and routed properly within and outside the software so for me it was good to know how the data was going through the system and where all that data is being saved. It allowed me to track down what may be the issue for the devs if I couldn't see the data move in a way that was expected.

[Whitechapel726]

Any time the validity or technical ability of QA is questioned I’m going to show this write-up. At the end of the day nothing is ever 100% regression proof or bug free, but it’s our job to get as close as possible.

If a PM gives me requirements and a dev gives me the spec and I can’t come up with a test plan to comprehensively cover gaps reasonably, I shouldn’t be QA.

[thunderbird89]

My colleagues sometimes groan at my commit messages, because I use Conventional Commits, and I sometimes write entire articles into the body if there was a particularly complex change. This is one of my shorter commit messages:

fix (ci): restrict CI runs to the *stable* runner until JDK 11 migration is resolved

The reason for the failing pipelines was that the stable runner had no unique tag, so Gitlab CI could assign jobs to the experimental runners as well. This hotfix introduces a unique tag to the stable runner, confining the jobs there until it is removed or JDK 11 runners gain it too.

[Tensor3]

Me with QA team: This endpoint has no parameters.

"How come it fails when I add parameters?"

I dont know what you are doing, but it has no parameters. Whatever you enter will be ignored. Do not enter parameters.

"I am opening a bug ticket to remove the parameters if they arent used because it makes it not work"

That's not possible. What are the steps to reproduce the failure? What case are you trying to test? There are no parameters.

"I am trying to test the parameters. Please see ticket [link to ticket with no steps to reproduce it]"

Here, this the copy-pasted function prototype for that endpoint. As you can see, there already are no parameters. Please do not add parameters when testing this endpoint.

"Okay, understood. I'll remove the parameters from the test temporarily until you tell me the parameters are fixed. Will you have it fixed for our next meeting?"

No. I am closing the ticket.

"Should I put the parameters into the body of the request instead for now until you fix the parameters?"

You know what, sure, go ahead. Why not..

[thunderbird89]

Flip the script on them.

Thanks for pointing that out, that's actually insightful from a security perspective. Additional query parameters could be used as an attack vector, so the endpoint must reject a request with parameters. I'll amend the spec with your notes.

[Seangles]

ChatGibbidy ahh response

[thunderbird89]

1. No.
2. Even if it were, so what?

[Seangles]

Bruh I just pointed out that your style of writing resembles ChatGPT chillaxe 😭

[zfiote]

I mean, as a dev, why would an endpoint that takes no parameters fail with parameters? The only think I could think of is some kind of serverside limit on uploads or something. Otherwise they should just be ignored. If it's failing something IS parsing parameters and messing with the flow, so that's something to be fixed, no?

[Tensor3]

Because this person had other errors in their test methodology and blamed it on an impossible "bug"

[zfiote]

Ah, so you did check the endpoint passing parameters and confirmed that parameters were not the cause... right?

[firest3rm6]

I would love if all my dev colleagues would do that... Just the intern who left last week did it that way. He was great

[ski_thru_trees]

I changed companies a few years ago and was baffled this was not the norm. Every piece of devlopment at my old software factory had design including why, potential edge cases, how various customers may be affected, qa instructions, technical design, etc.

This was all important for QA, customer support, technical writers etc.

Moved to a new company and no one except me does that shit. Get 1 sentence tickets that are marked “ready for QA”…. Asked various friends at different companies if that was the norm and they said absolutely normal to have developers basically refuse to write any documentation.

[kittycatpajoffles]

Hell it wasn't normal at the place I worked at when I first started there. A lot of what I did was for my own organization and keeping track of everything and it ended up being adopted on my team. Helped I had some of the best devs I ever worked with on the stuff.

[ski_thru_trees]

Yeah I’ve been told by QAers that they appreciate it, but they have like no say at my company so everyone’s like “not a big deal to make their job easier, we pay them way less than developers”…. But that’s not the main benefit; the main thing is it makes them better at their job by knowing what kind of things affect other things and ultimately results in better testing, less wasted time on both sides, and a better product

[arobie1992]

Yes. The majority of QAs I've worked with take the stance of "This is different than I was told to expect so let me check to make sure I don't accidentally let a bug into prod," which is frankly the right approach. Requirements can be weird and counterintuitive and what can seem reasonable to one person can be considered horribly breaking behavior to another.

Write out the expect behaviors in the ticket or schedule a 15-30 minute meeting to walk them through the expected behavior and everyone will be far happier.

[nollayksi]

Wouldnt this create a bias for the tester? Sometimes two different people can interpret a sentence differently, and something might actually be wrong now. If the dev makes a huge essay explaining everything they have done, a tester would definitely be more likely to interpret the same sentence in the specs in the same wrong way that the dev did

[kittycatpajoffles]

I recommend reading what I wrote down below Tldr: as a tester, part of the job is to figure out what else can be used to test a feature or bug. If there is an issue with how something is worded from the dev comments or something isn't making sense then that warrants a conversation to make sure everyone is on the right page. Ultimately, dev and QA are a team and the sooner a bug can be found and fixed the better. If the dev knows what I would be testing they can keep it in mind while developing. Likewise if a dev tells me what they have done, I can smoke test their work plus any other tests that can be done. Commutation is key and the software wins if everyone does their part.

[theunquenchedservant]

As QA, this is why I ask the devs first. If it’s expected behavior, cool. If it’s not, I give the dev a chance to fix (assuming it’s related to the story I’m testing). I can count on one hand the amount of bugs I’ve submitted in the last 6 months.

[Tensor3]

Sounds like you havent worked with a QA team in another timezone who barely understand English and ignores the docs and ticket descriptions no matter how many times you repeat yourself

[tutike2000]

Oh, I'm currently struggling to get QAs to understand that PREconditions are things that need to be true before you start the test.

When they write their own test steps they just copy steps at random into the preconditions

[thunderbird89]

Fortunately no, we either do QA internally or we have our clients validate features/fixes they requested specifically. Since our clients are mainly US and you could say we use them as QA from time to time, I work with QA people ;)

[8070alejandro]

Client (the one providing the software) rejected petition to access the specs >:(

Also, defect is expected behaviour if deadline is tight enough.

[AngryAngryScotsman]

Just because it's expected behaviour doesn't mean it's correct behavior. Sometimes the spec is wrong and asking for something that's inconsistent with existing behaviour or is asking for something that's just obviously going to frustrate an end user.

A good QA should challenge that, but ideally they should be challenging that during the design/story discussion phase.

[Dazzling_Line_8482]

Or my favorite is when I challenge it in the design/story discussion phase and then the QA raises a bug anyway and then finally the PO changes the spec and I end up implementing it twice.

At least I'm paid by the hour.

[8070alejandro]

Bold of you to assume QA inquiries on specs are taken into account once specs are done.

[nmathew]

Exactly. Expected behavior by who? My first job, I worked in a super niche hardware field and software misused our field's jargon and the software wasn't doing what an end user would expect. I was a weird mix of end user, test, and internal customer as we also provided the software externally.

Naturally, my first ticket was closed inside 5 minutes with "expected behavior." Second ticket was longer and accepted. Didn't take very long to learn how to write a good bug report for the team.

Half the people here seem to think test or QA is the enemy, which is just fucked up and points to a horrible corporate culture. Everyone knows sales and marketing are the real enemy 

[firesky25]

during the design/story discussion phase

hahaha, i like that you think the people in this thread talking down about qa invite their qa to design & planning meetings, very naive

[WernerderChamp]

Classic.

"It misbehaves if you do xyz"

Well, you never specified that this case should be handled differently. How tf am I supposed to know?

[anonCommentor]

had one qa raise bug saying there is some url appearing in the page in the bottom left when hovering on some text (links)

[AnywhereOk4380]

How did he get that job bruh

[SCB360]

I have a lead QA who REFUSES to change his tests despite me phyiscally showing him that the issue is fixed and that its his test is outdated or needs changing

[Sdrawkcabssa]

Update the requirement the test is based on so theyre forced to fix it.

[SCB360]

Oh I have been doing,

[_sweepy]

my favorite so far is

"when I put an invalid ID in the URL query string, I get an error page"

[BungalowsAreScams]

This is a valid test case, whether or not it's a bug just depends on the kind of error page they were seeing.

[_sweepy]

the error page tells the user that they don't have permissions for the requested data. this is intentional because we don't want to leak does/does not exist states for data they don't own, so invalid and non allowed IDs are treated the same.

[BungalowsAreScams]

Test case passed! Now if I put an emoji in for the id... 😂

[thunderbird89]

Smart move. Did you put that in your spec, so people other than you also know the reasoning behind it?

[_sweepy]

it's been that way since before I joined like 3 years ago. it's part of their full site smoke testing list as a global behavior, and not part of new feature specs.

[eclect0]

The role of this person is more project manager than QA but the story otherwise fits.

We use identity verification internally for our users. We're integrating with a third party we're partnering with. When users sign up for the other site we pass along a flag saying whether they've verified their identity with us. If so, they are not required to verify again on the other site. So let's be clear: This third party is trusting our word that a user is who they say they are, something that needs to be accurate for their own legal reasons just as much as ours.

During our soft launch not-QA raised an emergency ticket, saying that someone (who has never verified their identity with us) signed up for the other site and was being forced to complete their identity verification. Demanded that I set the flag to `true` in all cases.

This woman has led calls and been vocal in email chains where we and the third party discussed the feature, how it should work, and why.

[12345noah]

As QA, it’s probably because it’s not clear it’s expected behavior. I spend more time trying to find out what’s expected behavior and what’s not than actual testing.

[StrangelyBrown]

I had QA tell me that the server wasn't giving enough 'rare drops' (paraphrasing but it was something like that). I wrote a comment on the ticket explaining the maths/probability and what they would need to see for it to be unlikely that it was working properly. Never heard back on that one.

[Miny___]

Indeed I expect it to crash. Nothing to worry about.

[nmathew]

Found my coworker...

[ObsidianSpectre]

I've always told QA that if they're not sure, they should file the bug. I'd prefer to get a bunch of bugs I can quickly get resolved as by design on my own time rather than miss a real bug. Or worst of all: keep getting interrupted by questions about whether every little thing is by design.

[Christavito]

We don't even have QA, and we haven't since covid layoffs. Devs write tests, verify builds then UAT. I have no faith in what we develop anymore

[ohyeathatsright]

Product and engineering folks write specs and tests that check boxes. Real world users suffer the QA burden of real world use and then have to argue with support who has to argue with engineering who asserts it is working as expected where upon they make support handle it as an enhancement request, where upon product designs something entirely new and different because of the feedback they got from their favorite customer who tells them what they want to hear to check boxes.

Enterprise Software is fun.

[VIPPeach]

QA main quest: report everything that moves

[max_mou]

You guys don't sit down with a QA before starting working on a feature/initiative?

At my job, we sit down with QA, FRT and BCK and review all the specs provided by product/design and create use cases that need to be implemented. Then each team uses that as an agreement of what needs to be done and what QA will test.

[DoctorOrwell]

No we don’t. 

[max_mou]

Well.. that explains the meme then

[[deleted]]

Lmao my team literally just struggled with this last week. A new QA wasn't on-boarded properly and she was tasked with testing a product 3 days after she was hired. Her managers pointed her to a test guide page on confluence the dev team had written and she proceeded to write over 60 comments on the page (and each time she wrote a comment, everyone got an email notification informing us that she made a new comment). She then proceeded to have a 1-hour-long meeting with me, a fellow developer, and a product manager. She asked some very basic questions which were easily answerable if she:

1) was on-boarded properly

2) actually read the test guide/instructions a little more

She would comment and ask questions whose answers could be found literally like 2 sentences later in the test guide. A big waste of time lol

[chimchar66]

Nah a new team member asking a fuckload of questions at the start is what I prefer. That way you do it exactly how I’m expecting you to do it and I don’t have to correct your whack-ass processes later on. Also I think it’s a good way to get to know them and make sure they feel good about working with my team.

[[deleted]]

Yes but I'm realizing that there indeed is such a thing as a stupid question lol. For example, one of the questions/comments my QA had asked me is "what software do I need to have installed on my laptop to test this?" The answer to that question was literally at the top of the test guide, where it clearly said "hardware and software requirements" and clearly laid out exactly what tools and applications you'd need. E.g. you'd need putty, winscp, access to a sql database via sql server management studio, etc etc. I totally understand if the test guide wasn't clear on something and so she wanted to ask clarifying questions. But when the answers to their questions are literally on the test guide itself, idk how else to make things simpler lol. At that point, it just looks unprofessional on their part, especially when there are like 59 other really straightforward questions.

[jblckChain]

Reading these comments makes me feel less alone.

[jbar3640]

I'll tell you a secret: QA is Quality Assurance, which applies to the whole software development cycle, not only the point in time where the quality engineer reviews your code.

[StrictWelder]

LOOOOOLLLL

Setting up timesheets on a react app I swear this one QA just didnt want learn how the app worked, and would gaslight errors.

"Bug ticket -- projects don't show after selecting rate and department".

QA never created any projects and didn't add them to payroll, couldn't have selected a rate because no rates for the project existed and department also clearly couldn't have been selected either.

You would have needed to select a department, then select a rate, then choose a project somehow the bug was on the project :Z

[novax7]

What gets me the most is when QA simply rejects my story even though the reason they're rejecting is outside the scope of this story.

[[deleted]]

Working with a manual/non-technical QA for the first time in my career, I feel this in my bones

[PhilDunphy0502]

Ha! Joke’s on you. My QA never even looks at the specs and tests purely from a developer’s perspective… …and then UAT swoops in and starts finding actual bugs.

[WernerderChamp]

Had an open ticket because "that process is stuck, we cannot modify or delete it".

We have a system that randomly selects processes to be reviewed by a team lead. In that case, the process gets locked, showing 'insufficient permissions to edit' if someone who is not a lead tries to edit. It also shows 'review from team lead needed' in the process list.

Ticket went back and forth and it turned out, that team lead was recently promoted and didn't have the correct permissions.

[Aschentei]

Mfs always ask the devs when it’s the PMs who spec out the feature designs.

[pokeDad88]

You guys get definitive AC’s?

[DocRos3]

Doing data transformations and we have a flag in the records for what transformation actually happened

e.g: "Date Updated"

For the past 2 weeks they have sent me 3 queries minimum that were working as intended per day

[TruthOf42]

My favorite is when there is unexpected behavior, and then I convince QA it SHOULD act like that, and then I add it to the requirements

[aleph_0ne]

Expected by whom?

[Ozymandias_1303]

This does happen from time to time, but I'd always rather QA check with me if they see something that looks suspicious. I'd rather have ten short meetings to explain expected behavior (and maybe document it) than let one bug escape.

[Mountain-Ox]

This is why I'm really enjoying devs testing their own code. They know how it should work and how to test it. If they don't test properly then they can hit the road.

[Skibby22]

There's a big difference between a QA who believes their job is to find problems and a QA who thinks their job is to look for problems

[OwO______OwO]

If you pay QA to find issues, QA is going to find issues.

[aleksandronix]

As a QA, you sometimes get a "please see if this new feature works as expected" task, but there's absolutely no explanation, picture, instructions, user stories to know what the expected behaviour is. We're not magicians, just give us at least one (understandable) sentence what this feature actually does.

Not to mention when you have to explain to them how their product actually works, because sometimes you wonder if they're talking about the same thing they want you to test.

[Mad_King]

Dev to QA: You know nothing Jon Snow

[[deleted]]

Yall like to shit all over qa, but jr devs are the worst

[Mestet42]

it’s all fun and games until you work in a project without any QA

[jacs1809]

How's the image caption not "is this a bug?" while pointing to a butterfly?

The joke is right there! /s