Agile FAQs
  About   Slides   Home  

 
Managed Chaos
Naresh Jain's Random Thoughts on Software Development and Adventure Sports
     
`
 
RSS Feed
Recent Thoughts
Tags
Recent Comments

Who needs a separate QA Team?

Have you come across developers who think that having a separate Quality Assurance (QA) team, who could test (manually or auto-magically) their code/software at the end of an iteration/release, will really help them? Personally I think this style of software development is not just dangerous but also harmful to the developers’ growth.

Having a QA Team that tests (inspects) the software after it’s built, gives me an impression that you can slap inspection at the end of any process and improve the quality of your product. Unfortunately things don’t work this way. What you want to do is build quality into the process rather than inspecting (checking) at the end of your process to assure quality.

Let me give you an example of what I mean by “building quality into the process“.

Back in the good old days, it was typical for a cloth manufacturer to have 10-15 power looms. They would set up these looms at the beginning of the day and let them run for the day. At the end of the day, they would take all the cloth produced by the looms and hand it over to another team (separate QA team) who would check each cloth for defect.

There were multiple sources of defects. At times one of the threads would break creating a defect in the cloth. At times insects would sit on the thread and would also get woven into the cloth creating a defect. And so on. Checking the cloth at the end of the day was turning out to be very expensive for the cloth manufactures. Basically they were trying to create quality products by inspecting the cloth at the end of the process. This is similar to the QA process in a waterfall project.

Since this was not working out, they hired a lot of people to watch each loom. Best case, there would be one person per loom watching for defects. As soon as a thread would break, they would stop the loom, fix the thread and continue. This certainly helped to reduce the defects, but was not an optimal solution for several reasons:

  • It was turning out to be quite expensive to have one person per loom
  • People at the looms would take breaks during the day and they would either stop the loom during their break (production hit) or would take the risk of letting some defects slip.
  • It become very dependent on how closely these folks watched the loom. In other words, the quality of the cloth was very dependent on the capability of the person (good eyesight and keen attention) inspecting the loom.
  • and so on

As you can see, what we are trying to do here is move the quality assurance process upstream. Trying to build quality into the manufacturing process. This is similar to the traditional Agile process where you have a couple of dedicated QAs on each team, who check for defects during or at the end of the iteration.

The next step which really helped fix this issue, to a great extent, was a ground breaking innovation by Toyoda Looms. As early as 1885 Sakichi Toyoda worked on improving looms.

Toyoda Loom

One of his initial innovation was to introduce a small lever on each thread. As soon as the thread would break, the lever would go and jam the loom. They went on to introduce noteworthy inventions such as automatic thread replenishment without any drop in the weaving speed, non-stop shuttle change motion, etc. Now a days, you can find looms with sensors which detect insect or other dirt on the threads and so on.

Basically what happened in the loom industry is they introduced various small mechanisms to be part of the loom which prevents the defect from being introduced in the first place. In other words, as and when they found issues with the process, they mistake proofed it by stopping it at source. They built quality into the process by shifting their focus from Quality Assurance to Quality Control. This is what you see in some really good product companies where they don’t really have a separate QA team. They focus on how can we eliminate/reduce the chances of introduction of defects rather than how can we detect defects (which is wasteful).

Hence its important that we focus on Quality Control rather than Quality Assurance. The terms “quality assurance” and “quality control” are often used interchangeably to refer to ways of ensuring the quality of a service or product. The terms, however, have different meanings.

Assurance: The act of giving confidence, the state of being certain or the act of making certain.

Quality assurance: The planned and systematic activities implemented in a quality system so that quality requirements for a product or service will be fulfilled.

Control: An evaluation to indicate needed corrective responses; the act of guiding a process in which variability is attributable to a constant system of chance causes.

Quality control: The observation techniques and activities used to fulfill requirements for quality.

So think about it, do you really need a separate QA team? What are you doing on the lines of Quality Control?

IMHO, in the late 90’s eXtreme Programming really pushed the envelope on this front. With wonderful practices like Automated Acceptance Testing, Test Driven Development, Pair Programming and Continuous Integration, I finally think we are getting closer. Having continuous/frequent working sessions with your customers/users is another great way of building quality into the process.

Lean Startup practices like Continuous Deployment and A/B Testing take this one step further and are really effective in tightening the feedback cycle for measuring user behavior in real context.

As more and more companies are embracing these methods, its becoming clear that we can do away with the concept of a separate QA team or an independent testing team.

Richard Sharpe made a great interview of Jean Tabaka and Bob Martin on the lean concept of “ceasing inspections”. In this 7 minute video, Jean and Bob support the idea of preventing defects upfront rather than at the end. Quality Assurance vs Quality Control

  • http://www.linkedin.com/in/gopinathr Gopinath

    Naresh, You  are confusing QA with QC and vice versa As per standard literature on Quality Management , detection of a problem is not Quality Assurance (QA) , it is QC (Quality Control). QA is actually prevention of a problem by putting in appropriate design, processes and trainings in place. Sometime back there was a similar discussion in Linked in to which I contributed. Have a look at it.
    Regards
    Gopinath

  • http://www.linkedin.com/in/gopinathr Gopinath

    Naresh, You  are confusing QA with QC and vice versa As per standard literature on Quality Management , detection of a problem is not Quality Assurance (QA) , it is QC (Quality Control). QA is actually prevention of a problem by putting in appropriate design, processes and trainings in place. Sometime back there was a similar discussion in Linked in to which I contributed. Have a look at it.
    Regards
    Gopinath

  • http://www.cynapse.com/ Apurva Roy Choudhury

    This is quite a myopic take on QA, from a developers standpoint, and these are the kind of mindsets that turn focus away from the customers/businesses / “Final Value Produce” perspective.

    Hope you take a 100ft view of the irreplaceable role of QA for the business as a whole, especially in the domains of tech & innovation

  • http://www.cynapse.com Apurva Roy Choudhury

    This is quite a myopic take on QA, from a developers standpoint, and these are the kind of mindsets that turn focus away from the customers/businesses / “Final Value Produce” perspective.

    Hope you take a 100ft view of the irreplaceable role of QA for the business as a whole, especially in the domains of tech & innovation

  • http://agilefaqs.com/nareshjain.html Naresh Jain

    Gopi, thanks for your feedback.  But can you please explain me the difference between QA and QC. My understanding is :

    QC activities include general methods such as accuracy checks on data acquisition and calculations and the use of approved standardized procedures for emission calculations, measurements, estimating uncertainties, archiving information and reporting. Higher tier QC activities include technical reviews of source categories, activity and emission factor data, and methods.

    Quality Assurance (QA) activities include a planned system of review procedures conducted by personnel not directly involved in the inventory compilation/development process. Reviews, preferably by independent third parties, should be performed upon a finalized inventory following the implementation of QC procedures. Reviews verify that data quality objectives were met, ensure that the inventory represents the best possible estimates of emissions and sinks given the current state of scientific knowledge and data available, and support the effectiveness of the QC programme.

    The key difference appears to be that QC is done by the people building a product at the time of building. While QA is done by an independent third party upon the completion of the product.

  • http://agilefaqs.com/nareshjain.html Naresh Jain

    Gopi, thanks for your feedback.  But can you please explain me the difference between QA and QC. My understanding is :

    QC activities include general methods such as accuracy checks on data acquisition and calculations and the use of approved standardized procedures for emission calculations, measurements, estimating uncertainties, archiving information and reporting. Higher tier QC activities include technical reviews of source categories, activity and emission factor data, and methods.

    Quality Assurance (QA) activities include a planned system of review procedures conducted by personnel not directly involved in the inventory compilation/development process. Reviews, preferably by independent third parties, should be performed upon a finalized inventory following the implementation of QC procedures. Reviews verify that data quality objectives were met, ensure that the inventory represents the best possible estimates of emissions and sinks given the current state of scientific knowledge and data available, and support the effectiveness of the QC programme.

    The key difference appears to be that QC is done by the people building a product at the time of building. While QA is done by an independent third party upon the completion of the product.

  • http://www.carltonnettleton.com/blog Carlton Nettleton

    QA is more about ensuring established processes are followed and finding the evidence they occurred.  The periodically inspect during the construction of the product.

  • http://www.carltonnettleton.com/blog Carlton Nettleton

    QA is more about ensuring established processes are followed and finding the evidence they occurred.  The periodically inspect during the construction of the product.

  • QualitySteve

    I’ve been reading quite a few blogs lately similar to this one (which was very well written by the way) and I feel shocked that QA guys are still encountering (or perceiving) this type of attitude still from development teams in 2009.

    By now, I would have expected nearly every IT or tech related team has heard the evils of waterfall/reactive development with mass manual testing tacked on at the end of the cycle with no time left for true iteration. Surely they have to know that quality isn’t just a department or phase, right?

    One thing I would suggest if you are running into this issue is find a company/team that sees the value in quality (not just QA/QC) and is willing to promote quality philosophies at every step, level, interview, meeting, widget, etc. Quality product is the cumulative effect of quality people, quality process, and quality details.

    In my current role, I have gone from just a “QA tester guy” to a quality evangelist and have forged some very good working relationships with production staff and development staff alike. They need to know what you can and can’t, should and shouldn’t, will and won’t do for them. They need to see you paying attention to defect density and module failure metrics. They need to see you taking an active role in sprint planning meetings as a stakeholder for at least acceptance tests – maybe even the scrum master! They need to see you talking to the tech director about unit tests and telemetry analysis.

    No matter who “fibs” to each other on the team (“Yeah, we’re tracking nicley towards shipping product boss!”), they need to see you as the truth bringer not the software cop – with data in hand. No emotional, adversarial debates necessary – just the true state of their software. And guess what – if your team doesn’t want that from you, you need a new team. They’re too junior to know quality even if you could miraculously bake it into their steaming pile of product and what’s worse, they may drag you down with their ship!

    This kind of quality assurance will gain you credibility with the teams and will give you the confidence you need in order to promote quality tenets when you need to. Good luck!

  • QualitySteve

    I’ve been reading quite a few blogs lately similar to this one (which was very well written by the way) and I feel shocked that QA guys are still encountering (or perceiving) this type of attitude still from development teams in 2009.

    By now, I would have expected nearly every IT or tech related team has heard the evils of waterfall/reactive development with mass manual testing tacked on at the end of the cycle with no time left for true iteration. Surely they have to know that quality isn’t just a department or phase, right?

    One thing I would suggest if you are running into this issue is find a company/team that sees the value in quality (not just QA/QC) and is willing to promote quality philosophies at every step, level, interview, meeting, widget, etc. Quality product is the cumulative effect of quality people, quality process, and quality details.

    In my current role, I have gone from just a “QA tester guy” to a quality evangelist and have forged some very good working relationships with production staff and development staff alike. They need to know what you can and can’t, should and shouldn’t, will and won’t do for them. They need to see you paying attention to defect density and module failure metrics. They need to see you taking an active role in sprint planning meetings as a stakeholder for at least acceptance tests – maybe even the scrum master! They need to see you talking to the tech director about unit tests and telemetry analysis.

    No matter who “fibs” to each other on the team (“Yeah, we’re tracking nicley towards shipping product boss!”), they need to see you as the truth bringer not the software cop – with data in hand. No emotional, adversarial debates necessary – just the true state of their software. And guess what – if your team doesn’t want that from you, you need a new team. They’re too junior to know quality even if you could miraculously bake it into their steaming pile of product and what’s worse, they may drag you down with their ship!

    This kind of quality assurance will gain you credibility with the teams and will give you the confidence you need in order to promote quality tenets when you need to. Good luck!

  • http://timuralhimenkov.ru/2009/01/chto-takoe-marketing Reader

    Great! Thank you very much!
    I always wanted to write in my blog something like that. Can I take part of your post to my site?
    Of course, I will add backlink?

    Regards, Timur I. Alhimenkov

  • http://timuralhimenkov.ru/2009/01/chto-takoe-marketing Reader

    Great! Thank you very much!
    I always wanted to write in my blog something like that. Can I take part of your post to my site?
    Of course, I will add backlink?

    Regards, Timur I. Alhimenkov

  • Hemant

    At best this blog describes a software process with a low level of maturity, atleast a decade behind industry.
    CMM, which has been around for more than a decade now has QA and QC built in, such that they are preventive.

    if i remember correctly, some of the earliest application of QA and QC well within the sw dev process (not at the end) was in the  70’s at IBM !!!

  • Hemant

    At best this blog describes a software process with a low level of maturity, atleast a decade behind industry.
    CMM, which has been around for more than a decade now has QA and QC built in, such that they are preventive.

    if i remember correctly, some of the earliest application of QA and QC well within the sw dev process (not at the end) was in the  70’s at IBM !!!

  • Robert Lewis

    Of course you should try to build quality in from the beginning, and developers should understand the range of tools available to help do that. However, it would be dangerous to assume that because you’ve written unit tests with 100% code coverage you don’t actually have to test the end product! On a big project, it becomes impossible for any one developer to understand everything that happens in the software, and someone has to run the finished product and see if it does what it’s supposed to.

    Maybe this isn’t what you’re suggesting, but you haven’t really admitted how important a final test cycle is either. Remember that in some cases, people’s lives can be at risk if software fails. I wouldn’t want to ship that kind of software without a lot of tests – and it’s the QA department that’s set up to do that kind of testing.

  • Robert Lewis

    Of course you should try to build quality in from the beginning, and developers should understand the range of tools available to help do that. However, it would be dangerous to assume that because you’ve written unit tests with 100% code coverage you don’t actually have to test the end product! On a big project, it becomes impossible for any one developer to understand everything that happens in the software, and someone has to run the finished product and see if it does what it’s supposed to.

    Maybe this isn’t what you’re suggesting, but you haven’t really admitted how important a final test cycle is either. Remember that in some cases, people’s lives can be at risk if software fails. I wouldn’t want to ship that kind of software without a lot of tests – and it’s the QA department that’s set up to do that kind of testing.

  • http://agilefaqs.com/nareshjain.html Naresh Jain

    Thanks Bob for highlighting this. I don’t think I’m saying we don’t need complete product testing. What I’m saying is you don’t want to wait till the end of your release to do complete product testing. You want to do that much earlier in your process.

    If you look at my Automated Acceptance Testing slides, I talk about 2 types of test. Tests that Drive Development and Tests that critique the product. The kind of tests that you are talking about certainly fits into the critiquing the product category. Most of which are automated and some are not.

    Personally I don’t think you need a separate QA department to do this kind of testing.

  • http://agilefaqs.com/nareshjain.html Naresh Jain

    Thanks Bob for highlighting this. I don’t think I’m saying we don’t need complete product testing. What I’m saying is you don’t want to wait till the end of your release to do complete product testing. You want to do that much earlier in your process.

    If you look at my Automated Acceptance Testing slides, I talk about 2 types of test. Tests that Drive Development and Tests that critique the product. The kind of tests that you are talking about certainly fits into the critiquing the product category. Most of which are automated and some are not.

    Personally I don’t think you need a separate QA department to do this kind of testing.

  • http://agilefaqs.com/nareshjain.html Naresh Jain

    Timur I. Alhimenkov, sure you can. All this stuff is released under Creative Commons, which means you have the write to modify this and reproduce it. And I don’t think these ideas are either new or compelling enough that someone will buy them.

  • http://agilefaqs.com/nareshjain.html Naresh Jain

    Timur I. Alhimenkov, sure you can. All this stuff is released under Creative Commons, which means you have the write to modify this and reproduce it. And I don’t think these ideas are either new or compelling enough that someone will buy them.

  • http://agilefaqs.com/nareshjain.html Naresh Jain

    Hemant, out of the CMM companies I’ve been to, I’ve not seen what you are talking happening. This is what I hear from most people @ those companies is that they struggle building the product so it can be deployed and tested. Focusing on quality is the last thing they want to think about.

    Some of the earliest application of QA and QC well within the sw dev process (not at the end) have been around from the 60’s.  Esp. during the Software Crisis. Somewhere along the line, we lost it.

  • http://agilefaqs.com/nareshjain.html Naresh Jain

    Hemant, out of the CMM companies I’ve been to, I’ve not seen what you are talking happening. This is what I hear from most people @ those companies is that they struggle building the product so it can be deployed and tested. Focusing on quality is the last thing they want to think about.

    Some of the earliest application of QA and QC well within the sw dev process (not at the end) have been around from the 60’s.  Esp. during the Software Crisis. Somewhere along the line, we lost it.

  • Steve Engels

    I agree and disagree with your points you make regarding the need for QA on a software dev project. first the agree’s…

    interjecting QA into the entire project lifecycle is absolutely necessary, across all disciplines of the project team! PM, BA, Business Owners, QA, DEV, etc…everyone should be focused on QA. On the projects we’ve run here at Object Partners, Inc., for many years now we have adopted a test driven and continuous integration mentality plus total project status transparency towards all projects, big or small. The TEAM is held accountable for the quality of the deliverables, wether that be stories, use-cases, code, test scripts, etc…

    Now for what I disagree with…I DO think that having a group or individual who focuses on testing the deliverables provides many benefits to the project.

    often our QA Group has found defects missed by our dev group, even in the presence of a team that was highly focused on quality by doing test first development, paired code reviews and testing, continuous build, etc. A separate QA individual will always test a deliverable different than the people who built it will…FACT!
    deliverable completion verification by our QA group is a good check-n-balance with our development effort in a way that is acceptable to our clients. Our QA teams are involved in the project from the scoping phase so that they can hear, 1st hand, from the users and business owners what the need is for the scope currently in focus.
    Additionally our QA team plays a major role in the User Sessions where a group of Users exercise the current increment’s (usually about 6 weeks worth of effort) functionality. They take a lead in collecting user feedback and organize the feedback into a format suitable for future iteration planning sessions.
    our QA group also takes the lead in identifying tools for use by the team related to the QA effort such as automated test tools, defect tracking tools, test methodologies, etc., and
    last but certainly not least, our clients still expect to see a separate QA function on their projects. The perception is that if QA is left only to the development group, then the resulting deliverables will be of lower quality. Even if your organization internalizes all of the QA principles within its development group, which we have seen work before, the PERCEPTION by the client is still an issue to be dealt with.

  • Steve Engels

    I agree and disagree with your points you make regarding the need for QA on a software dev project. first the agree’s…

    interjecting QA into the entire project lifecycle is absolutely necessary, across all disciplines of the project team! PM, BA, Business Owners, QA, DEV, etc…everyone should be focused on QA. On the projects we’ve run here at Object Partners, Inc., for many years now we have adopted a test driven and continuous integration mentality plus total project status transparency towards all projects, big or small. The TEAM is held accountable for the quality of the deliverables, wether that be stories, use-cases, code, test scripts, etc…

    Now for what I disagree with…I DO think that having a group or individual who focuses on testing the deliverables provides many benefits to the project.

    1. often our QA Group has found defects missed by our dev group, even in the presence of a team that was highly focused on quality by doing test first development, paired code reviews and testing, continuous build, etc. A separate QA individual will always test a deliverable different than the people who built it will…FACT!
    2. deliverable completion verification by our QA group is a good check-n-balance with our development effort in a way that is acceptable to our clients. Our QA teams are involved in the project from the scoping phase so that they can hear, 1st hand, from the users and business owners what the need is for the scope currently in focus.
    3. Additionally our QA team plays a major role in the User Sessions where a group of Users exercise the current increment’s (usually about 6 weeks worth of effort) functionality. They take a lead in collecting user feedback and organize the feedback into a format suitable for future iteration planning sessions.
    4. our QA group also takes the lead in identifying tools for use by the team related to the QA effort such as automated test tools, defect tracking tools, test methodologies, etc., and
    5. last but certainly not least, our clients still expect to see a separate QA function on their projects. The perception is that if QA is left only to the development group, then the resulting deliverables will be of lower quality. Even if your organization internalizes all of the QA principles within its development group, which we have seen work before, the PERCEPTION by the client is still an issue to be dealt with.
  • http://www.linkedin.com/in/gopinathr Gopinath

    Naresh,
    Your definition of QA and QC in your article is correct. However you are (and so do many companies, especially product companies) interpreting testing and inspection as QA activity, which is not consistent with what the standard literature says. So the title of your article should be “Who needs a seperate QC (Testing) team ?”. Now testing and inspections are certainly an overhead but nevertheless indispensable because we cannot create a perfect product and we need a group which independently tests and tries to prevent a defective product from going out on the field. The group which develops the product is keen on demonstrating that the “product works” whereas the testers need to “break the product”. Better to prove internally that the product does not work , rather than the customer telling you so. However the objective of any project should be to invest upfront on developing good processes, tools and training with a goal of minimizing the defects. And this what QA is (in conventional sense). In the companies that follow standard Quality models like ISO/CMMI, you generally have a seperate QA team (either full time or part time), which works with the project teams to define the process, tools and provide training. Their job is NOT testing or inspecting. But they do periodic audits to see whether the process is followed properly.
    Please refer this link QC vs QA. It clearly brings out the difference between QA and QC
    Gopinath

  • http://www.linkedin.com/in/gopinathr Gopinath

    Naresh,
    Your definition of QA and QC in your article is correct. However you are (and so do many companies, especially product companies) interpreting testing and inspection as QA activity, which is not consistent with what the standard literature says. So the title of your article should be “Who needs a seperate QC (Testing) team ?”. Now testing and inspections are certainly an overhead but nevertheless indispensable because we cannot create a perfect product and we need a group which independently tests and tries to prevent a defective product from going out on the field. The group which develops the product is keen on demonstrating that the “product works” whereas the testers need to “break the product”. Better to prove internally that the product does not work , rather than the customer telling you so. However the objective of any project should be to invest upfront on developing good processes, tools and training with a goal of minimizing the defects. And this what QA is (in conventional sense). In the companies that follow standard Quality models like ISO/CMMI, you generally have a seperate QA team (either full time or part time), which works with the project teams to define the process, tools and provide training. Their job is NOT testing or inspecting. But they do periodic audits to see whether the process is followed properly.
    Please refer this link QC vs QA. It clearly brings out the difference between QA and QC
    Gopinath

  • http://agilefaqs.com/nareshjain.html Naresh Jain

    Thanks Gopi for your comment. I would like to clarify somethings here:

    Now testing and inspections are certainly an overhead but nevertheless indispensable because we cannot create a perfect product

    Personally I don’t think the goal is to build a perfect product. Software development is an evolutionary process and the product might get perfect over time, but the goal is not to get a perfect product right away. Depending on the product you might decide how much perfection is required for your first release. For example if its a Web 2.0 app, may be you don’t need 100% perfection. But if you are building a medicare product may be you need a higher perfection.

    But of course you want to make sure the most important functionality is working as expected in any case (which I think the developers and embedded tester should be able to take care of).

    One thing I’ve never seen actually work is having an external team deciding what tools, processes and training a team needs. Personally I think its too much to expect from an external team. Simply because they are not in a position to decide that. They might give suggestions, but at the end of the day, the team has to have capabilities and rights to make such decisions.

    As you have pointed out, Process Adherence is another classic job of a QA team. Again this is another form of inspection and I think the ROI from such activities is very low. In some cases it does more harm than good.

  • http://agilefaqs.com/nareshjain.html Naresh Jain

    Thanks Gopi for your comment. I would like to clarify somethings here:

    Now testing and inspections are certainly an overhead but nevertheless indispensable because we cannot create a perfect product

    Personally I don’t think the goal is to build a perfect product. Software development is an evolutionary process and the product might get perfect over time, but the goal is not to get a perfect product right away. Depending on the product you might decide how much perfection is required for your first release. For example if its a Web 2.0 app, may be you don’t need 100% perfection. But if you are building a medicare product may be you need a higher perfection.

    But of course you want to make sure the most important functionality is working as expected in any case (which I think the developers and embedded tester should be able to take care of).

    One thing I’ve never seen actually work is having an external team deciding what tools, processes and training a team needs. Personally I think its too much to expect from an external team. Simply because they are not in a position to decide that. They might give suggestions, but at the end of the day, the team has to have capabilities and rights to make such decisions.

    As you have pointed out, Process Adherence is another classic job of a QA team. Again this is another form of inspection and I think the ROI from such activities is very low. In some cases it does more harm than good.

  • http://www.linkedin.com/in/gopinathr Gopinath

    Naresh,
    “Depending on the product you might decide how much perfection is required for your first release.”
        Agreed. If you can send out an Acceptable level of Quality of product from customer perspective, by doing developer testing or by embedded tester testing alone that is fine. But such testing needs to be done by a person who does not own the code.

    “One thing I’ve never seen actually work is having an external team deciding what tools, processes and training a team needs.”
        External QA team are not supposed to decide on its own. They are facilitators and are supposed to work with the project team. I agree that the project team has the capabilities and rights to make such decisions. But I have seen this never happens or happens in a rather ad hoc manner because they have their project pressures and are short term focussed. So many organization uses an external QA team to facilitate this.

    “Process Adherence is another classic job of a QA team. Again this is another form of inspection and I think the ROI from such activities is very low. In some cases it does more harm than good.”
         If a project team follows a consistent and sensible process without any trigger from a QA team. Then there is no need for QA.  Each and every person should be conscious of following a good process and deliver a good product. This is what TQM (Total Quality Manamement) is all about. Unfortunately this remains an Utopian dream and that’s why we need QA to ensure process adherence.

  • http://www.linkedin.com/in/gopinathr Gopinath

    Naresh,
    “Depending on the product you might decide how much perfection is required for your first release.”
        Agreed. If you can send out an Acceptable level of Quality of product from customer perspective, by doing developer testing or by embedded tester testing alone that is fine. But such testing needs to be done by a person who does not own the code.

    “One thing I’ve never seen actually work is having an external team deciding what tools, processes and training a team needs.”
        External QA team are not supposed to decide on its own. They are facilitators and are supposed to work with the project team. I agree that the project team has the capabilities and rights to make such decisions. But I have seen this never happens or happens in a rather ad hoc manner because they have their project pressures and are short term focussed. So many organization uses an external QA team to facilitate this.

    “Process Adherence is another classic job of a QA team. Again this is another form of inspection and I think the ROI from such activities is very low. In some cases it does more harm than good.”
         If a project team follows a consistent and sensible process without any trigger from a QA team. Then there is no need for QA.  Each and every person should be conscious of following a good process and deliver a good product. This is what TQM (Total Quality Manamement) is all about. Unfortunately this remains an Utopian dream and that’s why we need QA to ensure process adherence.

  • Pingback: Naresh Jain » Agile FAQs Blog » Managed Chaos » Separate Developers for Functional Testing?()


    Licensed under
Creative Commons License