Live data from Hacker News

Asking developers to do QA is broken – why anyone should own QA

rainforestqa.com

31–40 of 193 posts

Re: Asking developers to do QA is broken – why anyone should own QA

#31

I think QA-specific people that are specifically not SDETs create bad habits on teams. I think asking developers and product owners/managers to "own" QA fixes the "just throw it over the wall and hope for the best" problem.

But then you're settling for low quality testing. There's an excellent methodology a good test team uses on devs that throw it over the wall. They throw it back with the first bug report.

That said, it's sometimes the right thing for the team when something gets thrown over raw. A good test team should be fine with that and play their part.

Re: Asking developers to do QA is broken – why anyone should own QA

#33
Why can’t the QA people just live on the dev team? Why do they need to be siloed away or not exist?

I had this in my past job. Have 1 QA per two developers, the QA sits with those two developers, and you are constantly telling them when a build is done and on staging. They write tests, do some manual checks, and then tell you how it is going relatively immediately. They also handle the problem of reproducing bugs and narrowing down exactly where they occur, which is not trivial.

For all the faults in that organization (including letting our test runner be broken for months), we didn’t put out a lot of bugs and we found all manner of strange edge cases very quickly.

Re: Asking developers to do QA is broken – why anyone should own QA

#34

I've yet to see the automated test suite that replaces a skilled, sapient, human, functional tester. The automation takes away the drudgery of repeating tests, but it takes a skilled human to figure out what risks are in the code and figure out coverage to determine whether those risks are realized. If you have developers write good unit and integration tests, and build their work to their local environment to make s…

I've seen them used to do a decent smoke test to allow the QA people to make forward progress on other testing. I worked at a place that had a large number of computers running some testing software (robo something?) that ran through all the mainline scenarios. They constantly added new scenarios so the QA folks were working on much deeper flows until those too became automated.

Re: Asking developers to do QA is broken – why anyone should own QA

#35

Earlier quoted context omitted.

Yeah, this is the only thing that practically worked, in a complex product I used to work on. - If you ask the devs to do QA, you'll get no bugs other than the ones they already caught during testing and deployment. - If you have a mostly independent QA team, they will find somewhat silly/trivial bugs like the login page not working in an extreme edge case scenario. - However, when you ask your Product team to own QA…

> However, when you ask your Product team to own QA, you get the real good stuff - "Why does this feature not actually work well with this other feature when you combine the configuration" etc. It's great! That would require a skilled product management that is on equal footing with sales and has a veto right before stuff gets sold to customers. All too often however, the only thing that matters is customer wishes fo…

Having previously spent a decade in that role for a $1B company: I never got a veto right before stuff got sold to customers. I really, really wanted that in the beginning.

In the end what I ended up doing was spending a lot of time packaging the product as well as educating the sales force. If you don't have well-packaged products, the sales force will sell anything, even if it doesn't exist. And they'll get backed up by a typically slightly disconnected exec team, because they also want revenue really, really badly.

This strategy worked surprisingly well. I think both the sales team and the ever slightly disconnected exec team benefited from the artificial structure that I spent so much effort making up. I guess people instinctively just like following clear structures over chaos.

(This was 5-10 years ago, and not in Silicon Valley.)

Re: Asking developers to do QA is broken – why anyone should own QA

#36
* Adopt this automation platform

* It eventually becomes too much work for the PM as the product grows or the PM just gets tired of the tediousness of creating tests for all the edge cases

* PM hires someone to help with creating the automation tests

* That guy now becomes "the QA guy"

* Repeat till you've re-invented "the QA team"

Re: Asking developers to do QA is broken – why anyone should own QA

#37

I think QA-specific people that are specifically not SDETs create bad habits on teams. I think asking developers and product owners/managers to "own" QA fixes the "just throw it over the wall and hope for the best" problem.

But then you're settling for low quality testing. There's an excellent methodology a good test team uses on devs that throw it over the wall. They throw it back with the first bug report. That said, it's sometimes the right thing for the team when something gets thrown over raw. A good test team should be fine with that and play their part.

> But then you're settling for low quality testing.

Not necessarily though. I would also argue that manual testing is just an insurmountable timesink. You'll never have enough time because manual testing balloons to the time allotted.

> There's an excellent methodology a good test team uses on devs that throw it over the wall. They throw it back with the first bug report.

Sure, but continuing a cycle of "not my problem" helps no one and wastes time. Removing QA as a team/role/specialization, and instead making it a step in the process a dev goes through to ship software, you're fixing the broken feedback cycle QA teams create.

Re: Asking developers to do QA is broken – why anyone should own QA

#39

This feels a lot like a reincarnation of cucumber/gherkin, except they've replaced business-facing text DSL with a no-code visual UI. The intention is the same - to have the customer own the tests. This looks like it has a shallower learning curve to get started, but I would imagine that after a certain point it winds up being less productive to use the UI than to write code and this is ultimately why visual coding h…

If you want something it's closer to, it's sikuli script. Visually looking at the page (or whatever, tbh), then manipulating it using the keyboard and mouse. It's basically done using a KVM, so much closer to what a user would be able to see and do than something like cucumber or gherkin.

However, we also allow you to test using a crowd of humans, should folks need more nuanced feedback about things, or have much more complex things to ask.

Disagree on who should be writing tests; I think that's the case today as tooling doesn't support anyone but engineers (QA or not) automation things, or manual tests.

Re: Asking developers to do QA is broken – why anyone should own QA

#40
Dev sometimes aren't the best QA because they think like developers and not like end users. The mindset prevents you from doing things on the corners that end users do. Its like your instincts kick and a keep you safe without the railing where an end user might plow ahead thinking their path is ok and fall off the edge.

Devs should do automated unit and functional tests, but after that, get some good QA that do not have the same boss (at least at the first level) as the developers.

Post reply on HN