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!


Now read this

Multi-feature staging environment(s)

It is hard to work on several versions of a web app and demo them to other people on the Internet (or in an organization). In other words: how do you elegantly deploy all of your git branches and make them accessible on the Internet? The... Continue →