Hacker News Reader

Comment by vallode | Hacker News Reader

QA is a massively underappreciated position. A QA person that knows when to automate, when to manually test, and how to report and file issues relevant to the project can save a significant proportion of hours on a project overall. I wish many more companies included budget for QA, it saves developers a lot of time.

A bit of a side-note: this sort of analysis is a great answer to "I want to contribute to open source, how?". Some fairly simple wins for significantly better user experience, and no coding required!

View on HN

Good QA people are hard to find and it's a weird balance to strike.

I've seen QA get run over by aggressive developers.

I've seen QA people who were so good, detailed and provided clear reproduction steps that developers couldn't wait to see them work.

I've seen QA people who were completely unwilling to work on efficiency improvements, automation or even testing things in parallel so they became a bottleneck to the entire organization.

I've seen QA people who just fall into a routine, do exactly what is asked of them and never try to improve.

Like with anything, it comes down to the person in the job. If you get QA people who are really committed to the work, take pride in what they do and are always trying to improve it's the dream.

When you don't have that, it's a very mixed bag.

From manager perspective, no matter what people do you have at start of the journey, the team culture can be changed. Most people are willing to learn something new and try new processes if they see the value. In more than 20 years I have seen maybe 2 or 3 pathological cases, where a person had to leave the team rather than play by new rules. It is not easy, it may take time for the team to adapt, but that’s a manager‘s job to unlock the potential of every team member and that job is doable.

>Good QA people are hard to find

In general, I'd say that's because it's a position that's shit on.

You're apt to be paid far less than actual dev positions. If you're a QA manager you're always pushed on by upper management to outsource and lower costs. There is none of the prestige of being a "QA 10xer" that you'd see heaped upon a dev in the same position. And I see little training/courses pushed out for QA like is typically seen for dev.

It seems like QA in most companies is a necessary evil that management would take out back and shoot the first moment they could.

Developers are artists and QA is critique. Worse, you must entertain their complaining, and pay for the privilege! The vultures. (This implicit bias would explain the treatment disparity. But it's a baseless hypothesis. It just seems like the simplest behavioral explanation.)

It’s semantics, but thinking of QA as refinements rather than criticisms goes a long way. Everyone is reasonable until their mental defenses are activated I believe. I think it’s worth making even great efforts to communicate improvements or requirements without using phrases which make someone feel bad. If the goal is to actually persuade and make a positive impact rather than just point fingers to feel superior, finding the way to say things without assigning shame is almost always the way to get things done.

Good QA will be sensitive to this when creating feedback, and good Devs will understand that tunnel vision from submerged in the product full time every day will typically lead to a built experience that isn’t amenable to large portions of their users.

Providing QA feedback tactfully is an impressive and appreciated skill, as is receiving feedback gracefully. Everyone should aspire to do both.

> Good QA people are hard to find

True.

A good tester is the kind of person who revels in running the same lab experiment many, many times and chortles for always getting results within the error bars.

A good QA is the kind of person who can think of every way something will fail, and then come up with a proactive risk mitigation strategy that makes everyone smile with pride.

> QA get run over by aggressive developers

True.

Back when we had QA/QC, my "One Weird Trick" was to put the QA / Test team in charge of releases. Running the bug triages, in charge of acceptance testing, running the go/no-go meetings, etc.

Worked f@#$ing great. Almost like magic. Zero drama. Our releases were almost anti-climatic.

I miss the '90s.

Well, I miss my '90s QA/Test experience.

Most everyone else was stuck in Kem Caner's world. The preeminent "SQA" guru who preached victimhood and grievances. Probably did more than any one to pile drive the QA Test profession into the Mariana Trench of irrelevance.

(Apologies, weak sauce, I know. I usually have a better "colorful metaphor" ready to deploy for these types of rants.)

If one knows a great QA person, any recommendations on companies that appreciate that talent?

The old wisdom in the US, is that if you have "Quality" in your job title, your career is over.

At the Japanese company that I used to work for, it meant that you were one of the most powerful people in the corporation, and was a sought-after adornment.

Different strokes, and all that...

I always give the power to my QA team to block any release no matter what and to give higher priority to tickets than product manager. If CEO wants to override, I cover them and take the blame. This is not a guarantee that there will be no bugs in production, but it saved us a few times.

The Japanese testers were the best I'd ever seen.

They never reported a "NotABug." They could back up every report, and give exact reproduction steps.

They found weird, obscure corner cases, and that was by hand (they hated automation tools).

They had 3,000-line Excel spreadsheets. If even one of those rows failed, the whole shooting match (like an entire product line) could come to a halt (so that meant they had to cross their t's, and dot their i's).

They seldom had "opinion-based" reports, and, when they did, the report was presented by the manager, after long discussions.

The company I worked for, was renowned as one of the highest-Quality optical corporations in the world.

I worked with NTT Docomo years ago for a short time. First time I ever got to see a CMM Level 5 organization. It was insane. No wonder Japanese cars were so much better than everyone else for so long.

If you ever get the chance, take it - you will learn way more about software quality than you thought existed!

>No wonder Japanese cars were so much better

Heh, this reminds me of an episode of Top Gear I was watching years ago about quality of British cars. They said something along the lines of "The manufacture sais 'eh, good enough' the moment the car is able to move under its own power.

Anyone who has owned a Mini would probably question whether their QA even gets that far.

Do you have any insights into why desktop and mobile software from these companies is so universally horrible? I’m thinking of Canon’s remote tethering tools, Fuji’s instax and remote control apps for iOS, and Epson’s scanner software.

I don't want to get into slagging these folks, but I feel your pain. In a big way.

Hardware != software.

Hardware companies have a really difficult time, understanding this. They insist on running in-house software projects as waterfall-based-measure-twice-cut-once-never-accept-a-bug-count-greater-than-0.

Anything different is "bad quality cowboy."

It can be difficult. I rapidly learned not to use the word "agile," within earshot of many senior types.

This applies to US hardware companies, as well as Japanese ones.

Most folks, hereabouts, seem to think of me as an unbearable, retentive, snob, but my former managers would often think of me as an undisciplined, reckless, slob.

thanks, I appreciate hearing your perspective!

Fujifilm software is outdated garbage. UX was developed probably during WinXP era and still present. However their cameras are excellent.

> They never reported a "NotABug."

"Every ticket should result in a code change, *or* a documentation change"

was one of the coolest sentences I ever read on some web page.

Reply on news.ycombinator.com