Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

From Wikipedia:

Quality Assurance refers to administrative and procedural activities implemented in a quality system so that requirements and goals for a product, service or activity will be fulfilled.[1] It is the systematic measurement, comparison with a standard, monitoring of processes and an associated feedback loop that confers error prevention.[2] This can be contrasted with quality control, which is focused on process output.

You can read the following article to understand the difference between QA and testing (quality control): http://blogs.msdn.com/b/alanpa/archive/2006/02/26/539527.aspx

What I'd like to understand is whether there is a place for QA engineer who is not a tester in Agile/Scrum. Agile is deliberately short on processes and documentation (its even in the manifesto), and that's what QA specialize in. So should there even be a QA engineer in Agile?

I myself am not a QA engineer (I am a test lead), but I have a friend who is, so that's why I am asking.

share|improve this question
Are you interested in a particular type of organization, especially one in a rigorous environment (medicine or healthcare, aerospace, automotive), perhaps that is adherent to something like ISO9001 or something similar? –  Thomas Owens Mar 16 '14 at 20:05
We work in FDA regulated company, and my colleague, a QA engineer, wants to do quality assurance in addition to what is required by FDA. My recommendation would be against that. I don't see how process control is useful in an agile environment (that is besides what is mandated by FDA) –  Eugene Mar 16 '14 at 20:08
I'm wondering if this question and its answers may be useful. I'm not that familiar with the FDA - I have experience with working with agile development within the context of CMMI and AS9100 (which is an aerospace version of ISO9001). If it's a CMMI-rated organization, the SEI has publications on combining CMMI with the agile methods as well. Could you provide more information about what the FDA mandates and what additional process monitoring and control is being proposed? –  Thomas Owens Mar 16 '14 at 20:11
Going above and beyond what is mandated by higher levels - customers, regulatory bodies, corporate mandates - is not agile. It's definitely not lean, either. That's not to say that QA and process improvement doesn't have a place in agile organizations, it should be done in a way that doesn't add delays in the process or bureaucracy or reduce the power of the team (meaning the development team) to make changes in how they work. –  Thomas Owens Mar 16 '14 at 20:15
I think I have enough to write an answer now. Let me take a stab at it. –  Thomas Owens Mar 16 '14 at 20:20

2 Answers 2

I think that there is indeed a role for quality assurance in an agile organization, especially one that has to adhere to a quality management system such as ISO9001, ISO13485 for the medical device industry or AS9000 in the aerospace industry, for the purposes of meeting customer requirements, regulations, or corporate mandates.

There are two important things to keep in mind. First, quality assurance is not just interested in the quality of the final product, but all intermediate work products. You can view software development as a black box that takes in some form of customer requirements and outputs software (and perhaps support for that software). However, during that process, the development team does things - transformations of those requirements into something usable to design and build software, creation of designs, prototypes and simulations, production code, test code, supporting scripts, manual procedures (for testing, deployment...), user documentation, and more - any of which can have defects which would impact downstream activities that rely on that information. Quality assurance is concerned with not only how defects are found in these work products, but how those defects are prevented. Second, quality assurance is also interested in process quality - how well we are doing the work. Although the obvious thing here is the quality of the work products, it's also how long it takes to do the work (among other things).

Two of the tenets of Agile are to favor "individuals and interactions over processes and tools" and to favor "working software over comprehensive documentation". However, neither of these say that you shouldn't have a process or that you don't need any kind of documentation. If you're trying to implement a quality management system, it's likely that you are required to have some level of documentation that can be compared to the work that is actually done during auditing. I think that these Agile ideals are better expressed in a few of the concepts of lean software development - eliminate waste by removing delays in the process, reducing bureaucracy, and improving internal communication, amplify learning, and empowering the team to make decisions about how to best achieve the goals.

In addition to being responsible for internal auditing, a QA organization can also help support agility or lean software development by being responsible for helping to detect waste, find delays, and ensure that what is documented gives each development team sufficient leeway to implement process requirements (levied by customers, regulatory agencies, corporate mandates, etc.) in the best way for the individual project but still having some level of consistency across the organization to allow for people to transition between projects without having to relearn an entire new set of processes and methods on top of the technical learning curve.

