The product is in a pre-release phase. User feedback is fast and furious and the issue list is growing. Bugs need to be fixed now or the clinicians are going to lose confidence. Resources are tight. How to respond rapidly and improve stability?Read more »
The 'rapid concept'. It almost works, but not quite. The management are interested, but it has to be viable and can't take up valuable resources. How does the concept get turned into a product prototype and get aligned with design processes?Read more »
The "classic" design brief: new sub-system required to replace technology that went obsolete yesterday. No time, no budget, no contingency. It also has to fit into the same, restricted volume, be powered by the same supply and communicate in the same way.Read more »
The product has passed through customer prototype evaluation and is already in the process of being transferred to manufacturing. All is going well until a trial customer stumbles across a well-hidden failure mode. A second customer is right behind. The product needs a bug fix - yesterday - and the resources are just not available to pick the task.
The specifications say that the product does X with a precision of Y. There's a document somewhere to prove it. Somebody did a calculation. Did anyone verify or validate the calculation? We re-calculated, simulated and compared to publications for other devices. We discovered that the error was only 10% in this case, but who knew? Errors impact customers.
The pressure to maintain data integrity and security in the Internet of Things is becoming greater and greater. Moore's Law gives us more data, faster. Testing needs to keep up. In an all-software system there are well-defined rules and tools. In a mixed hardware / software system this takes great planning and a serious, strategic, targeted approach to testing.