Stel je deze hypothetische situatie voor: je werkt in Easy LMS aan een fantastische GDPR-cursus. Het is fantastisch omdat je het leuk hebt gemaakt met coole infographics en aansprekende video's. Dag, dag saaie compliance training. Alle GDPR-informatie is er; je hoeft het alleen nog maar in het systeem te zetten. Alles loopt gesmeerd. Totdat je een video wilt uploaden. Plotseling is je hele cursus weg! Met één klik. Aaargh!
Dit is duidelijk iets wat jij en wij niet willen! Wij vinden het beter om te ontdekken dat er iets kapot is voordat onze klanten dat ontdekken. Daarom hebben we een uitgebreide Quality Assurance (QA) procedure die handmatige en automatisch testen omvat. In dit artikel richten we ons alleen op handmatig testen. Omdat je soms gewoon mensen nodig hebt in plaats van robots. Welkom in onze wereld van handmatig testen!
Wat is kwaliteitsborging? En waarom hebben we het nodig?
QA-medewerkers zijn vaak de poortwachter bij het bepalen of de functie of opgeloste bug wel of niet klaar is voor release
Laten we eerst een stapje terug doen voor het geval je overweldigd bent door de term Quality Assurance ?. Wat is kwaliteitsborging? En waarom heb je het nodig? Quality Assurance (QA) is ervoor zorgen dat iets werkt zoals het bedoeld is. Naar onze mening is het hebben van een QA proces cruciaal voor onze (software) product- en klanttevredenheid en dus het succes van ons bedrijf. QA-medewerkers zijn vaak de poortwachter bij het bepalen of een functie of opgeloste bug wel of niet klaar is voor release.
Hoewel sommigen QA reduceren tot simpelweg testen, denken wij dat het meer is dan dat. Een goede QA is net zo cruciaal als het bouwen zelf. Het zorgt ervoor dat je kunt voldoen aan je eigen hoge kwaliteitsnormen! Het maakt je product ook stabiel en het geeft je team een veilig gevoel. We maken allemaal fouten; het is een onvermijdelijk onderdeel van het mens zijn, zelfs als je een getalenteerde ontwikkelaar bent (zoals wij? ). Maar als je een vangnet hebt, voel je je vrij in je geest en in je werk, zodat je je grenzen kunt verleggen. Dit zal uiteindelijk leiden tot meer geavanceerde (ontwikkeling, ontwerp, schrijven, noem maar op) vaardigheden!
Wie voert de tests uit?
Een jaar geleden was Caroline onze enige echte QA-medewerker. Ze testte alles wat door onze ontwikkelaars werd ontwikkeld handmatig. En we kunnen je vertellen: dat is veel. Omdat we streven naar autonome teams die volledig zelfstandig kunnen opereren, hebben we geëxperimenteerd met het uitvoeren van een QA door de ontwikkelteams zelf. Het experiment was succesvol! "Testen met ons team voelt als het juiste om te doen. Ons team is multidisciplinair, dus we merken allemaal verschillende dingen op. Dit geeft ons een veel grotere garantie om kleine problemen op te sporen dan wanneer een enkel lid alleen zou testen. We weten ook hoe de code werkt, dus we hebben een duidelijker idee van hoe we de code kunnen breken!", legt Bram, Back-End Developer, uit.
Hoe ziet onze testprocedure eruit?
Onze handmatige testprocedure bestaat uit zes stappen. Laten we ze samen doorlopen!
Stap 0: Controleer of de code voldoet aan onze kwaliteitsstandaard.
Voordat we handmatig gaan testen, doen we een code review. Een andere ontwikkelaar controleert de kwaliteit van de code. We controleren bijvoorbeeld expliciet op beveiligingslekken. Ook draaien we automatische tests die de kwaliteit van de code analyseren. Deze tests moeten slagen voordat we verder gaan. Als de test mislukt, gaan we terug naar de tekentafel en lossen we de problemen op.
Stap 1: Controleer of aan alle acceptatiecriteria is voldaan.
Wanneer we een nieuwe functie bouwen, beginnen we met het schrijven van acceptatiecriteria. Acceptatiecriteria definiëren hoe een bepaalde functie kan worden gebruikt vanuit het perspectief van de klant. We bedenken dus hoe een functie moet werken, zodat we achteraf kunnen testen of de functie werkt zoals bedoeld.
Stap 2: Controleer of aan onze definitie van Gereed is voldaan.
De Definitie van Gereed is een overeengekomen reeks items die moeten worden voltooid voordat een project als voltooid kan worden beschouwd. Onze definitie van klaar omvat bijvoorbeeld
Stap 3: Probeer dingen kapot te maken
We nemen het perspectief van de klant. Eerst gebruiken we de functie zoals we verwachten dat de eindgebruiker zou doen. Daarna gaan we tot het uiterste. We herhalen acties meer dan eens, gebruiken extreme testgevallen en controleren of de nieuwe functie bestaande functies niet heeft gebroken. Wat gebeurt er met X als ik op de nieuwe knop Y druk? We testen ook met verschillende testaccounts met andere kenmerken.
We nemen het perspectief van de klant
Stap 4: Test vanuit een beveiligingsstandpunt.
We streven ernaar GDPR compliant te zijn. We nemen de gegevens van onze klanten serieus. Daarom testen we op mogelijke kwetsbaarheden met een paar veelgebruikte hacktechnieken. We zijn goede mensen, dus we gebruiken deze technieken nooit in het echt; geen zorgen!
Stap 5: Test de nieuwe vertalingen en bewerk ze.
We ondersteunen 11 talen in ons dashboard en onze spelersinterface is beschikbaar in 24 talen. We hebben een pool van freelance vertalers die alle tekst handmatig vertalen in een aparte vertaaltool. Wij controleren of alle tekst is toegevoegd aan die tool. Ook controleren en bewerken we ze, zodat ze meteen klaar zijn om te gebruiken!
Stap 6: Bedenk welke inhoud moet worden bijgewerkt of geschreven.
Meestal gaat een nieuwe functie gepaard met nieuwe tekst. Waar mogelijk bereiden we alle interne of externe inhoud van tevoren voor. Als we een nieuwe functie uitbrengen, willen we compleet zijn! Dat sluit aan bij onze single item flow-visie!
"QA goed doen kan een tijdrovende taak zijn. Hoe meer perspectieven en ogen erbij betrokken zijn, hoe beter. Het werkt als de stappen gedocumenteerd zijn zodat iedereen ze kan volgen, in plaats van te vertrouwen op slechts één persoon. Bij Easy LMS werken we in multidisciplinaire teams, met back-end en front-end ontwikkelaars die nauw samenwerken met onze implementatieconsultants die het klantperspectief inbrengen. Dat is logisch!", zegt Caroline, QA medewerker;
Wanneer testen we handmatig?
Elke functie wordt handmatig getest
Elke functie wordt handmatig getest en doorloopt hetzelfde proces! Zelfs kleine functies (zoals het vervangen van een afbeelding op de startpagina) die op het eerste gezicht niet eens getest hoeven te worden. Maar de duivel zit in de details en in kleine functies. We voeren onze handmatige testprocedure uit wanneer de ontwikkeling is voltooid. Is de test geslaagd? Dan is het tijd om het vrij te geven zodat onze klanten ervan kunnen genieten! Is de test mislukt? Dan wordt de functie opnieuw onderzocht. Dit betekent dat het ontwikkelteam het probleem oplost en de kwaliteit opnieuw test. We herhalen dit totdat alle vakjes van onze QA review checklist zijn aangevinkt.
