Auteur: Erik Bits

TestNet Leergang: Share your Brains

Geschreven door Erik Bits op 9 juni 2017. Gepost in ISO 25010 Categorien, KOM.

De vereniging TestNet verbindt testprofessionals uit het gehele land, van diverse bedrijven en van ieder niveau. Zij doen dit door op regelmatige basis Thema-avonden te organiseren, door trainingsmogelijkheden zoals de werkgroepen en TestNet Summerschool. Daarnaast is TestNet voortdurend op zoek naar nieuwe vormen waarbinnen de leden met en van elkaar kunnen leren. Zo kwam het dat 2B4QA, begin 2017 gevraagd werden om pilot uit te werken voor een nieuwe werkvorm: De TestNet Leergang.

Ons concept was vrij simpel: Vijf avonden lang werken vier parallelle groepen aan een specifiek topic binnen een vastgesteld kader. Het doel is een concreet, bruikbaar eindproduct. Iedere deelnemer kiest op de avond zelf aan welk onderwerp hij of zij wil bijdragen. Je kiest zelf aan welk product jij je hersenen wilt uitlenen: Share your Brains.

Het benoemen van het onderwerp, het schetsen van de context en het definiëren van de verschillende vraagstellingen en het daadwerkelijke eindproduct is feitelijk het lastigste van de gehele leergang. Wat is actueel? Wat is voor een ieder interessant? Wat is nog niet eerder volledig uitgewerkt? Bernd en ik besloten op de toepassing van kwaliteitszorg binnen een continuous integration pipeline eens onder de loep te nemen. Dit leidde tot de volgende beschrijving:

ISO-SQuaRe binnen CI/DevOps

Functionaliteit is de meest belangrijke eigenschap van ieder object. De functionaliteit bepaalt of dit object nuttig is of juist niet. Zo’n object kan van alles zijn: bijvoorbeeld een koffiezetapparaat, een auto, een mobiele telefoon, een stoel of software. In het kader van leergang doelen we op de functionaliteit van de laatste, de software. Deze software kan een interface, een Graphical User Interface (GUI), een webapplicatie of zelfs een compleet informatiesysteem zijn. Voor al deze onderdelen geldt: de functionaliteit beschrijft ‘wat’ de software moet doen. Vervolgens zijn het de compleetheid, correctheid en toepasbaarheid die bepalen op welk niveau de software geschikt is voor haar doel. Dus functionaliteit is uitermate belangrijk. Maar hoe zit het met de andere categorieën, de hoedanigheden van de software? Hoe krijgen we de overall kwaliteit op orde?

Hoe kunnen we verschillende non-functional testen integreren in een continuous delivery pipeline of een continuous integration proces? Want moeten testen als installability, maintainability niet naast performance en security in een CI-pipeline? Tijdens deze leergang ontwikkelen we samen een wijze waarop verschillende onderdelen van ISO-SQuaRE en de toepassing van de kwaliteitsattributen (ISO 25010) binnen DevOps-team worden samengevoegd.

De nadruk ligt op de testfase (model 2501x). Hoe kunnen we bijvoorbeeld een PRA uitvoeren binnen een Agile omgeving? Hoe gaan we om met risico-classificatie aan de hand van pokerkaarten en hoe kunnen we functionaliteit en hoedanigheden beoordelen vanuit verschillende rollen (product owner, beheer, development team, architectuur) binnen een continuous integration pipeline?

De Uitvoering

22 maart vond de kick-off plaats. Als vanzelf ontstonden vervolgens de parallelle groepen waarbinnen in de opeenvolgende avonden interessante discussies plaatsvonden, menig idee werd uitgewerkt en het eindproduct langzaam maar zeker vorm begon te krijgen. Wat is de minimale uitgangspositie voor een continuous integration pipeline? Hoe ga je om met een product risico analyse in een DevOps-organisatie? Hoe verhouden de functionaliteiten zich ten opzichte van de karakteristieken van de te ontwikkelen software? Welke relatie bestaat er tussen productkwaliteit, datakwaliteit en de kwaliteit van het informatiesysteem in gebruik?

Het resultaat

