[This article was collectively written by few of my colleagues and myself few years back when we were in process of structuring the QA Organization framework. I landed upon it today while I was going through some of my old notes. A lot of collective experience and brainstorming had gone into it. Publishing it here with the hope that it might be useful to a wider community.]
Our organization’s target customers are typically Independent Software Vendors (ISV) and Application Service Providers (ASP). For such typical partners, Software Product Engineering is an exercise in managing complexity. The complexity exists within the software design itself, within the software organization of the company, and within the industry as a whole. It can span multiple technologies and often involves multiple sub-disciplines. Software specifications tend to be fluid, and change rapidly and often, usually while the SDLC is still going on. Software teams also tend to be fluid, likewise often changing in the middle of the design process. Hence it is important that the team has to have the ability of making decisions under constraints of limited time, resources, and knowledge. This is where the notion of Engineering holds its value.
Engineering is more about how you do the process than it is about what the final product looks like. Programming and the build/test cycle are central to the process of engineering software. We need to manage them as such. The economics of the build/test cycle, plus the fact that a software system can represent practically anything, makes it very unlikely that there are any general purpose methods for validating a software design.
Considering the above the Engineering aspects and the non-engineering aspects of Software Development needs to be identified. Also, it needs to be recognized that there are specialists who are well-versed in doing either of the tasks. These specialists typically originate on the basis of their educational path or as in many cases – the aptitude. At the same time it is important that the expectations of the capability of the individuals needs to be well-understood by all the stakeholders. Any mis-match in terms of capabilities and expectations, typically tends to adversely affect on the final outcome of the SDLC delivery.
While this applies to all the domains of SDLC, this exercise is being done for professionals who are involved in the Quality Assurance (domain). The goal is to categorize these professionals based on their inherent capabilities (and hence the expectations set on them)
- The table below characterizes three different roles. These roles are similar from the functional perspective (i.e. Quality Assurance), however are different from capabilities and expectations perspective.
- While the table below does not suggest a career roadmap, it can help individuals in terms of career aspirations.
Comparison of Roles:
QA Tester vs. QA Engineer vs. QA Architect
|QA Tester||QA Engineer||QA Architect|
|Function – Strong in test execution.||Function – Test planning, Test Design and execution.||Function – Define approach to test entire systems|
|Write and execute test cases – may not be coverage driven. Requirements driven testing.||Prepare test plans, develop test cases and execute tests with a focus on coverage.||Design, plan, execute, monitor, improve testing process for a testing engagement.|
|Determines Quality. Good to answer – did you find any bugs?||Engineers Quality. Good to answer – what is the quality of the product?||Provides answers to –
|Linear thinkers, low capability of analysis and re-usability of efforts/resources.||Logical thinkers. Ability to resolve issues using abstraction. Capability in analysis/predictions/improvements.||Analytical and creative. Systems thinking and quantitative/statistical thinking capabilities.|
|Requires a defined environment. Typically are weak in finding solutions in ambiguous/constrained environments.||Can reconcile conflicting constraints.||Able to define the environment.|
|Low process oriented capability.||Process and metrics/measurement driven.||Defines standards, guidelines, methodologies, metrics.|
|May not be cost sensitive (time, effort, monetary, etc.)||Cost sensitive||Cost sensitive|
|Good for UI Testing
||Good for System/functionality testing
||Good for defining, planning and managing for test engagements.|
|Typical involvement is in later stage of SDLC||Best to have them involved in complete SDLC Cycle.||Best to have them involved in complete SDLC Cycle.|