Hur bygger man en automatiserad kvalitetssäkringsprocess som både är effektiv på att hitta defekter (fel, buggar eller annan oönskad funktionalitet) och samtidigt har en så hög automatiseringsgrad som möjligt?
Naturligtvis kan man ha samma approach som förr i tiden, men automatisera det som tidigare var manuellt arbete. Många känner till testautomatiseringsverktyg som exempelvis Selenium eller WebDriver som interagerar med systemet som testas, via det grafiska användargränssnittet.
Men detta är inte det mest effektiva angreppssättet. Vi vet sedan årtionden att ju tidigare i utvecklingskedjan vi hittar mjukvarudefekter desto billigare och snabbare går de att åtgärda. Trenden idag, framför allt i organisationer som har kommit långt med Continuouos Integration och Continuous Delivery, är att bygga en automatiserad pipeline med olika testaktiviteter.
Det här möjliggör att identifiera och åtgärda defekter tidigare, närmare införingspunkten. Framför allt möjliggör detta att förhindra att defekter uppstår. Ibland kallas dessa automatiserade testaktiviteter ”defektavstötande”.
Det är självklart att den billigaste och snabbast fixade defekten är den som aldrig behöver hittas eller fixas, eftersom den aldrig har införts från början. Här har QA en stor uppgift i att reducera antalet defekter som från början införs.
Jag tänkte i en kort artikelserie innehållande nedan delar beskriva hur man kan införa en sådan automatiserad test-pipeline och fokusera på de aktiviteter som kan göras så tidigt som möjligt i implementationsarbetet.
Vad är det som kännetecknar ”bra” kod och hur jobbar man med att försäkra sig om att koden teamet skriver verkligen är ren och prydlig?
Man använder verktyg som skannar och analyserar själva källkoden. Vilka skanners och vilka typer av defekter eller allmänt dåliga eller olämpliga kodkonstruktioner bör vi leta efter?
När det gäller att hitta fel så slår ingenting en människas kritiska tänkande, intelligens och omdöme. Hur får man in detta så tidigt som möjligt i en delivery pipeline?
De flesta vet hur bra det är att ha enhetstester men hur ser bra enhetstester ut? Hur många ska man skriva och vad är lagom mängd kod som dessa bör täcka?
Automatiserade tester är en förutsättning för Continuous Integration och Continuous Delivery och dessa arbetssätt anammas av fler och fler organisationer. Men kanske upplever du att steget från att skriva automatiserade tester till att implementera tester för en hel Continuous Delivery Pipeline känns stort? I denna serie av artiklar kommer du bland annat få med dig hur automatiserade tester fungerar i den världen, med olika nivåer av tester och kvalitetskontroller och vilka typer av defekter som kan detekteras var.