Janet Gregory has been a long time icon of mine. When I was asked to write an article for the Agile Journal regarding Agile testing I was honoured. The first person I thought of was Janet Gregory and Lisa Crispin as their book, Agile Testing, was a huge help to me when I was first learning about this topic. After contacting Janet about co-authoring the article, we quickly discovered that we had a very strong difference of opinion. We decided to share that with you in this article. You may feel strongly one way or another from reading this article, and the comments from the conversation, but please remember we are all trying to do the same thing. Increase quality, of our software, and help others to do the same.
I see a clearly defined difference between quality assurance as an activity or effort in preventing defects from entering the system and agile testing, which would be any activity in discovering defects in the system.
I really don’t like to draw a distinction between the two ideas. What testers do on an agile team is testing. The prevention part is testing up front - I test the assumptions, I test the customer’s interpretation of the problem, etc. I don’t like the phrase “quality assurance”, because I don’t think we can actually ever ‘assure’ the quality of a product.
Ok, so if you are on a Scrum team and you are in a planning meeting, who is responsible for ensuring that the stories are testable? Not that I am saying you need to actually test the stories then and there, but who raises their hand and states that a story is un-testable? I do not see that as testing, I see that as quality assurance. Here, you are assuring the quality of the application through defect prevention, by not allowing the team to have a poor story in the next iteration.
Over the years the phrase, 'quality assurance or QA', has changed to mean different things to different people, which is I really hesitate to use it.
As a tester I don’t need developed software with a UI to start testing. I can test a requirement and test the proposed solution. I encourage people to test scenarios if the customer draws a flow diagram. I can ask for, and maybe provide examples and edge cases as tests. These types of tests (business facing tests that support the team) [i], help everyone to get a shared understanding of what to expect, and eliminates many hidden assumptions.. Is that quality assurance? I find it simpler to say that it is testing to support the team in its effort to reduce the rework fixing defects later. Once we’ve developed something, we can validate it against these examples (or tests) and check to see if it is acceptable. I believe that is what you are calling testing.
You also asked who is responsible for ensuring the stories are testable. As a tester, I have a special interest in it. If it is not obvious, I will ask the question in the planning session. However, it is the whole team's responsibility to make sure it meets that quality attribute.
I will agree with you that it is difficult to assure certain levels of quality; however, we can assure that the application has a certain code coverage level, that we require a code coverage percentage to class files with a code complexity rating of a certain number. I know I am getting into the metrics argument, however I think that