Testar utan en QA-resurs

Är det möjligt att göra tillräcklig testning av programvara med bara utvecklare och BA och ingen QA-resurs?

Det finns två tankeskolor här:

En är tron ​​på att alla buggar är relaterade till kod och att om du har en mycket hög procentsats av testtäckning för din kod, ska du i princip inte ha några buggar. Som testare vet vi alla att detta inte är sant!


Den andra tron ​​är att du gör tillräcklig enhetstestning och också gör integration, system- och användaracceptansprovning för att säkerställa att applikationen är lämplig för ändamålet. Även om detta verkar vara en bra idé, är det inte praktiskt eftersom utvecklare behöver komma åt nya funktioner!

Båda dessa övertygelser är extrema.


Att testa din egen kod kan vara effektiv, för som utvecklare vet du vilken del av din kod som är komplex och mer sannolikt att vara buggy, så du skulle fokusera på det området. Att veta att det inte finns mer QA är du också tvungen att skriva kvalitetskod, som en utvecklare uttrycker det

I mitt första jobb hade jag inte QA. Det var upp till mig att se till att min egen kod var tillräckligt kvalitet innan jag släppte den, och den aspekten skrämde mig nog så att jag lärde mig att skriva kvalitetskod (vilket i princip betyder att du testar din egen kod noggrant och gör din egen QA).

Är utvecklare testa tillräckligt?

Jag tror att det är ett bra steg att uppmuntra mjukvaruutvecklare att ta äganderätten till kvaliteten på sin egen kod, men när du testar din egen kod kommer du mer än troligt att missa en hel klasser av buggar.

Du kan vara mycket effektiv på att fånga de typer av buggar du kan tänka dig, men det är alltid de enklaste buggarna att fånga i första hand. Testerna du skriver själv kommer aldrig att göra ett bra jobb med att fånga fel i dina antaganden om vad koden ska göra, vilka typer av ingångar den behöver hantera, etc. Att fånga sådana typer av konceptuella buggar kräver verkligen kontradiktorisk testning från någon som inte är börjar inte från samma uppsättning antaganden.


Att arbeta som en automationstester innebar att jag var tvungen att fokusera på att testa och koda båda samtidigt, och jag kämpade ofta! När jag kodade testerna ville jag bara se till att koden körs och få testet att klara, jag var inte så bekymrad över vad det faktiska testet var eftersom mitt huvudfokus var på kodning. Snart insåg jag att jag automatiserade värdelösa tester som inte gav något värde.

En annan viktig punkt att notera är att enhetstestning bara fångar programmeringsfel i kod, enhetstestning upptäcker inte fel i applikationen, vilket betyder att om du har 100% kodtäckning betyder det inte en bug-fri applikation.

Även om det alltid är nödvändigt att testa din egen kod via enhetstester innan den skickas vidare, är det också viktigt att ha den andra uppsättningen ögon från en beteendemässig synvinkel. Ofta är vi för nära koden för att verkligen slå den ordentligt och utsätta den för riktigt konstiga kantfall, och bra QA-människor är ganska skickliga på att göra det. Att testa på systemnivå av en annan uppsättning användare som testare kan ofta avslöja mycket intressanta buggar.

Det handlar inte bara om funktionstestning. Vi måste bry oss och oroa oss för prestandatestning, säkerhetstestning, användbarhetstestning, etc, vilket krävs om vi vill släppa programvara av hög kvalitet.


Varför behöver vi fortfarande QA?

Testare ses ibland som flaskhals till hela leveransrörledningen. Skulle det inte vara så mycket bättre om allt automatiserades utan manuellt ingripande och inga testare lyfter fel för att stoppa utsläppet?

En del av problemet när testare ses som flaskhalsar är på grund av bristande äganderätt till kvalitet hos utvecklare. Om alla verkligen kände att de var ansvariga för produktens kvalitet (inte bara kod), arbetar utvecklare och testare mot samma mål.

Testare kan para ihop med utvecklare för att skriva bättre enhetstester och utvecklare kan hjälpa testare med att skriva automatiserade kontroller och också utbilda testare om applikationens arkitektur så att de kan designa bra test för att hitta de områden som mest troligt kommer att bryta under systemtestning.

I en ideal värld testare bör inte hitta några defekter, eller åtminstone triviella defekter. När det finns ett 'QA-team' vars uppgift är att hitta defekter är det frestande för utvecklare att bara lita på att testare hittar alla defekter medan utvecklarna fokuserar på utveckling och kodning.


Medan Yahoos steg att eliminera QA och Testing-avdelningen uppmuntrar utvecklare att ta äganderätt till produktens kvalitet är det fortfarande inte tillräckligt bra för att säkerställa en robust produkt. Med detta sagt, även med ett team av testare kan du fortfarande inte garantera en felfri programvara, men det som är viktigt är att se till att programvaran ses från olika synvinklar och från olika perspektiv och det är där den verkliga fördelen med att ha en bra QA-funktion (i motsats till QA-teamet) kommer.

Testare kan se till att utvecklare följer bästa kvalitetssäkringsmetoder och hjälper till med tekniska och affärstestdesigner för att identifiera de mest kritiska buggarna innan de släpper programvara.