Effektiv QA bedste praksis

Arbejde på Effektiv Jeg har deltaget i mere end 30 forskellige projekter. Alle af dem var helt forskellige: web og mobil, store og små, komplicerede og enkle. Vi byggede projekter fra bunden, tilføjede nye funktioner og vedligeholdt eksisterende projekter.

Der var mange vanskelige sager i kvalitetssikringsprocessen, test, styring og udvikling, og nu føles det som om vores team bestod Per Aspera ad Astra.

I øjeblikket føles det som om der ikke blev gjort noget specielt, men når vi sammenligner Effektiv nu og da kan jeg sige, at vi gjorde et enormt skridt fremad. Der blev foretaget analyser af fejl, teamets ønsker og forslag, jeg har udarbejdet følgende liste over bedste fremgangsmåder til kvalitetssikring. Formålet med denne liste er at hjælpe unge teams med at forstå, hvad der kan være nyttigt for dem uden at bruge meget tid på forskning. For nogle af erfarne kan dette se ud som ny opfindelse af cykel :) Here we go!

Forstå forretningsmæssige mål, og gør acceptkriterier klare

Dette er hjørnestenen i et projekt og bør afklares inden udviklingen starter. Et projektteam skal forstå, hvad der skal gøres, hvem der er målgruppen / funktionskonsumenten, og hvordan man kan forstå, at der ikke er noget tilbage at gøre.

Forståelse af forretningsmæssige mål vil hjælpe dig med at besvare spørgsmål som 'Hvad skal vi gøre, og hvem bruger det?'. Acceptkriterier hjælper dig med at forstå, at en funktion opfylder forretningsmæssige mål eller ej. Fra min erfaring kan jeg sige, at forretningsmæssige mål og acceptkriterier skal bekræftes af en klient eller kundens repræsentant. Baseret på klare og gennemsigtige forretningsmål og acceptkriterier kan dygtige outsourcing-softwareudviklingsvirksomheder desuden opgradere en forretningsidé eller foreslå en bedre løsning.

CI / CD - Kontinuerlig integration / kontinuerlig implementering

Lyder velkendt… er det ikke? En af de mest populære ting i den nuværende softwareudvikling, hvorfra QA-teamets perspektiv er den største fordel, at vi let kan få et build med de nyeste funktioner eller rettelser.

I løbet af udviklingscyklussen kan vores udviklingsteam have en masse gitgrene relateret til forskellige funktioner, men kun en gren indeholder den mest opdaterede kode. CI-værktøj kontrollerer denne gren, og når koden ændres, opretter den en ny build og deler den til den specificerede distributionstjeneste.

Vi har prøvet TeamCity og Jenkins. Begge disse er gode værktøjer. TeamCity har smukkere brugergrænseflade, men Jenkins er helt gratis, så vi har valgt Jenkins.

Applikationsdistributionstjenester

Generelt ser det ud som intet særligt, men under hætten giver kontinuerlig integration med afstemte applikationsdistributionstjenester dig den nemmeste og hurtigste måde at få den nyeste bygning på en hvilken som helst testenhed eller -miljø. Det er ok at uploade build via USB til en enhed. Men hvad nu hvis du har brug for at kontrollere bygningen ved hjælp af 10 forskellige enheder? Det er pointen.

Til mobilprojekter har vi prøvet et par forskellige tjenester som HockeyApp, Beta by fabric (ex-Crashlytics), Test Flight af Apple, Play Console fra Google. Der er selvfølgelig flere tjenester, men disse er blevet valgt som de mest populære. Nu stemmer jeg for Testflyvning og playkonsol på grund af disse tjenester er fleksible, understøtter interne og eksterne testers funktioner og officielle tjenester fra Apple og Google og kun fra testers e-mail kræves. Den eneste begrænsning her er, at du har brug for Apple og Google-udviklerkonto, der koster 25 $ for Google (engangsbetaling) og 99 $ for Apple (årligt).

Andre tjenester som HockeyApp eller Beta har nogle vanskeligheder med at tilføje nye testere til projektet, især på iOS. På grund af Apple-sikkerhedspleje, fra testere, er det påkrævet at levere UDID af deres enheder til udvikleren, og udvikleren skal tilføje disse UDID'er til projektet. Da vi deler dev builds med vores klienter (som normalt har en masse forskellige enheder og ændrer dem regelmæssigt) blev vi alle trætte af denne UDID-indsamlingsaktivitet. Derfor har vi valgt Testflyvning og playkonsol.

For webprojekter er alt lidt enklere, fordi vi bruger et specielt testmiljø, der opdateres af CI-værktøjet, når udviklingsgrenen ændres.

