Resultatdatalagring – även kallat det ”svarta hålet”

”Nu fungerar inte testet längre!”, känns dessa ord bekanta?

Plötsligt har testet som tidigare fungerat alldeles utmärkt i produktion börjat få en massa FAIL och du vet inte riktigt varför. Du svarar enligt testingenjörens praxis 1A: ” Har du provat att testa om?”. Operatören svarar enligt operatörpraxis 1A: ”Ja, och jag har dessutom startat om datorn.”.

Fungerar inte omtest och omstart, då måste det vara något ”riktigt” fel. Med lite tur finns det möjligen en testrapport tillgänglig, där du kan scrolla igenom alla mätningar som gjorts i produktionen för att se om du kan trimma till kraven en aning. I en textrapport eller HTLM rapport kan man dessutom trycka ”CTRL+F” och söka på ”FAIL”. Mycket effektivt, om inte varje enskilt testobjekt har sin egen rapportfil, då blir det genast lite jobbigare, men skam den som ger sig! 

Efter ett tag kan du konstatera att en kravgräns verkar vara någon feljusterad, så du sänker denna en aning. Du säger nu till operatören enligt testingenjörspraxis 1B: ”Jag har justerat gränserna lite, prova igen.” 

Eftersom du antagligen enbart justerade den ena gränsen i ett kravintervall, så för varje gång detta sker, blir kraven allt mer tillåtande tills i princip alla testobjekt går igenom.

Produktionen rullar på ett tag, men efter ett tag kontaktar utvecklingsavdelningen dig och undrar om det går att få lite testdata från produktionen, då de fått många returnerade enheter från kunder. Då enheten kalibreras i produktionen är de intresserade av att se hur en viss mätning har ändrat sig över tid och mellan olika batcher. 

Du svarar: ”Hmm, det går, men det tar lite tid att sammanställa, då testresultatet ligger i olika textfiler på varje testdator. Dessutom hade vi en hårddiskkrasch på en av stationerna i förra veckan, så hälften av testdata är nog borta tyvärr.”

För att undvika att detta sker igen, ska vi självklart skapa en egenutvecklad databaslösning! Några tabeller och lite SQL så är allt klart. Du känner dig riktigt nöjd och nu sparas all data ner från produktionen i en gemensam databas.

Det går några månader innan utvecklingsavdelningen kommer på besök igen och behöver lite testdata från produktion, då ryktet spridit sig om databasen. ” Kan vi få lite testdata i Excel?”. Du svarar: ”Inga problem. Excel kan hämta data från databaser.”

Du startar Excel och efter en liten stund har du googlat fram hur man ställer en SQL fråga i Excel. För att göra databasen lite mer effektiv har du enligt databaspraxis 1A normaliserat din relationsdatabas. Du trycker på ”Execute” och det händer absolut ingenting. ”Working...”. Efter ett par minuter är Excel klar och du får ett blad med en massa siffror istället för data. Efter ytterligare två dagar har du nu klurat ut hur du ska kombinera ”SELECT” med en ”INNER JOIN” och lite ”WHERE” och äntligen har ställt frågan! Du har ett svar och du kan maila utvecklingsavdelningen dina nya fynd. Du får som svar att problemet redan är löst och de gjorde några egna mätningar istället.

Ett par år senare får du ett jobberbjudande som du inte kan motstå, tack och hej då. En ny testingenjör anställs och du visar hur alla system fungerar och alla trick och finesser som man behöver för att får igenom enheterna i testet. Du nämner i all hast att all data sparas i en databas.

I samma ögonblick du slutar förvandlas databasen till det ”svarta hålet” med testdata. Ingen annan än du lyckades någonsin få ut testdata ur den.

Den nya testingenjören vill såklart visa framfötterna på jobbet och börjar kolla över testerna. Efter ett par veckor är testkoden analyserad och det visade sig att en väsentlig del av testtiden gick åt att exportera data till databasen. Enligt operatörerna har det varit så här länge nu, det blir allt trögare för varje månad allt eftersom de gigantiska svarta hålet växer allt djupare och slukar mer och mer testresurser och testtid.

Känns ovanstående scenario igen?

Varför byggs det så många egenutvecklade resultathanteringssystem? Om det nu finns något resultathanteringssystem överhuvudtaget?

Ett alternativ till detta är QRM – Quality Result Management från AddQ. Det består av tre delar:

• Databas – En färdigutvecklad resultatdatabas baserade på åratal av erfarenhet från produktion inom olika branscher
• Lagringssystem – asynkron web service som på ett robust och säkert sätt skickar och lagrar data i en databas
• Webbapplikation – presentera dina resultat direkt i en webbläsare. Ta fram testrapporter, produktionsöversikt och SPC analyser

Om QRM funnits i scenariot ovan hade berättelsen varit en annan. Vi tar den från början igen.

” Nu fungerar inte testet längre!” säger operatören. Du svarar: ”Ja, jag har sett att ni har haft en nedåtgående trend på yielden ett tag nu. Jag har analyserat yielden med QRM och identifierat den mätning som orsakar problemet. – Jag gjorde en SPC analys på de senaste veckornas produktion och kan se att mätprocessen inte är stabil och under kontroll i nuläget. Cpk har sjunkit från 1.5 till strax under 1.2 de senaste veckorna och jag har exporterat ut mätdata till utvecklingsavdelningen tillsammans med några andra mätdata så de kan kolla på detta. Vi vill inte skicka ut några enheter till kund som inte håller rätt kvalité. Kvalitétsavdelningen är nu inkopplade för att gå till botten med detta och ledningen är bekymrade över att vi inte kan leverera lika mycket som förra månaden. Det visade QRMs produktionsrapporter.”

Utvecklingsavdelningen är mycket konfunderade över detta och undrar om det kan bero på testutrustningen? Men för att vara på den säkra sidan och utesluta detta, utförde du en MSA – Measurement System Analysis på teststationerna och QRM kunde med hjälp av den inbyggda MSA analysen direkt visa att systemet har god precision, repeterbarhet och reproducerbarhet och att problemet beror på variationer i testobjektet.

Genom att agera snabbt med rätt beslutsunderlag kunde kvalitén i produktionen garanteras och inga felaktiga enheter levereras till kund. Investeringen i ett resultathanteringssystem återbetalar sig mycket snabbt. Har du råd att vara utan?

PS! Den nya testingenjören skickades på QRM kurs, så kompetensen bibehölls.

Mer om Quality Result Management hittar du här.

Kort om författaren:

Mattias Ericsson har jobbat med test- och mätsystem i 15 år. Han är R&D manager inom AddQ, Test och mätsystem och jobbar med framtagningen av resultathanteringssystmet QRM när han inte är upptagen med kundprojekt.