--- title: "How uTest will destroy your Quality Assurance" url: "https://osherove.com/blog/2007/12/18/how-utest-will-destroy-your-quality-assurance.md" canonical: "https://osherove.com/blog/2007/12/18/how-utest-will-destroy-your-quality-assurance.html" published: "2007-12-18T17:47:44" updated: "2007-12-18T17:47:44" tags: ["Agile"] author: "Roy Osherove" description: "I just read on TechCrunch an article by Roi Carthy that UTest will allow \"Crowd Sourced\" QA solutions, where companies pay per bug and get QA done by many anonymous QA people around the web. I'm not sure what scares me…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # How uTest will destroy your Quality Assurance By Roy Osherove December 18, 2007 In [Agile](https://osherove.com/blog/category/agile) **Historical article** · Originally published December 18, 2007; technical details may be outdated. I just [read on TechCrunch](http://www.techcrunch.com/2007/12/18/utest-gets-17m-for-crowd-sourced-quality-assurance/)  an article by [Roi Carthy](http://www.roicarthy.com/) that [UTest](http://www.utest.com/) will allow "Crowd Sourced" QA solutions, where companies pay per bug and get QA done by many anonymous QA people around the web.  I'm not sure what scares me more. let's begin with one comment on this article that reads: > "who would give their unfinished product to strangers before it rolls out ? > > do they have hte business knowledge to do so?" Great question indeed. to which some QA person responded in the comments(bolded by me): > "It happens all the time. **QA is not a very high priority in most companies**. I work for a company that does outsourced QA for other companies. **Most companies provide us with no knowledge about how their product is supposed to work** except for the product itself. **We do the best we can** and help them make a better product, **ideally they would provide us with more information, but they don’t want to spend the time and money** so we make do with the situation. We test a few hundred software apps a year like this for various companies and are located in the US. Most of the apps are not programmed in the US and have silly errors that you would not have, were they written by an American or someone working on site with the company with the program idea." So, this is chaos all over again. Not only will uTest not benefit the sate of software quality by lowering the bar for low quality quality assurance, but they will let companies think that this is a good thing! The problem is most companies think QA is such a problem that can't be solved anyway, they may as well spend even **less** money on it instead of changing the way they work. **Problems that won't be solved:** - QA will only find minute and superficial bugs. - Repeating test cases will still be a problem since it will not be automated. - automation will be a problem because there is no model of "pay per automation" or better yet "pay per bug reproduction automatically" - Like smoking "lite" cigarettes, companies will find that re-teaching the product to new anonymous QAs every time will actually cost them more instead of getting one solid QA team that **knows** it - Communication is something which cannot be thrown away.  If it is, companies will find that the product quality level will actually be lower, while quality **expectation** will be higher. **Note**: I have sent a membership request to uTest so that I can explore the things I could do as a company wanting testers, so I can get a fuller picture.. The problem isn't uTest. They will make lots of money of the backs of companies who think testing is something you do at the end of development and costs less than development. The problem is the reality is perpetuates - a reality where testing is shoved aside. Can you imagine a company doing the same anonymous type of outsourcing to its development process? Oh wait, this happens too. [The results are quite distressing](http://www.intelligententerprise.com/showArticle.jhtml?articleID=189600721). **What can you do?** - Get a proper **serious** QA team (people that also know programming) - have them be part of the development team (tester per team at least) - Automate as much as possible - Every penny you save on your QA is a dollar you lose on quality later on. - Get some serious [Consulting](http://www.exampler.com/blog/) to help you. ## More in Agile [All posts in Agile](https://osherove.com/blog/category/agile) - Jan 9, 2008 ### [Scala, NRehersal and Fluent Test Interfaces](https://osherove.com/blog/2008/1/9/scala-nrehersal-and-fluent-test-interfaces.html) - Dec 31, 2007 ### [Joining TypeMock](https://osherove.com/blog/2007/12/31/joining-typemock.html) - Dec 18, 2007 ### [Basic Guidelines for using RowTest and data driven tests](https://osherove.com/blog/2007/12/18/basic-guidelines-for-using-rowtest-and-data-driven-tests.html) - Dec 18, 2007 ### [\[RowTest\] for NUnit, File System Interfaces for unit testing](https://osherove.com/blog/2007/12/18/rowtest-for-nunit-file-system-interfaces-for-unit-testing.html) --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/