Hvordan kan man være sikker på at et en feature virker. Nemt tænker man jeg prøver bare at køre mit software, og tjekker om den omtalte feature virker som forventet. Når man har to features så gør man det samme og per induktion kan man sige at hvis det virker med de eksisterende features og det virker hvis man tilføjer en feature mere, så virker det HELE jo.
Men for at man kan fortage denne antagelser så antager man at det at tilføje en feature ikke ødelægger noget for tidligere fungerende features.
I en normal projektplan, hvor man givet et eller andet udgangs punkt tilføjer ny funktionalitet betyder det at hvis man vil tilføje ny funktionalitet, men samtidig vil være sikker på at man ikke ødelægger de features som allerede er fungerende i systemet, at man ikke må røre ved den kode som allerede kører (faktisk hvis man skal køre det helt ud, må man ikke engang kalde eksisterende kode, da man ikke kan garantere at de nye kald ikke rammer nogle edge-cases (kant scenarier?!?) i koden som ødelægger det for andre.
Normalt ender man altid med genbruge metoder og klasser, det er jo hele ideen, at genbruge og udvide hist og her. Men når man er færdig med at lave en ny feature så skal man verificere at man har et produkt i samme tilstand som før man startede med at tilføje features, skal alt testes igen, for ellers kan man ikke være sikker på at det hele kører. Mange firmaer forsøger at løse dette ved at have en stor QA afdeling, som sidder parat efter hver udviklings cyklus til at test det hele og rapportere fejl og mangler, selvom mange vil påstå at så er det allerede for sent.
Men i princippet er det jo ikke nok at blot gøre det når man er færdig med in iteration, man skal faktisk starte forfra hver gang der er en fejl rettelse, for hvem ved om lige netop den rettelse ødelægger andre ting. For at dette skal kunne lade sig gøre i praksis, kan man ikke rigtig gøre andet end at køre en slags waterfall, da man skal lave udvikling også skal man stoppe mens man tester det hele.
På mindre skala kan samme problematik gentages, to udviklere sidder og arbejder på to forskellige ting, men i virkeligheden kan de sidde de og ødelægger hinandens kode, hvis man er rigtig uheldig, kan man risikere at de kan begge sidde og ødelægge hinandens kode, således at når de begge råber “Jeg er færrrdiggg” så er der ikke andet end exceptions tilbage.
Alle må vel sidde og tænke på det her tidspunkt at det er åbenlyst at dette ikke er den rigtige måde at gøre tingene på. IKK!?!? Men man bliver ofte overrasket!
Løsningen i mine øjne er automatiseret tests. Det betyder ikke at man skal fyre alle QA personer for de er rigtig gode til at lave modspil til udviklerne, eller at man skal have så mange tests at man kan garantere at alt virker efter hvert test run. Det vil sige det kommer selvfølgelig an på hvor dedikerede testene er. Men hvis man prøver at tage et pragmatisk syn på det, vil alle da kunne blive enige om at hvis man nu bare tager et solskins scenarie for hver feature som man implementere, og laver en automatiseret test for hver af dem, så er man langt hen af vejen lige så godt stillet som efter en dags manual testing efter checklister. Der ud over er der også brug for manual testing, men de kan blive koncentrerer om sjovere scenarier.
Mange bruger argumentet at det er for ressource krævende at have automatiseret tests, men regnestykket går hurtigt i minus at lade være med at have dem, hvis du begynder at regne på hvor meget tid udviklere bruger på at debugge fejl introduceret af kollegaer og rette fejl.
Men i sidste ende handler det om tillid, hvad kan man gøre for at få mest tillid til at noget virker?
Edge case: hjørnetilfælde