Effectieve QA Best Practices

Werken bij Effective Ik heb deelgenomen aan meer dan 30 verschillende projecten. Ze waren allemaal heel anders: web en mobiel, groot en klein, ingewikkeld en eenvoudig. We bouwden nieuwe projecten, voegden nieuwe functies toe en onderhouden bestaande projecten.

Er waren veel lastige gevallen in kwaliteitsborging, testen, beheer en ontwikkeling en nu voelt het alsof ons team Per Aspera ad Astra heeft doorstaan.

Momenteel voelt het alsof er niets bijzonders is gedaan, maar af en toe vergelijken van Effectief kan ik zeggen dat we een enorme stap voorwaarts hebben gemaakt. Er zijn analysefouten gemaakt, teamwensen en suggesties, ik heb de volgende lijst met best practices opgesteld voor kwaliteitsborging. Het doel van deze lijst is om jonge teams te helpen begrijpen wat voor hen nuttig kan zijn zonder veel tijd aan onderzoek te besteden. Voor sommigen van ervaren, kan dit eruit zien als fietsre-uitvinding :) Hier gaan we!

Begrijp zakelijke doelen en maak acceptatiecriteria duidelijk

Dit is de hoeksteen van een project en moet worden verduidelijkt voordat de ontwikkeling begint. Een projectteam moet begrijpen wat er moet gebeuren, wie de doelgroep / consument is en hoe te begrijpen dat er niets meer te doen is.

Als u bedrijfsdoelen begrijpt, kunt u vragen beantwoorden als 'Wat moeten we doen en wie gebruikt het?'. Acceptatiecriteria helpen u te begrijpen of een functie aan zakelijke doelstellingen voldoet of niet. Uit mijn ervaring kan ik zeggen dat bedrijfsdoelstellingen en acceptatiecriteria moeten worden bevestigd door een klant of diens vertegenwoordiger. Op basis van duidelijke en transparante bedrijfsdoelstellingen en acceptatiecriteria kunnen vakkundige outsourcing-softwareontwikkelingsbedrijven een bedrijfsidee upgraden of een betere oplossing voorstellen.

CI / CD - Continuous Integration / Continuous Deployment

Klinkt bekend ... is het niet? Een van de trends in de huidige softwareontwikkeling, waarvan het belangrijkste voordeel vanuit het perspectief van het QA-team is dat we gemakkelijk een build kunnen maken met de nieuwste functies of oplossingen.

Tijdens de ontwikkelingscyclus kan ons ontwikkelingsteam veel git-branches hebben met betrekking tot verschillende functies, maar slechts één branch bevat de meest bijgewerkte code. CI-tool controleert deze tak en wanneer de code wordt gewijzigd, wordt een nieuwe build gemaakt en gedeeld met de opgegeven distributieservice.

We hebben TeamCity en Jenkins geprobeerd. Beide zijn geweldige hulpmiddelen. TeamCity heeft een mooiere gebruikersinterface, maar Jenkins is absoluut gratis, dus we hebben voor Jenkins gekozen.

Toepassingsdistributiediensten

Over het algemeen lijkt het niets bijzonders, maar onder de motorkap biedt continue integratie met afgestemde toepassingsimplementatieservices u de eenvoudigste en snelste manier om de nieuwste build te krijgen op elk testapparaat of omgeving die u maar wilt. Het is prima om build via USB naar één apparaat te uploaden. Maar wat als u de build met 10 verschillende apparaten moet controleren? Dat is het punt.

Voor mobiele projecten hebben we een aantal verschillende services geprobeerd, zoals HockeyApp, Beta by fabric (ex-Crashlytics), Test Flight van Apple, Play Console van Google. Natuurlijk zijn er meer diensten, maar deze zijn gekozen als de meest populaire. Nu stem ik voor Test Flight en Play Console omdat deze services flexibel zijn, ondersteuning bieden voor interne en externe testfuncties en officiële services van Apple en Google en alleen e-mail van testers is vereist. De enige beperking hier is dat u een Apple- en Google-ontwikkelaarsaccount nodig heeft dat 25 $ kost voor Google (eenmalige betaling) en 99 $ voor Apple (jaarlijks).

Andere services zoals HockeyApp of Beta hebben wat problemen met het toevoegen van nieuwe testers aan het project, vooral op iOS. Vanwege Apple-beveiligingszorg, van testers, is het vereist om UDID van hun apparaten aan de ontwikkelaar te verstrekken en de ontwikkelaar moet deze UDID's aan het project toevoegen. Omdat we dev-builds delen met onze klanten (die meestal veel verschillende apparaten hebben en ze regelmatig wijzigen), werden we allemaal moe van deze UDID-verzamelactiviteiten. Daarom hebben we voor Test Flight en Play Console gekozen.

Voor webprojecten is alles een beetje eenvoudiger omdat we een speciale testomgeving gebruiken die wordt bijgewerkt door de CI-tool wanneer de ontwikkelingstak wordt gewijzigd.