Wat ons betreft is de pilot geslaagd. Het is gebleken dat het oprecht gebruik maken van elkaars kennis en kunde zonder de vraagstelling ter discussie te stellen en met de vrijheid om op ieder moment van onderwerp te kunnen wisselen het mogelijk maakt om heel snel resultaten op te leveren. Het rouleren zorgt voor dynamiek en frisse, verrassende inzichten. Een van te voren vastgestelde doorlooptijd (in dit geval 5 avonden) zorgt voor een duidelijke deadline en vergroot de betrokkenheid. Je weet per slot van rekening waaraan je je verbindt. En dat was dan alleen nog maar de werkvorm. Wat dacht je van de eindproducten?

Op de laatste avond zijn de resultaten gepresenteerd. Een modulaire opbouw voor een continuous integration pipeline, een PRA binnen DevOps-teams en een matrix waarbinnen het verband tussen de verschillende ISO 250xx-normen is uitgewerkt. Mooie, bruikbare producten. Ben jij nieuwsgierig naar het resultaat? Neem dan eens een kijkje in de bibliotheek van TestNet of kom naar TestNet Werkgroepen Presentatie. Wij zullen daar onze resultaten nogmaals aan een breder publiek presenteren

Devops ervaringen/tips voor beginnende devopsers

Geschreven door Erik Bits op 7 maart 2017. Gepost in Continuous Learning.

Vanaf augustus ben ik in een devops-team gekomen. In eerste instantie was dit team opgericht om de openstaande problemen en incidenten voor de ontwikkelstraat op te ruimen. Voor ons, de devopersers, bestaat deze straat uit 4 scrumteams, productie-incidenten en -problemen en een zijstraat met nog eens 4 teams. Wij zouden deze straat gaan ondersteunen door onopgeloste problemen en niet functionerende software aan te pakken en werkend te maken. Een taskforce die geen functionaliteit zou gaan opleveren, maar problemen van bestaande functionaliteit en ook van de nieuw opgeleverde functionaliteit zouden gaan oplossen om zo het gehele product te verbeteren.
Natuurlijk is dit voor 1 team onmogelijk, maar toch zijn we vol moed en toewijding begonnen met het analyseren van de problemen. Hieruit kwamen nogal wat lijstjes en deze lijstjes verdwenen weer bij een directielid in de la.
Deze lijstjes leek ons niet echt taskforce, laat staan devops. Dus zijn we begonnen om die lijstjes los te laten. Ze te leggen bij de mensen die ze wilden hebben en ons daarmee maar moesten aansturen. Wij gingen ons in de straat zetten als één van de teams. Hierdoor dwongen we onszelf om weer te gaan scrummen. Een goede keuze voor het team. We werden namelijk een team. Een groep die weet waar de expertises liggen en wie er aangesproken moeten worden voor welke problemen. Dit werd het kenmerk voor mij om het team te bekijken als devops. Een team met ontwikkelaars, ofwel developers, en met beheerders, ofwel operations. Zo kunnen de ontwikkelaars makkelijk schakelen met de beheerders over een plan van aanpak. Maar ook kan er snel geschakeld worden om de oorzaak van een probleem te vinden.

Nu we dit hadden moest ons scrumbord opgetuigd worden. Aangezien we anders functioneren dan de andere teams konden we niet zomaar het scrumproces blijven volgen. We maakten ons bord met een extra horizontale lane. De specials lane, die gebruikt werd voor alle issues die door de sprint heen aan het team werd gevraagd. Een voorbeeld waarvoor we de specials lane nog gebruiken is voor de beheerders. Niet alle testomgevingen zijn even stabiel, waardoor de beheerders nog wel eens bezig zijn met andere zaken dan de stories op het bord. Juist daarvoor is deze lane er, om rekening te houden met de tijd die het team buiten de sprint om bezig is.

De specials lane is voor ons ook handig om de tijd buiten de sprint in te perken. We wilden namelijk ook functionaliteit opleveren en de al in stories opgenomen problemen oplossen. Hierdoor moesten we af en toe ‘nee’ verkopen, of ‘ben je al bij de product owner geweest?’. Voor de teams om ons heen niet zo leuk, maar voor ons cruciaal om te kunnen blijven functioneren. En dit moesten we ook naar de andere teams communiceren: De devops is er niet om alle problemen voor je op te lossen. We krijgen problemen op ons bord die niet met een simpele refinement te vatten zijn. We duiken dieper de stof in, maar devops wil niet zeggen dat we de vuilniswagen zijn.

