Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

rainforestqa.com

Post reply on HN
Print view View original

151–160 of 193 posts

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

#151

Post by draw_down »

darkwater wrote: post #139

Sorry to sound harsh but IME I find - to be kind - naïve saying that developers are incentivized for release speed and at the same time pretending that product managers/owners WILL NOT have the same, exact incentive. I mean, I don't know in which dreamland company you are working but in the average company the ones pushing for new features and not caring about code quality are... PMs. I know they have to sell their n…

Agreed, many issues are boiled down to some quirk or incentive of engineers, leaving pretty much the entire business apparatus out of the analysis.

Like, if a game has a female character with huge breasts, it’s because devs are horny. Well, someone had to conceive of that character, iterate through sketches, design the models, biz people had to sign off on everything, etc.

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

#152

Post by ozim »

mobilene wrote: post #18

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…

There is even more to it than that.

Business thinks that you can do test automation in a vacuum without any domain knowledge and without knowing the system.

You always need people to understand the system, to understand the automation and to keep domain knowledge in house.

If your whole QA team leaves and you have automation (or even documentation) - you are still in deep shit because hiring new people and training them on the system will still be needed and only then they can learn to run the automation. They still need to spend time reading documentation and understanding it, because that something is written down or documented does not mean other person has the same understanding of it and the same reference framework to use that documentation.

Well you can hire some new people and let them run automation built by previous team but ... good luck with that.

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

#153

Post by Rapzid »

bilalq wrote: post #23

In a model where developers adhere to a devops philosophy and are product owners, there's no need for a split. Developers should not be measured only quantity of releases, but also on metrics related to availability, customer impact, latency, operational costs, etc. I'm not opposed to a model where non-technical roles are empowered to define test cases and contribute to approval workflows of a release pipeline, but t…

Agree but a lot of companies, particularly larger ones, don't have this sort of culture. They are filled with people whos sense of worth(at the company at least) is defined by a narrow job title and set of skills. Their worldview requires them to categorize everyone else on a narrow set of attributes as well:

"Oh, you're a programmer so you must not be good at soft-skills and communicating with the business."

"Ah, you have soft-skills and you also program? You must not actually be very good at programming so you should stop that and just become a PM."

"Ah, they are PMs/Sales/Whatever so SQL is too hard for them and they can't be expected to learn git or markdown; that's for nerds."

This leads to cringy, insulting sentiments like:

> The most valuable thing you can be doing is writing code

Ughh.

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

#154

Post by ozim »

desc wrote: 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…

Code reviews should be about project structure and abstractions and keeping approach in order or to use team common approach instead of each team member doing whatever, well syntax/code should be linted and formatted automatically nothing for reviewer. Second thing is checking by second pair of eyes if they understand code in question in the same way.

Unit and integration tests should not be generated. Those should be written by people if they find code that they are writing doing complex things like some specific calculation. It is more as a tool for understanding what you are doing and then maybe leave some tests behind for regression. But don't generate BS tests that will only slow down system and people. People have to understand what is going on and be on top of it and never "just run the tests" because tests that are passing green but are actually wrong are really bad.

UI testing should not be abstractable - it should be only augmenting manual UI testing - so tester should be automating his own work after he has done it manually. That tester should also find things that take him long time or have to be done multiple times and are not changing often so he wins time to do more important things. QA person should also be always engaged with the system and automation because that is the only way you can keep domain knowledge.

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

#155

Post by Rapzid »

ukd1 wrote: post #78
sytse wrote: post #65

I agree with not asking the developers of the feature. I don't think it should be part of product. QA is a deeply technical job. At GitLab QA gets own department called Quality. They are on the same level as development, design, development, and infrastructure. The people in it are mostly Software engineers in test. For more information please see https://about.gitlab.com/handbook/engineering/quality/

