Some Common QA misperceptions and reason why they are wrong:

Myth #1: Anybody can do QA

 Wrong. Testing is a skilled activity that requires the ability to think, explore and follow logic while questioning and reasoning at the same time. It is based on the philosophy of performing a technical investigation of a product, to provide information and report back to various stakeholders throughout the organization. And to achieve the end result of communicating back your findings, you will need to use various types of infrastructure and experimentation, logic, models, mathematical probabilities and supporting tools to build the appropriate Test Case scenarios. And don’t forget that QA teams usually have very limited product documentation (if any), and have to work in a very time-constrained schedule. Sorry, you just can’t take anybody off the street to do QA. It takes a skilled, intelligent professional who understands the needs of the organization and is ready for the task!

 Myth #2: Any out of school kid can test our applications

 Wrong. Your applications are a critical company asset. Depending on the nature of your business, direct profit and revenue can be impacted if an application goes down or performs poorly. And of course, a company’s reputation can also be seriously damaged when things don’t “work” right. Think about it. Will you hire an inexperienced, out of college kid to take care of your critical investments and financial assets? If you answer yes, then I would say sure, go ahead and hire an out of school kid to test your applications. Otherwise, please hire professional, experienced, skilled testers or QA Engineers (with or without certification, that is another debate point in itself) to build your QA team.

 Myth #3: A QA Engineer is a “Developer wannabe”

 Wrong. While it is true that some QA engineers like to get into the code, and enjoy using automated scripts, there are other folks that prefer a “thinking & building test cases while executing manual tests” type of approach. Probably within your team you will even have a mixture of skill-sets and different personality types. Similarly you will have folks that started in QA, landed in QA from a different career, are considering a career change, or want to remain in QA for the long term. What is important to remember is this - QA is a valuable professional field that requires intellectual efforts similar to those required to develop a product. Think about it. A QA Engineer is developing the plan that will ensure the success of a company’s product in the marketplace.

 Myth #4: QA doesn’t provide much value to the organization

 Wrong. QA represents the heterogeneous users of the products that your company produces, so they are there to improve product quality, ensure a better user experience and reduce support costs. Let’s take a quick look at some of the responsibilities that QA has within an organization. QA engineers are in charge of finding and reporting bugs (from critical problems to minor enhancements or documentation changes), and verify that bugs are fixed (and that nothing else broke because of code changes). In addition they typically work very closely with development, product management, customers and other internal folks to understand product functionality and use cases, as well as build appropriate test plans. They are the ones you want to vouch for the adequacy of your user documentation while it is being finalized. To top it all, QA teams assess product conformance to specifications and standards, while checking interoperability with infrastructure, complementary products and/or third party vendor products. Lastly, they have the final saying of when a Beta and/or GA product can be shipped to customers, so they can block or veto a premature product release. Impressive, right? To say that QA doesn’t provide much value would be gross misrepresentation of the truth.

 Myth #5: QA is a boring, repetitive job with no creativeness involved

 Well, this one could be partially true, depending on the internal processes that you have in place. For example, if QA is not involved with a project from the beginning, there is not much room to bring new ideas or feedback to product’s requirements. And this could translate into lack of empowerment, and not feeling appreciated. Another scenario could be if you have no automation in place, and there are truly repetitive tasks and regression testing steps that could in fact be automated in your environment. (I am not talking here about 100% automation either, but about finding out the right balance that makes sense for your organization based on your applications, environment and objectives). And, of course, boredom could set in within your team if you have internal processes that require hundreds of pages to document simple test cases, or if internal policies are based on a “write all that you do” type of approach. You need to be sensitive to this and avoid creating unnecessary procedural quagmire.