Stop me if you've heard this one, "why didn't QA catch it before!!
Dear Readers,
In my professional career, there are few things I have zero-tolerance for, and being admonished for doing the job I was hired to do ranks up there.
There are things within the field of IT that quality assurance analysts are responsible for, but there are more things that are beyond our control, and I wish to outline a few:
There are things within the field of IT that quality assurance analysts are responsible for, but there are more things that are beyond our control, and I wish to outline a few:
Faulty Requirements
The
bane of any tester, no matter how good they are, is to have
less-than-stellar requirements. When developers spend more time trying
to figure out the outcome of a feature, they've wasted time programming.
When QA is asked "figure it out" the end result are CRs that are
rejected because the issue found is as expected. Really?! Where was that written? Oh! that's right, it wasn't!
Shortened / compressed timelines
All
phases of the the SDLC are properly allotted a budgeted amount of time
with which to execute the scope of work. When the project runs late, the
time constraint most affected is that of testing. There will be a lot
of push back from the QA manager, with the stern warning that the
project-in-test will go live with a lot more issues than what's allowed.
Shortened timelines will guarantee higher-than-tolerable failures.
Laziness
Note to Developers: I'm on your side 100%, but the burden of quality coding cannot be rested on the shoulders of the QA Analyst alone. There are a few that toss the project over the wall and hope it works, relying on QA to find the problems and improve the overall quality of the app / site. Unacceptable! it is not for QA to ensure the quality of the code, but rather the quality of the entire project. Developers MUST NOT rely on testers alone to ensure the features work.
Fix-A-Bug, Find-A-Bug
When time is of the essence, and the project is behind schedule, nothing is more frustrating to QA Analysts than to test, write a bug ticket, close said ticket then find a new bug introduced by the fix .. repeat! As a segue to my previous statement, carelessness is just not acceptable when the project needs to be handed off to the client at an expected time.
Testing is tedious enough but the test-fix-break-test is tiresome especially when the build is handed back to QA without it being tested.
Its QA's fault .. even when it isn't
Nothing is more toxic or demoralizing to a tester / QA Analyst than to bear the brunt of an issue that made it all the way to the Client. QA can run a battery of test cases, crowd-source test the project, automate to no end, but there will always be bugs. To be blamed is just not fun.
Blame has not place in the workplace ... like on any team, its no one person's fault ... we own it, we share it!
Conclusion
The life of a QA Analyst is an inglorious one. We shoulder the responsibility of the project, writing up our test cases by rooting out use cases based on poorly written requirements. We bear the brunt of the problems, get the short-end of prestige, and never get the respect owed to us. However, it is for QA to speak out the solution to make it happen, not complain about the problem; nothing happens until it is spoken .. in a positive manner!
But enough about me .. how was your day?
