Quality Assurance
I spent a lifetime doing Software Quality Assurance one summer. My appreciation for what they do has remained.
~ Aristotle Sabouni
Created: 2003-01-06 |
Quality Assurance
QA people, in general, are the testers who make sure things work and work well, before you ship the product to customers. If your product doesn't work well, customers will make a lot of noise, harm your reputation, demand their money back, sue you, and otherwise make bad things happen. Even the best case, if your customers are dead, nice or stupid, you're still going to have to fix the problems after your product has shipped; which costs far more than if you fixed the problems earlier. So QA is the good guys, saving you money and your reputation.
I was a young programmer; I'd started in my early teens. And I'd done some consulting for a few large organizations including aerospace, government, and education; but I wanted experience in the commercial sector and to have a "real" job, not just consult. I was told the way to do this was "to start at the bottom" and work up, and somehow this was equated to working in Quality Assurance for Pertec (also known as MITS of the Altair fame). This was the very early 80's. They were building a "super-micro" computer that was a very powerful multi-user 68000 System that ran UNIX, PIC and their own proprietary Operating System. That sounded both interesting and fun; OK, I'm truly a geek and always have been.
Log[edit | edit source]
Monday, my first day on the job, was the intro to the hardware, having lots of documentation dumped in my cube, shown the facilities, and told what I was to be doing; testing the operating system (mostly their own proprietary one) to find bugs in it and various programs. A little open-ended, but it sounded interesting. I was shown how to fill out a bug report on paper, which I could then submit in triplicate, and when the new builds came out on the following Tuesday we were supposed to retest any bugs that were fixed, and then if we had time, go back and retest old bugs as well (full regression testing). Sounded easy enough.
Tuesday I started testing against the new version of the software and quickly documented 50 bugs that hadn't been entered in the system yet, and about 1/2 of them were real showstoppers - crash and burn, system halting and flaming out kinda stuff. Hey, they were making this easy for me, I submitted them all with great pride in my diligence.
Wednesday I was told, "Whoa, slow down there Mr. Enthusiasm. You don't want to be labeled a nitpicker and demoralize the programmers with too many bugs". This was an interesting concept to me since I thought to pick nits and finding bugs was my job. But I was told to slow down. Fine, I found another 50 bugs, but saved them for the following weeks build, and wouldn't submit them too fast.
That meant I had 3-4 days to twiddle and wait for the next build. What to do?
- Well, the OS didn't have a utility to do live chat (and file transfers) from one terminal/user to the next; so I wrote one. QA and others were spread out over the building, so it was quite handy and took me the rest of the week, and was a huge hit with the QA staff.
- The next week, I got a new build. Supposedly 10 of the 50 bugs had been addressed, but they didn't really tell us what had been fixed exactly, or what to test. When I retested, 5 still existed, 3 still failed but in slightly different ways, and 2 were actually fixed, and 40 had been untouched. So I resubmitted the bugs that weren't fixed, logged the few fixed, wrote up a dozen more... and was now bored by tuesday.
- So I wrote my own macro/scripting and testing system to capture keystrokes and scripts and play them back, so I could automate testing. This was the early 80s before everyone had these tools. I created the scripts that would test for all my bugs and was done. Now I could verify bugs in about 1/4 the time of normal. That meant about 1/2 way through Monday, I'd done the weeks work, and was bored. And as I could find add bugs faster than they could fix them, I could only do that about 2-4 hours per week.
- I started testing their security, and it was glorious -- I wrote up about 100 bugs (how to get root access, how to delete other people's files, or alter them, and so on), but I would only add 10 a week or I would piss people off too mcuh.
- I got another talking to: I'd already submitted more bugs than anyone else by week three, and nobody in business/schools was going to try to break into systems or read each others files? Why was I wasting time on that.
- By my second month, I'd settled in that this job paid me to work one or two days a week to keep retesting things that the programmers themselves admitted they hadn't fixed yet, and to keep from submitting problems that might need to be addressed to avoid hurting feelings. But I got to read, research, do homework, and so on.
- I read all about IBM's SNA protocols and laughed that they were still using EBCDIC, and created my own network analyzers and snoopers. I wrote network games for their systems like checkers, backgammon, star-trek, and Yahtzee. I created all sorts of tools for QA, but I had to be quiet and not let management find out or I'd get lectured again. I was having an OK time, but I didn't like stupid authority, and it was just a matter of time before I let them know what I thought.
- Finally, after about 6 months, I started fixing the bugs that I'd reported. I didn't change the source code in their repository -- but after I did it locally and validated it, I added addendum's to my bug reports so they said, "on line 5 of file "xxx", change this to that, and the bug will be fixed". I submitted about 200 of those at once.
I managed to offend a dozen people on that day, as I'd just showed up a team of engineers. It didn't matter if I was right, it mattered that I'd pissed off a few programmers, who had complained to management.
I was not hired as a programmer, what was I doing fixing their programs? I didn't even have a degree! So obviously, I wasn't qualified to code. Who was I to fix more of my bugs than they had over 6 months?
I'd violated the processes and duties of my job. And they'd found out that there were all sorts of utilities and programs written that people were using, that hadn't been written by the software department! How dare I!
I was told clearly that either I could shape up, and never write another program or touch their OS again, and stop submitting so many bugs, or I could leave.
I left.
Today[edit | edit source]
Now, in today's world, management is far savvier, and most QA people aren't punished nearly as much for automating processes or doing their jobs well. So that's sort of a caricature of today's QA. But there are still elements of that around. Management or other teams think Q.A. is calling the baby ugly, just because the product needs improvement, and those that do their job best are often labeled as nit-pickers, loud-mouths or trouble makers. At least outside the QA or support departments.
Q.A. people are supposed to find and report bugs. But a few Prima Donna programmers or managers get offended that QA people are saving the company money by finding the bugs before they get to customers and tarnish the reputation of the company. How DARE they! And so sometimes there is an adversarial relationship between programmers and software QA when really the QA people are just saving the software people's bacon if only the programmers had the humility to understand that.
There's an attitude by some immature programmers that think of QA people as "people that couldn't cut it as real coders". Certainly a few are like that, but many just chose a different career path. Some were often good programmers that just burned out of the B.S. on that side of the fence, and so choose to create or improve products on the quality side of things. Some just haven't made the transition yet. So these stereotypes are unfair and ignore the difficult job that QA people have to do. Most programmers I've known couldn't cut it as a QA person. QA can be a tedious job, with little appreciation.
This attitude about shit on Q.A. people doesn't just end with just programmers. Management doesn't usually understand what they do, or how much they are saving the company; so they often have this attitude that Q.A. is an annoyance that whines about quality all the time, and slows down releases. I've heard people say, "If it wasn't for them, we could have shipped already". Um, excuse me? You could have, but what would have shipped? There's this constant pressure on Q.A. to just sign off and say "good enough" - and then blame them when they do because customers are underwhelmed with the quality and lots of bugs got through.
QA workloads in most organizations are far higher nowadays; but they still have elements of binge and purge. Times when they have found way more bugs than anyone can address so they have to back off and do other things; and times right after a build and before a release, when they need to work 25 hour days in order to test everything that needs to be tested, for release, tomorrow. Ready or not.
Conclusion[edit | edit source]
Sometimes I treat QA people like they are half demented postal workers, who hate their jobs, hate their bosses, and hate their lives because the job can do that to them. The idea is that they are often under-appreciated, under-valued, and just one step away from bringing a UZI to work and improving the quality of the product tenfold.
- "Thank you for finding that bug Mr. QA person, it will make a better product."
- "You like me, don't you?"
- "If you were thinking of eliminating the management and software team, you'd tell me to call in sick that day, wouldn't you?"
I do that not only out of genuine fear but with reverence and respect that they deserve. The specialized tedium and torture that their job entails are beyond me, and my tolerance level for pain. They don't deserve to be ridiculed for that but worshipped. They truly are underappreciated for saving companies money and reputations, for preventing engineers from looking like bigger idiots than they sometimes are, and for helping us all to have better products. So I say to them, "thanks" for doing a thankless job.
🔗 More
| |
| |
Tags: Tech General Tech PCC
