by tariq on 9/23/11, 1:16 PM with 58 comments
by absconditus on 9/23/11, 3:37 PM
* The people who are good at QA usually have the skills to work as a developer. QA is generally not as desirable as development to a young developer, so why do it?
* Many QA people are almost completely useless and exist just to generate paperwork so that the company can cover its ass. Warning signs for bad QA people seem to be certifications and fear of anything that does not strictly adhere to classic waterfall development. The bulk of all defects are found by a small number of people on my team.
* Most developers are horrible at testing and writing unit tests. We have thousands of unit tests and the main thing that they catch is that someone did not update the test after refactoring code.
by kabdib on 9/23/11, 2:16 PM
"We need a test framework" are terrifying words to me. It means that I (the dev) will have no one at my back. It means that tests will be written by junior QA engineers (the senior ones are off writing and maintaining the framework, right?). It means that I am responsible for my own tests, because /no one/ else besides the customer will be testing my code.
That's generally all right; I think I do a good job. But not everyone does; some devs think they can toss code over the fence to a group that will tell them if it worked or not.
Everyone is responsible for quality; Devs must do unit tests, but they have blind spots and that is what QA is for, namely higher-level assurance that things are working as intended.
by imperialWicket on 9/23/11, 1:56 PM
QA needs to be done, and it needs to be funded. Everything you put into will return in less development time (overall, not necessarily in the short term), and more satisfied users.
by wccrawford on 9/23/11, 1:51 PM
That MMO that is getting away with using customers as QA, and only fixing bugs that NEED fixing? I bet they're making a nice profit. I'm sure the customers are annoyed, but in my experience, gamers won't quit playing over bugs. Bad customer service, price hikes, etc... Sure. But not bugs. Even if they stick around for years.
However, business applications are a different story. Businesses can't afford to be stopped from doing what they need to. And a QA person makes all the difference in the world there.
For those that don't understand why, a programmer can't find their own bugs because they've already done their utmost to find bugs in the code. They've already stretched themselves to the limit before they sent the code to QA. You can train, coddle, beat, or otherwise influence them and only get a few more bugs found by programmers. It's much better for everyone's sanity and wallets if you just pay for proper QA.
by Yhippa on 9/23/11, 2:25 PM
That is parts like coding and deployment were necessary because they actually were important and helped move business ideas to the customer. QA to them was a redundant step. This coming from a shop that avoided automated testing because it was too expensive.
I was disappoint. QA to me is insurance against being human (which we all are). The ended up not getting rid of QA but the fact that they seriously considered it was shocking.
by dustingetz on 9/23/11, 3:13 PM
i would never say that "we don't need no stinking QA", but i do believe that teams who live by "think and analyse" need QA a lot less than teams who don't.
[1] http://www.dustingetz.com/linus-think-and-analyze-motherfuck...
by DanielRibeiro on 9/23/11, 4:31 PM
On the other hand, when you are building your MVP, progress is not built features, but validated learning. So QA tasks takes more of an approach of building measuring tools (which have to be done by the people building the MVP).
Even on a later stage startup, QA takes a whole new role, specially when you start doing continuous deployment and start developing immune systems. These can get quite complicated (think of Netflix Chaos Monkey[1]), and having a dedicated team can be beneficial.
What we don't need is a 20th century waterfallish QA. But ensuring the quality of a product[2] has never been more important.
[1] http://www.codinghorror.com/blog/2011/04/working-with-the-ch...
[2] http://www.ashmaurya.com/2011/06/your-product-is-not-the-pro...
by steve8918 on 9/23/11, 3:27 PM
I work at a company where they have a 5 year old product, and the mentality at the time was "Yes I know it doesn't make sense but if the user does X, then it could cause the server to crash, so let's do Y." This grew to a series of matrices that has now turned the act of adding 1 single feature into a 3 pages worth of "If A then B, otherwise C". This has made the QA effort in terms of testing incredibly complex, and even developers get confused as to what is supported and what isn't.
For example, there is an instance where copying a directory takes a different code path than copying a single file. Why? Because they wanted to "special case" this situation. It makes the functionality and behavior utterly unpredictable.
The takeaway that comes with experience is don't spend too much time trying to prevent your users from doing stupid things. If they want to do stupid things and the system crashes, it's okay to say "Don't do it, otherwise it will crash." This keeps your feature set, your code, and your QA effort much cleaner and more maintainable over the long haul.
by ecaradec on 9/23/11, 4:28 PM
Users and bosses thinks they have done more than their duty when they said you that "it doesn't work", "nothing work" without more details. You have to run after them to get more context and detailed information.
I love QA.
by bobbles on 9/23/11, 2:25 PM
One of the major problems can be keeping the newer people & graduates interested in the testing & QA process. There can be a lot of 'grinding' through test cases and I guess it takes a certain mentality to get through it on some days.
by hello_moto on 9/23/11, 5:37 PM
I've been a QA, QA Developer, Developer, and Integrator during my internships.
QA is often the less honoured role of all. This creates a stigma that QA is some sort of crappy role to be in.
Being second class citizen requires more support than ever to work at the top day to day. Unfortunately, most people are not built that way so quality degrades because QA was treated like crap.
This leads to less advancement in the QA community because it's not a good role to be in. You only see a few books and a few noted experts in the QA community that continue to push better practices.
At the end of the day, it's a loss for all of us.
I wish there's none or minimum differences between QA and Developer as I agree with one of the comments here that if you do that, there will be more jobs created and IT professionals can experience different roles within our world.
My opinion is that QA should have a wide range of skills from load/performance testings (that means knowing the tools and statistics), automation testings (that means if DEV created hard-dependency issue that is not easily testable, QA should step in and teach DEV the patterns and best practices to avoid such situation), QA should understand business practices to beat up stupid Business Analysts.
More importantly, QA should keep track deficiencies and ineffectiveness during the development and potentially offer solution (or can be done through group discussions).
Unfortunately, that's not how the world works. Telling someone that he's not efficient or pointing out where the most bugs occurred when the team lead is the one whose responsible for the feature isn't desirable.
Not to mention that certain type of companies don't necessarily get the most ROI from having QA (if your typical Web 2.0 social networking tagging machine had a few issues, users probably complain but everyone will move on).
by bitmage on 9/23/11, 5:52 PM
The company had literally fired the whole testing department previously for saying the product wasn't ready. With those annoying testers out of the way, out the door it went. And promptly had multiple emergency point releases the following week to fix showstoppers cropping up at the customer sites.
That got them to create a testing department again - but it was still without honor in the company. And firing the whole group again was often discussed, as they were _still_ delaying releases by finding bugs!
I departed. They got eaten in a merger several months later.
by alain94040 on 9/23/11, 6:55 PM
by jrockway on 9/23/11, 5:00 PM
QA is nice, but it's a finite resource that you should save for things that actually matter, not stupid things that a computer can fix for you in 30 seconds.
by mrgoldenbrown on 9/23/11, 2:38 PM
by pavelkaroukin on 9/23/11, 4:14 PM
by YetAnotherAlias on 9/23/11, 2:18 PM
by aidenn0 on 9/23/11, 4:56 PM
by Shenglong on 9/23/11, 4:09 PM
When you're doing QA on a product, do you worry about border cases? I found quite a few bugs related to time syncing and inadequate safeguards in a project I worked on - but they were difficult to reproduce without a macro.
I'm still not sure whether people were happy or angry with me, for reporting all those bugs.
by jfricker on 9/23/11, 3:58 PM
by TwoBit on 9/23/11, 7:22 PM
by greenfield on 9/23/11, 4:48 PM
by pointyhat on 9/23/11, 3:21 PM
The only reason they needed QA is the software was a giant toilet-clogging turd. There were no formal unit or integration test cases so it was used to catch regressions against massive test plans knocked up in Excel, Word and god-knows what else.