Håndtering af Kvalitet i projekter

Det er nok ikke overraskende, at nogle af de mest almindelige problemer, der fører til projektsvigt, er kvalitetsproblemer.

I vores interessenters øjne er lav kvalitet lig med lav værdi. Så hvis noget ikke lever op til forventningerne, er det tydeligvis blevet gjort dårligt og vil sandsynligvis ikke opfylde sin tilsigtede funktion.

Men hvad er kvalitet egentlig? Og hvordan kan vi være sikre på, at vi alle arbejder mod den samme definition af kvalitet? Det er vores fokus for i dag.

Her er, hvad du vil lære i dagens indlæg:

• Du vil lære, hvordan du definerer kvalitet for dit projekt og hvordan du uddanner dine interessenter om, hvad kvalitet er.
• Vi vil vise dig, hvordan du håndterer kvalitet ved hjælp af en kvalitetsstyringsplan.
• Du vil lære forskellige testmetoder og hvornår du skal bruge dem i dit projekt.
• Vi vil gennemgå, hvordan du håndterer fejlrapportering og sporingsprocessen.
• Og du vil lære, hvordan du balancerer kvalitet med omkostningerne ved kvalitet, så dit projekt forbliver på sporet.

Forberedelse

Noget der hurtigt kan underminere et projekt, er projektets kvalitet.

Efter at dine interessenter har set en god strategi, og løsningen er smukt udarbejdet på papir, vil de være spændte på at se det endelige resultat. Men hvis det, de ser under udviklingen, ikke er helt klar eller er fyldt med fejl og problemer, kan det skabe alle slags udfordringer.

Pludselig begynder de at gå i panik. De troede, de kunne stole på os, men nu er deres håb og drømme knust – de begynder at tro, at alt, hvad de ser, er helt forkert!

Derfor er det virkelig vigtigt, at vi finder eventuelle problemer, før vores eksterne interessenter gør det! For at gøre det skal vi håndtere kvalitet.

Hvad er Kvalitet?

Først lad os tage et skridt tilbage og se på, hvad vi mener med kvalitet.

Teknisk set er kvalitet et mål for, hvor godt dine projektoutput opfylder deres krav og dine projektstandarder inden for de givne projektbegrænsninger. Med andre ord, for at være “høj kvalitet” skal de ting, dit projekt producerer, krydse alle boksene for det, der er aftalt, og de skal være i overensstemmelse med de standarder, du har lovet.

Men i den digitale verden er der helt klart meget mere på spil end blot denne tekniske definition. Faktisk er de to mest almindelige kvalitetsklager i den digitale verden: Hvorfor fungerer det ikke som Apple, Google, Uber osv.? Og Hvorfor fungerer det ikke på min Blackberry, Internet Explorer 6 eller mit smart-tv?

Lad os tale om det første i et stykke tid: “Hvorfor fungerer det ikke som en anden populær app i en anden branche?”. Dette er et klassisk eksempel på flydende forventninger, og der er ingen reel måde at undgå det på.

Flydende forventninger betyder, at hvis brugere har nydt en problemfri og sammenhængende brugeroplevelse i en anden kontekst eller branche, vil disse forventninger blive anvendt på enhver brugeroplevelse.

Et eksempel på dette er, når brugere bliver frustrerede over, at de ikke kan bruge deres ansigt til at logge ind på et firmaintranet, som de gør i deres forbrugerbankapp. Dette er en komplicerende faktor, når det kommer til at præsentere vores arbejde, fordi folk, der ikke er tæt på projektet, måske anser det for at være af lav kvalitet, selvom det fuldt ud opfylder de krav, der er aftalt.

Det andet eksempel er noget af det modsatte: “Hvorfor fungerer din løsning ikke på en ældre enhed eller browser?” Dette er mere relateret til forventningen om, at en app eller digital oplevelse af høj kvalitet skal fungere på alle web-aktiverede teknologier, der nogensinde er lavet.

Det er selvfølgelig usandt: de fleste mennesker har eksempler i deres daglige liv, hvor en ny opdatering gør deres gamle teknologi straks forældet. Måske er det en ny version af iOS, der ikke fungerer på en ældre iPhone. Eller måske er det en webapp, der ikke fungerer, medmindre du bruger den nyeste og mest sikre version af en webkit-browser.

I begge eksempler gør det ikke den ældre teknologi af lavere kvalitet.

Så lad os vende tilbage til det oprindelige spørgsmål: hvad er kvalitet? Kvalitet er noget, der er besluttet og aftalt. Men i den digitale verden er det også noget, hvor forventninger skal håndteres omhyggeligt og proaktivt gennem stærk kommunikation og løbende uddannelse.

Hvordan håndtere man Kvalitet?

Men det kan være vanskeligt at få folk til at være enige om kvalitet.

Der er en hel række faktorer som enhedsspecifikationer, browserversioner og typer, forbindelseshastighed og plugins, der påvirker, hvordan – og hvor godt – en slutbruger vil interagere med det, vi har lavet. Og mange af disse ting er uden for vores kontrol.

Så vi håndterer kvalitet ikke for at sikre, at det, vi bygger, er helt fejlfrit. Vi gør det for at give tillid til, at produktet vil fungere i de fleste vigtige tilfælde. Men der er absolut ingen garanti for, at det vil fungere i alle tilfælde.

Faktisk vil det i mange tilfælde ikke fungere korrekt. Og det er okay!

Vi skal sætte forventningerne korrekt. Vi skal hjælpe vores interessenter med at forstå, at teknologien er evolutionær. Browsere og enheder ændrer sig så hurtigt, at bare fordi en app fungerer en dag, kan den tænkeligt bare stoppe med at fungere den næste dag på grund af en ny opdatering. Testning er nødvendig, men resultaterne er specifikke for det tidspunkt og den teknologi.

Løftet om testning er at sikre et vist kvalitetsniveau med hensyn til det, der frigives. Så vi skal blive enige med kunden eller sponsoren om kvalitetsniveauet – baseret på risiko, budget og tidsplan – og teste til det niveau. Testning er en væsentlig del af processen, men det garanterer ikke perfektion.

Når vi tænker på kvalitet, skal vi acceptere, at de ting, vi bygger, skal være optimeret til et specifikt publikum. Det betyder, at visse browsere og enheder vil blive prioriteret over andre. Det er for dyrt at understøtte alt fuldt ud – og det ville også tage alt for lang tid!

Så ja, håndtering af kvalitet har nogle begrænsninger.

Håndtering af kvalitet har fire komponenter:

• Kvalitetsplanlægning
• Kvalitetssikring
• Kvalitetskontrol
• og Kvalitetsoptimering

Kvalitetsplanlægning

Vi starter med at lave en plan omkring kvalitet. Det er her, vi etablerer rammerne for at beskrive kvalitet og begynder at definere, hvad kvalitet er for vores projekt. Det er også her, vi bliver enige om processen og kontrolforanstaltningerne for at sikre, at kvaliteten opretholdes gennem hele projektet.

Denne plan kan tage mange former, men kort sagt bør din kvalitetsplan beskrive de elementer af kvalitet, der er relevante for projektet, og processen, hvormed kvaliteten vil blive dokumenteret og kommunikeret. Det er i bund og grund rammerne for kvalitet og kvalitetsstyring.

Generelt er dette ikke noget, projektledere skaber. Ofte oprettes det af en testingeniør på kvalitets- eller testteamet i samarbejde med ingeniør- eller udviklingsteamene. Men det er stadig vigtigt at kende som projektleder, så du kan bruge det til at begynde at uddanne og håndtere forventninger med interessenter.

Kvalitetsplanen vil sandsynligvis omfatte svar på spørgsmålene:

• Hvad er vores kvalitetsstandarder for dette projekt?
• Hvordan vil kvaliteten blive målt?
• Hvor vil kvaliteten blive målt?
• Hvordan vil kvaliteten blive kommunikeret?

