Skip to main content

Categorie: Activiteiten

Traineeship 2b4qa & Centric

Drie weken verder. Nog één week te gaan.
Elke dag: de wekker maakt lawaai om half 7 en eigenlijk wil ik me nog een keer omdraaien. Ik hoor de auto’s buiten voorbij rijden en word wakker met de rest van de wereld.
Eenmaal in de auto blik ik terug op de afgelopen weken. Zware weken. Maar zeker ook leuke weken.
Een intensieve en uitdagende periode waarin ik veel geleerd heb. Veel trainingen, studeren, koffie, leren hoe tools werken en meer koffie. Wat ben ik trots op mezelf, ik heb al twee certificaten op zak: PSM-1 en TMap. De basis voor mijn werk van de komende tijd.
Na intakegesprekken met mijn nieuwe opdrachtgever heb ik de geleerde communicatieve vaardigheden en technische kennis meteen in de strijd gegooid. De komende maanden worden spannend en ik heb er zin in om aan de slag te gaan. Wel ga ik mijn mede-trainees en alle docenten missen. Het was niet alleen leerzaam maar ook heel gezellig.
De conclusie: ik ben nu uitgerust met een goedgevulde rugzak vol technische kennis en communicatieve vaardigheden die me bij mijn verdere carrière verder kunnen helpen. Door alle informatie die ik tot nu toe op heb gedaan ga ik vol vertrouwen en enthousiasme de laatste lesweek in. Op de planning staan: Prince2, systeemontwerp, Java voor testers en Selenium. Het wordt spannend… samen gaan we ervoor!

Door: Melissa Hurkens, Farah Benjamin, Isabelle Kooreman

 

2B4QA Continuous Learning Sessie Java for Testers

Continuous learning

Bij 2B4QA hanteren we het principe van Continuous Learning op onze Odd Friday sessie, omdat we het belangrijk vinden dat we als Quality Consultants onszelf blijven ontwikkelen en zo bijblijven in de snel ontwikkelende wereld om ons heen. Lees hier verder over onze visie op continuous learning.

Binnen ons vakgebied is het Agile werken in multidisciplinaire teams niet meer weg te denken. Teams bestaan uit developers, welke natuurlijk nog wel specialisaties hebben. Ontwikkelaars, testers, designers werken steeds nauwer samen, moeten dezelfde taal spreken om zo tot een goed en releasebaar eindproduct te komen.

Door de korte release cycles en het snel veranderen van functionaliteiten is testautomatisering onontbeerlijk verbonden met onze werkzaamheden binnen het multidisciplenaire team. We willen als Quality Consultants samen met de ontwikkelaars ook na kunnen denken over test automatisering. Of het nu unit testen zijn of geautomatiseerde regressie testen, we willen toegevoegde waarde leveren binnen het team.

Java for Testers

Vanuit dit oogpunt hebben we recentelijk de cursus “Java for Testers” gevolgd. Met het hele team hebben we twee vrijdagen ons verdiept in Java en dan met name gefocused op wat we als testers aan Java kennis nodig hebben. Immers, als testers hebben we niet dezelfde diepgaande Java kennis nodig als ontwikkelaars, maar is het wel echt handig als je niet volledig in het duister tast als er termen als Class of Method geroepen wordt.

Het doel van de training was om ervaring op te doen in het schrijven van testautomatiseringscode in Java, ondersteund door JUnit. Het leren van de basisprincipes van Java, maar ook code leren lezen en begrijpen. Dit geeft je namelijk een voordeel als je met je mede teamleden naar defects gaat kijken in plaats van alleen opvoeren.

We hebben kennisgemaakt met Java door onze eerste programma te maken “Hello World”, wie kent het niet.

Hello World in Java

Uiteindelijk is er veel aan bod gekomen in de twee dagen en kan ik met een gerust hart zeggen dat deze sessie ons verbreding en verdieping heeft gegeven in Java, maar ook in kennis van testautomatisering.

We gaan ons nu zelf ook verder ontwikkelen door de combinatie met bijvoorbeeld de Selenium Webdriver library en BDD via Cucumber te zoeken.

Het vervolg van onze Continuous Learning sessies op onze Odd Fridays zal dan ook ongetwijfeld iets in deze hoek zijn. Lees hier verder over onze Odd Fridays.

Want ja, een dag niet geleerd is een verloren dag!

2B4QA op de Nederlandse Testdag !!

Wij staan 20 oktober op de Nederlandse testdag, georganiseerd bij Windesheim in Zwolle. Als je meer wilt weten over ons Tornadomodel, kom dan naar de presentatie van Erik en Tobias . Je kunt Raldy en Matthijs vinden op de beursvloer om te horen wat wij voor jou kunnen betekenen.

 

Continuous Everything – najaarsevenement Testnet

 

Afgelopen woensdag bezochten we het testnet najaarsevent in Nieuwegein. Het thema was Continuous Everything, een verwijzing naar de richting waarin de IT sector zich ontwikkelt. Dit uit zich vooral in steeds korter wordende release cycles van software. Voor het testen betekent dat dit continue gedaan wordt. Immers, bij elke release wil men nog steeds weten of de functionaliteit nog werkt.

Naast onze belangstelling voor de nieuwste ontwikkelingen in ons vakgebied dreef ook een ander gegeven ons naar dit evenement: onze collega’s Erik Bits en Tobias Verhoog stonden op het podium met een allegorie over de overgang van de sequentiële wereld naar agile testing. Zo kregen we de mogelijkheid om vast te stellen of Tobias en Erik de “Ars Dicendi” ook zouden beheersen buiten de veilige contouren van ons 2B4QA kantoor.

Op mijn programma stond workshop waarin ik zou leren een Jenkins pipeline te maken. Jenkins is een platform waarop men aan continuous integration doet, vooral in combinatie met Git. Omdat ik al menig commitje en pull requestje heb gemaakt in Git maar geen idee had hoe dit samenwerkte met Jenkins, leek dit me een goede gelegenheid om daar eens wat inzicht in te verkrijgen. Nadat ik een bak pleur naar binnen had gewerkt om de nodige arbeidsvitamines te verkrijgen begon ik met mijn collega Sonny aan de cursus. Hoewel de cursus interessant was hadden we graag wat meer achtergrondinformatie gehad over de werking van continuous integration. Maar de procedurele kennis die we op hebben gedaan biedt ons voldoende basis om zelf eens een CI / CD pipeline op te zetten.

Na een stevige lunch begon het middagprogramma met een keynotespeaker die de relatie legde tussen het persoonlijke leven en werkleven in een CI / CD omgeving. Af en toe smeet hij daarbij ballen in het publiek waarvoor de reden me tot op de dag van vandaag nog steeds onduidelijk is. Na enkele bakken koffie en nog een presentatie over valkuilen bij de transitie naar continuous development, was eindelijk het moment aangebroken waar we voor komen: de presentatie van Tobias en Erik: “The Wizard of Oz.”

Hoewel ik niet over dezelfde retorische kwaliteiten beschik als Erik en Tobias, doe ik mijn best om de presentatie te omschrijven. Het verhaal voerde ons mee naar het magische “Land of Oz.” Dit verhaal geschiedde in het midwesten van Amerika, in de staat Kansas, waar het “saai vertoeven” was, aldus hoofdpersonage Dorothy (in navertelling door Erik Bits). Op een dag kwam er een tornado die haar huis in het land van Oz neersmeet en daarbij een heks plette. Dorothy ging vervolgens op queeste om de tovernaar te vinden die haar kon helpen om weer terug te komen in Kansas waarbij ze hulp kreeg van enkele sprookjesfiguren. Deze sprookjesfiguren hadden kennelijk allerlei persoonlijke problemen, en hoopten dat de tovenaar die problemen kan oplossen. Na vele avonturen kwamen ze bij de tovenaar aan, die tot verbijstering van de hoofdpersonages een flessentrekker bleek te zijn.

Tobias en Erik gebruikten het verhaal om het tornadomodel te beschrijven. Een model waarbij in het begin van de Agile Tornado er creative destruction onstaat van het oude: in het geval van de IT sector de problemen behorend bij het sequentiële model, zoals bureaucratie, lange time to market en een gebrek aan transparantie. In het geval van the Land of Oz wordt de slechte heks geplet en de gevangenen vrijgelaten. Een tornado zorgt dus voor een hoop ontregeling maar lost tegelijkertijd problemen op.

Hoe groter de tornado, hoe verder je zit op de mate van continuous integration (en agile werken). Wie de flessentrekker was in tornadomodel, is mij nog niet helemaal duidelijk geworden. Wellicht dat dit tijdens een volgende sessie wordt onthuld….

Ketenregie – Van idee tot werkende software

Op 14 juni was er een TestNetavond. Deze avond had als onderwerp Ketenregie. Mij trok dit aan aangezien ik in mijn opdracht in een team zit dat ook de keten overziet om zo de performance van het softwareproduct te verbeteren. Mijn eigen kennis van ketenregie was dan ook beperkt tot aan het vele regressietesten. De spreker Jos van Rooyen heeft mij met deze avond meer begrip gegeven over ketenregie. Daarnaast heeft hij ook een model als handvat aangereikt. Al met al was het een leerzame avond. Waarbij ik heb geleerd wat ketenregie is en hoe je dat zou kunnen toepassen.

Ketenregie

Aangezien ik me wat verder wilde verdiepen in ketenregie en het proces heb ik eerst eens wat begrippen opgezocht. Het eerste begrip is keten. Vanuit NORA (Nederlandse Overheid – Referentie Architectuur) komt het begrip keten neer op: “een samenwerkingsverband tussen (afdelingen binnen) organisaties die naast hun eigen doelstellingen, één of meer gemeenschappelijk gekozen (of door de politiek opgelegde) doelstellingen nastreven. Deze ketenpartners zijn zelfstandig, maar zijn ook afhankelijk van elkaar waar het gaat om het bereiken van de gezamenlijke doelstellingen.”

Nu het woord keten duidelijk is heb ik ketenregie opgezocht. Ensie geeft hier een uitleg: “Ketenregie is het besturen en beheren van logistieke ketens. Ketenregie omvat alle activiteiten die in dienst staan van het beheren van de gehele keten, van grondstof tot eindproduct.” Ook Jos van Rooyen geeft een uitleg over ketenregie: “Ketenregie is een professionele aanpak waarbij de stabiliteit, veranderbaarheid en performance van de keten wordt gemaximaliseerd. Dit wordt gerealiseerd door belemmeringen op te ruimen en ontwikkelmogelijkheden te identificeren en door te voeren.”

Nu ketenregie iets duidelijker is, rijst de vraag hoe je dit dan kan toepassen.

Waarom ketenregie toepassen?

In een groot bedrijf loopt de organisatie eigenlijk waterval. Directie heeft een plan. Architecten maken daarvoor het plaatje, ontwerpers delen het plaatje op en maken ontwerpen, ontwikkelaars bouwen 1 van de ontwerpen en testers testen dat.

Je kan wel geloven dat er dan veel communicatie verloren kan gaan. Allereerst zal het lastig zijn om door deze ketens van beneden naar boven te communiceren. Een ontwikkelaar kan bijvoorbeeld aan de hand van een ontwerp zien dat het (voorbeeld) niet gaat werken. Die zegt dit dan aan de ontwerper, deze zal het weer tegen de architect vertellen en die aan de directie. Komt hierdoor de oorspronkelijke tekst van de ontwikkelaar nog aan?

Dit is een voorbeeld van waarom ketenregie nodig is, ketenregie verbetert inefficiënte processen, de samenwerking in de keten en de communicatie van en het begrip voor product versus productie gereedheid.

Een gebrek aan ketenregie is dan ook vaak een gebrek aan overzicht van de keten. Mogelijke oorzaken hiervan zijn:

  • De toenemende fragmentatie, ketens worden langer waarbij de complexiteit ook toeneemt,
  • Een verandering in een stuk software kan in een keten lastiger traceerbaar zijn, de traceability wordt complexer,
  • Processen zijn inefficiënt ingericht,
  • Er is gebrek aan goede communicatie tussen partijen, dit kan binnen een bedrijf zijn maar ook tussen bedrijven (toeleverancier en ontvangende partij),
  • De kijk op het proces is erg beperkt, er wordt bijvoorbeeld alleen gefocust op de ICT,

Het model

Om ketenregie toe te passen zijn er volgens Jos van Rooyen 6 principes waaraan gehouden moet worden.

  1. Werk vanuit een visie,
  2. Organiseer de regie,
  3. Werk met alle mensen,
  4. Creëer ritme,
  5. Durf vanuit overzicht,
  6. Meet en borg.

Dit zijn simpele principes, ook om je aan te houden. In deze principes is meteen te zien dat er een overzicht van de keten wordt gecreëerd. Het model wordt hierdoor zo:

Een iteratief proces waaruit een visie spreekt en waardoor regie wordt gehouden, alle mensen betrokken zijn, ritme en overzicht gecreëerd worden en documentatie (meet en borg) wordt opgesteld. Een model om iedereen op en om het bedrijf tevreden te stellen en vooruitgang in het vooruitzicht te stellen.

 

 

  • 1
  • 2