Individuals who hold technical QA positions may believe there is "too much theory" within the industry. Conversely, an individual who operates externally from a theoretical point of view would say that QA involves too much technical phenomena. It is a paradox that these "micro" (former) and "macro" (latter) standpoints are both needed to appropriately implement software quality assurance. In fact, the best QA engineers are able to balance the two and are highly experienced in both. It makes sense, seeing as the QA process embodies aspects of both technological science and theoretical analysis.
There are corporations across the world that have the tendency to believe that QA engineers should test until the software is just good enough to pass. This is a micro frame of mind: "Don't ask questions, just test." And, many managers downplay the role of QA employees, whom they consider nothing more than "testers" who bog down the system when customers are waiting for a finished product. This can sometimes stem from business politics or in an extreme case from a manager who doesn't want to get off his high horse and doesn't want QA to have the power to tell him what he's doing wrong. If your company does not value QA enough to have it involved throughout the process -- especially during testing, when it's most essential -- I suggest that you speak up and communicate its importance to management. After all, QA is truly the lifeblood of a product.
This is why -- before involving any kind of technical implementation -- a QA process should be outlined that includes all scenarios of what "could go wrong" mapped out in detail and a potential solution to each. Someone who doesn't specialize in QA, or even a purely "technical QA individual," might scoff at this approach. Many times, what they want is to get the product out the door in one piece, even if it's missing a few nuts and bolts. This, of course, creates an inaccurate product that is unable to be fully tested or even reused.
I admit there was a time when I was that "technical QA individual" who would go straight for the quick technical fix. I learned quickly, however, that if I didn't spend enough time outlining the project, I would pay for it in the end by dishing out my evenings and weekends answering customer complaints and trying to fix whatever had gone wrong. At a previous job, I remember one manager talking to a QA tester at 3 p.m. on a Friday before a long holiday weekend. The manager indicated to the tester that he didn't care if the guy had to buy a cot and sleep at work over the weekend; the software needed to be fully tested, pronto. Obviously, that kind of work environment puts a ton of strain on the tester. Therefore, if management doesn't support planning and process mapping prior to beginning the project, they'll most likely have a bunch of sleep-deprived and disgruntled "testers" to deal with on Monday morning.
In a perfect world, QA would act as a balance, with the weight of the business analyst team on one side and the development team on the other. Customers and management should bolster the scale by creating a solid foundation at the base -- each department supporting each other. In the real world, new QA professionals will often stand behind a manager and do whatever the manager says (they're the expert, right?) but later find themselves trapped in an endless cycle of "because I said so" business. Or they might be caught in the pressures of "you said so" by management. This kind of business politics should never be used to control quality assurance or the implementation of accurate procedures. It's important to have a happy medium.
Since QA is usually the last department to get involved in a project (although it shouldn't be), QA engineers depend upon the proper communication channels to get the job done correctly. After a process is put together and understood by all, the technical implementation of QA can exist. Some technical QA tasks could be such things as how database testing will be executed, what approaches and techniques will be used to begin testing, how automated scripts will be captured, how the data will be used to complement the testing, approaches to connecting multiple tests together, and how to test applications with a particular functionality -- lookups, checkpoints, drop-downs, etc.
It's one thing if QA professionals were meant to be merely "testers" and nothing more. But, as mentioned before, the reality of the QA profession is much broader. QA is not meant to be locked up in an information silo to test solely based on the methodology set by managers. QA analysts are not just conducting the test but are an integral part of how the testing is done from all angles of the environment and software development life cycle. This is why QA is often split into process, manual, and technical QA groups.
The process group outlines the mapping, standards, and procedures at both the enterprise and department levels within an organization. The group ensures governance based on the guidelines that were set to ensure a quality product.
The manual group defines and creates the test plans from the requirements. This team works heavily with the business analyst, ensuring that proper test plans and procedures are documented. Team members also execute tests manually, based on how an everyday user would execute the scripts. They test not just a function, but also an aesthetic of what was designed and developed. It is also important to test with no technical or business biases by testing from the user's perspective.
The technical group is even more diversified. Tasks may include automation, data testing, security, performance, and even certain functions such as EDI testing and data encryption using compression on an application. This group exists to take the burden off of the other two. If one person were to conduct both manual testing and technical testing, it would be cumbersome to ensure that the correct methods were being used to validate the test.
So, in a software organization, QA professionals need to embody both the technical "doer" and theoretical "thinker" mentality in order to be well-rounded and successful. It is imperative for all departments to work together to make a positive impact. The pressures and politics of everyday business should not take priority over the quality of the work.
About the author:John Scarpino is director of quality assurance and a university instructor in Pittsburgh. You may contact him at Scarpino@RMU.edu.