Testing for Developers: why you should be doing Unit, Integration and QA Testing | Hacker News Reader

Testing for Developers: why you should be doing Unit, Integration and QA Testing

blog.rainforestqa.com

19 pointsukd16 comments

"By leveraging internet services like Amazon Mechanical Turk, we can significantly reduce the cost compared to in-house testing and even outsourced testing."

Unfortunately, this means that your testers are going to include random people who know nothing about your application or your domain - and very little about testing (why would someone who was a trained tester settle for Mechanical Turk wages?). They might find some obvious problems, but they probably won't find subtle problems. Unlike a QA team that works closely with a team of developers, they won't be able to offer you meaningful feedback about how you could improve your product. And if they're going to be paid low wages to test code written by people they've never met, they're really not going to care very much about doing a good job. As in most cases, you'll get what you pay for.

QA is all about situational ethics. It's the very epitome of tactics and triage. Unit testing, integration testing, black box,beta testers, internal QA, outsource...-they are all arrows in the Quiver. Anyone who tries to sell you one fits all is setting your snakeoil.

Nice way of dealing with a near religious debate within the dev community. Huge fan of TDD from a process perspective, sometimes it can feel like ice skating uphill selling it though - well written and supported post.

>Having an internal QA team is not a practical solution if you want to deploy your application frequently.

By having testers who are not connected to your company nor care about its success, you overlook a crucial feature of having in-house QA. It doesn't have to mean weeks of non-stop manual regression testing. It means having a team working in tandem with developers to create unit, functional, and integration tests for rapid deployments.

I've used mechanical turk and similar services for data entry and other repetitive tasks, and it can be useful. But quality, usability testing, and sanity checking are the last areas I would consider handing over a mechanical turk service.

The notion that "In-house QA is killing your business" is one of the most laughable tech articles I've read all year. The hyperbole from Rainforest is over the top.

Agreed. If you cannot deploy frequently with in-house QA, it's because the in-house QA isn't doing automation, not because you haver in-house QA

Your product can be the best. But i, like google and others use siesta-js for unit tests and interface tests with mouse simulation. Its all js and runs natively on every browser

See the demo: http://www.bryntum.com/examples/siesta-latest/examples/brows...

It can record your actions and generate the tests.

Worth looking.

Reply on news.ycombinator.com