What would be the first things that you would do if you had to build a QA department???
Todd Walker
that basically had no formal software development process in place?
This company does not even have version control of their applications.
They are just building and adding on a continuous basis. They do have
one tester but he is only testing module by module. Nothing
Integrated. They do not even have specifications floating around.
What would be some of the first things that you would do?
What would your salary quote be if someone wanted you to start a QA
department at this company?
Martin Fensome
- What time frame are they looking at - asap, or 6 months to become more
process oriented
- Do you get to hire the testers or do you have to make do with whoever gets
put over to you from other departments?
- If you get to hire, find out your salary groups that you can hire for -
better yet, present them with a scale of pay for the skill levels you need
- Whom do you report to? - vp of company, gm of company, development
manager?
- What kind of development processes can you change, implement, rewrite?
- Version control for Source code and components is essential, obviously -
it scares me that they seem not to know about this.
- How many developers are working on how many projects?
- What kind of release timeframe is there for small updates, major products,
etc..
- Is there a long term business plan - or will this company drop dead in the
middle of your department building effort?
- What is your experience level with this - advanced tester, experienced
test manager, ex-developer?
w/o knowing the answers to above, I'm guessing even more than I like to, so
I'll say a range between 65K and 115K per year.
Some of the items above could possibly add some "bonuses" into your
contract - ie, if they want this department built and ramped up in 1 month -
probably you want 10K bonus on hitting that milestone (with some clear
parameters to shoot for so that it's good faith all around as to whether you
made it or not).
It sounds like it could be a nightmare or a good opportunity to "create"
something cool.
Anyway, good luck.
Martin Fensome
Manager, Software Quality Assurance Department
TOP PRODUCER SystemsŽ
"Todd Walker" <twal...@aol.com> wrote in message
news:c0fbb02b.02031...@posting.google.com...
Peter Harrison
> What would you do if you had to build a QA department at a company
> that basically had no formal software development process in place?
Quality is something that goes on throughout the development process. They
can't just hire a 'QA' guy to make their quality problems go away. So in
short they need to put processes in place.
> This company does not even have version control of their applications.
> They are just building and adding on a continuous basis. They do have
> one tester but he is only testing module by module. Nothing
> Integrated. They do not even have specifications floating around.
> What would be some of the first things that you would do?
Okay, here is a plan:
1. Authority.
If you are only considered only the 'testing guy' you are doomed, because
for quality to increase you will need the participation of all developers
and project managers. You need to have equal authority in the development
process as project managers.
2. Education.
Have a meeting and discuss with the team why QA is important, and how it
must be intergrated into the development process. Explain to them the
options they might like to use:
- Unit Testing
- Code Reviews
- Pair Programming
- Source Code Control
- Refactoring
- User Stories / Acceptance Tests
3. Implement.
Once you have an agreement that the developers can improve the process get
all the developers to buy into the process. I suggest you read about
Extreme Programming to get some ideas, but you don't need to swallow the
whole XP religion.
> What would your salary quote be if someone wanted you to start a QA
> department at this company?
Can't help there. Equal to a project manager or senior developer. Not equal
to a 'tester'.
PS : in companies I have been involved with 'testers' are lowly creatures
paid about half the sum of developers. Quality consultants are probably
paid twice that of developers. They are different roles.
lschwartz
(1) Is there executive management support (VP level) for a bona fide
Quality department, or is this just an expansion of a testing group?
(testing is a part of QA but is not the whole enchilada)
(2) Will you be politically protected by a "champion" of the concept of
software quality (who holds an executive level position), or will you have
to "go it alone"?
==================
Leonard
RobertoM
Step 3: Documentation Control system.
**********************************************
Roberto Minicucci
Software Quality Assurance Engineer
Cisco Photonics Italy
**********************************************
"Todd Walker" <twal...@aol.com> wrote in message
news:c0fbb02b.02031...@posting.google.com...
David B Lightstone
> that basically had no formal software development process in place?
Find out why they failed to consider establishing a QA department
previously. If there is no problem there is no need for QA.
If there is a problem, well there will be immediate expectations
for progress in the - make the problem go away task
I will assume that there is a problem, and that it must go away.
That having been said, the issue is one of drawing a plan
what transforms the known and understoud problem into
marching orders for purposes of implementing the artifacts
needed for successful establishment of a QA organizations
The principle obstacle is in establishing an environment
in which the relation between QA and the successful
development of the companies products is known and
understoud by the developers and the management.
With the developers you will have a turf fight. This
in the sense that there will be additional requirements/constraints
upon what and how they do things. As much as everyone
wants the artifacts of QA, the impact upon people must
first be accessed and resolved. This may mean additional
people and/or task partioning. Such decisions must be
evaluated before putting in the artifacts of a QA organization.
More importantly there must be agreement and acceptance of
those impacts
With the managers your have the traditional bean counting issues
and more importantly a series of risk and uncertainty issues
Of these I consider the risk and uncertainty to be more important.
Managers have a tendency either to (1) throw money at problems in an
effort to make them go away; or (2) ignore problems completely
as though they were figments of someones imagination. Either
of these phenomena is a recipe for failure. Until there is an
active participation of the management or at least certainty
that the two tendencies are absent only superficial progress
can be made
The issue is constructing a path between the problem and the
QA scope to be implemented in such a way that the risks and
uncertainties are understoud but the participants.
First step is an assessment
First goal is to eliminate the uncertainty and risk imposed
by the known problems
If that means Configuration management - good
If that means Bug tracking - good
If that means formal requirement documents - good
If that means formal project risk management - good.
One size does not fit all
Jon Orris
> What would you do if you had to build a QA department at a company
> that basically had no formal software development process in place?
>
> This company does not even have version control of their applications.
> They are just building and adding on a continuous basis. They do have
> one tester but he is only testing module by module. Nothing
> Integrated. They do not even have specifications floating around.
From what you describe, I'd seriously question whether a standard QA
department would be capable of functioning at that company.
With no specs, what do you write test plans against? No version
control? That's a recipe for disaster. You don't specifically mention
project management, but from your description, it sounds nonexistent.
How are you going to coordinate planning with engineering and release?
How will you know what state features are in, when they're due to be
complete, what are the priorities, etc.
I've seen something like this before, and it was _really_ hard for QA
to be effective. That situation was not as bad as what you describe.
What they need, IMO, is to get a lot of other software engineering
fundamentals straightened out before trying to build a full fledged QA
group. It sounds like they need a competent head of engineering more
than hiring testers right now. That being said...
> What would be some of the first things that you would do?
I'd try to reset expectations and goals. They really need to improve
their engineering fundamentals first. This all assumes, of course,
that the company is willing to listen.
If their thought is, "Quality stinks. Testing is supposed to improve
quality. Lets start a QA department and hire testers!" you need to
convince them that this isn't practical. With their utter lack of
process, it would be a waste of time for everyone involved, and they'd
probably end up sacking the QA staff in 6-12 months since they didn't
accomplish anything. This isn't to say you shouldn't be testing, just
that hiring a bunch of test professionals right now probably won't
help much.
If this is what they insist on anyhow, I wouldn't take the job if at
all possible. I don't think you'd be very happy or effective at it.
Get them to focus on a few goals:
1) Get a version control system. NOW.
2) Start writing and validating specs. Put them under version control
too.
3) Engage in real project management.
4) Defect tracking
5) Begin to integrate some test planning and structured testing.
Most importantly, make sure you have upper management commitment to
all of this. You'll need a budget and the authority to hire people and
purchase tools. You'll need the authority to institute changes in
process and make people stick to them. Finally, you'll need protection
when everyone starts howling for your head on a platter ;) Seriously,
you'll probably make people frightened and angry, no matter how
diplomatic you try to be, and you need your superiors to support you.
After people see the improved process as working and adding value,
then I'd look at building up the QA staff. You'll have a much better
base to work from.
Good luck.
Jon Orris
jono...@ieee.org
boris beizer
news:6f92bcc2.02032...@posting.google.com...
> twal...@aol.com (Todd Walker) wrote in message
news:<c0fbb02b.02031...@posting.google.com>...
> > What would you do if you had to build a QA department at a company
> > that basically had no formal software development process in place?
> >
> > This company does not even have version control of their applications.
> > They are just building and adding on a continuous basis. They do have
> > one tester but he is only testing module by module. Nothing
> > Integrated. They do not even have specifications floating around.
The year is 2002. You are describing an environment that's rooted in the
practices of the 50's or, to be generous, the late 60's -- that's 40 years
out of date. Any software development organization that somehow manages to
function with such practices is more than an even money bet to fail --
eventually. Unless you were the CEO, you have little chance of success --
and even then, the odds would be that you'd have to fire half the staff --
including some of the seemingly most productive and creative people there.
The first thing I would do is figure out why that organization has suddenly
found religion and decided that it needs a QA function. The usual reason in
such circumstances is that they don't really want one, but customer
pressure, law, political correctness, and/or other external factors are
forcing them to have such a function -- at least in name. I've seen this
over and over again. They hire a competent, well-intentioned person with
some knowledge and then thwart her every move -- what they want is a title
on the door and a figure-head sitting behind a desk. The ideal candidate is
a 60 year old woman with severe disabilities, member of a major
minority-ethnic group, with a Ph.D. -- that way, they can get all their
political correctness brownie points in one shot.
Assuming that none of the above are operative (it is unlikely, I've
yet to see it, but I will grant the theoretical possibility) and that they
really want to change, I would get the ground rules in writing, from the
CEO -- and that should be cosigned by the chairman of the board if it is a
different person. No one lower. Read Deming to see why anything less is
doomed. The ground rules have to be absolutely clear and unambiguous. You
are being asked to make radical, revolutionary, changes in an organization
and that isn't going to get done with nicey-nicey.
Assuming that you are given the power to do what needs to be done --
the next step is to test the limits of that power to see if it is real.
Assuming it is real -- hire an outside consultant -- not me -- I don't do
that any more. Not because the outside consultant is better or more
knowledgeable than you, but because they can take the heat and the blame.
If you do the dirty work, your tenure will be short-lived and it will be
your successor who reaps the rewards. By hiring an outside consultant to do
the dirty work, .. you get the picture.
Forget QA -- that's secondary. First you need a process. I
don't mean formal documents because some of the best processes I have seen
were not documented. That can work in a small organization (e.g., fewer
than 50 programmers) but not in a large one. Pick a new project and start
imposing the process on that one project and no other.
Simultaneously. Get some good accounting in so that you can
actually determine and document what the software development is costing.
This is a revolutionary step. Don't listen to the accountants or the
lawyers who may throw up all kinds of flack about amortization versus
expensing and various arcane IRS rulings -- it is BS and smokescreen. Find
out the real cost of each project. Work hours, outside expenses, customer
service, hot-line costs, etc. In an organization such as you describe,
often no one knows what things actually cost because cost is distributed
under a hundred different rugs. That's the first and most important metric
to get in place -- real total, end-to-end, life-cycle cost -- including
derivative costs (e.g., customer service calls).
Once you have done one project successfully, you should be able to
show that the pilot project cost less to accomplish under the process you
established. That could take a long time -- a year or more. Assuming
that you do have a success (and haven't had to fire every one assigned to
the project three times over) you have an internal bench mark to which to
point. It may help to bring in an outsider to run the project and to staff
it at least with 65% totally new hires who are not polluted by the existing
environment.
With one successful project behind you, break the group up and
distribute them to new projects. Try to continue with the domination of the
new thinkers. For example, staff a new project with 30% from project #1,
40% new hires, 30% old hands. Now you have three pilot projects from which
to draw people.
It is only when the most of the organization and most projects are
under process control (version control, specifications, documentation,
honest time keeping and accounting, proper documentation, etc.) that you can
start to concern yourself with real QA issues -- which are, after all, only
process optimization issues -- if you have no process, there is nothing to
optimize and therefore, no purpose to QA.
If the above is too intimidating, too negative, too pessimistic, and
too long in duration, then you should turn your talents to sharpening your
resume.
"Till the whole were newly modeled, they cannot expect any notable success
in any of their endeavors."
Oliver Cromwell to Parliament. Read Oliver Cromwell's biography to see
what it is all about.
Boris Beizer
--
-------------------------------------
Boris Beizer Ph.D. Seminars and Consulting
1232 Glenbrook Road on Software Testing and
Huntingdon Valley, PA 19006 Quality Assurance
TEL: 215-572-5580
FAX: 215-886-0144
Email direct: bbe...@sprintmail.com
Email (Forwarded): bbe...@acm.org, bbe...@ieee.org
------------------------------------------
John McClenny
twal...@aol.com says...
> What would you do if you had to build a QA department at a company
> that basically had no formal software development process in place?
quit
sheri.lyn
> quit
I second that
sher...@xtra.co.nz
http://queen_of_testing.tripod.com/front.html
" A woman's mind is cleaner than a man's. She changes it
more often."
Jeremy Mordkoff
doozy....
A wise man once said, if you don't know where you're going, any road will
do.
Start at the highest level. What are the product requirements, or what are
the company's goals? How will the company know they've achieved them? Forget
the code, the specs, the lack of version control.
Another said, If you don't know where you are, no map will help you.
Step 2 would be a thorough analysis of the current state of affairs. You
seem to be aware of many problems.
Step 3 would be a plan to get from point A to point B.
JLM
--
Jeremy Mordkoff
Registrar & webmaster, New England Over-the-Hill Soccer League
http://www.othsl.org
DMTS, Access Point SQA, http://www.Lucent.com
Human, Husband, Dog-lover, http://go.to/mordkoff
Peace, Love, Truth, Beauty, Soccer
"Todd Walker" <twal...@aol.com> wrote in message
news:c0fbb02b.02031...@posting.google.com...
Jeremy Mordkoff
therefor seemingly banal?
Anyways, it was serious. Lack of specs and code control and stuff are real
problems. But most companies in this state also don't have written
requirements or even well understood goals. What happened to the originator?
JLM
--
Jeremy Mordkoff
Registrar & webmaster, New England Over-the-Hill Soccer League
http://www.othsl.org
DMTS, Access Point SQA, http://www.Lucent.com
Human, Husband, Dog-lover, http://go.to/mordkoff
Peace, Love, Truth, Beauty, Soccer
"Jeremy Mordkoff" <ot...@othsl.org> wrote in message
news:u9t1tnh...@corp.supernews.com...
Robert Klemme
Jeremy Mordkoff schrieb:
>
> I am surprised this did not generate any responses. was it too terse and
> therefor seemingly banal?
maybe it was too abstract, i.e. not concrete enough. otherwise i
could not find anything wrong with your approach.
> Anyways, it was serious. Lack of specs and code control and stuff are real
> problems. But most companies in this state also don't have written
> requirements or even well understood goals. What happened to the originator?
got lost? :-)
regards
robert
--
Robert Klemme
software engineer
--------------------------------------------------------------------------------
myview technologies GmbH & Co. KG
Lindberghring 1 ~ 33142 Büren ~ Germany
Fon: +49-2955-7433-20 Fax: +49-2955-7433-99
--------------------------------------------------------------------------------
The information transmitted is only intended for the person or
entity to which
it is adressed. It may contain confidential and/or privileged
material. Any
review, forwarding, distribution or any other action related to
this information
by persons or entities other than the intended addressee is
prohibited. If you
receive this by mistake, please contact the addresser and delete
the material
from any computer.
J.M. Ivler
> What would you do if you had to build a QA department at a company
> that basically had no formal software development process in place?
1) who wants it?
2) what's more important, meeting a commitment or quality?
Sure, anyone can implement software tools to do CM and defect
administration, but without an executive champion, there is nothing to
stop them from using tools to release crap. Without a commitment to
quality (defect free software), there will always be a reason to release
crap to the field.
> What would be some of the first things that you would do?
Get the most sr managment to commit in writing that the head of this
department can stop a product release over quality.
> What would your salary quote be if someone wanted you to start a QA
> department at this company?
$150K/yr to start and operate the department. A contractual agreement that
if a decision to override my decision not to release software due to
defects is made, a $2MM bonus will be paid if such software is released to
a paying customer.
If they want me, and they are serious about quality software, they will
agree to the bonus. If they don't agree to the bonus, then they aren't
serious about having quality software developed there.