Ons scrumproces bevat dan ook geen refinement zoals scrum dat aangeeft. We hebben in onze tweewekelijkse sprint geen refinement waar we als hele team de stories voor de komende sprint bekijken en klaarmaken. Deze refinement noemen wij analyse en de stories die voor een analyse in de wacht staan nemen we op in de sprint om ze op de goede diepte en waarde in te schatten. Deze analysestories geven dus alleen een oplossingsrichting. Na de analyse wordt dan gekeken of de oplossing de gewenste oplossing is en hoe deze ingevoerd kan worden. Hierbij is het voor ons de taak om de story bij het goede team te zetten. Dit hoeven wij namelijk niet te zijn.

Om te blijven functioneren als devops is het dus van belang om niet alleen lijstjes te maken of te analyseren. Het is juist belangrijk om te doen. Om de expertises te gebruiken binnen het team en daarmee problemen efficiënt op te lossen. Het is hierbij dan ook binnen het team belangrijk om een proces te volgen dat past bij het team waardoor het team kan functioneren. Een extra specials lane of juist geen refinement kunnen de middelen zijn die succes garanderen.

De onderwerpen naast het testen

Geschreven door Erik Bits op 21 oktober 2016. Gepost in Master Class.

Informatie (Over)Load
In juli en augustus is er veel theoretische stof behandeld: Van TMap Next, ISTQB, Tosca, JIRA, presentatievaardigheden, intakegesprekken tot Stakeholdermanagement.
TMap Next en ISTQB zijn twee frameworks waarmee het testproces gestructureerd en gestuurd kan worden. Van deze 2 cursussen heb ik ook geleerd wat de eigenschappen van een tester zijn. Als tester is het prettig om zeker de volgende eigenschappen te hebben: Creatief, nauwkeurig, positief kritisch, communicatief sterk, professioneel pessimistisch en oog voor detail hebbend. Deze eigenschappen zijn nodig om het te testen object goed en nauwkeurig te testen op de vastgestelde risico’s. Alles wat afwijkt van bijvoorbeeld het Functioneel Ontwerp, Technisch Ontwerp of het testplan wordt opgemerkt en genoteerd. JIRA is hierbij een hulpmiddel. JIRA is een bevindingen-beheertool. In JIRA kunnen alle bevindingen opgeschreven worden. Een bevinding is alles wat afwijkt van het te testen object. Dit kan een fout zijn in de programmeercode, een probleem tussen de integratie van 2 (deel)systemen of een probleem met het gebruikersgemak of beheerbaarheid (non-functionals) van het object. Maar: Een fout is altijd een bevinding maar een bevinding hoeft geen fout te zijn, dit kan ook een kleurencombinatie zijn voor een website die niet lekker samen gaat (bijvoorbeeld geel en paars).
Een ander testtool heet TOSCA. TOSCA is een testautomatiseringstool. Het automatiseren van een test kan handig zijn, vooral als een test vaak herhaald moet worden om regressie uit te sluiten of als een test opnieuw gedaan moet worden, een hertest of retest. Hierdoor blijft de software tester fris en creatief en wordt het herhaaldelijke werk overgenomen door een computer. Een ander pluspunt is dat deze geautomatiseerde testen ook op andere tijdstippen uitgevoerd kunnen worden anders dan onder werktijd.

Het Afblazen Van De Informatie-stoom
Ondertussen waren we naast deze vooral theoretische kennis over het testen ook bezig met het maken van de cv’s in AddYT-style en hielden we intakegesprekken onder leiding van Rob. Een intakegesprek is net een sollicitatiegesprek. Om als externe software –of kwaliteitstester in een baan in de IT bij een bedrijf te komen heb je een goed/aansluitend cv nodig waardoor je uitgenodigd wordt voor een intakegesprek. Het oefenen van deze gesprekken was erg leuk doordat we ook de rol van de aannemende kant/bedrijf in konden nemen. Een training die hier naar mijn idee bij past was de presentatievaardigheden van André. Deze training ging niet alleen over wat je moet presenteren, dit ligt namelijk aan je eigen interesse en het publiek waarvoor je gaat presenteren, maar ook hoe je het presenteert. Belangrijk is hierbij de voorbereiding, het inlezen in de materie, het onderzoeken wie er in het publiek zitten en waarom ze naar je presentatie komen en welke middelen je wilt gebruiken (powerpoint, whiteboard, flip-over etc). Via de ‘tell tell tell’ methode kan de presentatie ingedeeld worden en blijft je presentatie memorabel door herhaling per behandeld onderdeel. Deze training heeft mij meer zelfvertrouwen gegeven in het feit dat ik kan presenteren en ik zal blijven oefenen met presenteren met de tips en trucs van de training.

