3. Moving from the Typical model to the TQA model
Prev   Site Home   Next

3. Moving from the Typical model to the TQA model

TQA means getting control of the quality of your product from the very beginning. Quite often I've heard the phrase. "It's a startup, once we get our initial product running well start doing XYZ" (pick the point that got skipped.) The problem is that it's a startup organization that needs it the most. Cost management for them is the difference quite often between success and failure. Yet when you move to large corporations quite often they are afraid to move into a TQA environment for fear of disruption of the status quo. Engineers, QC/QA personnel etc will for large corporations be hesitant to move away from "business as usual" for fear that it will make the all to familiar product "Death March" at the end of the cycle even worse than it already is. However proper planning before recommendation of the new process. Then a well laid out plan on how and where all members of the teams responsibilities lie will aid in beginning the change to TQA.

The following flow chart is an example of how the management of a project reflects TQA. (Figure 2)

Figure 2. TQA cycle flow chart showing a smoother production process.

TQA cycle flow chart showing a smoother production process.

In figure 2 you begin to see how the process has smoothed out. It should also be noticed, that QC/QA is involved from the very beginning. Over the course of the next few paragraphs it will be explained how QC/QA is to be involved in each of these steps and the value/cost savings it can impart on the entire production cycle. Deployment of QC/QA in this manor can also push your product toward the holy grail of product development. Releases with no know bugs.

The next point most often noticed is the drop in the number of loops in this model. The loops that are here are designed in loops necessary for completion of the various phases. In the case of the final loop (Which in the original diagram was where a large amount of slowdown occurred.), you will find that this loop is only used when an actual bug that requires re-coding occurs. The original group that created the product is no longer in this loop and this loop has become free to do something other than babysit the product.

3.1. Phases of TQA

There are 5 distinct sections of the TQA method of QC/QA. These sections have very specific points of purpose that they are to create. Failing to create the necessary documents and procedures will most likely through your project into the well know death march loop of old.

3.1.1. Idea Phase

This "section" has, or rather requires the input of 3 standard business groups.

  • Marketing/Sales - They have the pulse of the customer and should best know it's needs.

  • Engineering - They are the ones who determine if it can even be done, in what general time frame and what is needed but possibly not available to them to complete the project. This is not just coding it needs to include the concepts of Project management and UI as well as pure code writing.

  • QC/QA - Their job is to design in not only the method of testing of all sub components of the product, but also if they are involved from the beginning they will know and be able to be input into the time line sufficient time for proper testing.

3.1.1.1. Idea Phase Documents

This phase needs to produce the following documents.

  1. Overview - A summary of what the product is, what it is expected to do, and what problems it is expected to solve. This document will serve as a cover or preamble to the following document.

  2. Marketing Spec. - This document combined with the above is not just for PR use. This document creates a clear and when needed specific set of requirements and expectations. If all parties have bought off on this document then later, when delivery date is near there is no chance of anyone adding a feature at the last moment. ("I thought it would have this so that is what I sold the customer!" syndrome.) This document is key because it provides Engineering the ability to establish a firm time line for production.

  3. Story Board (general overview). - Just like when creating a movie or an animation product a visual of expected interaction between user and product needs to be created. It is much easier to code to the UI than it is to make a UI fit the code. (Coding first, then designing UI is a lot like putting your boots on then your socks. All the steps are there but a lot of effort and time will be wasted.)

3.1.2. Design Phase

This section is where all of the details of how the product will be designed. UI questions, Code methodology, Language selection and team assembly (overall and component) are decided. This section as well has some very specific documents to produce.

  1. Engineering Overview. - This document covers the goals, objectives, vision of deliverables, and general timetable of the project this is done in light of the information obtained from the Marketing Overview. In short this is an extension of the Marketing Overview.

  2. Engineering Spec. - This is the single most important document. It will contain

    1. Coding methodology.

    2. Variable naming conventions.

    3. Language choices for each part of the product.

    4. Class Library choices (if and where applicable)

    5. Full product definition (what is it going to do?)

    6. Full definition and listing of all tests that each section needs to pass.

    7. Copy of the UI Story board and layout (where are the buttons etc.)

    8. Time line in detail what gets built when, and when does it have to be completed.

    9. Who works on what section. List all responsibilities and get each member of each team to sign off on it.

    10. File size limitations (Most critical in embedded applications but it can apply anywhere.)

    11. External forces and interactions that affect the program. (if it's an e-mail client it needs to be able to talk with any smtp server or POP3 or IMAP server. Hardware requirements like Risc, x86, sparc, etc.)

    12. A copy of the documents created in the first stage

    13. QA time table.

    14. Full list of all needed environments, tools (and their versions) as well as physical equipment with a list of who is going to be delivering what, when and where.

    15. Communication methodology, file server space access procedure, CVS (or other version control) design with a list of who will set up what, for whom and when.

    16. List of any e-mail groups that need to be created.

    17. Full communication protocol. Everyone on the teams e-mail address, IM nickname, Phone numbers (cell and home) desk extension (Office PBX) etc.

    18. Procedure for handling unforeseen changes or problems that may (and will) come up. This is to provide a way for an individual at any step of the way to alert management about problems without fear.

    19. Integration documentation. Any time you have two "modules" of a product (Client and Server) there has to be a plan on how they will integrate and communicate with each other.

    20. QC/QA testing objectives. QC/QA needs to state up front what they will be testing for. Not necessarily how they will test for a certain aspect, but what the aspect they will be testing for is.

3.1.3. Coding Phase

For a number of projects and companies this is the phase they want to immediately jump into. Which is the cause of most nightmares. It takes years to get from idea to factory. Along the way similar steps to the above have to be taken. For the software industry the coding phase is the factory. As in a real factory you cannot afford to be designing the product while it is on the production line. The deliverables of this phase are.

  1. The Code

  2. All tests as they ran them. (How do they know the code works C. If they aren't testing things themselves.) This can be either in written form or a test "script"

  3. Status reports at the designated (via the Eng. Spec) time and in the designated manor.

3.1.4. Build Phase

This phase's major responsibility is integration of the code delivered in the code phase either in the first run or in the case of a bug in subsequent runs to QC/QA.

  1. Entries into the bug tracking system documenting all problems with completing the build.

  2. Reporting to QC/QA with the results of the build process and availability of the build for testing

3.1.5. Final QC/QA Phase

This phase is called the "Final QC/QA phase" as previous phases all had a QC/QA component. This phase differs in the the primary focus is QC/QA and the discovery of all remaining bugs with the product as a whole (Documentation, Code, Binaries, etc.). This phase produces the following documents.

  1. Entries into Bug tracking system.

  2. Reports on Bug status. (How many, Level, etc.)

  3. Reports on compatibility of delivered product with UI design, Marketing Spec and Engineering Spec.

  4. Detailed report on Usability impression.

  5. Time table reports on progress toward final release.

  6. Co-ordinates with PM as to the viability of a release candidate being elevated to final.

  7. After Release QC/QA delivers a report on the process of development and problems/solutions for further fine tuning the process.

  8. Responsible for overseeing the movement of the product, bugs on that product, and any additional files and data both to an archive, and to a "maintenance" status to ease working with customer problems and solutions

  9. QC/QA test procedures - detailed version Here QC/QA is responsible for creating the detailed tests and checklist (Pass Fail etc) and passing the results on in a report to the PM

Prev   Up   Next
2. Typical Production Cycle  Home  4. QA/QC the Production Cycle Overlord