De start van een nieuwe opdracht begint natuurlijk met inwerken. Bij sommige opdrachten is er een inwerkplan voorbereid. In dat geval kun je dit artikel gebruiken om te bekijken of er nog dingen zijn die ontbreken. Het ontbreken van een inwerkplan komt echter ook voor. Gebruik dan dit artikel als inspiratiebron.

Voor het inwerken is geen standaard stappenplan te bedenken. Ik zal in dit artikel dan ook stilstaan bij een aantal situaties waar je mee te maken kunt krijgen en hoe daar mee om te gaan. Een tester heeft als motto “Gij zult geen aannames doen”. Hou dit in je achterhoofd en stel dus veel vragen. En vergeet daarbij niet door te vragen.

Zeker in het begin is het goed om mondelinge communicatie te gebruiken. Dit geeft je de mogelijkheid om direct door te vragen en wordt het daarna ook makkelijker direct op die collega af te stappen mocht je andere vragen hebben. Het werkt dus drempelverlagend.

Er komt veel nieuwe informatie op je af. Het is maar voor weinigen weggelegd om alle verkregen informatie direct blijvend in hun geheugen op te slaan. En dan is het nog maar afwachten of je het terug kunt vinden in je geheugen 😉 Het is beter om veel aantekeningen te maken. Verwerk die aantekening in een naslagdocument. Je zult ervaren dat bij het verwerken van de aantekeningen er nog dingen niet helemaal duidelijk zijn. Verzamel de vragen, zodat je deze naar een vervolgafspraak kunt meenemen.

De projectleider of testmanager zijn de aangewezen personen om je iets te vertellen over de wijze waarop het project is georganiseerd. Bij een Scrum werkwijze zijn de scrum master en product owner de personen die een algemene introductie kunnen geven.

Inwerken kan op verschillende manieren en is afhankelijk van:

• De fase waar het traject zich in bevindt
• De beschikbare tijd van collega’s
• De beschikbare documentatie
• De gewenste snelheid om productief te kunnen zijn
• De testtooling die eventueel wordt gebruikt

Wat wil je bereiken met inwerken?

• Kennis opdoen van de functionaliteit van de applicatie
• Kennis opdoen van de wijze van documenteren van de requirements, specificaties en testgevallen
• Kennis opdoen van de te gebruiken procedures voor het testen zelf of voor bijvoorbeeld het beheren van bevindingen of testdata.
• Kennis maken met de eventueel al ontwikkelde software

De fase waar het project zich in bevindt bepaalt mede de mogelijkheden en diepgang van inwerken

Het project bevindt zich in de opstartfase

Wanneer het traject net gestart is, dan is er nog niet veel of alleen een projectplan en business case. Het inwerken beperkt zich dan tot het bestuderen van algemene documenten. Het is in deze situatie ook aan te raden om te praten met iemand uit de business die iets kan vertellen over de organisatie en de bedrijfsprocessen die door de te ontwikkelen applicatie ondersteunt moeten gaan worden. De projectleider of productowner kunnen meer vertellen over de te behalen doelstellingen. Welke problemen moet de applicatie oplossen en wat is de globale planning. Is er een testcoördinator dan kan deze je meer vertellen over de teststrategie indien aanwezig.

Het project bevindt zich in de ontwikkel en testfase

Wanneer het ontwikkelen van de software en het testen al is begonnen, ga dan in eerste instantie praten met een aantal keyplayers. Ik zelf begin dan het liefst bij de architect. Deze kan een overall plaatje schetsen van de applicatie, welke business processen ondersteunt moeten worden, welke problemen er door de applicatie in de organisatie opgelost gaan worden en de volgorde waarin de verschillende onderdelen ontwikkeld worden en bovenal waarom. Vervolgens kun je met een functioneel ontwerper bespreken hoe de applicatie ingedeeld gaat worden in functionaliteiten en met je collega testers over de te hanteren testaanpak. Wanneer je hier 3 x een uurtje voor inplant ben je al aardig op weg. Niet dat je dan al alles weet. De diepgang komt als je echt aan de slag gaat.

De volgende inwerk activiteiten die je kunt doen zijn afhankelijk van

• • Requirements, specificaties en testen aanwezig
    Wanneer er documentatie aanwezig is, is het altijd de vraag “Wat wel en wat niet lezen”. Vraag in de gesprekken met de key players, welke documenten zij aanraden om als eerste te lezen. Ik zelf begin bij de high level requirements om een algemeen beeld te krijgen. Vervolgens lees ik het document waar de functionele architectuur in is beschreven. Dat document geeft mij in hoofdlijnen een beeld van de te ontwikkelen functionaliteit. Om inzicht te krijgen in de manier waarop de testgevallen worden beschreven bestudeer ik vervolgens een stukje detail functionaliteit met de bijbehorende testgevallen. Na al dat lezen zijn er weer een hoop vragen die je kunt bespreken. En zo kom je steeds een stukje verder.
  • Geen requirements, specificaties en testen aanwezig
    De documentatie zit in dit geval in de hoofden van je collega’s. Je zult dan ook regelmatig met je collega’s in overleg moeten gaan om informatie te verkrijgen. Wanneer volgens scrum wordt gewerkt, zorg er dan voor om bij de refinement en planning betrokken te worden. Daar krijg je gedetailleerde informatie over de te ontwikkelen functionaliteit en kun je mee bepalen met welke diepgang er getest moet worden.

De volgende stap is mee te kijken met een van de testers die al langer met de applicatie werkt. Laat de tester, aan de hand van een bestaand testscript, uitleggen hoe de testuitvoering gedaan wordt. Om vervolgens zelf aan de gang te gaan met een ervaren tester die over je schouder meekijkt.

Procedures en tooling

Naast het opdoen van inhoudelijke kennis, zul je ook moeten weten welke procedures en tools je moet gebruiken.

Je collega’s kunnen aangeven welke procedures er zijn. Wanneer deze zijn beschreven lees ze dan door en gebruik ze zeker de eerste tijd als naslagwerk. Zijn ze niet beschreven laat een van je collega’s dan het een en ander uitleggen. Maak daarbij aantekeningen en verwerk die vervolgens in een document. Dan is er meteen een korte instructie beschikbaar voor jezelf en voor anderen.