IT Employment

Ask something
Discussion Locked

Setting the Software Quality Department

0 helpful
7 replies

by vithal prabhu

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.
I need to create a software quality department for our company. I would like to know, what should be the strategies to be set for SQA department ? What are the roles and responsibilities of the staff in the dept. What is the scope of the department and how to control all the activities.

7 replies

by single - hiveminds.info

...SEI books on CMM or any of the IEEE/ISO guidelines? They might not tell you exactly who does what but will give you a good idea on what is required to have a good SQA department. I assume you have a lot of SQA experience since you have been giventhe task?

by vinod_modha

Vithal,

I just saw your posting and wondered how you are getting on with the SQA department.

I have a number of suggestions which I'll be happy to pass on to you if necessary.

by pakman

Your SQA department will need to be involved in the entire life cycle of the development projects. The manager of SQA should be at the same level as the development manager in the org chart, and have the authority to raise red flags when a problem arises. You will want QA personnel involved during analysis and requirements writing, because they should be the ones to lead the development of test plans and scripts. Once development has completed white box testing, QA will be involved with black box testing, integration, systems, etc. The key concept, Verification and Validation. Are we building the software right, and did we build the right software.

by gmkenney

You need to produce quality software. There's a world of difference between those positions.

1. It starts with your development methodology: what processes drive development? Today's agile processes, for example, cover issues of testing and quality - whatever you do should be integrated with your processes.

2. What is your development philosophy regarding quality? Do you want quality designed and built into the product or tacked on after development. The former yields better qualityat lower costs, BUT management and development engineers have a difficult time understanding and accepting the concept. The latter represents the traditional approach to quality assurance: test and fix after the fact. It's costlier but almost everyone understands it.

On the other hand, if all you really need is a QA department, determine your budget and hire accordingly. Who knows? It might even introduce some quality measures.

by crittermn

To add my 2cents. Keep good records of defects starting with requirements. Build a defect prevention program. Determine where and why errors are happening and fix them where they start. You will end up with fewer defects to test out and a shortertest period because you don't need to test recycles. Keep records to show mangement that you are fielding sooner and have fewer trouble calls (and happier customers).

For your formal testing for management--start with the test report that management will get. A fleshy outline. Get management to agree that the report will have the information thay need for their fielding decision. Then test to prove/dis-prove those points. No one has the resources to test for the sake of testing--be efficient.

Quality assurance is the process of helping to design, build and deliver a good product. Testing is a measuring tool to (partially--never completely) estimate the risk of releasing a product at a given point in time.

by bear090938

The Armed Forces Joint Logistics Commanders put together a project called Practical Software Measurement because there was too much unvalidated theory on Software Quality Control.
They worked in conjunction with SEI, IEEE and many in industry and academia and produced some useful things to measure. You start with people
who know what to measure and why. Then you sell
that to the rest of your company. Then you can get a budget. Then they must produce working product at an affordable price. Your risk is to
over test or under test with respect to time to market place. A few mistakes are acceptable, if quickly fixed. If the perception is that the product doesn't work, you are out of time and a job. Therefore your second hire is someone who can perceive the difference. Third is a budget type. Last is a born salesman, because if you can't sell the programmers and analysts, your dept. won't work for long. There is no requirement for these people to like each other. You must keep them from going postal and working as a team. If you can't, hire a chaplin, because you don't have a prayer.
Chuck

This discussion is closed to new replies.