Archive for October, 2014

Testers Do Not Break the Product.

Posted on: October 21st, 2014 by admin 1 Comment

Requirements testing

There is a Twitter discussion going on regarding “Testers do not break the product.”  I am not so sure this is true in all contexts.  Consider for example, embedded products.  Our organization will almost certainly have a multiple perspective approach to the testing of that product.  One of those would be test the product to the requirements. Testing to requirements are one means of learning the product’s ability to meet the expectations put upon it via specifications.  The result of which should be part of the contract closure phase of the project.  Did we get what was specified?  This would be true whether externally (supplier) or internally developed by our organization.  To close the project it is incumbent upon us to identify if the project expected outcome has been met.

Test Cases

However, there is more to know about the product than just does it meet the requirements via passing requirements testing.  Consider the consequences of an “inadvertent” power down during an EEPROM or other memory write cycle.  What happens to the product and how will it respond on a subsequent power up sequence? Our product requirements may not point to such a scenario, but our test engineers may know this can happen.  It could be good for us to understand the consequence on the product performance and customer satisfaction before we launch the product.  The end result of such a test may be the product is now “broken” (fails to perform) even if that was not our intent.  We will learn from this and may choose to add some requirements to mitigate the influence of this mechanism on the product.

Testers, Test Failure and Consequences

Depending upon the risks and costs associated with product failure, we may in fact strive to determine the breaking point of the product.  It can be argued a prudent organizational approach to the testing of that product includes knowing where and how the product can fail.  This is especially valid for products in which a failure may cause catastrophic outcome, such as cars, planes and medical systems.  If your system is of such complexity and failure may result in loss of life or serious property damage, it may behoove the organization to take a more drastic approach to testing.  In such cases we will endeavor to find the breaking point of the product. This will inform us of the margins, the gap between a working product and a failed product, and the specific failure impact.  Where these margins are close, a small increment in stimuli from the requirements creates a failed product, will likewise inform us about the product’s capability.  We can then make rational decisions regarding the product rather than assume all is well.  For example, we may decide that the present design limit is not acceptable and alter some aspect of the product increasing the margin for product failure.

Testers and Design Limits

To further understand the design limits of the product, we may employ HALT (Highly Accelerated Life Testing) on the product.  Using this technique we actively and deliberately find the product weakness (which usually means make the product fail).  HALT is directed at product reliability, or the ability of the product to perform over time and variety of stimuli.  Using this technique the product is pushed beyond that expected during use.  In that way we learn about the product’s potential weaknesses and can make a conscious decision to address (remediate) or neglect (ignore).  Not all failures are created equal and require attention.

Conclusion

I submit that testers do not always break the product. But to say that testers, software or hardware, do not break the product is not entirely accurate.  The answer is; it depends.  It depends upon the company. It depends upon the risk. It depends upon the industry.  Defining break as a failure to perform as expected unless there is technical intervention (reconfigure, reset parameters, download the software again) sometimes testers, even software testers, break the product.

Saving the Business with Assorted Cost Improvement Methods

Posted on: October 18th, 2014 by admin No Comments

Saving the Business with Assorted Cost Improvement Methods

Reducing Process Costs with Lean, Six Sigma, and Value Engineering Techniques

Reducing Process Costs with Lean, Six Sigma, and Value Engineering Techniques

There are boom times and there are times when the business world is less secure and profit margins erode. We see some company responses to economic downturn are to eliminate staff as if that were the only way to become a viable company once again. We wonder if these companies have some cost improvement methodology behind them that would give their management other options than summarily removal of personnel.  A company that has effective cost improvement activities ongoing will be better suited to adapt to the changing economic climate. More like the little creatures that survived the meteor impact that caused the extinction of the dinosaurs – adaptive.

Saving Money Includes Innovation

There is value in an organizations ability to innovate. New product or service generation is important for business growth to be sure. However we want to maximize our return on this investment in development of a product or a new service. To do that we must frequently critique how we are meeting our customer’s needs. What is our value proposition? How can we improve upon the existing proposition?

Example of a few of Methods

Certainly it is not necessary to wait until we have delivered our product or service to start thinking about cost. It is sound business practice to understand the market and whether a particular course of action has economic upside for the undertaking organization. Value Analysis and Value Engineering techniques improve our organizations profit margins by reducing costs.  An abundance of techniques of varying degrees of sophistication are available that will drive out costs, improve efficiency and provide the organization with a competitive advantage.  In our work experience we have saved companies hundreds so thousands and millions of dollars and we can show you how to do this as well.

  1. Brainstorm and Mind mapping
  2. Teardowns
  3. Process improvements
  4. Cost recovery
  5. Optimization
  6. Lean and Six Sigma

Any of these techniques can improve the bottom line of your organization. It is also certain that cost improvement activities go only so far. An organization cannot rely solely upon cost as a competitive feature as a long term strategy for success. However it is also certain that demand and competition influence the asking price for the product or service and that influences potential profit margins. A company that does not actively seek cost improvements leaves much on the table and is not necessarily a good steward of the organizations resources.

Cost Improvement was and still is Important

Cost and value improvement activities for business is as old as business itself. In the days of selling pots, our ancestors crafted the best pot they could with the materials available –which were no doubt limited. Farmers have met their needs through creative means (a butter churn). My father in law regales my family of a story of the farm upon which he was raised. To make butter, they had to manually churn the milk. One day, they elevated the drive axel of the car, placed a belt on the tire and a belt on the churn handle in such a way that the car idle and subsequent tire rotation would churn butter.  It could be argued that the value of the car was greater than that of the purchase price for the vehicle solely for its intended operation. It is difficult to say from the story whether or not there was a suitable substitute. This was in the 1930’s and there may not have been an automatic butter churn available. However, this demonstrates the principle of creative thinking to meet a need.

Our book shows you how to make the most of what you have. Check it out! Call us about volume pricing.

Single Sign On provided by vBSSO