Om kvalitetssäkringen av programvara börjar med ett visst antal fel kan det vara lättare att hitta alla problem. Många pusselböcker visar till exempel en teckning och ber dig hitta ett exakt antal gömda föremål. Eller så visar de dig ett par teckningar och ber dig se ett visst antal skillnader mellan dem.
Inom programvaruutveckling är antalet skillnader - eller buggar - inte alltid så specifikt. Hur mycket enklare skulle inte kvalitetssäkring av programvara vara om någon kunde viska i vårt öra hur många fel som finns att hitta? I verkligheten vet vi aldrig. Vi vet bara ett minimum: om vi har hittat 37 fel, vet vi att det finns minst 37 fel. Kanske finns det en till att hitta, eller så finns det hundratals - vi kan inte vara säkra.
Det skulle vara bra att ha en ungefärlig uppfattning om hur många fel som återstår, så att vi kan använda våra testresurser på bästa sätt. Om vi alltid utgår från att det finns hundratals fel som återstår att hitta, kan det hända att vi övertestar en produkt på bekostnad av andra. Om vi har anledning att misstänka att vi har hittat alla fel, eller nästan alla, kan vi omfördela våra resurser så att deras tid och arbete används på bästa sätt.
Grova uppskattningar
Ingenting kan säga hur många fel som finns kvar under kvalitetssäkringen av programvara, men lite matematik kan ge dig en uppskattning. Antag att du har en testare som har hittat ett antal fel. Om du inte bara visste hur effektiv hon är på att hitta fel, utan också hur stor sannolikheten är att hon hittar varje fel under en viss tidsperiod, skulle du kunna uppskatta hur många fel det finns att hitta. Men du kan inte veta hur många fel som hon har hittat om du inte vet hur många fel som finns att hitta.
Anta att du har en annan testare som också har hittat ett visst antal fel. Du vet inte heller hur många fel han har hittat. Men genom att kombinera felräkningarna från de två testarna kan du uppskatta hur många fel det finns.
Detta kan verka för bra för att vara sant, men det är det inte - det viktiga är att ta hänsyn till hur många fel som båda testarna hittade. Anta att den första testaren hittade 20 fel och den andra 30, men att det bara fanns ett fel som båda hittade. Man kan misstänka att det finns många fel att hitta, eftersom båda kunde hitta så många med knappt någon överlappning. Om å andra sidan 18 av felen på den första listan finns med på den andra listan kan du känna att dina testare förmodligen har hittat de flesta av dem.
Lincoln-indexet
Du kan kvantifiera en uppskattning med ett verktyg som kallas "Lincoln-index". Om den första testaren hittade A fel, den andra hittade B och C fel var gemensamma för dem, skulle det uppskattade totala antalet fel vara AB/C. I det första exemplet ovan är A = 20, B = 30 och C = 1. I detta fall skulle det finnas uppskattningsvis 600 felrapporter att hitta. Men i det andra exemplet ovan är A = 20, B = 30 och C = 18. I detta fall skulle det finnas en beräknad 33 1/3 fel.
Hur hittar man 1/3 av ett fel? Du kan hitta 1/3 fel i din soppa, men du kommer inte att hitta 1/3 programfel. Lincoln-indexet är en enkel matematisk modell, så det kan inte säga exakt hur många buggar det finns. Den bygger på ett par förenklade antaganden, nämligen att testare hittar fel slumpmässigt och oberoende av varandra. Detta kommer inte att vara exakt sant i praktiken, vilket innebär att vi bör vara skeptiska till den siffra som genereras. Lincoln-indexet ger oss ändå en uppskattning att utgå från - mycket bättre än att säga: "Jag har ingen aning om hur många buggar det finns".
Här är matematiken bakom Lincoln-indexet: Anta att det finns totalt N fel och att den första testaren har en sannolikhet p att hitta varje fel. Då skulle hon hitta ungefär A = Np insekter. Om den andra testaren har en sannolikhet q att hitta varje fel, skulle han hitta ungefär B = Nq. Och om de hittar fel oberoende av varandra skulle de hitta ungefär C = Npq fel gemensamt. Då bör AB/C vara ungefär (Np)(Nq)/(Npq) = N, antalet insekter. Sannolikheterna för att varje testare ska hitta ett fel upphäver varandra.
Slutsats
Även om processen för kvalitetssäkring av programvara aldrig kommer att vara lika enkel som ett pussel med att hitta skillnaderna finns det för vissa typer av programvaruutveckling enkla verktyg som hjälper till att uppskatta det svårfångade antalet fel. Med hjälp av Lincoln-indexet kan vi fastställa graden av överlappning mellan våra testresurser, vilket vanligtvis talar för hur många fel som återstår att upptäcka. Med denna grova uppskattning kan vi fatta datadrivna beslut om hur vi bäst fördelar våra resurser.
![En global plan för hantering av samarbetsarbete [Video]](https://blog.planview.com/wp-content/uploads/2019/07/A-Global-Collaborative-Work-management-blueprint.png)
