Het belang van een goede testsyllabus

 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.
​