For those that are software weenies like myself I just posted this on LinkedIn. Just because.
“A Software QA Engineer’s job is to find bugs. Their job is not to verify that design requirements have been satisfied. That is the job of the product manager(s) that came up with the requirements to begin with. If your Jira tickets go from development to QA directly you are doing it wrong. You will lose employees because of it. Why? Because if QA misses one aspect of a design requirement, they’re in trouble. Now you are pitting QA vs. Product Management. You are setting up conflict even in the best environment. Product managers, verifying your requirements is not my job. I break stuff. Or I automate the process of breaking stuff. YOU came up with those requirements, not me. It’s YOUR job to verify that the requirements have been met. It goes like this: ticket creation->development->code review->product management->QA. If you don’t do that I will not work for you. This applies when the Jira ticket is a functional requirement, not a bug, and was entered by product management. This is a hill I will die on.”
-SB
Oh, and I posted this.
“If you interview me do not code test me, asking if I can find the largest word in a series of strings. I don’t do that. I identify objects and manipulate them and then I verify the results. I’m not breaking new ground in software development. If I’m doing GUI automation I’m using Selenium. This stuff is not rocket science. Ask me Selenium questions. API? Ask me REST questions or let’s talk Postman. You’re all doing it wrong and it shows. If I was a manager I would want a software QA engineer that can code, not a software developer in test. THERE IS A DIFFERENCE. They are not Sherlock Holmes, I am.”
-SB
Snowybear - Just so you know that isn’t the way the med device/pharmaceutical software world has worked in the 24 years I’ve been working in it....mainly because of regulations and ISO standards that drive the requirement that testing be conducted by quality as an independent agent. That testing is required to confirm that requirements are being met so the protocols have to be written to ensure that all requirements are covered and then the test have to document that they were which then become the design verification and/or validation reports demonstrating the requirements were met.
I’ve had more issues with Design controls in S/W then in any other aspect, because so many of the S/W world come from a coding culture that wants to just do their own thing without documentation and doesn’t understand basic design controls: requirement—>design input—>design output—>design verification—>design transfer/final product—>design validation.
Bugs in this world are considered anything that would prevent a design input or requirement from being met.
That being said I agree that it’s still product management’s responsibility to be the arbiter of product requirements. Often this means that when a failure occurs they have to lead the discussion about whether that feature is still something that needs to remain a requirement or if instead a project will change their marketing claims and/or scope.