Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!xylogics!merk!epochsys!jeremy From: jeremy@epochsys.UUCP (Jeremy L. Mordkoff) Newsgroups: comp.software-eng Subject: Re: SQA (was: Re: The Software Process - Watts Humphrey.) Keywords: SQA, quality Message-ID: <884@epochsys.UUCP> Date: 1 Nov 90 16:36:51 GMT References: <9150@fy.sei.cmu.edu> <1711@blackbird.afit.af.mil> <144261@sun.Eng.Sun.COM> Reply-To: jeremy@epochsys.UUCP (Jeremy L. Mordkoff) Organization: Epoch Systems, Westborough, MA Lines: 48 In article <976@qusunitg.queensu.CA> dalamb@qucis.queensu.CA (David Lamb) writes: >There's an inherent tension between getting a product out by a deadline >(the bias of developers) and getting out a product with no defects (the >bias of SQA groups). You want a separate SQA groups not so much >because they specialize in SQA as because they aren't the developers, >so don't have the developer's biases and mindset about the product. >There's a right way and a wrong way to introduce an SQA group: > right=SQA and dev report to a single project manager wrong=SQA is a seperate department and the two report to a director or VP of (SW) engineering This 'right' scenario is a good structure for a testing group. It is _not_ appropriate for an SQA group. SQA needs an advocate on the same peer-level as at least the group that must support this project after FCS. This is usually one level above the project manager and sometimes two. This is required because of differences in opinion as to the meaning of quality (bugs vs. usability for instance). An effective SQA effort needs upper-management backing, so it is better to insert it as high as possible in the structure. You must pool the SQA talent, rather than disperse it among the projects. SQA's seemingly unattainable goal is to making testing obsolete. Testing is unique to each project; the goals and skills of SQA are common to all. This model also implies that the groups are of the same size scale. The best I have seen is three to one. The worst I have seen is twenty to one. The 'wrong' model has the advantage of pooling the SQA talent. The model I advocate is a hybrid, and it works well. I report to the director of engineering, but I get my day to day direction from the project leader. In all the ways that matter to testing, our group follows the 'right' model, but it is to the director of engineering that I give the final go-ahead to. Just knowing this, the project manager will always get my opinion first, putting me on par with the developers as a group. This also allows me to work on several projects as once, and that frees me to get involved from day one. I feel that by pushing for better specifications we can build better products, so I take the role of spec critic very seriously. My next goal is to make customer support part of SQA (or vice versa) so that the people who must support the product have more say in when it is released. -- Jeremy L. Morkdoff uunet!epochsys!jeremy Epoch Systems, Inc. {harvard!cfisun,linus!alliant}!palladium!jeremy 8 Technology Drive (508)836-4711 x346 (voice) Westboro, Ma. 01581 (508)836-4884 (fax)