Op 28 september 2023 kwam de 4e blog in geweldige reeks 'Testautomatisering: een zegen of last?' van Polteq online.

Testautomatisering: een zegen of last? (Blog 4 van 6) | Polteq, specialist in software testen

Hierbij een visie/beschouwing op deze blog.
In de basis is de kwaliteit van de blog geweldig. Graag zou ik nog wat aanvullingen willen doen op hetgeen genoemde.

In de laatste alinea staat geschreven: Gebruik design patterns, refactor vaak en vergeet niet: test je code!

Deze tekst is fantastisch in de lijn met de blog: 
blogs about software testing - Testenvansoftware.nl (weebly.com)

waarin te lezen valt dat er 3 categorieën van testautomatiseringstools zijn. Je ziet in dit voorbeeld dat wordt gesproken over de laatste categorie, en van deze laatste categorie zie je dat het echt over de senior ervaring aspecten hiervan gaat. Dit is geen junior software tester materie.

Een ander aspect wat met dit stuk tekst van de blog prima uit te lichten valt, is het feit dat je door rekruuters en bedrijven nogal eens de klaagzang hoort: hoe kan het toch dat senior testautomatiseerders zo ontzettend moeilijk te vinden zijn.
Dat zal ik in de volgende alinea proberen uit te leggen.

Wanneer je aan het testautomatiseren raakt in de laatste categorie en je gaat design patterns toepassen, POM structuur etc, en je raakt daar goed in. 9 van de 10 keren verdien je een stuk minder dan een developer in deze IT wereld. Wat erg vreemd is want je kan bijna even goed programmeren op dat punt en soms hebben de testautomatiseerders zelfs veel meer inzicht in, of affiniteit met. 
De grote dollarteken$ komen dan gemakkelijk in de ogen te staan als deze testautomiseerders hier over babbelen met hun mede IT collega's (developers).

Kortom: dat principe maakt dat de vijver in de sectie "ervaren testautomatiseerder" soms nog leger wordt dan dat deze al was.
Het duurt lang voordat je op dat niveau bent en als je eenmaal op dat niveau bent is de kans ook nog ontzettend aanwezig dat je zomaar opeens doorstroomt naar een andere rol.
​

Vandaag kwam ik op een punt waarbij het testen en het Scrum proces mij tot een woord leidden namelijk: adhocdheid.

adhocdheid is een niet bestaand woord, maar zou eigenlijk moeten worden toegevoegd in het kader van software testen is mijn mening.
In theorie kun je van allerlei regels en procesregels instellen in een bedrijf of team, maar wat je vaak merkt in de IT is dat er dan plotseling en heel opeens aan al dat soort processen voorbij gegaan wordt.

gevoel: "werken we dan niet Scrum meer?"

In theorie.... ... maar in de praktijk gaan we opeens met zijn allen aan wat anders werken, worden de bochten afgesneden en acties gedaan zonder degelijk overleg of (wat ik noem) doortesten.

Crux: naast Gary Klein documentatie.... zeer interessant en op zijn minst onderzoekwaardig!
​

 In zijn algemeen zijn er 3 type software test projecten:

Je kunt als software tester terecht komen of nodig zijn op een project waarbij
1)  de mate van techniek erg laag is.
2) de mate van techniek gemiddeld is.
3) de mate van techniek zeer hoog is.

In project type 1 kom je misschien terecht bij een bank waarbij verzekeringssoftware wordt gebouwd of hypotheeksoftware. Je controleert of de functionaliteit van de software werkt zoals de klant gevraagd heeft. Het kan zijn dat je helemaal niet in aanraking komt testautomatisering. 

In project type 2 controleer je ook software maar daar wordt ook van je gevraagd dat je het automatiseert, het is een type software wat niet 1 keer gebouwd wordt en dan moet het werken, maar met de tijd mee gaat en het blijft aan verandering onderhevig. 
Echter, het is een online informatiesysteem en met een bepaalde testautomatisering tool waar je helemaal geen programmeertaalkennis voor nodig hebt valt het prima te automatiseren.

Project type 3 is een ander verhaal. Om de correcte werking van het informatiesysteem te controleren is een continue ontwikkeling van de testautomatisering nodig. Op alle facetten van het testen.  Je hebt een testtool nodig die in alle gaten en hoeken moet kunnen komen en ieder denkbaar (web)element moet kunnen besturen. Zelfs custom libraries in een programmeertaal zijn nodig om dit automatisch te laten blijven verlopen. Als software tester ben je bijna een programmeur.

Op Internet zijn voorbeelden van een testsyllabus te vinden. Wanneer je Googled op 'test syllabus' kom je bijvoorbeeld op dit exemplaar: ​www.satisfice.com/images/testsyllabus.pdf

Een testsyllabus kun je maken over het vakgebied van software testen, een goede testsyllabus zal dan heel compleet zijn en alle facetten van het software testen benoemen.

Op bedrijfsniveau zou deze syllabus dan al een stuk kleiner kunnen zijn, bijvoorbeeld: 'het anonimiseren van (test)data speelt bij ons helemaal niet.' 
Dit deel kun je dan weglaten.

Op projectniveau ziet de syllabus er wellicht nog weer anders uit, want heb je in het ene project te maken met een informatiesysteem dat geïnstalleerd kan worden op een Operating System van een computer, in het andere project is het een pagina in de Internetbrowser draait die op verschillende devices moet tonen. Deze syllabus ziet er dan weer anders uit.

Het mindmappen, brainstormen en realiseren van zo een testsyllabus levert dan inzicht met wat voor een soort testlandschap je eigenlijk te maken hebt.

Het goed overzicht hebben van een testlandschap op haar beurt geeft weer goede input om een PRA sessie te houden.  Op deze manier maak je de kans kleiner dat je zaken mist.

Een complete syllabus over het vakgebied van software testen zou er dan zo uit zien:
(mindmap made with bubble.us)

Maar niet in ieder bedrijf is ieder sub topic of zelfs topic van toepassing, bijvoorbeeld testdata anonimiseren.

Als je alle verbanden tussen de onderlinge topics en sub topics zou leggen zoals ze in de praktijk zijn, zou je een wirwar aan verbanden creëren:

Kortom, als je de sofware testing syllabus echt helemaal compleet en goed wilt maken,

dan is het een soort van holografische weergave, waarbij de onderlinge verbanden...

...elkaar niet langer kruizen maar gewoon in één oogopslag meteen goed zichtbaar zijn.

Het anonimiseren (als voorbeeld) van testdata is dan niet alleen gelinked aan de database, en SQL kennis misschien wel, maar ook aan testtechnieken en ervaring en/of soft skills.
Als voorbeeld dus, maar dit geldt ook voor alle andere topics en sub topics.
Dat zou de juiste en volledige weergave van een testsyllabus zijn.

Zo een test syllabus kun je op verschillende lagen maken, over het vakgebied van software testen, maar dus ook op bedrijfsniveau maar ook op projectniveau. 
(want op project A hebben ze misschien niet te maken met sub topic testdata anonimiseren, maar op project B dan weer wél.
​