Testing Patterns

bullet1 The product is

  • safety or life critical
  • a consumer product
  • a product for expert users
  • a product for data-processing
  • an embedded system
  • ....

The software under test may be life critical or a simple consumer product, it may have been developed for some expert users or for a mass market, it may be highly interactive or does data processing in the guts of a company, it may be a stand-alone product or an embedded system. The best approach to test a software product depends mainly on the type of the software under test, I don't think – that’s my very personal opinion and experience – that there is a one-size-fits-all way to test software. And not all of approaches to test software are compatible ...

For example safety or life critical software (e.g. an air traffic control system or software controlling medical equipment) has to be tested much more thoroughly and more documentation is needed compared with an application for a fast-moving market. For products with sophisticated and highly interactive GUIs, usability and ergonomics are important topics on the agenda, and use cases and scenarios are important testing tools. On the other hand data processing software (i.e. software that does some calculations and transformations on input data) is often located in the back office of banks and assurances; it’s tested by comparing validated sets of input and output data and is very suitable for test automation. If you test embedded systems, development and testers have to adapt to the methods and processes of those folks who build the hardware that contains the software – for example if you make embedded software for automotive, you had to conform to the automotive engineering practices.

And these are only some examples.