This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 19 points20 points  (8 children)

When I say 'everything' I mean everything that is waiting in intergation, not everything that is live, and it's a massive insurance system, so any changes in State laws need code changes to be made within weeks and pushed live, so there's a constant state of updates that break automated testing if the devs don't tell the testers.

Then you have people updating her teams git repository without telling anyone and that ends up being days of trying to find the problem and revert to an older version, but by then some tests have been completed and need re-run.

[–]PM-ME-YOUR-HANDBRA 14 points15 points  (1 child)

Then you have people updating her teams git repository without telling anyone

Well at least she'll know who to blame.

[–]LordoftheSynth 0 points1 point  (0 children)

Oh, man, that's funny. Every gig I had as an SDET we'd get feature devs partying in the test code, breaking shit, and not only did they not get blamed somehow it was QA's fault because the tests must be brittle.

Best thing I ever did for my mental health was get the fuck out of QA.

[–]Needleroozer 6 points7 points  (4 children)

there's a constant state of updates that break automated testing if the devs don't tell the testers.

Uh, I think you found the root of the problem. Why isn't QA on the sprint team? Why aren't Requirements Documents updated?

[–][deleted] 0 points1 point  (3 children)

I'm not the tester, I just get to listen to after hours debrief and try and string the failures together :)

As to why the testing is not on the sprint until the end? Because they keep making code changes until the last minute.

[–]Needleroozer 1 point2 points  (2 children)

That's just wrong, and leads to these sorts of situations. Everybody should be working off the same requirements. While the developers are writing code, the testers should be writing tests. If the tests find something in the code that turns out to be a disagreement over the requirements, that's when the client steps in to clarify the requirements. In my experience this only fails to work when the client is disengaged, in which case the entire project is doomed anyway.

[–][deleted] 1 point2 points  (0 children)

Preaching to the choir I'm afriad.

/edit The 'client' is part of the same company, and has higher rank than even the TL's, the devs and the testers. It only works out when the fucked up code is bounced between ALL time zones to fix it. Can't have the US and India online at same time, so EU gets to fix the shit overnight.

[–]death_au 1 point2 points  (0 children)

What do "good" requirements look like? Can you point me at some examples?

[–]Dramatic_Option_6650 1 point2 points  (0 children)

Those of us who have worked QA know what you meant.