Begrijp de ontwikkelaar goed en weet hoe je met ontwikkelaars omgaat.
Soft skills zijn voor een tester van levensbelang bij het creëren van test bewustzijn. Het volgende lijstje kan je in ieder geval een beetje helpen bij empathie en hoe je reageert op ontwikkelaars.
Het lijstje is al 10 jaar oud, maar nog steeds erg sterk, misschien wel belangrijker nu agile opkomt!
| Goede tester: | Goede ontwikkelaar: |
| Domein kennis | Kennis van de binnenkant van het product |
| Snel op snelheid komen | Grondig inzicht |
| Onwetendheid is belangrijk | Deskundigheid is belangrijk |
| Model is gedrag van gebruikers | Model is systeemontwerp |
| Focus op wat fout kan gaan | Focus op hoe het kan werken |
| Focus op de ernst van het probleem | Focus op de interesse in een probleem |
| Empirisch | Theoretisch |
| Wat is waargenomen | Hoe is het ontworpen |
| Sceptisch | Gelovige |
| Tolereert verveling | Automatiseert verveling |
| Comfortabel met conflicten | Vermijd conflicten |
| Rapportage van problemen | Begrijpen van problemen |
(uit Pettichord, “Testers and Developers Think Differently: Understanding and Utilizing the Diverse Traits of Key Players on Your Team,” Software Testing & Quality Engineering, Vol. 2, No. 1, 2000, pp. 42-45.)
Nu nog een paar extra tips om je helemaal op weg te helpen:
- Overtuig de ontwikkelaar dat de software kwaliteit hun eerste en belangrijkste prioriteit is.
- Overleggen met de ontwikkelaar over de test strategie en testgevallen is een goede manier om dit proces te starten.
- Communiceer voortdurend met de ontwikkelaar - bijvoorbeeld, laat ze een controle doen op elke zware bevinding voordat je ze aanmeldt in jullie bevindingen database. Dit geeft de ontwikkelaar de tijd om de correcte oplossing te vinden voordat het in het volgende overleg wordt besproken.
Toon intelligentie:
- Ken de functionele en technische specificaties.
- Maak aantekeningen wanneer u vragen stelt, zodat je niet constant dezelfde vragen blijft stellen.
- Log je bevinding met reproduceerbare regressie stappen en geef een duidelijke analyse van de gevolgen van de bevinding indien van toepassing.
Hoi,
ReplyDeleteLijkt het je zinnig om als tester ook meer te weten van het programmeren zelf? Of worden we als tester dan misschien juist (te) vervelend omdat we menen hoe het gebouwd moet worden?
Groet,
Mieke
Tester
Sorry voor het late antwoord, ik krijg bij dit blog geen meldingen als iemand een reactie plaatst (optie heb ik nu wel ingesteld).
ReplyDeleteMaar inderdaad, ik denk als je inzicht hebt hoe software wordt geprogrammeerd dat je beter wordt in het vinden van mogelijke problemen.
Pas er inderdaad wel voor op dat je in je bevindingen niet gelijk aangeeft hoe het opgelost moet worden, dat is voor de ontwikkelaar zelf om te bekijken. Er zijn altijd meerdere oplossingen mogelijk en vanuit zijn of haar vakgebied zal deze creativiteit komen. Samen doorspreken op mogelijke oplossingen kan natuurlijk altijd, let wel even op de karakter van de ontwikkelaar, kan deze wel tegen kritiek, wil hij/zij het zelf oplossen of staat hij / zij open voor ideeën?
Een verdere goede verwoording hiervan kan je vinden in deze blog: http://ubertest.hogfish.net/?p=222