Who gets to decide when to ship software?

I recently got in a lengthy debate with some folks over this very topic.  As I quickly found out, most folks have a very strong opinion on this.  And here I thought I was the only oneJ.  It seems as though most folks fall into 3 different camps: 

Camp #1 – The Testers decide 

This “camp” was formed of folks on waterfall and agile teams (which I found interesting).  They felt that the team that tests the software and was most familiar with the quality and test coverage should get the final say on whether or not to ship it. 

Camp #2 – The Project Manager decides 

This “camp” applied to people on more traditional waterfall projects.  They felt that the project manager knew all of the data points with the project and based on that data should be responsible for determining when to release software.  However, this project managers did not have ROI responsibility. 

Camp #3 – The Product Manager (aka: ”the business”) decides 

This “camp” applied to people that were staffed on more agile projects.  On these teams that had a strong product owner presence, they felt that since the product owner was ultimately responsible for the ROI, then they should decide what and when to ship. 

Camp 1 had the most votes followed by camp 2 and then camp 3 had the least amount.  In some ways this surprised me but in other ways, it was what I was expecting. 

I will admit that I used to be a member of Camp #1.  As a matter of fact, I believe at one point I might have actually been the camp founder and directorJ  However, over time, I have moved to Camp #3.  Let me tell you why. 

Testers typically do have the most insight into the quality of the software.  We are intimately familiar with what is working, what isn’t, and what the high risk areas of the application are.  We can tell you the defect trends, defect turn around time, severity break downs, etc.  Because of this, it is easy for us to feel like we should be the decision maker as to whether or not we should put this code into our customer’s hands.  However, often times, there are several things we do NOT know that also play in to the decision of whether to ship code or not.  Perhaps there is a large business deal that will fall through if we don’t ship.  Perhaps the customer (or customers) wanted the new code so badly that they were willing to take the risk of using it with the list of known issues.  Perhaps the business wants it shipped for demo purposes but isn’t planning on having customers use it until it is cleaner.  Perhaps the business is planning a Beta / trial period.  The list can go on and on.  You get my point.   

Here is what I think about the testers’ role in deciding when to ship software.  I think the tester is responsible for delivering all of the metrics around the quality of the code to the business.  Deliver the facts, not your emotion.  Include test coverage, defect count, defect find rate, etc.  Make sure the business has a solid grasp on the current state of the code and any risks associated with shipping this code.  Then, do the hardest thing possible…..trust that the business team will make the right decision based on those facts and any other data points they may have.

Then, I also firmly believe that the business should CLEARLY COMMUNICATE with the delivery team why they made the decision to ship (or not ship) the software.  This is particularly important if they decide to ship software that the testers don’t feel is ready to ship.  The business should let the team know that they understood the risks but made the decision to ship based on the following facts (at this point, they should clearly list out the reasons why they are shipping).

 If you think a bad decision was made and don’t know why, then by all means ask for an explanation!

Should we be called QA Analysts?

I have been thinking a lot about titles lately and just how much I detest them 🙂  I do love the fact that my current title (QA Architect) is something most people have never heard of so it prompts them to ask me what I really do.  It gives me a chance to explain to folks what I actually do at work, not what they will assume I do based on my title!  Common titles can be very misleading to what people actually do.  The title of QA Analyst or QA Engineer is a perfect example.  I am going to pick on this because I had this title for a long time.  (The same goes for QA Manager).  There are several reasons why I hate these titles.  Here are the top 3 reasons why:

1.   If someone on your team has the title of QA Analyst, they typically bear the responsibility of the end quality of your product.  People start to say things like, “The QA folks will test it…don’t spend too much time testing your code.”  Or, “QA will catch it if there are bugs.”  Since when did the end quality of the product rest solely on the QA staff?  Everyone on your team should be responsible for quality, not just the folks testing the software.

2.   QA Analyst of what exactly?  It sure is vague.  Everyone just assumes it means the quality assurance analyst or engineer of the application you are building.  Why are there people with the word “quality” in their title only on the development side?  What about the quality of the entire development process, the quality of the designs, the quality of the sales team, quality of support?  By putting a “QA” title in development only it seems like we are really missing the boat by not looking at quality across the organization in all roles.

3.   When you tell someone that you are a QA person, you have just stuck a huge label on yourself.  It may be a good label or a bad label depending on who you are talking to.  Some QA folks focus solely on testing.  Some QA folks are really focused on SDLC only.  By telling someone that you do “QA”, you may not be telling them what you really do at all.   

Here is what I would love to see.  I would like to see people that focus on testing called “Testers.”  Nothing more, nothing less.  If the main purpose of your job is to test the application to ensure that it is working as it should, then just call yourself a tester.  People that develop code are just called developers, not “Quality Developers”.  Let’s call a spade a spade here.  If you test, then just say you are tester.  You should not be ashamed of that! 

Then, ideally, you WOULD have someone in your organization that is overseeing quality.  However, this person would be looking at quality across the board.  They would be analyzing processes, etc from the sales team all the way through development and then to the team that supports the customers.   Depending on the size of your company, this could be a whole team of folks.  Make sure these people know what they are doing and have been in the trenches actually “doing it” before.  Also, make sure these folks are trained on the Lean Principles of software development  to get the biggest bang for your buck.

What is your current title?  Do you think it reflects what you really do?