Test af dokumentation

Gennem årene har vores QA-team fundet fire mest værdifulde dokumenter, der kan deles med klienter eller interessenter:

  • Understøttede platforme
  • Testplan
  • Testtilfælde / tjeklister
  • Udgivelses noter

Understøttede platforme-dokument skal udarbejdes så tidligt som muligt, når et projekt begynder og underskrives med klienten. Det skal indeholde oplysninger om understøttede hardware- og softwarekonfigurationer, kendte begrænsninger og begrænsninger. Det er også baseret på målgruppenheder, fordi enhedsmarkederne er forskellige i forskellige lande.

Når vi underskriver dette med vores klienter, garanterer vi, at den første version af et produkt fungerer perfekt på listede konfigurationer, ud over at vi lader vores klienter vide, at produktet kan arbejde på de andre konfigurationer, men nogle problemer kan vises. Og hvis produktet og målgruppen vokser, vil vi være i stand til at analysere og implementere support til yderligere platforme. I fremtiden vil dette dokument give os mulighed for at fokusere på specificerede platforme i udvikling og bugfix.

Testplanen skal også udarbejdes i starten og deles med kunden. Dette dokument skal indeholde alle typer test, der vil blive brugt under produktudvikling med et beskrevet formål for hver type. I testplanen skal QA-teamet beslutte, hvad de bruger til test, testtilfælde eller checklister. Normalt afhænger det af projektets varighed og funktionel kompleksitet. Understøttede platforme bør også knyttes til testplanen. Og endelig skal testplanen indeholde oplysninger om planlagte testaktiviteter efter datoer, der følger efter projektudviklingen og frigivelsestidslinjen.

Testcases / checklister er en påkrævet ting for hvert projekt. Selvfølgelig tager det nogen tid at forberede disse leverancer, og det kan tage yderligere tid at støtte denne dokumentation, men det giver dig en slags træstamme, og ved hjælp af denne bagagerum kan du nemt forestille dig og oprette nye testscenarier bare ved at tilføje grene til din bagagerum. Senere kan du dele forberedte testsager med UAT-teamet på klientsiden eller med betatestere eller endda vise testtilfælde til projektudviklingsholdet. Dev-team kan bruge testsager som en del af kravene, og det kan virkelig hjælpe dem med at undgå nogle problemer.

Hos Effective har vi prøvet en masse TMS (Test Management System) og valgt TestRail som et af de mest populære, tilpasses, hurtige og praktiske værktøjer til test af sager og testhåndtering. Brug af TestRail giver os mulighed for let at holde testsager og tjeklister ajour. For os passer dette værktøj godt, men der er stadig mange alternativer. Det vigtigste tip her er at bruge den rigtige TMS og ikke bruge Google Docs og regneark til testcases og testlogfiler :)

Release Notes er det dokument, der er udarbejdet af vores QA-team til kunder og indeholder faktiske oplysninger om projektet. Hvilke funktioner blev afsluttet i den bestemte sprint, hvad der stadig er i gang, hvad der er kendte problemer, hvor og hvordan demo build kan downloades. Vi forbereder altid udgivelsesnotater efter sprint og ved udgivelse. Det giver vores kunder yderligere gennemsigtighed omkring udviklingsfremskridt.

Exploratory Testing

Den sidste ting, der aldrig bør glemmes, er Exploratory Testing. Hovedformålet med denne test er at forstå dit produkt bedre og se på det fra en brugers perspektiv. Ved at kombinere efterforskende og scriptet test (ved scriptetesting mener jeg testtilfælde eller brug af tjeklister), kombinere testers og brugers opfattelse af produktet og huske forretningsmæssige mål, kan du gøre det produkt, du arbejder på, så perfekt som muligt.

Som en del af efterforskningstest bruger vi også metode til sværmtest. Ved hjælp af Test Flight and Play Console inviterer vi eksterne testere, der normalt er effektive medarbejdere, der er ude af projektet og kan fungere som beta-testere. Dette giver os mulighed for at få et produktoversigt fra en brugers perspektiv og være opmærksom på brugervenlighed.

Effektiv QA-oversigt over bedste praksis:

  • Forstå forretningsmål
  • Gør acceptkriterier tydelige
  • Kend dine understøttede platforme
  • Forbered testplan
  • Brug testcases / checklister
  • Brug kontinuerlig integration + kontinuerlig implementering
  • Hold testtilfælde / tjeklister opdateret
  • Del udgivelsesnotater med dine klienter
  • Glem aldrig Exploratory Testing

Tak for at have læst! Du er velkommen til at kommentere, hvis du vil vide mere, være uenig eller har spørgsmål :)