Meny

Exploratory Testing vs Scripted Testing: Who Wins?

exploratory testing vs scripted testing

Prova Vårt Instrument För Att Eliminera Problem

Verkliga fördelar med utforskande testning:

Traditionellt har mjukvarutestning varit en mycket stel aktivitet, men de senaste åren har det skett ett skift från skriptbaserad testning. Explorativ testning , som är mer kontextdrivet, har kommit fram. Det beror på att det ger testare mer frihet att utnyttja sina färdigheter och kunskaper, och det gör dem ansvariga för att optimera värdet av sitt eget arbete.

Exploratory Testing vs Scripted Testing

Inte alla säljs för värdet av utforskande testning. Den upplevda bristen på formalitet och betoning på personligt ansvar kan få larmklockor att ringa. Men denna oro bygger till stor del på en felaktig tolkning av undersökande testning. Det handlar inte om att kasta regler ut genom fönstret och testa slumpmässigt, det är faktiskt väldigt strukturerat och systematiskt. Och det är också mycket effektivt.

Skeptiker vill ha konkreta bevis på att det gör mer än att förbättra testarens moral. Därför bestämde vi oss för att genomföra en studie som skulle sätta kontextbaserade, utforskande tester direkt mot en manusbaserad testmetod. Resultaten var väldigt intressanta, som du ska ta reda på.

Vad du kommer att lära dig:

varför är standardgatewayen inte tillgänglig

Kontextbaserade (Exploratory Testing) vs Scripted Testing Teams

Två lag, två tillvägagångssätt:

Vi började med att dela upp testarna i två lag om tre. Testare i varje team hade samma jämförbara applikationskunskap. Samma definitioner för defekt svårighetsgrad (major, minor) etablerades för båda lagen. Båda lagen hade samma applikationsbyggnad levererat till sig. Ett team ('scripted') skulle tillämpa en traditionell scriptbaserad testmetod och det andra teamet ('exploratory') skulle anta en kontextdriven testmetod. Testaktiviteterna skulle delas in i två faser om tre dagar vardera.

Det manusbaserade teamet identifierade fem affärsflöden för att testa och genererade 15 testfall. Testfallet var begränsat, så testarna hade ingen frihet att utforska utanför manuskriptets gränser.

Det utforskande teamet skapade två visuella tankekartor , en som identifierade testtäckningen och testcharterna, och den andra som täcker produktkomponenter / moduler. Processen gav totalt 24 testcharter. De definierade stadgarna var på hög nivå och tillät kontextuell tolkning, vilket utvidgade testperioden för testarna.

Fas 1:

Skriptgruppen lyckades slutföra sex testfall under de tre tilldelade dagarna. De rapporterade sex stora brister under den tiden.

Det utforskande teamet lyckades genomföra 13 testsessioner från 30 minuter till 180 minuter vardera. De rapporterade 10 större brister och 5 mindre brister.

scripted vs exploratory testing 1

Intressant nog rapporterade det undersökande laget alla brister som det skriptlag hade rapporterat.

Fas 2:

Skriptgruppen lyckades slutföra 9 testfall den här gången. De rapporterade 10 större brister och 8 mindre defekter .

Det undersökande laget avslutade 18 sessioner. De rapporterade 14 större brister och 5 mindre defekter.

scripted vs exploratory testing 2

I fas 2 rapporterade det skriptgruppen två större och en mindre defekt som det undersökande teamet inte hittade, men det undersökande laget rapporterade tre större och en mindre defekt som det skriptlag inte rapporterade.

Detta tar inte hänsyn till de relativa komplexiteten i arbetsflöden som kan ha valts av testarna under dessa sessioner och testfallet, men vi kan ändå dra några intressanta slutsatser.

Vad betyder det?

Det verkar som att ett utforskande tillvägagångssätt och det ansvar och den flexibilitet det ger upphov till en effektivare testform. Det kan vara möjligt att täcka mer mark genom att utveckla och anpassa dina testcharter när testsessionerna utvecklas, baserat på vad som är vettigt i sammanhanget. Denna frihet saknas i skriptbaserad testning och det kan förhindra upptäckt av defekter.

hur ser jag en XML-fil

Att hålla fast vid skript skapar slitna vägar, och det är bara genom att avvika från de vägar som vi kommer att avslöja alla defekter. Som nämnts flera gånger av tanke-ledare inom testgemenskapen, 'Om du föreställer dig en produkt som ett fält av landminor och varje landmin är en defekt, är det ganska tydligt att det inte går att gå samma väg om och om igen. Allt.'

I slutändan var inget av dessa tillvägagångssätt perfekt, eftersom varje lag rapporterade brister som det andra laget inte identifierade, även om det utforskande laget rapporterade mer totalt sett.

Realistiskt kan detta innebära att rätt tillvägagångssätt, när det gäller att komma så nära 'minimala' defekter som möjligt, kommer att bli en blandning av de två. Men det finns många fördelar med kontextdriven strategi som talar till dess fördel. Det kräver mindre förberedelsetid, mindre dokumentation, identifierar problem tidigare och utmanar testare att använda analytiska färdigheter och deduktiva resonemang. De får en djupare och mer grundlig förståelse för produkten och fungerar verkligen som förespråkare för slutanvändaren.

Slutsats

Slutresultatet visar att utforskande testning leder till rapportering av fler defekter innan de tas i bruk, vilket resulterar i en bättre produkt levererad av teamet, och i slutändan mer nöjda / uppfyllda testare som alla är önskvärda resultat, hur du än tittar på det.

Om författaren

Mush Honda är QA Director på KMS-teknik , en leverantör av IT-tjänster över programvaruutvecklingen med kontor i Atlanta, GA och Ho Chi Minh City, Vietnam. Han var tidigare testare på Ernst & Young, Nexidia, Colibrium Partners och Connecture. KMS-tjänster inkluderar applikationshantering, testning, support, professionella tjänster och personalökning.

Håller du med? Skicka gärna dina kommentarer, frågor nedan.

PREV-handledning | NÄSTA självstudie # 4: Exploratory Testing with HP Sprinter

Rekommenderad läsning

^