In deze nieuwsbrief:

Password strength explained – deze blogpost gaat wat dieper in op sterke wachtwoorden en waarom ze belangrijk zijn.

Een sterk wachtwoord is belangrijk om je accounts te beveiligen. Maar er zijn nog een aantal dingen belangrijker die een sterk wachtwoord nog teniet kunnen doen. Het belangrijkste is om een wachtwoord niet voor meerdere websites of logins te hergebruiken. Je kunt er op rekenen dat websites niet goed op hun beveiliging letten en dat inloggegevens gestolen worden. Als je dan overal hetzelfde wachtwoord gebruikt, maakt het niet uit hoe sterk het is.

Een wachtwoordmanager zoals Bitwarden is dan onmisbaar. Je bedenkt een sterk wachtwoord voor Bitwarden en dit programma genereert voor iedere website weer een nieuw sterk wachtwoord.

Het is ook belangrijk om tweefactor authenticatie aan te zetten (zeker voor het e-mailadres dat je gebruikt voor je “wachtwoord vergeten” e-mails). Daarnaast moet je je wachtwoorden niet laten stelen in een phishing aanval.

Simpel gezegd is een sterk wachtwoord een lang wachtwoord dat niet in het woordenboek staat of op lijsten met veelvoorkomende wachtwoorden. Je kunt daarom beter een wachtzin (passphrase) gebruiken dan een wachtwoord. Dit zorgt ervoor dat als een database met versleutelde wachtwoorden wordt gestolen dat een hacker zeer lang bezig zou zijn om jouw wachtwoord te raden.

Voor normale mensen en normale accounts is een wachtzin van vier woorden voldoende (bijvoorbeeld “correct horse battery staple” van de afbeelding hierboven). Voor belangrijke accounts (met veel geld erop) of belangrijke personen is vijf woorden voldoende en leiders van landen / grote organisaties kunnen beter zes woorden kiezen.

Hopelijk leest Donald Trump ook deze nieuwsbrief, want hij had voor zijn Twitter wachtwoord blijkbaar “yourefired” en “maga2020!” volgens Nederlandse hackers.

The best user story! – Dit artikel beschrijft zes manieren waarop een user story slecht kan worden.

1. De requirements worden te abstract en high-level opgeschreven – wanneer bijvoorbeeld 1 persoon uit het team weet wat er moet gebeuren en de rest daarop vertrouwd. Dit zorgt ervoor dat de story niet vanuit alle perspectieven bekeken wordt en niet goed ingeschat en gemaakt kan worden.
2. Acceptatiecriteria beschrijven ieder mogelijk scenario – als het team alle scenario’s gaat uitschrijven is er minder tijd en energie voor discussie van het hele team. Het gevaar is ook dat er dan door developers en testers wordt gedacht dat de story helemaal volledig is en er niet meer wordt nagedacht en aangevuld bij de implementatie.
3. Niet goed de business waarde omschrijven – het team is minder betrokken bij een feature als de business waarde niet helder is. Het het uitdenken en implementeren wordt hierdoor minder goed. Dit gebeurt ook door niet het gebruik en feedback na livegang te laten zien.
4. Story wordt beschreven voor degene die zich het meeste laat horen – dit gebeurt net als punt 1 wanneer er 1 persoon is die er het meest vanaf weet. Vragen van anderen worden niet behandeld. De story is teveel afhankelijk van die ene persoon.
5. Beschrijving van een user story is een of twee regels – er kan een lange discussie zijn in het team zonder dat de story wordt bijgewerkt. Of het is heel technisch en de story is weer teveel afhankelijk van 1 persoon.
6. Product owner dicteert de story – als de PO exact vertelt hoe het moet worden kan het ook zijn dat de business analyst wordt overgeslagen en niet de juiste stappen worden doorlopen om een story voor te bereiden

Als je deze valkuilen in de gaten houdt kun je ervoor zorgen dat alle teamleden hun bijdrage kunnen doen aan een story. Hierdoor kunnen problemen vroeg gevonden worden.

Should You Create Automation For Each Negative API Scenario? – Is het bij het testen van API’s nodig om ieder negatief scenario ook af te dekken? Het is met de meeste API testtools wel makkelijk, maar is het ook verstandig? En welke zou je dan wel en welke niet moeten doen?

Pluralsight tip van de maand: Introduction to SQL – of je nu nog nooit iets hebt gedaan met SQL of juist je skills weer wilt opfrissen: deze introductiecursus leert je de basics van SQL. Voor meer verdieping kun je ook andere cursussen van het MySQL path volgen.