Liset Meijerman
Ik ben een enthousiaste en leergierige YPer in testen.
Vol vertrouwen zie ik de toekomst in naar verder ervaringen in het testvak.

Ervaringen van Onze YPs

Geschreven door Erik Bits op 11 september 2015. Gepost in Master Class.

Voordat in juli de traineeship begon had AddYT al gezorgd voor meerdere kennismakingen door middel van diners en een evenement. Dit gaf mij meteen een positief beeld over AddYT. Ze zijn niet alleen betrokken bij de traineeship maar ook met de trainees. De 3 trainees (Marc, Tobias en ik) kregen ook meteen het lidmaatschap van TestNet, de vereniging door en voor software -en kwaliteitstesters. Zo konden we meteen het eerste evenement meemaken. 24 juni hebben we het zomerevenement, de TestNet Summer School, voor testers bijgewoond. Bij dit evenement konden we, nog voordat we aan het traineeship waren begonnen, al wat kennis opdoen over testen.

De TestNet Summer School
De ochtend werd in beslag genomen door de vraag: Waarom geen productiedata? Ik verwachtte bij deze vraag een presentatie waarin de sprekers zouden vertellen waarom je als tester geen productiedata zou moeten gebruiken. Deze presentie kwam niet. In de plaats hiervan was er een werkgroep gepland waar we in groepjes aan de vraag konden werken. Als leek vond ik dat best spannend, maar al snel daagde het begrip over wat productiedata nu eigenlijk is en waarom je daar geen testen mee wilt uitvoeren. Deze productiedata heeft betekenis. Je kunt met deze gegevens gevoelige dingen te weten te komen, zoals wat de directie verdient, wat je buren of collega’s in hun vrije tijd doen etc. Daarnaast kun je door met deze gegevens te testen onbedoeld mailtjes of brieven naar mensen sturen. Gevolgen kunnen zijn dat het bedrijf waar je werkt boetes krijgt voor bijvoorbeeld het onjuist verstrekken van gegevens en er kan imagoschade en verlies van klanten optreden. Klanten willen zich niet meer verbinden met het bedrijf door de fouten die gemaakt zijn.
Maar welke data kan er dan gebruikt worden om de software van het bedrijf te testen? Productiedata blijft toch het meest realistisch en geeft daardoor een goed beeld over wat er mis kan gaan met de software. Hierdoor is er naar oplossingen gezocht die de risico’s van het gebruik van productiedata verkleinen. Zo kan de data geanonimiseerd worden en kunnen de persoonsgegevens verwijderd worden en vervangen worden door bijvoorbeeld een nummer. Daarnaast kan er testdata gecreëerd worden. Deze data is buiten de testomgeving nutteloos en zolang het voor iedereen duidelijk is dat het testdata is blijven de risico’s beperkt.

De Non-Functional Security Testen
Na een heerlijke lunch werd de middag in beslag genomen door beveiliging van websites. Wat is hacken en waarom is wit-hacken niet tegen de wet? Wit-hacken betekend dat een bedrijf je heeft gevraagd om hun website aan te vallen en te kijken waar de zwakke plekken zitten en of er gevoelige informatie gelekt kan worden. Wit-hackers willen deze aanvraag zwart op wit hebben voordat ze aan de slag gaan. Zo geeft het bedrijf aan dat de wit-hackers niet tegen de wet handelen door hun website aan te vallen.
Al met al een erg interessante dag waar ik al veel informatie heb kunnen opdoen en het gezellige sfeertje van TestNet heb op kunnen snuiven. Na deze dag kon ik vol vertrouwen nog een weekje vakantie vieren voordat de traineeship begon.

Even voorstellen

Naam: Liset Meijerman
Woonplaats: IJmuiden
Leeftijd: 24 Jaar
Ik ben een enthousiaste en leergierige YPer in testen.
Vol vertrouwen zie ik de toekomst in naar verder ervaringen in het testvak.