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

De manier van werken:
Is tegenwoordig vaak Agile - Scrum.

Take notice: dat je naast het testen van de User Story's en Epics ook een regressietest-set opbouwt.

In de story test je dan dat je bijvoorbeeld dat je kunt inloggen als een bepaalde rol. ("ik zet winterbanden onder de auto én dit én dat...").
In de regressieset zet je dan vaak een subset van het totaal wat de lading wel dekt. "Ik kan in Winterberg aankomen met de auto").
Als rol X kan ik een bijlage toevoegen aan...
Je gaat vaak wat op een hoger niveau van testen zitten. (met altijd de terugweg naar hoe je kunt inloggen ergens wel te herleiden). Maar je zit meer op het vlak te testen nadat functionaliteiten van eerdere User Story's al zijn samengekomen.

http://www.testnieuws.nl/2020/08/03/zoom-lek-kon-aanvallers-toegang-tot-beveiligde-videomeetings-geven-2/

Een beveiligingslek in Zoom maakte het mogelijk voor aanvallers om toegang tot met wachtwoord beveiligde videomeetings te krijgen. Een combinatie van een zescijferig wachtwoord en geen beveiliging tegen aanvallen waarbij alle mogelijke combinaties worden geprobeerd maakte het mogelijk om toegang te krijgen. De kwetsbaarheid in de Zoom-webclient werd ontdekt door webontwikkelaar Tom Anthony.
Anthony besloot de Zoom-webclient te onderzoeken nadat de Britse premier Boris Johnson een screenshot via Twitter had verstuurd waarin het Zoom meeting-ID van een overleg van de Britse ministerraad zichtbaar was. De Britse overheid gebruikte de betaalde versie van Zoom die standaard met een wachtwoord beveiligd is. Het wachtwoord bestond standaard uit zes cijfers, wat inhoudt dat er 1 miljoen mogelijke combinaties zijn.
Anthony ging ervan uit dat Zoom gebruikmaakte van "rate limiting" om het aantal pogingen het wachtwoord te raden te beperken. Hij ontdekte echter dat het wel degelijk mogelijk was om alle 1 miljoen mogelijk wachtwoorden met hoge snelheid te proberen. Wanneer de Zoom-webclient voor het eerst wordt geopend plaatst die een cookie met daarin een GUID, wat het anonieme gebruikers-ID lijkt te zijn, aldus Anthony.
Op de pagina van de Zoom-webclient kan vervolgens het meetingwachtwoord en de naam van de gebruiker worden opgegeven. Zoom bleek geen rate limiting toe te passen op het proberen van wachtwoorden. Een probleem bij het proberen van 1 miljoen mogelijke wachtwoorden is dat er twee http-verzoeken nodig zijn om een wachtwoord te proberen. Eén request voor het versturen van het wachtwoord en een request om te kijken of het wachtwoord juist is.
Een aanvaller zou daarbij op de server moeten wachten voordat het eerste request is afgerond voordat er een tweede request kan worden verstuurd. Iets wat aan de kant van de server werd bijgehouden, gekoppeld aan het GUID van de gebruiker. Anthony ontdekte dat het mogelijk was om een onbeperkt aantal GUID's op te vragen en vervolgens parallel voor meerdere GUID's de wachtwoorden te proberen. Door verschillende cloudservers te gebruiken zou het zo mogelijk zijn om binnen een paar minuten alle 1 miljoen mogelijke combinaties af te gaan.
De webontwikkelaar merkt op dat bij terugkerende bijeenkomsten steeds hetzelfde wachtwoord wordt gebruikt. Wanneer een aanvaller het wachtwoord van dergelijke meetings weet te achterhalen blijft hij toegang houden. Verder zag Anthony dat het mogelijk was om ook het wachtwoord van geplande meetings te kraken. Na te zijn ingelicht door Anthony haalde Zoom de webclient offline en voerde verschillende aanpassingen door, waaronder het gebruik van alfanumerieke wachtwoorden en het verplicht inloggen via een Zoom-account.