Some of QA is technical needlessly; we think that's a common issue with tooling today. QA today is just not accessible to folks that think about and manage change to the product, namely product folks. Why don't you think it should be part of product? Love that your department is called "Quality", implies more metrics-less-feeling before reading the doc.

> folks that think about and manage change to the product, namely product folks

It's weird to me that the software engineers building the product are not viewed as "product folk".

The people designing the architecture for and building the actual product aren't managing the changes to it or concerned about it? The people who have to address any defects in it aren't concerned about their processes as they pertain to quality?

This sort of worldview seems anti-agile and anti-lean TBH.

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

#156

Post by ozim »

ChrisMarshallNY wrote: post #150

In my experience (and I have a great deal of that), true product Quality is dependent upon an endemic cultural philosophy of an organization; not a single tool or technique. It's a shared discipline , and a cultural imperative. It's like those ads for exercise machines, where professional athletic models, who train for five hours a day, and drink broccoli smoothies for lunch, are shown using a machine for a couple of…

Totally agree.

You just need good enough quality and prevent total catastrophes that would drive customers away.

A lot of the time it is about making sure that stuff just works and not about testing edge cases - in my current company we did not really care about edge cases and I don't remember when we had an issue because of something like that. Mostly issues are popping up because people don't understand how things work or how they should work.

People not understanding how things work leads to "exercise machine" metaphor, because to keep all people updated with knowledge is hard work that needs to be done every working day and it is hard work that costs a lot of money. For this "test-automation" and "low-code" solutions are promising that you can put your domain knowledge into such "exercise machine" and have it regardless if you keep people or let them go, if they spend time learning about system or not. Which is a false premise just like "excercise machine" giving six-pack without much work.

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

#157

Post by sdevonoes »

Being part of a medium-size company I realise the reason to not have QA is to save money. When an outage occurs because "oops, we didn't catch that bug", the issue is fixed within minutes. I suspect this is fine for the company and I imagine that the cost of these outages is cheaper than the cost of dedicated QA teams. Besides, this "culture" of "developers should own their products from conception to deployment, including QA" is becoming more ingrained in all new companies. It almost seems as if developers should be in charge of almost everything... and certainly it does cut costs (at least in Europe where we don't have such salaries as in the USA):

developers should know about frontend, backend, databases, now the cloud, devops, developers should have a "product mind", they know monitoring, they should do paid on-call rotations, they should do QA, they should help in technical interviews, they should mentor juniors colleagues, they should do "dojos" and "katas", they are encourage to go to conferences and "share knowledge" when they come back, they should help onboarding of new colleagues, they should organize "tech talks", they should... and all with the excuse "we care about you growing as a professional".

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

#158

Post by jakubp »

sdevonoes wrote: post #157

Being part of a medium-size company I realise the reason to not have QA is to save money. When an outage occurs because "oops, we didn't catch that bug", the issue is fixed within minutes. I suspect this is fine for the company and I imagine that the cost of these outages is cheaper than the cost of dedicated QA teams. Besides, this "culture" of "developers should own their products from conception to deployment, inc…

If you were running a business, and wanted someone to do tech talks, or design/run interviewing for tech candidates, or have mentoring for junior devs, would you prefer non-developers to do it?

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

#159

Post by tester34 »

regularfry wrote: post #74
protomyth wrote: post #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 h…

This can absolutely be learned, enabled, and encouraged by the right guidance and, if necessary, training at the dev-team level. It's just part of the job.

for what kind of software?

if your product is e.g docker, git - then yea, easily

if it's soft for different industry, then complexity increases

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

#160

Post by woutr_be »

MattGaiser wrote: post #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…

I’ve experienced both, were the dev team also had to do QA, and a dev team with QA people.

I personally hated writing automated tests, but it did give me a much deeper understanding of the product. Especially when writing tests for features I wasn’t working on.

That said, having a dedicated QA person within the team is far more effective. The dev team can build features, while our QA person works with the business to come up with test cases and test data.

Post reply on HN