Leiderschap in testen: testhulpmiddelen
Noot van de redactie: Welkom bij de serie Leadership In Test van softwaretestexpert en consultant Paul Gerrard. De serie is bedoeld om testers met enkele jaren ervaring—vooral testers in agileteams—te helpen uitblinken in hun rol als testleider en manager.
In het vorige artikel bekeken we de infrastructuur van de website en hoe je deze test. In dit artikel neem ik je mee door de gereedschapskist van de tester, hoe je kiest tussen propriëtaire en opensourcetools en een korte oefening voor het selecteren van tools.
Schrijf je in voor de nieuwsbrief van The QA Lead om een melding te ontvangen wanneer nieuwe delen van de serie verschijnen. Deze posts zijn fragmenten uit Pauls Leadership In Test-cursus, die we ten zeerste aanbevelen als je dieper op dit en andere onderwerpen wilt ingaan. Als je dat doet, gebruik dan onze exclusieve couponcode QALEADOFFER voor $60 korting op de volledige cursusprijs!
Softwareteams die zichzelf managen gebruiken meer verschillende tools dan ooit tevoren. In een typisch softwareteam kunnen wel twintig of zelfs dertig tools in gebruik zijn. Om je hierbij te helpen, behandelen we in dit artikel:
- Tools voor testen
- Toolarchitectuur
- Testmanagement
- Testontwerp
- Propriëtair of opensource?
- Een oefening voor het selecteren van tools
Laten we eerst kijken naar de belangrijkste soorten tools die je voor het testen zult gebruiken.
Tools voor testen
Het is handig om de tools die relevant zijn voor testen in drie typen te verdelen:
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
- Samenwerkingstools: deze ondersteunen het vastleggen van ideeën en vereisten, communicatie binnen het team met enige integratie met geautomatiseerde processen en soms bots.
- Testtools: een breed spectrum aan tools die ondersteuning bieden voor testgegevensbeheer, testontwerp, unit-testframeworks, functionele testuitvoering, prestatie- en belastingtests, statisch testen, testontwerp, het beheren van het testproces, testgevallen, testregistratie en rapportage.
- DevOps- of infrastructuurbeheertools: deze tools ondersteunen omgevings- en platformbeheer, implementatie met behulp van infrastructuur als code en containertechnologieën, en logging, monitoring en analyse in productie.
The Tools Knowledge Base is een online register voor tools dat verschilt van de meeste online registers doordat het register samenwerking, testen en DevOps omvat. Er zijn meer dan 1700 tools verspreid over deze drie gebieden. Webpagina's van tools zijn geïndexeerd en kunnen worden doorzocht.
De website verzamelt en indexeert ook meer dan 300 bloggers en meer dan 52.000 blogs zijn eveneens geïndexeerd en doorzoekbaar. We hebben URL's naar de belangrijkste toolcategorieën en snelkoppelingen voor zoekopdrachten binnen deze categorieën in de blogs beschikbaar gesteld.
Er zijn meer dan 1700 tools die samenwerking, testen en DevOps ondersteunen.
Later in dit artikel bespreken we de belangrijkste aandachtspunten die van invloed zijn op en ondersteuning bieden aan testmanagement.
Toolarchitectuur
In de onderstaande afbeelding hebben we de verschillende soorten tools geïdentificeerd die de meeste moderne softwareteams gebruiken. We hebben de tools die doorgaans worden gebruikt in ontwikkel-, test- en productieomgevingen afzonderlijk weergegeven.
Deze tools zijn gebaseerd op infrastructuur tools die platforms, virtuele machines en containers bieden om omgevingen te hosten, en op tools die geautomatiseerde implementaties uitvoeren. De tools die worden gebruikt om implementaties en releases te beheren, worden tools voor release- en pijplijnorkestratie genoemd. Communicatie binnen het team, en ook met veel van de geautomatiseerde processen, wordt beheerd met samenwerkings- of ChatOps-tools.
Hoewel de verschuiving naar DevOps de ontwikkeling en toepassing van tools voor continue ontwikkeling stimuleert, zijn bijna al deze tools nuttig voor elk softwareontwikkelings- of operationeel team.
Je hoeft geen DevOps-cultuur te hebben om “DevOps”-tools te gebruiken.
Testmanagement
Testmanagementtools zijn onmisbaar in alle projecten van enige omvang. Agile projecten maken doorgaans gebruik van een hulpmiddel voor incidentbeheer en vertrouwen voor tests enigszins op het gebruik van bedrijfsverhalen en gebruiksscenario's om belangrijke voorbeelden van, zo niet alle, tests bij te houden. Testmanagementtools variëren in reikwijdte van zeer eenvoudige oplossingen, zoals Microsoft Excel, tot uitgebreide producten voor het beheer van de levenscyclus van applicaties (ALM).
Over het algemeen bestrijkt de reikwijdte van testmanagementtools verschillende gebieden:
Model voor testdekking: Met de meeste testmanagementtools kun je een reeks vereisten definiëren waaraan testgevallen en/of controles in tests kunnen worden gekoppeld. Deze vereisten kunnen soms hiërarchisch zijn om de inhoudsopgave van een document weer te geven. Steeds vaker kunnen ook andere modellen, zoals gebruiksscenario's of bedrijfsprocesstromen, worden vastgelegd. Rapporten over de dekking van testplannen en testuitvoering zijn doorgaans beschikbaar.
Testgevalbeheer: Testgevallen en hun inhoud kunnen worden beheerd om een gedocumenteerd overzicht van tests te bieden. De inhoud van testgevallen kan voorafgaand aan het testen worden voorbereid of worden vastgelegd als registratie van uitgevoerde tests. Testgevallen kunnen de vorm hebben van vrije tekst of worden gestructureerd in stappen met verwachte resultaten. Het importeren van documenten en afbeeldingen om deze aan tests of stappen te koppelen is gebruikelijk.
Planning van testuitvoering: Tests kunnen in een hiërarchie worden gestructureerd of van labels worden voorzien om een dynamischere structuur te bieden. Testteamleden kunnen tests toegewezen krijgen. Geplande testduren kunnen worden gebruikt om een gesynchroniseerd testschema te publiceren dat door het hele team moet worden uitgevoerd. Subsets van tests kunnen worden geselecteerd om de dekking van vereisten te bereiken, geselecteerde functies te testen en regressietestsets opnieuw uit te voeren. Tests die zijn geregistreerd als nog niet uitgevoerd, geblokkeerd, mislukt of met een andere status, kunnen eveneens voor uitvoering worden geselecteerd.
Testuitvoering en registratie: Terwijl het team tests uitvoert, wordt de status van de tests geregistreerd. Bij alle uitgevoerde tests worden de tester, de datum en tijd en de duur vastgelegd. Geslaagde tests kunnen een eenvoudige status ‘geslaagd’ krijgen. Aan mislukte, geblokkeerde of afwijkende testresultaten kunnen schermafbeeldingen en testresultaten worden toegewezen, evenals een incidentrapport. Veel hulpmiddelen bieden koppelingen met hulpmiddelen voor testuitvoering die tests beheren en uitvoeren, resultaten registreren en zelfs conceptincidentrapporten maken.
Incidentbeheer: Testfouten worden geregistreerd in het uitvoeringslogboek. Deze vereisen doorgaans nader onderzoek, met foutopsporing en herstel wanneer een fout door een bug is veroorzaakt. Fouten die nader onderzoek vereisen, worden meestal vastgelegd met behulp van incident- of observatierapporten of foutrapporten. Incidentrapporten kunnen een grote hoeveelheid ondersteunende informatie bevatten. Doorgaans krijgen incidenten een type, een object dat wordt getest, een prioriteit en een ernstniveau toegewezen. Sommige bedrijven registreren een enorme hoeveelheid informatie en koppelen die aan een geavanceerd incidentbeheerproces.
Rapportage: Rapporten en analyses van gegevens uit alle bovenstaande functies, waar van toepassing. Het aanbod aan rapporten varieert van geplande versus werkelijke testdekking en de status van incidentrapporten om openstaand onderzoek, herstelwerk en hertests te volgen, tot analyses van de hersteltijd voor verschillende fouttypen, per functie, ernst en urgentie, enzovoort.
De populairste testmanagementtool ter wereld is nog steeds Microsoft Excel.
Testontwerp
Testontwerp is gebaseerd op modellen. In het geval van systeem- en acceptatietesters zijn typische modellen vereistedocumenten, gebruiksscenario's, stroomdiagrammen of diagrammen met zwembanen. Meer technische modellen, zoals toestandsmodellen, samenwerkingsdiagrammen, sequentiediagrammen enzovoort, vormen eveneens een goede basis voor testontwerp.
In veel projecten worden modellen gebruikt om vereisten of ontwerpen op hoog niveau vast te leggen. Wanneer ze beschikbaar worden gesteld aan testers, kunnen zij worden gebruikt om paden te traceren en rechtstreeks vanuit het model dekkingsitems te selecteren. Als dergelijke modellen niet beschikbaar zijn, is het vaak nuttig als het testteam bijvoorbeeld processtroomdiagrammen of diagrammen met zwembanen vastlegt. Deze helpen testers om zinvollere gesprekken met belanghebbenden te voeren, vooral als het gaat om de aanpak van testdekking.
In de wereld van propriëtaire software ontstaan hulpmiddelen waarmee modellen zoals stroomdiagrammen kunnen worden vastgelegd en gebruikt om testgevallen te genereren door paden te traceren volgens een bepaald dekkingsdoel, bijvoorbeeld alle koppelingen, alle processen, alle beslissingsuitkomsten, alle paren en alle paden. Deze hulpmiddelen kunnen worden gekoppeld aan hulpmiddelen voor testgegevensbeheer en -generatie om combinaties van testgegevens te genereren voor gebruik met handmatige of geautomatiseerde tests.
Er zijn ook hulpmiddelen waarmee modellering kan worden uitgevoerd in hulpmiddelen voor testuitvoering. Zo kunnen deze hulpmiddelen de testontwikkelaar bijvoorbeeld toestaan alle velden op een webpagina vast te leggen, koppelingen te maken om de velden met elkaar te verbinden en een navigatiemodel voor de pagina te maken – allemaal in een grafische indeling.
Het model wordt vervolgens gebruikt om navigatiepaden te maken en een testpakket samen te stellen dat aan bepaalde criteria voor testdekking voldoet – net als bij de bovenstaande modelleertools. Deze uitvoeringstools kunnen geautomatiseerde testpaden maken met behulp van geselecteerde criteria, of deze willekeurig genereren, en ook de dekking ten opzichte van deze modellen rapporteren.
Dit is momenteel een dynamisch gebied – houd modelleertools in de gaten die testontwerp en testgeneratie ondersteunen, evenals uitvoeringstools die modellering van het te testen systeem en geautomatiseerde selectie en rapportage van testpaden ondersteunen.
Propriëtair of opensource?
In de afgelopen twintig jaar is het gebruik van gratis en opensourcesoftwareproducten (FOSS), vooral voor het uitvoeren van infrastructuur, wijdverbreid geweest. De kosten van licenties voor besturingssystemen en de bijbehorende webserversoftware van Microsoft, en de algemene opvatting dat Linux/Unix betrouwbaarder en veiliger is dan Windows, betekenen dat Linux/Unix voor veel omgevingen het besturingssysteem bij uitstek is voor servers.
Hoewel het artikel de voor- en nadelen van opensource- en propriëtaire tools bespreekt, kan onze uitgebreide handleiding over testmanagementtools specifiek voor Jira je helpen een weloverwogen beslissing te nemen als je specifiek op zoek bent naar oplossingen die goed met Jira integreren.
De twee onderstaande tabellen (dagelijks bijgewerkt op w3techs.com) tonen de relatieve populariteit van besturingssystemen en webserverproducten. Ongeveer 85% van de sites gebruikt de bekendste opensourcewebserverproducten, Apache en Nginx.
De populariteit van deze FOSS-infrastructuurproducten bewijst dat opensourceproducten net zo betrouwbaar, zo niet betrouwbaarder, kunnen zijn dan propriëtaire producten.
Voor een softwareteam dat twintig of dertig softwaretools nodig heeft om zijn activiteiten te ondersteunen, zijn er betrouwbare en functionele FOSS- en propriëtaire tools voor elke taak. Hoe kies je tussen een propriëtair en een FOSS-product?
De onderstaande tabel vat enkele overwegingen samen die je kunt maken bij het selecteren van een type tool.
| Propriëtair | FOSS | |
| Beschikbaarheid | Tools beschikbaar voor elk gebied. | Sommige gebieden, met name ontwikkelings- en infrastructuurtools, worden beter ondersteund dan andere. |
| Aanschafkosten | Vaak duur, vooral ‘zakelijke producten’. | Gratis, of een licentie voor communitygebruik zonder kosten. Er kunnen commerciële licenties bestaan voor zakelijke of gehoste versies. |
| Documentatie | Meestal zeer goed. | Varieert. Soms uitstekend, soms niet-bestaand en alles daartussenin. Vaak geschreven door programmeurs voor programmeurs, en daardoor minder bruikbaar dan commerciële documentatie. |
| Technische ondersteuning | Zeer goed, tegen betaling. | Varieert. Sommige toolauteurs bieden uitstekende ondersteuning en voegen op verzoek zelfs functies toe. Veel tools hebben onlineforums – maar die kunnen zeer technisch zijn. Andere tools worden slecht ondersteund. |
| Betrouwbaarheid/kwaliteit | Meestal zeer goed. | Wisselend. Producten met veel gebruikers, lokale versies en grote ondersteuningsteams zijn doorgaans uitstekend. Sommige tools die door individuen met weinig bijdragers en weinig gebruikers zijn geschreven, kunnen onbetrouwbaar zijn. |
| Rijkdom aan functies | Functiesets volgen doorgaans gepubliceerde productroutekaarten en zijn meestal uitgebreid. | Producten evolueren doorgaans op basis van gebruikersbehoeften en de omvang van het team van bijdragers. Bijdragers voegen doorgaans functies toe die zij zelf nodig hebben, in plaats van bijvoorbeeld op basis van klantonderzoek. |
| Frequentie van releases en patches | Grote releases verschijnen doorgaans met tussenpozen van maanden, soms jaren. Regelmatige patchreleases. Waarschuwingen en releaseopmerkingen zijn doorgaans zeer goed. | Varieert. Grote releases van infrastructuurproducten – net als bij propriëtaire producten. Kleinere, minder populaire producten worden doorgaans vaker uitgebracht. Weinig of geen waarschuwingen, slechte releaseopmerkingen en soms verlies van achterwaartse compatibiliteit. |
FOSS-producten zijn mogelijk goedkoper in aanschaf, maar andere kosten en verantwoordelijkheden kunnen aanzienlijk zijn. De doorslaggevende factor bij de keuze tussen beide is meestal een combinatie van je cultuur, risicobereidheid en technische vaardigheden.
Wanneer je propriëtaire producten en ondersteuningsovereenkomsten aanschaft, zijn de risico’s die verband houden met incompatibiliteit (met andere producten), betrouwbaarheid, gebruiksgemak en oplettende technische ondersteuning over het algemeen laag, ook al kunnen ze soms duur zijn.
Bij FOSS-producten moet je meestal veel uitgebreider onderzoek doen voordat je besluit er een te gebruiken. Er is immers geen verkoper om mee te praten en de documentatie kan functioneel in plaats van informatief zijn. Natuurlijk is een proefperiode eenvoudig op te zetten en kun je zoveel tools gebruiken als je wilt, maar je zult uitgebreider moeten onderzoeken waartoe de tool in staat is.
Minder goede bruikbaarheid en incompatibiliteit met je bestaande tools kunnen problemen veroorzaken, waardoor je mogelijk software of plug-ins voor koppelingen en hulpprogramma’s voor rapportage of gegevensimport en -export moet schrijven.
Daarnaast moet je jezelf en je team opleiden om hen op weg te helpen en meestal ook zelf de softwareondersteuning verzorgen. Je team zal echter een diepgaandere kennis hebben van de werking van de tool en grotendeels zelfstandig ondersteuning kunnen bieden.
Een FOSS-tool kan je helpen tegen geringe kosten ervaring op te doen met een nieuw type tool. Met die ervaring ben je beter in staat om voor de lange termijn een propriëtaire tool te kiezen.
Een oefening in toolselectie
Als je op zoek bent naar een testmanagementtool ter ondersteuning van je huidige of een vertrouwd, recent project en de bijbehorende applicatie. Maak op basis van de functiegebieden die hierboven zijn besproken bij testmanagementtools een lijst van 15-20 functies die ofwel:
- Verplicht
- Gewenst
Dit kan bestaan uit functionele mogelijkheden, integraties, een focus op gebruiksgemak, ondersteuning of een groot gebruikersbestand, of onlineforums/FAQ's. Als je al een tool gebruikt, selecteer die dan niet.
Zoek met behulp van de tekst van je vereisten in de Kennisbank voor tools drie tools (waaronder een propriëtaire en een FOSS-tool) die aan je vereisten lijken te voldoen. Maak op basis van de functiebeschrijvingen van de tools een vergelijkingstabel van de drie producten. Voeg een vierde kolom toe voor de tool die je daadwerkelijk gebruikt, ter vergelijking.
- Hoe verhouden de tools zich tot elkaar wat betreft functies?
- Welke functies ontbreken in de FOSS-tool(s) in vergelijking met de propriëtaire tools?
- Hoeveel tools bestaan er die in grote lijnen aan je vereisten voldoen?
- Hoeveel tijd denk je nodig te hebben om tools te onderzoeken en een shortlist van bijvoorbeeld drie tools op te stellen?
Meld je aan voor de nieuwsbrief van The QA Lead om op de hoogte te worden gebracht wanneer nieuwe delen van de reeks online komen. Deze berichten zijn fragmenten uit Pauls cursus Leiderschap in testen — zeer aan te raden voor iedereen die zich verder in dit en andere onderwerpen wil verdiepen. Gebruik in dat geval onze exclusieve couponcode QALEADOFFER om $60 korting op de volledige cursusprijs te krijgen!
Leer van mede-testers door naar onze podcasts te luisteren of onze blogs te bekijken. Dit is er een waarvan we denken dat je er veel van zult leren: HOE TESTVAARDIGHEDEN MIJ EEN BETERE AUTOMATISERINGSONTWIKKELAAR HEBBEN GEMAAKT
