Implementing Test Automation, a story about changing insights and experiences

Today I gave a presentation on the Test Automation day. In this presentation I explain a simple strategy for implementing Test Automation in your organization. A simple strategy? I tell the story of my experience so far and look back in retrospective to the presentations I gave at the Test Automation Day before.
In this presentation I state that:

• Organizational Maturity (like measured with TPI or TMMi) should not raise a threshold for getting started
• In order to become good in Test Automation, we need to get started and learn from our mistakes (fail forward)
• There is a shift from technology and tool selection toward selling the business case
• But the real implementation is a process of organizational change, where people, and budgets play a key role.
• People need to learn their new roles, need to work with new processes and you need to have a good story if you want to interfere with projects.
• In the end, I conclude that once you completed the journey, and got the organization to start with test automation, you end up with the technical challenges again: What tool are you going to use, what architecture, and how do you write effective scripts….

A simple strategy? I am still learning.

Implementing Test Automation, a story about changing insights and experiences from Derk-Jan de Grood

 

 

The above presentation was preceded by a presentation from Ard Kramer. Today he gave this presentation alone, previously we gave this presentation together at the Dutch testing conference. The topics are very much related and its slides can be found here:

Experience Story: Implementing Test automation in your organization from Derk-Jan de Grood

 

Test Automation is an Industry standard

With the Test Automation Day coming up next Thursday, I decided to dedicate my new column on the EuroSTAR community pages to this topic also:

I’ll explain how the adoption to tool aided tests is influenced by:

• Economics,
• Different systems and development methods,
• Continuous Delivery,
• A shift to production,
• The test tool market and
• Generations of testers

As I conclude:

“I do not aim to state that automatic testing can replace manual testing completely. Manual testing is another ball game than running automatic checks, but everything indicates that tool aided testing is on the rise. I have noticed that current generation of testers is often reluctant to automation, whereas the new generation of testers perceives automation as a standard practice. They will thus contribute to a greater adoption of automated testing. Even testers that are trying to stay away from technical testing will sooner or later be confronted with tooling and test automation. It’s inevitable, so better be prepared.”

You can read the full column on the EuroSTAR community pages.

The 3 phases of Test Automation

This week all subscribers of Bits & Chips magazine received the issue pictured above. For this issue I wrote a column about the 3 phases in Test Automation. The article describes how to deal with the organizational aspects of introducing TA in your company. This article is closely related to the presentation I’ll be giving on the Test Automation day in Rotterdam. With kind permission of the editor of B&C I publish the full text below:

Drie fases in testautomatisering

Binnenkort wordt in Rotterdam voor de vierde keer de Test Automation Day (TAD) gehouden. Doel is om testautomatisering te promoten en kennis uit te wisselen over de in- en uitvoering ervan. Ook nu mag ik weer mijn visie komen geven. Ik vind het leuk dat mijn verhaal elk jaar groeit; de ontwikkeling loopt gelijk op met mijn eigen leercurve.

Traditioneel was automatisering iets voor een kleine groep technische testers. De bulk waagde zich liever niet aan tooling anders dan voor de procesondersteuning. Functioneel testen prima, maar dan het liefst handmatig via de GUI aan de hand van vooropgestelde testgevallen in Word of Excel. Als ik automatisering op de agenda zette, proefde ik veel koudwatervrees. Vaak voor niets, want na een korte maturity assessment was de conclusie vaak: ‘Uw organisatie is er nog niet klaar voor.’ Ik verdenk veel testers ervan dat ze dit eigenlijk wel prettig vonden. Zo konden ze de techniek buiten de deur houden en blijven doen waar ze goed in waren: handmatig testen, processen inrichten en door middel van verbetertrajecten de ontbrekende randvoorwaarden invullen.

Tegenwoordig komen we hier niet meer mee weg. Testautomatisering is geen optie, het is noodzaak. Betere tooling en samenwerking met ontwikkelaars maakt dat de drempel veel minder hoog is. Op mijn eerste TAD vertelde ik over een klantencase waarbij ik een negatief advies heb gegeven. Hoewel ik daar in dit specifieke geval nog steeds achter sta, had ik graag willen adviseren: ‘Ga aan de slag, begin met leren.’ Wel kwam ik hiermee in een nieuwe fase. Eentje waarbij de businesscase centraal staat.

Als de testers en ontwikkelaars ervan overtuigd zijn dat het beter is om de tests voor een groot deel automatisch uit te voeren, betekent dat nog niet dat we alle handen op elkaar hebben. Managers redeneren vanuit de businesscase. Hen kunnen we overtuigen door ons in te leven in hun denkwereld en uit te leggen, het liefst kwantitatief, hoe de investering bijdraagt aan de businessdoelen. Ondanks dat dit negen van de tien keer snellere, betere en goedkopere software is, vergt het enige creativiteit en rekenwerk om een sluitend verhaal op te stellen. Vorige jaar presenteerde ik op de TAD een checklist die inzichtelijk maakt welke extra kosten we moeten maken als we randvoorwaarden niet hebben ingevuld (je kunt de checklist downloaden onderaan mijn eerdere post over dit onderwerp)

Inmiddels ben ik weer een stapje verder. Randvoorwaarden moeten nog steeds ingevuld, businesscases nog steeds opgesteld, maar mijn focus ligt nu op de organisatie. Hoe gaat die om met toolkeuzes als verschillende projecten werken aan automatische testsets? Enerzijds willen we de projecten autonoom laten bepalen wat voor hen het beste is; anderzijds zijn er veel kosten verbonden aan wildgroei binnen het toollandschap. Hoe kunnen we centraal kennis borgen en voorkomen dat elk team het wiel opnieuw uitvindt, zonder innovaties te smoren?

Bij een van mijn klanten heb ik gezien hoe testautomatisering een hefboom kan zijn voor verdere professionalisering. Hiermee draaien we het oude adagium om: we wachten niet met de invoering van testautomatisering totdat we voldoende volwassen zijn, maar we maken flinke groeispurten doordat we gaan automatiseren. Ineens is er een noodzaak om regressietests vast te leggen. De vraag welke tests we als eerste automatiseren, triggert een discussie met de business over risico’s. Omdat we tests vaak gaan herhalen, ontstaat de vraag wie ze beheert. De staande organisatie krijgt hierbij een centrale rol, omdat zij de geautomatiseerde tests na oplevering tot in lengte van dagen zal runnen. Zij mag dus ineens eisen en wensen uitspreken richting de projectorganisatie, en dat blijkt best een omslag. Rollen en verantwoordelijkheden worden voor het eerst uitgesproken en ik zie dat duidelijk wordt welke doelen we met elkaar nastreven.

Testautomatisering is nog nooit zo interessant geweest. Ik kijk uit naar de conferentie op 19 juni.