QA Manager and Test Manager in the Same Company

Home Forums Software Testing Discussions QA Manager and Test Manager in the Same Company

Viewing 17 posts - 1 through 17 (of 17 total)
  • Author
  • #9180

    Is it common to have both roles in a team?

    I’ve heard it described that a QA Manager is responsible for policy and processes and the Test Manager is responsible for tactical implementation of these processes. Is this accurate?

    I’d be interested to know if this is how it works in your organisation or if anyone has encountered alternatives that worked well (or didn’t work well for that matter).

    Or are these roles largely rolled up into one where the Test Manager or QA Manager is responsible for the strategy and tactical?


    QA manager is responsible for all the development and/or maintenance life cycles policy and processes. Sometime he is also responsible for what you call –the tactical implementation of these processes, or at least help to implement it.
    Testing processes are part of the life cycle activities. The QA Manager is responsible to define the policy and processes, sometime with the help of the Test Manager. The Testing Manager is responsible for tactical implementation of these processes
    I worked for one company as Testing Manager, as QA Manager for another, and had both roles in another one. So it is depend on the company (size, “QA culture”, etc.)


    Thanks for the reply Shlomi! How do these roles work together – does the Testing Manager report to the QA Manager (where both roles exist)?



    In my company we do not have any of them.
    We only have QA leads and the “tasks” associated with QA/Test Manager are devided among the leads.
    Frankly I do not hink this is working well, people seem to go to the same person if they do have problems.
    And I do not believe that our processes are aligned. But this is all explained by the saying: a scrum team can define his own processes.
    I’m trying to let management see that they need to change but for them they tell me they think it’s working well. Qa leads do take on responisbilities and work them out, so no need to change.
    The dificulty is that you do not really get a visible mandate if the added responisbility is not communicated to the other leads.


    To Paul – I do not think that a testing manager should report to QA manager. Testing manager should either report to IT manager – with a same level as the development manager, or report to the development manager. I prefer the first.
    QA manager role is to audit and verify that the testing processes, as all the other development/maint. processes, are executed as it should

    To An – It looks that you are working in a company that can be described as CMMI-stage 1. It looks that you do not have project or company procedures or any QA at all.
    Even agile development should work according to some company procedures, but sometimes they take agile as an excuse to work without any.


    (I’ve been a Quality Manager, Method Development Engineer, Process Improvement Manager (and few titles of the kind) and mostly a Test Manager, so can speak from my experience on few companies)

    On small projects and organisations this is a non-issue as there seldom are several quality or process-related roles. many times projects are resourced for the project and there is some form of continuity between projects but it can be very informal.

    On larger contexts I think the key difference is between the project world and the line organisation. Projects come and go, and on many organisations projects are staffed with internals from matrix organisation (meaning project participants do not necessarily share a same line manager but come from various resource pools) or resourced from externals who likely will leave at the end of the project at the latest (if not before that). The effect of this resourcing model depends heavily on the organisational culture (project independence) and the nature of the business — it is different in IT shops and product organisations and then again in project business. But in general this means that there are very shallow means of providing any concrete forms of continuity between projects. For example if there is a nice practice of organising the test data for one project X, it is very likely there will later come project Y that knows very little about it. Also for many organisations there seems to be very little value in creating a real product / system creation process that is also expected to be followed (those ISO 9001 folders that nobody used after the audit we can forget already).

    But on many cases there is a good reason for the organisation to invest in organisational continuity. This is needed for example:

    • if there is a considerable business risk,
    • there is potential for synergy savings among several parallel and sequential projects (using or creating shared assets for example), or
    • there is an external or top-level pressure to improve the organisational processes and shared practices across teams and projects (for example a process improvement initiative, wanting to benefit from six sigma, PDCA-cycle, etc, or there is expectation to adher an industry standard like the FDA type approval rules)

    Then it is quite normal to nominate a line role for looking after the process assets (process models, training material, metrics, etc) or maybe even drive a continuous improvement process. That is the role of middle & higher management, but normally delegated to a quality manager, QA manager, etc. I’ve seen several quality managers whose role was very ceremonial — mostly keeping upper management happy with good looking numbers and sticking to the organisational ISO-9001/2/14000/whatever certification — essentially keeping up with appearances and also not to allow organisation to lapse on the good behaviour of the recent past. Then there have been more operational roles, like process improvement managers, or “head of organisational development” — essentially changing the organisation. And these have nothing to do with testing — they are about keeping the organisational machinery in shape on all areas. Calling these “QA managers” is IMHO in a typical quite misleading. On last decade these roles have very much disappeared, especially the ceremonial side of quality management.

    Getting back to the question of Test Manager and QA Manager/ Quality Manager: the thing is not on job titles but what they are expected to do. The difference is on how the organisational continuity or improvement / organisational learning is taking place, and whether there is anyone in line organisation & still outside the project expecting any improvement that stays after the project. Looking after process within a project is no more in the typical scope of a test manager than development team manager or a business analyst. But in practice it is easy to mix the quality work of testing with the very confusing and misleading “QA” term to be same as testing but still be about process in general. (I think we should issue a global ban on term “QA” and talk either of “testing” or “quality & processes” — well, not likely, is it? 😉

    Nowadays projects are small (biggest I ever joined had about 1500 engineers…) and any fixed costs have been shaved off wherever possible. Having a full time test manager being able to focus on test management can be a luxury (I love testing and would hate being cornered as just a test manager without any chance of actually testing) and having anybody looking after the process over several projects is available on not so many small or middle-sized organisations. But when we talk about tens of millions’ budget (on any currency) it is common to have (in any business model) someone nominated to care for the process & practices, helping the stressed project manager. The difference might be how operational the role is and how much support a project can expect. But no saying i”in general” as there is no “general” 🙂


    We have (or actually had) this approach.

    We separate QA from QC, where QA is covering the process/policy side of things, but on a high level (ISO process level), and not only covering test, but all PLC processes – from requirements management via development/test to competenece management

    Then, we used to have the role of “QC manager” that was on a level closer to the actual craft of testing. This role would drive definition of visions, values, guiding principles, practices, lower level process, methods etc etc. (and of course the ordinary people management things). Here, we had a dedicated team of testers.

    Moving towards being agile, I believe it is imperative for each organization to understand how the previous areas of responsibility of the QC/Test Manager is being taken care of in a new situation with cross-functional teams and a more distributed responsibility.
    James Bach has interesting take on this with the concept of Test Jumper.


    Hi, Paul…

    I’ve heard it described that a QA Manager is responsible for policy and processes and the Test Manager is responsible for tactical implementation of these processes. Is this accurate?

    This is a kind of unicorn question, a question that needs to be unpacked before we can even try to answer it in a helpful way.

    You’re asking “is this accurate?” but you’re referring to something that you’re talking about in the passive voice; “I’ve heard it described…” The person doing the describing is a relevant factor in all this, since the person might be a member of a real organization or someone talking about some theoretical idea; a person who studies development organizations seriously, or some random novice tester on LinkedIn.

    When you say “I’ve heard it described”, you mean that some person has described (or proposed) this organizational model, apparently for some purpose in some organization. So you might be asking

    a) “is this a faithful description of that person’s model?”; or
    b) “is that person’s model consistent with the reality in that person’s organization?”; or
    c) “do many people subscribe to this model?”; or
    d) “does this sound like a helpful way of organizing management work?”

    I’ll answer those questions one at a time.

    a) The person making the statement would be able to assess whether you’ve given a faithful description of what they’ve said. Ask that person.

    b) The person making the statement might say Yes, but others in the organization might say No. In other words, people who work in the organization (s)he is describing might say, “That’s the model, but that’s not how it really plays out.”

    c) It’s hard to say, but based on travelling around the world and talking to lots of people from lots of organizations, my guess would be “some, perhaps, but not very many”.

    d) It doesn’t sound very helpful to me. I would take “QA” out of the description and simply say that managers generally are responsible for policy and processes in their respective domains, and that testing is one of those domains for which managers are responsible. In this sense, anyone with management authority is a “QA manager”; to me, assuring the quality of the work being done (which includes policies and processes) is intrinsic to any role called “management”. (Of course, there’s also the question about what “responsibility” means: responsible for controlling? Steering? Evaluating? Accepting blame?)

    My experience is that a separate line of authority for policies and processes fairly quickly becomes fixated on models of how work should be done, and becomes separated from the realities of how work is done. At worst, this role becomes a kind of “quality police”; busybodies that add overhead and enforce policies that don’t fit the work. At best, a “QA manager” could become a thoughtful counsellor or mentor, noticing problems in what is being done and offering alternatives to practices that aren’t working. I haven’t seen that happening, myself, and it remains unclear to me how this should be separated from the other management roles in the organization.

    Note the way I’ve answered (d). To me, that’s the only way to answer that question: with an opinion clearly stated as an opinion, based on experience, both of which depend on a number of context elements. (Erkki gave a particularly good example of this.) It’s important to examine the problem that you’re trying to solve (or the question you’re trying to answer), and it’s important to examine the factors that contribute to the problem and to the solution. Any other kind of answer, in my view, turns into best-practice fluff.

    —Michael B.


    I’ll answer with an example.
    I once took a contract as a “QA Manager”. I was quite keen to give this my best as I was on a bit of a “process thing” at the time, and the opportunity to assure the quality of the work on the project suited my personal agenda.

    When I arrived I very quickly established that what they wanted was a Test Manager. I fairly rapidly had to give up on having any direct control over the quality of the work done since not only did the business analysts and developers resist, the project manager and client clearly didn’t expect me to do that role. Besides which, I was going to have my hands full just managing the testing!

    This is just one example, but it typifies for me the problem. In a nutshell “QA” is very often just a fancy way to make testing sound “posh” for people who don’t understand testing. To many people outside the craft testing implies “finding bad things” so they need a euphemism. This is unhelpful

    I’m not saying that QA can’t be a real thing, but that I’ve rarely seen anything come close to being effective. But in any event I’m very confident that whilst Testing can contribute to an overall QA effort, the roles are not the same and that it’s very unhelpful to try to overlap them. TBH is QA were to be drawn from any one SD discipline (and I’m not saying it should) then I’d suggest it was somewhere closer to Business Analysis or Development than Testing.


    Hi all,

    even usually I don’t really like when I cannot apply a clear “roles-separation”, basically I agree with Erkki and Michael posts.

    In my currently experience I started out definitely as a Test Manager, following all the activities that goes strictly with this role. I act in an Agile environment, (first time for me) and it was clear from the beginning, we have no a large budget, there’s no way to have a QA engineer in every Team. So, helped by a Coaches Team, we started to identify a QA deputy for each Team and grow a QA Community inside the company and I began playing a role very similar to a Test Jumpers, trying being helpful testing around and in collecting Best Practice (hoping avoid fluff 🙂 ).
    Lately we become part of a Group with international scope and we deem it necessary to make some processes become the same for all location. These processes are not in any way concern on how to conduct the tests, but only on how organize them in their different phases, trying to be according with Continuous Delivery (and Testing) concepts.
    We guess this is a job for a QA Management, but in this moment we split that task between some managers, at each location.

    In theory roles are always well defined, regardless of the methodology you are using, but in practice the application of these roles depends on such many factors. I’ve always believe that you must know the theory in the best way possible, to get what you need with what you have.



    Hi Paul,

    Isn’t funny that test managers are largely enforced to write test strategies, test plans, put up test schedules and report about quality and we hardly find any described development strategy or plan in the organizations or projects we work for.
    I encounter often that I as a test manager need to structure or restructure the process or set requirement to the “work products” to enable the possibility for testing or improving testing quality. Most project leaders are very pleased with this.

    Having worked during the startup of a large project I was assigned both areas (TM and QA) and had in the beginning some difficulties to separate the two roles. It became easier after I defined that I as QA should be focusing on preventing defects being implemented in the product and as a TM I should be focusing on removing as many as possible defects before releasing the product.

    I ended up with defining, and largely describing, the development process as QA manager which included test and other QA activities in the different development phases. As a TM I developed a supporting test strategy which fitted nicely in this development process.

    To be honest I am quite uncertain if I want to combine these two roles during project execution. Both are quite demanding, not conflicting but servicing different purposes. The context and size of the project will be a factor here I guess.


    Knowingly or Unknowingly All organizations would have QA Manager Role played by someone in the organization. It won’t be explicitly defined in the roles but someone would play the role of the QA Manager in the organization to improve / change the processes in the organization. From my past experience in smaller organizations, I have seen CTO working on the process improvements coordinating with the delivery and the management for the process improvements. In this case, the CTO is also playing the role of a QA Manager.
    Answering to your first questions, there is a QA manager in every organization but whether it is explicitly defined in the organization structure or the responsibilities is appended to any other role’s responsibilities is to be determined based on the organization size and the budget.
    In my previous organization with 200 members (30 members in testing team) , QA/Test Manager role was played by the same person. He had two teams reporting to him, one team was responsible for the QA processes across the organization and the other team would be responsible for the testing of the projects and certifying the projects for quality before delivering to the customer. In this cases the same person is responsible for defining the test strategy, Test plan and defining process across the organization with the help of his team members.


    Hi all

    To me it is very simple discussion. 🙂
    1. QA is mostly focused on How and QC is on what. Keeping that basics, depending on the project/organization complexity the QA and QC roles are decided.
    2. QA is a continuous improvement on how we are dong things in the project/organization and etc. predominantly a undercurrent of organization culture, business and values to meet the customer satisfaction
    3. QC is a time bound deliveries on what was agreed to a customer and how they are delivered in the fixed scope, budget, time line using the same organization culture, business and values to meet the customer satisfaction

    In a simple example,
    QC is a “Car” and QA is a “Driver”. If a car met with an accident, we can not blame only the engine, also the driver and his foreseeing vision and the way it is driven. 🙂

    If the Driver see the potential danger to my customer who is trusting the driver to take him to his business destination, if the QA process applies a break like policies, procedures, check list etc the car will stop.

    Sorry for this short note, as I am little busy this week.

    BTW, I am handling both QA and QC, can give more details if any one is interested.
    Popularly known as KK

    with warm regards
    Head of Test CoE & QA Services, AMEA


    I can only answer part of your question:

    I’d be interested to know if this is how it works in your organisation or if anyone has encountered alternatives that worked well (or didn’t work well for that matter).

    I don’t have any relevant data on the other more generic questions.

    In my experience as tester in the Netherlands the QA Manager role typically is more concerned with the development process than with the process of testing.
    I will use my current environment as an example. This company has a QA Manager on each project team. Typically the QA Manager handles several projects. The main concern for the QA Manager is to ensure that quality standards set by the clients of the company are met. So the focus is on compliance with several standards like ISO, SiG/TuViT, Prince2, CMMI. Testing is rather low on their priority list.
    The reasoning is that if the processes associated with these standards are implemented correctly this in itself ensures a higher quality software compared with the situation where this is not the case.
    Testing is only looked at from the point that it must be done and the QA Manager reviews.

    This works for me insofar as it gives me a lot of freedom to manage the testing as I see fit.
    It also works because the software we make has to comply to several standards or the clients of the company and by extension the company that hired me could face severe legal issues. In this situation it makes (legal) sense to me to appoint somebody that makes sure all required standards are met, even if I do not necessarily find the standards useful or even meaningful.

    Personally I feel that software quality is more served with good individual programmers, good individual testers and good ownership of the requirements.
    The roles QA Manager and Test Manager really do not make a lot of sense to me – although I have been called Test Manager on most projects I have worked on as tester.


    Hi all,

    Thanks everyone for your responses – a variety of experiences and opinions.. To clarify what I was asking (based on Michael‘s dissection of the question: “is this accurate?”), I hoped to learn a combination of

    c) “Do many people subscribe to this model?”


    d) “does this sound like a helpful way of organizing management work?”

    It’s interesting that some participants in this conversation don’t appear to consider the term “QA” (as part of a job title) to serve any significant purpose. It’s just a phony label for testing in Paul‘s case and neither Test Manager nor QA Manager make sense to Kasper.

    Others suggest an individual can and does fulfill both roles separately (KK, Manoj) but maybe shouldn’t be (Frans) or did but no longer does (Per)

    It seems there’s a gap in understanding the role of testing and those who do the testing. Who’s responsibility might it be to clarify the role of testing?


    It seems there’s a gap in understanding the role of testing and those who do the testing. Who’s responsibility might it be to clarify the role of testing?

    Mine. 🙂 I’ve written about it. Testers: Get Out of the Quality Assurance Business

    But seriously, neither I nor anyone else can legitimately claim to declare THE role of testing, any more than anyone can declare THE role of grandparents or THE role of marketing. There are no universal principles at work here. The role of testing is constructed by social, political, economic, technological, and cultural considerations in each context in each organization. As such, people working on the project—the testers and the clients of testing—negotiate and clarify testing’s role. I’d suggest that’s one of the most important aspects of the job. If roles and and responsibilities aren’t clear (and aren’t being evaluated continuously), misunderstanding and problems are likely to follow. Quickly.

    —Michael B.


    Hmm, I need to clarify my position since I stated it a little black and white.

    neither Test Manager nor QA Manager make sense to Kasper.

    In terms of software quality – which is my main concern as tester – I truly believe in my statement.
    I have more trust in the quality of software made by self organizing teams then made by teams steered by some manager.
    We have a book in the Netherlands titled “Bullshit Management” that makes the case that middle management does not improve companies or the products they make. Leadership on the floor works. I agree with most of that book..

    In my current working environment I does make sense to have a QA Manager from a compliance and legal point of view.
    The title Test Manager really does not make much sense to me – even though my function at this company is most often described as test manager.
    It is a term of convenience that puts me on a level with other managers. For my communication with other testers the ‘manager’ part of my function is irrelevant. My experience and knowledge is relevant – regardless of the title I have at that moment.

    The role of testing can be compared with parallel universes. It is different at other places, times and circumstances. There is not one role of testing.

Viewing 17 posts - 1 through 17 (of 17 total)
  • You must be logged in to reply to this topic.