Maken van een programmeervraag of -test – Dutch

Artikel 5 uit 5 over het maken van je eigen testen.

Dit is het vijfde artikel in een reeks van vijf, om je te helpen eigen testen te maken met behulp van het TestGorilla-platform. De volledige reeks omvat:

Ontwikkelen van een effectieve assessment
Kiezen van verschillende soorten vragen
Schrijven van situationele beoordelingsvragen
Maken en gebruiken van je eigen test
Maken van een programmeervraag of -test (optioneel)

De optie om je eigen testen toe te voegen is beschikbaar voor accounteigenaren, admins en recruiters die beschikken over Pro-pakketten.

Wanneer je een eigen test maakt, raden we je aan eerst een schets te maken voordat je deze op het TestGorilla-platform plaatst. Dit helpt ervoor te zorgen dat alles goed georganiseerd en ingedeeld is zoals jij dat wil.

Leestijd ca. 8 minuten

Wat is een programmeervraag?

Programmeertesten en vragen worden gebruikt om het vermogen te beoordelen van een kandidaat om binnen een bepaalde tijdslimiet code in een bepaalde taal te maken of te debuggen. Voor de meeste programmeertalen ontwikkelen we testen in de volgende categorieën:

Algoritmisch denken (bv. zoeken, sorteren, recursie, iteratie)
Taalspecifieke concepten (bv. datastructuren, objectgeoriënteerd programmeren)
Debuggen

Het belangrijkste verschil tussen een programmeertest en een programmeervraag is dat de test een bibliotheek met programmeervragen bevat en dat ons platform hieruit een keuze zal maken. Een programmeervraag wordt afzonderlijk gepresenteerrd, als onderdeel van het deel Aangepaste vragen.

Wie kan een programmeervraag aanmaken?

Elke gebruiker met de rol Eigenaar, Admin en Recruiter kan een aangepaste programmeertest of -vraag maken. Vanwege de technische aard van programmeertesten moet je de vragen laten maken door een expert in de vereiste programmeertaal.

Opmerking: TestGorilla kan je niet helpen met de inhoud van je aangepaste testen. Elke test die je maakt moet een originele creatie zijn.

Beschikbare programmeertalen

Er zijn momenteer 15 programmeertalen beschikbaar, die gebruikt kunnen worden in zowel testen als vragen:

Java: OpenJDK 12
C: GCC 10
C++: G++ 10
C#: SDK 3.1.300
Go: 1.16
JavaScript: Node 13
PHP: 7.4
Python: 3.8
Ruby: 3
SQL: SQLite 3.31.1
Typescript: 4.3.4
Kotlin:
R:
Scala:
Swift:

Opmerking: Per test of vraag kan slechts één programmertaal gebruikt worden.

Een programmeervraag maken

Programeervragen kunnen op twee manieren gebruikt worden:

Als onderdeel van je vragenbibliotheek voor een Mijn bedrijfstest.
Als aangepaste vraag, toegevoegd in Stap 3: Vragen toevoegen tijdens het aanmaakproces van een assessment.

Het proces van het maken van je programmeervraag is hetzelfde, ongeacht welke methode je volgt. Elk van de gekoppelde handleidingen gaat dieper in op hoe je de vereiste fase kunt bereiken. Deze handleiding leidt je door het proces van het gebruik van de vraageditor om je programmeervraag te maken.

Je taal selecteren

In het eerste scherm dat je te zien krijgt na het starten van de vrageneditor, kun je een programmeertaal kiezen. Er zijn 15 talen om uit te kiezen, kies er een uit het raster om naar het volgende scherm te gaan.

Opmerking:

Als je een Mijn bedrijfstest maakt, moet de taal hetzelfde blijven voor alle programmeervragen binnen de test.
Als je aangepaste vragen gebruikt, kun je voor elke vraag een andere taal kiezen.

Vrageneditor

De vrageneditor staat op het volgende scherm. Het tekstvak aan de linkerzijde van de pagina is waar je de testbeschrijving schrijft. Dit levert de details die je kandidaat nodig heeft om de oefening te kunnen voltooien. Je kunt de tekst opmaken met de werkbalk bovenaan het vak. Hiermee kun je belangrijke tekstpassages benadrukken.

Schrijven van de testbeschrijving

