Inwerken nieuwe opdracht
16 juni 2019 

Inwerken nieuwe opdracht

De start van een nieuwe opdracht begint, na de introductie,  natuurlijk met inwerken. Soms heeft het team een inwerkplan voorbereid. In dat geval kun je dit artikel gebruiken om te kijken of er nog nuttige aanvullingen zijn. Het ontbreken van een inwerkplan komt echter vaker voor. Gebruik dit artikel dan 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 je daar mee om kunt 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 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 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 in een vervolgafspraak kunt bespreken.

De projectleider, testmanager of Scrum master zijn de aangewezen personen om je iets te vertellen over de wijze waarop het traject is georganiseerd.

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 is het doel van 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 product owner 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 key players. 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.

Over de schrijver
Ik ben sinds 1983 werkzaam binnen de ICT. Ooit begonnen als Cobol en Credit programmeur en vervolgens de wereld van kwaliteitszorg en testen in gerold. In 1990 ben ik betrokken geweest bij de ontwikkeling van TMap® De jaren daarna heb ik vele functies vervuld binnen het testwerkveld. Waarbij coaching en doceren mij altijd erg is bevallen. Bij Cygnus ben ik met name verantwoordelijk voor het ontwikkelen van content en opleidingen. Heb je een testinhoudelijke vraag of wil je sparren over het stoppen van software fouten bij de bron? Neem dan gerust contact met mij op. Uiteraard ben ik ook beschikbaar voor consultancy opdrachten en coaching.
Reactie plaatsen

arrow_drop_up arrow_drop_down