Najaarsevenement 2017

Continuous Everything

-------------------------------------------------------------------------------------
MIDDAG- EN AVONDTRACKS - GEEN AANMELDING NODIG!
-------------------------------------------------------------------------------------

 

Continuous change, 7 wijze lessen van onze familie en vrienden - Andreas Prins

Een sterk team bouwen en veel hoogwaardige software leveren is niet altijd eenvoudig. Als je denkt dat je het onder de knie hebt veranderd je team, de omgeving of komt er die grote fout vanuit productie. Een adaptief team bouwen om daar mee om te gaan is niet iets wat je zomaar even doet. Het is als een familie het groeit over tijd in omvang, diepgang, samenwerking en in de doelen die ze stellen. We ontdekken samen hoe sterk onze privť situatie overeenkomt met onze werksituatie en hoe we daarin kunnen groeien.

Automated Risk Based Testing in an Agile environment – Ben Visser en Peter Nwanko

Agile without automated testing is not possible. One of testing’s best practices is risk based testing. How do the two work together or even strengthen each other? This presentation shows how to generate test cases automatically for several coverages and how to feed the different sets of test data to the test tooling.

The presentation starts with a brief introduction in Risk Based testing: what it is and how high risk requirements are translated into a different set of test cases than low or medium risk requirements. Coverage type and coverage intensity will be explored.
The next part of the presentation/demo focuses on the test case creation: small sets for low risk feature, larger sets for higher risk features (the example we’ll us: all values coverage for low risk, all pairs for medium risk and all combination for high risk features.)
The test data can be generated in different formats (JSON, XML, CSV) and can be executed through a wide range of tools (UFT, Protractor, etc.)
We’ll close with a live demo of test execution based on the generated test cases, testing an insurance premium calculation through a UFT framework.

Continuous F##k-ups – Hans de Rooij en Joep Lobee

Veel IT-projecten ondervinden problemen en zijn niet succesvol doordat ze continuous in dezelfde valkuil trappen of stoten tegen die ťne steen. Waarom accepteren we deze problemen en incorperen we deze in onze “Best practice”? Zijn we niet in staat als vakgroep om met de lessons learned daadwerkelijke verbeteringen te realiseren! Juist als tester ben je nu eindelijk al vroeg betrokken bij een project en kun je problemen aan zien komen en dus voorkomen.

Als je om je heen kijkt lijkt het wel of in IT-projecten steeds dezelfde fouten worden gemaakt, het lijkt haast “standard-practice” om deze fouten in elk project te herhalen. In deze presentatie wordt deze situatie op humoristische wijze aan de tand gevoeld en de zaal uitgedaagd om op te staan en het komende jaar het verschil weer te gaan maken door de stenen te verwijderen en valkuilen te dichten.

De presentatie zal worden gegeven door 2 sprekers:
De 1e spreker vertegenwoordigt een fictief bedrijf wat een best practice heeft gemaakt van alle standaard problemen in projecten: ze komen in elk project terug, dus het moet wel een succesformule zijn.
De 2e spreker analyseert deze best practice en bespreekt hoe deze vanuit een testperspectief weg te nemen zijn en daarmee de overall kwaliteit van het project verbetert wat leidt tot succesvolle projecten!

Continuous Requirements Engineering – Hans van Loenhoud

Professioneel Requirements Engineering is continu - vanaf de start tot en met de oplevering - van belang voor het succes van het project en de kwaliteit van het product. Het is een domein waar alle ontwikkelaars mee te maken hebben, niet alleen PO’s en BA’s, maar zeker ook testers.

In traditionele projecten werd Requirements Engineering gezien als een aparte initiŽle fase. Hierin werden alle (?!) requirements voor het product in detail vastgelegd en ‘bevroren’ als input voor de ontwikkeling. Wijzigingen in de loop van het project werden zo veel mogelijk afgehouden. Bij een Agile aanpak wordt juist heel flexibel omgegaan met requirements: het zijn items op een voortdurend door de PO en het team aangepaste backlog. Ook dan is expliciete aandacht voor Requirements Engineering noodzakelijk, niet als initiŽle
fase maar als continu proces binnen iedere iteratie. De initiŽle backlog bevat vaak alleen de grote brokken te realiseren functionaliteit. Tijdens de ontwikkeling worden deze voortdurend verder opgebroken in kleinere stukken, totdat ze gedetailleerd genoeg zijn om in een volgende sprint te worden gerealiseerd. Professioneel Requirements Engineering zorgt ervoor dat de totale set compleet en consistent blijft en voorkomt daarmee overbodig rework en vertraging. Dat vereist voortdurend zoeken naar de juiste balans tussen vooraf uitwerken (meer zekerheid) en aan het team overlaten (meer flexibiliteit). Hierbij zijn alle teamleden betrokken, niet alleen de PO of de BA. Uiteindelijk komt alles samen bij de testers, die op basis van acceptatiecriteria en eigen referentiekader de kwaliteit beoordelen.

Tien kinken in de kabel bij continue (test)verbetering – Kees Blokland

We moeten alert zijn op mogelijke veroorzakers van haperende (test)verbetering. Door die te herkennen en bij de bron aan te pakken, of nog beter, voor te zijn, , maak je het mogelijk dat een organisatie in een continue flow van (test)verbetering komt.

Alleen IT-organisaties die continu hun softwareontwikkeling met daarbinnen testen verbeteren, maken kans om te overleven. Dat is echter gemakkelijker gezegd dan gedaan. In de praktijk stuiten we op allerlei, soms hardnekkige, problemen bij het op gang brengen en op gang houden van de verbeterflow. Wat zijn vaak voorkomende oorzaken daarvan?

Kees behandelt tien belangrijke oorzaken van haperende (test)verbeterprocessen aan de hand van voorbeelden uit de verbeterpraktijk. Hij introduceer belangrijke mechanismen, zoals de “volwassenheids-verbeter” paradox, en de “er-moet-wel-pijn-zijn” heuristiek. Ook staat hij stil bij, vaak onderschatte, oorzaken in de organisatie zelf, zoals de cultuur en de type mensen die er werken. In de verschillende fases van het verbeterproject zelf kan het ook mis gaan, zoals tijdens het onderzoek, bij de rapportage, en niet in de laatste plaats gedurende de implementatie van de verbeteringen.

Continuous Testing? Zorg dat je testautomatisering FITR – Bas Dijkstra

Om Continuous Testing succesvol te laten zijn is het hebben en uitvoeren van geautomatiseerde tests alleen niet genoeg. In deze presentatie vertel ik je hoe je je testautomatisering geschikt maakt voor CT door het toepassen van vier principes.

Om succesvol Continuous Integration en Continuous Delivery te implementeren, moet je als team of organisatie in staat zijn om ook on demand inzicht te krijgen in de kwaliteit van je applicatie (Continuous Testing). Heel vaak wordt daarvoor (en minimaal deels terecht) gekozen voor testautomatisering. Maar alleen het hebben van een geautomatiseerde (regressie-)testset maakt nog niet dat je succesvol kunt zijn met Continuous Testing.

In deze presentatie laat ik aan de hand van het FITR-model zien aan welke eisen je geautomatiseerde tests moeten voldoen om ze wel succesvol in te zetten bij CT:
• Focused (gericht) – zorg er voor dat je geautomatiseerde tests zich op het juiste applicatieniveau richten
• Informative (informatief) – zorg ervoor dat je geautomatiseerde tests de juiste informatie teruggeven
• Trustworthy (betrouwbaar) – zorg ervoor dat je op je tests en de resultaten daarvan kunt vertrouwen
• Repeatable (herhaalbaar) – zorg ervoor dat je geautomatiseerde tests on demand herhaalbaar zijn

Continuous improvement: van technical debt naar duurzame software – Maarten Wagenaar

Continuous improvement is een belangrijk onderdeel van het agile werken (inspect & adapt). Naast de retrospective zijn er ook andere manieren om empirisch naar een doel toe te werken. Door middel van een praktijk voorbeeld geef ik handvatten hoe dit aan te pakken, te meten en wat dit opleverde.

Een veel gehoorde klacht van agile teams is dat zij onvoldoende tijd krijgen om achterstanden op het gebied van technical debt en (test) automatisering weg te werken. De product owner vind het vaak goed genoeg en ziet de waarde van deze, op het oog, dure verbeteringen niet.

In de presentatie wil ik de aanwezigen meenemen hoe mijn agile team in 2 jaar tijd vanuit een onstabiele basis test & technische automatisering in het agile ontwikkelproces heeft toegepast. In de presentatie zal het volgende aan bod komen:
- De startsituatie waarin het team zich bevond en de uitdagingen waar we mee te maken hadden
- Onze (toenmalige) visie op het optimale test- en ontwikkelproces
- Hoe we als team iteratief een passende test(automatiserings)strategie hebben ontwikkelt, geimplementeerd en gemonitort buiten de standaard scrum meetings om
- Hoe we de stakeholders vervolgens hebben meegekregen om te investeren in automatisering & vernieuwing (kwaliteit)
- Waarom we dit proces vervolgens weer hebben losgelaten om nog meer innovatie toe te staan (en wat dit vervolgens opleverde)

Tornado model – Erik Bits

Om onze klanten te ondersteunen bij het opzetten een CI/CD pipeline introduceren wij het Tornado model. Dit model is gebaseerd op de gedachte dat je bij het implementeren van een pipeline alle verschillende activiteiten tegelijk start maar niet op volledige sterkte. Ze starten klein en gecontroleerd om zo uit te groeien tot volle kracht, net als een tornado.

De schaal van Fujita is een schaal om tornado intensiteit te beoordelen. Primair gebaseerd op de destructieve gevolgen die een tornado heeft op menselijke bouwwerken en vegetatie.
We gebruiken deze F0 – F5 schaal om de verschillende fases binnen Continuous Delivery Maturity te definieren.

We kiezen doelen en onze technieken, onze vaardigheden en tooling om deze doelen te behalen. We beginnen klein, als een wervelwind, met beperkte sterkte maar elke fase groeien we aan kracht. We krijgen steeds meer ervaring in hoe de pipeline te gebruiken en te perfectioneren. Totdat we in fase 5 op volle kracht zijn.
Net als bij een echte Tornado, als je niet goed voorbereid bent, zullen de gevolgen desastreus zijn voor je organisatie als je het model niet goed onder controle hebt.

We zullen je helpen het model te gebruiken, zodat het jouw kan helpen om op een solide, onderhoudbare, transparante en flexibele manier een ci/cd pipeline in te richten binnen je organisatie.
Daarnaast gebruiken we de tornado zoals deze ook in de Wizard of Oz is ingezet: Het transporteert een volledig team van ontwikkelaars, ontwerpers en testers naar een andere (DevOps/ISO-SQuaRE) wereld.

Binnen deze wereld krijgen zij te maken met de heksen (bedreigingen) uit alle 4 de windstreken (de kwadranten uit het ISO-SQuaRE model) en wordt duidelijk hoe de verschillende eigenschappen van de blikkenman, de vogelverschrikker en de leeuw samenkomen binnen een Development-team waardoor deze bedreigingen en hoofd worden geboden.

Testen als continuous enabler – Edwin van Loon

De presentatie zal gaan over de ervaringen van APG rondom de transformatie naar een Agile/DevOps cultuur, waarin ‘continuous everything’ centraal staat.
APG is een formele organisatie, die te maken heeft compliancy eisen en toezichthouders. Tevens heeft de ervaring betrekking op het Generiek Pensioenen Systeem (GPS), dat een groot backoffice systeem is.
Allemaal ingrediŽnten, die over het algemeen niet aan Agile en DevOps gekoppeld worden.
Wijzigingen in het testproces en de werkwijze rondom testen hebben geleid tot het feit dat in deze omgeving het toch mogelijk is om DevOps te werken.

Binnen het GPS programma heeft een transformatie van het testproces plaatsgevonden. Deze presentatie zal het verhaal rondom deze transformatie vertellen. Beginnend bij de gestelde doelstellingen (80% beter, 50% sneller en 25% goedkoper) en eindigend bij een Agile werkwijze, waarin systeem- en acceptatietesten zijn samengegaan en plaatsvinden in het realisatieteam tijdens de Sprint.
En, waarin de focus ligt op geautomatiseerde testuitvoering.
Tijdens de presentatie zullen de ervaringen rondom de volgende 4 deelgebieden worden gepresenteerd:
- Proces en organisatie
- Het T-profiel van de test professional
- Tooling en technieken
- Continious improvement

Continuous performance testen @NS – Onno Wierbos, Dennis van Zundert en Leen Brouwer

Wendbare IT is cruciaal voor NS om de klant goed te kunnen bedienen en om competitief te blijven, maar tegelijk mag betrouwbaarheid niet in het geding komen. We hebben binnen NS een referentie architectuur neergezet voor het integreren van performance en beschikbaarheidstesten in de CI pipeline; essentieel om de doelen voor wendbare IT te behalen.

De Reisplanner app, het Railpocket device van de conducteur, software voor planning, bijsturing of OV Chipkaart... NS kent veel mission critical applicaties. Performance en hoogbeschikbaarheid testen is daarom aan de orde van de dag; falen van IT mag immers nooit tot operationele verstoring leiden. Maar om de klant optimaal te kunnen bedienen ťn om de competitieve voorsprong te behouden ontwikkelt de behoefte aan wendbare IT zich in sneltreinvaart en doet Continuous Delivery zijn intreden bij NS.

In de domeinen Reisinformatie en OV Chipkaart heeft het NS Test Competence Center een referentie architectuur neergezet om Performancetesten te integreren met de Continuous Integration pipeline. Daarbij is gekozen voor de basis pipeline definitie en coŲrdinatie door Jenkins en een flexibele invulling van de tools die verschillende projecten naar eigen inzicht graag gebruiken. JMeter en InfluxDB zijn populair. Afhankelijk van de product risico's, test je op een klein geschaalde T-omgeving of op een productie-like A. Of allebei.

De presentatie bevat een demo waarin getoond wordt hoe Continuous Performance Testen naadloos integreert met Ansible: de developer wijzigt de code, de Jenkins omgeving wordt getriggerd waardoor een omgeving wordt geconfigureerd waarop vervolgens de performance test automatisch wordt uitgevoerd. De resultaten worden teruggekoppeld aan de developer via het InfluxDB dashboard.

Our Continuous Delivery journey at Rabobank – Rien Krol & Amrenda Kumar

In a highly competitive market where the digital world is consistently changing, Rabobank is leading a smooth transformation in their IT landscape by successfully implementing Continuous delivery in its ‘client On-boarding’ program.
We like to share our approach, challenges and lesson learned thru this journey. “We learn, we define and we shine!”

DevOps is considered a core backbone for achieving our IT objectives at Rabobank. Within the wholesale domain the Customer On-Boarding program aims to ensure a proper on-boarding process for our clients. The Pega workflow framework based IT solution touches multiple applications from Client Data to Risk Management and Fulfilment.

Building a new solution was not enough to meet our business objective, also timely delivery of the system to comply with legal requirements was key. Therefore we wanted to deliver smaller logical chunks with faster verification and feedback in the test environments. To support continuous deployment of code to higher environments, automated regression tests triggered by every deployment we needed a platform to automate this. With all that we wanted to control the entire release management process into our production environment.

To achieve continuous delivery, we automated following processes as much as possible in our IT ecosystem: Code builds, Code deployments, Artefact management, Regression tests and Release management.
And we did it!
We laid out the plan, faced challenges, improved and established the entire continuous delivery pipeline. This session will take you through our journey and explain the small/big things that can make a difference for you as well. We like to share our experience.

Hoe we performance risico’s ook in een CI/CD wereld de baas blijven – Renť Meijboom

Binnen DevOps/Agile en CI/CD is er geen ruimte meer om de performance te testen op de manier zoals wij dat jaren gewend zijn geweest. De perfor-mance risico’s blijven echter, weliswaar op een andere manier, aanwezig. In deze presentatie staan we stil hoe we deze risico’s in de ‘nieuwe wereld’ het best kunnen afdekken. Een verhaal over Shift Left Testing, efficiŽnte moni-toring en het killen van risico’s!

We staan kort stil bij de mismatch tussen de traditionele best practices van performance testen en de veranderde performance risico’s en randvoorwaarden in de wereld van DevOps en een CI/CD omgeving.

Vervolgens geven wij onze visie op hoe je als organisatie je middelen het best inzet om deze performance risico’s af te dekken. Om dit scherp te krijgen staan we stil bij de impact die DevOps/Agile hierop heeft door onder andere de introductie van Continuous Integration, Continuous Delivery en Continuous Monitoring. Hierbij worden de voor en nadelen, de kansen en de risico’s van de verschillende mogelijkheden die vanuit performance engineering perspectief toepasbaar zijn, besproken. Zo komen snelle feedback loops op performance langs, shift left testing, de uitdaging van de continue datastroom die dit veroorzaakt, de wijziging die dit teweeg brengt in toegepaste tooling en methodes, en de veranderende rol van de performance tester binnen de organisatie.

We gebruiken hierbij input uit de praktijk, de veranderende wensen binnen (onze) klantorganisaties en de visie van onze performancespecialisten.

Testen en Testautomatisering in een Agile CI/CD omgeving – Mustafa Canbaz

Lessons learned bij de implementatie van Agile (SCRUM), CI/CD en DevOps bij een grote Nederlandse bank in relatie tot (geautomatiseerd) testen.

Aanpak transitie naar Agile (SCRUM), implementatie CI/CD en DevOps. De uitdaging was om de veranderingen in een logische volgorde te realiseren. Implementatie in fases van de nieuwe manier van werken, zodat de nieuwe SCRUM teams voldoende tijd hadden om zich aan te passen. Dus heel erg veel geduld.
De oplossing was om een bootcamp te geven met training over flexibiliteit en trainingen over tools zoals Jira. Begeleiding werd gedaan met een Agile coach. Daarna gevolgd door het delen van kennis over geautomatiseerde testen om naar een CI/CD te groeien. Er was overigens geen CI/CD coach. We willen graag onze aanpak en best practices delen. Ook welke uitdagingen, vanuit organisatorisch en technisch oogpunt, we hebben meegemaakt. Tenslotte willen we over geautomatiseerde test frameworks een aantal nieuwe inzichten bespreken. Het opbouwen van een aangepast automatische testtool of het gebruik van op een leverancier gebaseerde automatiseringstool.

Security; de wedloop in de ICT – Heini Veneberg

Kunnen organisaties de wedloop tegen cybercriminaliteit stoppen of moeten we leren hiermee om te gaan? Met betrekking tot testen denken we bij security met name aan penetratietesten en vulnerability testing. Continuous `Everything` biedt ICT organisaties, samen met gebruikers en leveranciers, mogelijkheden om adequaat te kunnen reageren op kwetsbaarheden en bedreigingen.

In zijn presentatie gaat Heini in op de security wedloop. De gevolgen van informatielekken en cyberaanvallen kunnen desastreus zijn. Incidenten leiden niet alleen tot technische, financiŽle en reputatieschade, de aandacht die (social) media aan security incidenten besteden leidt bovendien tot een zeker gevoel van angst en onbehagen. Door de alsmaar toenemende omvang van informatiesystemen, complexe onderlinge koppelingen en het onderbrengen van bedrijfsfuncties in de cloud, wordt het waarborgen van integriteit, beschikbaarheid en vertrouwelijkheid een steeds grotere uitdaging. Dankzij onder andere ‘Bring Your Own Device’ (BYOD) en de toegang tot bedrijfssystemen via mobile devices neemt het aantal zogeheten ‘attack surfaces’ enorm toe. Cybercriminaliteit is ‘big business’ en wordt ingezet om financiŽle, commerciŽle, politieke of maatschappelijke doelen te ontwrichten.
In de voortdurende wedloop tegen cybercriminelen is ‘security by design’ steeds vaker een uitgangspunt. Een penetratietest of vulnerability scan is al lang niet meer voldoende om veilige en betrouwbare systemen op te leveren. Heini zal in zijn presentatie een aantal aandachtspunten de revue laten passeren, die bij de realisatie en het beheer van informatiesystemen op dit moment wellicht nog onvoldoende aandacht krijgen. Hij geeft zijn visie op de wijze waarop continuous `Everything` een wezenlijke bijdrage kan leveren aan het opleveren van veilige systemen.

Test the bot, Test with the bot – Adonis Celestine

Advancement in machine learning and big data processing has fundamentally changed the way we build software. But this advancement also brings in unique challenges for the testing industry. This presentation gives useful tips for testers to overcome this challenge and use this as an opportunity to continuously improve quality.

What was once science fiction is fast becoming a fact of today’s business world. The world is beginning to accept that everything that aren’t software are being transformed by AI and Machine Learning. While the concept itself is not new and has been there for many years, today we actually have the technology to use it in reality.
The advancement in Natural Language Processing, Machine learning and the ability to process huge amounts of data has led to the explosion of bots which can communicate with humans like humans. This rise of conversational bots is the great story of our time.
While developing a well-designed bot would require some effort, testing a chat bot has it’s own set of challenges. The most obvious challenge is to deal with the personality a chat bot brings to the table in varying conversational responses. The first part of the presentation (Test the Bot) is from my experience at the customer location in testing a chatbot which provides first line customer support.
The mathematical accuracy and perceived human intelligence has made way for bots to replace traditional test automation approaches. The second part of the presentation (Test with the Bot) is about couple of tools that we developed using machine learning AI technologies which enables continuous testing by getting quality insights and statistical analysis.

Continuous Hybride Agile ketentesten – Han Duisterwinkel

Praktijk voorbeeld van ketentesten in een deels Agile omgeving. Daarbij wordt aangeven hoe dit aangepakt is, hoe je continuous hybride test en waarom daarvoor gekozen is. Ook wordt toegelicht waarom de term hybride daarbij past. Door interactie met het publiek worden andere opties besproken en sluit ik af met lessons learned.

Volgens Agile wordt met de product owner een Backlog opgesteld en geprioriteerd. In goede samenwerking met de externe software leverancier worden Sprints opgeleverd. Tijdens de presentatie wordt aangegeven hoe deze basis in samenhang met Backlogs van interne service teams opgepakt wordt en hoe dit afgestemd wordt met de (externe) ketenpartners.
Hoe Agile kun je dan zijn en ben je dat dan nog (echt)? Helpt Scaled Agile daarbij? Hoe kun je dan continuous testen op een hybride manier?
De aanpak van het realiseren van de koppelingen, de ketentesten en de resultaten daarvan tot nu toe (Q1 2018 is datum live gepland) zal ik daarbij toelichten. Ook zal ik toelichten waarom het mijns inziens een vorm van continuous hybride Agile ketentesten is.
Eťn van de vragen aan het publiek… hoe zou je dit beter of anders kunnen doen?
Ik sluit of met de conclusies en lessons learned tot nu toe!

Key to Continuous Delivery – Service Virtualization – Ruben Wildeboer & Rix Groenboom

- Service Virtualization is key technique to support modern Continuous Everything trend
- Service Virtualization is and can be used within all stages of SW development (from DEV to ACC testing)
- Service Virtualization can be used to support all different types of testing (regression, functional, performance, security etc)
- Service Virtualization is ready for implementation in modern CI/CD pipelines

Unrestrained access to a trustworthy and realistic test environment—including the application under test and all of its dependent components—is essential for achieving “quality @ speed” with agile, DevOps, and continuous delivery. Service virtualization is an emerging technology that provides teams access to a complete test environment by simulating the dependent components that are beyond their control, still evolving, or too complex to configure in a test lab. Ruben Wildeboer covers the ABCs of service virtualization—what it is and how it impacts Access, Behavior, Cost, and Speed. Learn how it can help you test more rigorously, avoid parallel development bottlenecks, and isolate application layers for debugging and performance testing in two ways—first, by providing access to dependent system components that would otherwise delay development and testing tasks; and second, by allowing you to alter the behavior of those dependent components in ways that would be impossible with a staged test environment.

Part of the Pipeline – Ash Winter

Nobody /really/ likes change, its human nature. Testers have a special relationship with changing tools and techniques, they change and we tend to flounder a little and end up very nervous about our place in the new world. Continuous delivery is one such circumstance, I see and speak to many testers really struggling. However, with a significant shift in outlook and a chunk of personal development testers can excel in environments such as these. Its time to start to get out in front of a changing world, rather than always battling to catch up.

I want to share my experience of adding value as a tester in a continuous delivery environment, what new technologies and techniques I've learned, using your Production environment as an oracle, advocating testability and most crucially, not overestimating what our testing can achieve. Testing is not the only form of feedback, its time to let go of some the aspects of testing we cling to.

Continuous delivery adds richness and variety to our role as testers. To me, it is a facilitator for the autonomy and respect that testers have craved for a long time, so lets get involved...

* My learning and experience of working in a low batch size, high flow environment and the effects that it had on me as a tester.
* Aspects of testing which hinder ones effectiveness in this environment and how to let go of them.
* A few practical ways to add value, based on skills that I gathered along the way...

Ash Winter is a learning tester, conference speaker, unashamed internal critic, with an eye for an untested assumption or claim. Veteran of various roles encompassing testing, performance engineering and automation either as a team member delivering mobile apps and web services or a leader of teams and change. He helps teams think about testing problems, asking questions and coaching when invited.