Who decides if the product ready?

In my career I have often been in the situation when I was asked whether or not the product is ready to be shipped. After so many times I was through it I still hesitate when I am asked this question. The reason why I couldn't answer it for sure is that I do not have all the required information to draw a decision.

Being a quality manager all I can judge upon is the quality. But the quality is not the mere criteria to take into consideration when trying to figure if you are ready to release. There are also business demands and limitations, promises made to customers, market situation, corporate strategy, and so on. All those questions are beyond the authority of a quality manager.

So, what to do if you are asked this question yet. Below is how I would behave at different positions.

Quality manager

Above I mentioned that the only criteria you can asses is the quality. You have to start answering this question since the very start of the project. You have to build this answer with all the activities on testing and QA throughout the project timeline. Start building it up from the very beginning - test strategy and keep it in sight all the time. Assess and mitigate quality risks. as you learn new information about the product do the corrections of testing course.

When it's time to answer this question, use all the information you have collected. Just compare metrics against previous similar releases (or against you previous experience with similar systems) and state things as they are, without too much of optimism. If the product is a crap say so. Don't be afraid. You will not be punished for the truth in case you kept saying so all the time when you were asked. Saying that everything is fine during the project and demanding that it's a crap in the end looks unprofessional.

Providing your answer make sure that everyone understands that you are talking of QUALITY CRITERIA ONLY. So that no one can bear an incorrect opinion that you are taking the responsibility for a BUSINESS DECISION.

The best way to say it IMO:
- All the testing we have planned is completed. No issues that are considered critical for the release are open. Latest cycles of testing did not reveal many regression issues. The changes in the latest builds were scarce and undergo all a strict process of risk assessment and regression testing. Fixes which were too risky to do have been moved on to the next version. I can say that we are in good shape from the quality perspective.

In case it's not as good you may also add:
- However, we have experienced significant problems with testing the system under high load. The tools that we have used did not allow us generating required load capacity. So, we do not know how system reacts to peak load. It is a risk for the system operation. After discussion with management we decided that this risk can be accepted.

In the case when it's not good at all:
- Every time we start testing the system it brings many new issues. Defect arrival rate is at almost the same rate all the time. It stays as high as X defects per day till the very end of testing cycle. I would strongly recommend analyzing the reason why we introduce so many defects, improve the process and do another cycle of development and testing to create a product of acceptable quality.

Project manager

As a project manager you have to be sure that your quality manager is confident with the quality of the release. If it is not the case then try to find out the nature of the risks. Assess those risks against project goals and made a decision. It can be a hard one nonetheless you are in better position to make it than anyone else on the project team.

Software tester

I knew several top managers who liked asking it to software testers. They believed that they can get to know the information from first hands, thus testing the correctness of information provided by middle level managers. I don't think this is a good idea. Anyway, as a tester, you need to be prepared. Before giving the answer, make it clear that you can answer only based on YOUR experience with the system. Your experience may be limited to some module or type of testing. If it went good then say that only that system's feature is OK. Do not pretend you possess all the information to say so about the whole product. This may be a killer. I also was in the situation when I was asked "why do you say that everything goes smooth if your guy told me that his module is full of bugs and he sees no end to it?" or opposite "why do you keep telling me that things go so badly when your guys report the system is fine?". Do not put your manager in the situation like this.

Top manager

Well you have someone to report to (board of directors or something) you also need to weight your words. The most dangerous but exciting about your position is that this decision is completely yours. So, don't show a weakness and don't expect that someone else will step up and do it for you. All the responsibility as well as all the fame is yours.

Before making a decision, ask your managers (quality and production). But don't be pushy. Do not force them saying what you want to hear. Be as objective as you can.

It's all for now. Sorry for a mess in thoughts I wrote it real fast. Hope this helps you avoid embarrassing situation when you are asked if the product is ready to be released.

Bad process or bad implementation?

Recently, in a course of a training session, we touched ground on what seems to be an interesting topic to me. One of training attendees raised a discussion related to pro and cons of different processes. In order to prevent another holy war I warned everyone that it scarcely matter what process people do use. What really matters is whether they know how to use it. Fool with a tool is still a fool.

Same is true to the processes. We have invented several big-name process as well as dozens of not so famous ones, however we keep looking. Why? - Because we are not satisfied with the results. Because we think that things could be organized better. And all we do in this intention is going cycles around several simple ideas (think ahead, do just enough, think before doing, think after you are done, observe and make corrections). All the process that I know of, are about these concepts, wrapping them in different objects, providing different interfaces to the user. Though the ideas behind stay as simple.

If we all use the same underline ides why some are successful and some are not? The answer is not in the plane of definition but it's in the plane of implementation. Do you remember that saying above? ;) The process is not a panacea. If you expect that a weak, diseased organization wearing a CMM hat will do much better then you are deadly wrong. People are what make processes to work or to fail. People are undermining it by doing thing "slightly different" or doing "just opposite" only because they think that they know better. Just look around and see if there are any of those characters right beside you. And start correcting things right away. Start from yourself ;)

P.S. I am not saying that all the processes are equally feasible for all teams. No. I only was speaking that nearly all the processes are GOOD and COULD HAVE BEEN WORKING if they were applied correctly. Anyway, the process is always better than no process at all. If it's your case, you know where to start! :)

Three simple ideas on management

Today I had an interesting conversation with a manager who is in charge of testing at some world famous organization here in Minsk. She told me that she is about to go on long vacation, so she needs to teach one of her champions how to cope with things while she is out.

One interesting thing I noted is that she realized how much she is of a manager only after trying to teach someone else. Well, this is a known old effect when one can only learn how she knows something by trying to teach someone else. Despite we believe we know something we may have troubles explaining it because the knowledge is scarce and has gray areas, things that we never knew but nonetheless important to get the whole idea. And otherwise, for some of us it is important to test the knowledge by teaching others. This what she did and how she got to know that she is much more powerful a manager than she realized. Try yourself ;)

Another thing we touched is management and who is capable of doing it right. We both come from the same organization where she was my team leader. We know our managers well enough and went into discussing their strong and weak points. One of the most discouraging I found is blaming someon else in the failure. Manager is responsible for all work created by the team. So there is no sense and even more damage to the image in trying to guard against the blame with the subordinates. The relationships between manager and subordinates are built upon trust and openness. If the former blames the latter then this link break free, so there is no normal relationships after that.

The third interesting topic of discussion was aptitude. We both agreed that a person is on rightful place in the organization needs only slight attention and rare correction from a manager. Ijn contrary, a person who misbehaves often and requires a lot of attention from managers will only become a greater distracter in the future. So, finding the right place is very important. No matter who you are employer or an employee.

If you are not at the right place move on. Don’t waste time, yours and that of a manager! :)