11–20 of 21 posts
> 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 someth…
“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 comp…
When you need to go back and forth on a bug 4 or 5 times, every time the programmer claiming it was fixed but failing an old test case, a test group won't fix the problem, programmers taking responsibility to ensure their own code is correct will.
> 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.
Absolutely. Unforunately, if the tester is not up to snuff, they're no help against a great developer, and a great tester against a sub-par (or worse, insecure) developer is nothing but trouble, no matter who's right.
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.
Earlier quoted context omitted.
Though Evan's post made me write this, I'm actually talking about different aspects to testing than he is. But to respond to you - neither do a lot of others (need high quality software i.e). Agility->quality is a continuum. On one end, you can instantly deploy any piece of code to prod as soon as it is written. On another end, you test code for several years to make sure it is rock solid (stuff that goes into nuclea…
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 the…
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.
I really hope this changes in the future. I don't think testing gets nearly the respect that it deserves. I have thought about making the move from dev to test but I know that there are very few organizations that give the same level of respect to the test team as they do to the development team.
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.
Testing is a VERY different skill set to dev. While good tester have coding skills, and understand concepts like design patterns, most of their knowledge is in failure modes of systems (inc. software), and how to identify/prevent these. Often they have security or performance testing skills on the side. Almost always they have automation skills. If a company does not understand that these skills are as useful as a developer, or BA etc, then I suggest that the tester needs to move firms - from experience there a plenty of firms that do value these skills.
Earlier quoted context omitted.
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 the…
I work on medical software for a large bureaucratic company. We have a large QA department and more processes and sign-offs than I have ever seen before. The software is the lowest quality software that I have ever worked on.
Second, it's not fair to go easy on the quality of test/QA folks. This is where a lot of organizations that actually invest in dedicated testers fail. Testers must be held to a similar bar as developers, just with a different functional role. As others have pointed out, the disbalance that widely varying talent levels cause in organizational health is quite disastrous. It's the same as any other piece of hiring. Make sure you have the right person for the job. That almost always means someone who knows computers/code/workflow/users at the same level as developers or product managers.
Finally, as a former Windows engineer, I don't agree with the narrative that the Vista fiasco was a result of over-automation and not enough end-user scenario testing. It was more a problem of poor processes that couldn't handle the scale of the team and a lack of clear planning/leadership to account for that. Windows 7 had, if anything, more automation and more testers than Vista and was obviously a much better product. A lot of things have to go wrong to get something as ugly as the Longhorn Reset (http://en.wikipedia.org/wiki/Development_of_Windows_Vista#Mi...) and the one that OP pointed out was likely one of many.
Earlier quoted context omitted.
I really hope this changes in the future. I don't think testing gets nearly the respect that it deserves. I have thought about making the move from dev to test but I know that there are very few organizations that give the same level of respect to the test team as they do to the development team.
Google's test engineers are pretty impressive. I am convinced that they are better developers than the average developer at most companies.
Earlier quoted context omitted.
Why? Seems like a fair-enough term.
It was meant as an ironic joke, I wasn't serious. Re-reading my comment I guess it doesn't come across as a joke, should have put a smiley :)