Quality Assurance (QA) aims to oversee software development as a whole and mitigate risk with a bug-free system launch. QA monitors the entire software development process, safeguards standards and procedures, and adopts a general strategy of preventing problems before they occur. It performs best when it identifies development problems early in the process, though QA does not strictly limit itself to software testing. Testing will confirm that a system works as intended; QA will also assess the customers’ needs, measure usability, and oversee other aspects of software development such as hiring, communication, cooperation, and adherence to practices and policies.
Early in development, QA will work with other analysts to identify the customer’s needs and convert them into a group of testing cases and scripts, known together as a test plan. This document outlines the objectives, scope, strategy, and focus of the project. Specifically, some items include: risk analysis, test environment, test outline, database setup requirements, allocation of personnel, personnel pre-training requirements, and completion criteria.
While software testing is not the only element of quality assurance, it is nonetheless a significant component. The types of testing will vary according a project’s needs and scope, and an analysis of all types sits beyond the scope of this article. Many potential tests can run as either white-box or black-box, though most software developers use both. Black-box testing does not require intimate knowledge of programming code as it merely confirms that a desired input produces the desired result. White-box testing checks the software’s code for error and inefficiency; as such, it demands programming expertise.
Examples of possible tests include: functional, load, stress, ad-hoc, recovery, and compatibility. As its name implies, functional testing gauges the software against QA’s functional requirements. Load and stress testing are often used interchangeably because both examine the software’s ability to perform under extreme conditions. Load testing measures the software’s ability to perform within the limits of its specifications, while stress testing inflicts unfavorable conditions on software to find flaws. Ad-hoc testing (also known as “informal testing”) gives developers a means to mimic the relatively random applications of the typical user. Recovery testing verifies the software’s ability to recuperate and function from varying degrees of failure. Tests for compatibility gauge the software’s tendency to “play nice” with other programs.
Again, while some tests lend themselves as more of the black-box or white-box variety, many can function as either. Part of the QA team’s job is to decide the type, scope, and capacity for each type of test, and do so in a way that meets deadlines, stays in budget, and assures the quality of the final release.
Simply put, quality assurance works to guarantee efficiency and collaboration within the software development team with an eye toward releasing a competitive and relatively bug-free product. While a significant part of QA involves testing, it often includes intangibles like leadership, maintaining a spirit of collaboration, and deciding on what “quality” means to the customer.