Kunnen reliability-tests helpen om de kwaliteit van de software in een röntgensysteem te verbeteren? Voor die vraag stond Bryan Bakker van Sioux. Met een beperkt budget bouwde zijn team een quick-and-dirty oplossing door de apparaten via de hardware-interfaces te instrumenteren. Ondertussen heeft de methode zichzelf bewezen en is zij breed uitgerold bij de klant.
Bij een van onze klanten liet de betrouwbaarheid van de medische röntgensystemen die ze daar ontwikkelen en produceren te wensen over. Weliswaar waren er geen problemen met de veiligheid – kwaliteit en met name safety hebben een zeer hoge prioriteit in de organisatie – maar het systeem wilde bijvoorbeeld niet altijd volledig opstarten. En dat terwijl dit meerdere keren per dag moet gebeuren. Het apparaat is bedoeld om chirurgen met realtime beelden bij te staan tijdens een ingreep. Het heeft een mobiel karakter en verhuist steeds van de ene operatiekamer naar de andere. Door het systeem een keer opnieuw aan te zetten als het in de opstart bleef hangen, werkte het uiteindelijke wel, maar dit is natuurlijk niet de bedoeling.
Tijdens de opstartfase van een nieuw project om enkele grote wijzigingen aan te brengen aan het product (nieuwe features, nieuwe hardware) kwam daarom ook de reliability van de software op de featurelijst terecht. Hiervoor werden verschillende verbeteringen aangedragen, zoals het uitvoeren van failure-mode effect analyses (FMEA‘s), betere afspraken met leveranciers en de introductie van software-reliabilitytests als aanvulling op de bestaande kwaliteitstests.
Bij het inrichten van reliabilitytests voor de software is het belangrijk om te weten wat de primaire functies van het systeem zijn. Zaken als het opstartgedrag en het uitvoeren van beeldacquisities zijn onmisbaar voor het functioneren, terwijl een fout bij het bewaren van plaatjes op een extern medium wel vervelend is, maar het systeem niet onbruikbaar maakt. Om de reliability te verhogen, moet je de fouten in dit soort primaire functies opsporen door ze met duurtests keer op keer te herhalen.
Idealiter definiëren we de primaire functies met behulp van operationele profielen, een kwantitatieve karakterisering van hoe de software zal worden gebruikt. Deze informatie komt bijvoorbeeld uit oudere vergelijkbare producten in het veld. Voor dit project hebben we deze functionaliteit echter geschat met de kennis van enkele betrokkenen.
Scripttaal
Het was bij de aanvang van het project lang niet voor iedereen duidelijk dat een automatische testaanpak zou helpen om de reliability te verbeteren. We beschikten daarom over beperkte middelen en moesten snel resultaten laten zien om het nut te bewijzen. Tijd om eens lang over de eisen en eventuele toekomstige uitbreidingen van het testraamwerk na te denken, was er niet. We kozen dus voor een incrementele ontwikkeling van ons testraamwerk: eerst zo eenvoudig mogelijk, daarna stapsgewijs verbeteren.
Een voor de hand liggende manier van automatiseren is via software-interfaces. Via de software kunnen we acties triggeren en de uitvoering verifiëren. De softwareontwikkelaars hadden echter niet de tijd om deze interfaces te implementeren; het project stond al onder tijdsdruk en juist de software-engineers hadden veel features te bouwen. Daarom kozen we ervoor om het systeem via hardware-interfaces te instrumenteren door de elektrische signalen na te bootsen die normaal gesproken via de toetsenborden en hand- en voetschakelaars worden gegenereerd.
Een hardware-engineer heeft dit in korte tijd gerealiseerd, waarbij hij de eerste set testcases in Labview heeft gemaakt. Aangezien het om duurtests ging, was de inhoud redelijk eenvoudig: systeemopstart, enkele acties, een paar acquisities. Toch konden we hier het hele systeem mee belasten, inclusief de generatie van röntgenstraling. Deze eenvoudige tests hebben we gedurende de nacht vervolgens continu herhaald. De volgende dag konden we de logfiles analyseren die het systeem had geproduceerd. Hierin waren bijvoorbeeld een softwarecrash en mislukte of afgebroken acquisities terug te vinden. In eerste instantie kostte dit napluiswerk nog heel wat tijd, maar met wat simpele scripttooling konden we al een flinke tijdswinst boeken.
Met deze simpele aanpak hebben we reeds de eerste reliability-failures kunnen achterhalen. De logfiles bleken hiervoor over het algemeen voldoende informatie te bevatten voor de software-engineers om de oorzaak te vinden. De oplossingen waren ook te verifiëren met de duurtests.
Omdat Labview voor softwaretesters zeker niet de makkelijkste omgeving is, hebben we in de tweede increment een interface geïmplementeerd om Labview aan te roepen met de Ruby-scripttaal. Dit maakte het veel eenvoudiger om de testcases te implementeren en te onderhouden: de cases bestonden nu niet meer uit Labview-code en -diagrammen maar uit een script dat door meer testengineers te volgen en te gebruiken was.
In de derde increment hebben we de mogelijkheid toegevoegd om de logfile direct te inspecteren tijdens de uitvoering van de duurtests, in plaats van de semiautomatische controle achteraf. Hiermee werden fouten zoals het afbreken van een acquisitie meteen gedetecteerd. Het werd nu mogelijk de bekende pass/fail-criteria van de testcases te implementeren.
Daarnaast konden we hiermee de toestand van het systeem bewaken. Bij veelvuldige röntgengeneratie wordt het systeem warm en om schade te voorkomen, weigert het verdere straling op te wekken. Deze tijd konden we nu gaan benutten door andere tests uit te voeren, zoals het opstarten: deze tests kosten relatief veel tijd, maar belasten het systeem nauwelijks en geven het de kans om weer af te koelen.
Niet blij
Toen de eerste reliability-issues boven water kwamen en de softwareontwikkelaars hier tijd in gingen investeren, werd al snel duidelijk dat dit impact zou hebben op de duur van het project. Om dit met de juiste achtergrond uit te leggen, hebben we presentaties georganiseerd voor de systeemgroep en voor de projectleiders en het voltallige managementteam. Hier legden we de aanpak van de automatische reliabilitytests uit en lieten we de resultaten tot dan toe zien.
Uiteraard waren de projectleiders en het managementteam niet blij met het extra werk, maar het was precies waar ze om hadden gevraagd: inzicht in de betrouwbaarheid van het systeem (met name de software) en een mogelijke verbetering. Dat hierdoor andere projectdoelstellingen niet zouden worden gehaald (de deadline) was van minder belang. De kwaliteit en betrouwbaarheid hadden topprioriteit.
Bovendien viel de berekening voor de return on investment (ROI) van de reliabilitytests erg gunstig uit. Hiervoor bepaalde een ervaren systeemengineer welke van de tot dan toe gevonden issues er door de latere testfases zouden glippen en een software-update voor de klanten noodzakelijk zouden maken. Dat zou voor zeven van de meer dan honderd issues het geval zijn. Het management heeft vervolgens aangegeven wat een gemiddelde software-update zou kosten die uitgerold zou moeten worden naar ziekenhuizen. Als we deze afzetten tegen de kosten van het testen, inclusief de implementatietijd van het raamwerk en de tests en de aanschaf van de hardware, elektronica en licenties, dan zou de ROI al zijn bereikt met slechts één failure die niet het veld in zou gaan.
Het was duidelijk dat we op de juiste weg waren, en er werd meer tijd en budget vrijgemaakt. Niet alleen om meer testcases te implementeren, maar ook om het raamwerk uit te breiden en meerdere testopstellingen te maken, zodat we meerdere systemen tegelijkertijd konden testen. Deze ROI-berekening is uiteraard slechts een benadering, maar een doeltreffend middel om voor het management inzichtelijk te maken dat reliabilitytests veel geld kunnen besparen.
In medische omgevingen moeten processen volgens de regelgeving duidelijk gedefinieerd zijn en aantoonbaar worden nageleefd. Ook bij de testactiviteiten is dit van groot belang. Bewijslast wordt verkregen door alle testresultaten nauwkeurig te beschrijven en te herleiden naar de bijbehorende requirements (traceability). Gebruikte tooling bij het testen moet vooraf een validatie ondergaan, die op een gedegen manier aantoont dat het gereedschap het verwachte gedrag vertoont.
Wij hebben echter een andere weg gekozen. Het product ondergaat nog een zeer uitgebreide systeemtest aan het eind van het ontwikkeltraject, waar documentatie van testresultaten zeer veel aandacht krijgt. Deze voldeed al aan alle eisen wat betreft safety en regulerende instanties en we hebben die test dan ook ongewijzigd gelaten. Falen van reliabilitytestgereedschappen zou dus geen gevolgen hebben, wat de validatie van deze tools vele malen eenvoudiger maakte. Het testraamwerk is technisch ook geschikt om bijvoorbeeld regressie- of functionele tests uit te voeren. Maar om dat te kunnen bewerkstelligen, zal eerst een uitgebreide toolvalidatie moeten worden uitgevoerd.
Avonduren
Naast de forse besparing die uit de ROI-berekening naar voren kwam, waren er meer positieve resultaten te melden. Zo verliep de systeemtestfase vele malen soepeler omdat we geen reliability-issues meer aantroffen. De kwaliteit van de software aan het begin van de systeemtest was al vele malen hoger dan in voorgaande projecten. Het aantal systeemtestcycli werd daardoor drastisch lager. Vergelijkbare projecten in deze organisatie hadden gemiddeld vijftien rondes nodig voordat het systeem uiteindelijk kon worden vrijgegeven; in deze case bleef de inhoud van de systeemtest gelijk, maar daalde het aantal cycli naar vijf.
De aanpak via de hardware-interface bleek achteraf ook een goede keuze. Doordat we hardware-interfaces gebruikten, hadden we ook weinig last van het zogeheten probe effect: het onbedoeld veranderen van het systeem door de manier waarop wordt gemeten. Dit is een veel voorkomend probleem als de testautomatisering wordt gerealiseerd via software-interfaces of bij het testen in gesimuleerde omgevingen. Alle geïdentificeerde reliabilityproblemen in de röntgenapparatuur zaten echter daadwerkelijk in het product, geen enkel issue was te wijten aan de manier van testen.
Daarnaast wist de methode ook enkele problemen met de hardware op te sporen, ondanks dat het doel het vinden van reliability-issues in de software was. Doordat de systemen nu veel vaker (in de avonduren en in de weekenden) totaal werden gebruikt, kwamen ook enkele hardware-issues bovendrijven.
Verder bleek de aanpak makkelijk over te zetten naar legacy röntgensystemen. Deze zijn vergelijkbaar met de nieuwe apparaten, maar beschikken over minder features en gebruiken een andere techniek. Ze worden nog wel steeds onderhouden met nieuwe softwarereleases. Doordat we het systeem onder test via hardware-interfaces aanspreken, was de omzetting naar deze producten zeer eenvoudig: de software zelf verschilt sterk, maar de hardware-interfaces zijn al jaren niet gewijzigd. Daardoor was het mogelijk vrijwel dezelfde testcases te gebruiken.
Door het succes van deze geautomatiseerde reliabilitytests worden tegenwoordig steeds meer projecten bij de organisatie onderworpen aan deze aanpak, met een grote kwaliteitsverbetering tot gevolg.