So You Want To Work in QA
By: Dee-Ann LeBlanc
Perhaps you like working with software, but you don't really want to be a programmer. Or maybe you're already a programmer, and you're looking for a change of scenery that doesn't require complete retraining. If these describe you, the areas of software testing and quality assurance (QA) can be tempting careers. Yet, many in the software industry—and outside it—have misconceptions about what these jobs entail. Often, people don't even realize that software testing and QA are not the same thing (except for in very small operations).
The Job Description
Try walking into a QA discussion forum like QA Forums and using the phrase “QA tester,” as so many people do. You'll learn that QA professionals make a clear distinction in the nature of the work. Software testers are the people who sit down with a program and pound on it, trying to find all of the bugs.
On the other hand, in many ways Quality Assurance personnel are the guiding hands throughout the entire development process: from going over the initial product specifications to participating in the business decision about when a product is ready to go out the door.
Ultimately, for a top notch product, you need both types of professionals involved in the development process. Sure, smaller companies often merge multiple roles into a single individual or share them among a small team. However, it's important not to lose sight of the areas where you lose out by not having an extra, fresh set of eyes. For example, on the QA side of things, someone outside the development team needs to carefully look over whether the software design document. Does it actually addresses the problems identified in the requirements documents? In testing, a fresh perspective is invaluable; you need to imagine every way a user might try to use your software, and then see which techniques break the program or causes, in the the more gentle phrase, “unexpected results”.
A Day In The Life
If you're still interested in becoming a Quality Assurance professional, then let's take a look at typical tasks you might be asked to do. It's impossible, really, to walk through a standard day, since what you do completely depends on where the product(s) you supervise are in the development process. The cycle begins by taking the requirements documents for the software and looking for holes, inconsistencies, logical errors, and omissions—thus, an “anal” attention to detail is a valuable skill in a QA professional.
Many QA professionals, such as Darrel Damon (a regular in the QA Forums), follow the SMART acronym as a guideline when inspecting requirements documents, making sure that all of the items included are Specific, Measurable, Achievable, Relevant, and Testable. “I spend 90% of my time in requirements' reviews, making sure that they meet these criteria,” says Damon. These checks can prevent problems from cropping up later on, such as releasing a product that doesn't meet your customers' needs; it's common for requirements to be laid out too vaguely and never clarified. That's the sure kiss of death for any new product or updated version.
After the requirements have been refined, the QA professional often looks over the design specifications with the same issues in mind; and then, perhaps, examines pseudocode before the programmers get started on real coding. During each iteration, QA compares what is offered to the requirements document, making sure that everything is properly addressed.
There are also standards to consider. Company policies may require that various standards are met by any product they release. The standards can range from usability issues (for example, features that allow for interfacing with screen readers for the blind); to how code is laid out, written, or commented (such as: every routine must be commented with a brief description of its intended function); to legal issues (are liabilities introduced through the help information?); to security issues (perhaps no data may be transmitted without using some form of encryption); to government compliance (some industries are heavily regulated regarding data acquisition and storage; to... well, you get the idea. It is often part of the QA department's job to ensure that all these individual standards have been met—and there's still more to it.
For example, QA tracks software defects (that is, bugs), including the number of bugs in the reporting queue that are not fixed, and the severity of those bugs. Eventually, it is QA who makes the “go live” recommendation. Typically, that means QA feels that all the severe bugs and most of the not-so-critical bugs have been addressed, and the product is of a good-enough quality to be rolled out.
QA may also be involved in Software Configuration Management (SCM or CM), which is similar to version control. SCM tracks each version of the software (every build, sub-version, and so on), exactly how that software was built (the compiler options), the version's default configuration, user configuration options — all so that testers and technical support can duplicate a problem scenario.
The Testing Type
Still thinking about going into QA? Then you'll want to look at your personality traits and skill sets. Are you detail oriented? Are you creative: can you look at a set of requirements, and at least somewhat picture what the result should be? A background in software development can be beneficial; if you've been a programmer, you will have a better feel for the “other side of the fence,” and understand what the development team wants, needs, and is trying to communicate. Being customer oriented is also useful, and it's especially helpful if you have the talent to see what and end user might need to do with the end product.
But don't worry too much if you don't come from a development background. In practice, the educational backgrounds of QA professionals are all over the map. Many people simply fall into the field. Perhaps they already worked as software developers and showed a strong aptitude toward this kind of work, and discovered they prefer it. In some cases, people slide over to QA from help desks, software testing, technical writing, and training, especially in companies where project teams include people from all of these disciplines. Others end up in QA through far more seemingly random circumstances, with bachelor's degrees in topics as not-quite-testing oriented as History.
Even if you don't choose this segment of the industry as the next phase of your career, it may help to understand the role of the people who work in your company's QA department. Buy 'em a cup of coffee to say Thanks for the work they put into your products, sometime.
... to read more articles, visit http://sqa.fyicenter.com/art/