Re: Quality Control as part of the process
I'd start with requirements.
Get QA involved in the discussions from the start. (Digits71 has a thread going a little lower down on this page)
Most defects are found to have been caused during the requirements phase of all projects. It might be vague or missing some crucial information that the coder has to extrapolate (guess), maybe they aren't testable.
"Fast" for example can't be tested without a definition of fast supplied by the business. "Half-Fast", now that's another test method and can be done easily.
Jean James, CSTE
J.James Consulting, Inc.
"I deliver what I promise, and I only promise what I can deliver."
I deliver what I promise, and I only promise what I can deliver.
Re: Quality Control as part of the process
<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by QAM1:
We lack experience in this area which is why I am looking to everyone here for advise in building Quality Control as part of the process. Where would you start and why???<HR></BLOCKQUOTE>
As Jean pretty much indicated, you need to have the realization that at each phase of your life cycle you are going to want to have some element of "quality control" or "testing". That means determining what happens in each of those phases and what the deliverable is from each phase.
In other words, think of each phase as a sort of process that occurs and the result of that process is some deliverable - whether that be a document, source code, binaries, etc. So think of what you need to do in order to make certain that the process is taking place and is capable of producing the deliverables. Then think of what you have to do to verify that the deliverables that came out are correct.
Note that when you do this your phrase "...Ensuring Quality is followed before the drop to QA..." is seen to be a misnomer because your phrase makes it seem as if there is some one point where something is "dropped" to QA. The quality effort should permeate all aspects of your development life cycle.
One good place for this is definitely the requirements, again as Jean already noted. (This is not always the best place to start though. More on that later.) One of your main elements in the requirements phase, from a testing perspective, is to make sure that the requirements are written in such a fashion that they are testable. What this means is that if someone later came to you and said: "Can you prove that this requirement has been fulfilled?", you should be able to answer "yes". Why? Because you made sure that the requirement was stated in such a fashion that it will be easy to determine when the requirement, as it was stated, has been met in the product.
Now, beyond that strict perspective, there is also the notion that a requirement should not be vague. We will stick with Jean's example: "fast". Say the requirement says: "The application should perform all calculations very fast." Well, what does "very fast" mean? Is thirty seconds fast? Is ten seconds fast? In order for that requirement to be valid, it needs to be quantified and not so ambiguous. That also means you will be making it more testable. (It all really boils down to the notion of testability. As I mentioned in another thread here, the notion of "QA" is predicated upon the notions of testing.)
The means by which people state the requirements is the process that I mentioned before. The final, written requirements are the deliverable that I mentioned before. You can see that if you take care to make sure the process is valid, often the deliverables will be valid as well. (The reverse is certainly not always the case.) We could carry this same kind of thinking through to any of the other points that you mentioned: design documentation, code reviews, unit testing, build verification, etc. Just think of each of those as being a type of process and each of those producing some sort of deliverable.
Now, would I start at requirements? Ideally, that would be a great place to start. But as you said, you all lack experience. In that case, sometimes that means requirements can be one of the harder places to start depending upon how requirements are currently handled at your organization, assuming they are at all. So the first thing to do, before anything that we have said so far, is to take stock of your development life cycle. Determine what is currently done. You have to know what is there first before you start making changes to it.
Sometimes it can pay to start adding easier "quality control points" much farther down the life cylce chain before you start doing the same things further up the life cycle chain, at places like the requirements stage. Why? Because while you are figuring out the best way to handle the upper tiers of the life cycle, which often can be more problematic, you can at least have some backstops along the way so that you are not left with nothing at all. (Sometimes people new to this concentrate all their effort on the requirements stage and forget, while all that is going on, to worry about the downstream - which gets left relatively untended.)
Anyway, I hope some of this helps. Let us know what is confusing or where you want clarification. You will find that many of us have gone through the same procedure that you are embarking on right now.
Quality Control as part of the process
Currently we are looking to add Quality Control Points through our development life cycle process. Areas such as design docs, Functional/Technical documents, Code Reviews and Unit Testing/Build Verify. Ensuring Quality is followed before the drop to QA.
We lack experience in this area which is why I am looking to everyone here for advise in building Quality Control as part of the process. Where would you start and why???