We all are!
I get a kick out of watching the news for “quality” issues – or should I say “lack of quality” issues! There are usually lots of them.
Someone recently told me that there is no difference between Quality Assurance and Quality Control. Seriously?
Sadly, its not the first time. In my not-so-humble opinion – most companies or organizations have absolutely no clue as to the difference between Quality Assurance and Quality Control. Even though Quality Control has been an out-dated practice for more than twenty years, I still find a “quality control mindset” on each consulting assignment. They may even call it Quality Assurance, but it ain’t. Lets look at the two shall we?
Quality Control(QC) is the traditional way of looking at quality. In a QC environment, quality efforts are usually tacked on at the end of a given process. Something is produced and then given to the QC folks to test and determine if the product meets quality standards. In the event a quality issue is detected (and there usually is), the entire product may need to be scrapped and rebuilt. Or, where it is practical, pieces or parts of the product may need rework. Then the whole production/quality process repeated until quality standards are achieved. If time is critical, its the quality process that gets the ax. Ultimatly, only the QC Team is held responsible for quality. A QC mindset is expensive. Had the problems been found earlier in production or even during the design process it would have been significantly less expensive to fix. Ask Toyota.
Quality Assurance(QA) on the other hand involves having an eye to quality at every level of the organization, throughout every process, by everyone involved in designing, producing and even using the product – be it a computer, or the software that runs it. With QA, quality isn’t saved until the end but rather looked at constantly – by everyone, not just testers. Its having what I like to call the “Quality Mindset”. The goal should be to identify quality issues constantly, throughout the process and adjust as neccessary (Controlling function of management) Finding and resolving issues early ultimately saves money! Sure it may take a bit longer to produce the final product and cost some money, but in the long run I think it saves money. Ultimately is produces goodwill and trust with the customer. Unfortunately, to the bean-counters, trust and goodwill are difficult to measure in terms of dollars and cents (or is that sense?).
If you’re Microsoft and control your market, you can slip up on quality (or customer service) and get away with it. You can make your products difficult to install or completely annoy your customers. Since there is no real competition, customers have no where else to turn. So the company can make you lose all of your installed software when you try to upgrade to a more expensive version of THEIR operating system. (Try upgrading from Windows 7 Home to Windows 7 Professional – you can’t. They force you to do a new installation. Not only do you have to reinstall all of your software, you also have to reinstall all of your drivers) Then they can get away with charging a small fortune to help you resolve the problem when you call customer support. What other option do you have? Why make me pay to use the more expensive version of YOUR product then charge me for assistance? Or for that matter – to use your product at all (see Microsoft Project). Because they can!
It is unlikely your company can get away with it. You need a quality product and you need produce it as inexpensively as possible. You probably have to compete in a competitive marketplace.
I like to get involved in any product development early. I know most of the pit falls and I can catch most of them early – hopefully before the first line of code is ever written. Will things slip by? Absolutely? As much as I like to think I’m perfect, I’m the first to admit that I’m not. I want to see all design documents, specifications, requirements, etc. I may find something really trivial – but its a lot cheaper to fix it now by running a spell checker than it is to fix it in the code, re-install it and re-test it.
Watch for the tell-tale signs. Listen for things like “We’ll catch it in test” or “That’s not important right now” or “Its someone else’s job to fix that – they’ll find it later”. You gotta love job security!
Time for another war story. When I was in the Air Force…..
I worked for a Wing Commander, who’s mantra was “push people”. He felt it was OK that you could make crews work overtime or work weekends etc. Of course we never pushed the aircraft. The machines were always given appropriate down time for maintenance, refueling, reloading, etc. The commander had “stars” in his eyes (in this case general’s stars). It was an accident waiting to happen. Unfortunately it did happen – taking 6 lives including a high-ranking government official. It wasn’t until the accident investigation that his “management style” was revealed and ultimately identified as a major contributing factor – crew fatigue. It took an accident investigation and the lives of 6 people for the “leadership” to see there was a problem. They could have asked me 3 months before the crash.
Sometime later I read an article on productivity. I wish I would have saved it because it has had a huge impact on me ever since. Essentially, the article stated that people can only be pushed so far before productivity begins to suffer. When you push them beyond their full capacity, you will see some short-term gains in productivity, but over the long haul productivity will decline – significantly. So if you have air crews and maintenance crews working 3, 8-hour shifts, you will see some short-term gains when going to 2, 12-hours shifts. At some point, however, things begin to break down. Maintenance gets sloppy, minor (but necessary) procedures will get over looked, and accidents happen. We saw it every time we would go into any long-term or frequent war game, or as we called them – exercise.
We used to practice going to war all the time. There would typically be one or two “exercises” a year. However in the event of a pending major inspection – the exercise schedule would be increased. Colonels become Generals based on these exercise results. So twice a year became once a month. By the time the actual inspection arrived we were exhausted. We made stupid mistakes – mostly minor – but mistakes none the less. We passed – barely. Oh – and we were responsible for handling nuclear weapons.
Back to the article. The author studied and tracked productivity as workers were stretched from full capacity to beyond full capacity. The study found that in the short-term, productivity levels did increase – slightly. Then as time went by productivity dropped dramatically to levels below full capacity. The bottom line – crews were more productive, over the long-term, if allowed to work normally. Well not more productive exactly, but productivity did not decrease. I showed the article to the new commander but he blew me off. Never confuse a military leader with facts!
In addition to the loss in productivity, there were other negative factors. The most obvious (now anyway, we didn’t see it at the time) was that personal quality evaluation (Task Evaluation) scores began to decrease. Periodically, Quality Control inspectors would watch various crew members perform their daily job tasks and complete an evaluation of their performance. When pushed beyond capacity – they made mistakes – which were ultimately reflected in the evaluation results. Maintenance crews would take short cuts, not follow instructions, read an indicator incorrectly, etc. They were tired and exhausted.
There were other indirect signs as well. Domestic violence incidents increased. Alcohol related incidents increased. There were more driving violations. Family members were getting in trouble – the list goes on.
Sadly, we’re seeing this today. Military troops are being pushed way beyond capacity and we’re seeing the results. Minimum tours have been increased from 12 to 15 months. Enlistments have been involuntarily extended. Troops may get to spend a year with their families before being deployed for another 15 months. The result: Drinking and drug use are on the rise. Domestic violence has increased. Divorce rates among troops is up. Worst of all – suicide rates for military members is at an all time high. Is it worth it?
So when you are estimating project length – keep all of this in mind. You can only push people so far. Will it be as drastic as I described…probably not. But there is a downside. You can’t push people. They will break!
Shut up and Test!
Shut up and Test!
Shut up and Test!
Shut up and Test!
Shut up and Test!
My new mantra
Thanks Jimmy Buffett and Mac MacManally!
It’s my job to be different than the rest
And that’s enough reason to go for me
It’s my job to be better than the rest
And that’s a rough break for me
It’s my job to be cleaning up this mess
And that’s enough reason to go for me
It’s my job to be better than the rest
And that makes the day for me
One from the Capn’s Treasure Chest. I’ve just been thinking about this one a lot recently. One of my character traits – or flaws – is that I will usually tell people – sometimes bluntly – what I think. It’s my job. If you are paying me big bucks to look at your stuff – then you deserve some honesty. You may not like the message, but it’s better to hear it from me than your customer. So here goes….one from the archives…
While I’m not a huge fan of American Idol, I’m a big fan of Simon Cowell! Do you think if one of the Idol winners ever gets an award, like a Grammy, they will thank Simon? I doubt it. He’s lucky. He can be open and say what he feels. Sure people are angry at him. But you know what? He’s usually right. It’s just the message delivery that upsets most people. Deep down, they know. Unfortunately, for software testers, that’s not a luxury we have.
I think Simon would be a great software tester. A desirable attribute for any good software tester is to tell people what we think – tactfully (OK this is SO not Simon). Software developers, Project Managers, Product Managers, and anyone else on a software project, spend countless hours designing and developing software applications for customers. They’re proud parents. It’s their baby. Then they show it to us, and essentially ask: ”What do you think?” More often than not we have to tell them they have an ugly baby!
I imagine, if you have an ugly baby, Simon would tell you so!
Nobody wants to tell someone they have an ugly baby, but unfortunately, it’s our job. The key is how you tell them. Sadly, you will always run into a proud parent that will be hurt no matter how you tell them. Different parents will respond differently depending on the way the message is delivered or received.
So how do we handle these delicate situations? Having been a test consultant now for a few years, I’ve had to deal with a number of delicate parents. Here are a few tips on the proper care and feeding of delicate parents:
- Build a Rapport with the Team: Get to know them. Take them to lunch. Buy them bagels or donuts. Let them know that you are there to make them look good. When a virtually flawless application is delivered to a customer, no one says how well tested it was. Development teams will always get the credit. However, if it is delivered with bugs, everyone will wonder who tested it!
- Be Honest and Responsive: One of the best compliments I ever received was: ”If Dave and I grew up together, I’d never let him touch my toys. He breaks everything!” Tell them up front, you’re going to do everything in your power to break their application. It’s what you do! Although a good magician never reveals their secrets, a good tester should. If I have time, I will usually tell them what my attack plan will be.
- Be Open and Available. Want me to take a look at your requirements? – Absolutely! I always let teams know, that if I’m available before formal testing begins, I will give them a free look at their requirements, specifications, code, whatever they have. I won’t create a defect in the bug tracker. I’ll just shoot them a quick email, and make a note to look at it later. It ends up saving everyone time in the long run and, once again, makes them look good when formal testing begins. It also helps me develop and refine my tests.
- Let Them Review Your Tests. If you’re going to look at and critique their stuff, it’s only fair to let them do the same to your stuff.
- Don’t Rely on the Bug Tracker. Never send a public ugly baby notice! The last thing you want to do is rely on the bug tracker to deliver bad news. There is nothing worse, or less productive, than flame wars in the bug tracker.
- Talk to someone! Let them know what you did and why you did it. Show them. Lead them towards a solution. Tell them what your expectations are. It may be a simple misunderstanding of a vague requirement. Count to 10, then write it up.
- Check Your Attitude. This is my personal weakness. You don’t want to come off badly. What’s funny to you, or well meaning, can be completely misconstrued. Be critical, but constructive. You need an air of friendliness and support. If you come off as arrogant or condescending, the ultimate message will be lost.
- Don’t Take it Personally. Tough to do? Absolutely! But you’re just the messenger. Its’ usually not about you. You’re just the closest and easiest target. Grow a thick skin.
- Be Prepared. It’s going to happen. Maybe it hasn’t happened yet, but if you do this long enough, it will. Be ready for it.
- Write an Article. While it may not solve anything, you will feel better afterwards. I know I do!
Unfortunately, while these tips tend to work well with in-house teams, it can be difficult with geographically distributed teams. Since they don’t work with you face-to-face every day, and you can’t take them to lunch or buy them donuts or bagels, there is a tendency for the message to get distorted. As I recently learned (the hard way). Even though you may have good intentions, someone’s feelings may get hurt. Unfortunately, attitudes don’t translate well over the phone or by email. Don’t be afraid to apologize. It’s typically a misunderstanding. It’s more important to heal the relationship and move on than to stand on principle. If you’re right – gloat to yourself.
Bottom line – no matter what you do, you’re going to hurt someone’s feelings. Be prepared for it and don’t be afraid to make adjustments if you need to. It may still be an ugly baby, but it’s never too late to do something about it! Someone has to do it. You don’t want the customer to do it.
If you’re in this business for personal rewards or recognition, you probably need to rethink your career choice. Not that they’re not there. They’re just few and far between. No, a good tester gains satisfaction by knowing, albeit silently, that they were the reason the application was virtually flawless. Sure, no one else may notice, but I know, and that’s good enough for me!