QA? We don't need no stinking QA
thecodist.com
QA? We don't need no stinking QA
1–10 of 62 posts
Re: QA? We don't need no stinking QA
#2I mostly agree.
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.
Re: QA? We don't need no stinking QA
#3I mostly agree. 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…
"However, business applications are a different story."
You've sure got that right. Our application conducts real-time purchasing events (reverse auctions) where bidders are ranked based on a couple of different configurable algorithms. An error in calculation means incorrect ranking, which means the entire outcome is invalidated. Considering that it can take weeks to put together a purchasing event of this type means that there is a lot riding on that single series of calculations.
Simply releasing and finding bugs in production would be financial suicide. QA isn't even a question in our business. Everything is tested thoroughly when it goes out the door.
Re: QA? We don't need no stinking QA
#4I could not agree more. And not only should all projects include QA, but they should include QA by an actual quality assurance analyst or team. QA performed by minimum wage (or low payed) temps or short-term services tends to be next to worthless. Also, don't even think about using a spreadsheet to track issues.
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.
Re: QA? We don't need no stinking QA
#5I mostly agree. 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…
Lately my interest has been piqued by analytical code verification techniques and/or fuzzing (going beyond simple static verification or "checking the code style").
I think a lot of bugs made in day-to-day coding could be found given such methods. It would be best to integrate something like that into the compiler (and IDE) as it has the necessary information and structures. I believe the clang team is working on this (http://clang-analyzer.llvm.org/).
I guess it'd require defining "higher level" pre- and post conditions and assertions and such in the code...
Not a substitute for "proper QA", but I think sometimes that "software engineering" is simply dabbling in the dirt as a engineering discipline, a computer could probably run the function you are editing right now 1000000x per second and/or verify the hell out of it while you are thinking about the next letter to type :p
Re: QA? We don't need no stinking QA
#6I mostly agree. 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…
"However, business applications are a different story." You've sure got that right. Our application conducts real-time purchasing events (reverse auctions) where bidders are ranked based on a couple of different configurable algorithms. An error in calculation means incorrect ranking, which means the entire outcome is invalidated. Considering that it can take weeks to put together a purchasing event of this type mean…
I write software for clinical trial data collection, so I'm in the same boat. Not only is every product tested, but QA must thoroughly document their tests. At the end of the day, yeah, it slow the process down, but the software is significantly more robust when it heads into field.
Having worked at many companies that didn't believe in QA at all, I think having a team of testers is beneficial not only for software quality, but also filtering potential bug reports from the field. When a client reports a potential, QA does the initial leg work in duplicating the issue, then passes it off to engineering.
Re: QA? We don't need no stinking QA
#7On the other hand, I've seen QA groups who do no QA at all. Instead, they do frameworks.
"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.
Re: QA? We don't need no stinking QA
#8I don't have much to add to the discussion. I just want to vent a bit of frustration. I came in this morning and found out that 7 of my co-workers were just laid off. We are a 30 people company so thats quite a big deal. And some of my good co-workers in QA were axed. I guess some management guy thought QA was unnecessary. Oh this seems to start to look like 2008 all over again!
Re: QA? We don't need no stinking QA
#9One financial services company I worked at a long time ago was getting caught up in the Lean hype. We did process maps of nearly everything including our dev process. They put a big red circle around the QA piece noting that it was a candidate for elimination since it was not value-add.
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.
Re: QA? We don't need no stinking QA
#10I'm really glad to be working for a company that has the QA team involved from requirements to production (& maintenance thereafter).
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.