Med hensyn til standarder kan din kvalitetsstyringsplan beskrive de vigtigste kvalitetsområder, der skal overvejes. I nogle tilfælde kan disse simpelthen være et udvalg af, hvad vi kalder “kvalitetsattributter” – karakteristika ved løsningen eller systemet, der er vigtige for at opnå kvalitet og projektmålene samlet set.

Eksempler på kvalitetsattributter for digitale løsninger inkluderer: ydeevne, tilgængelighed, brugervenlighed, vedligeholdelsesevne, kompatibilitet, sikkerhed, brugervenlighed, skalerbarhed, interoperabilitet og pålidelighed.

Derefter med hensyn til, hvordan og hvor kvaliteten vil blive målt, kan din kvalitetsstyringsplan omfatte en teststrategi. Teststrategien ville skitsere de typer test, der vil blive udført, processen, hvormed testningen vil finde sted, og hvor testningen vil finde sted.

For eksempel kan teststrategien udarbejde en plan for at bruge manuelle og automatiserede enhedstest, integrationstest, funktionstest og visuel test under udviklingen sammen med en kombination af mere periodiske penetrationstest, tilgængelighedstest og brugeraccepttest.

Det kan også angive, at der er brug for et separat testmiljø, hvor committed kode kontinuerligt integreres i kodebasen, og hvor indhold og den passende sidekonfiguration efterligner, hvad løsningen vil have i produktion, så testningen kan være præcis.

Kvalitetssikring & Kvalitetskontrol

De næste komponenter er kvalitetssikring og kvalitetskontrol. Hvis jeg skal være ærlig, bliver disse to udtryk brugt ombytteligt i de fleste digitale projekter, men de er filosofisk set ret forskellige.

Kvalitetssikring er den mere proaktive side af kvalitet: det handler om at tage skridt til at sikre, at processerne, der er skitseret i kvalitetsstyringsplanen, bliver fulgt, så kvalitet opnås det meste af tiden, og at de fleste fejl *forebygges*.

Kvalitetssikring kan omfatte proaktive skridt som at sikre, at test er opsat til at ske, når de skal, kontrollere at testtilfælde bliver oprettet, før en funktion går i udvikling, og håndhæve dokumentationen og kommunikationen af kvalitet baseret på planen.

På den anden side er kvalitetskontrol den reaktive side af kvalitet. Det er den del, hvor vi tester og fanger de fejl, der måske er smuttet igennem revnerne. Når vi har bygget noget færdigt, kan vi begynde at teste ved hjælp af vores testtilfælde, som skitserer specifikke ting, der skal verificeres under testningen. Disse testtilfælde giver en ramme for kontrol af funktionerne og funktionaliteten.

Normalt udfører vi testning i to separate trin – intern test for at sikre kvalitet og brugeraccepttest (UAT) med vores kunde eller sponsor for at få godkendelse af det, vi har bygget.

Kvalitetsoptimering

Den sidste komponent af projektkvalitet er kvalitetsoptimering, eller kvalitetsforbedring. Kort sagt handler det om kontinuerligt at forbedre dine kvalitetssystemer og -processer.

Hvis en kvalitetsrevision afslører, at en bestemt type fejl fortsætter med at smutte igennem revnerne, er det sandsynligvis værd at gennemgå og finjustere processen for at prøve at fange dem gennem kvalitetssikring i stedet for at finde dem i testning og derefter skulle rette dem.

Ligeledes, hvis interessenter finder ud af, at de har brug for at vide mere – eller måske har brug for at høre mindre! – om projektkvalitet, kan det være værd at genoverveje måden, kvaliteten kommunikeres på. Dette kan virke selvforklarende og indlysende, men det er alt for ofte, at vi blot holder os til planen uden at finde måder at gøre det bedre på!

Så det er komponenterne af kvalitet: Kvalitet kræver planlægning for at definere parametrene omkring kvalitet, hvordan den vil blive opnået, og hvordan den vil blive kommunikeret. Derefter stræber en kombination af kvalitetssikringsprocesser og kvalitetskontrolaktiviteter proaktivt og reaktivt efter at opnå det aftalte kvalitetsniveau.

