With all this talk of test driven development, one has to naturally ask, “Where does the QA department fit in? Do they even have a role in the organization any more?”
Well, the answer to that is, “absolutely but probably not the role they think they have.”
QA People Are Not Programmers
Once again, as I visit organizations, I find that they are trying to use automated testing tools to script their test. This ends up being a fool’s errand because most QA people are not programmers and to create a script that is actually going to work reliably, that is going to take a programmer.
Jr Programmers Are Not QA People
The other related problem I frequently see is that organizations tend to put junior programmers in the QA department to handle this “trivial programming task” when what they really ought to be doing is placing senior level programmers in the department because they are more likely to be able to predict what could go wrong. But I digress.
By moving to a test driven development process, you actually end up solving the problem of QA needing programmers because you’ve moved the creation of the scripts away from the QA department and back on to the programming staff where it belongs.
So what is the point of having a QA department if they are no longer going to create test scripts?
The Proper Role of QA
They have the same function they’ve always had. Their job is to try to break the program. To find all of the conditions the programmers left out when they wrote the code and to report those problems back to the programming staff where they can write a test for the problem and fix the bug.
This may sound like a job that anyone can do, but remember that once they’ve broken the program they have to document how they broke it in a way they can repeat so that when the problem is reported to the programming staff, the error is easy to find. This requires an attention to detail that few people have.
Other post in TDD
- Why Don't You Practice Test First Development? - February 20th, 2014
- Test Driven Specifications - February 25th, 2014
- Unit Test Structure - March 11th, 2014
- When You Really Need All Of Your NUnit Test In One Class - March 18th, 2014
- TDD Isn’t All About Testing - March 25th, 2014
- Automated Web Application Functional Testing - April 1st, 2014
- What Not To Test - April 9th, 2014
- Make Your Test Work For You - April 18th, 2014
- Don’t Comment Out That Test - April 24th, 2014
- The Proper Function of QA - May 1st, 2014
- TDD Saves Time – A Story - May 22nd, 2014
- It is called "Unit Testing" for a reason - August 28th, 2014
- Is Your Architecture Crippling Your Unit Testing? - September 4th, 2014
- Selenium Performance Improvements - October 2nd, 2014
- Technical Debt Is Inevitable - October 16th, 2014
- NUnit, Unity Dependency Injection, MOQ and Private Fields - October 23rd, 2014
- NUnit & Visual Studio - December 4th, 2014
- Software Architecture without Test Driven Development is DANGEROUS! - January 29th, 2015
- NUnit Test Code Structure - February 5th, 2015
- Excuses For Not Testing - February 26th, 2015
- Why Johnny Can't do Test Driven Development - March 5th, 2015
- Changing Habits - March 19th, 2015
- 100% Code Coverage Possible? - March 26th, 2015
- TDD Gamification - Turning Test Driven Development into a Game - April 23rd, 2015
- Run NUnit from Visual Studio - April 30th, 2015
- The Parable of The Road Line Painter - May 28th, 2015
- The Fallacy of Motion - July 23rd, 2015
- Test Driven Learning - An Experiment - March 24th, 2016
- 3 Reasons You Believe 100% Code Coverage Is Impossible - May 26th, 2016