Systems Theoretical Testing Analysis

With STPA, I have been able to analyze:

•Risks in the organization

•Critical integration tests

•Unit tests that prove quality, security, and safety

Traditional risk analysis is based on experience and gut feeling. STPA is a new risk analysis method where risks found will be clearly documented and understandable. STPA has helped me build trust in testing.

There’s a philosophical aspect to this.

The verb testing comes from latin testa, noun for the pot of clay in which tradesmen used to test the value of gold used in their transactions by melting it over fire. Testing was a necessary step as the purity of the gold of stamped coins could not be trusted.

Complex software is pure design. The value of it as experienced by our users and stakeholders is emergent. In that way software is like gold: It might have some claimed quality. But no simple inspection of the code can prove or even evaluate that. We need to test it.

However, the complexity of modern systems means testability often sucks as the costs and complexity of setting up test environments explodes. For years, I’ve been looking for a technique to reduce the scope of testing to make development cycles faster. STPA is what I’ve found.

Testability is the degree to which an artefact supports being tested. Validating through so called “end-to-end testing” of complete systems is often very expensive. In the sprint, developing a component, it’s sometimes impossible.

But waiting until after the sprint is too late. Only testing in production is a bad idea, and a bug found late is expensive to fix, and impossible to learn and improve from.

In the talk, I’ll introduce STPA and live-analyze a new system to demonstrate its power.