Software QA and Communism: An Incompatible Combination

• Mon, Jun 12, 2023
• 5-minute read

Have you ever pondered the political pattern underlying the structure of QA in your company? Does it resemble a centralized QA team reflecting the principles of communism, or a decentralized QA approach within product teams resembling the tenets of capitalism? When contemplating the organizational structure of QA, intriguing parallels can be drawn to political ideologies, and surprisingly, by comparing these QA approaches to political reasoning, valuable insights can be gleaned to aid in the decision-making process of selecting the most suitable approach to adopt.

In order to make an informed decision about the appropriate QA structure, it is crucial to understand the key responsibilities of QA professionals. From the software engineer’s perspective, here are my expectations of responsibilities of QA professionals:

• Possessing an extensive understanding of the platform.
• Conducting various types of tests to evaluate developed features before their release, aiming to minimize the occurrence of bugs.
• Periodically checking on product features to identify edge cases before users encounter them.
• Replicating bugs reported by users, providing detailed instructions on how to reproduce them, and forwarding them to developers for investigation and resolution. (It would be beneficial if the QA professionals would be able to analyse on the state of the product for the occurrence of the bug, eg: if the user skipped a part of the signup process to reach that state)
• Developing automated tests that cover the core flows of the product.

A common practice in communism is the shared allocation of resources to maximize productivity. In this approach, resources, such as machines, are centrally owned and distributed based on the needs of different entities or individuals. The advantage of this approach is that it aims to make the maximum utilization of resources, promoting efficiency and equal access. For example, machines are shared among departments or production lines instead of being individually owned. The allocation of machines is based on the current needs of each area, ensuring optimal resource utilization. If one department needs a machine more than another, the central authority can redistribute it. Therefore, centralizing resources and allocating them on demand prevents underutilization and promotes collective productivity.

The centralized QA team structure follows a similar principle. Each product team reports their requests for QA resources, and the allocation is based on the workload of each QA engineer member. This approach aims to minimize the non-working time for QA engineer. Requests are queued and only get processed when QA resources become available. This structure facilitates tracking and management of QA engineers’ work and enables quantification of the overall work accomplished by the QA team. Ultimately, it streamlines the evaluation process and aids in planning for future tasks.

The goal that the centralised QA team structure intended to achieve is desirable, but the assumption that QA can be treated as a shareable resource is incorrect. In communism, shared resources are typically machines that perform repetitive tasks, which do not require contextual understanding. As a result, the performance of these machines remains consistent regardless of the task or the entity requesting the task. However, the nature of QA work requires a deep understanding of the tasks and familarity with the platform, which makes the QA task non-repetitive and highly experience-dependent. The more familiar they are with a particular task, the higher their performance is likely to be. Conversely, assigning a task in the little-known project to a QA engineer steals their focus from testing to learning. Consequently, the quality of their testing work may be less satisfactory.

Teams that adopted the “capitalist” approach (dedicated QA engineers working within a product team) help QA professionals to become platform experts. By actively participating in standups, sprint planning sessions, and feature demos, QA professionals can quickly familiarize themselves with the language used in the platform, the business model, user flows, and upcoming features. This level of immersion enhances their understanding of the product and tasks at hand.

The graph above provides a visual representation of the efficiency comparison between the two QA approaches. It illustrates that the efficiency of task execution is directly correlated with the level of familiarity and understanding of the product and tasks. When QA professionals are integrated into their respective product teams, their efficiency tends to improve due to their deep knowledge of the platform and close collaboration with the development team.

Another drawback of a centralized QA team is the potential loss of the “know-it-all” for the product. When QA professionals are involved in testing all features of the platform, they develop an in-depth understanding of the product and become a “living repository” of knowledge regarding the released features. This accumulated knowledge allows QA engineers to notice even the subtlest changes in the platform and helps in maintaining consistency and quality.

Having this wealth of knowledge readily available also greatly benefits engineers. When they need to reach a specific user state or trigger certain platform behaviors, they can rely on the expertise of the QA professionals instead of spending significant time reading through code to understand how to replicate the desired state.

To sum up, I believe that centralized teams are optimized for quantity and decentralized ones for quality of the work. While a centralized QA team offers the benefits of resource optimization and centralized expertise, it may struggle to keep up with the evolving product landscape and the need for deep domain knowledge. On the other hand, a decentralized QA structure allows for better integration within product teams, fostering a deeper understanding of specific features and more efficient collaboration between QA and development.

What would be the appropriate metric for measuring QA deliverables? probably incorporate it as part of the overall metric for product performance?

---

Thank you for investing your time in reading this blog post. The opinions and graph presented above are derived from my personal experiences. I am open to receiving any comments or feedback regarding the content. Your input is highly appreciated! ʕ •ᴥ•ʔ