We raden aan je testbeschrijving op te delen in vijf stappen:

	Geef wat context en het uiteindelijke doel van de programmeeropdracht. Dit brengt de vraag tot leven en is nodig voor de kandidaat om de bedoeling van de programmeeropdracht te begrijpen. Hier staat een goed voorbeeld van hoe dit er uit zal zien:
	Formuleer helder wat de kandidaat moet doen. Laten we voor dit voorbeeld zeggen dat de kandidaat een functie moet schrijven. Specificeer De output: wat moet de functie retourneren? De argumenten van de functie (de input) Werkend met het bovenstaande scenario, volgt hier een voorbeeld:
	Geef een voorbeeld van input en output dat voldoet aan de eisen. Dit kan er ongeveer zo uitzien:
	Voeg relevante informatie toe. In ons kluis-voorbeeld is dit bijvoorbeeld:
	Optioneel: Voeg eventuele hints of andere overwegingen toe. Dit is in de meeste gevallen niet nodig, maar het kan iets zijn dat je wil toevoegen.

Codespecifieke informatie invoeren

Op de rechterzijde van de pagina kun je codespecifieke informatie invoeren. Er zijn 4 tabbladen die je moet invullen:

Functiesignatuur

Hier kun je het type variabele instellen dat de functie retourneert, de naam en de inputparameter(s). Je kunt uit de volgende parametertypes kiezen:

