Har du någon gång varit med om att du som testare har hittat en riktigt skön bugg? En riktig goding som varit tillfredställande komplicerad att rota fram men som är tillräckligt allvarlig för att sänka hela releasen. Låt oss anta att du har gjort det och, uppfylld av vetskapen av att ha gjort ett riktigt bra jobb, ivrigt registrerar den i ditt ärendehanteringssystem. Efter att ha lagt till komplett med steg-för-steg beskrivning, skärmdump, prioritet, testområde och sjuttio-elva andra saker enligt IEEE 829 känner du dig riktigt nöjd med dig själv. Det är då som du får ett surt ”rejected” tillbaka med enda kommentaren - ”works as designed”. I det läget ligger det nära till hands att förbanna den tröga utvecklaren och påbörja en rejäl bug advocacy. Följaktligen går du på ännu hårdare, återupprepar buggen tio gånger, beskriver i ännu mer detalj, gör en konsekvensanalys, en egen spontan felsökning och är nittio procent säker på vad som orsakar felet! Tio minuter efter återöppnat ärende kommer svaret - ”rejected, works for me”. Vad är det som händer? Det är ju helt absurt? Hatar utvecklare testare?
Det påstås ofta att utvecklare och testare bör hålla sig lite ifrån varandra. Hålla sig på sin egen kant av utvecklingsspektrat och inte beblanda sig alltför mycket. T.ex. står det i ISTQB att ”oberoende leder till bättre tester”. Andra vill dra detta ännu längre och ser till att placera utvecklare och testare i skilda rum, avdelningar, kontor eller kontinenter. Allt detta leder till färre kommunikationsmöjligheter, mindre sammarbete och sämre tester. Hur ska man kunna testa något om man inte vet hur det är uppbyggt och är tänkt att fungera? Ju mer information som finns tillgänglig, desto mer relevanta tester kan göras. Vi pratar mycket om vikten av testtäckning samt spårbarhet mellan krav och testfall. Är inte den tekniska systemlösningen en lika viktig komponent i teststrategin? Istället ser vi att testare och utvecklare hålls isär rent organisatoriskt. De placeras ofta i olika avdelningar under olika chefer. Formella processer stryper kommunikationen och tvingar folk att skriva ärenden i ärendehanteringssystem, istället för att prata med varandra. Jag anser att detta leder till sämre arbetsklimat, dåliga leveranser och dålig systemkvalité.
De flesta utvecklare tycker om att få sin kod testad. Seriösa utvecklare, som vill göra ett bra jobb, tycker det är jobbigt när deras misstag eller missuppfattningar får konsekvenser i produktion. De flesta utvecklare uppskattar en klåfingrig testare som utmanar lösningen med kreativa testuppslag. En testare som har en god uppfattning om kravbilden, verksamhetens förutsättningar och produktionssituationen. En testare som kliar på eventuella sårskorpor tills de blöder och tillsammans med utvecklaren kan bygga en bra lösning. Seriösa utvecklare ser det som en utmaning och en hjälp i arbetet. Testare kan vara extremt nyttig för utvecklaren. Testaren har ofta unik kunskap om hur systemlösningen används i praktiken och kan se hur en isolerad funktion passar ihop med systemet i övrigt. Testaren vet hur kraven ska tolkas, vad som krävs av lösningen i en produktionssituation, vilka som använder systemet och hur. Utvecklare kan ge testaren viktig kunskap om hur lösningen är byggd, vilka svagheter som finns och hur lösningen kan testas. Utvecklaren kan också göra jobbet lättare för testaren genom att bygga in testbarhet, hjälpa med testmiljöer, testverktyg och liknande.
Men ofta ser det ju inte ut så. Testaren får ofta sin leverans långt efter att utvecklaren är klar. Ett specifikt krav kanske inte testas förrän en månad efter funktionen har utvecklats. När fel uppstår ska alltså utvecklaren sätta sig in i och svara för fel som gjordes för en månad sedan. För att förvärra det hela så utgår testaren från en kravspecifikation som kanske är uppemot ett år gammal. Mycket är irrelevant, medan annat har ändrats under resans gång, viktiga saker kan ha tillkommit och det finns säkert ett antal viktiga krav som inte beskrivits alls. Inte konstigt att utvecklare har en tendens att bli irriterade när testare dyker upp med sina fynd. Lyckligtvis kan man ganska enkelt förändra den här situationen.
Sök upp de utvecklare som bygger koden som du ska testa. Ta med dig glass eller bullar och be att få sitta tillsammans med dem. Luncha med dem, lyssna och delta i deras diskussioner. Se till att bli upptagen i gruppen och börja arbeta tillsammans.
Om du är en teknisk testare så ta reda på vilka verktyg utvecklarna använder och lär dig använda dem. Ta reda på hur du kan komma igång och testa effektivt redan i början av utvecklingsperioden istället för att vänta på kompletta leveranser mot slutet. Skaffa en egen utvecklingsmiljö och ta emot de senaste kodversionerna. Använd utforskande testning för att komma igång snabbt utan testfall. Undersök möjligheter att effektivisera tester genom smarta tekniska lösningar och automatisering.
Om du är en verksamhetsorienterad testare, ta reda på så mycket som möjligt om verksamheten och den omgivning som systemlösningen ska verka i. Bli en expert på hur kraven ska tolkas, vilka outsagda krav som finns och vad verksamheten förväntar sig.
