code metrics plays a huge role in quality assurance. Hence, that is assuring the quality of an application. Elisabeth Hendrickson has taught me that defect metrics become pointless when we don't allow major defects into the application. This too assures the quality of the system. As a QA Analyst it is my job to report the level of quality of a system or application. As a tester it is my job to discover defects in the system and report those to the stake holders. This is why I see a very strong division. QA is about the process and QC is about the product.
Software Quality Assurance is primarily concerned with assuring the quality of the software development process rather than the quality of the product (Dorfman, 1996)*. Quality Assurance is the set of support activities (including facilitation, training, measurement, and analysis) needed to provide adequate confidence that processes are established and continuously improved to produce products that meet specifications and are fit for use. Quality Control is the process by which product quality is compared with applicable standards, and the action taken when nonconformance is detected. Its focus is defect detection and removal.
I agree with Elisabeth completely about the idea of tracking defect metrics. I am not sure the other metrics you mention, provide a lot of value if you are testing each story as it is built.
You talk about the QA Analyst and tester as two separate roles. Do you have different people performing these roles? In traditional phased and gated projects, there tends to be that differentiation - I'm a test designer or analyst so I will create the tests. You, as the lowly tester get to run them over and over and over again to make sure the application doesn't break. In agile projects, we want to blur the roles so that no one can say "that's not my job". We want everyone to take ownership of quality. I believe when we start naming specific roles, we pigeon hole ourselves into that role and stop looking at the big picture. If I think my job is only to report defects, my attitude can become detrimental to the team's cohesiveness. One of the agile values on the manifesto is “People over process”, meaning, let’s think about the people first. They are the ones who make things happen. One of my favourite sayings to testers who are new to agile projects is, "Instead of thinking your job is to break the software, consider instead, how you can best help the team to deliver good software".
One of the tasks to help the team might be to provide information on the quality level of the system (metrics). Another might be to find and report defects (preferably to the project team first) as a form of feedback. Can you see where I’m going with this?
Good points Janet, and yes I see where you are going. Allow me to answer your first question. In our development process we do have different people serving as a QA Analyst and a Tester. Of course, I would like to qualify that a bit in that most, if not all, parties involved do some level of testing. The visual testing of a GUI or the unit testing of a specific method in the code is all part of testing. As far as system level and user acceptance testing, we have one person for each of these roles. The UAT is typically done by a BA or a Product Owner. The system level testing (positive and negative test scenarios) is done