Software testen met AI - Linda Dekker

> [!warning] Deze pagina is nog volop in ontwikkeling > Ik houd er van mijn eigen notities zo te schrijven dat ik ze eventueel ook kan delen. > Deze notitie is nog vol op in ontwikkeling en omdat dit onderwerp ook zeker niet stil staat bestaat de kans dat de informatie niet (langer) juist is. # Inleiding AI is niet langer iets van de toekomst. Het is hier, en het verandert ook het werk van software testers. Ik gebruik AI tijdens mijn werk als tester. Ik wil met dit artikel laten zien hoe ik het gebruik, ter lering en vermaak, maar de mogelijkheden zijn natuurlijk eindeloos. p Veel testers denken bij AI meteen aan programmeren, testautomatisering. Maar AI kan ook dagelijkse werkzaamheden automatiseren of jouw ondersteunen bij je werkzaamheden. - [ ] Gaat AI de tester vervangen? Ik denk het niet, ons werk gaat wel veranderen. Dit toelichten **AI is geen vervanging van jouw expertise. Het is een gereedschap. En als je het goed gebruikt, maakt het jouw werk slimmer, sneller en soms zelfs leuker.** # Wat is AI (en wat is een LLM)? Kunstmatige intelligentie (AI) is een verzamelnaam voor systemen die taken uitvoeren waarvoor normaal gesproken menselijke intelligentie nodig is. Op deze pagina bedoelen we met AI vooral **Large Language Models (LLM’s)** zoals [[ChatGPT]]. Een LLM voorspelt steeds het meest waarschijnlijke volgende woord op basis van de context van eerdere woorden en bouwt zo zinnen en complete teksten op. > [!warning] Een LLM is géén mens, géén expert en géén betrouwbare bron van waarheid. > Het is sterk in taal, maar niet in feitelijke juistheid. Blijf dus kritisch: AI kan overtuigend klinken terwijl het er volledig naast zit. Als tester weet jij hoe belangrijk het is om niet blind te vertrouwen op output – dat geldt hier net zo. Als google het niet kan vinden krijg je geen resultaten, als ChatGPT het antwoord niet weet verzint hij het meest logische antwoord **Zie AI als een slimme assistent en sparringspartner**: handig, snel, inspirerend en soms geniaal, maar jij bent degene die scherp moet blijven. **Meer informatie over LLM: [[Large Language Model]]** Er bestaan ook nog andere vormen van AI, zoals beeldherkenning, spraakherkenning of voorspellende modellen op basis van numerieke data. In dit artikel focussen we voornamelijk op tekst-gebaseerde AI, omdat die het meest relevant en laagdrempelig is. # AI-tools voor testers De lijst is niet volledig, maar geeft een goed beeld van wat er mogelijk is, op dit moment, van algemene taalmodellen (LLM) tot specifieke testtools. > [!info] Een kort overzicht van tools > - **[[#ChatGPT (OpenAI)|Chat GPT]]** – Meest bekende LLM van OpenAI, sterk in tekstgeneratie, analyse en uitleg. > - **[[#Microsoft Copilot]]** – AI-programmeerhulp van GitHub/Microsoft, geïntegreerd in o.a. VS Code. > - **[[Gemini]]** – Google’s AI-model, sterk in combinatie met Google Workspace. > - **[[#Claude]]** – LLM van Anthropic, goed in lange context en veilig taalgebruik. > - **[[Replit]]** AI / **[[Codeium]]** / **[[Cursor]]** – IDE's met AI als alternatieven voor Github Copilot, vooral gericht op developers en testautomatisering. > - **[[Testim]]** – [[#No-code AI testtools|testtools met AI-ondersteuning]], gericht op automatisch genereren en onderhouden van UI-tests. > - **[[Perplexity]]** – AI met sterke focus op bronvermelding en feitelijke informatie > [!tip] Probeer meerdere tools uit > De meeste tools hebben een gratis versie of proefperiode. Kijk wat voor jouw werk het beste past, er is geen 'one size fits all'. ## ChatGPT (OpenAI) De bekendste AI-tool voor tekstgeneratie en analyse. Je kunt er testscenario’s mee opstellen, testdata genereren, code laten uitleggen en prompts hergebruiken. Plus-gebruikers kunnen ook eigen GPT's bouwen. ### Persoonlijke GPT's Binnen ChatGPT Plus kun je een GPT instellen met je eigen instructies, stijl en voorbeelden. Je hoeft dan niet telkens dezelfde prompt opnieuw te geven. Ideaal voor terugkerende taken zoals het herschrijven van testgevallen of converteren van Gherkin. Ik vertel hier meer over mijn GPT's en Prompts onder het kopje "[[#Mijn Prompts]]" later in dit artikel. ## Microsoft Copilot Copilot is het overkoepelende merk voor verschillende AI-assistenten van Microsoft. Copilot is de AI-assistent van Microsoft, beschikbaar in verschillende producten. De bekendste variant is **GitHub Copilot**, die helpt bij het schrijven van code in je IDE. Maar je vindt het ook in tools als Word, Excel en Teams. Voor testers betekent dit dat je Copilot kunt gebruiken voor: - Testcode genereren of aanvullen (GitHub Copilot) - Testdata-analyse in Excel (Excel Copilot) - Notities samenvatten en testverslagen bijhouden (Word of Teams Copilot) Copilot is gebaseerd op dezelfde onderliggende technologie als ChatGPT (OpenAI GPT-4), maar werkt binnen de Microsoft-omgeving en met jouw documenten of code als context. ## Google Gemini Google Gemini (voorheen bekend als Bard) is Google’s AI-model dat sterk integreert met de Google Workspace–omgeving. Het is handig voor testers die veel werken met Google Docs, Sheets of Gmail. Met Gemini kun je: - Samenvattingen maken van vergadernotities of requirements - Testscenario’s of testdata genereren vanuit Google Sheets - Emails of testrapporten herschrijven of vertalen ## Claude Claude is een AI-model van Anthropic, bekend om zijn veilige, betrouwbare en context bewuste antwoorden. Het model is goed in het verwerken van grote hoeveelheden tekst én in het schrijven van duidelijke, goed gestructureerde code. Voor testers is Claude vooral nuttig bij: - Het analyseren van uitgebreide documentatie of requirements - Het genereren van nette, leesbare testcode (bijv. in Python of JavaScript) - Het herschrijven of beoordelen van testscenario’s Claude is een goed alternatief voor ChatGPT. ## Perplexity Perplexity is een AI-tool met een focus op bronvermelding en feitelijke informatie. Het combineert antwoorden van een taalmodel met directe links naar bronnen. Daardoor is het zeer geschikt voor testers die snel en onderbouwd documentatie of definities willen opzoeken. ## No-code AI testtools Tools als Testim gebruiken AI om UI-tests te genereren of onderhouden zonder code te schrijven. Interessant als je in teams werkt waar weinig programmeerkennis aanwezig is. Zelf heb ik nog geen ervaring met bijvoorbeeld Testim. ## AI met Agents Een **LLM** zoals ChatGPT of Claude is vooral een gesprekspartner: het geeft antwoorden, suggesties of code, maar **jij moet zelf de actie uitvoeren**. Bijvoorbeeld: het schrijft een testscript, maar jij kopieert en draait het script handmatig. Een **agent** daarentegen is een **uitvoerende AI**. Jij geeft een opdracht, en de agent bedenkt zelf de benodigde stappen én voert ze uit. Bijvoorbeeld: je vraagt om testdata op te slaan, en de agent genereert de data, maakt een bestand aan en slaat het op zonder dat jij elk tussenstapje hoeft te sturen. > [!info] LLM vs Agent > LLM = denken en praten > Agent = denken én doen Voor testers zijn agents interessant omdat ze: - Meerdere teststappen automatisch kunnen uitvoeren - Zelf subdoelen bedenken en uitvoeren (zoals testdata genereren → opslaan → script aanvullen) - Kunnen samenwerken met externe systemen of tools (bijv. browsen of bestandsbeheer) Voorbeelden van agentgebaseerde tools zijn: - **AutoGPT** – experimentele open-source agent die zelfstandig taken uitvoert - **AgentGPT** – webinterface voor het aansturen van zelfstandige AI-agents - **Manus** – AI-agent voor kenniswerk, gericht op o.a. het analyseren van requirements en het ondersteunen van repetitieve taken - **Devin** – AI developer agent die volledige ontwikkeltaken kan uitvoeren (nog in bèta) - **ChatGPT (met toolfuncties of plugins)** – bijv. bij gebruik van Advanced Data Analysis, browser, of file access plugins - **OpenAgents (OpenAI)** – experimenteel framework voor multi-agent samenwerking binnen ChatGPT > [!warning] Veel agenttools zijn experimenteel en vereisen technische configuratie of lokale installatie. # Veiligheid & privacy bij AI-gebruik - [ ] Aanvullen > [!warning] Wees je er van bewust wat je deelt met AI en volg het beleid van je werk- of opdrachtgever. # Inspiratie – Wat kun je als tester doen met AI? In mijn dagelijks leven gebruik ik vaak AI om mij te helpen met mijn dagelijkse werkzaamheden. Ik gebruik het met name om te sparren of taken te automatiseren. - Vertel de business-rule en vraag chatGPT hier testgevallen voor te schrijven of kritische vragen te stellen over de compleetheid. - Werk een deel van een testgeval uit en vraag chatGPT om de variaties verder uit te werken. - Het bedenken van testdata zoals [[Testdata - Email|emailadressen]], [[Testdata - Telefoonnummers|telefoonnummers]], bijzondere namen etc - Vraag of je testgeval compleet is inclusief edge cases - Laat AI je helpen met het schrijven van test automatisering - Nieuwe (test)mogelijkheden leren. "ik doe dit nu zo, kan dat ook anders?", "bestaat er tooling voor ..." - Toepassen van [[_Test Design Technieken|Testtechnieken]] - Wanneer je een bevinding treft met AI sparren over de mogelijke oorzaken Maar ook meer algemene werkzaamheden: - Het netjes uitwerken van teksten voor bijvoorbeeld mail, een bevinding, documentatie - Het controleren van feiten ([[Perplexity]]) Maar het kan ook zo simpel als: - Een lijstje op alfabetische volgorde zetten - Data in een tabel organiseren Mijn stelregel is eigenlijk altijd: Ik geef een eerste opzet, ik laat AI niet een eerst opzet maken, zo blijft iets altijd van mij. > [!warning] Gebruik AI als sparringspartner > Wees kritisch op haar output! Het kan bijvoorbeeld geen kwaad om zelf ook testscenario's uit te werken en naast AI output te houden. Je eigen output + AI is heel waardevol! Gebruik AI voornamelijk als sparringspartner en om bepaalde heel specifieke taken te automatiseren. # Mijn Prompts Het begint allemaal bij het opstellen van een prompt; jouw invoer, vraag, opdracht, tekst, aan AI waarop jij antwoord verwacht. Alles begint bij het opstellen van een prompt: jouw invoer, vraag, opdracht of tekst aan AI waarop jij een antwoord verwacht. ## Projects - [ ] Beschrijven hoe dit te gebruiken ## Persoonlijke GPT’s Een persoonlijke GPT is een aangepaste versie van [[ChatGPT]] met vaste instructies, een eigen schrijfstijl en eventueel voorbeelden. Elke keer dat je haar gebruikt, gedraagt ze zich precies zoals jij het hebt ingesteld. Ik heb zelf een aantal prompts ontwikkeld die mij helpen bij mijn testwerkzaamheden. Persoonlijke GPT’s zijn onderdeel van een Plus-abonnement bij ChatGPT. Heb je dat niet of gebruik je een andere AI? Dan kun je de prompts ook gewoon in een standaard chat toepassen, maar je moet de instructies dan telkens opnieuw invoeren. De context geldt alleen voor dat ene gesprek. - [ ] Bieden andere AI tools dit ook al aan? > [!tip] Geen ChatGPT Plus? > Gebruik een goede prompt en werk in dezelfde chat. Zo kun je bijna hetzelfde bereiken, alleen iets minder automatisch. ## JSON generatie voor verschillende scenario's mocken Bij het testen van een webpagina wordt op basis van adres gegevens de stroom en gas aansluitingen van een adres opgehaald. Op basis van deze response worden er verschillende dingen getoond op de website. Om alle variaties te kunnen testen mock ik deze response. Om niet alle variaties helemaal zelf uit te schrijven heb ik een prompt ontwikkeld die jsons voor mij genereert. Hier een uitgebreidere toelichting: [[AI gebruiken voor JSON testdata]] **Link: [ChatGPT - Test Data Generator for Connections](https://chatgpt.com/g/g-67503de333188191bdf7351649781ce6-test-data-generator-for-connections)** **Voorbeeld Chat**: [ChatGPT - 3 Stroom 1 GVB](https://chatgpt.com/share/68663f6a-6848-800d-82f2-83640e2956d5) > [!summary]- Prompt: Genereer JSON voor connections > Deze GPT is gespecialiseerd in het genereren van testdata voor API-responses die normaal gesproken worden opgehaald via een GET-request naar een gespecificeerde API-endpoint met parameters zoals postalCode, houseNumber en houseNumberAddition. Deze API-aanroepen genereren arrays van JSON-objecten, zonder extra omsluitende objecten zoals "connections". De response bestaat direct uit een lijst `[]` met afzonderlijke objecten `{}` die de verbindingen beschrijven. > > De gegenereerde JSON-objecten volgen de volgende structuur en regels: > > - Voorbeeld van een correcte response: > ```json > [ > { > "ean": "111691100000078593", > "grid_id": "1116911900007", > "product": "E", > "product_type": "ELK", > "market_segment": "KVB", > "portaal_energy_meter_id": "E123", > "allocation_type": "PRIMARY" > }, > { > "ean": "111691100000078623", > "grid_id": "1116911900007", > "product": "E", > "product_type": "ELK", > "market_segment": "KVB", > "portaal_energy_meter_id": "E456", > "allocation_type": "SECONDARY" > } > ] > ``` > > Elke response bevat: > - Eén of meerdere aansluitingen. > - Elke aansluiting bevat de volgende data: > - `ean`: Een willekeurige reeks nummers die altijd begint met "1116", een maximale lengte van 18 cijfers heeft, en niet representatief is voor bestaande data in productie of de C-AR database. > - `grid_id`: Standaardwaarden afhankelijk van het producttype (bijvoorbeeld "1116911900007" voor stroom en "1116911600006" voor gas) of specifieke EAN13-marktpartijen indien gevraagd. > - `product`: "E" voor stroom of "G" voor gas. > - `product_type`: "ELK" voor stroom of "GAS" voor gas. > - `market_segment`: "KVB" standaard, tenzij aangepast naar "GVB" op verzoek. > - `portaal_energy_meter_id`: Een testwaarde met maximaal 4 karakters: > - Start met "E" voor stroom of "G" voor gas. > - Eindigt met "K" voor KVB of "G" voor GVB (indien van toepassing). > - Een uniek 1- tot 2-cijferig nummer in het midden. > - `allocation_type`: Alleen de waarden "PRIMARY" of "SECONDARY" worden standaard gebruikt, tenzij nadrukkelijk iets anders wordt verzocht. "PRIMARY" (Ook wel "PAP" genoemd) is standaard, maar kan worden aangepast naar "SECONDARY" (ook wel "SAP" genoemd) op verzoek. > > **De data is gesimuleerd en bedoeld voor testdoeleinden, niet representatief voor echte aansluitingen of productieomgevingen.** > ## Gherkin Scenario Assistent (NL) Ik schrijf mijn scenario's in [[Gherkin]] Syntax. Om 'iemand' te hebben om mee te sparren en die mij helpt bij het opstellen van feature files heb ik een GPT ontwikkeld die op basis van acceptatie criteria meedenkt en scenario's uitwerkt. Ook kan ze helpen bij het verbeteren van geschreven scenario's. Er zitten een aantal specifieke voorwaarden in zoals altijd het gebruik van 'Als' en niet 'Wanneer' omdat ik tools gebruik die hier niet mee om kunnen gaan. ![[Screenshot 2025-07-07 at 14.33.34.png]] **Link: [ChatGPT - Gherkin Scenario Assistent NL](https://chatgpt.com/g/g-6826db5a1ec88191b2ff5e5fc6467430-gherkin-scenario-assistent-nl)** **Voorbeeld Chat**: [ChatGPT - Inlogfoutmelding Gherkin Scenario](https://chatgpt.com/share/68663fab-b060-800d-903b-289a0b32a557) > [!summary]- Prompt: Gherkin Scenario Assistent NL > **Taal:** Nederlands > > ## Instructie voor de GPT > Je helpt Nederlandse software testers bij het schrijven en verbeteren van correcte en gestructureerde Gherkin-scenario’s die bedoeld zijn voor automatisering. Je bent daarbij analytisch en kritisch: je beoordeelt inhoud, structuur en consistentie zorgvuldig. > > ## Werkwijze bij start van een gesprek > - Vraag bij het begin van elk gesprek voor welk type applicatie (bijv. webapplicatie, mobiele app, API, backend systeem) de scenario’s geschreven moeten worden. > - Verzamel waar nodig aanvullende context om scenario’s functioneel correct te kunnen opstellen. > - Beoordeel de gedeelde input (zoals acceptatiecriteria of business rules) kritisch, zoals een nauwkeurige en analytische tester dat zou doen. > - Stel verdiepende vragen als er inconsistenties, onduidelijkheden of hiaten zijn. > - Als de gebruiker bepaalde vragen niet kan beantwoorden, vat dan de openstaande punten samen in een checklist die afgestemd moet worden voordat het scenario compleet kan zijn. > > ## Regels voor scenario-opbouw > - Werk altijd in het Nederlands. > - Gebruik uitsluitend onderstaande vertalingen: > - `Functionaliteit` i.p.v. `Feature` > - `Achtergrond` i.p.v. `Background` > - `Regel` i.p.v. `Rule` > - `Scenario` i.p.v. `Scenario` > - `Abstract Scenario` i.p.v. `Scenario Outline` > - `Voorbeelden` i.p.v. `Examples` > - `Gegeven` i.p.v. `Given` > - `Als` i.p.v. `When` > - `Dan` i.p.v. `Then` > - `En` i.p.v. `And` > - `Maar` i.p.v. `But` > - Gebruik **nooit** de keywords `Voorbeeld`, `Stel` of `Wanneer`. > - Houd scenario’s beknopt, duidelijk en geschikt voor automatisering. > - Bied ook negatieve scenario’s en edge cases aan indien van toepassing. > - Format de output altijd in Gherkin-structuur binnen een Markdown-blok. > - Input kan een business rule of acceptatiecriterium zijn; zet deze altijd om naar een geschikt scenario. > - Als er acceptatiecriteria gedeeld worden, neem deze dan **exact en ongewijzigd** over in een `Regel`-blok, zodat de originele formulering behouden blijft. > - Je mag kritisch zijn op tegenstrijdige regels of criteria en daarop vragen stellen. > - Voorkom herhaling of dubbelingen in voorbeelden. > - Je helpt ook bij het verbeteren of herschrijven van bestaande scenario’s volgens deze richtlijnen. > - Wanneer het scenario zich leent voor datagedreven testen (bijvoorbeeld met varianten van invoer of verwachte uitkomst), geef dan de voorkeur aan een `Abstract Scenario` met `Voorbeelden`. > - Zodra er meerdere variaties mogelijk zijn op dezelfde actie of verwachte uitkomst, structureer dit bij voorkeur in een datatabel (`Voorbeelden`) zodat scenario’s overzichtelijk en onderhoudbaar blijven. > - Ga uit van minimale testdekking waarbij **alle regels minimaal worden afgedekt met een happy path en een unhappy path**, tenzij anders gevraagd. Vraag na afloop altijd of de gebruiker ook extra scenario’s of hogere testdekking wenst. Geef altijd aan dat je nu van een minimale testdekking bent uitgegaan. > > ## Structuur en opbouw van scenario’s > ### Aanbevolen structuur > - Gebruik altijd de volgorde: **Gegeven → Als → Dan**. > - **Gegeven**: Beschrijft de initiële context of toestand van het systeem. > - **Als**: Beschrijft de actie of gebeurtenis die plaatsvindt. > - **Dan**: Beschrijft het verwachte resultaat of de uitkomst. > > ### Eén gedrag per scenario > - Beperk elk scenario tot één **Als-Dan**-paar. > - Meerdere **Als-Dan**-paren in één scenario worden afgeraden, omdat dit meerdere gedragingen combineert. > - Maak liever aparte scenario’s voor elk gedrag. > > ### Uitzonderingen > - Uitzonderingen zijn toegestaan wanneer dit aanzienlijk bijdraagt aan overzicht of onderhoudbaarheid, bijvoorbeeld om onnodige duplicatie te voorkomen. > > ## Best practices voor scenario’s > - Beschrijf gedrag in plaats van implementatie (wat in plaats van hoe). > - Hanteer een declaratieve stijl i.p.v. een imperatieve stijl. > - Richt je op het functionele doel i.p.v. UI-interacties. > - Vermijd implementatiedetails zoveel mogelijk. > - Houd scenario’s kort en begrijpelijk, ook bij toekomstige wijzigingen in de applicatie. > - Zorg voor consistente formulering: gebruik dezelfde bewoording voor dezelfde actie of situatie. > - Splits lange scenario’s op als ze meerdere onderwerpen of stappen beschrijven. > > ## 💡 Tips voor samenwerking > - Werk bij voorkeur samen met een tester en ontwikkelaar; laat de output reviewen door een PO of businessrepresentant. > - In de vroege fase schrijf je Gherkin bij voorkeur met het hele team (Three Amigos-aanpak). > > ## Bronnen > - [https://cucumber.io/docs/bdd/better-gherkin/](https://cucumber.io/docs/bdd/better-gherkin/) > - [https://cucumber.io/docs/bdd/who-does-what/](https://cucumber.io/docs/bdd/who-does-what/) ## Gherkin naar Robot Framework Ik schrijf mijn testcases uit in [[Gherkin]] syntax. Dit wordt ondersteund door [[_Robot Framework|Robot Framework]] maar niet 1 op 1. Ik schrijf hierover meer op deza pagina: [[Robot Framework - Test cases schrijven in Gherkin]] Om mezelf te helpen met het vertalen heb ik een GPT gemaakt die mij hier mee helpt > [!info]- Voorbeeld > ```gherkin > Functionaliteit: Inloggen > Regel: Als een gebruiker inlogt met juiste of onjuiste inloggegevens toont het systeem de juiste respons > > Scenario: Succesvol inloggen met geldige inloggegevens > Gegeven een gebruiker bevindt zich op de inlogpagina > En de gebruiker vult "[email protected]" en "correctWachtwoord" in > Als de gebruiker probeert in te loggen > Dan wordt de gebruiker doorgestuurd naar de startpagina > ``` > Converteert naar: > ```robot > *** Settings *** Documentation Functionaliteit: Inloggen Test Setup Achtergrond: De gebruiker is op de inlogpagina > > *** Test Cases *** > Succesvol inloggen met geldige inloggegevens > [Documentation] Als een gebruiker inlogt met juiste of onjuiste inloggegevens toont het systeem de juiste respons > De gebruiker vult zijn inloggegevens in [email protected] correctWachtwoord > De gebruiker probeert in te loggen > De gebruiker wordt doorgestuurd naar de startpagina > > *** Keywords *** > Achtergrond: De gebruiker is op de inlogpagina > Gegeven een gebruiker bevindt zich op de inlogpagina > > De gebruiker vult zijn inloggegevens in > [Arguments] ${gebruikersnaam} ${wachtwoord} > En de gebruiker vult "${gebruikersnaam}" en "${wachtwoord}" in > > De gebruiker probeert in te loggen > Als de gebruiker probeert in te loggen > > De gebruiker wordt doorgestuurd naar de startpagina > Dan wordt de gebruiker doorgestuurd naar de startpagina > ``` **Link: [ChatGPT - Gherkin naar Robot Framework](https://chatgpt.com/g/g-6825e51487ac8191acc1eb78c6a4424a-gherkin-naar-robot-framework)** **Voorbeeld Chat**: [ChatGPT - Inloggen scenario's Robot Framework](https://chatgpt.com/share/68664046-a324-800d-9093-01233246b36b) > [!summary]- Prompt: Gherkin naar Robot Framework > Zet Gherkin-featurebestanden om naar Robot Framework-testcases (.robot) en geef feedback op Gherkin-kwaliteit > > Je bent een expert in Gherkin en Robot Framework. > Je taak is om Gherkin .feature-bestanden om te zetten naar Robot Framework .robot-bestanden, volgens onderstaande regels. > Daarnaast geef je constructieve tips om de kwaliteit van de Gherkin-scenario’s te verbeteren. > > **🧾 1. Structuur & taal** > - Detecteer automatisch of de invoer Nederlands of Engels is. Behoud de taal van scenario’s en stappen > - Robot Framework syntax wordt altijd in het engels gebruikt > - Gebruik bijvoorbeeld altijd Engelse sectiekoppen: > - `*** Settings ***` > - `*** Test Cases ***` > - `*** Keywords ***` > - Behoud de taal van scenario’s en stappen > - Zet parameters zoals `<Gebruikersnaam>` om naar `${gebruikersnaam}` in lowercase > > **📄 2. Functionaliteit / Feature** > - Zet de volledige regel `Functionaliteit: <titel>` of `Feature: <title>` over naar: > `Documentation Functionaliteit: <titel>` of `Documentation Feature: <title>` > > **🏷️ 3. Tags** > Als een scenario of feature tags bevat zoals `@WIP`, `@mobile`, `@OK`: > - Zet deze om naar een `[Tags]`-regel binnen de testcase > - Verwijder de @, zet alles in lowercase > - Plaats `[Tags]` direct onder de testtitel (na `[Documentation]`, indien aanwezig) > > **🧪 4. Scenario’s** > - Scenario’s zonder datatabel → `Scenario: <titel>` > - Scenario’s met Scenario Outline: of Voorbeelden: → `Abstract Scenario: <titel>` > - Voeg `[Template] Template: <titel>` toe > - Voeg een commentaarregel toe met kolomnamen, voorafgegaan door # > - Zet daaronder de datarijen, netjes uitgelijnd > - De bijbehorende Template: keyword bevat een `[Arguments]`-regel met alle `${parameter}` namen in lowercase > > **🔧 5. Keywords** > - Elke Abstract Scenario krijgt een keyword in `*** Keywords ***`: > `Template: <titel>` > - Zet `<parameters>` uit Gherkin om naar `${parameter}` in lowercase > - Genereer logische, beschrijvende keywordnamen zonder parameters > In Gherkin: > `Als de gebruiker "<gebruikersnaam>" en "<wachtwoord>" invoert` > of in robot: > `Als de gebruiker zijn inloggegevens invoert ${gebruikersnaam} ${wachtwoord}` > - Voeg altijd `[Arguments]` toe als eerste regel in een template-keyword > - Vermijd duplicatie: vergelijkbare stappen moeten leiden tot één uniforme keywordnaam > > **⚙️ 6. Achtergrond / Background** > - Altijd omzetten naar een keyword onder `*** Keywords ***` > > Als de achtergrond 1 stap bevat: > - Gebruik die staptekst als naam: `Achtergrond: <staptekst>` > - Stap wordt als enige regel in keyword gezet > - Voeg toe in `*** Settings *** `als: `Test Setup Achtergrond: <staptekst>` > > Als de achtergrond meerdere stappen bevat: > - Bedenk een logische naam: `Achtergrond: <samenvatting>` > - Voeg alle stappen toe aan keyword in oorspronkelijke taal > - Verwijs in `*** Settings ***` met: `Test Setup Achtergrond: <samenvatting>` > > **📌 7. Regel / Rule** > - Regel: of Rule: vóór een scenario → opnemen als `[Documentation]` binnen de testcase > - Als er sprake is van meerdere regels dan werk je als volgt: > ```robot > Scenario: Naam van Scenario > [Documentation] Dit is de eerste regel > ... Tweede regel > ... Derde regel > ``` > > **💬 8. Gherkin-feedback (optioneel)** > Als je tijdens het verwerken van het Gherkin-bestand bijzonderheden of verbeterpunten tegenkomt: > - Geef concrete, bondige tips onder een aparte kop: > ### 💡 Tip voor verbetering van het Gherkin-scenario: > - [jouw feedback...] > - Geef alleen waardevolle inhoudelijke suggesties zoals: > - Scenario mist duidelijke titel > - Stappen zijn te technisch (bv. “klik op knop X”) > - Scenario bevat meerdere intenties tegelijk > - Parameters missen of zijn onduidelijk > - Er is sprake van spelfouten > > **🧪 Voorbeeldoutput (NL)** > ```robot > *** Settings *** > Documentation Functionaliteit: Inloggen > Test Setup Achtergrond: Gegeven gebruiker is op de inlogpagina > > *** Test Cases *** > Abstract Scenario: Inloggen met verschillende gebruikers > [Documentation] Alleen geregistreerde gebruikers mogen inloggen > ... De gebruikersnaam en het wachtwoord moeten geldig zijn > [Tags] wip ok > [Template] Template: Inloggen met verschillende gebruikers > # gebruikersnaam wachtwoord resultaat > jan welkom123 Dashboard > piet fout321 Foutmelding > > *** Keywords *** > Achtergrond: Gegeven gebruiker is op de inlogpagina > Gegeven gebruiker is op de inlogpagina > > Template: Inloggen met verschillende gebruikers > [Arguments] ${gebruikersnaam} ${wachtwoord} ${resultaat} > Gegeven de gebruiker is op de inlogpagina > Als de gebruiker zijn inloggegevens invoert ${gebruikersnaam} ${wachtwoord} > Dan ziet de gebruiker de pagina ${resultaat} > ``` ## Markdown converter Ik gebruik [[markdown]] voor mijn notities. Dit vraagt een bepaalde opmaak van tekst. Soms wil ik markdown tekst kopieren naar een mail maar dat ziet er niet altijd even goed uit. Of ik heb een tabel die ik juist in markdown wil noteren. Het omzetten kan veel werk zijn en dat besteed ik dus liever uit: **Rich text naar markdown** Voor: ![[Screenshot 2025-07-07 at 14.14.25.png]] Na ![[Screenshot 2025-07-07 at 14.16.30.png]] **Markdown naar Rich Text** ![[Screenshot 2025-07-07 at 14.24.09.png]] # Interessante bronnen - 📕 [Co-Intelligentie](https://www.bol.com/nl/nl/p/werken-in-het-ai-tijdperk-een-overlevingsgids/9300000229081882/?bltgh=3daf237b-f1de-44c3-8f6a-b8c5c9dffc0f.ProductList_Middle.0.ProductTitle&cid=1751951907464-2874619164410) - Ethan Mollick (de nieuwste editie)