However, based on some of your comments, it seems like the direction that this is going in is not Agile or lean. It's a fine line to walk on how detailed to make your process documentation. If it's too vague and gives each project team room to implement anything that they wanted to, leading to wide variations in process implementations (and therefore process quality and likely product quality) across the organization. If it's too specific and detailed, it's likely to add bureaucracy and comprehensive documentation would get in the way of interactions and working software. There needs to be balance between agility and the ability to obtain information about process quality (through measurements and some level of consistency).

See also:

share|improve this answer
Good answer, good digging for what the OP was actually after. –  Dave Hillier Mar 16 '14 at 22:17
Thank you for the thoughtful answer. What I would like to know is how come non regulated agile companies don't have QA people? The vast majority of people on this forum haven't even heard of such role. –  Eugene Mar 17 '14 at 5:01
@Eugene I'm not really sure. Perhaps it's the same reason why few companies outside of these industries look for people with continuous improvement or software engineering process experience, outside of management roles. –  Thomas Owens Mar 17 '14 at 10:39
"You can view software development as a black box that takes in some form of customer requirements and outputs software". Actually, agile software development can't be viewed that way at all. Customers must be involved in software development and requirements are changed/detailed/rethought inside the black box. That's why we use the word agile at all. A development process is not agile when it follows all the ceremony of an agile methodology, but there is no actual change in scope within the black box. It seems to me that it marks quite a change in defining "quality". –  Sklivvz Mar 26 '14 at 12:09
@Sklivvz It's still a true statement in agile methods. In agile methods, the customer representative is a participant in the processes that occur inside the black box of software development and is not an outsider to the process. Even in more plan-driven methodologies, there can be some customer visibility. For example, in his definition of waterfall, Winston Royce called for external design reviews and acceptance reviews, and many organizations actually do have external requirements, preliminary and detail design, and acceptance test reviews with external stakeholders. –  Thomas Owens Mar 26 '14 at 12:17

I'm not sure that I understand the difference (or how it is relevant) between "testing" and "quality assurance". In the end to do QA you must do testing.

QA, as you define it, sounds a bit against the Agile manifesto's value of Working software over comprehensive documentation. Do you really need all that process documenting? Are you trying to squeeze an existing process into an Agile one. If you really need the documentation you should add it to your definition of done.

Agile methodologies prefer "generalizing specialists" who do vertical slices. This means any team member should be able to complete any story. Developers should test, QA should test and everyone should work to build quality in.

Agile teams use retrospectives as the point where they improve their process.

In teams that I've worked in everyone is responsible for quality. Typically there is a lag between something testable in an iteration/sprint being ready for a tester. With this time, you can get your QA activities done just in time for testing of stories. Be careful for this introducing scope creep within an iteration.

Many Agile processes are not prescriptive about that level of detail and it is left to the team to decide. Would a self organising team ask for a QA specialist?

share|improve this answer
In an organization adhering to something like ISO9001 or AS9100, yes, having a documented process is important for auditing by external organizations, such as customers or governing bodies. A QA organization is not just concerned with product quality, but also process quality and the relationship between them. A QA organization would ensure that documented processes match reality (and either the documentation or reality is changed, as appropriate) and that the processes in place are appropriate for finding and containing defects early in the development lifecycle. –  Thomas Owens Mar 16 '14 at 20:00
That's what I was thinking. QA is useful only when you are audited by some government agency. Otherwise it seems like an overhead to me. –  Eugene Mar 16 '14 at 20:03
@ThomasOwens fair enough, I'm not that familiar with documentation heavy processes. Mike Cohn's book Succeeding with Agile has a description of how to combine CMMI & ISO9001 with Agile. It's quite thin on details... –  Dave Hillier Mar 16 '14 at 20:04
They don't necessarily have to be documentation heavy, as evidenced by this question, which includes an answer from a former ISO 9001 auditor. It's just a matter of being able to align how you do work consistently across the organization by pointing at something that's controlled and monitored. –  Thomas Owens Mar 16 '14 at 20:08
Audits are useful regardless of whether there is a legal requirement to have them. 'Audit' is simply another way of saying you're checking that people are doing what they say they are doing. Whilst trust is important, of course it is, any reasonable investment has a requirement for checking authenticity. All business is a form of investment, all audits are a check of authenticity, QA is an audit of your quality processes, and all development processes that are worth using should pass, agile or not. –  Rob Baillie Mar 17 '14 at 14:03

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.