Softwaretestning er et utroligt komplekst og intensivt område, hvor virksomheder og uafhængige udviklere alle søger at forbedre deres produkter med en række testmetoder.
En af de mest almindelige metoder, som virksomheder bruger til at teste, er black box-testning, en teknik, der skaber afstand mellem udviklere og testere for at give præcise resultater og eliminere skævheder.
Få mere at vide om, hvad black box-testning er, hvordan man udfører black box-testning, og nogle af fordelene ved at implementere black box-testning i softwareudvikling med denne detaljerede vejledning.
Hvad er Black box-testning?
Black box-testning henviser til processen med at teste et system eller et stykke software uden at have nogen forudgående viden om den måde, det fungerer internt på. Dette henviser ikke kun til, at man ikke kender til selve kildekoden, men også til, at man ikke har set nogen af de designdokumenter, der omgiver softwaren. Testerne giver blot input og modtager output som en slutbruger ville gøre. Selv om dette er en simpel black box-testdefinition, er det en generel definition af systemet.
Målet med black box-testning er at få brugerne til at interagere med softwaren på en mere naturlig måde end normalt, uden at de har nogen forudindtagethed, der skyldes, at de allerede kender softwaren.
I denne metode er de personer, der er ansvarlige for at gennemføre testene, forskellige fra dem, der har udviklet softwaren, hvilket skaber en adskillelse mellem de to teams.
1. Hvornår og hvorfor skal du lave Black Box-test i softwaretestning?
Der er nogle få faser i udviklingscyklussen, hvor det er ideelt at bruge black box-test, og de fleste black box-test finder sted i slutningen af udviklingen, kort før frigivelsen.
Dette omfatter metoder som f.eks. brugeracceptationstest, hvor softwaren testes af medlemmer af softwarens målgruppe som en form for test før udgivelsen. Dette er mere almindeligt kendt som betatest og er et ideelt værktøj for en virksomhed, da større eksponering betyder, at folk er mere tilbøjelige til at finde potentielle fejl i softwaren.
Det er et must at arbejde med black box-metodologien mod slutningen af udviklingscyklussen, da det er en version, som brugeren sandsynligvis vil få adgang til. Du kunne bruge black box-testning af de enkelte funktioner, men det ville ødelægge formålet med testen.
2. Når du ikke behøver at lave Black Box-test
Black box-testning har meget lidt formål i de tidligste faser af udviklingen. Når en virksomhed opbygger den grundlæggende funktionalitet i sin software, bruger den white box-testning, så udvikleren kan se, hvor i koden der er problemer.
Der er heller ikke behov for black box-testning, når softwaren er open source eller et relativt simpelt webværktøj eller designet til at hjælpe en tredjepart med kodningsprojekter, da der er en relativt simpel brugergrænseflade, og brugeren alligevel kan få adgang til programmets kildekode. Hvis du forventer, at en bruger skal have adgang til kildekoden, mister black box-testning sit hovedformål.
3. Hvem er involveret i Black box-testning?
Der er mange roller, der er involveret i black box-testprocessen, og nogle af disse roller afhænger af arten af den virksomhed, der udfører testen.
Vigtige roller med involvering i black box-testprocessen omfatter:
– Tester
En tester er ansvarlig for at gennemføre manuelle testcases i en virksomhed, skrive grundige testcases, der undersøger appen i detaljer, før de udføres og rapporterer resultaterne. Denne rolle eksisterer primært i en manuel testproces, med automatiserede systemer, der spiller en rolle, hvor der er testautomatisering på plads.
– QA-analytiker
En QA-analytiker er ansvarlig for programmering af testcases i en QA-proces, primært når virksomheden anvender en QA-testautomatiseringsproces.
Processen omfatter både udformning af grundige testcases, der sikrer et højt funktionsniveau, og udførelse af testcases og hentning af resultater, når de er færdige.
– Udvikler
Den person, der er ansvarlig for udviklingen af den software, som QA-teamet tester. En udvikler modtager feedback fra testteamet og opdaterer softwaren i overensstemmelse hermed, idet han/hun arbejder som en del af et udviklingsteam, men er i konstant kommunikation med testerne.
– QA Manager
En QA-manager er leder af kvalitetssikringsteamet og er ansvarlig for at lede alle de opgaver, som testerne udfører.
Dette omfatter tilrettelæggelse af testplanen, udarbejdelse af en liste over de ting, der skal gøres for medarbejderne, og løsning af eventuelle konflikter i teamet. De forklarer også black box-test i forbindelse med uddannelse af nye medarbejdere.
– Projektleder
En projektleder er ansvarlig for kvaliteten af det endelige projekt og overvåger både testprocessen og udviklingen for at sikre, at kunden får en softwarepakke, der lever op til alle krav.
Fordele ved Black Box-testning
Der er flere væsentlige fordele ved at bruge black box-test i dit udviklingsarbejde. Jo mere du er opmærksom på disse fordele, jo mere kan du udnytte dem og få så mange fordele som muligt ud af teknikken.
Nogle af de vigtigste fordele ved at bruge black box-test i din kvalitetssikring omfatter:
1. Intet behov for teknisk viden
En black box-tilgang betyder, at du ikke har brug for teknisk viden, når du undersøger en applikation.
Målet med black box-testning er at undersøge, hvordan applikationen fungerer for slutbrugeren, og standardbrugeren har i de fleste situationer ikke nogen avanceret teknisk viden. Dette kan reducere omkostningerne til testning og hjælpe organisationen med at opdage flere fejl til en lavere pris og dermed blive mere økonomisk effektiv.
2. Præcis modellering af brugeren
Slutmålet med en black box-testproces er at forstå, hvad problemerne med en applikation er, når en bruger interagerer med den i dagligdagen.
Nogle typer af black box-testning – som fokuserer på at efterligne den måde, som en bruger opfører sig på – modellerer brugerens adfærd med en høj grad af præcision. Dette gælder især for brugeraccepteringstest, hvor slutbrugerne oplever produktet og ikke blot modellerer eller simulerer en brugers adfærd, men rent faktisk implementerer den.
En nøjagtig modellering hjælper med at afsløre eventuelle fejl, der påvirker brugerens faktiske arbejdsgange.
3. Mulighed for crowdsourcing af test
Black box-testning er en meget tilgængelig form for testning takket være de relativt lave krav til færdigheder.
Det betyder, at virksomheder ikke blot kan ansætte testere med et lavere niveau af tekniske færdigheder, men også at de kan crowdsource deres testning til ivrige kunder. Dette er mere og mere almindeligt i spilindustrien, hvor virksomheder tilbyder Early Access-udgivelser og opdaterer spillet med tiden for at løse problemer, som brugerne finder.
Det er meget lettere at finde fejl i dette tilfælde, da alle funktioner er meget mere eksponeret.
Udfordringer ved Black Box-testning
Ud over fordelene ved black box-testning er der et par store udfordringer, som du skal tage højde for. Hvis du er opmærksom på disse udfordringer, kan du tilpasse dig dem og øge standarden af dine test ved at reducere de skadelige virkninger, som black box-testning kan have.
Nogle af disse udfordringer omfatter:
1. Svært at finde årsagerne til problemerne
En af de største ulemper ved black box-testning er, at det kan være vanskeligere at finde årsagen til problemer, når testerne ikke har adgang til kildekoden.
Selv om de kan beskrive, hvad fejlen er, og hvornår den opstår, har de ingen indikation af, hvilken del af kildekoden der forårsager problemerne eller hvorfor.
Testerne kan afbøde dette ved at være grundige i deres notater, og detaljerede fejlmeddelelser fra udvikleren kan også give yderligere indsigt i fremtidige opdateringer.
2. Automatisering er vanskeligere
Da du aktivt forsøger at genskabe den måde, som en bruger interagerer med en softwarepakke, kan det være ekstremt vanskeligt at automatisere en black box-testproces.
Den første årsag til dette er, at testeren ikke har adgang til kildekoden, hvilket gør det vanskeligere at kode en præcis testcase. Dette hænger sammen med det faktum, at testen er designet til at efterligne menneskelig adfærd så meget som muligt, idet automatiseringen er specielt designet til at agere som en robot.
Du kan afbalancere dette problem ved at automatisere de mere ubetydelige opgaver og kombinere automatisering med manuelle tests, hvor det er muligt.
3. Problemer med test i stor skala
Ovennævnte problemer med automatisering betyder, at det er mere kompliceret at teste i større målestok. Test i stor skala giver virksomhederne mange flere data om softwaren og betyder, at det er lettere at finde og gentage fejl.
Kravet om manuel testning som en prioritet betyder, at det kan være vanskeligere at arrangere testning i større målestok. Nogle virksomheder imødegår dette ved at bruge et “åbent betasystem”, hvor alle med interesse i produktet kan hjælpe med at teste før udgivelsen og støtte virksomheden ved at give feedback på tidlige builds på frivillig basis.
Karakteristika ved Black Box-test
Der er nogle få vigtige karakteristika ved black box-tests, som man skal være opmærksom på, og som adskiller testningen fra enhver anden form for kvalitetssikring af software.
Disse egenskaber omfatter:
1. Ingen forudgående intern viden
Black box-test kræver ingen forudgående intern viden om softwaren. Dette kan være vanskeligt i nogle tilfælde, da testerne har en idé om de aspekter af den software, de tester, og nogle af de funktioner, de leder efter, men dette defineres bredt som ikke at kunne se intern dokumentation af nogen art.
Hvis oplysningerne er synlige for en slutbruger i en app-butik eller på download-siden på et websted, kan en tester se dem.
2. Adskil testere og udviklere
Test- og udviklingsfaserne gennemføres af forskellige personer i en black box-testsituation. Denne forskel skyldes den manglende viden, som testere har, da udviklere har viden om kildekoden, fordi det er dem, der har udviklet den.
Virksomhederne griber dette an på forskellige måder afhængigt af deres specifikke situation, idet nogle vælger at bruge en ekstern organisation til at udføre testningen, mens større virksomheder har dedikerede afdelinger med testere til at udføre dette arbejde.
3. Afprøvning i den sene fase
Dette henviser til det udviklingsstadie, hvor denne afprøvning finder sted. Black box-tests er baseret på en relativt avanceret version af en eksisterende applikation med en omfattende brugergrænseflade, der giver mulighed for at navigere gennem softwaren og adgang til alle funktioner i frontenden af hver enkelt funktion.
Det betyder, at black box-tests kun er mulige i nogle af de senere faser af testprocessen, når alt dette først er blevet udviklet. Selv om brugergrænsefladen og kontrolelementerne kan blive ændret med tiden, skal de eksistere i en eller anden form for at give blackbox-tests adgang til funktionaliteten.
Hvad tester vi i Black box-test
Black box-testning undersøger specifikke aspekter af en softwarepakke og giver ekstra information på nogle områder af softwaren, som fører til opdateringer, der øger den generelle livskvalitet.
Nogle af de vigtigste dele af en softwarepakke, som testere undersøger i en black box-test, omfatter:
1. Funktionalitet
Nogle udviklere bruger black box-testning som et middel til at sikre, at et stykke software fungerer efter hensigten for en person uden eksisterende viden.
Langt de fleste mennesker, der bruger et stykke software kommercielt, gør det uden at have nogen forståelse for softwarens indre funktioner, så testning med denne viden betyder, at du kender løsninger på eventuelle eksisterende problemer.
Denne grundige funktionalitetstest sikrer, at alle oplever det bedste, som applikationen har at tilbyde, i stedet for at støde på fejl, som ikke ses, når white box-testning anvendes.
2. Brugergrænseflade
Brugergrænsefladen henviser til alle de måder, hvorpå brugeren interagerer med et program for at få det til at udføre en række opgaver. Dette omfatter de menuer, som en bruger arbejder med, de specifikke knapper, der findes i et program, og den branding, der findes i hele softwaren.
Udviklerne bruger størstedelen af deres tid på at sikre, at selve programmet kører som forventet, hvilket betyder, at der er mindre opmærksomhed på brugergrænsefladen.
Black box-testning præsenterer testerne kun for softwarens funktioner i brugerenden, hvilket giver mere opmærksomhed på brugergrænsefladen end i de fleste andre testfaser.
3. Ydelse
Ud over at fungere normalt og se godt ud er det vigtigt, at et program fungerer på en måde, som er afgørende for at tilfredsstille kunderne.
Ydeevne henviser til nogle få faktorer, herunder appens hastighed, når den reagerer på brugerinput, og de ressourcer, den bruger på en given enhed.
Med testformater som end-to-end-test, der undersøger alle funktioner i et stykke software, kan udviklere se, hvor meget hukommelse en app bruger, og hvilke funktioner der belaster deres respektive enheder mest, hvilket kan styre effektivitets- og ydelsesrelaterede opdateringer i senere versioner af applikationen.
Jeg rydder lidt op i forvirringen:
Black box vs. White box vs. Greybox-testning
Black box-testning er et begreb, der lyder som grey box- og white box-testning, men ideerne er grundlæggende meget forskellige fra hinanden. Hvis du forveksler dem, kan det give alvorlige kommunikationsproblemer i udviklingsprocessen og gøre opdateringsprocessen langsommere og mindre effektiv.
Læs videre for at få klarlagt noget af forvirringen omkring de forskellige typer af “bokstest”, hvordan de adskiller sig fra hinanden, og hvornår de skal bruges.
1. Hvad er White Box Testing?
White box-testning er undertiden kendt som “glass box-testning” og henviser til en testproces, hvor testeren har fuld adgang til alle oplysninger bag softwaren. Dette omfatter adgang til kildekoden, designdokumenterne og pakkeens kundebeskrivelse.
Hvis en tester f.eks. arbejder i de tidligste faser af en udviklingsproces med at undersøge en enkelt funktion, betyder det at kunne se funktionens kildekode, at han/hun straks kan finde årsagen til problemet.
Et af de bedste tidspunkter for at bruge white box-testning er primært i forbindelse med interne opgaver. Dette henviser til den tidlige udvikling af applikationens funktionelle side, hvor hurtige løsninger er ideelle, da der ikke er nogen fordel ved at sløre koden, når du ikke simulerer brugeroplevelsen. Test af hvid kode anvendes også i open source-systemer, da kildekoden i disse tilfælde er tilgængelig for alle brugere.
Hvad er forskellene mellem white box og black box-testning?
Den vigtigste funktionelle forskel mellem black box-testning og white box-testning er det niveau af adgang, som testeren har til softwaren, men dette har langt større indvirkning på aspekter af testen, såsom timing.
Black box-testning anvendes mere konsekvent senere i processen, efterhånden som produktet nærmer sig lanceringen, mens de mere grundlæggende udviklingsfaser nyder godt af gennemsigtigheden og lydhørheden ved white box-testning. Når man overvejer en black box-test vs. white box-test, adskiller de to også i det nødvendige ekspertiseniveau, da white box-test kræver ekspertise inden for kodning og udvikling for at være mere effektiv.
2. Hvad er Grey Box Testing?
Grå boks-testning er en form for testning, hvor en bruger har en vis forståelse af koden uden at have fuld adgang til koden. Dette indebærer at have kildekoden til den funktion, der testes, eller at have adgang til noget af designdokumentationen, så brugeren forstår, hvad den overordnede hensigt med softwarepakken er.
Hvis en tester f.eks. kun undersøger en af funktionerne i en softwarepakke, kan han/hun få adgang til kildekoden for denne ene del af programmet.
Virksomheder bruger primært grey box-testning, når de undersøger den måde, hvorpå en applikation er integreret med et tredjepartsværktøj. De kan kun få adgang til kildekoden for en del af processen, hvilket begrænser deres muligheder for at gennemføre grundige white box-test. I stedet kan de se input og output fra tredjepartsintegration og den kildekode, der er ansvarlig for integrationen.
Testerne bruger dette til at vurdere, om der opstår problemer på grund af softwaren, tredjepartsapplikationen eller integrationen mellem de to.
Hvad er forskellene mellem Black box og Grey box Testing?
Hovedforskellen mellem black box- og grey box-testning er igen niveauet af adgang til information, og den type software, der testes, er en af de vigtigste faktorer, der adskiller testtyperne fra hinanden.
Grå boks-testning har tendens til at omfatte tredjepartsværktøjer som f.eks. datalagring i skyen eller eksterne behandlingsværktøjer, mens black box-systemer har tendens til at være en sammenhængende enhed. Mange black box-tests er ikke afbrudt af tredjeparter, mens integrerede applikationer ikke har andet valg end at arbejde med en grey box-testmetodologi.
3. Konklusion: Black box vs. White box vs. Grey box testning
I sidste ende er der grundlæggende forskelle mellem black, grey og white box-testning, som alle er baseret på, om testteamet får adgang til oplysninger bag kulisserne.
Black box- og white box-testning er yderpunkterne i dette spektrum, mens grey box-testning omfatter alt fra at se alt undtagen kildekoden fra tredjepart til kun at kunne se koden bag en specifik funktion.
Alle disse testmetoder spiller dog en rolle i softwaretestområdet, så det er et must at bruge tid og opmærksomhed på at lære dem og implementere dem effektivt.
Typer af Black Box-test
Der er tre hovedtyper af black box-testning, som omfatter alle de test, som en virksomhed gennemfører ved hjælp af black box-metoden. Det drejer sig om:
1. Funktionel afprøvning
Funktionel testning omfatter alt omkring den måde, som applikationen fungerer mekanisk på. Dette indebærer at sikre, at den håndterer data på den korrekte måde, at brugerne kan logge ind med de rigtige legitimationsoplysninger og at den behandler oplysninger og input som forventet.
Test af funktionalitet er et af de vigtigste aspekter af processen og omfatter både applikationens lokale funktionalitet og den måde, hvorpå den interagerer med eksterne værktøjer og programmer som f.eks. cloud-baserede tjenester eller værktøjer til enkeltlogon.
2. Ikke-funktionel afprøvning
Ikke-funktionel testning henviser til testning, der undersøger ethvert aspekt af softwaren, som ikke udtrykkeligt vedrører applikationens funktionalitet. Dette indebærer at fastslå, om en applikation er anvendelig og let at forstå for brugerne, om den er kompatibel med en lang række enheder og operativsystemer, og om den fungerer under betydelige belastninger (selv om dette kan gå over i funktionel testning på visse punkter).
Dette sker primært mod slutningen af udviklingsprocessen, når den komplette app er blevet kompileret.
3. Regressionstest
Efter en opdatering gennemgår testerne et program for at sikre, at det har udført den tilsigtede funktion, og at der ikke er utilsigtede bivirkninger, som får programmet til at gå tilbage.
Dette kaldes regressionstest og er en grundlæggende del af arbejdet med at sikre, at en applikation er klar til at blive sendt på markedet.
Regressionstest anvendes efter hver enkelt opdatering for at sikre, at både de funktionelle og ikke-funktionelle aspekter af applikationen lever op til den standard, der tidligere blev opnået.
Black Box-testteknikker
Når du gennemgår black box-testprocessen, er der en lang række teknikker, som du kan implementere for at forbedre standarden af dit arbejde. Nogle af de vigtigste black box-testteknikker, som du bruger i et kvalitetssikringsmiljø, omfatter:
1. Parvis testning
Parvis testning er en form for testning, der fokuserer på at afprøve alle mulige kombinationer af dataindgange i softwaren.
Hvis f.eks. tallene et til ti er alle gyldige indtastninger i en kolonne med alle alfabettegn i en anden kolonne, vil parvis testning teste alle mulige kombinationer fra 1A til 10Z. Dette er en form for testning, som kan tage meget tid og kræfter for en bruger at gennemføre, hvilket gør den til en af de teknikker, der er mest åben for potentiel hyperautomatisering. Dette er ekstremt grundigt og finder eventuelle problemer med dataindtastning.
2. Grænseværdianalyse
Mange programmer er afhængige af dataindtastning, og dataene har specifikke grænser, som en klient forventes at arbejde inden for.
Et system, der er udviklet til at beregne tal fra 1 til 100, kan f.eks. have svært ved at håndtere værdier på 0 eller lavere eller højere end 100.
Grænseværdianalyse indebærer test af disse grænser, idet der indtastes tal ved og omkring de grænser, som softwaren tester, for at undersøge, om der er fejl i kanten af en softwarepakkes forventede arbejdsområde. Dette er primært nyttigt i beregningsbaserede systemer og kan hjælpe udviklerne med enten at justere grænserne eller finde årsagen til eventuelle problemer.
3. Test af tilstandsovergange
Mange programmer varierer mellem forskellige “tilstande” eller “tilstande” og kræver en overgang fra en fase af denne proces til den næste. Når disse overgange fungerer korrekt, betyder det, at webstedet fungerer som brugeren forventer, og at der ikke er nogen uventede forsinkelser.
Test af tilstandsovergange er en form for test, der undersøger alle overgange mellem tilstande i et stykke software, og som sikrer, at de er funktionelle og giver sikkerhed for, at brugerens strømme gennem softwaren fungerer uden uventede afbrydelser.
Black box-testning i softwareudviklingens livscyklus
Black box-testning er en disciplin, der primært anvendes mod slutningen af softwareudviklingens livscyklus. Dette omfatter alt fra test af den måde, som brugerne interagerer med softwaren på, til at give fuld beta-adgang, hvor black box-testning primært kommer ind, når alle funktionerne fungerer som forventet.
Det sparer en masse tid og kræfter i forhold til white box-testning, som kræver et højt niveau af ekspertise, og som er bedst implementeret, når du ikke har brug for et udviklingsteam til at foretage øjeblikkelige ændringer i den måde, systemet fungerer på.
Manuelle eller automatiserede black box-tests?
Softwaretestning findes i to forskellige former, hvor manuel testning er den traditionelle form, hvor der anvendes softwaretestere i alle faser af processen. Dette er i klar modstrid med automatiseret testning, som anvender et stigende niveau af kunstig intelligens og maskinlæring til at udføre opgaver uden menneskelig indblanding.
Læs videre for at få mere at vide om, hvad manuel og automatiseret testning er, hvilke udfordringer de hver især har, og hvilken af de to metoder der er ideel for en virksomhed.
1. Manuel Black Box-testning – fordele, udfordringer, proces
Manuel black box-testning henviser til processen med at gennemføre black box-testning uafhængigt, hvor medarbejdere udfører alle opgaverne i stedet for at bruge en automatiseringsplatform som en del af virksomhedens værktøjssæt.
Nogle af de største fordele ved at bruge manuel testning i softwareudvikling er, at du har en større grad af fleksibilitet i forhold til den måde, du gennemfører testningen på, og at udviklerne kan få langt mere grundig feedback, som er af kvalitativ karakter.
Der er dog nogle få naturlige udfordringer ved den manuelle testproces. Den første af disse er, at manuel testning kan tage meget tid, da mennesker er langsommere end automatiserede programmer til at udføre deres opgaver.
En anden er et større potentiale for fejltagelser, idet folk har mulighed for at klikke forkert eller gøre ting i den forkerte rækkefølge. Dette kan i sidste ende resultere i unøjagtigheder i testdata.
Manuel testning er en proces, der starter med at lære virksomhedens forventninger til en applikation at kende, før man skriver testcases, der udfordrer denne opgave, udfører testcases og rapporterer resultaterne til udviklingsteamet.
2. Automatisering af sort boks test – fordele, udfordringer, proces
Automatiserede test henviser til test, som en virksomhed gennemfører på en softwarepakke ved at udfylde testcases med et automatiseret system. Disse bruger tredjepartsplatforme til at automatisere softwarepakken, hvor alle automatiserede trin følger specifikt forberedte testcases.
Den største fordel ved automatisering af black box-test er hastigheden, idet automatiserede programmer tager meget mindre tid for hver enkelt testkørsel. Det giver en stor tidsgevinst i forbindelse med testning, som du kan bruge på at udvikle applikationen.
En anden fordel er nøjagtigheden, da et godt automatiseringsværktøj udfører de samme opgaver i samme rækkefølge hver gang.
Ulemperne kan stadig forårsage problemer med automatisering af black box-test, og et af de vigtigste problemer er fokus på kvantitative data. Det er godt for målinger, men det betyder, at der i en brugeracceptabilitetstest kun er få værdifulde oplysninger at hente.
Der er også en relativ mangel på fleksibilitet i automatiseret testning, idet analytikerne skal kode helt nye testcases, hver gang de ønsker at foretage en ændring.
Processen for automatisering af test starter med design af en række testcases, som derefter kodes ind i systemet, før testene udføres, og der udarbejdes en rapport efter afslutningen.
3. Konklusion: Manuel eller Black box test automatisering?
I sidste ende er valget mellem manuel og automatiseret black box-testning et kompliceret valg, som afhænger af, hvad du leder efter i et system.
Hvis du er på udkig efter kvalitative oplysninger af høj kvalitet, som du kan bruge til at foretage designændringer for slutbrugeren, er manuel testning langt den bedste løsning, mens automatiseret testning er ideel til funktionelle og præstationsmæssige faser i processen.
Tænk over, hvad du leder efter i hvert enkelt trin af testprocessen, så kan du nemt få vejledte data, der forbedrer din præstation.
Hvad har du brug for for at starte Black Box-testning?
Der er nogle forudsætninger, som du skal have adgang til, før du går i gang med black box-testning, og som hver især bidrager til at skabe en mere sammenhængende testproces.
Nogle af de ting, du skal have med, før du begynder på black box-testarbejde, er bl.a:
1. Krav til software
Softwarekrav henviser til de specifikke punkter i en designbeskrivelse, som softwaren skal opfylde. Dette kan omfatte en række ting, lige fra at det er nødvendigt at udføre et bestemt sæt opgaver til at have et bestemt udseende og en bestemt fornemmelse, når du bruger det.
Når du har disse oplysninger, får du nogle få specifikke mål at sigte efter i din testning, og testerne kan udarbejde en testplan, der resulterer i et mere sammenhængende sæt resultater, som informerer udviklerne om problemer med softwaren.
I nogle virksomheder vil udviklerne begrænse testerens adgang til briefingen, da der er tale om en blackbox-test.
2. Kompileret software
Før et kvalitetssikringsteam kan teste et stykke software, skal det have adgang til softwaren. Dette indebærer typisk, at udviklerne leverer den nyeste version af softwaren, og at teamet har fordel af at have en helt nykompileret version af softwaren til at udføre deres tests på.
En nyere version betyder, at testene omfatter nogle af de nyeste rettelser, hvilket betyder, at de giver et nøjagtigt billede af, hvordan softwaren fungerer.
3. Mål for afprøvning
Testere har en tendens til at gå til en testperiode med nogle specifikke mål i tankerne. Disse testmål fastsætter præcis, hvad de tester for i den kommende periode, uanset om det er brugeracceptabilitet, end-to-end-funktionalitet eller fuldførelse af penetrationstest.
QA-ledere har disse mål, og den næste testfase afhænger typisk af, hvad udviklingsteamet har arbejdet med og de dele af softwaren, som denne udvikling påvirker.
Black Box-testproces
Black box-testprocessen er en relativt præcis proces, og virksomhederne har fordel af at følge processens trin så nøje som muligt. De forskellige faser i black box-testprocessen omfatter:
1. Planlægning af test
Start black box-testprocessen med en indviklet planlægningsproces. Dette indebærer en diskussion af alle de individuelle mål, som du har for testen, de specifikke aspekter af softwaren, som du undersøger, og de ressourcer, som du vil afsætte til testen.
En grundigere planlægning betyder, at alle ved, hvad de skal gøre, og hvornår de skal gøre det, herunder hvilke metoder der skal anvendes i forbindelse med testene.
2. Skrivning af testcases
Udarbejdelse af testcases er det næste trin i processen. En testcase henviser til en række trin, der skal gennemføres i en test, og mere detaljerede testcases giver brugeren en større grad af konsistens.
I en automatiseret testproces indebærer dette også kodning af testcasen i det automatiseringsværktøj, som du planlægger at bruge.
Dobbelttjek alle dine testcases for at sikre, at de er grundige og klare med hensyn til de trin, der skal gennemføres.
3. Udførelse af testcases
Når du har forberedt dine testcases, skal du begynde at udføre testcases. Når du bruger automatisering, kan det være en forholdsvis nem opgave, der består i at sætte programmet i gang og vente på resultaterne. Manuel testning er baseret på, at medarbejderne gennemfører testcases gentagne gange, og flere gentagelser fører til mere konsistente data af høj kvalitet.
Udfør alle testcases så omhyggeligt som muligt, da jo mere præcis udførelsen af testcases er, jo større er chancen for, at dataene kan være nyttige for udviklingsteamet.
4. Endelig rapportering
Den endelige rapporteringsfase henviser til den del af processen, hvor testteamet rapporterer tilbage til udviklerne.
Start med at inkludere et simpelt resumé af de indsamlede oplysninger, før du tilføjer alle de målinger, som testerne har indsamlet, til dette resumé. Dette giver udviklerne indledende vejledning om den ideelle retning for den næste række af opdateringer, før de får vist dem de fulde data, hvilket giver dem mulighed for at få en dybere forståelse af problemerne.
Bedste praksis for Black Box-testning
Uanset hvilken branche du er i, er det et must for enhver virksomhed at følge bedste praksis. Best practices henviser til en række adfærdsmønstre og teknikker, som en virksomhed har fordel af at anvende i sit daglige arbejde, hvilket øger virksomhedens effektivitet og forbedrer standarden af den software, som virksomheden anvender.
Nogle af disse metoder, der hjælper en virksomhed med at forbedre kvaliteten af dens black box-testning, omfatter:
1. Fokus på udvikling af færdigheder
Hvis du driver en virksomhed, der arbejder på flere softwareprodukter ad gangen, kan du overveje at fokusere på at udvikle testkompetencer og specialiseringer. Jo mere tid du bruger på at specialisere dig og udvikle de rette færdigheder, jo bedre er dine chancer for at finde ud af, om der er problemer i dine produkter.
Dette er forbundet med at ansætte folk med de rette færdigheder, men er mest hensigtsmæssigt for virksomheder, der næsten konstant tester software, da der altid er en fordel ved at anvende disse evner.
2. Balance mellem arbejdsbyrder
Nogle testteams kan være meget store med snesevis eller endog hundredvis af medarbejdere, som alle regelmæssigt udfylder testcases.
Den bedste praksis for at få mest muligt ud af disse medarbejdere er at tage sig god tid og være forsigtig med at tildele folk specifikke opgaver. Udbrændthed er en alvorlig årsag til problemer i softwareudviklingsbranchen, men det er noget, der kan undgås med en bedre styring af arbejdsbyrden.
3. Skab konsekvente processer
Virksomheder er bygget på at have processer, som deres medarbejdere gennemfører dagligt, og testprocesser omfatter den måde, hvorpå en virksomhed skriver testcases, gennemfører undersøgelser og kommunikerer internt på tværs af afdelinger.
Konsekvens i disse tilfælde er nøglen, da det betyder, at folk lærer hurtigere, når de kommer ind i virksomheden. Dette fører til hurtigere tilpasning og bedre resultater meget hurtigere end i en virksomhed uden konsistens på tværs af opgaverne.
Hvis du kan, skal du skabe disse processer på en måde, der inddrager medarbejderne i beslutningsprocessen, da det sikrer, at de er enige i strategien.
7 fejl og faldgruber ved implementering af Black Box-tests
Fejl er naturlige i alle brancher, men hvis du kender til fejl, før du får mulighed for at begå dem, kan du spare en masse tid og kræfter.
Nogle af de mest almindelige fejl og faldgruber, som black box-testere falder i, omfatter:
1. Manglende defineret testomfang
Nogle organisationer begynder at teste deres produkter uden at planlægge processerne ordentligt, hvilket er en stor fejl.
Ved at undlade at planlægge kan virksomheder miste overblikket over omfanget af testningen. Et aftalt omfang hjælper testen med at være af den rette størrelse og med at opnå effektive resultater.
Hvis I ikke er enige om omfanget af jeres testning, før I går i gang, er der en alvorlig risiko for, at I tester for bredt og tager for lang tid for at få resultater, der er mindre relevante.
2. Forhastede testprocesser
Testning kan føles som en proces, der tager meget lang tid, især med langvarige testcases, der er designet til at undersøge en hel applikation. Nogle mennesker kan være fristet til at skynde sig med deres test, især ved gentagelser af tidligere test. Dette er en alvorlig fejltagelse. Hvis du skynder dig at gennemføre dine tests, kan det føre til fejl i udførelsen af testcases, hvilket forringer værdien af dataene og i sidste ende betyder, at du alligevel skal lave de samme tests igen.
3. Automatisering uden en verifikationsproces
Testautomatisering fokuserer primært på at sikre, at indtastning af en dataværdi vil føre til det rigtige output i slutningen af processen. Automatisering af disse tests fungerer ved at kontrollere resultatet af den automatiserede proces i forhold til det, der burde være resultatet.
Nogle testere begår en væsentlig fejl ved ikke selv at beregne værdien, hvilket betyder, at de ikke har nogen mulighed for at kontrollere, om output er korrekt eller ej, og potentielt undlader at finde væsentlige fejl i hele systemet.
4. Manglende brug af hybrid testning
Hybrid testning henviser til en balance mellem automatisering og manuel testning, da de to metoder fungerer på en måde, der perfekt dækker hinandens fejl og mangler.
Nogle organisationer foretrækker dog at fokusere på en af de to metoder. Ved at gøre det åbner du op for alvorlige problemer og unøjagtigheder i din test.
Gennemfør hybridtestning for at opnå en bedre balance i din testning og reducere antallet af fejl så meget som muligt.
5. Manglende gennemførelse af regressionstest
Regressionstest bør være en konstant proces i ethvert effektivt softwaretestsystem, idet denne form for testning fastslår, om softwareopdateringer har forårsaget problemer andre steder i systemet. Hvis du ikke gennemfører regressionstest, betyder det, at funktioner, som du har testet tidligt i processen, kan fejle, uden at du opdager det.
Ved at gennemføre regressionstest sikrer du, at du leverer et produkt af højere kvalitet uden at lægge for meget ekstra arbejde i kvalitetssikringsprocessen.
6. Aktiv jagt efter fejl
Nogle tror, at målet med black box-testning er at finde fejl i en softwarepakke og rapportere dem til et udviklingsteam, og selv om dette er et aspekt, er det ikke det eneste fokus. Testning har til formål at forbedre en softwarepakkes standard generelt.
Ved at fokusere for meget på fejlene i softwaren begynder du at bevæge dig uden for standardarbejdsgange, idet du rækker ud over testens omfang og ignorerer nogle af de mere relevante problemer med softwaren til gengæld for at jagte potentielt irrelevante fejl i koden.
7. Ignorering af din intuition
Ved manuel test har en tester rollen, fordi han/hun har en eksisterende intuition og et kendskab til kode, der leder ham/hende mod potentielle problemer og informerer ham/hende om områder, der skal undersøges, når han/hun arbejder.
Nogle vælger dog at ignorere denne intuition fuldstændigt, når de arbejder med testcases. Ved at notere alt det, du ønsker at teste, og kontrollere det i en ny testcase, får du det fulde udbytte af din tekniske viden, samtidig med at du gennemfører de forberedte testcases.
Typer af output fra Black Box-tests
Der er flere typer output, som du kan få fra black box-test, og hver type giver unik indsigt for en virksomhed, der ønsker at foretage relevante opdateringer af sine produkter og forbedre den kvalitet, som kunderne oplever.
Nogle af de vigtigste typer af output fra black box-tests omfatter:
1. Kvalitative data
Den første form for output, som du kan få fra en black box-test, er kvalitative data. Det er oplysninger, der primært beskriver applikationen, og som stammer fra tests som f.eks. end-to-end-test og brugervenlighedstest.
Kvalitative data beskriver typisk standarden af applikationen, diskuterer folks erfaringer med applikationen og forklarer de ændringer, som en tester gerne vil foretage.
Når en tester skaber disse data, skriver han/hun typisk en grundig rapport med alle beviser for sine punkter og understøtter kvalitative udtalelser med yderligere funktioner som f.eks. skærmbilleder af det, han/hun refererer til.
2. Kvantitative data
Dette refererer til klare numeriske data i form af målinger, hvor testmedarbejdere enten noterer sig specifikke dele af en applikation eller modtager numeriske data fra en protokol til automatiseringstestning.
Kvantitative oplysninger er mere nyttige til at give udviklerne klare løsninger, der angiver dele af applikationen, f.eks. dens ydeevne, dens effektivitet med hensyn til ressourceforbrug og antallet af fejl og problemer, der findes i applikationen.
Kvantitative oplysninger er nemmere at analysere og vurdere end deres beskrivende modstykke, da der ikke er behov for fortolkning.
3. Fejlmeddelelser
Fejlmeddelelser forekommer, når softwarens funktionalitet ikke fungerer som forventet. Dette kan skyldes hardware- eller softwareproblemer og er typisk ledsaget af en kort beskrivelse af problemet samt en fejlkode.
Udviklere opretter et system af fejlkoder for at hjælpe dem med at indsnævre præcis, hvor et problem opstår i et system, og nogle ideer til implementering omfatter at bruge det første ciffer til at indsnævre den funktion, der oplever et problem, det andet til at beskrive, hvad der specifikt mislykkedes, og et tredje til at angive årsagen til problemet.
Ved at bruge dette system med fejlkoder ved udviklerne straks, hvad problemet er, og de kan arbejde på en løsning.
Eksempler på Black box-test
Mens teorien bag black box-testning er relativt enkel, kan det være en kompleks proces at implementere den i praksis, især for førstegangs-testere. Hvis du ser et eksempel på en black box-test i praksis, kan det hjælpe dig med at tilrettelægge din test.
Nogle eksempler på black box-testmetoder, herunder flere typer af test og forskellige grader af succes, omfatter:
1. Ineffektiv brugeraccepteringstest
En virksomhed ønsker at frigive sit produkt i de kommende uger, men brugeracceptationstesten mangler stadig at finde sted. Ansøgningen er en strikkevejledning til et ældre publikum.
Udviklerne søger at fremskynde denne proces og samle en gruppe af testere hurtigt, idet de udelukkende bruger ikke-strikkere i midten af trediverne til at teste, da de er en mere tilgængelig gruppe. Denne gruppe ser ingen problemer med ansøgningen og giver den grønt lys til offentliggørelse.
På grund af de to gruppers forskellige niveauer af teknisk viden er målgruppen mere forvirret, når de bruger softwaren, og kan ikke få adgang til mange af funktionerne. Som reaktion herpå er virksomheden tvunget til at gennemføre hastende opdateringer.
Fejl ved test som denne viser, hvor vigtigt det er at forberede sig grundigt.
2. Vellykket end-to-end test
End-to-end-testning henviser til testning, der finder sted, når en app-funktionalitet er blevet samlet i en softwarepakke for første gang.
En virksomhed har omhyggeligt planlagt at gennemføre en end-to-end testproces og har en række medarbejdere ansat specifikt til at udføre testopgaver med to medarbejdere dedikeret til hver testcase.
Efter en omhyggelig proces gennemfører de deres testcases og noterer alle data, som de indsamler, og en QA-manager samler dataene i en sammenhængende rapport ved afslutningen af testningen.
Udviklerne bruger denne rapport til at planlægge den næste række af opdateringer og ændringer af applikationen, hvilket forbedrer produktet betydeligt.
3. Automatiseret regressionstest
En udvikler har gennemført en række opdateringer til sin software, som før opdateringerne fungerede som forventet. Efter opdateringerne gennemgår testteamet en regressionstestproces med fokus på automatisering og får en automatiseret platform til at udfylde alle de grundlæggende funktioner.
Teamet skriver koden til en testcase og udfører testcases, læser alle testresultaterne og finder eventuelle problemer.
Dette forhindrer, at der opstår problemer, fordi en organisation foretager opdateringer og undlader at kontrollere, om de har et problem eller ej.
Typer af fejl og fejl, der opdages ved hjælp af Black box-testning
Selv om fejl og fejl ikke er alt i black box-testprocessen, er de en væsentlig del af den måde, som virksomheder tester på.
Hvis du kender nogle af de vigtigste typer af fejl og fejl i black box-testning, kan du kategorisere de problemer, du støder på, og forstå mere om, hvorfor de opstår.
Nogle af de vigtigste typer af fejl og mangler, der kan opdages ved hjælp af black box-testning, omfatter:
1. Brugervenlighedsfejl
Brugervenlighedsfejl henviser til fejl i et program, som ikke påvirker funktionaliteten, men som kan skabe problemer for en bruger, der forsøger at interagere med softwaren.
Hvis et program f.eks. har en alvorlig grafikfejl, fungerer det teknisk set stadig, men uden de rigtige ikoner og tekst kan slutbrugeren ikke bruge det effektivt. Disse problemer er ofte forbundet med appens design og den måde, som designet indlæses på for brugeren, idet mere komplekse applikationer kræver mere kompleks grafik end i enklere brugergrænseflader.
2. Funktionelle fejl
Funktionelle fejl henviser til problemer, der opstår, når en del af et program ikke fungerer som forventet.
Hvis du f.eks. kører et databasesoftwareprogram og forsøger at sortere oplysningerne efter en bestemt kategori, men finder ud af, at det ikke virker. Dette gælder både for funktioner, der slet ikke fungerer, og for funktioner, der ser ud til at fungere, men som fungerer forkert.
Dette kan være nogle af de største problemer for et program, der kan give brugerne store ulemper og forværre udviklerens omdømme, da produktet ikke fungerer som annonceret.
3. Nedbrud
Når et stykke software går ned, er der et grundlæggende problem med softwaren, som forhindrer den i at køre. Der kan forekomme forskellige former for nedbrud, herunder når et program lukker i sin helhed eller blot fryser på et tidspunkt i processen.
Et nedbrud er et af de mest alvorlige problemer, der kan opstå, da der ikke er nogen måde at få programmet til at fungere igen på, ud over at lukke og genåbne det fuldstændigt. Nogle programmer har stadig processer i baggrunden, men der er ingen mulighed for at interagere med softwaren efter dette punkt.
Almindelige målepunkter for Black Box-testning
Manuel black box-testning er fremragende til at generere kvalitative data, men når du fokuserer på kvantitative data, skal du være opmærksom på de målinger, du kontrollerer. Hvis du forstår disse målinger fuldt ud, kan du forstå fejlene i platformen og prioritere forskellige områder, der skal arbejdes på.
Nogle af de mere almindelige black box-testmetoder, som du finder i dit arbejde, omfatter:
1. Fejlprocent
Fejlprocenten kan henvise til et par ting, enten det rene antal fejl, der opstår i softwarens testcyklus, eller de fejl, der opstår pr. testtime. Timemålinger er bedre, da de repræsenterer tætheden af fejl i softwaren i stedet for blot at angive et tal, idet større programmer potentielt kan blive misrepræsenteret.
Udviklerne forsøger at begrænse fejlprocenten i deres applikationer, da jo færre fejl der er i softwarepakken, jo bedre bliver kundernes oplevelse af at bruge systemet.
2. Reaktionstid
Når en tester ønsker at finde ud af mere om det ydelsesniveau, som brugeren oplever, er svartiden et af de vigtigste aspekter at tage hensyn til. Dette henviser til den tid, det tager softwaren at udføre en opgave, efter at brugeren har indtastet en prompt, og længere svartider viser, at programmet er relativt ineffektivt. Længere svartider giver anledning til bekymring, da brugerne kan miste tålmodigheden med en applikation, der tager for lang tid.
3. Brugertilfredshed
De fleste målinger fokuserer på rene tal, der genereres af softwarepakken og testprogrammet i en test, men nogle målinger fokuserer på holdninger.
Hvis en virksomhed f.eks. gennemfører en betatest med 1000 testere, kan den indsamle data om antallet af tilfredse personer og omsætte det til en procentdel. Dette er en yderst nyttig måling at have til rådighed ved afslutningen af en cyklus, idet en højere grad af brugertilfredshed viser, at flere mennesker nyder programmet og indikerer, at det er mere sandsynligt, at det vil klare sig godt i fremtiden.
Bedste værktøjer til Black Box-testning
Black box-testning er en form for testning, som i høj grad er afhængig af at have værktøjer til rådighed, både til automatisering af din black box-testning og til organisering af de oplysninger, du får fra dine test.
Ved at bruge den rigtige kombination af værktøjer kan du og dit team arbejde langt mere effektivt og opbygge mere effektive processer i hele kvalitetssikringsafdelingen.
Se nogle af de bedste værktøjer til black box-testning nedenfor og lær, hvordan de kan hjælpe dig med at trives:
5 bedste gratis værktøjer til Black Box-testning
Små og nye virksomheder, som f.eks. uafhængige udviklere, har ikke et stort budget at arbejde med, når de udvikler deres software. Dette kan medføre en række udfordringer, herunder at finde de rigtige værktøjer at arbejde med.
Nedenstående er nogle af de bedste gratis værktøjer, som uafhængige udviklere, der ønsker at forbedre deres arbejdsgange med et begrænset budget, kan få adgang til:
1. ZAPTEST GRATIS UDGAVE
Den gratis udgave af ZAPTEST er den perfekte introduktion til automatisering af softwaretest. Dette værktøj er specielt designet til at understøtte automatisering af alle opgaver og hjælper dig med at arbejde hurtigere og mere effektivt, uanset hvilken opgave du udfører.
ZAPTEST’s gratis version indeholder en enorm mængde funktioner til at understøtte automatisering af enhver applikation… 1SCRIPT implementering på tværs af browser, enhed, applikation og parallel udførelse er en af de tilgængelige funktioner.
2. JIRA
Gratis udgaver af JIRA er ideelle værktøjer til at notere fejl, tilføje detaljer til dem i tickets og prioritere dem, når du kommunikerer med et udviklingsteam.
Men i stedet for at være en alt-i-én automatiseringshjælp er den udelukkende specialiseret i projektstyringssiden af testprocessen.
3. Selenium IDE
Dette er en open source-app, der optager og afspiller testautomatisering, og er et godt værktøj til at se, hvad en automatiseringsplatform ser, når den gennemfører en test.
En fejl ved Selenium er den relative mangel på avancerede funktioner som f.eks. integration af automatiserede opgaver på tværs af platforme.
4. AutoHotkey
AutoHotkey er et helt gratis og open source scriptsprog til Windows, som hjælper brugerne med at oprette scripts i forskellige størrelser, der udfører en række opgaver efter indtastning af et enkelt tastetryk.
AutoHotkey er godt til automatisering af enkle opgaver, men kan begynde at få problemer med større scripts og automatiseringskrav.
5. Appium
Dette er et værktøj, der primært er fremragende til automatisering af iOS-applikationer, og det er et ideelt program til at bruge, når du ønsker at forbedre kvaliteten af dine mobilapplikationer.
Den største ulempe ved Appium er, at du er begrænset til et meget lille udvalg af produkter, hvilket reducerer dit tilgængelige marked betydeligt.
De 5 bedste værktøjer til testning af virksomheders Black Box-test
Gratis værktøjer er alle gode og rare, men virksomheder og store virksomheder har brug for flere funktioner for at kunne teste deres software grundigt. Heldigvis har nogle af de bedste værktøjer til black box-testning i virksomheder omfattende funktionalitet og hjælper virksomheder med at få et betydeligt afkast af deres investeringer i deres kvalitetssikringsprocesser.
Nogle af de ideelle værktøjer til black box-testning i virksomheder, som du bør overveje at investere i, omfatter:
1. ZAPTEST ENTERPRISE EDITION
Enterprise-udgaven af ZAPTEST er et af de mest betydningsfulde automatiseringsværktøjer på markedet og kan give op til 10x afkast af investeringen i dit produkt.
Funktioner som f.eks. adgang til en fuldtidsansat ZAP-ekspert som en fjernstyret del af dit team og ubegrænsede licenser sikrer, at du kan implementere blackbox-testautomatisering uden behov for en stejl indlæringskurve og til en fast pris, uanset hvor hurtigt du vokser.
2. TestRail
TestRail er en platform, der fokuserer på realtidstest med det formål at forbinde dine test med en sammenhængende projektstyringsplatform. Mens dette er ideelt til centralisering af dit team management-arbejde, er automatiseringsfunktionerne langt fra perfekte til et udviklingsteam, der ønsker at lægge stor vægt på automatiserede tests.
3. Opkey
Opkey er en platform, der fokuserer på automatisering uden kode, hvilket betyder, at folk uden teknisk viden kan begynde at automatisere deres testtjenester.
En af de største fejl ved Opkey er manglen på et aktivt fællesskab omkring softwaren, hvilket kan give dig en følelse af at være relativt strandet, når du forsøger at automatisere på en måde, der er ny for dig.
4. Perfecto
Perfecto er et værktøj, der fokuserer på at hjælpe brugerne med at automatisere mobilapplikationer uden alvorlige problemer, der fungerer på en lang række enheder og fokuserer på end-to-end testarbejde.
Applikationen kører dog på rigtige enheder i stedet for virtuelle maskiner, hvilket tilføjer endnu en stor omkostning til det, der allerede er et relativt dyrt testværktøj til begrænsede platforme.
5. JIRA Enterprise
Ud over at færdiggøre automatiseringssiden af testning er projektstyring fortsat vigtig, og det er her JIRA kommer ind i billedet. Enterprise JIRA har mere lagerplads og giver flere brugere adgang til platformen, men kan skabe potentiel forvirring med behovet for skræddersyede tilladelser og adgang for hver enkelt bruger. Det tager meget administrativ tid at gennemføre dette.
Hvornår skal du bruge
Enterprise vs. Freemium Black Box-værktøjer?
Til at begynde med vil de fleste virksomheder bruge freemium black box-værktøjer. Dette giver mening ud fra et økonomisk synspunkt, da ingen intelligent virksomhed ønsker at investere i et produkt, som den ikke forstår fuldt ud, uanset om det er fra et projektledelses- eller automatiseringsperspektiv.
Freemium-værktøjer omfatter ikke kun helt gratis apps, men kan også omfatte gratis versioner af virksomhedsprodukter, som en virksomhed bruger, når den skal lære at implementere værktøjet i sine processer.
Det ideelle tidspunkt for en organisation til at opdatere sit valg af værktøj til en enterprise-udgave er, når virksomheden begynder at opleve gnidninger i sine testprocesser på grund af det gratis værktøj. Uanset om der er tale om et gratis værktøj, der kun tilbyder et udvalgt antal licenser eller et antal tests, bør du i det øjeblik, du begynder at opleve ineffektivitet i dine processer som følge af dine testværktøjer, skifte til en virksomhedsversion, der opfylder alle dine behov.
Tjekliste, tips og tricks til Black box-testning
Da black box-testning er en meget kompleks testmetode med mange muligheder for at opbygge din viden om en softwarepakke, er der nogle få ting, som du skal kigge efter.
Nogle vigtige tips og tricks, som du bør medtage i din tjekliste for black box-testning, er bl.a:
– Forståelse af opgaven
Før du begynder at lægge planer for testning, skal du sikre dig, at du forstår den bredere briefing for testperioden. Dette omfatter at forstå softwaren så godt som muligt og lære præcis, hvad det er meningen, at du skal teste.
– Korrekturlæs test case
Prøv at få alle, der er involveret i testningen, til at vurdere de testcases, som du bruger i black box-testning. Jo flere øjne, der ser testcasen før implementeringen, jo større chance har du for at eliminere eventuelle fejl.
– Opstille en liste over de ting, der skal gøres
Den ikke-tekniske side af forberedelsen til black box-testning kan være lige så vigtig som den tekniske side. Når du planlægger, skal du oprette en sammenhængende liste over de ting, der skal gøres, og som angiver, hvem der tester hvilken del af softwaren på hvilket tidspunkt. Det mindsker både forvirring, potentiel udbrændthed og forsinkelser, fordi andre opgaver tager overhånd.
– Registrer resultaterne med det samme
Registrer alle de resultater, som en test genererer, med det samme. Hvis du venter for længe med manuelle tests, kan du huske problemerne forkert, så ved at tage øjeblikkelige noter øges nøjagtigheden betydeligt.
– Kontakt med udviklere
Diskuter din tidsramme og strategi for testning med udviklerne, så de forstår, hvad der sker, og hvornår de kan forvente at arbejde på nye opdateringer. Det indebærer bl.a., at der skal fastlægges klare processer, som afdelingerne kommunikerer med hinanden efter.
– Data, der kan bruges til handling
Når du skriver en rapport, skal du sikre dig, at alle de data, du giver udvikleren, er brugbare. Det hjælper teamet med at udvikle et produkt, der reagerer på dets problemer, i stedet for at en udvikler ikke forstår de ændringer, han skal foretage.
– Forstå dine prioriteter
Som testteam er din prioritet i sidste ende at sikre, at virksomheden leverer et produkt af høj kvalitet til sine brugere. Hvis det tager lidt længere tid end forventet at teste, skal du huske, at det er en værdifuld udveksling for den øgede kvalitet, som kunden oplever.
– Kend hierarkiet
I en ideel udviklingsvirksomhed befinder udviklere og testere sig på samme niveau i hierarkiet og har lige stor indflydelse på den måde, softwaren vokser på. Forstå hvordan hierarkiet er i din organisation, og sørg for, at alle forstår værdien af gode tests.
– Opbevar konsekvent dokumentation
Opbevar kopier af alle de data og rapporter, som du genererer i forbindelse med din testning. Du kan følge de ændringer i appen, som testteamet er ansvarlig for, og du kan se tilbage på gamle fejl for at se, om de gentages i fremtidige udgaver.
Konklusion
Black box-testning er i sidste ende en af de vigtigste dele af softwaretestprocessen. Det hjælper virksomheder med at sikre, at det, de leverer, er af den højest mulige standard og udnytter et perspektivskifte til at give en unik indsigt i den måde, som en applikation opfattes og implementeres af en ekstern bruger.
Enhver virksomhed, der ikke tilføjer black box-testning, både automatiseret og manuel, til sine processer, går glip af en mulighed for at forbedre kvaliteten af sin applikation betydeligt. Test intelligent, og du vil høste frugterne, når dine kunder får adgang til dit produkt.
Ofte stillede spørgsmål og ressourcer
Uanset hvor meget du ved om black box-testning, har du måske flere spørgsmål og ønsker at uddybe din forståelse af metoden. Se vores ofte stillede spørgsmål nedenfor for at få mere at vide om black box-testning og få adgang til en række ressourcer, der kan fortælle dig mere om metoden.
1. De bedste kurser i Black box Test Automation
Der findes flere kurser i automatisering af black box-test, som du kan følge, og som hver især hjælper folk med at opnå en anden teststandard.
Nogle af de mest anerkendte kurser i black box-testning, der er tilgængelige, omfatter:
– “Black-box og white-box test” af Coursera
– “Black-Box Software Testing-serien” af BBST
– “Introduktion til Black Box Software Testing Techniques” af Udemy
– “Software Automation Testing” af London School of Emerging Technology
– “Tre vigtige black box-testteknikker” af Udemy
2. Hvad er de 5 vigtigste interviewspørgsmål om Black box Testing?
Softwaretestning er et meget konkurrencepræget område, hvor der er mange ansøgere til hver eneste ledige stilling. Hvis du bliver interviewet til en stilling inden for black box-testning, er dette nogle af de spørgsmål, som du måske skal forberede dig på at besvare i et interview:
– Hvilken erfaring har du med at arbejde med black box-testning?
– Hvad er de vigtigste forskelle mellem black box- og white box-testning?
– Har du erfaring med softwareautomatisering i dine tidligere stillinger?
– Kan du fortælle os, hvornår du har oplevet udfordringer på din arbejdsplads, og hvordan du overvandt dem?
– Hvad tror du, at fremtiden for black box-testning er, og hvordan passer dine færdigheder til en langsigtet karriere inden for softwaretestning?
3. De bedste Youtube-vejledninger om Black Box Testing
YouTube er en af de vigtigste læringsressourcer for folk, der ønsker at forbedre deres færdigheder inden for softwaretestning, da det er en gratis kilde til information, som du kan bruge til at udvikle din teknik.
Nogle af de bedste tutorials, som du kan se, når du skal lære at lave black box-test, er:
– “Introduktion til Black og White Box-testning – Georgia Tech – Softwareudviklingsprocessen” af Udacity
– “Black Box and Glass Box Testing” af MIT OpenCourseWare
– “7 Black Box Testing-teknikker, som enhver QA bør kende” af The Testing Academy
– “Black Box Testing | Hvad er Black Box Testing | Lær Black Box Testing” af Intellipaat
– “Hvad er White vs. Grey vs. Black Box Testing?” af ITProTV
4. Hvordan vedligeholder man Black Box Tests?
Vedligeholdelse af black box-tests, uanset om der er tale om manuelle eller automatiserede tests, er et spørgsmål om at være opmærksom på testene undervejs og konstant at søge at rette op på problemer, hvis der er problemer.
Dette indebærer at sikre, at alle testcases kører som forventet hver eneste gang, og at automatiserede værktøjer gennemgår alle de korrekte trin. Gør dette så ofte som muligt for at forhindre, at dine standarder falder, da en velholdt black box-test giver de mest præcise resultater.
5. Bedste bøger om Black Box Testing
Mens black box-testning og softwaretestning som helhed er et område i konstant udvikling, er der flere bøger, som stadig er relevante og giver en masse indsigt i, hvordan du kan forbedre dit testarbejde.
Nogle af de bedste bøger om black box-testning er bl.a:
– “Black Box Testing”: Teknikker til funktionel test af software og systemer” af Boris Beizer
– “Softwaretestning: Principper og praksis” af Srinivasan Desikan, Gopalaswamy Ramesh
– “Essentials of Software Testing” af Ralf Bierig, Stephen Brown, Edgar Galván
– “Introduktion til softwaretestning” af Paul Ammann og Jeff Offutt
