Tag: Testnet

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.

 

 

Aan de slag met Postman, LiveCode en Agile risicoanalyse bij TestNet ZomerWorkshops 2017

Het was op 10 juli weer tijd voor het ZomerWorkshops event van TestNet. Ondanks dat het mijn verjaardag was ben ik naar Nieuwegein afgereisd, waar ik een aantal 2B4QA collega’s heb ontmoet en twee workshops heb gevolgd.

Testautomatisering voor Dummies

We begonnen de dag na het gebruikelijke kopje koffie in de ochtend met een workshop die beloofde “Testautomatisering voor dummies” helder te maken. Dit was een boeiende sessie over het gebruiken van de ontwikkeltool LiveCode als hulp bij het testen.

De noodzaak hiervoor werd beschreven door uit te leggen dat als je een onderdeel van het systeem wilt testen terwijl nog niet het hele systeem klaar is je dit soort tools kunt gebruiken als hulp. Ook wanneer een proces in het systeem bestaat uit veel stappen die nog niet allemaal af zijn kun je met een testtool al wel bepaalde onderdelen testen. We hebben in de workshop eerst Postman gebruikt om een service te testen en later zelf een tool gemaakt in LiveCode om meer verandering aan te kunnen brengen.

testautomatisering voor dummies

Zoals docent Rob Kuijt van Valori het uitlegde “op deze manier kun je ook alleen pagina 19 in een werkproces van 20 pagina’s testen”. Ik kan me erg goed vinden in het voorbeeld dat je een heel proces door moet om uiteindelijk een klein nieuw onderdeel te kunnen testen. Ik ben van mening dat het ook belangrijk is om een end-to-end test te doen voor nieuwe functionaliteit, maar het scheelt vaak veel werk en tijd om een groot deel van de test cases uit te voeren met een tool als Postman.

We zijn toen verder gegaan met uitleg over het gebruik van Postman. Postman is een API testtool waarmee je simpel gezegd een service kunt testen door een request in te sturen en een antwoord kunt ontvangen. Dit is dus erg handig als er een service veranderd of opgeleverd is, terwijl de front-end misschien nog niet beschikbaar is. Je kunt Postman gemakkelijk als app toevoegen aan Chrome.

De groep is toen onder leiding van Rob en Curd Klaassen verder gegaan met een volgende tool. LiveCode is een visuele ontwikkelomgeving waarbij je op een canvas een aantal elementen zoals knoppen en velden kunt toevoegen waarna je dan code toevoegt om te bepalen wat de elementen moeten gaan doen. Je maakt hierdoor snel zelf een applicatie. We hebben dezelfde functionaliteit als van Postman toegevoegd aan een nieuwe applicatie in LiveCode. We hebben hierbij een case gevolgd die ook na te lezen is op het blog van Valori.

We hebben bij deze workshop geleerd om de basics van Postman te gebruiken en een eerste applicatie in LiveCode te maken die wel direct bruikbaar is als testtool. De waarde van zo’n tool is dat je delen van een keten die nog niet opgeleverd zijn al wel kunt nabootsen om nieuwe functionaliteit te kunnen testen.

Agile Risico Analyse

Als tweede heb ik een workshop bijgewoond over Agile risicoanalyse door Gijs op den Beek en Thomas Veltman van Sogeti. Gijs had bij een klant een nieuwe manier van risico’s analyseren ontwikkeld en beoefend. Hierbij kun je op een agile manier risico’s per user story inschatten. Ik was hier zeer in geïnteresseerd omdat ik het lastig vind om risico’s bij een agile team onder de aandacht te brengen. Stakeholders vinden vaak alles belangrijk en willen alles “goed getest” hebben.

Gijs begon met een lange opfrissing van de agile principes en de rol van risico’s daarin. Via Kahoot hebben we een inventarisatie geprobeerd te doen van het gedeelte van het publiek dat in een agile omgeving werkt. We hadden helaas wat netwerkproblemen met de wifi van het congrescentrum. Na een inventarisatie door hand opsteken bleek dat minder dan de helft van de aanwezigen vond dat hij in een agile omgeving werkte. Veel aanwezigen werkten in een agile/waterval hybride omgeving.

We gingen verder met risicoanalyse door de risico’s van een vakantie in te schatten met de groep. Wat kan er misgaan en wat is de kans daarop? De formule risico = faalkans x schade passeerde de revue.

Voor een waterval project is het goed om een uitgebreide risicoanalyse vooraf te doen en vervolgens actiepunten uit te zetten voor de risico’s. Bij een agile werkwijze kun je tijdens de planning risico’s benoemen en acties definiëren. In de methode van Gijs gebruik je een soort risicopoker. Tijdens refinement kun je met verschillende aanwezigen ook de faalkans en de potentiële schade inschatten op een schaal van een tot drie.

We zijn hierna met een voorbeeld in groepjes aan de slag gegaan. Hierbij kwam de uitleg meer tot leven. We kregen verschillende teamrollen toebedeeld en hebben voor een vijftal user story’s de risico’s ingeschat. Hierbij merk je dat het handig is om eerst de faalkans en schade apart in te schatten, maar dat je later met je team ook in één keer het risico kunt inschatten en dat je nog later misschien wel het risico direct in de pokerpunten kunt meenemen. Dit was ook de ervaring van Gijs in zijn opdracht.

agile risico analyse

Er waren vragen vanuit de zaal over hoe je dit kunt implementeren. Door met het hele team risico’s te bespreken kun je de test strategie makkelijker bepalen, de test resources beter verdelen en ook al een aantal risico’s verminderen. Voor het beheersen van risico’s werd de ROAM methode uit SAFe genoemd. Het kost het team uiteindelijk ook steeds minder werk om de risico’s te benoemen. Ook het samenpakken van alle risico’s per story zorgt voor snelheid. Iemand vroeg nog naar de mogelijkheid om ook non-functionals te betrekken. Deze kunnen ook goed per project of product in een PRA besproken worden.

Aqua: agile improvement voor teams

Mijn collega Liset ging bij deze workshop aan de gang met de pijnpunten van een agile implementatie. Deze workshop was erg interactief. In groepjes van 5 werd er besproken wat de lastige punten zijn bij een agile implementatie en  wat het voor jou moeilijk maakt. Er werd ook gepraat over hoe jouw bedrijf agile verbeterd en wat je daarvan vind. Daarnaast had de spreker Huib Schoots van Improve een model gemaakt om in een agile werkomgeving een team te optimaliseren. In de groepjes hebben ze van dat model kunnen proeven.

Bijna iedereen heeft wel ervaring met de implementatie van agile bij een organisatie. Door dit met elkaar te delen kom je toch weer tot nieuwe inzichten. De spreker had ook veel energie waardoor je toch makkelijk meedoet en je ideeën deelt.

Internet on Wheels en BDD met Robots

Collega Sonny had zin in een dagje aan de gang met robots en is naar de workshop Internet on wheels van Parasoft en BDD met Robots van Bartosz gegaan. Bij internet on wheels moest er een robot door een doolhof geleid worden. Dat kon door via bluetooth opdrachten te sturen in python. Dit bleek erg lastig te zijn en het was niemand gelukt om de robot op die manier het einde van het doolhof te laten vinden. De robot kon ook bestuurd worden door sensors die erop zaten. Hiermee was het makkelijk om hem een kant op te laten gaan.

Ook in de sessie van Bartosz moest een robot door een doolhof geleid worden. Deze Mbot kun worden bestuurd door opdrachten in programmeertaal Scratch in BDD scenarios te geven. De geprogrammeerde scenarios zorgden met ingebouwde sensors ervoor dat de robot zijn weg kon vinden. Door de juiste commandos in te voeren en ook de juiste snelheid aan te houden was het Wall-e team van Sonny het snelste van de dag!

Afronding

Uiteindelijk liep de dag voor mij ten einde bij het dinerbuffet. We hebben met de aanwezige collega’s van 2B4QA nog even zitten napraten en grijpen het diner van TestNet ook altijd aan om samen te eten.

TestNet Leergang: Share your Brains

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

 

Contact

  • Telefoon

    0318 - 240 044

  • Email

    info@2b4qa.nl

  • KVK

    601.397.73

  • Postadres

    Cuneraweg 322
    3911 RT Rhenen

  • Bezoekadres

    Kerkewijk 31
    3901 EB  Veenendaal

2B4QA BV  (c) 2018