Test Automation Days 2022 Presentaties: Automation in Testing en Observability

Dag twee van de Test Automation Days 2022 op 15 en 16 juni jl. bestond uit presentaties. De sprekers kwamen uit binnen- en buitenland. Ze hadden het over lessen uit hun carrière als testautomatiseerder, is het mogelijk dat 1 persoon alle activiteiten van een testautomatiseerder uitvoert (nee), en belangrijke zaken zoals testability en observability. Tobias zet aan aantal presentaties op een rij. Lees ook zijn verslag over de eerste dag van de Test Automation Days met workshops.

“Het was boeiend veel mensen met vele jaren ervaring te horen vertellen. Veel thema’s kwamen steeds terug zoals Automation in Testing, waarbij je kijkt welke test- en ontwikkelprocessen je kunt ondersteunen met testautomatisering. Ook testability was een veel gehoorde term: hoeveel testpijn kost het testen van een applicatie? Verminder deze testpijn door met je collega’s te praten en samen te werken. Als laatste was samenwerking en communicatie het sleutelwoord bij veel problemen.

Do we really need a test automation engineer? – Bas Dijkstra

Testautomatisering is te breed en lastig om door één persoon te laten doen. Het is een activiteit die het hele team moet uitvoeren. Het bevat vaardigheden voor testen, ontwikkelen, testautomatiseringstools en andere software engineeringsactiviteiten. Een testautomation engineer moet voortdurend de keuze maken of hij zijn programmeervaardigheden verbetert of aan zijn testvaardigheden werkt. Aangezien de rol van de tester verandert naar overzicht houden over de kwaliteit is de term quality engineer passender dan test automation engineer.

Naar mijn mening was dit een bekend verhaal waarbij je de verantwoordelijkheid van kwaliteit deelt met het hele team. 

Test Automation Days 2022 presentaties

 

Test4Change: 4 steps for starting Test Automation – Richard Scholtes

De spreker deelde lessen uit zijn ervaring van meer dan 10 jaar testen. Namelijk dat je als tester de leiding moet nemen over het testproces. Maak een plan in vier stappen voor de korte en lange termijn voor het testen en de testautomatisering.

  • De eerste stap is het bepalen van de scope van het team, de technologie, de tester en de testactiviteiten.
  • De tweede stap is klein te beginnen met testautomatisering en te kijken hoe testautomatisering andere processen kan ondersteunen.
  • De derde stap is een tool selecteren of zelf te maken.
  • Als laatste en vierde stap moet je documenteren. Documenteer alles wat je doet zodat je ieder moment met vakantie kunt of weggeroepen omdat je kind geboren is.

 

Don’t judge a test by its front end! – Michel Lalmohamed

Front-end testen worden duur, langzaam en flaky genoemd. Duur is niet te voorkomen, omdat je laat in het ontwikkelproces test. Langzaam en flaky zijn wel op te lossen met een goede aanpak zoals het maken van een wachtstrategie. Maak je eigen locators en geef de applicatie de tijd om te laden. Hierdoor begrijp je goed wat er gebeurt en kun je voorkomen dat testen flaky worden.

 

Testing woes, feedback slows as complexity grows! – Rob Meaney

Dit was een redelijk ingewikkeld praatje over complexiteit. Onbeheersbare complexiteit is de oorzaak van bijna alle problemen in de softwareontwikkeling. Een complexe applicatie zorgt ervoor dat mensen het model niet begrepen. Dit hangt samen met een slecht ontwerp van de software dat zorgt voor moeilijk uit te voeren testen. Testautomatisering is een manier voor het vastleggen van kennis van een systeem. Begrijp je het systeem niet goed, dan zal de TA ook niet goed zijn.

De Complexiteit en dus de testbaarheid van een systeem verbeteren kan door 4 attributen te optimaliseren:

  • controllability
  • observability
  • decomposability
  • simplicity

 

Observability meets a Flaky Test – João Proença

Goede observability kan je een hoop ellende schelen bij het ontwikkelen en testen van je applicatie. Observability betekent dat je goed kunt zien wat een applicatie doet of heeft gedaan. Vaak wordt hiermee uitgebreide logging bedoeld. Het kan ook iets zijn als het maken van screenshots en videos van je testen. Het verschil tussen monitoring en observability is dat monitoring een antwoord geeft op vooraf opgestelde vragen. Monitoring gaat over de known unknown van de applicatie. Zoals hoeveel errors zijn er en hoeveel cpu/geheugengebruik en bezoekers. Observability gaat over de unknown unknowns. Dus van tevoren weet je niet dat over iets een vraag hebt. Bijvoorbeeld waarom een test gefaald heeft of een applicatie gecrasht. Kun je antwoord geven op dit soort vragen zonder een nieuwe code naar productie te brengen, dan is de observability goed.

Dit kan ervoor zorgen dat je een flaky test goed kunt doorgronden door het bijhouden van een goede logging, ook op testomgevingen. Het bijhouden is de eerste stap. Daarna moet je ook zorgen voor het bij elkaar opslaan van de logging en zorgen dat die goed doorzoekbaar en filterbaar is.

 

Automation in Testing – Towards a paradigm shift – Ingmar Goudt

Testautomatisering kun je ook anders inzetten dan alleen voor het automatiseren van test cases. Het ondersteunt dan op een veel bredere manier het test- en ontwikkelproces.

Voorbeelden zijn het klaarzetten van situaties voor exploratief testen, het voorbereiden van testdata of het vernieuwen van certificaten.

Belangrijke aspecten voor testautomatisering zijn de testbaarheid van de applicatie en het afdekken van risico in plaats van code coverage. Het belangrijkste is: overleggen met collega’s. 

 

Reinforcing Good Testing Behaviors: Directions for Intelligent AI Behaviors in Software Testing – Martijn van Otterlo

Onderzoek in reinforcement learning kan heel interessant zijn voor testen, maar staat nog ontzettend in de kinderschoenen. Een bot kan zonder script in een applicatie rondklikken. Geef hem een bepaald doel om te bereiken, dan kan hij dit ook gaan behalen. Bijvoorbeeld zo veel mogelijk van een applicatie gaan ontdekken en kijken of hij fouten tegenkomt. Dan moet je dus nadenken over wat je wilt belonen (het ontdekken van een nieuw stuk van de applicatie) en waar die naar op zoek is (specifieke fouten). Dit soort software kan ook een applicatie leren kennen en dat vastleggen voor het vaker uitvoeren van deze scripts. Een voorbeeld van een applicatie waarmee gewerkt wordt voor het onderzoek is Testar.

Dit was als allerlaatste een vrij theoretische en technische presentatie op de conferentie. Best wel pittig zo aan het einde van de dag. Leuk om te horen was dat het een heel actief onderzoeksgebied is, maar dat er ook nog heel veel onderzoek gedaan moet worden. Dit ging over reinforcement learning, een onderdeel van machine learning, wat weer een onderdeel is van kunstmatige intelligentie (AI).