String
Integer
Boolean
Float
Array (ingevoerd als door komma's gescheiden waarden zoals 1,2,3,4,5)

Opmerking: Objecten worden niet ondersteund als functieparameter.

Initiële code

De initiële code is het startpunt voor kandidaten. Deze toont de functiesignatuur. Je kunt code toevoegen als startpunt, als de opdracht daarom vraagt. Geef aan of van de kandidaten verwacht wordt dat ze eigen code invoegen.

Opmerking: dit is niet nodig als je een debugging-opdracht ontwikkelt.

Testcases

Testcases zijn combinaties van invoer- en uitvoerparameters die voldoen aan de vereisten die je in de vraag hebt opgegeven. Onder dit tabblad vind je twee kopjes:

Testcases die tijdens de test gebruikt moeten worden. Dit zijn testcases waartoe de kandidaat toegang heeft tijdens de test. Ze helpen de kandidaat om de programmeertaak met succes te voltooien, aangezien kandidaten hun code tijdens de oefening kunnen testen aan de hand van deze testgevallen.

Als de kandidaat tijdens de codeeroefening op uitvoeren klikt, wordt de code die ze hebben geschreven uitgevoerd met de invoerparameters die zijn gespecificeerd in elk van deze testgevallen.

Als de code een resultaat retourneert dat overeenkomt met de resultaten die jij hebt opgegeven, is de testcase geslaagd en krijgt de kandidaat dit te horen. Als hun code faalt, krijgen ze dat ook te horen; dit stelt hen in staat om fouten te zoeken en bewerkingen uit te voeren voordat ze een definitief antwoord indienen.

Deze testcases moeten eenvoudig zijn. 4 is het minimum.

Testcases die voor validatie gebruikt moeten worden. Dit zijn testcases die gebruikt zullen worden om de uiteindelijke testscore te bepalen. Ze worden niet gebruikt tijdens de assessment, dus kandidaten kunnen hun code niet vergelijken met deze testcases.

Deze testcases moeten alle vereisten dekken die in je scenario zijn uiteengezet, inclusief uitzonderingen, randgevallen, enz. We raden aan om er 6-10 te maken afhankelijk van de complexiteit van de vraag.

De Nauwkeurigheidsscore is het percentage van geslaagde validatietestcases.

Je kunt ook testcases toevoegen om te meten hoe efficiënt de code is. Deze testcases bepalen de Prestatiescore en tonen het % van geslaagde prestatietesten.

De prestatie wordt bepaald door de runtime die nodig is om de testcase uit te voeren, in milliseconden. De code van de kandidaat doorstaat de prestatietest als de runtime van de code volledig is uitgevoerd binnen de door jou ingestelde tijdslimiet.

Een prestatietestcase is relevant voor programmeertesten waarbij schaalbaarheid belangrijk is. Je kunt zien hoeveel tijd het kostte om een prestatietest uit te voeren wanneer je de verificatiecode uitvoert (zie hieronder):

Verificatiecode

De verificatiecode is in essentie het modelantwoord. Je moet het coderen en uitvoeren om er zeker van te zijn dat al je ingevoerde testcases slagen. Pas dan kun je de vraag opslaan.

Nadat de kandidaat de test heeft voltooid, zal er een codeerrapport zijn met de code van de kandidaat en het resultaat van de validatietestgevallen die de score bepalen. Meer over het programmeertestrapport kun je hier lezen.

SQL-testen

SQL-testen zijn enigszins verschillend, gezien de extra database-component in de test. Hier zie je het doel van de verschillende tabbladen bij het schrijven van een SQL-test:

Databasestructuur. Hier kies je of je de kandidaat vraagt om een query te schrijven — met SELECT — of een database update — met INSERT, UPDATE of DELETE.
Dit tabblad is ook waar je de initiële database zult scripten door de tabel(len) te maken en de juiste waarden in te voegen. In de meeste gevallen moet je de initiële databasestructuur als een codeblok in de testbeschrijving kopiëren. Anders hebben de kandidaten geen idee hoe de database gestructureerd is en wat er in staan.
Initiële code. Hier kun je een paar eerste regels code invoegen, als dat nodig is voor je opdracht.
Testcases. Zoals hierboven vermeld worden testcases opgesplitst tussen testcases die beschikbaar zijn voor de kandidaat — Testcases die tijdens de test moeten worden gebruikt — en testcases die worden gebruikt om de correctheidsscore te bepalen — Testcases die moeten worden gebruikt voor validatie.

Het grootste verschil met het schrijven van SQL-vragen zit in de opbouw van testcases. Bij het schrijven van testcases kun je aanvullende waarden in de database invoegen in de Testcase configuratie. Deze setup is een script dat direct na het maken van de databasestructuur wordt uitgevoerd, maar vóór de kandidaatcode. De verificatiecode werkt op dezelfde manier als bij andere programmeervragen: dit is het modelantwoord en het moet schoon en efficiënt zijn.

Bij het schrijven van een SQL-testcase, is het een goed idee om de volgende stroom in gedachten te houden.

In het geval dat je de kandidaat vraagt om een zoekopdracht te maken, definieer je het verwachte resultaat van de zoekopdracht gezien de databasestructuur en de testcase-configuratie, zoals in figuur 1 hieronder.

Figuur 1: Volgorde van SQL-scripts die worden uitgevoerd wanneer een kandidaat wordt gevraagd een query te schrijven (met SELECT)

In het geval dat je de kandidaat vraagt om een database-update te schrijven, moet je ook een controlequery schrijven. Deze query zal worden uitgevoerd na de code van de testnemer.

In Resultaat specificeer je wat de controlequery moet retourneren. Zie figuur 2.

Figuur 2: Opeenvolging van SQL-scripts die worden uitgevoerd wanneer een kandidaat wordt gevraagd een database-update te schrijven (met INSERT, UPDATE of DELETE)

Opmerking: Elke testcase herschept de database. Testcases zijn daarom geïsoleerd van elkaar.

Opslaan van je vraag

Het makkelijkste onderdeel van het proces! Wanneer je alle gegevens hebt ingevoerd, klik je op de knop Opslaan in de rechterbovenhoek van het scherm.

Ons platform voert eerst al je code uit om ervoor te zorgen dat er geen fouten zijn. Je krijgt een foutmelding als er een wordt gedetecteerd - je moet alles opnieuw doorlopen om je fout te corrigeren.

Als het opslaan gelukt is, zal het vrageneditor-scherm afsluiten en terugkeren naar het vorige scherm.

Veel voorkomende vragen

Waarom moet ik meerdere programmeervragen voor mijn test maken?

Zo kan ons platform elke keer dat je test wordt gebruikt, een andere vraag stellen. Als je kandidaten hebt die je test al eerder hebben gedaan, hebben zij een voordeel ten opzichte van anderen, omdat zij de inhoud van de test al van tevoren weten. De beschikbaarheid van meerdere vragen voorkleint het risico dat dit gebeurt.

Moet ik een programmeertest of een aangepaste programmeervraag gebruiken?

Dit is afhankelijk van je behoeften. Als je regelmatig kandidaten screent voor dezelfde ontwikkelaarsrol, is het misschien beter om de tijd te nemen om een volledige bedrijfstest te maken, zodat je het proces niet snel opnieuw hoeft te doen. Als je echter maar één of twee vragen nodig hebt en de ruimte hebt binnen de toegewezen aangepaste vragen van je pakket, kan dat gemakkelijker zijn.

Zit er een grens aan het aantal programmeertesten of vragen die ik bij mijn assessment kan gebruiken?

Je assessment kan maximaal 5 testen bevatten en - afhankelijk van je pakket - tot wel 20 aangepaste vragen. In theorie kun je 5 programmeertesten en 20 aangepaste programmeervragen in je assessment gebruiken. Houd alleen rekening met de totale lengte van je assessment; het is onwaarschijnlijk dat een kandidaat jouw assessment maakt als ze er 12 uur aan moeten besteden!

Volgende stappen

Hoewel niet opgenomen in deze serie, hebben we andere artikelen die nuttig zijn bij het maken van je eigen test die het bekijken waard zijn. Dit zijn: