Live data from Hacker News

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

rainforestqa.com

51–60 of 193 posts

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

#52
post #49

Silver bullets. They don't exist. Code review. Read the results of someone thinking through a process. Spot more than they will, simply by throwing more eyes at it. Actually fairly effective: getting a senior dev to cast even a lazy eye over everything gives more opportunities to discuss Why It's Done This Way and Why We Don't Do That and Why This Framework Sucks And How To Deal With It with specific concrete example…

The only silver bullet is approximated by a holistic approach.

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

#53

Love the idea, but have you met product owners?

Yeah, the good ones really care about the product experience and customer outcomes, so this makes a lot of sense to me. But what do you mean?

It's hard to get them to provide details to the engineers. I haven't seen many who write user stories. Asking them to build no-code automated test cases, that's ... ambitious.

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

#55
post #41
post #16

Earlier quoted context omitted.

What do you use to plan it or otherwise manage the process? Is it all manual?

Essentially yes. We are trying to move to a hybrid model where we can send excel workbooks to the customer for completion, and then directly import these into the system. This would get us ~80% of the way there. One huge upside with configuration is that it can be copied really easily. If you have a model customer that is very similar to others, you can use it as a starting point and save 99% of the work effort.

Makes sense. Did y'all try to automate any of it? I've seen situations where things are highly-configurable, and massive at the same time - mostly in the medical industry. Test plans are hard due to interactions between config being highly-complex. No sense testing all of the setups, as not all are used or would even make sense.

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

#56
post #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 mor…

Engineers should absolutely be writing unit tests and integration tests for their APIs. Personally I find that it brings a lot more integrity and a sense of ownership into the process when engineers are required to deliver tests.

I disagree with the problem's that you mention in this article:

Developers aren’t incentivized to prioritize QA testing

Developers are typically evaluated based on the quantity of software they ship, and how fast they ship it.

That's an organizational problem that is not universal and certainly won't be solved by a QA automation tool.

Developers’ job satisfaction goes down when they’re in charge of QA

Expanding upon one of the previous points:, we’ve seen that most developers just don’t enjoy doing QA.

This might be the case for manual testing but for automated testing the opposite is true. Delivering tests along with code increases integrity, makes debugging significantly easier, and helps clearly communicate the intention of each feature. This only works if there is collaboration between the developers and the product owner.

Clearly you have a viable product that works for many organizations, but it's certainly not a one-size-fits-all solution nor a best practice.

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

#57

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…

They're not claiming people are not needed.

They say that instead of being developers writing codee, they should be non technical product managers using no-code.

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

#58

Devs doing QA worked fine for us. You need to have a team that actually cares about the product, and you need figurehead devs - not necessarily seniors or team leads, but charismatic people others will fall into line with - who model the behaviours you want. The problem with almost anything else is that it increases the number of hand-offs between groups of differently-aligned people on the route to production. If yo…

My main problem with devs doing QA is that QA is huge, knowing the entire product is hard.

In my case, devs were just testing what they changed and never noticed something horribly broken somewhere else.

I think all devs should test that what they built works in production (you don't need QA for that), you need QA to keep everything else tested and working.

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

#60

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…

Terrible idea. The dev team manager is focused on growing new features in the next release. QA is focused on the excellent of the current release. Subordinating quality to new releases is the result. In a similar situation, devops supposedly addressed similar tensions of dev and ops.

QA here, disagree. In this situation QA is focused on the quality of the new features, so they're already excellent when they go out into the current release.
Post reply on HN