Know your quality!

Initially an auxiliary project role, quality assurance is nevertheless a non-removable link of a software product delivery chain. Obviously, no one would oppose its necessity; the actual question is, whether it does require a specific role in a team. Including a separate QA engineer into a project is one of the common practices in software development, yet in every certain case it depends on project goals and available resources.

Software testing has made a long way from a general concept to a specific profession, as the entire software development industry grew and evolved. This process as usually is marked with differentiation of technical roles and therefore with growth of specialization. The division of development and testing tasks as an element of the general division of labour trend has grounded the necessity of a separate QA role in a project.

While the importance of quality control causes no doubt, a bigger question persists, whether this role requires a specific QA engineer or testing functions could be performed by developers? In other words, does project need a separate person fully dedicated to bugs detecting and constant re-checking of freshly built product versions’ basic functionality? Or will it be enough to get team members now and then switching from developing to testing whenever needed thus maintaining a more flexible overall working schedule? Well, universal solutions are rare in this world; and typically each project team follows its own rules.

Whether a QA engineer should have development skills is a matter of debate; but it is important to know that testing significantly differs from developing. A major difference between developer’s and tester’s jobs is the ‘direction’ of the work: while a programmer builds entire product from components, a tester’s mission is closer to decomposition: general performance and features of the product are first to be analyzed; after that it is divided into smaller logical parts to examine them as well.

Testing in detail

Normally a testing process includes the following basic stages (higher priority tasks come first):

  • Overall functionality testing (basically performed together with acceptance or system testing). It is most important to check that everything works as it should as the primary mission of a product is getting approval from users or customers. They will judge its quality by its functionality and are not likely to evaluate its code. A tool that does not work appropriately will not be successful in its market niche no matter how well organized it may be (unless the main goal is to create a programming masterpiece).
  • Testing in specific conditions (such as compatibility or stress testing) is one step deeper: once the tool is fully operable in normal conditions, it is tested in different ‘unusual’ situations. This includes using different browsers, less popular devices & OSs, emulating super-heavy workload etc. The purpose is to define the actual boundaries of tool’s ‘abilities’.
  • Finally, when a tester has made sure the product performs well in all possible situations (at least in those which could be emulated within the project), it is time to examine the code more closely. This stage includes testing of program components and looking how well they are compatible with each other (see: Unit Testing). The purpose is to optimize the code: separate elements as well as the general structure. In fact this part is usually automated; and unit tests are performed by developers at early stages of building the product.

It is clearly visible that at each stage there are no rigid rules defining which team member has to get the respective task assigned to. While basic usability can be checked by anyone familiar with the application’s interface, code testing and stress load emulation are usually automated – and automation is typically a task for developers. The difference between approaches of QA and software engineers consists of more complex factors. While a developer is naturally more concerned about functional efficiency and inner logic, a QA engineer considers also simplicity of usage, interface attractiveness and customer feedback. Finally, it is widely acknowledges that a collaborator involved in the code writing is less likely to find flaws in the code.

Software testing as a separate IT skill has proven its importance long ago; and its place in a software development project schedule should not be underestimated. Of course each project has its specific goals, requirements and limitations which define the amount of resources assigned for this job type. But it is worth noting that higher dedication of project roles (whenever affordable) leads to better overall quality.