Effektiv QA beste praksis

Jobber på Effektiv Jeg har deltatt i mer enn 30 forskjellige prosjekter. Alle av dem var helt forskjellige: nett og mobil, store og små, kompliserte og enkle. Vi bygde prosjekter fra grunnen av, la til nye funksjoner og vedlikeholdt eksisterende prosjekter.

Det var mange vanskelige saker i kvalitetssikringsprosess, testing, styring og utvikling, og nå føles det som om teamet vårt passerte Per Aspera ad Astra.

For øyeblikket føles det som om det ikke ble gjort noe spesielt, men når vi sammenligner Effektivt nå og da, kan jeg si at vi gjorde et enormt skritt fremover. Det ble gjort feil, teamønsker og forslag. Jeg har utarbeidet følgende liste over beste fremgangsmåter for kvalitetssikring. Hensikten med denne listen er å hjelpe unge team til å forstå hva som kan være nyttig for dem uten å bruke mye tid på forskning. For noen av erfarne kan dette se ut som ny oppfinnelse av sykkel :) Here we go!

Forstå forretningsmessige mål og gjør akseptkriterier klare

Dette er hjørnesteinen i et prosjekt og bør avklares før utviklingen starter. Et prosjektgruppe må forstå hva som skal gjøres, hvem som er målgruppe / funksjonsforbruker, og hvordan man skal forstå det er ingenting igjen å gjøre.

Å forstå forretningsmessige mål vil hjelpe deg å svare på spørsmål som ‘Hva trenger vi å gjøre og hvem skal bruke det?’. Akseptkriterier vil hjelpe deg å forstå at en funksjon oppfyller forretningsmessige mål eller ikke. Ut fra min erfaring kan jeg si at forretningsmessige mål og akseptkriterier skal bekreftes av en klient eller kundens representant. Basert på klare og transparente forretningsmål og akseptkriterier, kan dyktige outsourcing-programvareutviklingsselskaper også oppgradere en forretningsidé eller foreslå en bedre løsning.

CI / CD - Kontinuerlig integrering / kontinuerlig distribusjon

Høres kjent ut ... er det ikke? Noe av de mest spennende tingene i den nåværende programvareutviklingen, fra QA-teamets perspektiv, er at vi enkelt kan få et bygg med de nyeste funksjonene eller rettelsene.

I løpet av utviklingssyklusen kan vårt utviklingsteam ha mange gitgrener relatert til forskjellige funksjoner, men bare en gren inneholder den mest oppdaterte koden. CI-verktøyet sjekker denne grenen, og når koden endres, oppretter den en ny bygging og deler den til spesifisert distribusjonstjeneste.

Vi har prøvd TeamCity og Jenkins. Begge disse er gode verktøy. TeamCity har vakrere brukergrensesnitt, men Jenkins er helt gratis, så vi har valgt Jenkins.

Distribusjonstjenester for applikasjoner

Generelt ser det ikke ut som noe spesielt, men under panseret gir kontinuerlig integrasjon med avstemte applikasjonsdistribusjonstjenester deg den enkleste og raskeste måten å få den siste bygningen på alle testenheter eller omgivelser du ønsker. Det er ok å laste opp bygg via USB til en enhet. Men hva hvis du trenger å sjekke byggingen ved å bruke 10 forskjellige enheter? Det er poenget.

For mobilprosjekter har vi prøvd noen få forskjellige tjenester som HockeyApp, Beta by fabric (ex-Crashlytics), Test Flight av Apple, Play Console av Google. Selvfølgelig er det flere tjenester, men disse er valgt som de mest populære. Nå stemmer jeg for Test Flight og Play Console på grunn av disse tjenestene er fleksible, støtte for interne og eksterne testers funksjoner og offisielle tjenester fra Apple og Google, og bare fra tester e-post er nødvendig. Den eneste begrensningen her er at du trenger Apple og Google-utviklerkonto som koster 25 $ for Google (engangsbetaling) og 99 $ for Apple (årlig).

Andre tjenester som HockeyApp eller Beta har noen vanskeligheter med å legge til nye testere til prosjektet, spesielt på iOS. På grunn av Apple sikkerhetspleie, fra testere, er det påkrevd å gi UDID av enhetene sine til utvikleren, og utvikleren må legge til disse UDID-ene til prosjektet. Siden vi deler dev builds med kundene våre (som vanligvis har mange forskjellige enheter og endrer dem regelmessig), ble vi alle lei av denne UDID-samlingen. Derfor har vi valgt testflyging og spillkonsoll.

For nettprosjekter er alt litt enklere fordi vi bruker et spesielt testmiljø som blir oppdatert av CI-verktøyet når utviklingsgrenen endres.

Testing av dokumentasjon

