I mean this in the general sense: for those of you who have made QA your career choice, why? I have read lots of posts here that describe why QA should exist and what people should do to get started and even if they should consider it as a career. So I put the question to those of you who have already made it your career: what is the number one thing about QA that made you stick with it?
Re: Why QA?
Well, for me it is a lot of things but you mention the "number one" thing. And I would say this:
It is the fact that QA is essentially technology and business-model independent. This means that QA will be there whatever inflection points we hit in the industry as a whole with minimal dislocation to its core precepts. Think of developers who have to constantly stay on top of new languages or additions to existing languages (i.e., Java, C++, Visual Basic, Perl, etc.). This is hard to do. Now add to that the markup concepts (HTML, XML, CSS, XSL, etc.) then figure on the different models that encapsulate those languages and markup such as Sun's upcoming Net Effect concept or Microsoft's .NET platform. Also consider the plethora of tools that come on the market that need to be learned in different capacities (Fireworks, Dreamweaver, Flash, Photoshop, Visual Studio, XMLSpy, etc.) Also consider the different strategies that exist in business models that development has to work within, the most notable one of late being the concept of "Internet Time." The one thing I always say is that it is true that "Internet Time" does necessitate a velocity-driven mentality, but that does not change the processes of quality assurance as much as it might, say, a development scheduling practice.
QA can whether any tide easily because the core concepts of QA are not dependent upon a given technology-base or even a given business model (which necessitates a business strategy) because its goal is to work within those models and with that technology. This is why QA can be applied in diverse environments that have JAD sessions or those that prefer "code-and-fix" methods, or in environments that perform Rapid Application Development as Efficient Development or utilize "Code Like Hell" approaches, or in environments that utilize strict UML concepts or those that adhere more to Extreme Programming. I could on but I will spare you.
For me QA is the utlimate "run anywhere" sort of concept because it is, if done right, designed to tailor itself to its host organization (much like a benign virus) and work within that to achieve quality to whatever degree possible; basically to spread its tendrils throughout the organization in a Body Snatchers-like fashion - sometimes utilizing what already exists, sometimes modifying what already exists, and sometimes establishing something that does not exist.
Bottom line: QA can change with the times with minimal dislocation. I call this being "future-mobile" and that is my number one thing: QA is future-mobile.
(Incidentally, all of the above should not be taken to mean that people in QA, and in its military branch QT, should not also be learning some of those concepts that are always changing but it does mean that the onus is not on QA to do that as much and thus it makes QA something very portable, maintainable, and modular - just what we like good products to be. QA just moves this to the level beyond the product, which is the methodology/process.
Re: Why QA?
<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by Murn:
I mean this in the general sense: for those of you who have made QA your career choice, why? what is the number one thing about QA that made you stick with it?<HR></BLOCKQUOTE>
It's fun, and I'm good at it.
I've worked pretty much all the steps of the SDLC, from project conception through product retirement. I've found that the piece in any project life cycle most in need of more efforts and champions is the QA piece. To do go a good job at QA you have to be curious and you have to be able to communicate with all the teams that work on the project from the marketing department and business analysts to the development staff to the end users, to help everyone do their best to get a good quality product built.
QA and testing is sometimes the poor step child that gets the "scraps" of budget, time, effort and attention. I like coming in and working to try to give the project testing some pinash (did I spell that right?) and class. I feel like I can really help make the difference between a buggy inaccurate product and one that works 'out of the box'.
I love to work with developers to help make them look good when that product hits the streets and it WORKS!
I deliver what I promise, and I only promise what I can deliver.
Re: Why QA?
Jean, Jeff - thanks for the responses. That is interesting.
Jeff - I said one thing. Your response indicates a few! Of course, I like you response once I sorted through your thoughts. QA as Body Snatchers. Hmmmm. There's something there, I just can't put my finger on it. As long as you seek peaceful coexistence. In going through a lot of posts I notice you don't like to answer with a short blurb but I guess I get your point. You seem to be saying that QA for you is basically capable of carrying you into the future without you having to worry about keeping up-to-date with a lot of the technology. Is that right? And why can't development have this future-mobility.
Re: Why QA?
QA as Body Snatchers might go over a little better than QA as Borg. What is better, slow insidious possession or outright assimilation? As far as the peaceful coexistence - but of course - just step into this peapod here...
Anyway, what you state as my point is not quite on target. I am not saying that I do not have to worry about keeping up-to-date. On the contrary, I have to keep up not only with the technology but also with the different business practices, inflection points, methodologies, etc. So, in that sense, I cannot specialize like a developer, who decides only on Java or C++, can do. But the difference is that my focus can be a little more high-level than the strict developers. I just have to know how to help developers along with their process and then know how to test the results of that process - but I do not have to know how to code the application itself.
But, even with that, it is helpful for me to learn about code optimization, code constructs, etc. It is just that my focus is different and I can be a little more relaxed about the exact details. In other words, I sacrifice seeing some (perhaps even many) of the trees but I have a great view of the forest. The developer, by contrast, has a fantastic view of all the trees but does not have to worry about the forest layout. That analogy will stretch a little thin and I would need to add a lot of caveats (such as the "forest" encompassing much more than just coding, including such things as requirements, design, etc.) so I will pass on that for now. Hopefully I clarified my position a little better.
Having said all this: I like Jean's response as well and that is my "number two" reason for QA. I believe that there really is a QA mentality that leads one to a quality philosophy, of sorts, and it is basically just a driving effort to "make things right" or "make them work." This is a very powerful effect of QA/QT, particularly in an industry where the major differentiating factor is becoming the quality of the product rather than its feature set or glitzy interface.