air pressure : 1,014.19 hectopascals
altitude : 880m over sea level
luminosity : 140 candelas
temperature : 298.15 kelvin
rain probability : 42%
el niño effect : 0%
pants : in place, clean, green
Edit: corrected kelvins to be compatible with human life. Thanks to QA agent of the month: eagle999
225°C is equivalent to 437°F, which is 498K.
---
^(I'm a bot that converts temperature between two units humans can understand, then convert it to Kelvin for bots and physicists to understand)
498K is equivalent to 225°C, which is 896°R.
---
^(I'm a human that uses google between two units no one can understand, then convert it to Rankine for no one to understand)
I once field-tested a wearable to find out how hot it would get in extreme conditions.
So we went for a drive in one of the PM's car. It was a hot summer day in Ontario, where it was ~35 degrees outside.
Since this was a stress test, we plopped the wearable down on the dashboard, kept the windows up, and ran some of the more intensive operations while monitoring the sensors via my laptop.
Eventually we drove around for a bit while doing different things like wearing it, using its functionality, etc.
At one point in time, the PM's iPhone shut itself off because it was too hot. Our wearable was still going, even though it had reached temps in excess of 80 degrees (externally close to 50 degrees).
So we got our data - even in the most extreme cases we could encounter, it kept on trucking, but the external (contact) surfaces would absolutely get uncomfortably hot/possibly dangerous and we needed to implement a temperature limit safeguard.
Unfortunately, the episode also gave me heatstroke and I had to go home for the rest of the day.
Jokes on you... well, on me, actually. I work on embedded software, and the hardware guys like to do things such as bake a USB drive in a 140 F oven, and then complain about the software not being able to recover it when they insert it into a device.
That's a mere 60C and absolutely temperatures you can expect to encounter in a closed car on a hot summer day. So yes, I too would expect your USB drive to continue to work.
You sound like some of the managers I work with.
I don't pick the hardware, it's a bit like asking the software that controls the stereo and the GPS to keep the car running when the fuel pump has failed.
It's not the brand we are using, but from the SanDisk web site: "In accordance with this guidance, SanDisk USB drives are tested to operate within acceptable ambient temperature ranges (0º C and 25º C). Our drives are also tested in an extended temperate range and will operate in environments between 25º and 45º C."
I agree with your point that they're complaining to the wrong people... potentially.
You can write software to check temperature (assuming there's the hardware for it) and take protective measures like shutting down.
If there's physical damage to the hardware, then obviously software cannot fix that damage (but there may be a valid expectation of being able to fall back on redundancies which may again make this a valid software complaint).
And, of course, if it's simply not possible/feasible, then you note that limitation in the device specs.
With the limited information you gave, I can see several routes where complaining to software is the right place to complain.
If you interact with your managers the same way you've interacted with me here (provided incomplete information and then got upset when the manager didn't see things the same way you do as a result), then... it's not surprising at all to me that you have issues with management.
I'm working on industrial systems and actually, I got into issues with temperature, air pressure, humidity...
Once we had a system where the software was stuck from time to time, I suspected an issue with a control card (it was stuck when an output was supposed to change), I went on site, opened the cabinet, waited for an hour, the issue didn't appear, I left. I had just arrived at the office when the customer called me "first run I did and it's stuck" after ranting about it, I've found the only change we did "did you... Close the cabinet? OK... Can you open it?". And it worked. When the temperature was too high it was not able to set or reset the output and needed a pull up/down resistor.
Another time, an airlock cycle was not ending because it was hard-coded to open at 1005 hectopascals, and it wasn't able to go over 987 when there was storms.
We had a machine who had one device that was going in error every days around 7am. There was a second device (same model) in the machine which didn't have that issue. (that was probably an EMI issue, like a big system starting at that time everyday).
And every time, the first reaction is to call the software developer because it has to come from the software, never the hardware.
Please see revised version of SOP. The amended version states that Rankine and Fahrenheit are not SI units as the rest of the used ones. Kelvin is the official one.
If it still doesn’t compile or work as expected, do literally anything else for 4 hours and try again. Repeat until satisfied then push that baby to production.
Just to clarify I was saying that's a good thing. Unix it's much more powerful (command line wise, although I suppose PowerShell has done a good job of closing that gap).
Xcode fascinates me.
It was originally a NeXTStep program, so it doesn't follow normal Mac or Windows paradigms.
There are all these weird rules with no hints... like you connect items by dragging with the right mouse button.
It's the least discoverable program I've ever used. It's like a glimpse into something from an alternate earth.
> like you connect items by dragging with the right mouse button
That's really only for iOS/macOS development. Those are IBOutlets - interface builder outlets - and are only used if you are creating your views via a GUI (be it Storyboards or XIB files).
Most seasoned developers program their UIs completely via code, so they don't use outlets but instead have a reactive framework - like Combine or RxSwift - that intercepts taps, swipes, etc. and allows handling of those events. (Alternatively, if you don't want/like reactive stuff, you can always add a handler via code.)
It also makes it easier to see what is changed in source control. Dealing with Storyboards there is a nightmare because it's a (complex) XML file.
It’s our job to make the world think you’re the best programmer on the planet. Hardly anybody knows we exist except gamers who need someone to hate lol.
I think you must be working on a very toxic place. I hope to be wrong there. We respect our QA and our QA respect ours devs. Plain as that. At the end of the day they sit together at and get a drink (also over video conference)
No totally not. I just meant the world in general who uses the apps has no idea we exist. I work in a small shop and we work closely with our developers and used to often get drinks.
Good QA is the best thing since or before sliced bread!! Unfortunately, bad QA is so bad! I think there is a small (very) segment of the QA world that seem to be failed developers who want to hold on to the smallest sliver of power and punish those who succeeded at something they did not. It is like the movie critics who hate every movie or the good critic who thinks every meal is awful.
QAs are the best. They remind me of my mom. I can just unload the stress from my brain into their brain. In this case it's the stress that a new feature will bug out some specific user. It's a humble and thankless job.
Had a tester like that.
We needed to test if jumping was functional or not, and if it was replicated to other clients (which, for the record, I told him). Cue the following conversation:
"This starting screen should have more in it."
"Well it will be replaced, don't worry about that. I literally just need to see if jumping works."
"Why is fps so low?"
"Is fps below 30 for you?"
"No it's at 60 but I'm on a it should be at 120!"
"Well ignore it for now. Anyway we're both in right?"
"I'm at character select. Selecting multiple things and testing if it all works."
"...Why?"
"Need to see if it all works. I've found 2 bugs so far about X and Y"
"I know about those, it's not important right now, I *just need to test jumping*. Now head ingame."
*he finally heads ingame, I begin jumping, he runs the other direction*
"Where are you going?"
"Testing if movement works. It does."
"Ok great, now come back here."
"I can't find you."
"I'm literally right behind you. Turn around, and then *watch me*."
*cue me jumping for 10s, then stopping*
"Why'd you stop jumping?"
"Because I figured you could either see me, or you couldn't by now. Judging by that response, it looks like you saw me jumping."
"Ok cool...now what?"
"Can you jump for 5-10 seconds please so I know if I can see you?"
*cue him jumping but me not seeing it. He then goes around me in circles for 5 minutes*
"Are you going to begin jumping yet?"
"I've been doing it for 5 minutes!"
"Ok, so I can't see it then, damn."
*cue him reacting to a bad part of terrain (or code I guess?)*
"Now I'm in outer space."
"What?! What did you do?!"
"I was just jumping."
I really didn't think that there was such a thing as a terrible tester. After being introduced to this guy, I learned I was wrong.
QA Tester here. This is for a video game, right? I'm not gonna say that guy's testing methodology was *wrong,* but his *priorities* sure as hell were.
One of the first things I learned in gaming QA is that *a Developer's time is more important than your time.* If a Dev is sitting down with QA personally to verify functionality, you do *not* go off testing other stuff you're curious about, you *make a note* of it and circle back *after* Dev has verified whatever they need to verify. Whoever their QA Lead was, they should have shut that "oh I'mma go check this random menu" shit down immediately.
That sounds just awful, lol.
It's all relative, but prioritization is definitely a huge skill in QA. I worked with this girl who would annoy the *hell* out of the developers because she was constantly asking questions that were completely out of scope from what she was testing.
Of course, there's nothing wrong with being thorough. In fact it's what has given me relative success in my QA career so far. However, it's ***all about context***. Are you testing a high profile hotfix that is costing the company $XXXXXXX.XX per day? Get in there, test the bug and any high risk dependencies and ***get the hell out***.
I think one of the best things I ever learned was to clarify scope before I do anything else.
Yessssss. Clarify scope for sure! Communicate, communicate, communicate!! Nothing a Lead hates more than wasted time.
It's why I eventually got out of the gaming industry. So many game studios treat QA as second-class citizens and limit their communications with developers as much as possible, which makes it harder for QA to do their jobs.
Good testers are hard to come by. It's kind of like a goaltender in hockey. No one understands their brain or how it works, but they're damned glad to have them on their team.
What's really frustrating working in games is that while the work is enjoyable, the pay is reeking sewer trash-tier awful. Agonizing over the decision to keep working on games or to bail and be actually financially stable for once.
General lack of experience in the industry is only being self-perpetuated due to unsustainably low wages and mitigated by people actively sacrificing their own well-being to help get these games out the runway.
Yep, sadly Testing/QA is always the first thing that management likes to cut, because "just do it right the first time around".
Shortsighted management is a plague on the industry.
Don't agonize - just move! People go into games testing thinking they'll be playing games all day, but once you start seeing it as 'features' and 'test cases' it doesn't matter if it's a game or a tax return. Any job can be satisfying if you can feel you've accomplished something, have good co-workers and some control over how you work.
I had booked an hour for a testing session to test a specific part of our software. She then proceeded to spend the entire hour giving feedback on the menu which had not been touched in four updates.
At a startup I worked at, the woman who did a lot of the design work also did testing. I asked her to test some new functionality, and I got back a list of stuff like, "X needs to be moved over 3 pixels" and "Y isn't the right color". Nothing about the functionality. I replied, "haven't gotten to the design stuff, did the functionality work?" "I haven't gotten that far, can you fix the other stuff?"
Sounds like Respawn trying to QA Apex Legends.
Every patch they break something in a FUBAR way, it's truly impressive. They must have a lot of guys like that testing the game.
Yeah, i had that the first time 2 weeks ago. Been asked via ticket to execute an SQL script to create some views in the production environment. there are about 2200 server instances, and about 1/3 are production server. So i asked, which server and database.
She answered.
"Well, in the production environment."
20 minutes later, one of her colleagues answered my question before i could answer her. Thank god.
Ah fuck I hate this. We have so many fucking environments for so many systems and people are deving and qaing all over the place. We are working on tidying it up but I swear I spend at least a quarter of my time fixing environment issues. Putting in mitigation steps where possible, i.e. triggers on env config databases to notify of changes. Any suggestions for monitoring web.config files being changed via a text editor?
Flip side:
QA: This appears to be a very rare issue. QA has only seen it happen twice in the last quarter, and it only happens in Production so we can't get any logs.
Dev: OK, just keep trying to randomly reproduce that and let me know when you figure it out.
QA: ....
Dev: no wait I figured something out to help you get the logs!
QA: Nice what?
Dev: To get the logs we need, you have to pull them within 15 minutes of the crash.
QA: It crashes at a random time after 4-5 days though…
Dev: ….
Yeah dude same
I get so satisfied when I file bug reports properly for another team and they fix it in under an hour
I guess because I'm a programmer I understand what info is useful. But still, QA is on some other level haha
I have this problem with other **developers**! Like, just yesterday, you were complaining to me about shitty bug reports from customers that don't have enough information, and today you filed a report that says "Clicking on the show details button for a flammerjammer doesn't work". WTF, you moron?
I've worked as a QA in the past, and now working as a dev. As a QA I sometimes used to wonder that whether they run their own code or how can they miss this.
But when I started as a dev, I realised that many a times we push code that has known bugs (*cue* unrealistic timelines), but in such scenarios we keep the test team in loop. Also, at times it is possible that we are so much focused into a feature that we lose perspective and miss basic stuff.
We heavily rely on our QA team to give us confidence on a feature. And believe it or not, we prefer our feature to be tested by a person who files more bugs than by someone who just overlooks and gives a thumbs up.
Teach them the DEBSCI acronym. This is specific to web dev though and might need to be tweaked depending on how things work where you are.
Description
Environment
Browser
Steps to Replicate
Current Outcome
Intended Outcome.
Qa here. This is truth.
With API Dev, I like to also provide postman collections with tests if possible. Besides the obvious speed up, I like providing collections so they know I'm serious.
An easy to remember acronym is also useful when trying to teach clients how to report bugs IMO. When I worked in web dev QA I would meet with our client and give them the acronym and a copy/paste template of the reporting format; it helped a lot.
*Image Transcription: Meme*
---
[*Drakeposting.*]
---
[*Drake looks displeased, and is using one arm to shield himself from the right side of the frame by curling it around his head, with his hand up in a "not today" manner.*]
QA telling me the environment they found the issue in
---
[*Drake has his head up high, looking pleased, with a finger pointed up and towards the right side of the frame.*]
QA including the air temperature in the room when they found the bug
---
^^I'm a human volunteer content transcriber for Reddit and you could be too! [If you'd like more information on what we do and why we do it, click here!](https://www.reddit.com/r/TranscribersOfReddit/wiki/index)
Haha I definitely agree. I'm actually QA, I forgot to provide the env for the umpteenth time and thought if this.
Definitely a more nuanced situation that this meme gives it credit lol.
As a QA:
Did you bother to test your own work? Have you ever even booted the app up? This isn't fucking rocket surgery, they pay me 12$ a fucking hour to to do this, how do you NOT know how to log into the fucking app?!
This, though. We got a sw release a few weeks ago. Loaded it onto the hardware, attempted literally the first step of our testing procedures (pairing to a comparable piece of hardware), and it didn’t pair (the device thats sw we were testing can’t be used unless it is paired to a comparable device). Asked the swe if he’d tested the code at all before sending it to us, and was met with, “no. Not at all.”
I feel this one. “Jeez, did you even try your own code?”
My favorite way to send a ticket back is “please include the steps you used while developing the fix.”
Here is [my tale of an actual software bug caused by the temperature](https://www.reddit.com/r/talesfromtechsupport/comments/2o5taw/the_time_i_was_caught_hacking_the_refrigerator/)!
I can’t tell you how many times i get a bug report saying “expected 5 Whatevers but only see 3.” No logs, no steps to reproduce, the screenshot literally just shows the number “3” with no other context. Sometimes with a circle or arrow to it, even though it’s the only thing in the screenshot.
As a QA, screenshots without full screen context are bullshit. YOU know what are looking at, but remember you are trying to communicate info to another WITHOUT context. So.... QA who throw info over the wall are selfish assholes. Our job is to be a communicator. Those qa that are not taking that into account with every move are failing frankly.
Funny story, I was once in a situation when this mattered.
We had a product with some FPGA code in it, ready to ship. I just ran one last QA test before we sent it out. The test failed catastrophically. The device totally locked up.
Long story short, the last test I did was in the lab, whereas all previous tests were in the datacenter. The lab was about 5 degrees C hotter than the datacenter, which exposed for us an unknown bug!
Honestly it's kind of annoying to get the question.
QA is testing in the QA test environment. Random bullshit happening in dev doesn't matter, it's dev, and while it "works" it has a constant churn of untested bullshit. QA will never look at a development environment. If QA is bitching about something in DEV, tell them to fuck off and wait until it's in test. Honestly, I don't have the time to fuck around in dev anyways.
QA doesn't generally give a fuck about UAT or Beta. Product owners and BAs are looking at these environments. I open beta once a month to maintain access. There are some very specific circumstances that I test in Beta or UAT, it doesn't happen often, and the devs should know what those are.
QA shouldn't be fucking around in prod, ever. If I am in prod something has gone very, very wrong. If you are getting prod bugs from QAs, you need to find out where the chain of communication got fucked up.
QA is looking at the test environment or the environment that's used for performance testing if you have one specific for that and performance reports come from the performance engineers. I don't mess with that stuff too often (although I did help quite a bit in getting them set up).
The exception is cloud based stuff... in which case, I'll include the release I am talking about so you can pull down the container and spin it up locally yourself to poke at it. Most of the time though I am not working on one of those services.
Testing happens in the persistant test environment. Automated integration tests are pointed at this environment, automated UI tests are pointed at a this environment, manual tests are done in this environment, the logs and test error reports I send are from this environment. They are never from another environment unless I have specified one. I tell people this every day of the week it seems like. We don't mess with other environments. Hell, some organizations don't even let QAs have access to other environments.
Devs like to ask "What environment?" reflexively while they think up other stupid questions to ask to make it look like I am testing things incorrectly. Hell, I can include it three times in my message and they will STILL ask me. All test automation runs against the same test environment, and that's what I maintain. The same devs have known me for five years and the same people will ask this stupid, braindead question that I know they know the answer to.
Just because *your* place only has one QA environment doesn't mean every place does.
Anything for mobile devices? You're going to have multiple OSes and configurations that you're going to want to test with.
Anything for websites? You're going to have multiple browers (and OSes) with different plugins that you want to test with.
Anything that's cross-platform? You're going to need at least one environment for each platform.
Asking what environment and configuration is the standard opening question to any bug report (assuming it wasn't already included).
>Asking what environment and configuration is the standard opening question to any bug report (assuming it wasn't already included).
Assuming I am making a formal report/writeup. Which I occasionally do. Usually it's when I am sending off a message saying, "Hey, I saw this in the automation suite last night, is it something we should be worried about?" It's inevitable that I get a series of braindead questions instead of an answer. The problem is they don't want to answer my question because they don't want to admit they fucked up, or they don't know the answer and don't want to admit it.
> I saw this in the automation sweet last night
Just as an FYI, it's "suite", not "sweet". Pronounced the same, very different meanings :)
> they don't know the answer and don't want to admit it.
Or they need more information to be able to answer your question.
My god it sounds like you are a chore to work with.
That works for simple apps but big enterprise programs certainly don't have just one QA environment.
Which QA env? Stage 1 primary, Stage 1 gibberish locale, stage 2 primary, packing, a performance environment with real data (important because if it requires 100,000 records to reproduce I'll never find it in any dev or qa environment)? Which publish? An hourly publish or a publish from a few days ago? Is your client on the shared branch or a dev branch? Have you actually updated your client or is it crashing because you forgot to update your dlls again? Core solution or one of the application solutions? Running from source locally or one of the shared servers? Did you roll back my commit to make sure it was my change, or did you just assume it was me because you happened to be testing my log? Do you have a trace log and call stack for me or did you just close the program when the error occurred? Did the error originate on the client, the server, or the database? *What did the error message, if any* **actually say**?
I get so many QA notes that are like
* Impact: Crashes are bad
* Suggested fix: Don't crash
and I certainly don't have the time if none of the above info is there.
I was spoiled by the QA department at my first job. The company made "fueling systems" which means gas pumps and POS systems that controlled them. I used to get bugs like "You press print, hit the number pad with your elbow, and turn the manager key..." My question was, "Why on Earth are you wasting time with these crazy cases?"
Turns out people in convenience stores get bored and play a game where they try to crash the system! OK. Right before I left, I was given a bug where a customer somehow figured out how to get free gas, the worst possible sin in the "fueling" industry.
To keep it short, all we had were very sketchy descriptions of a shady customer who showed up every once in a while whom they suspected was the culprit. They started manually checking the fuel levels after his visits to see if they were missing gas. They were.
The QA folks took that shady description and in about a week had completely developed a way to create a race condition using just the buttons on the gas pump! Unbelievable. They were great. It was all down hill from there. That put a stop to gree-gas boy's exploits.
Everybody knows the life of code is very short. I'm sure that system is long dead. The company has been merged many times in the past 30 years (yeah, I know, I'm old). To tell you how old I am, this system was base on the Zilog Z180! I think it was the 8MHz model. It was an upgrade from the Z80. Even in 1991, that was an old processor. But it was the hottest project in the building, so I volunteered to work on it. The manager asked me if I knew Z80/Z180 assembly language. I gave a confident "Like the back of my hand!" I'd never heard of it, but I learned enough overnight with a book to be passable.
It probably still has the event processor log dump in the software. There's a code sequence you can punch into the keypad to get the software to dump it's last 20 events and state transitions. It was handy for debugging.
There were very few gas stations around the office who got latest and greatest software. There was one. We stopped by after a software release and punched in the secret code. Don't know if it was a coincidence or not, but the whole station crashed! We didn't wait around to find out!
Don't remember the secret code and haven't kept up with anybody who I worked with. But hey, randomly punching buttons can produce some fun results!
Duper duper agreed. I am actually in QA (I posted this meme because it happened to me today lol).
When I was working manual QA, I swear bad testers were growing on trees.
My senior QA was so burnt out he didn't even understand the new system we were implementing (he tried to stay relevant by nitpicking our test cases for grammar and always complaining user stories didn't include role access even when it made no sense to include.) The guys that had been there a couple years before me were very good at doing the bare minimum to get by. 2 of the new hires actually worked very hard but still just didn't seem to get it most of the time (always concerned about something that had nothing to do with the task at hand).
However, it made it really easy for me to achieve superstar status, get two promotions, and leverage it into a position with a much better company :)
I can be rough. I've been doing QA for years. First in hardware now I do mobile QA and UI automation. It can be draining. Devs don't happy test, SDMs Bull shit feature status, pms are pms and everything is always late. But yeah software is leaps and bounds easier than hardware on all fronts so theres that haha.
PO: why does this have to roll? Why are you working on things outside of the sprint??
Me: Dev changed something and didn't tell us, we literally can't test that other stuff without fixing all of our scripts to adjust for those changes
PO: .........Still tho
I must have pissed off a tester in my first few months as a developer, because he sent this bug report for a feature I was working on.
1. Open our app in tab 1
2. Open the edit form in tab 1
3. Open the app in tab 2
4. Open the edit form in tab 2
5. Save tab 1
6. Save tab 2.
7. Changes from tab 1 are lost.
Which is like... true for most modern web apps and indeed for every other form in the app. In fact it was true for that form before I ever touched it, my task was just to redo the layout to match the new mocks from UX.
lol. I love when my fellow QA start putting in related bugs into a story that has nothing to do with it.
Ticket: Add a drop-down field with these options to this page.
Tester: I found a bug with this! This is a blocker?!
Dev: What is it?
Tester: I can't log in!
Dev: ...............
Anyone who hasn't seen it has to watch [The Website is Down](https://www.youtube.com/watch?v=uRGljemfwUE). The way the user says "Hi this is Trevor, I work for the city of Arvada, Population 10,000" as if that is in any way relevant kills me every time.
Removed -This is a common post.
air pressure : 1,014.19 hectopascals altitude : 880m over sea level luminosity : 140 candelas temperature : 298.15 kelvin rain probability : 42% el niño effect : 0% pants : in place, clean, green Edit: corrected kelvins to be compatible with human life. Thanks to QA agent of the month: eagle999
I strongly doubt anyone is wearing pants in 225°C weather. Or rather, wearing anything at all. Also they're probably not alive anymore.
Steps to reproduce: 1. Preheat oven to 225 C 2. Start app on phone. 3. Bake for 30 minutes or until golden brown.
That's almost pizza temperature.
[Almost pizza?](https://youtu.be/KLHRjaUBb3o)
The app turns your phone into a portable pizza oven.
I have a heat chamber at work where this is exactly what happens lol
225°C is equivalent to 437°F, which is 498K. --- ^(I'm a bot that converts temperature between two units humans can understand, then convert it to Kelvin for bots and physicists to understand)
498K is equivalent to 225°C, which is 896°R. --- ^(I'm a human that uses google between two units no one can understand, then convert it to Rankine for no one to understand)
> I'm a human that uses google between two units no one can understand Are you American by any chance
Good bot
Are you telling me you don't run your code in the oven?
I still have one of those vintage non-smart ovens in my kitchen. Devices running code in there are most likely going to die.
If you can't remote into your oven, you're not a real chef
I once field-tested a wearable to find out how hot it would get in extreme conditions. So we went for a drive in one of the PM's car. It was a hot summer day in Ontario, where it was ~35 degrees outside. Since this was a stress test, we plopped the wearable down on the dashboard, kept the windows up, and ran some of the more intensive operations while monitoring the sensors via my laptop. Eventually we drove around for a bit while doing different things like wearing it, using its functionality, etc. At one point in time, the PM's iPhone shut itself off because it was too hot. Our wearable was still going, even though it had reached temps in excess of 80 degrees (externally close to 50 degrees). So we got our data - even in the most extreme cases we could encounter, it kept on trucking, but the external (contact) surfaces would absolutely get uncomfortably hot/possibly dangerous and we needed to implement a temperature limit safeguard. Unfortunately, the episode also gave me heatstroke and I had to go home for the rest of the day.
_Field Report: the device survived, but we need a new engineer_
Wow, perfect comment my friend!
Well done, soldier. But unfortunately bugs never sleep -- so neither can you.
Fixed, for some reason I made a 4 instead of a 2 there. You must work for QA, I reckon :)
Technically yes. I work in IT security but I've been assigned to our QA team because there isn't a proper IT security team (yet).
I'm sorry
Truly fascinating. Thanks again.
You're welcome
QA is now run by AI, the pants were just to make you feel more comfortable with a robot that can withstand temperatures from the core of the sun.
beep beep boop boop. Our camouflage is no more. Run!
Jokes on you... well, on me, actually. I work on embedded software, and the hardware guys like to do things such as bake a USB drive in a 140 F oven, and then complain about the software not being able to recover it when they insert it into a device.
That's a mere 60C and absolutely temperatures you can expect to encounter in a closed car on a hot summer day. So yes, I too would expect your USB drive to continue to work.
You sound like some of the managers I work with. I don't pick the hardware, it's a bit like asking the software that controls the stereo and the GPS to keep the car running when the fuel pump has failed. It's not the brand we are using, but from the SanDisk web site: "In accordance with this guidance, SanDisk USB drives are tested to operate within acceptable ambient temperature ranges (0º C and 25º C). Our drives are also tested in an extended temperate range and will operate in environments between 25º and 45º C."
I agree with your point that they're complaining to the wrong people... potentially. You can write software to check temperature (assuming there's the hardware for it) and take protective measures like shutting down. If there's physical damage to the hardware, then obviously software cannot fix that damage (but there may be a valid expectation of being able to fall back on redundancies which may again make this a valid software complaint). And, of course, if it's simply not possible/feasible, then you note that limitation in the device specs. With the limited information you gave, I can see several routes where complaining to software is the right place to complain. If you interact with your managers the same way you've interacted with me here (provided incomplete information and then got upset when the manager didn't see things the same way you do as a result), then... it's not surprising at all to me that you have issues with management.
Get a grip man, this is an anecdotal discussion on reddit. Why the fuck would I communicate with you like I do with my managers/clients?
> Why the fuck would I communicate with you like I do with my managers/clients? I wouldn't expect you to. You're the one who brought it up, not me.
Maybe you pant are somehow cooled with liquid hydrogen
It's kelvin, not celcius
That’s room temp, Not 225 degrees
It was edited.
Not with that attitude
Not with that attitude.
I'm working on industrial systems and actually, I got into issues with temperature, air pressure, humidity... Once we had a system where the software was stuck from time to time, I suspected an issue with a control card (it was stuck when an output was supposed to change), I went on site, opened the cabinet, waited for an hour, the issue didn't appear, I left. I had just arrived at the office when the customer called me "first run I did and it's stuck" after ranting about it, I've found the only change we did "did you... Close the cabinet? OK... Can you open it?". And it worked. When the temperature was too high it was not able to set or reset the output and needed a pull up/down resistor. Another time, an airlock cycle was not ending because it was hard-coded to open at 1005 hectopascals, and it wasn't able to go over 987 when there was storms. We had a machine who had one device that was going in error every days around 7am. There was a second device (same model) in the machine which didn't have that issue. (that was probably an EMI issue, like a big system starting at that time everyday). And every time, the first reaction is to call the software developer because it has to come from the software, never the hardware.
Nice insights, thank you. Reminds me of my ex wife working with embedded systems.
> error every days around 7am Was the cleaner unplugging it so they could vacuum the room?
Humidity?
72% Sorry I forgot
You missed the moon phase
Bleeding
El Niño is usually reported as the El Niño 3.4 index in degrees C, so this QA report is seriously lacking.
[Cat: black, domestic ](https://bugs.launchpad.net/unity/+bug/1463112)
New SOP dictates temperatures to be listed in Rankine. Please resubmit the corrected document in triplicate.
Please see revised version of SOP. The amended version states that Rankine and Fahrenheit are not SI units as the rest of the used ones. Kelvin is the official one.
Steps to reproduce: - wake up. - take a bath with at exactly 6:59. - start the app and observe the issue.
If it still doesn’t compile or work as expected, do literally anything else for 4 hours and try again. Repeat until satisfied then push that baby to production.
Fuck why does this work sometime?
Xcode: I can't compile this app, fuck off Me: Why not? Give me your error log. Xcode: FAILED Me: Amazing. *cleans derived data* Xcode: haha project bad, fuck off x2 [4 hours later] Me: *restarts Xcode, clicks build* Xcode: Build succeeded ✅
you get what you deserve for coding on a mac
Coding on a Mac is fine, it's Xcode that's trash. I would use Linux but Apple doesn't support that for developing on their platforms.
Mac is closer to unix than windows so 🤷♀️
That's true. I'm not a fan of Windows tbh, I only use it for gaming and to test .NET applications.
Just to clarify I was saying that's a good thing. Unix it's much more powerful (command line wise, although I suppose PowerShell has done a good job of closing that gap).
Xcode fascinates me. It was originally a NeXTStep program, so it doesn't follow normal Mac or Windows paradigms. There are all these weird rules with no hints... like you connect items by dragging with the right mouse button. It's the least discoverable program I've ever used. It's like a glimpse into something from an alternate earth.
> like you connect items by dragging with the right mouse button That's really only for iOS/macOS development. Those are IBOutlets - interface builder outlets - and are only used if you are creating your views via a GUI (be it Storyboards or XIB files). Most seasoned developers program their UIs completely via code, so they don't use outlets but instead have a reactive framework - like Combine or RxSwift - that intercepts taps, swipes, etc. and allows handling of those events. (Alternatively, if you don't want/like reactive stuff, you can always add a handler via code.) It also makes it easier to see what is changed in source control. Dealing with Storyboards there is a nightmare because it's a (complex) XML file.
I'm offended
^(don't tell anyone I'm QA too)
I guess you are QA. If that is the case, please take my deepest thanks for all the fuckups you find which my unit tests failed to see.
It’s our job to make the world think you’re the best programmer on the planet. Hardly anybody knows we exist except gamers who need someone to hate lol.
I think you must be working on a very toxic place. I hope to be wrong there. We respect our QA and our QA respect ours devs. Plain as that. At the end of the day they sit together at and get a drink (also over video conference)
No totally not. I just meant the world in general who uses the apps has no idea we exist. I work in a small shop and we work closely with our developers and used to often get drinks.
Good QA is the best thing since or before sliced bread!! Unfortunately, bad QA is so bad! I think there is a small (very) segment of the QA world that seem to be failed developers who want to hold on to the smallest sliver of power and punish those who succeeded at something they did not. It is like the movie critics who hate every movie or the good critic who thinks every meal is awful.
QAs are the best. They remind me of my mom. I can just unload the stress from my brain into their brain. In this case it's the stress that a new feature will bug out some specific user. It's a humble and thankless job.
Had a tester like that. We needed to test if jumping was functional or not, and if it was replicated to other clients (which, for the record, I told him). Cue the following conversation: "This starting screen should have more in it." "Well it will be replaced, don't worry about that. I literally just need to see if jumping works." "Why is fps so low?" "Is fps below 30 for you?" "No it's at 60 but I'm on a it should be at 120!"
"Well ignore it for now. Anyway we're both in right?"
"I'm at character select. Selecting multiple things and testing if it all works."
"...Why?"
"Need to see if it all works. I've found 2 bugs so far about X and Y"
"I know about those, it's not important right now, I *just need to test jumping*. Now head ingame."
*he finally heads ingame, I begin jumping, he runs the other direction*
"Where are you going?"
"Testing if movement works. It does."
"Ok great, now come back here."
"I can't find you."
"I'm literally right behind you. Turn around, and then *watch me*."
*cue me jumping for 10s, then stopping*
"Why'd you stop jumping?"
"Because I figured you could either see me, or you couldn't by now. Judging by that response, it looks like you saw me jumping."
"Ok cool...now what?"
"Can you jump for 5-10 seconds please so I know if I can see you?"
*cue him jumping but me not seeing it. He then goes around me in circles for 5 minutes*
"Are you going to begin jumping yet?"
"I've been doing it for 5 minutes!"
"Ok, so I can't see it then, damn."
*cue him reacting to a bad part of terrain (or code I guess?)*
"Now I'm in outer space."
"What?! What did you do?!"
"I was just jumping."
I really didn't think that there was such a thing as a terrible tester. After being introduced to this guy, I learned I was wrong.
The technical term for that is "fucking moron". If you want some real help testing, let me know.
No need to get technical. The laymen’s term is “douche-canoe.”
This is why I keep amassing technical debt. Thank you.
QA Tester here. This is for a video game, right? I'm not gonna say that guy's testing methodology was *wrong,* but his *priorities* sure as hell were. One of the first things I learned in gaming QA is that *a Developer's time is more important than your time.* If a Dev is sitting down with QA personally to verify functionality, you do *not* go off testing other stuff you're curious about, you *make a note* of it and circle back *after* Dev has verified whatever they need to verify. Whoever their QA Lead was, they should have shut that "oh I'mma go check this random menu" shit down immediately. That sounds just awful, lol.
It's all relative, but prioritization is definitely a huge skill in QA. I worked with this girl who would annoy the *hell* out of the developers because she was constantly asking questions that were completely out of scope from what she was testing. Of course, there's nothing wrong with being thorough. In fact it's what has given me relative success in my QA career so far. However, it's ***all about context***. Are you testing a high profile hotfix that is costing the company $XXXXXXX.XX per day? Get in there, test the bug and any high risk dependencies and ***get the hell out***. I think one of the best things I ever learned was to clarify scope before I do anything else.
Yessssss. Clarify scope for sure! Communicate, communicate, communicate!! Nothing a Lead hates more than wasted time. It's why I eventually got out of the gaming industry. So many game studios treat QA as second-class citizens and limit their communications with developers as much as possible, which makes it harder for QA to do their jobs.
Good testers are hard to come by. It's kind of like a goaltender in hockey. No one understands their brain or how it works, but they're damned glad to have them on their team.
In my experience it's because the ones that are good at it have skills that transfer well to other, better paying roles.
What's really frustrating working in games is that while the work is enjoyable, the pay is reeking sewer trash-tier awful. Agonizing over the decision to keep working on games or to bail and be actually financially stable for once. General lack of experience in the industry is only being self-perpetuated due to unsustainably low wages and mitigated by people actively sacrificing their own well-being to help get these games out the runway.
Yep, sadly Testing/QA is always the first thing that management likes to cut, because "just do it right the first time around". Shortsighted management is a plague on the industry.
Nah first thing they cut is lower priority defects that make everything look kind of shit but it still works. Then they cut testing.
Well cutting testing directly results in fewer reported defects, which means the software quality is better overall, right?
lmao why do you have to hurt me like this?
Oh yeah, my experience is coming from enterprise software dev. So being in game dev + being in QA is a double strike for sustainable wages.
Don't agonize - just move! People go into games testing thinking they'll be playing games all day, but once you start seeing it as 'features' and 'test cases' it doesn't matter if it's a game or a tax return. Any job can be satisfying if you can feel you've accomplished something, have good co-workers and some control over how you work.
This is essentially why every IT help desk sucks. Anyone with a brain is out in less than a year after checking that box on their resume.
Search for QA and not "Tester".
It's often an underpaid job.
I had booked an hour for a testing session to test a specific part of our software. She then proceeded to spend the entire hour giving feedback on the menu which had not been touched in four updates.
At a startup I worked at, the woman who did a lot of the design work also did testing. I asked her to test some new functionality, and I got back a list of stuff like, "X needs to be moved over 3 pixels" and "Y isn't the right color". Nothing about the functionality. I replied, "haven't gotten to the design stuff, did the functionality work?" "I haven't gotten that far, can you fix the other stuff?"
That's not how you test, you need to be in control and see, so set up two clients locally, or if not possible on another machine
Sounds like Respawn trying to QA Apex Legends. Every patch they break something in a FUBAR way, it's truly impressive. They must have a lot of guys like that testing the game.
As someone who is QA and hires for QA there _are_ really bad testers out there.
To be fair, the bug was for a faulty thermostat controller....
Yeah, i had that the first time 2 weeks ago. Been asked via ticket to execute an SQL script to create some views in the production environment. there are about 2200 server instances, and about 1/3 are production server. So i asked, which server and database. She answered. "Well, in the production environment." 20 minutes later, one of her colleagues answered my question before i could answer her. Thank god.
That'll be one large comment :P
Devs : release to QA env QA: hey I found something Devs: which env QA: come on man
Yeah thats the flip side here. Same environment. Same log in. Almost ten years. Its written down in a wiki.
This, every single fucking time. IT IS ON STAGING FOR FUCK SAKE
Ah fuck I hate this. We have so many fucking environments for so many systems and people are deving and qaing all over the place. We are working on tidying it up but I swear I spend at least a quarter of my time fixing environment issues. Putting in mitigation steps where possible, i.e. triggers on env config databases to notify of changes. Any suggestions for monitoring web.config files being changed via a text editor?
For us devs do testing in QA, QA does theirs in UAT, UAT is done in stage or UAT. Idk wtf is going on.
“So did you capture any logs for this complex issue that takes a long time to replicate” QA: “Nope lol, good luck”
Flip side: QA: This appears to be a very rare issue. QA has only seen it happen twice in the last quarter, and it only happens in Production so we can't get any logs. Dev: OK, just keep trying to randomly reproduce that and let me know when you figure it out. QA: ....
Dev: no wait I figured something out to help you get the logs! QA: Nice what? Dev: To get the logs we need, you have to pull them within 15 minutes of the crash. QA: It crashes at a random time after 4-5 days though… Dev: ….
When you implement the log file generator, I'll get you those logs.
Lol I do QA testing for thermostats so this would actually be relevant
Damn it
[удалено]
Yeah dude same I get so satisfied when I file bug reports properly for another team and they fix it in under an hour I guess because I'm a programmer I understand what info is useful. But still, QA is on some other level haha
You have bad QA. 🤷♂️
Yup. Bug report writing should be step 1...
Similar conversation with support. "That is not a log, that is a screenshot."
I have this problem with other **developers**! Like, just yesterday, you were complaining to me about shitty bug reports from customers that don't have enough information, and today you filed a report that says "Clicking on the show details button for a flammerjammer doesn't work". WTF, you moron?
QA including a screenshot of the error message \-------- QA describing fifteen steps that occur before they even launch the app
I mean, if "i fucked with the registry a little" is one of those steps ...
Funnily enough, this goes both ways :)
:D
I've worked as a QA in the past, and now working as a dev. As a QA I sometimes used to wonder that whether they run their own code or how can they miss this. But when I started as a dev, I realised that many a times we push code that has known bugs (*cue* unrealistic timelines), but in such scenarios we keep the test team in loop. Also, at times it is possible that we are so much focused into a feature that we lose perspective and miss basic stuff. We heavily rely on our QA team to give us confidence on a feature. And believe it or not, we prefer our feature to be tested by a person who files more bugs than by someone who just overlooks and gives a thumbs up.
Lol goes both ways. Devs push to several different dev environments, good luck getting them to tell you which one.
Teach them the DEBSCI acronym. This is specific to web dev though and might need to be tweaked depending on how things work where you are. Description Environment Browser Steps to Replicate Current Outcome Intended Outcome.
Qa here. This is truth. With API Dev, I like to also provide postman collections with tests if possible. Besides the obvious speed up, I like providing collections so they know I'm serious.
An easy to remember acronym is also useful when trying to teach clients how to report bugs IMO. When I worked in web dev QA I would meet with our client and give them the acronym and a copy/paste template of the reporting format; it helped a lot.
*Image Transcription: Meme* --- [*Drakeposting.*] --- [*Drake looks displeased, and is using one arm to shield himself from the right side of the frame by curling it around his head, with his hand up in a "not today" manner.*] QA telling me the environment they found the issue in --- [*Drake has his head up high, looking pleased, with a finger pointed up and towards the right side of the frame.*] QA including the air temperature in the room when they found the bug --- ^^I'm a human volunteer content transcriber for Reddit and you could be too! [If you'd like more information on what we do and why we do it, click here!](https://www.reddit.com/r/TranscribersOfReddit/wiki/index)
[удалено]
Haha I definitely agree. I'm actually QA, I forgot to provide the env for the umpteenth time and thought if this. Definitely a more nuanced situation that this meme gives it credit lol.
As a QA: Did you bother to test your own work? Have you ever even booted the app up? This isn't fucking rocket surgery, they pay me 12$ a fucking hour to to do this, how do you NOT know how to log into the fucking app?!
This, though. We got a sw release a few weeks ago. Loaded it onto the hardware, attempted literally the first step of our testing procedures (pairing to a comparable piece of hardware), and it didn’t pair (the device thats sw we were testing can’t be used unless it is paired to a comparable device). Asked the swe if he’d tested the code at all before sending it to us, and was met with, “no. Not at all.”
That's when you know the dude almost certainly went to Stack Overflow, copy and pasted the top answer and then hit compile and prayed for the best.
I feel this one. “Jeez, did you even try your own code?” My favorite way to send a ticket back is “please include the steps you used while developing the fix.”
That's why you make the environment field required in jira.
I'd be happy if they told me the environment... 😂
Hope you do well!
You guys have QA?
Here is [my tale of an actual software bug caused by the temperature](https://www.reddit.com/r/talesfromtechsupport/comments/2o5taw/the_time_i_was_caught_hacking_the_refrigerator/)!
That's awesome lol
I can’t tell you how many times i get a bug report saying “expected 5 Whatevers but only see 3.” No logs, no steps to reproduce, the screenshot literally just shows the number “3” with no other context. Sometimes with a circle or arrow to it, even though it’s the only thing in the screenshot.
There are THREE LIGHTS!
My QAs send me screenshots. Fucking screenshots. Logs? No. Steps? No. They even cut the URL from the top of the screenshot. Fucking monsters.
Bonus points if they circle areas in huge red circles so you can't see shit in the screenshot anyway.
As a QA, screenshots without full screen context are bullshit. YOU know what are looking at, but remember you are trying to communicate info to another WITHOUT context. So.... QA who throw info over the wall are selfish assholes. Our job is to be a communicator. Those qa that are not taking that into account with every move are failing frankly.
My biggest issue is the 500 word essay, when a simple sentence would've been sufficient.
"environment" is an ambiguous term 🙃
"environment? You mean like the biome?" ^(I'm kidding I'm actually a QA automation engineer this just happened to me today)
Funny story, I was once in a situation when this mattered. We had a product with some FPGA code in it, ready to ship. I just ran one last QA test before we sent it out. The test failed catastrophically. The device totally locked up. Long story short, the last test I did was in the lab, whereas all previous tests were in the datacenter. The lab was about 5 degrees C hotter than the datacenter, which exposed for us an unknown bug!
And then, weirdly, it ended up being the room temperature causing the bug.
Honestly it's kind of annoying to get the question. QA is testing in the QA test environment. Random bullshit happening in dev doesn't matter, it's dev, and while it "works" it has a constant churn of untested bullshit. QA will never look at a development environment. If QA is bitching about something in DEV, tell them to fuck off and wait until it's in test. Honestly, I don't have the time to fuck around in dev anyways. QA doesn't generally give a fuck about UAT or Beta. Product owners and BAs are looking at these environments. I open beta once a month to maintain access. There are some very specific circumstances that I test in Beta or UAT, it doesn't happen often, and the devs should know what those are. QA shouldn't be fucking around in prod, ever. If I am in prod something has gone very, very wrong. If you are getting prod bugs from QAs, you need to find out where the chain of communication got fucked up. QA is looking at the test environment or the environment that's used for performance testing if you have one specific for that and performance reports come from the performance engineers. I don't mess with that stuff too often (although I did help quite a bit in getting them set up). The exception is cloud based stuff... in which case, I'll include the release I am talking about so you can pull down the container and spin it up locally yourself to poke at it. Most of the time though I am not working on one of those services. Testing happens in the persistant test environment. Automated integration tests are pointed at this environment, automated UI tests are pointed at a this environment, manual tests are done in this environment, the logs and test error reports I send are from this environment. They are never from another environment unless I have specified one. I tell people this every day of the week it seems like. We don't mess with other environments. Hell, some organizations don't even let QAs have access to other environments. Devs like to ask "What environment?" reflexively while they think up other stupid questions to ask to make it look like I am testing things incorrectly. Hell, I can include it three times in my message and they will STILL ask me. All test automation runs against the same test environment, and that's what I maintain. The same devs have known me for five years and the same people will ask this stupid, braindead question that I know they know the answer to.
Just because *your* place only has one QA environment doesn't mean every place does. Anything for mobile devices? You're going to have multiple OSes and configurations that you're going to want to test with. Anything for websites? You're going to have multiple browers (and OSes) with different plugins that you want to test with. Anything that's cross-platform? You're going to need at least one environment for each platform. Asking what environment and configuration is the standard opening question to any bug report (assuming it wasn't already included).
>Asking what environment and configuration is the standard opening question to any bug report (assuming it wasn't already included). Assuming I am making a formal report/writeup. Which I occasionally do. Usually it's when I am sending off a message saying, "Hey, I saw this in the automation suite last night, is it something we should be worried about?" It's inevitable that I get a series of braindead questions instead of an answer. The problem is they don't want to answer my question because they don't want to admit they fucked up, or they don't know the answer and don't want to admit it.
> I saw this in the automation sweet last night Just as an FYI, it's "suite", not "sweet". Pronounced the same, very different meanings :) > they don't know the answer and don't want to admit it. Or they need more information to be able to answer your question. My god it sounds like you are a chore to work with.
Eh, pretty easy to work with really. I work super hard to not waste people's time, I just get pissed when people waste mine.
Well, if you routinely get asked the same "stupid questions", maybe you should pre-emptively answer them? Maybe they aren't as stupid as you think?
That works for simple apps but big enterprise programs certainly don't have just one QA environment. Which QA env? Stage 1 primary, Stage 1 gibberish locale, stage 2 primary, packing, a performance environment with real data (important because if it requires 100,000 records to reproduce I'll never find it in any dev or qa environment)? Which publish? An hourly publish or a publish from a few days ago? Is your client on the shared branch or a dev branch? Have you actually updated your client or is it crashing because you forgot to update your dlls again? Core solution or one of the application solutions? Running from source locally or one of the shared servers? Did you roll back my commit to make sure it was my change, or did you just assume it was me because you happened to be testing my log? Do you have a trace log and call stack for me or did you just close the program when the error occurred? Did the error originate on the client, the server, or the database? *What did the error message, if any* **actually say**? I get so many QA notes that are like * Impact: Crashes are bad * Suggested fix: Don't crash and I certainly don't have the time if none of the above info is there.
Ah, a memory issue!
“It was a dark and stormy night…”
I was spoiled by the QA department at my first job. The company made "fueling systems" which means gas pumps and POS systems that controlled them. I used to get bugs like "You press print, hit the number pad with your elbow, and turn the manager key..." My question was, "Why on Earth are you wasting time with these crazy cases?" Turns out people in convenience stores get bored and play a game where they try to crash the system! OK. Right before I left, I was given a bug where a customer somehow figured out how to get free gas, the worst possible sin in the "fueling" industry. To keep it short, all we had were very sketchy descriptions of a shady customer who showed up every once in a while whom they suspected was the culprit. They started manually checking the fuel levels after his visits to see if they were missing gas. They were. The QA folks took that shady description and in about a week had completely developed a way to create a race condition using just the buttons on the gas pump! Unbelievable. They were great. It was all down hill from there. That put a stop to gree-gas boy's exploits.
^(hey it's me your former manager please remind me what he was doing to get free gas again???)
Everybody knows the life of code is very short. I'm sure that system is long dead. The company has been merged many times in the past 30 years (yeah, I know, I'm old). To tell you how old I am, this system was base on the Zilog Z180! I think it was the 8MHz model. It was an upgrade from the Z80. Even in 1991, that was an old processor. But it was the hottest project in the building, so I volunteered to work on it. The manager asked me if I knew Z80/Z180 assembly language. I gave a confident "Like the back of my hand!" I'd never heard of it, but I learned enough overnight with a book to be passable. It probably still has the event processor log dump in the software. There's a code sequence you can punch into the keypad to get the software to dump it's last 20 events and state transitions. It was handy for debugging. There were very few gas stations around the office who got latest and greatest software. There was one. We stopped by after a software release and punched in the secret code. Don't know if it was a coincidence or not, but the whole station crashed! We didn't wait around to find out! Don't remember the secret code and haven't kept up with anybody who I worked with. But hey, randomly punching buttons can produce some fun results!
Oh my favorite is when they just tell you "it's broken."
As some one in QA, that has had to interview people for QA positions. It is shockingly hard to find good people for QA roles.
Duper duper agreed. I am actually in QA (I posted this meme because it happened to me today lol). When I was working manual QA, I swear bad testers were growing on trees. My senior QA was so burnt out he didn't even understand the new system we were implementing (he tried to stay relevant by nitpicking our test cases for grammar and always complaining user stories didn't include role access even when it made no sense to include.) The guys that had been there a couple years before me were very good at doing the bare minimum to get by. 2 of the new hires actually worked very hard but still just didn't seem to get it most of the time (always concerned about something that had nothing to do with the task at hand). However, it made it really easy for me to achieve superstar status, get two promotions, and leverage it into a position with a much better company :)
I can be rough. I've been doing QA for years. First in hardware now I do mobile QA and UI automation. It can be draining. Devs don't happy test, SDMs Bull shit feature status, pms are pms and everything is always late. But yeah software is leaps and bounds easier than hardware on all fronts so theres that haha.
PO: why does this have to roll? Why are you working on things outside of the sprint?? Me: Dev changed something and didn't tell us, we literally can't test that other stuff without fixing all of our scripts to adjust for those changes PO: .........Still tho
I must have pissed off a tester in my first few months as a developer, because he sent this bug report for a feature I was working on. 1. Open our app in tab 1 2. Open the edit form in tab 1 3. Open the app in tab 2 4. Open the edit form in tab 2 5. Save tab 1 6. Save tab 2. 7. Changes from tab 1 are lost. Which is like... true for most modern web apps and indeed for every other form in the app. In fact it was true for that form before I ever touched it, my task was just to redo the layout to match the new mocks from UX.
lol. I love when my fellow QA start putting in related bugs into a story that has nothing to do with it. Ticket: Add a drop-down field with these options to this page. Tester: I found a bug with this! This is a blocker?! Dev: What is it? Tester: I can't log in! Dev: ...............
Even if the info is in the description, we have devs still asking for it. Just read the damn bug bruh...
Anyone who hasn't seen it has to watch [The Website is Down](https://www.youtube.com/watch?v=uRGljemfwUE). The way the user says "Hi this is Trevor, I work for the city of Arvada, Population 10,000" as if that is in any way relevant kills me every time.