My department is called QA but we are definitely Testing and not QA. Since I took over the department, I was considering talking with my boss about changing our name. Somehow people in my company seem to think we "own" quality, even though we really have no control over quality (you can't test quality into a product). I thought that perhaps a change in the name of the department might change others' perceptions of the department.
I spoke with the other tester here about this. She suggested that by changing the department name, we may paint ourselves into a corner where we could never become a QA department. To be quite honest, I have no interest in becoming a QA department. I fail to see how 2 people with no development experience outside of testing and no major education in processes should start telling people who know their work how to do their work. I'm also about as interested in auditing people's work as I am in getting a root canal. I see QA as a specialized field, for which you should have a lot of education and experience behind you.
I'm interested in your thoughts on this. Would you change the department name? How have you changed the company's perception of testing?
Re: Department Name
I am not entirely sure what answer would help you in terms of getting the information you want. I can tell you that I was responsible for the change of the name of our department at where I am now to "TechQA". I did this because of a direction I wanted the group to go in and how I wanted others to view us. So it was a two-pronged strategy on my part.
Even with that, however, we are still more a "strict testing" group than a "strict QA" group. And that is okay with me right now. I am taking one battle at a time. The first battle was to get my own team members to realize they need to be a little more technical. The second battle will be to get more of a "strict QA" mindset than just a "strict testing" mindset in place. Note I put a lot in quotes here. I do that because there are no "actual" definitions of these concepts, at least so far as I am concerned. QA is predicated upon the notion of testing because testing is a broad concept. (I have waxed philosophical on this at numerous places on the forums and will abstain from that here.)
So let me go to the two questions you specifically asked.
Would you change the department name?
Yes. I have done that.
How have you changed the company's perception of testing?
Right now I would say I am more working on changing my own team's view and/or perception of testing before I start in on the company. As to how I have done that, mostly by a series of e-mails and "white papers" that delineate some of the thinking battles that the team has to engage in if they want to call themselves testers. I have also shown them different ways to look at testing (both proactive and reactive) and what it means to be a skeptical questioner of information. I have also been getting them to focus on work products and work deliverables because those, to an extent, define the interface with other teams in the company. I have also been encouraging them to learn how to think critically and make operational distinctions between terms. I have also been training them in how to look at fallacies in terms of how questions are asked and how they are answered. Once I feel the team is ready to "face the world", so to speak, I will then attempt to determine on the viability of the other elements regarding how we infuse more of a "quality mindset" into the company. And note, of course, that I do not presume such a grander vision is likely or even possible. Sometimes you have to win tactical battles before you get strategic victory. (See my article Winning Battles, Losing Wars.)
But note that, above all, I cannot change the company's perception of testing until I make sure that there is a consistent perception of testing within the testing group itself. That is currently the challenge I am dealing with now. Changing the name of the team was not strictly a necessary element of my plan but I think it does help because it allows for a focusing element that I can often refer to when the need arises.
Re: Department Name
My 2 cents
Leningrad - St. Petersburg, Bombay - Mumbai.
IF the people behind the names are or will be able to identify theselves clearly with the change then go ahead with the change. Otherwise its said "Whats in the name?"
Re: Department Name
If it is important to the organization that the name reflects the activities, then it makes sense to make the change. I would recommend a "sales presentation" that does the following:
1) Demonstrates how each function/role owns and/or influences quality.
2) Draws a clear distinction between what you do and QA.
3) Solicits thoughts about QA from your audience so that the audience feels it has input. This input may likely cement your case and enlighten the organization. It may also give people a sense of "QA empowerment" such that they look at their own processes with an attitude of improvement and helping your cause.
Re: Department Name
My question would be: Who IS responsible for the QA process in your company?
My company recently relocated a project team to work on a new project, and I was chosen as the sole QAP. I AM the QA department, even though prior to this placement I was primarily a tester (with a development background). I had to implement our QA policies and procedures, and design test plans, test cases, most of these duties which had previously been handled by the QA manager at the parent office. Even though it is not my cup of tea, I definitely have taken on more responsibility and the initiative to move into more of a quality assurance role instead of quality control. I've worked to educate the team on their role in quality assurance and how we work together as a team to produce a product of high quality. I guess I'm just lucky to have a job in IT right now. So I'm willing to be flexible so that I can be valuable to the company.
The important thing is not to stop questioning.
Re: Department Name
DJardine, I would say test plans and test cases are a function of a testing department, not a QA department (the QA department would simply assure that the testing department creates said documents and followed the process). But then, I guess it all comes back to what Jeff said, "there are no "actual" definitions of these concepts".
So, maybe I should define what I believe QA to be. Quality Assurance oversees the process and ensures all stakeholders adhere to the process. They are not involved in the actual building of software (or whatever it is you are building), they audit the process by which you build it (and I believe building would include testing). Many companies, despite having a department called "QA" do not have a "true" QA department. According to www.softwareqatest.com, "Software QA involves the entire software development PROCESS - monitoring and improving the process, making sure that any agreed-upon standards and procedures are followed, and ensuring that problems are found and dealt with. It is oriented to 'prevention'."
Re: Department Name
JP - good suggestion! Put it on our Task list.
I realized after yours and Jeff's posts, that I'm actually doing things to change the perception. Since I took over, I have started being more diligent about reporting the actual work our department has done (rather than just saying "we've completed testing the product" as my predecessor did). I think this is giving others a better idea of the scope of our department and our work. Also, I do not recommend a build for GM release. I just give the powers that be the info (this is what we tested, you can view the results here, this is what we found, here's the defect tracking report) and let them decide if it's ready for release. And, finally, I've been getting other departments more involved with our work. Testing used to exist in a vacuum - now I'm looking for sign-off on test plans and cases from dev and marketing and sending out a detailed weekly status report of our work on all projects in the queue.
Re: Department Name
I like your model of communication. Do you feel you are getting awareness results?
Some details about the sales presentation I use...
The core of the presentation is centered around the typical project bell-curve - cast as effort along a project timeline. I make a few points about the extraordinary heap of effort piled up at the planned release date. Typically the points involve the why behind the heap of effort - excluding the effort-penalties accrued through ineffective people management, procrastination, finger-pointing, and any other polarizing factors.
Just a few of the why points:
1) Incomplete and ambiguous requirements.
2) Changing requirements and lack of effective management thereof.
3) Changing design work.
4) A mounting defect pile - as discovered by the black box testing community.
5) et al.
At the point I see the enough eyes wide-open that communicate "Oops!", I begin to ask questions. The biggest question:
What can each upstream discipline do to reduce the height of the Mount Everest bell-curve?
The answers come pouring in:
1) Inspections and reviews of designs, code, and other key documentation
2) Controlled change
3) Unit and unit integration testing, etc.
4) Better estimating
5) Risk analyses / functionality ranking and prioritization
6) Usability testing
7) QA process education
One common concern:
If we flatten that bell-curve, then we delay the release date. We can't do that!
Well, this usually leads to an interesting discussion where people begin to realize the difference between real project progress and perceived project progress.
Here is one example used to illustrate the difference:
Perceived progress is based on the fact that development claims that coding is complete. Coding may be complete but typically unit and unit testing are not, thus forcing more effort onto the disciplines downstream and pushing the peak of Everest beyond 29,028 feet.
Real progress is (should be) based on the fact that development can prove coding is complete. The proof is in the form of meeting and gaining sign-off on exit and/or entry criteria from the previous SDLC phase to the next.
And then as timelines typically go the product is released prematurely and defect identification and reporting are pushed onto the end-user. Everyone ready for the maintenance and support costs nightmare? <- That boosts the premise that changes to upstream processes can reduce the effects of that nightmare.
Anyway, I could go on and on!!! To my amazement and satisfaction in knowing that I helped our worldwide collective QA cause one client adopted this presentation and made it a new-IT employee orientation requirement. Changes were made within IT that demonstrated one basic concept: We all own quality.
[ 11-29-2003, 07:16 AM: Message edited by: jpensyl ]
Re: Department Name
Some key points about the presentation I spoke of:
At the beginning - I ask "Who owns software quality?" About 55% indicate "We all do." Answers consist of: "QA (meaning the black box testing unit)", "The head of the IT dept.", "The end-user", "The BAs", and so on.
At the end of the presentation it is between 95 and 100% "We all do."
People see the difference between detection and prevention of defects.
There is little discussion if any, about blackbox testing.
[ 11-29-2003, 08:20 AM: Message edited by: jpensyl ]
Re: Department Name
<font size="2" face="Verdana, Arial, Helvetica">I am glad this seems to have worked for you, however, for the reasons I bring forth in my article Is Quality Everyone's Responsibility?, this is the approach I try to avoid unless a series of "thinking battles" have already been won. And even then I try to avoid trite phrases like "We all own quality" or "Quality is our responsibilty: each and every one of us." That is not to say there is not truth to those statements. It is just that in my experience, without people understanding what an operational definition of "quality" means (and, yes, this is contextual), then saying everyone "owns" it (or a part of it) or saying that it is everyone's "responsibility" eventually just leads into a lot of process cul-de-sacs that are often better avoided. I have also found that it can lead a long-term defocusing of the notion of a "quality effort".
Originally posted by jpensyl:
Changes were made within IT that demonstrated one basic concept: We all own quality.
What a lot of this thread implicitly speaks to is the influence a group has in a company, the perception of the people that are outside the putative "QA Group", the perception of the people inside the putative "QA Group", the general culture that exists in the organization in terms of process adherence, velocity mentality, etc. It also depends on skill-levels of various people and the cognitive abilities of all people that are relevant to the discussion. That latter is one of the more important and it is, in my opinion, where the "thinking battles" need to be waged before people worry too much about "QA Process" or even departmental name changes.
This whole effort to get QA (or even a good test regimen) instituted, in my experience, often depends on the balance between strategy and logistics (tactics) that are employed or that are capable of being employed. That is often where I start in terms of perceptions. I look at the interface between a "test team" and other teams within the company. I look at the work products and work deliverables that have to pass through those various interfaces. I then look at how those work products and work deliverables (the logistics) can potentially be improved while still maintaining a viable overall "test effort" (strategy) or "QA effort" (strategy).
Note, here, that I am speaking to a higher level of perception than just how many bugs get out into the field, how long coding takes as opposed to how long people thought it would take, etc. Those are definitely important and need to be dealt with. But I have found if the firm foundation for thinking operationally about quality is not in place, then the rest eventually falters. "Thinking operationally" in this context means that people are aware of how to make operational distinctions and how to ask operational questions, they are aware of how to do situation assessment, they are aware of how to do decision analysis, they are aware of how to do opportunity analysis, they are aware of how to do potential problem analysis, etc.
So going back to Gail's words: "I thought that perhaps a change in the name of the department might change others' perceptions of the department." It might. But if it does do so, that, to me, is ancillary. What I want is to change their perceptions of what it means to "test" something and what the notion of "quality" means. Further, I want to make sure there is a viable cognitive mapping between the concepts of "testing" and "quality" in the organization because it is only with such a cognitive mapping that the notion of "assessing product quality" even makes sense (particularly when you realize "testing" is a broad term) and it is a good way to show that one single group cannot possibly "own" quality while also showing that quality cannot be "everyone's responsibility" in some simplistic fashion. And, of course, those perceptions can be changed regardless of what the name of the team is. I more use the name change of a team as a focusing element for the team itself rather than those outside it. For the perceptions of those outside the team, I go back to those interfaces that I mentioned before. I do that because then I can operationally show why assessing quality matters to individual groups because I can trace it to spheres of accountability and responsibility.
But I cannot stress enough: the "test team" or the "QA team" or whatever it ends up being called, first needs to have its own perceptions aligned before there is a hope of tackling the perceptions of others. Note, also, that with what I said above, I do not have to sit there and worry about how each and every person defines "Quality Assurance" or "Quality Control" or "Quality Testing" or what they all think the interplay between those concepts is. What I like to do is normalize the perceptions (if I am doing a sales pitch) by defining the notion of quality operationally relative to the company and then tying that into how we can assess that notion of quality and how each group can help to do that in different ways.