Dette indlæg [1:4] er en del af en ny serie af GPowers softwareudvikler, Jesper Kjær Sørensen, om at bygge solide software- og testsystemer.
Kender du det...?
Kender du det? Telefonen rykker dig ud af din ellers tiltrængte nattesøvn. Du kigger søvndrukkent på den. Din kollega er midt i at køre en ny testlinie i Sydney ind, og du har telefonvagten. ”Houston, we have a software problem!”, lyder det fra den anden side af planeten, og I går i gang med at undersøge, hvad der går galt.
10 timer senere, efter voldsomme mængder kaffe, finder I fejlen. Testsystemet ved ikke, at testemnet lukker forbindelsen ned. Der er et tjek for, om der er forbindelse, men når tjekket fejler, så lukker testsystemet. Løsningen er hurtigt klaret, og vi ændrer testsystemet til at genetablere forbindelsen. Hvis det så fejler, fejlmeldes enheden i stedet for at lukke teststationen ned.
Manglende fejlhåndtering kan blive en dyr affære
Eksemplet ovenfor er ikke en fed situation at stå i. Indkøring stopper, fordi man skal fejlfinde. Det koster tid og penge at nå frem til en løsning. Dette kunne have været undgået ved at prioritere fejlhåndtering. Manglende fejlhåndtering kan være en stor omkostningskilde, som kunder ofte glemmer at prioritere. Man vælger i stedet den simple løsning: Alle fejl lukker testsystemet, uagtet om dette er nødvendigt eller ej.
Manglende fejlhåndtering er en af grundende til, at man hører sætninger som, ”Denne tester er lidt lunefuld, så den virker bedst, når Mads er på arbejde” eller ”Jeg ved ikke lige, hvorfor det her sker. Spørg lige Mads, når han kommer i morgen”. Det er, fordi Tekniker-Mads er fejlhåndteringen grundet hans viden og erfaring. Det er ikke en holdbar løsning på lang sigt, slet ikke hvis Tekniker-Mads forlader forretningen. Så hvordan gør man sin drift mindre sårbar?
5 nemme trin til at reducere afhængigheden af "Tekniker-Mads"
- Identificér, kategorisér og prioritér fejl både i testsystemet og produkt(er)
- Vurdér, om kritiske fejl kan reduceres til ikke-kritiske
- Afhjælp alle ikke-kritiske fejl, hvor de opstår
- Luk testsystemet ned ved de kritiske fejl
- Gør fejlmeddelelser handlingsorienterede, så fejlsøgning bliver hurtigere
Ved at afhjælpe fejlen frem for at lukke testsystemet ned, sparer man tid både i testen, men også overordnet set på testsystemet. Den tid det tager at nå til det samme punkt i testen, vil være sparet med det samme. I de værste tilfælde såsom f.eks. termiske testsystemer kan der være tale om opstarts- og nedlukningstider fra adskillige minutter til timer.
Hvis du vil beholde din nattesøvn og spare penge, er det bare med at komme i gang med fejlhåndtering.
– LabVIEW Champion, Jesper Kjær Sørensen, GPower
