We see well-meaning people adopt an attitude “if it needs done, then I will do it” even if their job or position in the company does not define them as the person to solve the problem. I call this absorption and it is part of the much ballyhooed “can-do attitude” upon which many companies thrive. […]
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 […]
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 […]
To perform embedded software testing, we recommend five phases of testing. These phases may take place concurrently and are as follows: Compliance testing Combinatorial testing Stochastic (or exploratory) testing Extreme testing Attack mode Each of these methods provides some view of the product the other method does not. Of course, testing the product is not […]
We have briefly discussed why verification is important to the product quality. Verification does not just address the product quality. Our project work requires verification as well. When we take on a project, we should have the scope articulated in a way that we can confirm that the project did indeed fulfill the objective. As […]
Requirements management and configuration management are required for anything that even closely resembles effective testing. Experience suggests failing in these two areas unnecessarily complicates the product verification activities, and we will show some of those traumas in the next few posts. An iterative and incremental product development process calls for reviews throughout the development process. […]