Auteur: Liset Meijerman

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

Informatie naar Kennis

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

Startende Starter

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

 

blog foto
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.

Contact

  • Telefoon

    0318 - 240 044

  • Email

    info@2b4qa.nl

  • KVK

    601.397.73

  • Postadres

    Cuneraweg 322
    3911 RT Rhenen

  • Bezoekadres

    Plesmanstraat 59
    Kamer 21
    3905 KZ  Veenendaal

2B4QA BV  (c) 2018