Gjennom årene fant QA-teamet ut fire mest verdifulle dokumenter som kan deles med klienter eller interessenter:

  • Støttede plattformer
  • Testplan
  • Testtilfeller / sjekklister
  • Utgivelsesnotater

Dokument som støttes plattformer, bør utarbeides så tidlig som mulig når et prosjekt begynner og signeres med klienten. Den skal inneholde informasjon om støttet maskinvare- og programvarekonfigurasjoner, kjente begrensninger og begrensninger. Det er også basert på målgruppenheter fordi enhetsmarkedene er forskjellige i forskjellige land.

Ved å signere dette med våre kunder, garanterer vi at den første versjonen av et produkt fungerer perfekt på listede konfigurasjoner, i tillegg til at vi lar kundene våre vite at produktet kan fungere på de andre konfigurasjonene, men noen problemer kan vises. Og hvis produktet og målgruppen vil vokse, vil vi kunne analysere og implementere ekstra plattformsstøtte. I fremtiden vil dette dokumentet tillate oss å fokusere på spesifiserte plattformer i utvikling og bugfix.

Testplanen skal også utarbeides i begynnelsen og deles med kunden. Dette dokumentet skal inneholde alle typer tester som vil bli brukt under produktutvikling med et beskrevet formål for hver type. I testplanen skal QA-teamet bestemme hva de bruker til testing, testtilfeller eller sjekklister. Vanligvis avhenger det av prosjektets varighet og funksjonelle kompleksitet. Støttede plattformer bør også knyttes til testplanen. Og til slutt, testplanen skal inneholde informasjon om planlagte testaktiviteter etter datoer etter prosjektutvikling og utgivelsestidslinje.

Testfall / sjekklister er en nødvendig ting for hvert prosjekt. Selvfølgelig tar det litt tid å klargjøre disse leveransene, og det kan ta ekstra tid å støtte denne dokumentasjonen, men det gir deg en slags trestamme, og ved å bruke denne bagasjerommet kan du enkelt forestille deg og lage nye testscenarier bare ved å legge grener til bagasjerommet ditt. Senere kan du dele forberedte testfall med UAT-teamet på klientens side eller med betatestere eller til og med vise testtilfeller til prosjektutviklingsteamet. Dev-teamet kan bruke testtilfeller som en del av kravene, og det kan virkelig hjelpe dem å unngå noen problemer.

Hos Effective har vi prøvd mye TMS (Test Management System) og valgte TestRail som et av de mest populære, tilpassbare, raske og praktiske verktøyene for test case management og test management. Ved å bruke TestRail kan vi enkelt holde testtilfeller og sjekklister oppdaterte. For oss passer dette verktøyet bra, men det er fremdeles mange alternativer. Hovedtipset her er å bruke riktig TMS og ikke bruke Google Dokumenter og Regneark for testtilfeller og testlogger :)

Release Notes er dokumentet utarbeidet av vårt QA-team for kunder og som inneholder faktisk informasjon om prosjektet. Hvilke funksjoner ble fullført i den aktuelle sprinten, hva som fremdeles pågår, hva som er kjente problemer, hvor og hvordan demobygget kan lastes ned. Vi utarbeider alltid utgivelsesnotater etter sprint og ved utgivelse. Det gir våre kunder ytterligere åpenhet om utviklingsfremdrift.

Utforskende tester

Den siste tingen som aldri bør glemmes er Exploratory Testing. Hovedhensikten med denne testingen er å forstå produktet ditt bedre og se på det fra brukerens perspektiv. Ved å kombinere undersøkende og skriptetesting (med skriptetesting mener jeg testtilfeller eller bruk av sjekklister), kombinere testers og brukers oppfatning av produktet og huske forretningsmessige mål kan du gjøre produktet du jobber med, så perfekt som mulig.

Som en del av utforskende tester bruker vi også tilnærming til svermtesting. Ved å bruke Test Flight and Play Console inviterer vi eksterne testere som vanligvis er Effektive ansatte som er ute av prosjektet og kan fungere som betatestere. Dette lar oss få en produktoversikt fra brukerens perspektiv og ta hensyn til brukervennlighet.

Effektiv QA sammendrag av beste praksis:

  • Forstå forretningsmål
  • Gjør akseptkriterier klare
  • Kjenn dine støttede plattformer
  • Utarbeide testplan
  • Bruk testtilfeller / sjekklister
  • Bruk kontinuerlig integrasjon + kontinuerlig distribusjon
  • Hold testtilfeller / sjekklister oppdatert
  • Del utgivelsesnotater med dine klienter
  • Glem aldri forklaringstesting

Takk for at du leste! Kommenter gjerne hvis du vil vite mer, er uenig eller har spørsmål :)