Blogg

Test löser allt!

Test anses ofta kunna lösa alla problem. Det är enkelt att föreställa sig att om man har test med i ett projekt löser sig allt och blir perfekt. Kvalitén blir enastående och kunden får exakt vad denne vill ha. Helt automatiskt. Tänk om det hade varit så underbart!

Artikelverktyg:

I mjukvarutest ska lösningen visa att den motsvarar ställda krav. Test kan inte bli bättre än det underlag som finns. Testfall skrivs bland annat baserat på kravspecifikationen/user stories. Testaren utgår ifrån att dessa är uppdaterade och korrekta. Tester körs. Om det då är så att man gjort ändringar utan att anteckna dessa och då kodar efter ändringarna, genererar detta, med största sannolikhet, buggar. Helt i onödan.

Problem kan lätt uppstå om kunden ändrar sig och dessa ändringar inte antecknas, vilket är lätt hänt. Det faller mellan stolarna, man hinner inte ändra. Det är mycket att ändra. Kommunikationen kan vara bristfällig så testaren får inte reda på ändringarna utan arbetar på och fortsätter testa efter en kravspecifikation som inte är uppdaterad.

Vidare kan man också lätt föreställa sig att om man testat, kan inga buggar uppstå alls. Test ska ju testa allting. Så är dock inte fallet. Det är omöjligt att testa precis allting. Det övergripande målet är inte att hitta varje bugg som finns, utan att avslöja situationer som kan inverka negativt hos kunden, på användbarheten och/eller underhållet.

Viktigt är också att tänka på att test inte bara ska utföras, det måste ske på rätt miljöer (så produktionslik miljö som möjligt vid systemtest och acceptanstest) och skiljt från utvecklarna. Att t.ex. utföra systemtest på en utvecklingsmiljö där utvecklarna regelbundet arbetar med sin kod, gör att tidigare testning kan bli ogiltig. Om utvecklaren ändrar i koden på ett ställe, kan det dyka upp buggar i andra funktioner och även sådant man redan testat en gång tidigare. I ett projekt är det därför viktigt att frysa utveckling och ge tid för test. Mot slutet av projektet är det en god idé att göra ett mer omfattande systemtest och baserat på risk/prioritet testa de olika flödena. Sedan släpps kunden på för sina användaracceptanstester.

En aspekt är också att det är viktigt att man har en gemensam samsyn och målsättning kring test. Testaren/testledaren har sin bild, projektledaren sin bild och utvecklaren en tredje. Det kan skapas konflikter om dessa inte jackas ihop. Därför bör test diskuteras tidigt i projektet för att reda ut eventuella frågetecken, som exempelvis: hur ska test bedrivas, vad är test, vad är inte test, vad förväntas av alla i projektet, vad ska vi testa, vad ska vi inte testa, vad gör vi om utvecklingen drar ut på tiden, vilka viktiga datum har vi, vilka miljöer har vi, hur ser miljöerna ut? Då är det viktigt att allt kommer upp till ytan och att alla får säga sitt kring hur testprocessen ska se ut.

Slutligen är det viktigaste att se på testarbetet (ja, hela projektet egentligen) som något man faktiskt gör tillsammans, även om man har olika roller och arbetsuppgifter. Test rör oss alla på något sätt i slutändan.

Är du nyfiken på hur vi arbetar med test i våra projekt? Kontakta vår Försäljningschef Filip Berglund så berättar han gärna mer om hur vi kan hjälpa dig med test och andra digitala utmaningar.

0 kommentarer

Skriv kommentar