Archive for the
‘Testing’ Category

 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 […]

Cell phones and Laptops, Tools – or the Distraction to Success Ever think your not getting the most out of your team due to distraction.  The greatest invention perhaps is the smart phone.  Now it is easy to check all of our email accounts, text message our friends, post on Facebook, blurt on Twitter, connect […]

Survival of the fittest is not just a biological concern.  Our business must constantly adapt to external stimuli and find better, quicker ways of performing our work.  One way to accomplish this growth is through actions sometimes referred to as project post mortem, or an after action report.  We have a plethora of tools of […]

My work experience informs me that the loss of slack is a big risk to projects. Without this wiggle room, we reduce our probability of success. Projects scheduled out to the last available date just do not work. The reality is these are not manufacturing or routine tasks and jobs. Even the rather routine tasks […]

Our risk exposure starts at the beginning of the project. Even before the project is actually a project.  The simple act of scoping a project in the initiating phase already alludes to the risks to which we may be exposed. For example, the minute we decide that our project scope is going to include software, […]

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 […]

        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 […]

            We have discussed compliance testing earlier. This is known as testing to requirement. These requirements can be taken directly from a customer specification (when we have one) or derived internally from a requirements review or even both. Compliance testing is the primary method we use to ensure that we are meeting all specifications and […]