Og endelig bør kvalitetsstyringsprocessen regelmæssigt gennemgås og finjusteres eller optimeres, hvor det er nødvendigt.

Typer af Test

Når det kommer til testning, er der ingen mangel på metoder, og det er en god idé for dig som projektleder at have en forståelse af dem. Vi vil ikke være i stand til at dække alle typer test, så vi vil fokusere på nogle få almindelige.

De to mest kendte måder at teste en digital løsning på er funktionel testning og visuel testning. Funktionelt vil vi teste, om det, vi har bygget, gør, hvad det skal? Interagerer det med vores andre systemer, som det skal? Opfylder det de systemspecifikationer, vi har defineret? Håndterer det den forventede glade vej såvel som negative tests eller undtagelser?

Og visuelt spørger vi os selv: ser dette ud, som det var designet? Render det korrekt på de browsere, vi understøtter? Og giver brugerflowet mening?

I mange tilfælde er dette en manuel indsats. Men nogle testteams kan også bruge automatiserede værktøjer, der tester hele flows og kører visuelle kontrol uden menneskelig indgriben.

Det er indrømmet en indledende investering, men det kan ofte ende med at spare værdifuld tid og budget på større, mere komplekse projekter, hvor testning og gen-testning af funktionalitet og visuelle elementer kan være meget dyrt.

Ud over funktionel og visuel testning kan dine projekter også kræve andre typer testning. Dette kan inkludere enhedstestning, integrationstestning, præstationstestning, tilgængelighedstestning, sikkerhedstestning og katastrofegendannelsestestning. Vi vil dække nogle af disse mere detaljeret i andre indlæg, men lad mig give dig en hurtig smagsprøve:

• Enhedstestning handler om at teste et individuelt stykke kode for at sikre, at det fungerer som det skal i isolation. For eksempel kan du have et krav om, at kun stærke adgangskoder, der inkluderer et specialtegn, er tilladt. Så dit testteam kan skrive en automatiseret enhedstest for at kontrollere, at svage adgangskoder afvises.
• Integrationstestning handler om at teste, hvordan ny kode fungerer med resten af løsningen. Dette er typisk en automatiseret test drevet af værktøjer som Git og Jenkins, så ny kode kun kan integreres, hvis den ikke skaber konflikter med den eksisterende kodebase.
• Regressionstestning handler om at sikre, at en ny ændring i løsningen ikke har ødelagt en anden funktion, der fungerede fint før. Dette kan gøres manuelt eller gennem automation eller en kombination af begge.
• Præstationstestning handler om at teste hastighed og kapacitet. For eksempel kan du have et ikke-funktionelt krav om, at alle skærme eller sider i løsningen skal indlæses inden for 7 sekunder 90% af tiden. Du kan også have et krav om, at løsningen understøtter 500 samtidige brugere.
• Tilgængelighedstestning handler om at skabe inkluderende oplevelser for dine brugere. For eksempel kan du have et krav om, at hele løsningen skal overholde W3C’s WCAG2-standard på AA-niveau. Så dit team kan være nødt til at teste alle funktioner for at sikre, at de ikke bruger farvekombinationer, der er ubehagelige for brugere med farveblindhed, og at de kan betjenes ved hjælp af hjælpemidler som en skærmlæser.
• Sikkerhedstestning handler om at finde og rette sikkerhedssårbarheder. Du kan have et krav om, at din løsning opfylder sikkerhedsbedste praksis som OWASP top 10. Så dit team kan køre penetrationstest for at tjekke for sårbarheder og bagdøre, der kunne udnyttes af ondsindede aktører for at få systemadgang eller adgang til følsomme data.
• Katastrofegendannelsestestning handler om at sikre, at din løsning kan gendannes efter en katastrofal hændelse. For eksempel kan du have et krav om, at løsningen kan bringes tilbage online inden for 24 timer efter et systemnedbrud. Så dine teams og interessenter kan beslutte at køre en øvelse, der simulerer et systemnedbrud for at teste failover-systemer og procedurer.

