QA - Quality Assurance vs Quality Assistance

den 25 augusti 2015

Vi på Creuna brinner för god kvalitet och vi har genom åren utvecklat vår QA-grupp både i antalet personer och hur vi arbetar i teamen. QA är idag en självklar del i varje team och vi arbetar hela tiden för att ständigt förbättra våra arbetssätt inom teamet gällande QA. I det sammanhanget vill vi sätta en annan översättning på förkortningen QA – Från Quality Assurance till Quality Assistance.

Varför vill vi det? Jo, det vill jag berätta nedan:

Vårt jobb är att stötta utvecklingsprojektet att skapa funktioner med kvalitet. Vi finns med för att ”lätta på bördan” i kvalitetsarbetet, inte ”skapa börda” för utvecklingsprojektet. Att leverera en produkt med bra kvalitet är en gemensam målsättning för hela teamet, så kvalitetsarbetet har ett gemensamt ägarskap.

Att sitta mitt i teamet gör att vi finns med som extra ögon och öron i det löpande utvecklingsarbetet. Det finns alltid ett värde att se på samma sak ur olika synvinklar. Dessutom är det både roligt och effektivt att jobba tillsammans i ett utvecklingsprojekt med mycket kommunikation.

Vi finns som en servicefunktion för alla kompetenser inom teamet och jobbar för att teamet ska leverera kvalitet i alla led för projektet. Vi testar t ex redan på ’skiss-stadiet’ (se blogginlägg ) eller på levererad kod så snart vi kan då vi vet att ett tätt samarbete mellan design, utveckling och test borgar för snabb återkoppling, snabbare leveranser och att utvecklingsprojektet kan fortsätta i önskad takt.

Om testerna inte kan utföras till fullo är vi alltid intresserade av att genomföra tester på delar av systemet för att på det sättet snabbt få igenom en funktion från utveckling till leverans. Det kan t ex handla om att testa en helt fristående funktion utan ”sitt sammanhang” för att sedan när hela systemflödet kring funktionen är klar testa funktionen igen.

Det är viktigt att vi alltid försöker lära oss produkten snabbt och använda den kunskapen för att på ett kreativt sätt kunna genomföra bra och verklighetstrogna tester. Att ’vikta’ vad som är viktigare än något annat är en naturlig del av planeringen av testerna. Centralt i den ’viktningen’ är att tänka utifrån kund och/eller utvecklingsperspektiv.

För att få feedback på den testdesign vi använder för vi ständigt en dialog med teamet och övriga i QA-gruppen kring hur vi testar vilket oftast leder till att vi tillsammans kommer fram till fler testscenarios och bra lösningar som gör produkten än mer ”lätt-testad”.

Vi jobbar för ett gemensamt ägandeskap av de automatiserade testerna. Detta då de testerna ytterst ”ägs” av produkten och inte av den/de som byggt testerna. Detta gör att det på ett naturligt sätt blir en förändring av både kod och tester i de fall produkten förändras. QA-arbetet utvecklar vi tillsammans med hela teamet i och med att vi alla har samma gemensamma mål – Webb med god kvalitet.

Kundens acceptanstestarbete är en viktig del av vårt arbete och som bygger både kundrelation och förtroende. Att ha en tät dialog med kunden under projektets gång och när det är dags för acceptanstest och lansering gör att införandet av produkten/funktionen oftast blir både smidig och av hög kvalitet.

Allt detta sammantaget visar att om vi assisterar teamet ger det effektivare leveranser av högre kvalitet och dessutom ger det ett roligare teamarbete med bättre teamkänsla. Om vi istället hade som utgångspunkt att hela tiden försäkra att teamet gör sitt jobb så skulle inte teamet stärkas av det och då skulle de effekterna jag beskriver ovan till stor del utebli.