Current Events > I'm pretty sure a coworker will get fired within days - AMA

(+) Yeah! (+)

I'm working for a small software company, and once more, an update from our end broke something important for our customers.

Again. For stupid silly reasons that are stupid and silly.

Now this is not about our developers (in this case UI-designer), but about our staff in testing.

The bosses are already extremly unsatisfied with her work, and this is once more an obvious stupid bullshit bug that jumps you right into the face if you test it at least once. But noooo, it went on unnoticed throught testing, and now everyone in the office is once more getting the heat to release a hotfix ASAP and deliver it to all our customers once more.

Seriously, she is a nice person, but sometimes I have to question what she is actually doing. The situation is truly bad atm.

Also, AMA, because why not. I will try to answer if I have the time between angry customer calls and emergency meetings, because I can't do shit atm besides that anyways.

I work in a small software company and we had an employee like that, who evaded being fired for about 3 years because her husband is the golden child of the company (he's that one ex-hacker full stack dev who is good at everything and had a hand in building everything).

I'll never forget the time that she was given the task to do a gap analysis on our competitor's products to see what they offer and what we don't (literally just a matrix chart in excel, should have taken a week tops), and was given an entire year to do this, and she never produced anything. At that point they just had to let her go.

its definitely bad if a dedicated tester isnt doing their due diligence. i dont know how it works at larger software companies, but wouldnt even the devs be testing as they dev? i cant imagine you'd want to write more than a bit of code at a time without verifying it works at whatnot.

Kloe_Rinz posted...

its definitely bad if a dedicated tester isnt doing their due diligence. i dont know how it works at larger software companies, but wouldnt even the devs be testing as they dev? i cant imagine you'd want to write more than a bit of code at a time without verifying it works at whatnot.

Nah. You don't get devs to do testing. It slows them down and they've been staring at the code for too long anyway.

I mean they should be doing the bare minimum to ensure it works in the conditions they're given but you don't want devs to sit there going through all the permutations while thinking about the user experience too much.

Be looking like this when they're tossed out

https://gamefaqs.gamespot.com/a/user_image/8/4/7/AAJHVqAAE57X.jpg

Kloe_Rinz posted...

its definitely bad if a dedicated tester isnt doing their due diligence. i dont know how it works at larger software companies, but wouldnt even the devs be testing as they dev? i cant imagine you'd want to write more than a bit of code at a time without verifying it works at whatnot.

To keep it very simple:

The dev is just checking the specific usecase they are working on, and that's it. If it works, it works, on to the next task.

The tester is supposed to check all the stuff working together, and checking if any change breaks something different somewhere else.

if there was something i really liked about my last job, it was that we had rock solid testing practices, between a very meticulous manual tester and my massive suite of unit and integration tests and ci infra to run them all nightly. made work very easy.

slowly getting there at my new job, though with far more complex software. the team is extremely competent in terms of code quality which is probably why issues in production are exceedingly rare, but i still scream bloody murder for more test coverage because if something goes wrong, it could get ugly.

but anyway, enough with the rant. are the individual contributors at your employer not required to write their own unit/integration tests?

I'm not involved with the development itself, so I have no idea what rules and guidelines are used exactly.

But this isn't something you can check with a unit / integration test anyways.

The problems is purely human, because under some circumstances we get a form that's bigger than the screen, and that breaks stuff because UI elements are out of sight. Sadly, these circumstances are too easy too meet, and "breaks stuff" means something critical.

Technically it works, the elements are there and can be accessed.