Cyber-University

Proof-of-Concept

Experimental Results

  • Testimation Technology enables Users to predict & measure Cyber-Risk; the foundation of this capability being Test Effort Estimation (TEE).

  • The only universal manner in which to validate Testimation Technology, & evade accusations of false testimony, is via its own creation & publishing the results with full disclosure. Therefore one expects that a tool capable of predicting & measuring Cyber-Risk, to accurately forecast the Test Effort required to validate its own development.

  • The Proof-of-Concept (PoC) document available for download, contains all of the experimental evidence gathered during the development of the product suite; thereby validating Testimation Technology to experimental accuracy greater than 98.07%.
Download
PoC

Cyber-Risk 101-107

  • Cyber-Risk is about much more than just Cyber-Security or Hacking attempts. Cyber-Risk involves all forms of Undiscovered Defects; e.g. Failover, Functionality, Performance, Security, Stress Response etc.

  • To understand Cyber-Risk, we must first measure our Cyber-Confidence; Cyber-Risk follows Cyber-Confidence, it never precedes it; you can't know the likelihood of failure until you first know the likelihood of success.

  • Cyber-Risk denotes the Testing which has NOT been executed. This includes tests for security workarounds which have not yet been discovered by the Hacking Community. In other words, a successful penetration event is simply a test that the victim has not yet executed; probably because the test has not yet been conceived or designed.

  • Cyber-Security is typically reactive; closing the stable door after the horse has bolted. Testimation Technology allows users to measure the value of being proactive rather than reactive.

Cyber-Risk 101

Cyber-Risk 102

  • Where would you expect most of your Cyber-Risk to be; System-Penetration perhaps ?

  • This is an interesting question & the answer may not be what you might expect. You can use Testimation Technology to model & analyse your Business Cyber-Risk to answer this question.

Cyber-Risk 103

  • What is the difference to Cyber-Risk between Testing & Quality Assurance ?

  • Watch this video to learn the answer.

Cyber-Risk 104

  • What is the difference to Cyber-Risk between System Testing (ST) & System/s Integration Testing (SIT) ?

  • Watch this video to learn the answer.
ST = System Testing | SIT = System/s Integration Testing | E2E = End-to-End Testing


PDR = Process Design Requirements
  • Documents defining the proposed or established Business Processes to be tested

IAD’s = Interface Agreement Documents
  • Artifacts defining the required behavioural interaction between systems

Func. Spec. = Functional Specifications
  • Artifacts defining the required functional behaviour of the systems to be tested

A to B
  • Testing for connectivity between systems; typically performed during environmental commissioning or changes etc.

A’ to B’
  • Testing that systems are interacting correctly by triggering a Functional Process in system “N” & verifying the result in system “N+…”

Depth of Testing
  • A generalised reference to the level of technical testing required in each phase
  • ST = most, E2E = least

Cyber-Risk 105

Ever wondered if Functional Defect Discovery (FDD) has a physical analogue ? .... As it turns out, it does. Cyclically discovering & fixing Functional Defects is analogous to Thermal Radiation; the farther you step back from the fire, the fewer Functional Defects you will find in each Testing Cycle. A cyclic approach to Testing is fundamental (e.g. Progressive Testing followed by Regressive Testing), & a primary firewall between an operational business & being in dire straits.

Watch this video to observe the distinct correlation between Cyclic Testing & Thermal Radiation. Connecting these phenomena is an important step in predicting & mitigating Cyber-Risk. It is impossible to predict any form of Cyber-Risk unless it is modeled in some mathematical form. In the absence of a mathematical construct, predictions are nothing more than speculative guesswork.
  • How many Testing Cycles does Cyber-Risk mitigation require ? .... The answer to this question has two key elements; theory & practice.

  • Watch this video to see how we translate a complex Mathematical Model into a simple table demonstrating that, the key to answering the question raised, is entirely dependent upon the commitment to Defect Fix Ratio (DFR) per Cycle by the Development Team.

  • If your Development Team commits to a DFR of at least 74(%) per Cycle, your Software Project will (generally speaking) not need more than two Cycles of Testing (Iterations per Sprint) to mitigate most Functional Cyber-Risk. This means that they must commit to permanently fixing at least 74(%) of Defects raised per Cycle. If this can be achieved, all your Critical, High & Moderate Severity Defects will be fixed by the end of your 2nd Cycle; leaving only the Low Severity Defects remaining. At this point, the business can decide if fixing the outstanding Defects is economically warranted.

  • As is customary with Testimation, we support conclusions via rigorous Mathematical Modelling to ensure that theory concurs with observation & expectation.

Cyber-Risk 106

Cyber-Risk 107

  • What is the difference to Cyber-Risk between Software Development Life-Cycle (SDLC) methodologies ?

  • Watch the video to learn the answer.

Cyber-Risk 201

Alumni