Stop trying to be something you're not!

I recently helped a client understand how QA (does our process work?) applied in an 'Agile' process that used SCRUM as it's foundation. Testing was nowhere to be found in the list... instead, testing fell within quality control (does our product work?)

Common 'Agile' practices such as Release Planning, Iteration (or Sprint) Planning and Retrospectives all played a part in answering the question "does our process work?". If you apply the Deming/Shewhart PDCA cycle, you can see how this applies.

Plan - Iteration planning especially represents process in the form of the tasks you identify and the discussion around tasks and how they'll be executed.

Do - well - we do the tasks as part of the iteration.

Check - monitoring the percentage of time our build is green vs red and more importantly the hard (metrics) and soft (team perceptions) inputs in the retrospective play a significant role in checking if our process works.

Act - we need to take the learning from each retrospective (conducted in each iteration) and ensure that any enabling tasks are in the queue for the next iteration and the team agrees to consider any process alterations as part of their estimates during planning.

Executing automated tests, continuous integration and exploratory testing were answering the question "does our product work?"

If an 'Agile' team is performing the actions that address the question "does our process work?" but use the term 'QA' to refer to activities that answer the question "does our product work" then that's probably not a problem (for them)...

My issue is when teams use the term QA incorrectly but also aren't doing activities that meet the purpose of QA... If they are convinced that they already have QA covered, then what reason do they have to consider that there's an important question that they have left unanswered....

In short...
If your doing QA & QC but calling them something else - that's less of a problem than if you are doing QC, calling it QA and doing nothing else.

Antony Marcano

On most test-related mailing lists, people seem to know that QA is not testing. At the last 2 agile conferences I have been to, 80% of people were talking about QA when they really meant testing. I think the battle may already be lost ;(


Erik Petersen
www.testingspot.net

Antony, you are right, I somehow missed to quote ... "defined in many places" ... synonymous with testing. Sometimes I think too fast :) .
Well, my message is following - I vote for balance between making QA equal to tests and defining QA as specialty skill sets that only the elite can do.
When I faced issue of not being "empowered or skilled" I used term QA to empower myself and approach similar to http://www.michaeldkelly.com/images/CAST2007_SpecialistsAndOtherMyths.pdf to be a productive contributor to a project

I’m not QA expert, but I believe I am able to ask the question “does our process work?” What I’m not skilled to do – solve the issue once the answer is NO. But I also can’t fix the product bugs as a tester…

Firstly, I think you may have a typo in there... Do you mean "QA is not sysnonymous with testing"?.

My point was that QA is not synonymous with testing.

Secondly, 'QA' is, as Ben put it, a team effort. The 'team' in this context is the entire development team - project managers, developers, testers - everyone involved in a project.

To give feedback to development about process based on the problems it causes in testing is a somewhat narrow view and is at best only a partial application of QA.

If someone is empowered and skilled to do real QA then they will be able to bring about change across every discipline to improve the team's ability to deliver working software.

Antony Marcano

I agree with both Antony and Ben. QA is indeed synonymous with testing. There are so many “political” reasons for that… like “because we need QA Manager signoff”, I also blogged 2 years ago a story about our so called “QA department” actually doing testing job…

What I practice myself is to take this (management calling you a QA instead of testing) as advantage of doing QA. Implement improvements into testing process (waiting not for management approval, because they have delegated this task to you, while calling you QA), point out issues in development process that makes testing harder or longer. For example, ask – what’s the developer created unit test coverage? Why so little? You may learn that this is actually what they want you to do at the end of the day.

Of course our process works. It's labeled a "best practice" so it has to work. Real leaders implement other's best practices. There's no need to ask if it works in our context. ;-)



I think that many use "QA" when they really mean "test". They don't even realize that quality assurance involves more than testing. The perception is so ingrained in people that many see no difference between testing and QA. I often hear developers, testers, and project managers use QA as they would the word test.

"I'm going to QA the product."

"I am QAing the software."

"Please check the calculation results when you QA the new features."


Software is design and engineering work, not repetitious manufacturing work. Neither testing or process can assure quality. Whether I write code, test, or implement processes: I'd rather not be thought of as the one that assures quality. Quality is a team effort.


Ben Simo
QuestioningSoftware.com

I hope to make time to write up a STARWest report soon.

Watch this space.

Antony Marcano