Documentatie testen

Door de jaren heen heeft ons QA-team vier meest waardevolle documenten gevonden die kunnen worden gedeeld met klanten of belanghebbenden:

  • Ondersteunde platforms
  • Testplan
  • Testgevallen / checklists
  • Release-opmerkingen

Het document met ondersteunde platforms moet zo vroeg mogelijk worden opgesteld wanneer een project begint en met de klant worden ondertekend. Het moet informatie bevatten over ondersteunde hardware- en softwareconfiguraties, bekende beperkingen en beperkingen. Het is ook gebaseerd op de apparaten van de doelgroep, omdat de markten voor apparaten in verschillende landen verschillen.

Door dit bij onze klanten te ondertekenen, garanderen we dat de eerste versie van een product perfect werkt op de vermelde configuraties, daarnaast laten we onze klanten weten dat het product op de andere configuraties kan werken, maar sommige problemen kunnen optreden. En als het product en de doelgroep zullen groeien, kunnen we aanvullende platformondersteuning analyseren en implementeren. In de toekomst kunnen we ons met dit document richten op specifieke platforms in ontwikkeling en bugfix.

Het testplan moet ook in het begin worden opgesteld en met de klant worden gedeeld. Dit document moet alle soorten tests bevatten die tijdens de productontwikkeling worden gebruikt met een beschreven doel voor elk type. In het testplan moet het QA-team beslissen wat ze gebruiken voor testen, testgevallen of checklists. Meestal hangt het af van de duur van het project en de functionele complexiteit. Ondersteunde platforms moeten ook aan het testplan worden gekoppeld. En ten slotte moet het testplan informatie bevatten over geplande testactiviteiten op datums die volgen op de projectontwikkeling en de tijdlijn van de release.

Testgevallen / checklists is een vereiste voor elk project. Natuurlijk kost het enige tijd om deze producten voor te bereiden en kan het extra tijd kosten voor ondersteuning van deze documentatie, maar het geeft je een soort boomstam en met deze boomstam kun je je gemakkelijk voorstellen en nieuwe testscenario's maken door gewoon takken toe te voegen aan je kofferbak. Later kunt u voorbereide testgevallen delen met het UAT-team van de kant van de klant of met bètatesters of zelfs testgevallen tonen aan het projectontwikkelingsteam. Het Dev-team kan testgevallen gebruiken als onderdeel van de vereisten en het kan hen echt helpen om bepaalde problemen te voorkomen.

Bij Effective hebben we veel TMS (Test Management System) geprobeerd en hebben we TestRail gekozen als een van de meest populaire, aanpasbare, snelle en handige tools voor testcasemanagement en testmanagement. Met TestRail kunnen we testcases en checklists eenvoudig up-to-date houden. Voor ons is deze tool geweldig, maar er zijn nog veel alternatieven. De belangrijkste tip hier is om het juiste TMS te gebruiken en Google Documenten en Spreadsheets niet te gebruiken voor testcases en testlogboeken :)

Release Notes is het document opgesteld door ons QA-team voor klanten en bevat actuele informatie over het project. Welke functies zijn voltooid in de specifieke sprint, wat is er nog aan de gang, wat zijn bekende problemen, waar en hoe de demo-build kan worden gedownload. We maken altijd release-opmerkingen per sprint en per release. Het geeft onze klanten extra transparantie over de voortgang van ontwikkeling.

Verkennend onderzoek

Het laatste ding dat nooit mag worden vergeten, is verkennend testen. Het belangrijkste doel van deze test is om uw product beter te begrijpen en te bekijken vanuit het perspectief van een gebruiker. Het combineren van verkennende en gescripte testen (met scripts testen bedoel ik testgevallen of checklists gebruik), het combineren van de perceptie van testers en gebruikers van het product en rekening houdend met bedrijfsdoelstellingen kunt u het product waaraan u werkt zo perfect mogelijk maken.

Als onderdeel van verkennende testen gebruiken we ook een aanpak voor het testen van zwermen. Met behulp van Test Flight en Play Console nodigen we externe testers uit die meestal effectieve werknemers zijn die geen deel uitmaken van het project en die kunnen fungeren als bètatesters. Hierdoor kunnen we een productoverzicht krijgen vanuit het perspectief van een gebruiker en aandacht besteden aan bruikbaarheid.

Overzicht van effectieve QA Best Practices:

  • Zakelijke doelen begrijpen
  • Maak acceptatiecriteria duidelijk
  • Ken uw ondersteunde platforms
  • Bereid testplan voor
  • Gebruik testgevallen / checklists
  • Gebruik Continuous Integration + Continuous deployment
  • Houd testcases / checklists bijgewerkt
  • Deel Release Notes met uw klanten
  • Vergeet nooit verkennend testen

Bedankt voor het lezen! Voel je vrij om te reageren als je meer wilt weten, niet mee eens bent of vragen hebt :)