On testers and testing

Note that Evan Priestley's post on Facebook and testing, linked in the article, ends with the statement "This process works for Facebook partly because Facebook does not, by and large, need to produce particularly high-quality software."

> Inspired by this post on Facebook’s testing http://www.quora.com/Is-it-true-that-Facebook-has-no-testers

and in this post "Ex-Facebook employees have some privileged channels they can use to report issues; I personally report around 13,000 bugs per month"

huh? That's about 18 bugs per hour on average. Does it say that the guy on quora is working for them on bugs although he's not an employee, or am I missing something??

This issue with testers in my experience is that anyone who is a really, really good tester has the skills and determination to very quickly move up and out of testing.

“Most product teams don’t need a separate testing role”, quoth the author. And he may be right. Most products don't need to be of high quality. Most products have few moving parts and few things that can go wrong. If your product is a web application, you can fix stuff quickly once your users start complaining, too.

But then there is the kind of software that must not break, ever. The kind of software that is so complex that every time a developer touches it, he is bound to break something, somewhere, because no human can keep all that complexity in his head.

Your operating system falls into that category. Your web browser. The machines that bring humans to the Moon, keep you alive at the hospital or your car on the road. You know, the difficult stuff.

I've spent a few years as test manager for a web browser engine you may have heard of. The team consisted of some of the best developers I've ever met. Razor sharp guys. But despite their brilliance: for every bug fix they did, there was a 30% chance of them breaking something. In the most complex parts of the layout code, that number was closer to 50%.

50%!

Having less than one tester per two developers on that particular project would be madness. And I'm not talking about outsourced monkeys pushing random buttons ten time zones away. I'm talking about people more evil than the devil himself – able to conjure up the kind of tests that will rip your software to pieces in ways you could never imagine. I'm talking about proper test engineers that can automate away all that boring shit humans don't want to do.

A sparring match between a great developer and a great test engineer is truly a thing of beauty. And in the end, both of them win.

This is not what I've seen. Large organizations are resistant to change, but it doesn't mean they test anything. I used to work for Bank of America. bankofamerica.com was down for over a week, despite a change control policy that basically prevents code from ever going into production. Big organizations like policies, but the people that make the policies do not have the knowledge required to implement or enforce them. And when they do, they don't work anyway; you can wish for perfect software, but when you hire dumb people to write it for you, it's going to break.

Big companies don't want downtime, but they hire non-programmers to make this happen. The result is downtime.