Waarom hebben programmeurs testen nodig?
De volgende paar niveaus zullen gewijd zijn aan testen op de manier die programmeurs nodig hebben . Maar laten we eerst eens kijken wat testen is en waarom het nodig is.
Met betrekking tot software kunnen we zeggen dat de testtaak is om te controleren of het programma:
- doet wat ze moet doen
- doet niet wat ze niet moet doen
Het tweede punt is trouwens niet minder belangrijk dan het eerste, maar daarover later meer.
Laten we beginnen met het eerste punt. Wat betekent "het programma doet wat het moet doen"?
Eerst moet iemand een lijst maken van alle use cases voor het programma. Ten tweede moeten ze beschrijven hoe het programma zou moeten werken, hoe de gebruiker zich zou moeten gedragen en welke resultaten worden verwacht. U kunt niet verder.
Zodra we schreven “hoe de gebruiker zich zou moeten gedragen”, viel het hele idee van het schrijven van goede documentatie in duigen. Mensen zijn geen machines, bovendien gedragen mensen zich heel vaak met software zoals ze willen . Niemand begint kennis te maken met technologie door de instructies te bestuderen. Het is een feit.
Daarom krijgen we een nieuw feit: de bijzonderheid van de software is dat deze veel verschillende werkscenario's heeft. Sommige liggen voor de hand, andere kunnen worden gedocumenteerd, andere kunnen worden aangenomen, andere kunnen worden geraden en de andere 50% zal niet eens bij je opkomen.
Vanuit het oogpunt van een programmeur zijn de meeste bugs helemaal geen bugs. Een fout is wanneer een programma niet werkt zoals het zou moeten of zoals verwacht. En er zijn veel situaties waarin het niet duidelijk is hoe het programma zou moeten werken, of scenario's die elkaar tegenspreken...
Er zijn oneindig veel scenario's en er zullen altijd gevallen in het product zijn waarin het programma zich niet gedraagt zoals verwacht (de programmeur heeft de code geschreven voor slechts een paar dozijn scenario's). Daarom kan worden gesteld dat er altijd bugs in elk programma zitten en dat elk product eindeloos kan worden verbeterd .
Daarna komt het allemaal neer op doelmatigheid. Eerst repareert de programmeur de grootste bugs, vervolgens de kleinere bugs, enzovoort. En tot slot komt er een fase waarin de eigenaar van het product gelooft dat het economisch niet haalbaar is om eraan te blijven werken.
Maar terug naar de fouten die iedereen herkent als fouten: het programma doet duidelijk iets verkeerd, viel, brak iets enz. Dergelijke fouten kunnen voorwaardelijk worden onderverdeeld in 3 categorieën: groot, middelgroot en klein.
En heel vaak gebeurt het dat een programmeur bezig is met het oplossen van middelgrote of zelfs kleine bugs, hoewel er nog veel serieuzere problemen in het project zijn. Hij heeft ze alleen niet gevonden , dus werkt hij aan de grootste die hij kent.
Daarom moeten er in elk project testers zijn. Deze mensen leren specifiek vanuit verschillende invalshoeken naar het product te kijken. Zodat u meer scenario's van het programma kunt zien. Hun taak is om fouten te vinden en op te schrijven (om niet meerdere keren dezelfde fout te vinden).
Testen is een proces gericht op het vinden van fouten. Deze bugs moeten worden gevonden, beschreven en geprioriteerd. Pas na de prioritering van fouten kunnen we spreken van een effectief software verbeterproces.
Onthoud dat de eerste stap bij het oplossen van een probleem is erkennen dat er een probleem is . Je kunt een fout die je niet kent niet herstellen.
Automatisering testen
Ik denk dat we het er allemaal over eens waren dat testen belangrijk is, dus laten we eens kijken naar testen zoals programmeurs. Hoe kijken programmeurs naar testen? Programmeurs automatiseren het werk van andere mensen. Het laatste beroep dat verdwijnt, is het beroep van programmeur.
We automatiseren alle processen die we tegenkomen. Het testen moet dus worden geautomatiseerd. En hoe het zoeken naar fouten te automatiseren? Kort antwoord: nee. Maar ook hier komt het feit dat we programmeurs zijn ons te hulp.
Het softwareontwikkelingsproces bestaat uit constante wijzigingen daarin. juist tijdens het voortdurend aanbrengen van wijzigingen, maken programmeurs heel vaak iets kapot dat tot voor kort prima werkte.
En testers moeten, in plaats van naar nieuwe fouten te zoeken, constant controleren of we iets hebben gebroken dat al heel lang goed werkt. De zogenaamde regressietesten. Het is dit type testen dat kan en moet worden geautomatiseerd.
Hier kan alle software in twee delen worden verdeeld:
- het programma interageert met de persoon
- programma communiceert met een ander programma
De eerste optie is moeilijker te automatiseren, hiervoor zijn speciale automator testers nodig, deze worden ook wel QA Automation of Software Test Engineer genoemd.
Maar de tweede optie kan en moet onafhankelijk worden geautomatiseerd. Als u een stukje software heeft dat:
- werkt goed
- al getest
- geïmplementeerd als een aparte module of logisch blok
- niet van plan te veranderen
- andere modules of programma's zijn ervan afhankelijk
- functioneel falen is kostbaar
Ik raad aan de tijd te nemen om er tests voor te schrijven die de belangrijkste aspecten van de huidige functionaliteit vastleggen. Het zou redelijk zijn om hiervoor 5% van je werktijd uit te trekken , ofwel 1 dag per maand.
Het is niet nodig om tests te schrijven omwille van tests.
Niemand zal uw tests ondersteunen. Niet andere programmeurs, niet jezelf. Niemand doet dat. 99% van alle schriftelijke toetsen wordt afgebroken en/of uitgeschakeld. Als u geen tests kunt schrijven, schrijf dan niet. Schrijf alleen als u absoluut niet zonder kunt.
Soorten testen
Elke programmeur zal, als hij geen speciale training heeft gevolgd, in zijn eigen woorden kunnen vertellen wat testen is: controleren of het programma doet wat het moet doen. Professionals op dit gebied onderscheiden echter hele testgebieden (typen).
Alle tests draaien echt om de betrouwbaarheid en beschikbaarheid van software, maar om de richting van testen beter te begrijpen, laten we een paar voorbeelden bekijken.
Stel dat u een typische online winkel aan het testen bent. Dan zijn de testgebieden onder te verdelen in de volgende typen: prestatietesten, functionele testen, integratietesten en unittesten.
Als de site-eigenaar besluit een serieuze advertentiecampagne te lanceren, zullen er veel gebruikers tegelijkertijd naar de site komen. Het is heel goed mogelijk dat de site niet zal vallen, maar sommige secties kunnen traag zijn of zelfs niet meer werken.
Om dit te voorkomen, moet u dergelijke problemen van tevoren identificeren en stappen ondernemen om ze te verhelpen. Dit gebeurt door middel van load testing , ook wel performance testing genoemd.
Misschien wilt u ook testen hoe uw backend-API werkt en elke functie ervan testen: registratie, inloggen, toevoegen aan winkelwagentje, betalingsverwerking, schrijven in database, enz. Alles zou moeten werken volgens de TOR. In dit geval moet u functionele tests uitvoeren .
Uw online winkel is hoogstwaarschijnlijk geïntegreerd met services van derden: brieven en sms'en verzenden, betalingssystemen, online ondersteuningchats, feedback van gebruikers verzamelen, advertentiesystemen, enz. Om er zeker van te zijn dat dit allemaal werkt zoals bedoeld, moet u integratietesten uitvoeren .
Tot slot worden complexe producten vaak opgesplitst in zelfstandige modules. Van dergelijke modules kun je het eindproduct samenstellen, zoals van een constructeur. Als u een dergelijke module ontwikkelt of met dergelijke modules communiceert, moet u unit-testen uitvoeren .
Samenvattend kunnen we zeggen dat functionele testen nodig zijn om elke individuele functie van de site te testen. Integratie - voor het testen van de interactie van grote modules en systemen van uw product. Modulair - om een afzonderlijke module te testen, nou ja, prestatietesten - om de werking van uw site onder belasting te controleren.
Er kunnen nog meer soorten testen zijn: hoe complexer het product, hoe meer aspecten van de ontwikkeling ervan gecontroleerd moeten worden.