What Counts as Working Hours?

Writing your hours correctly is essential for transparency, trust, and proper planning within the team. In this quiz, you will be presented with everyday situations. Your task is simple: decide whether the time spent should be written as working hours or not.

Keep in mind that short interruptions that are part of a normal workday are included, while longer breaks or time not directly related to work are not. Think carefully about each scenario and choose the answer that best reflects our agreements.

Working hours at government projects

Working in a government project, or any structured professional environment, introduces you to the discipline of writing hours and submitting timesheets. While the mechanics of entering hours are usually straightforward, questions often arise around what exactly should be written: how many hours per day, when your working day starts and ends, and how to handle situations like sick leave, holidays, or time off.

In a typical government project, a full-time contract is based on 36 hours per week. These hours are distributed across the working week. The standard pattern is four days of 8 hours and one day of 4 hours, resulting in a total of 36 hours. In most teams, this is organized as Monday through Thursday being full 8-hour days, and Friday being a shorter 4-hour day. This structure helps ensure maximum overlap between team members, which is essential for collaboration.

Some contracts allow alternative distributions, such as four days of 9 hours, but these are exceptions rather than the rule. Regardless of the distribution, timesheets are typically submitted at the end of the working week.

In practice, not every week follows the standard pattern. Situations may arise where completing 36 hours is not possible, for example:

  • You are sick for more than half a day during the week

  • You take more than half a day off

  • There is a public or mandatory holiday

In these cases, your total written hours will be lower than 36.

However, there are also situations where you can adjust your schedule. If you are sick for part of a day or take a few hours off, you must compensate by working additional hours on Friday. A common example is extending Friday from a 4-hour day to an 8-hour day to make up missed time. In some cases, your employer may expect you to do so. Friday becomes flexible only when hours were missed earlier in the week.

This leads to an important consideration: writing hours is not just about reaching a number. It is about accurately reflecting the work you have performed within agreed working patterns and maintaining alignment with your team. Simply “filling up” a timesheet to reach 36 hours without having worked those hours is not acceptable.

Working at the office comes with a few additional expectations. On office days, team members are expected to work a full 8-hour day. This includes a mandatory 30-minute lunch break, which is not counted as working time. The office is accessible between 07:00 and 18:00, so your working hours must fit within this window. This means you need to plan your start time accordingly. For example, arriving at 10:00 makes it impossible to complete 8 working hours plus the required lunch break before closing time. In such cases, you will not reach 8 working hours for that day, and these hours cannot be compensated on other days in the same week. It is therefore your responsibility to ensure you start on time. Please also note that travel time to and from the office is not considered working time and should not be written as hours.

To help clarify these situations and ensure a shared understanding, the following quiz presents a number of realistic scenarios. For each situation, consider how many hours should be written and whether any adjustments are appropriate.

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.

Meer hulp nodig? Volg de online cursus TMap Suite Test Engineer van Online Docenten.

Oefen je ISTQB Foundation examen (Engels)

ISTQB Foundation Level Syllabus EN-NL

A B C D E F H I K L M N O P Q R S T U V W
Er staan momenteel 236 begrippen in deze lijst.

Please select a letter from the index (above) to see begrippen.

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.