Posts Tagged

Models are not new, and neither models in the employ of product development. Product development has always had some basis in discovery and always will. If everything had such a high degree of certainty, likely the product or endeavor has already been done. Developing new things ceaselessly brings questions. To be effective, we want to answer these questions as quickly and as certainly as possible.

 TIEMPO – Test, Inspection, Evaluation Master Plan Organized by Jon M. Quigley and Kim Robertson PRODUCT DEVELOPMENT TEST, INSPECTION AND EVALUATION Ensuring product quality is not accomplished solely through testing and verification activities. Testing is but a fraction of the techniques that are at an organization’s disposal to improve their development quality.  Good planning of the […]

We would like to revisit our blog post May 2013 and tell the complete story over the course of a few blogs.  I realized the importance of showing the use of the variety of tools after giving an ITMPI webinar based upon our book Total Quality Management for Project Management.  At the end of the […]

We felt the need to follow on from our previous blog on tracking testing results in the background using hidden ubiquitous spreadsheet or documents.  If all you have is a spreadsheet for tracking, then you make that visible to all relevant stakeholders.  If the company has a sanctioned or preferred way of handling “bugs” and […]

We break form our blog run on sprint meetings due to incoming flambé du jour. Sometimes we see organizations that are afraid to use the most fundamental of tools, for example, fault tracking from verification.  Instead of using a tracking and visibility tool, we pass back and forth excel sheets behind the scenes. Why would […]

            We strongly recommend automated testing whenever this approach is feasible. The test team can use a language designed for this kind of testing; for example, the National Instruments product Labview. The software should be able to read in the documented test cases, execute the test cases against the product, and finish by producing a […]

With fifth dimension testing, we use techniques more commonly employed by the “bad guys.” For example, we may execute techniques such as: Fuzzing Response modification using genetic algorithms Input breakdown Overflows Underflows This approach allows for evolution of our test collection. We can automate a significant number of these tests if we have a comprehensive, […]

            Extreme testing occurs when we deliberately “torture” both the hardware and software to see what happens under undesirable conditions. Some examples of extreme testing include: Random voltages within the allowable voltage boundaries Voltage slews Deliberately introduced random noise on the data bus Extremely high bus loading (over 80% and sometimes over 90%) to see […]

        Stochastic testing occurs when we allow a reasonably well-seasoned test engineer to go with their “gut” and feel their way about the product’s performance. During the development of numerous embedded automotive products, we have seen stochastic testing elicit roughly the same amount of test failures as combinatorial testing. We are not recommending that stochastic testing […]

            We know that a very simple product or system can generate a vast number of potential test cases. With more complex systems, this number becomes astronomical. This is the result of a factorial calculation! One technique we use to get around this problem originates with designed experiments. Many designed experiments are based on orthogonal […]