Just Enough Testing

Det är spännande att lyssna till Hans Schaefer, en av nordens tongivande specialister på test av programvara. I trettio år har han studerat, undervisat och förmedlat kunskap om metodik kring testning av komplexa systemkonstruktioner. Tillsammans med flera andra specialister talade han på IT Quality Nordic Institutes årliga höstkonferens om testning av programvara.

Tillräckligt bra
Hur hittar man den punkt där testarbetet inte dominerar och blir en börda? Hur ser man till att nya programdelar inte stör befintlig kod? Hur kan man på ett bra sätt prioritera sitt testarbete?
Folke Nilsson, verksamhetsledare på ITQ, menade att vi nu nått en tid där det inte går att testa allt. Vi måste använda oss av riskbaserad testning och olika former av automatiserad testning i kombination med utforskande testning.

Öppen källkod
I Linuxvärlden talas det ofta om just risker med den öppna modellen men som Hans Schaefer sa det finns risker med alla former av programvara:
‑ Det finns inte tillräckligt med tid. Det går inte att testa allt. Använd metodik för att bedöma risker. Som alla säkert vet går allt att bryta sönder. Det är bara en fråga om resurser. ”You make it – I’ll break it”. Men det finns strategier som kan hjälpa till. Målet är att bekämpa riskerna och glöm inte, fel är sociala till sin natur, de tenderar att klumpa ihop sig!

Leta risker
Leta efter de värsta felen som skulle kunna inträffa. Värdera dem som ”hög” risk, ”låg” risk och ”ingen risk”. Tänk på riskfaktorer, vem berörs av felet? Påverkar den annan kod eller andra system? Kostar den pengar? Kan den rentav orsaka skada för människor? Värdera olika fel och risker mot varandra, Hans Schaefer sa att han ofta använde ett enkelt kalkylark för att snabbt kunna vikta olika fel och risker.

Standardiserat
Kanske du inte behöver använda DO-178B (Software Considerations in Airborne Systems and Equipment Certification) som skapats av RTCA Inc i USA men det kan vara ett sätt att hjälpa till och skapa förståelse för hur man bedömer risker i säkerhetskritiska system för flygindustrin. Lars Wahlberg, verksam på ADDQ, som också talade på konferensen berättade om hur man måste bygga in teststrategier tidigt i sina projekt. Hans var en av de som efter JAS 39 olyckan i Stockholm 1993 fick arbeta med att utreda och förstå vad som hände och bygga testmetoder för flygindustrin.

Vårt ansvar
Den öppna källkoden, allt det du ändrar eller bygger som ny funktionalitet måste testas. Det är du som har ansvaret, på samma gång en skrämmande men också positiv uppgift. Du vet vad du får. Det är du som projektledare, systemerare eller programmerare ska se till att du testar rätt men att du inte testar i onödan.

En annan risk
Professor Ken Sakamura, en ikon bland användare av realtidsoperativsystem, fader bakom TRON-projektet och drivande idag på samma sätt som för 25 år sedan. Ungefär 60 procent av alla dagens inbyggda realtidssystem baseras på TRON. Ken Sakamuras vision är att vi alla, vi nu sju miljarder människor, ska ha hundra processorkärnor var och han får rätt! Men den visionen han gav för 25 år sedan följs nu upp av en önskan om nya trådlösa system där vi kan få global täckning, obegränsad bandbredd och nätverk som överlever och fungerar i katastrofsituationer som exempelvis den jordbävning och tsunami som drabbade Japan den 11 mars i år. Men för att detta ska ske krävs nya tankesätt. Kommunikationsprotokoll som arbetar omnidirektionellt snarare än punkt till punkt. Ubiquitous networking, ubiquitous objects, ubiquitous computing är termer vi ska lägga på minnet säger en leende Sakamura-sensei.

Filed under: Jan Zettergren, Linuxspalten