7 nøgle ISTQB testprincipper | #3 Første skridt i softwaretestning

At udføre præcise og korrekte softwaretest følger mange principper. International Software Testing Qualifications Board skelner mellem syv grundlæggende, som vi vil diskutere i dag. Nysgerrig efter at finde ud af? Læs en artikel om de vigtigste ISTQB testprincipper!

ISTQB testprincipper – indholdsfortegnelse:

1. Testning afslører fejl, men kan ikke bevise deres fravær
2. Grundig testning er umulig
3. Tidlig testning sparer tid og penge
4. Fejlens sneboldseffekt
5. Pesticidparadokset
6. Det afhænger af konteksten
7. At reklamere for fejlfri software er et no-go
8. Sammenfatning

Testning afslører fejl, men kan ikke bevise deres fravær

Testning øger sandsynligheden for at finde fejl, hvilket igen letter chancerne for at rette dem. Dog kan det ikke fuldt ud garantere, at softwaren er fri for alle fejl, selvom langt de fleste bliver opdaget og rettet. På grund af manglende evne til at skabe fejlfri software, betragter mange processen som negativt designet, da man aldrig vil få et positivt resultat og altid vil finde noget “snavs” i programmerne.

Grundig testning er umulig

Den ovenstående tommelfingerregel siger, at det er nytteløst at opdage alle funktionsfejl i software. Dog gælder det ikke for simple korte programmer. Dette indikerer, at der er en chance for at se alle kombinationer af input og forudsætninger for at teste nogle programmer fuldstændigt. Når man evaluerer sofistikeret software, kan selv den bedste AI ikke udføre alle nødvendige målinger, for ikke at tale om manuelle testere. Automatiserede vurderere vil køre gennem apps mere effektivt og præcist, men de kan stadig ikke garantere fejlfri ydeevne. For at gøre det, skal man påtage sig yderligere opgaver som prioritering, risikanalyse samt finde og anvende andre testteknikker.

Tidlig testning sparer tid og penge

Mange fagfolk kalder også dette princip “skifte til venstre.” Jo før du opdager fejl, jo lettere kan du rette dem, derfor bør statisk og dynamisk testning begynde så tidligt som muligt. Kort sagt:

• Statisk testning – vurdering af produktet uden at køre koden.
• Dynamisk testning – evaluering af koden i et modul eller system under dets ydeevne

At opdage fejl i de første faser af implementeringen letter yderligere diagnose. Men når to områder af software interagerer, bliver det besværligt at rette fejl på grund af manglende evne til at pege på den, der har fejlen. I sådanne tilfælde kræver det ekstra tid, kræfter og arbejdskraft at tackle. Alt i alt er det den hurtige reaktion på opståede forhindringer, der kan forhindre, at revnerne multipliceres.

Fejlens sneboldseffekt

De fleste fejl har tendens til at klynge sig i de mest kritiske moduler, så deres dybdegående undersøgelse afslører og tilstrækkeligt eliminerer de fleste. Disse grupper bliver det primære fokus for at køre risikanalyse for at kortlægge og fastlægge fremtidige handlinger. De fleste fejl dukker op efter at have fulgt de stier, som brugerne tager, men i disse tilfælde gør viden alene ikke modulerne ufejlbarlige.

Pareto-princippet siger, at 80% af resultaterne stammer fra kun 20% af årsagerne. Med andre ord, 80% af fejlene findes i 20% af modulerne. Hvis du støder på adskillige funktionsfejl i et modul, så fortsæt med at grave, da de vil være der.

Pesticidparadokset

At køre de samme tests gentagne gange kan fejle, fordi de muligvis er designet forkert fra starten og aldrig vil vise sig at være effektive. Du skal ændre og opgradere testningen for at øge chancen for at finde nye fejl i softwaren.

At skabe et helt nyt system til diagnose vil heller ikke gøre tricket. At følge de tidligere kombinationer kan stoppe vurderingsprocessen på samme niveau. Dette princip kaldes ‘pesticidparadokset’, fordi pesticider, der kontrollerer skadedyr, også mister effektivitet efter en given mængde brug.

Det afhænger af konteksten

Metoden til at udføre testning afhænger af de emner, der undersøges. Således varierer testning af et regnskabsprogram, et videospil eller en social medieapplikation betydeligt. Det afhænger også af situationen, for eksempel vil en analyse, der fokuserer på praktisk anvendelighed af en app som at tjekke dens tiltrækningskraft for brugerne, brugervenlighed, visuel lag osv., også adskille sig fra de evalueringer, der sigter mod programmets funktionelle egenskaber, f.eks. at udføre korrekte beregninger.

At reklamere for fejlfri software er et no-go

At anvende forskellige typer diagnostiske værktøjer kan ikke garantere fejlfri apps. Mange, der hævder og reklamerer for deres apps som sådanne, tager fejl, men sandsynligvis er det kun for de marketingindsatser, de gør krav på. Du kan udføre adskillige manuelle og automatiserede tests for at øge sandsynligheden for at afdække og rette så mange fejl som muligt, men stadig er der ingen garanti for perfekt ydeevne. I nogle tilfælde vedrører forhindringerne operativ software, f.eks. kan programmet muligvis ikke opfylde alle brugerens forventninger.

ISTQB testprincipper – sammenfatning

Dette er, hvordan ISTQB, på et grundlæggende niveau, præsenterer syv ISTQB testprincipper, som en softwaretester bør følge. For det første indikerer de urealismen i fuld softwarediagnose, derfor er det afgørende, blandt andet, at ændre tests samt at udføre en grundig søgning i de centrale moduler. Disse handlinger forbedrer søgningen og rydningen af de fleste fejl, hvilket mindsker sandsynligheden for fejl i fremtiden.

Hvad er softwaretestning? Nu ved du svaret! Tjek vores andre serier om Python og Javascript!

Hvis du kan lide vores indhold, så bliv en del af vores travle bier-fællesskab på Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.