I've never worked with you, so I have no idea whether you'd insist upon a unit test document for copy changes. Or other such inanities. Or refuse to take any new projects until September leaving me with nothing to do. Which makes me very, very nervous.
Huh? I know you well enough to hope that you are talking only about the QA group in your current company, not painting all QA people with a broad brush...
Now they want a unit test form for everything. Including dopey little copy changes where all they have to do is look at the screenshots in the spec (which they have) and verify that the site matches. The notification we're already sending, telling them what files changed, for what spec or SCR is insufficient. Of course, since I've finished the only project I have for this release, and they refuse to let us put anything else in -- they won't take anything else from my queue until September, I've got nothing to do. Which makes me very, very nervous.
Let me illustrate -- imagine how dev would feel had M.G. had your job at our previous employer. It's not quite that bad; the guy in charge is at least fluent in English. FSVO fluent not involving writing coherently, though.
Not sure I'm getting all of the acronyms (FSVO?), but I get your meaning. That is a QA group that does not have a mission that fits in with the rest of the organization. Obviously there is insufficient detail in your post to get a truly accurate picture, but it sounds like they feel they have their hands full with too much to do, so they're putting on the brakes. What they probably really need to do is a risk analysis to make sure they are testing efficiently and effectively. (This is assuming your QA organization is primarily a Testing organization as oppposed to a Process Improvement organization with a separate IV&V organization.)
FSVO == For Some (or Small) Value(s) Of (I generally mean "Some Value", but I've seen the other expansion given, and either usually makes sense. Related acronym: FCVO, For Certain Values Of.
This is a term used by companies that have big "M" methodology, like those that are level 3 CMM or better. In those companies, QA (usually renamed to SQA) is the group tasked with making sure the processes used to develop the product (from idea through to delivery, and across all teams) have a high level of quality and are being followed. Software Testing activities fall into the domain of IV&V.
Think of it in terms of automobile manufacturing. The SQA group is equivalent to their QA groups, which monitor the processes used to build cars. Their Testing groups are usually called Quality Control, and they check the end product for defects.
If ever you work for one of the large governmental contractors, you'll get puzzled looks if you say your code hasn't been QAed yet.
(Besides, QA isn't a verb. The proper verb is "test". :-)
BTDT, hated it. When I first moved here, I worked for GDE SystemsMarconi Integrated Systems BAE Systems. IIRC, they were one of the first companies to achieve CMM 3 -- I've got the mug at home holding pens. They were working on 4 while I was there, and starting a Six Sigma program, too. Never, ever, ever want to work in that kind of environment again.
I don't want to work somewhere people are tweaking live code and there's no control at all, and I think it's great for someone with a better eye for detail and more patience to check out my work before it goes live, but processes and testing should help, not hinder.
You *are* only bitching about your company's QA folks, right? And surely they find worthy, meaningful bugs which need to be reported and documented anyway, right?
Signed, a former and hope-to-be-again QA engineer who is married to one.
Sometimes they do. And sometimes they show a total lack of reading comprehension and insist thing which are working correctly are bugs. Or they cannot grasp the fact that when the copy in the spec is highlighted and has a note referencing a different spec, the wording in the other spec should be considered definitive. Or they try to blame browser dependent behavior (like tab order for forms) on us. (We have a strict "no javascript" rule for this site.) Either they don't have brains or they refuse to use them. And they can't keep up, leaving us seriously undertasked in dev, because they won't take anything we could be doing.
I think QA is the enemy everywhere. In my company, I've been known to injure myself in rage after finding really really obvious bugs in a product, making clear that entire areas of functionality were not tested.
But, I'm in Tech Support. We're quirky and weird and demanding! :)
It's the sign of a bad company if the test group is considered "the enemy." There should be a very cooperative attitude between Test, Project/Product Management, and Development. If there isn't you can be assured that the product will be poorly conceived, poorly implemented, and poorly tested.
When I started with computers in 1955 (I built my own adding machine out of relays), I recall that testing code (such as there was) was comparatively simple. My first actual programming job had patch cords governing the sequence of operations. Debugging was easy; if it ran successfully, it was perfect. LT five minutes to test the "code" thoroughly. The most complex code I worked on in the late '50s was written on an LGP-30, which had 4096 words of storage on a drum, with each address accessible 1/7 of a drum revolution (one add operation's time) later. Debugging was, again, simply a matter of seeing if the program did exactly what you thought it would.
When I went to work for IBM in '68 (I look forward to the day when I have to specify *which* '68 -- *grins*), we wrote *really complex* code. I mean, our operating systems were almost 1 meg core image!(remember core, anyone?) And we had to shoot bugs on systems that had 16 megs of total storage. An impossible task, you say? It seemed so. I remember core dumps that were 6 to 8 inches tall, and in there somewhere was the explanation of why the code failed. I learned to read machine code fairly fluently and to add hexadecimal numbers in my head quickly. I could generally keep a mental image of all 16 general purpose registers' contents over time; it helped.
One of my more recent projects had to present the same appearance on several different versions of IE and Netscape on Macs and PCs. Testing becomes something else when one no longer has access to all of the possible combinations of hardware/software that might run the code.
One of my more embarassing failures as an IT professional was when I tried to build a test plan for a moderately complex system back in the 80's. I learned that it is not a trivial task to do good QC, especially in an environment where QC is seen as a burden, not a blessing.
Good SQA and QC is really difficult to do on large projects. It takes lots of creativity, knowledge, and attention to detail. My hat is off to those who do it well and create a win-win environment of cooperation, not competition.
I hope this post isn't too long. If I need to move it to my journal and put a pointer to it here, let me know. I'm still learning LJ etiquette... :-)
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
That warn't a Nice Thing to Say...
Date: 2003-07-25 11:30 am (UTC)*I* am a QA person.
...and not only that, but also one with a different perspective on
QA than you have! Amazing, but true!
Z
P.S.: And I *KNOW* I'm not the only QA Engineer on your Friends
List.
Re: That warn't a Nice Thing to Say...
Date: 2003-07-25 12:03 pm (UTC)no subject
Date: 2003-07-25 11:30 am (UTC)JOhn.
no subject
Date: 2003-07-25 12:06 pm (UTC)no subject
Date: 2003-07-25 12:30 pm (UTC)no subject
Date: 2003-07-25 12:53 pm (UTC)In other words, sounds like it sucks.
:-)
JOhn.
no subject
Date: 2003-07-25 01:28 pm (UTC)IV&V?
no subject
Date: 2003-07-25 03:56 pm (UTC)This is a term used by companies that have big "M" methodology, like those that are level 3 CMM or better. In those companies, QA (usually renamed to SQA) is the group tasked with making sure the processes used to develop the product (from idea through to delivery, and across all teams) have a high level of quality and are being followed. Software Testing activities fall into the domain of IV&V.
Think of it in terms of automobile manufacturing. The SQA group is equivalent to their QA groups, which monitor the processes used to build cars. Their Testing groups are usually called Quality Control, and they check the end product for defects.
If ever you work for one of the large governmental contractors, you'll get puzzled looks if you say your code hasn't been QAed yet.
(Besides, QA isn't a verb. The proper verb is "test". :-)
JOhn.
no subject
Date: 2003-07-25 04:02 pm (UTC)GDE SystemsMarconi Integrated SystemsBAE Systems. IIRC, they were one of the first companies to achieve CMM 3 -- I've got the mug at home holding pens. They were working on 4 while I was there, and starting a Six Sigma program, too. Never, ever, ever want to work in that kind of environment again.I don't want to work somewhere people are tweaking live code and there's no control at all, and I think it's great for someone with a better eye for detail and more patience to check out my work before it goes live, but processes and testing should help, not hinder.
no subject
Date: 2003-07-25 11:59 am (UTC)Signed, a former and hope-to-be-again QA engineer who is married to one.
no subject
Date: 2003-07-25 12:10 pm (UTC)no subject
Date: 2003-07-25 12:51 pm (UTC)no subject
Date: 2003-07-25 01:33 pm (UTC)But, I'm in Tech Support. We're quirky and weird and demanding! :)
no subject
Date: 2003-07-25 03:58 pm (UTC)JOhn (QA Fascist, but in a nice way ;-).
no subject
Date: 2003-07-25 04:38 pm (UTC)Now I'm scared.
How we change...
Date: 2003-07-26 06:12 pm (UTC)When I went to work for IBM in '68 (I look forward to the day when I have to specify *which* '68 -- *grins*), we wrote *really complex* code. I mean, our operating systems were almost 1 meg core image!(remember core, anyone?) And we had to shoot bugs on systems that had 16 megs of total storage. An impossible task, you say? It seemed so. I remember core dumps that were 6 to 8 inches tall, and in there somewhere was the explanation of why the code failed. I learned to read machine code fairly fluently and to add hexadecimal numbers in my head quickly. I could generally keep a mental image of all 16 general purpose registers' contents over time; it helped.
One of my more recent projects had to present the same appearance on several different versions of IE and Netscape on Macs and PCs. Testing becomes something else when one no longer has access to all of the possible combinations of hardware/software that might run the code.
One of my more embarassing failures as an IT professional was when I tried to build a test plan for a moderately complex system back in the 80's. I learned that it is not a trivial task to do good QC, especially in an environment where QC is seen as a burden, not a blessing.
Good SQA and QC is really difficult to do on large projects. It takes lots of creativity, knowledge, and attention to detail. My hat is off to those who do it well and create a win-win environment of cooperation, not competition.
I hope this post isn't too long. If I need to move it to my journal and put a pointer to it here, let me know. I'm still learning LJ etiquette... :-)