Tuesday, October 13, 2020

PNSQC 2020 Live Blog: Quality Focused Software Testing In Critical Infrastructure with Zoë Oens




We are all familiar with the "Iron Triangle" where we get three sides; Faster, Cheaper, Better... Pick Two, because that's all you will be able to achieve.  One hundred percent coverage is unachievable. Especially if the goal is to save money in the process. still, what is the answer when you have to test software on a  critical system? when I say critical, and when Zoë says critical, we are talking things like the power systems, water, medical, banking.  Bugs in production are not trivial.



So what do we do when it comes to testing CI (critical infrastructure) software? How close to one hundred percent coverage can be achieved? If a feature fails, what is the fallout? How many are affected? While not specifically software related, some of you may know/remember that I have direct experience with a Critical Infrastructure failure in my community. My town of San Bruno suffered a major gas line explosion in 2009. Maly lives lost and many homes destroyed. It took years to rebuild and in many ways, the scars and memories are still fresh. 

When we are looking at testing in these critical areas, we have to be able to prioritize and determine the mission-critical stuff. Granted, we can't just declare everything as mission-critical but dealing with the electricity grip or gas supply, yes, critical becomes more meaningful. 

Zoë mentioned her time in manufacturing helped her approach the questions and issues where CI comes into play. Make sure that there is a spread of knowledge. CI is an area where there should be no silos. No one person should be the one to know how to fix problems when they occur, both at a coding and an operational level.

An emphasis on test writing, test setup, and test execution needs to be codified and well understood, as well as run frequently and aggressively to be sure that as many cases have been focused on and addressed as possible. Automation falls into this spare especially if the steps are codified and well known. anything repetitive, especially if it is rote repetitive, should be automated. The goal in CI environments is to be able to run testing consistently and effectively. While there is an upfront cost here, this cost can be amortized over time, especially if any of the tests are long-lived.

CI environments can sound scary but the key takeaway to me is to be mindful and diligent, as well as look for repetitive areas that can be codified, confirmed, and repeated.

No comments: