Leiderschap in testen: testtools

• 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 belastingstests, statisch testen, testontwerp, beheer 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 verdeeld 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 verstrekt.

Er zijn meer dan 1700 tools die samenwerking, testen en DevOps ondersteunen.

We bekijken later in dit artikel de belangrijkste aandachtspunten die van invloed zijn op en ondersteuning bieden voor testmanagement.

Get Free Access

Get regular tech leadership wisdom for delivering better software and systems.

Create Free Account

Have an account? Log In

Toolarchitectuur

In de onderstaande afbeelding hebben we het scala aan soorten tools geïdentificeerd dat de meeste moderne softwareteams gebruiken. We hebben de tools die doorgaans worden gebruikt in ontwikkel-, test- en productieomgevingen afzonderlijk weergegeven. 

Deze tools worden ondersteund door infrastructuur tools die platforms, virtuele machines en containers bieden om omgevingen te hosten, en door 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 door samenwerkingstools 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

Tools voor testbeheer zijn onmisbaar in alle projecten van enige omvang. Agileprojecten maken doorgaans gebruik van een tool voor incidentbeheer en vertrouwen voor tests op het gebruik van bedrijfsverhalen en scenario's om belangrijke voorbeelden van, zo niet alle, tests bij te houden. Tools voor testbeheer variëren in omvang van zeer eenvoudige oplossingen, zoals Microsoft Excel, tot uitgebreide producten voor beheer van de levenscyclus van applicaties (ALM).

Over het algemeen omvat het bereik van tools voor testbeheer verschillende gebieden:

Model voor testdekking: Met de meeste tools voor testbeheer kunt u 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.

Beheer van testgevallen: Testgevallen en hun inhoud kunnen worden beheerd om een gedocumenteerd overzicht van tests te bieden. De inhoud van testgevallen kan voorafgaand aan het testen zijn voorbereid of dienen als verslag van uitgevoerde tests. Testgevallen kunnen een indeling met vrije tekst hebben of zijn gestructureerd in stappen met verwachte resultaten. Het importeren van documenten en afbeeldingen om 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. Aan teamleden kunnen tests worden toegewezen. Geplande testduren kunnen worden gebruikt om een gesynchroniseerd testschema te publiceren dat door het hele team wordt uitgevoerd. Subsets van tests kunnen worden geselecteerd om de vereiste dekking te bereiken, geselecteerde functies te testen en regressietestsets opnieuw uit te voeren. Ook tests die zijn geregistreerd als nog niet uitgevoerd, geblokkeerd, mislukt of met een andere status kunnen voor uitvoering worden geselecteerd.

Testuitvoering en registratie: Terwijl het team tests uitvoert, wordt de status van de tests vastgelegd. Bij alle uitgevoerde tests worden de tester, de datum en tijd en de duur geregistreerd. Geslaagde tests kunnen een eenvoudige status ‘geslaagd’ krijgen. Aan mislukte, geblokkeerde of afwijkende testresultaten kunnen schermafbeeldingen en testresultaten worden toegewezen, evenals een incidentrapport. Veel tools bieden koppelingen met tools voor testuitvoering die tests beheren en uitvoeren, resultaten registreren en zelfs conceptincidentrapporten maken.

Incidentbeheer: Testfouten worden in het uitvoeringslogboek geregistreerd. Deze vereisen doorgaans nader onderzoek, met foutopsporing en herstel wanneer een fout door een bug is veroorzaakt. Fouten die onderzoek vereisen, worden meestal vastgelegd met incident- of observatierapporten of bugrapporten. Incidentrapporten kunnen een grote hoeveelheid ondersteunende informatie bevatten. Doorgaans worden aan incidenten een type, een testobject, een prioriteit en een ernst 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, voor zover van toepassing. Het rapportageaanbod varieert van geplande versus werkelijke testdekking en de status van incidentrapporten voor het volgen van openstaand onderzoek, herstel- en hertestwerk, tot analyses van de tijd die nodig is om verschillende typen fouten op te lossen, uitgesplitst naar functie, ernst en urgentie, enzovoort.

De populairste tool voor testbeheer ter wereld is nog steeds Microsoft Excel.

Testontwerp

Testontwerp is gebaseerd op modellen. In het geval van systeem- en acceptatietesters zijn typische modellen documenten met vereisten, gebruiksscenario's, stroomdiagrammen of zwembaan-diagrammen. Meer technische modellen, zoals toestandsmodellen, samenwerkingsdiagrammen, sequentiediagrammen enzovoort, bieden ook een solide basis voor testontwerp.

In veel projecten worden modellen gebruikt om vereisten of ontwerpen op hoofdlijnen 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 zwembaan-diagrammen vastlegt. Deze helpen testers om zinvollere gesprekken met belanghebbenden te voeren, vooral als het gaat om de aanpak van de dekking.

In het propriëtaire domein komen tools op die het mogelijk maken modellen zoals stroomdiagrammen vast te leggen en te gebruiken 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 tools kunnen worden gekoppeld aan tools voor testgegevensbeheer en -generatie om combinaties van testgegevens te genereren voor gebruik met handmatige of geautomatiseerde tests.

Er zijn ook tools waarmee modellering in tools voor testuitvoering kan worden uitgevoerd. Zo kunnen deze tools de testontwikkelaar in staat stellen 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 creëren – allemaal in een grafische indeling.

Het model wordt vervolgens gebruikt om navigatiepaden te maken en een testsuite te creëren die aan bepaalde dekkingscriteria 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 testsysteem en geautomatiseerde selectie en rapportage van testpaden ondersteunen.

More Articles

• Levenscyclus van softwaretesten: fasen, hulpmiddelen & beste praktijken
• Leiderschap in de praktijk: hulpmiddelen voor testuitvoering
• Testdesign: een essentiële QA-vaardigheid

Propriëtair of open source?

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 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 voor servers is. 

Hoewel het artikel de voor- en nadelen van opensource- en propriëtaire hulpmiddelen 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 websites gebruikt de bekendste opensource-webserverproducten, Apache en Nginx.

De populariteit van deze FOSS-infrastructuurproducten bewijst dat open source even betrouwbaar of zelfs betrouwbaarder kan zijn dan propriëtaire producten.

Voor een softwareteam dat twintig of dertig softwarehulpmiddelen nodig heeft om zijn activiteiten te ondersteunen, zijn er betrouwbare en functionele FOSS- en propriëtaire hulpmiddelen 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 hulpmiddel.

	Propriëtair	FOSS
Beschikbaarheid	Hulpmiddelen beschikbaar voor elk gebied.	Sommige gebieden, vooral ontwikkel- en infrastructuurhulpmiddelen, worden beter ondersteund dan andere.
Aanschafkosten	Vaak duur, vooral zakelijke producten.	Gratis, of zonder kosten onder een licentie voor gemeenschappelijk gebruik. 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 auteurs van hulpmiddelen bieden uitstekende ondersteuning en voegen op verzoek zelfs functies toe. Veel hulpmiddelen hebben onlineforums – maar die kunnen erg technisch zijn. Andere hulpmiddelen worden slecht ondersteund.
Betrouwbaarheid/kwaliteit	Meestal zeer goed.	Wisselend. Producten met veel gebruikers, landinstellingen en grote ondersteuningsteams zijn doorgaans uitstekend. Sommige hulpmiddelen die door individuen zijn geschreven en weinig bijdragers en gebruikers hebben, kunnen instabiel zijn.
Rijkdom aan functies	Functiesets volgen doorgaans gepubliceerde productplanningen en zijn meestal uitgebreid.	Producten ontwikkelen zich doorgaans op basis van gebruikersvraag en de omvang van het team van bijdragers. Bijdragers voegen meestal functies toe die ze 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 misschien goedkoper aan te schaffen, maar andere kosten en verantwoordelijkheden kunnen aanzienlijk zijn. De doorslaggevende factor bij de keuze tussen beide is meestal een mix van je cultuur, risicobereidheid en technische mogelijkheden.

Wanneer je propriëtaire producten en ondersteuningsovereenkomsten aanschaft, zijn de risico’s die samenhangen met incompatibiliteit (met andere producten), betrouwbaarheid, gebruiksgemak en oplettende technische ondersteuning over het algemeen klein, ook al kunnen ze soms duur zijn.

Bij FOSS-producten moet je doorgaans veel uitgebreider onderzoek doen voordat je besluit er een te gebruiken. Er is tenslotte geen verkoper om mee te praten en documentatie kan functioneel in plaats van informatief zijn. Natuurlijk is een proefperiode eenvoudig op te zetten en kun je zoveel hulpmiddelen gebruiken als je wilt, maar je zult grondiger moeten onderzoeken wat de mogelijkheden van het hulpmiddel zijn. 

Een minder goede bruikbaarheid en incompatibiliteit met je bestaande hulpmiddelen kunnen problemen veroorzaken, waardoor je mogelijk interfacesoftware of plug-ins en hulpprogramma’s voor rapportage of gegevensimport en -export moet schrijven. 

Daarnaast moet je jezelf en je team opleiden om hen op niveau te brengen en meestal zelf de softwareondersteuning verzorgen. Je team zal echter een grondiger kennis hebben van de werking van het hulpmiddel en grotendeels zelfredzaam zijn.

Een FOSS-tool kan je helpen ervaring op te doen met een nieuw type tool tegen geringe kosten. Met die ervaring ben je beter in staat om op de lange termijn een propriëtaire tool te kiezen.

Een oefening in toolselectie

Als je op zoek bent naar een tool voor testmanagement ter ondersteuning van je huidige of een vergelijkbaar recent project en bijbehorende applicatie, maak dan op basis van de functiegebieden uit de bovenstaande bespreking van testmanagementtools een lijst van 15-20 functies die:

• Verplicht zijn
• Wenselijk zijn

Dit kan bestaan uit functionele mogelijkheden, integraties, de nadruk op gebruiksgemak, ondersteuning, een grote gebruikersgroep of online forums/FAQ’s. Als je al een tool gebruikt, kies die dan niet.

Gebruik de tekst van je vereisten en zoek in de Tools Knowledge Base naar drie tools (waaronder een propriëtair en een FOSS-product) die aan je vereisten lijken te voldoen. Maak op basis van de functiebeschrijvingen van de tools een vergelijkingstabel met de functies 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 selectie van bijvoorbeeld drie tools samen te stellen?

Schrijf je in voor de nieuwsbrief van The QA Lead om bericht te krijgen wanneer nieuwe delen van de reeks verschijnen. Deze berichten zijn fragmenten uit Pauls Leadership In Test-cursus—een echte aanrader voor iedereen die dieper op dit en andere onderwerpen wil ingaan. Gebruik in dat geval onze exclusieve kortingscode QALEADOFFER om $60 korting op de volledige cursusprijs te krijgen!

Leer van andere testers door naar onze podcasts te luisteren of onze blogs te bekijken. Dit is er een waarvan we denken dat je er enorm veel van zult leren: HOE TESTVAARDIGHEDEN MIJ EEN BETERE AUTOMATISERINGSONTWIKKELAAR HEBBEN GEMAAKT