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

Ads

#Ads. All around web, for the past couple of months, I was targeted and retargeted with all types of different ads, relevant to my various google searches, browsing, clicks, etc… Business as usual. 2 hours ago, over Google Hangouts, I... Continue →