Software testers are typically grouped en masse in the world of information technology (IT). Many in the software testing profession, however, know that this should not be the case. In this week's column, Dion Johnson exposes the dichotomy in testing that has produced two distinct groups--software test engineers and software test executors--and why these groups are embroiled in a struggle to possess the crown as the industry's true software quality professionals.
Test executors and engineers have distinct places in the IT organization, but test executors who present themselves as engineers have posed a problem for true test engineers for years because they perpetuate the myth that "anyone can be a tester." This weakens the power testers have in an organization with regard to decisions that affect the quality of the IT systems; in addition, the quality of life for test engineers in an IT organization is significantly diminished by this confusion. This has been a private struggle for years, but it must become public because it transcends the boundaries of testing.
This conflict is a problem for IT organizations as a whole, because all too often managers and project leads believe they are hiring test engineers when they are actually acquiring test executors. Relying on an executor to do an engineer's job is detrimental to a project's budget and goals, because the project will experience bloated costs and/or inefficient practices that will lead to a low-quality product. The best approach for ending the duel begins with clearly identifying the points of divergence that cause the dichotomy, then explaining how to discern on which side of the dichotomy a potential testing resource belongs.
The Points of Divergence
"A test engineer minus the requirements analysis equals a test executor."
I recently wrote an article for Better Software magazine called "Your Job - Requirements = Less Value." That article introduced the concept of test executors versus test engineers by disputing the claim that "anybody can be a tester" while simultaneously declaring that "anybody can be a test executor." There are four points of divergence that separate an engineer from an executor:
- Knowledge of testing theory
- Technical understanding
Let's begin our look at these points of divergence by discussing the term "engineering." Engineering is about optimization--the procedure(s) used to make a system or design as effective or functional as possible. A software project has limited time, money, and resources; someone must analyze the time, money, and resources available and figure out how to use them most effectively. Analysis is one point of divergence between engineers and executors. This includes analysis of requirements, processes, systems, and staff.
This analysis combined with a general knowledge of testing theory is used to engineer the most efficient testing approach possible in the existing environment. This is why knowledge of general testing theory is another point of divergence. Have you ever seen a tester take use-case scenarios or high-level testing scenarios provided by the requirements/business analysts and use those solely as the basis of their testing? That exemplifies how a test executor performs his job. On the contrary, test engineers analyze requirements to determine the completeness, correctness, consistency, and clarity of requirements. They work to get requirements improved as much as possible, and then they use knowledge of testing techniques (boundary analysis, exploratory testing, etc.) to go beyond what is stated in the requirements to further exercise the system.
Another point of divergence is attitude. Test executors are experts on what cannot be done, while test engineers are experts on what it will take to get something done. When faced with challenges, such as poor organizational processes or low resource availability, test executors excel in explaining why goals can't be accomplished. Test engineers understand, however, that conditions are never perfect, so they look at such challenges as opportunities to earn their paychecks. They begin to craft a set of scenarios that outline how various levels of a goal can be accomplished under the current circumstances.
Being technical does not mean being an expert programmer; it means understanding systems