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
In dit artikel
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 20 programmeertalen beschikbaar, die gebruikt kunnen worden in zowel testen als vragen:
- C: 10.2.0
- C# : 6.12.0
- C++ : 10.2.0
- Go: 1.16.2
- Java: 15.0.2
- JavaScript: 18.15.0
- Kotlin: 1.8.20
- PHP: 8.2.3
- Python: 3.10.0
- R: 4.1.1
- Ruby: 3.0.1
- Scala: 3.2.2
- SQL: SQLite 3.31.1
- Swift: 5.3.3
- Typescript: 5.0.3
In onze taalagnostische coderingstests kun je alle bovenstaande talen gebruiken, maar ook de volgende:
- Dart: 2.19.6
- Elixir: 1.11.3
- Erlang: 23.0.0
- Julia: 1.8.5
- Perl: 5.36.0
- Rust: 1.68.2
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:
|
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
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.
Taalagnostische coderingstests
Dit is beschikbaar met de Starter en Pro plans
Met onze taalagnostische coderingstests kunt u instellen uit welke programmeertalen uw kandidaten kunnen kiezen en kunt u zoveel talen opnemen als u wilt uit de 20 talen die momenteel beschikbaar zijn.
Op deze manier kunt u de vaardigheid van de kandidaat in een programmeertaal naar keuze beoordelen.
Voor een lijst van taalagnostische coderingstests, klik hier.
Voeg gewoon een taalagnostische coderingstest toe aan uw beoordeling, waarna u een scherm te zien krijgt waarmee u de coderingstalen van de test kunt kiezen. Er zijn 20 talen en u kunt er een willekeurig aantal selecteren.
U kunt de beschikbare programmeertalen in een taalagnostische coderingstoets bewerken door te klikken op de knop Bewerken naast de toegevoegde test.
Opmerking: Kandidaten kunnen de taal kiezen die ze tijdens de test gebruiken en krijgen oefenvragen en onboarding tooltips. Kandidaten kunnen ook onze configureerbare IDE (geïntegreerde ontwikkelingsomgeving) gebruiken om het kleurenthema, de venstergrootte, de schermgrootte en de lettergrootte aan te passen aan hun behoeften. |
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:
- Een lengte voor je aangepaste test kiezen
- De tekst- en formule-editor gebruiken
- Opmaken van tekstvragen