Profiel wijzigen voor examenkandidaten

Controleer uw gegevens goed! Uw voor- en achternaam worden gebruikt voor het certificaat dat u ontvangt als u voor een examen slaagt. Met uw gebruikersnaam en wachtwoord krijgt u toegang tot de voor u aangevraagde examens en de examenresultaten.

Je moet ingelogd zijn voor het wijzigen van je profiel

Inloggen voor examenkandidaten

Gebruik de logingegevens die u hebt gekregen bij het aanmelden voor een examen. De logingegevens bestaan uit een gebruikersnaam en een wachtwoord. Voor de gebruikersnaam vult u het emailadres in dat u bij het aanvragen van het examen hebt opgegeven. Het wachtwoord hebt u via het opgegeven emailadres ontvangen.

Na het inloggen kunt u het door u gekozen examen afleggen. De instructies hiervoor worden op de betreffende examenpagina gegeven. Ook kunt u uw gegevens inzien en wijzigen. Controleer uw gegevens goed! Uw voor- en achternaam worden op het certificaat dat hoort bij het examen afgedrukt.

Oefen je DevOps Fundamentals examen (Engels)

DevOps Fundamentals oefen examenvragen

Deze quiz bevat vragen die representatief zijn voor het DevOps Fundamentals examen. Deze quiz is, evenals het officiële DevOps Fundamentals examen, in het Engels opgesteld.

Na het starten van de quiz hebt u 20 minuten de tijd om de vragen te beantwoorden.

Bij het officiële DevOps Fundamentals examen worden er 40 vragen gesteld, waarvoor u 60 minuten de tijd krijgt om deze te beantwoorden. Om te slagen dienen 24 van de 40 vragen goed beantwoord te worden (60%).

Handig omgaan met testautomatisering in sprints

8 juni 2018

Wie als testautomatiseerder verantwoordelijk is voor het programmeren van de geautomatiseerde UI testen in een sprint loopt vaak tegen het feit aan, dat de software waarvoor de testen geautomatiseerd moeten worden pas laat in de sprint beschikbaar komt. Dat maakt de beschikbare tijd om te testautomatiseren onvoldoende om er nog iets zinvols van te maken. We zien hiervoor in de praktijk verschillende oplossingen: de sprint voor de testautomatiseerder wat langer maken, de sprint voor iedereen langer maken, testautomatisering beperken tot het meest noodzakelijke om toch te sprint door te komen of, en dat heeft onze voorkeur, de testautomatisering niet in dezelfde sprint realiseren als waarin de software wordt opgeleverd.

De reden voor de testautomatisering is niet, om de huidige sprint versneld door te komen. De reden voor de testautomatisering is, om de ontwikkelaars in staat te stellen vaak en snel op te leveren en de beschikbare regressietesten, met één druk op de knop, op een willekeurig moment te kunnen opstarten. Het helpt daarom enorm om een betrouwbare, omvangrijke regressietest te hebben, die automatisch in de CD/CD straat wordt aangeroepen. De testautomatiseerder voegt daar met regelmaat de nieuwste testen aan toe. Echter, testautomatisering volgt, maar loopt nooit voor op, door een testprofessional ontworpen testen. En deze testen worden gebaseerd op documentatie, proces, software of ervaring1En we weten onderhand dat proces (het beoogde gebruik van de software) en de software zelf (werken alle zichtbare functies, werkt het in vergelijking met de vorige versie goed), gecombineerd met de ervaring van de tester, hierbij het meest van belang zijn..

Om opgeleverde software goed te kunnen testen moet de tester er de nodige tijd mee kunnen doorbrengen, op ideeën komen, testen uitvoeren, situaties klaarzetten, onderzoek doen, overleg plegen, bevindingen rapporteren. In niet-agile trajecten kon dat ruim van tevoren aan de hand van uitgebreide functionele specificaties, maar nu moet dat op het oplevermoment zelf gebeuren.

De ontwikkelaars hebben, als het goed is, zelf de geautomatiseerde regressietesten al gedraaid en eventuele regressiefouten hersteld. Ook hebben zij, hopelijk, de regressietesten aangepast, als deze omwille van de aangepaste software niet meer de juiste resultaten leveren. Maar het wachten is nu op het woord van de tester.

Die tester kan, in plaats van bezig te zijn met de geautomatiseerde testen, beter doen waar hij het team het meest mee helpt en dat is testen ontwerpen en uitvoeren. Dat doet hij dan bij voorkeur ‘met de hand’ en maakt hiernaast een lijstje met aangepaste, en nieuwe testen. Dit lijstje wordt in één nieuwe user story gezet, die heet ‘Aanpassingen aan de geautomatiseerde regressietest naar aanleiding van sprint <huidige sprint>’. Deze user story bevat alle aan te passen en te vernieuwen testen in de geautomatiseerde regressietest en wordt bij de eerstevolgende refinement door het team ingeschat op punten. Omdat de user story binnen het hele team wordt besproken wordt de draagvlak voor het aanpassen van deze testen groter, en kan een grotere groep hieraan bijdragen. Het is voor de product owner ook altijd inzichtelijk, wat er moet gebeuren.

Practice your PSM I exam (English)

PSM I oefen examenvragen

Deze quiz bevat 40 vragen die representatief zijn voor het Scrum.org Professional Scrum Master I examen. Iedere keer dat deze quiz wordt uitgevoerd worden vragen gewisseld zodat iedere quiz verschillend is. Deze quiz is, evenals het officiële PSM I examen, in het Engels opgesteld. De vragen zijn gebaseerd op The Scrum Guide van Ken Schwaber en Jeff Sutherland. U kunt aan de uitslag van deze quiz geen rechten ontlenen.

Na het starten van de quiz hebt u 30 minuten de tijd om de vragen te beantwoorden.

Bij het officiële Scrum.org PSM I examen worden er 80 vragen gesteld, waarvoor u 60 minuten de tijd krijgt om deze te beantwoorden. Om te slagen dienen 68 van de 80 vragen (85%) goed beantwoord te worden. Het examen is open boek; antwoorden mogen in The Scrum Guide worden opgezocht. In de praktijk is er niet genoeg tijd om dat voor veel vragen te doen.

Oefen je TMap Suite en TMap Next Test Engineer examen

TMap Suite en TMap Next Test Engineer oefen examenvragen

Deze quiz bevat vragen die representatief zijn voor de vragen die worden gesteld voor het EXIN TMap Next Test Engineer en het EXIN TMap Suite Test Engineer examen. Iedere keer dat deze quiz wordt uitgevoerd worden vragen gewisseld zodat iedere quiz verschillend is.

Het EXIN TMap Suite Test Engineer examen bestaat uit 40 vragen, waar u 90 minuten de tijd voor krijgt om ze te beantwoorden. Bij het echte examen moet u 26 vragen goed beantwoord hebben om te slagen.

Oefen je ISTQB Foundation examen (Engels)

ISTQB Foundation oefen examenvragen

Deze quiz bevat vragen die representatief zijn voor het ISTQB Foundation examen. Iedere keer dat deze quiz wordt uitgevoerd worden vragen gewisseld zodat iedere quiz verschillend is. Deze quiz is, evenals het officiële ISTQB Foundation examen, in het Engels opgesteld.

Na het starten van de quiz hebt u 30 minuten de tijd om de vragen te beantwoorden.

Bij het officiële ISTQB Foundation examen worden er 40 vragen gesteld, waarvoor u 60 minuten de tijd krijgt om deze te beantwoorden. Deelnemers die de taal Engels niet als moedertaal hebben krijgen 15 minuten extra tijd. Om gebruik te kunnen maken van deze extra tijd dient de deelnemer hiervoor vooraf een aanvraag te doen. Om te slagen dienen 26 van de 40 vragen goed beantwoord te worden (65%).

Balanceren tussen high-level en low-level geautomatiseerde testen

24 januari 2018, eerder verschenen op TeamKPN

Bij het realiseren van geautomatiseerde CI/CD straten in onze DevOps teams ontstaat met regelmaat discussie over wat de verhouding moet zijn tussen de hoeveelheid (automatisch uitvoerbare) unittesten die door de developers met hun code wordt meegeleverd, het aantal geautomatiseerde UI-testen die door de testers, soms geholpen door developers, moeten worden gemaakt en welke testen er na het realiseren van de software nog met de hand moeten worden uitgevoerd.

Vanuit een kwaliteits- en effectiviteitsprincipe is een balans tussen snel aan te trappen geautomatiseerde testen en bedachtzame, maar vertragende handmatige testen, van levensbelang. Te veel automatiseren legt een te zware wissel op de inspanningen van het DevOps team, maar te weinig automatiseren levert een blokkade op de voortgang in de geautomatiseerde CI/CD-straat op.

Onderdeel van de balans vormt het doel van de testen: hierbij zou de kans op het vinden van fouten centraal moeten staan. Voor de 12e keer handmatige high-level regressietesten uitvoeren levert over het algemeen weinig op, terwijl tienduizend low-level unittesten geen enkel uitsluitsel over de bruikbaarheid van de UI hoeven te geven.

De pyramide van Martin Fowler, auteur van het boek Continuous Delivery, heeft precies dit doel: aanduiden dat een balans tussen ‘grote klappen, snel thuis’-geautomatiseerde UI-testen en ‘muizekeutels-op-het-tapijt’-unittesten, aangevuld met ‘sherlock-holmes’-procestesten van ‘utmost importance’ is voor een levensvatbare CI/CD-straat. Dat er idealiter veel meer snelle, doeltreffende geautomatiseerde low-level testen zijn dan procesblokkerende, handmatig uit te voeren procestesten staat buiten kijf, al was het alleen al dat er veel meer low-level testen nodig zijn om dezelfde dekkingsgraad te bereiken als met high-level testen.

In termen van kosten zit er weinig verschil tussen het maken van een UI-test en het maken van een unittest. Je zou daarom zeggen dat geautomatiseerde UI-testen het minst kosten. Op de lange termijn is dat wel zo in vergelijking met (steeds dezelfde) handmatig uit te voeren testen, maar juist niet ten opzichte van unittesten: het onderhoud aan unittesten is eenvoudiger dan het onderhoud aan UI-testen. Unittesten lijken echter problematisch te ontwikkelen zodra ‘coverage’ onderdeel van de kwaliteitsmaatstaf wordt: kwantiteit lijkt dan te prevaleren boven kwaliteit.

Het bereiken van een balans tussen de hoeveelheid en creatietijd van high-level en low-level testen is een holistisch proces, dat afhangt van de mate waarin aan bepaalde criteria wordt voldaan:

  • Beschikbaarheid van voldoende gemotiveerde teamleden voor het ontwikkelen van geautomatiseerde UI-, API- en unittesten;
  • Kwaliteit en hoeveelheid van de beschikbare geautomatiseerde testen;
  • Behoefte aan volledig geautomatiseerde testuitvoering na merge, build, deploy of releasen van software;
  • Aard en omvang van de aanpassingen;
  • Stabiliteit van de software;
  • Mate waarin het team T-shaped is en de teamleden elkaars werk kunnen ondersteunen.

In de praktijk blijkt een gezonde DevOps werkomgeving een positieve stimulans te geven op de snelheid waarmee een pragmatische balans wordt bereikt tussen ‘zware high-level testen’ en ‘lichte low-level testen’. Een balans die evenwel iedere sprint opnieuw moet worden bekeken om gaten die bijvoorbeeld ontstaan in de vorm van technical debt, op te sporen.

Test je kennis van het werken met Selenium Webdriver

Aan de slag met Selenium Webdriver en het Python unittest framework

Deze quiz bevat vragen waarmee je je kennis van het gebruik van Selenium Webdriver kunt toetsen.

Hoe staat het met je kennis van webtesten?

Testen van webtoepassingen

Met deze quiz kun je bepalen in welke mate je (al) op de hoogte bent van technieken en tools die gebruikt worden bij het testen van webtoepassingen.