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.
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
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.
"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.
>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.
6 comments
[ 5.3 ms ] story [ 23.2 ms ] threadSee the demo: http://www.bryntum.com/examples/siesta-latest/examples/brows...
It can record your actions and generate the tests.
Worth looking.
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.
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.