Fejlrapportering og Sporing

Lad os tale om, hvad der sker, når fejl opdages. Når funktioner og funktionalitet testes, vil fejl – eller bugs – uundgåeligt opstå. Det er en sikkerhed.

Men optagelse af fejl kan være vanskeligt! Som udvikler er der ikke noget mere frustrerende end at blive fortalt, at noget ikke fungerer, men ikke at blive fortalt, hvordan man gengiver problemet. Hvis du ikke kan replikere problemet, så er der ingen måde, du vil være i stand til at rette det!

Som minimum, når du rapporterer en fejl – uanset om det er dig, testteamet eller en anden interessent – skal der være nok detaljer til at kunne replikere problemet. Der bør være en fuld beskrivelse, der inkluderer URL’en, hvor du fandt den, trin til at gengive det, et skærmbillede, den forventede adfærd og den faktiske adfærd.

Som projektleder er det i din bedste interesse at uddanne interessenter og testere og regelmæssigt kontrollere, at de følger processen for rapportering af fejl. Ellers vil du se al slags tid gå tabt med frem og tilbage informationsindsamlingssamtaler.

Hvis det er nødvendigt, opret en skabelon i din projektstyringssoftware eller en formular i dit billetsystem, der har et felt for hver nøgleinformation, der er nødvendig for, at en udvikler kan gengive fejlen.

Så kan enhver selv-rapportere problemer korrekt … inklusive dig!

Balancering af Kvalitetens Omkostninger

Testning kan være en lang og trættende proces. Det kan også være virkelig dyrt. Dine testteams er grundige, kritiske og kan ofte være perfektionister af natur. Derfor er de så gode til deres job!

Og dine projektinteressenter vil aldrig stoppe med at ønske ændringer. Så der vil aldrig være mangel på fejl og anmodninger om ændringer.

Nøglen til testningens succes er at vide, hvornår noget er godt nok til at gå live. Sørg for at balancere prioriteter, tid og budget – kvalitet er fantastisk, men det kan være dyrt!

Som PM vil det være din opgave at vurdere alle fejl, der kommer fra testprocessen, og beslutte, hvad der skal gøres ved dem. Du skal beslutte, er dette virkelig en fejl eller ej? Kan vi ignorere det, eller skal vi rette det? Og hvis vi skal rette det, hvor placerer vi det i vores prioritetsliste?

Vi skal derefter spore fejlen for at blive rettet og derefter tjekke den igen, indtil den går igennem. Så sørg for, at du tænker på og håndterer kvalitet fra starten af projektet.

Involver QA-teamet tidligt og skriv testtilfælde baseret på kravene *før* du begynder at bygge de funktioner.

Vær klar over, hvilke enheder eller platforme du understøtter, og uddan dine interessenter, så de ved, hvad der er omfattet, og hvad der ikke er. Sørg for, at eventuelle fejl er dokumenteret korrekt, og at du sorterer de rigtige fejl til at blive rettet. Og hold den positive stemning oppe, sikring af kvalitet kan være en energidrænende tid!

Opsummering

Du ved nu, hvilken indvirkning kvalitetsproblemer kan have på dit projekt, og hvordan du navigerer dem. Interessenter skal uddannes og være enige om kvalitetsbegrebet, så deres forventninger styres.

Du har også nu en tankegang for at tilgå kvalitet. Digital teknologi ændrer sig altid, og vores mål er ikke at opnå perfektion på alle platforme. Du lærte, hvordan du håndterer kvalitet ved hjælp af en kvalitetsstyringsplan, robust kvalitetssikring og kvalitetskontrol og kontinuerlig kvalitetsoptimering.

Du lærte om forskellige typer testmetoder og hvor du måske skal bruge dem i dit projekt. Du lærte, hvordan du håndterer fejlrapportering og sporingsprocessen.

Og du lærte, hvordan du balancerer kvalitet med kvalitetens omkostninger. Du skal prioritere fejlrettelser for at holde dit projekt på sporet.