Let your users do QA

QA [quality assurance] is a step in your web development cycle. As soon as you create a role/job/department for QA whole tech team will delegate QA to that person/department. Eventually, when something goes wrong you’ll start the blame game…

QA should be done by CI automation, devs, PMs and by users.

What?! By users?!
— Yes. And it does not have to be a negative experience. It might and should be a positive one. Maybe only by a certain group of your customers — loyal, brave, privileged users, “innovators” and “hackers”. Give them a discount for every bug they find! Encourage, be vulnerable — they’ll sympathise and be your advocates.

Remember how Facebook engineers translated the site in other languages? They crowdsourced it from their users. Users did not get upset at all — they treated it as a game, challenge.

 Ideas on how to actually crowdsource QA:

Prior to deploying to “beta-production”, run through automated test suite, your CI and CD systems. Automate as much functional UI testing as possible. Cover critical paths.

 Putting these ideas into a broader context

Generally, you should aim to have as few people in your team as possible. This will significantly improve communication, speed up execution and make performance of each team member measurable. Why would you want to have individual performance well measurable — tldr, to reward people proportionately to their contribution. Paul Graham has more insights on the topic.

What are your thoughts on this? Let me know here. Thanks!

 
12
Kudos
 
12
Kudos

Now read this

Decoupling frontend from backend

Hopefully, you’ll not find anything revolutionary or cutting edge in this article, but in case you’ve been working on a X-year long project in a conservative organisation, you might find these words useful. How to keep frontend separate... Continue →