Computable.nl
  • Thema’s
    • Carrière
    • Innovatie & Transformatie
    • Cloud & Infrastructuur
    • Data & AI
    • Governance & Privacy
    • Security & Awareness
    • Software & Development
    • Werkplek & Beheer
  • Sectoren
    • Channel
    • Financiële dienstverlening
    • Logistiek
    • Onderwijs
    • Overheid
    • Zorg
  • Computable Awards
    • Overzicht
    • Nieuws
    • Winnaars
    • Partner worden
  • Vacatures
    • Vacatures bekijken
    • Vacatures plaatsen
  • Bedrijven
    • Profielen
    • Producten & Diensten
  • Kennisbank
  • Nieuwsbrief

Tester goede sparringpartner voor ontwikkelaar

16 december 2011 - 11:533 minuten leestijdOpinieSoftware & Development

De samenwerking tussen een ontwikkelaar en een tester gaat niet altijd over rozen. Geschillen en irritaties ontstaan vaak tussen beide partijen. Is een tester nou een vervelende lastpak of een goede sparringpartner?

Een ontwikkelaar krijgt vaak te maken met het realiseren van oplossingen en/of het uitbreiden van bestaande oplossingen. Bij deze oplossingen zijn vaak de wensen al bekend. De specificaties worden aan de hand van wensen bepaald en de totale werking van de oplossing wordt dan in documentatie vastgelegd. Uiteindelijk kan een ontwikkelaar aan de slag. Als ontwikkelaar zorg je voor de realisatie, maar hoe zorg je voor kwaliteit? Alleen testen is zeker niet voldoende. Zeker niet als het gaat om het testen van je eigen werk. Een optie is om iemand in te schakelen die de testwerkzaamheden kan doen op het opgeleverde werk.

Als ontwikkelaar zorg je ervoor dat een oplossing eerst werkt volgens de specificaties die zijn vastgesteld. Tijdens het ontwikkelen voer je af en toe kleine testwerkzaamheden uit om onjuistheden te achterhalen, zodat deze ook meteen hersteld kunnen worden. Uiteindelijk is het moment dan zover om het werk op te leveren. Het werk is afgerond volgens de specificaties en de functionaliteit is nogmaals goed gecontroleerd. Als ontwikkelaar ben je vervolgens tevreden over het eindresultaat. Het is voltooid en dus gereed om het werk over te dragen aan de testers.

Voor een ontwikkelaar kan een afkeuring van de testers op het opgeleverde werk een ergernis zijn. Want geen goedkeuring betekent geen oplevering. Hierdoor kan discussie ontstaan tussen de tester en de ontwikkelaar. Waarom is het niet goedgekeurd? Begrijpen de testers het weer niet? Of heb ik het niet goed gedaan? Er kunnen een paar mogelijke oorzaken zijn:

– meningsverschillen tussen de testers en de ontwikkelaars;
– onvolledig of onvoldoende getest vanuit de ontwikkelaars.

Meningsverschillen zijn vaak te voorkomen door concrete punten vast te leggen op papier. Helaas kunnen niet alle details van te voren worden opgenomen. Meestal zijn deze pas kenbaar nadat de oplossing ‘visueel waarneembaar’ is. Alle kleine details komen dan boven tafel. Dit kan dus leiden tot irritaties bij de ontwikkelaars want het vereist natuurlijk weer aanpassingen, ofwel: extra inspanningen.

Al met al is het zeker niet voldoende als een ontwikkelaar zijn eigen werk test. Een ontwikkelaar legt zijn focus namelijk met name op de technische vlakken waardoor de testwerkzaamheden zich beperken tot het technische deel. De functionele aspecten die bijvoorbeeld belangrijk zijn voor de eindgebruikers kunnen dan makkelijk over het hoofd worden gezien. Deze twee aspecten leiden al snel tot verscheidene vragen: ‘Tot hoe ver zou een ontwikkelaar zijn eigen werk moeten testen? Het gehele werk? Of is testen volgens de specificaties voldoende?’

Naar mijn mening zijn testers een goede sparringpartner voor ontwikkelaars. Zij hebben namelijk een heel andere blik op het opgeleverde werk: minder technisch en meer in het belang van de oplossing. Op deze manier leveren ze een grote bijdrage aan de kwaliteit van het eindresultaat. Hoeveel irritatie je als ontwikkelaar ten opzichte van de testers ook hebt, het valt niet te ontkennen dat zij onmisbaar zijn in een ontwikkeltraject.

Meer over

Testing

Deel

    Inschrijven nieuwsbrief Computable

    Door te klikken op inschrijven geef je toestemming aan Jaarbeurs B.V. om je naam en e-mailadres te verwerken voor het verzenden van een of meer mailings namens Computable. Je kunt je toestemming te allen tijde intrekken via de af­meld­func­tie in de nieuwsbrief.
    Wil je weten hoe Jaarbeurs B.V. omgaat met jouw per­soons­ge­ge­vens? Klik dan hier voor ons privacy statement.

    Whitepapers

    Computable.nl

    Staat van Digitale Connectiviteit binnen de Bouw- en Installatiebranche 2025

    Digitale connectiviteit is de kern van veel processen in de bouw en volgens insiders van strategisch belang voor de toekomst van de sector. Waar sta jij?

    Computable.nl

    Design Sprints: 4 dagen van idee naar prototype

    Hoe zet je in vier dagen tijd een gevalideerd prototype neer met Design Sprints?

    Computable.nl

    Resultaatgericht Samenwerken (RGS).

    RGS is een gestructureerde methode die vastgoedprofessionals direct ondersteunt bij kwaliteitsverbetering, kostenefficiëntie en verduurzaming.

    Meer lezen

    ActueelFinanciële dienstverlening

    Rechter kraakt falende erp-consultant

    ActueelCarrière

    Kort: Paul Broekhuizen leidt Fsas Benelux, Brink Software verkocht (en meer)

    ActueelData & AI

    Europese beurzen voor grensverleggend UvA-onderzoek in it

    AchtergrondSoftware & Development

    License to bill

    AchtergrondData & AI

    Ai-bedrijf Braincreators stelt de mens weer centraal in nieuwe koers

    ActueelSoftware & Development

    Europese tech hongert naar Navo-orders

    10 reacties op “Tester goede sparringpartner voor ontwikkelaar”

    1. Een tester schreef:
      22 december 2011 om 08:17

      Tester zijn niet alleen goede sparringspartners voor ontwikkelaars maar ook voor business analisten, informatie analisten, requirement opstellers, de business, etc.

      Jammer genoeg wordt in de praktijk de tester vaak pas op het laatst bij het project betrokken, wanneer ontwikkeling al een feit is. Terwijl iedereen toch inmiddels weet dat hoe eerder je de fout eruit haalt des te minder de herstelkosten zijn? Gelukkig worden bedrijven zich hier steeds meer bewust van.

      Login om te reageren
    2. Erik schreef:
      22 december 2011 om 08:27

      Wat een slecht artikel zeg. Wel heel erg gericht op het gelijk van testers. Zo zijn er bij meningsverschillen tussen ontwikkelaar en tester nog wel een paar mogelijkheden, die niet genoemd worden. Bijvoorbeeld: de tester heeft zijn werk niet goed gedaan of de specs niet goed geïnterpreteerd.

      Login om te reageren
    3. Pascal schreef:
      22 december 2011 om 08:51

      Erik,
      Niet te vergeten het aantal keren dat specs incompleet zijn, of er eigenlijk helemaal geen specs zijn doch slechts een kreet in de wandelgangen.
      Je zou ze de kost niet willen geven.
      Hebben we het nog niet gehad over specs die tijdens de ontwikkeling nog eens zes keer zonder enig overleg voledig nieuw verzonnen worden.

      ICT… wat een vak he.

      Login om te reageren
    4. Robin Rijken schreef:
      22 december 2011 om 11:24

      Uit ervaring weet ik dat slecht opgeleverd werk vaak komt door de gebrekkige functionele en technische ontwerpen. Door voor de programmeerfase de testscripts te schrijven, zijn al een heleboel fouten te onderkennen.
      Maar al te vaak heb ik mee gemaakt dat er te veel aannames worden gedaan die achteraf niet juist blijken te zijn.
      Maak de functionele en technische ontwerpen zo uitgebreid mogelijk. Dit voorkomt dat er te veel “foute” progrmmatuur wordt opgeleverd.

      Login om te reageren
    5. Een tester schreef:
      22 december 2011 om 12:58

      @ Robin Rijken

      De schuld ligt ook vaak bij de business. We willen “iets”. Ja prima. definiëer iets.

      Login om te reageren
    6. Cordny Nederkoorn schreef:
      22 december 2011 om 14:45

      Als ervaren tester weet ik dat je als tester echt niet hoeft te wachten op de ontwikkelaar, business analist of ontwerper. Dat is een aanname die een goede tester snel afleert.
      Dus testers, een goed voornemen voor 2012:
      Ga, indien iets niet duidelijk is, het navragen bij de verantwoordelijke persoon en vraag door tot het duidelijk is. En niet via email, maar aan het buro als het kan.
      En doe dit zo vroeg mogelijk in het testproces.

      Een voornemen waar ik me, net als de voorgaande jaren, aan wil houden in 2012.

      Login om te reageren
    7. Cordny Nederkoorn schreef:
      22 december 2011 om 14:51

      PS:
      Tester (ook @Robin en @de tester) laat je werk reviewen.
      Niet alleen door een collega-tester, maar ook een ontwikkelaar, ontwerper of business-analist. Wij testers maken ook fouten en wellicht kan er zo in een vroeg stadium mogelijke vertraging vermeden worden.

      Login om te reageren
    8. Michiel Croon schreef:
      22 december 2011 om 20:52

      Het betrekken van testers, business analysten, programmeurs: allemaal waar.

      Vergeet echter een partij niet: “ontwikkeling is de eerste fase van beheer”. Afhankelijk van het onderzoeksbureau blijkt 60-80% van kosten van een applicatie in beheer te zitten. Het loont om al in de ontwikkelfase een beheerder te betrekken bij het test- en implementatietraject.

      Login om te reageren
    9. ir. K.E. van Zanten schreef:
      23 december 2011 om 12:58

      @ Michiel Kroon: Helemaal juist: na een project van een jaar zit Beheerd (technisch en functioneel) zeven jaar of langer vast aan het systeem. Terecht dat ook Beheer het ontwerp reviewt.

      Jammer genoeg wordt dat reviewen niet altijd (of zelden of nooit) serieus opgepakt: Na de lunch onderuit in de bureaustoel, lekker in het zonnetje, bekertje koffie erbij en de voeten op het bureau: “Zo, nu even dat ontwerp reviewen. (geeuw)” Met als resultaat: “Ja, dat is wel ongeveer wat we bedoelen.” Daar hebben we niet zoveel aan.

      Als een reviewer niet vanuit zijn eigen functie het belang van goed reviewen ziet (als het niet van binnen komt) dan kan een projectmanager nog bevorderen dat er serieus gereviewd wordt. Maar projectmanagers worden beoordeeld op hoe zij het project hebben afgerond – niet op hoeveel nazorg hun product nodig heeft. Dus hebben zij geen prikkel om serieus werk te maken van reviews.

      Dan komt de bal te liggen bij de opdrachtgever. Volgens PRINCE2 is de “stuurgroep”, het gremium waarin opdrachtgever overlegt met de gebruikersorganisatie en de bouwers, verantwoordelijk voor kwaliteitsbewaking.

      Is dat moeilijk? Nee, niet echt: vraag de projectleider om bij het periodieke voortgangsoverleg een lijstje te tonen waarin per ontwerp is aangegeven wanneer het is gereviewd, door welke functionarissen, hoeveel bevindingen er zijn genoteerd en welke afhandeling werd afgesproken. In PRINCE2 heet dat een Quality log.

      Login om te reageren
    10. de hooij schreef:
      20 januari 2012 om 15:08

      zolang je maar niet zoiets doms bedenkt als ‘stragile testen’ gaat alles wel goed. gewoon old-school. eerst discussie, dan feiten, dan testplan.

      en niet andersom.

      Login om te reageren

    Geef een reactie Reactie annuleren

    Je moet ingelogd zijn op om een reactie te plaatsen.

    Populaire berichten

    Meer artikelen

    Uitgelicht

    Partnerartikel
    AdvertorialInnovatie & Transformatie

    Ontdek de toekomst van IT-support en m...

    Op 16 september 2025 vindt in de Jaarbeurs in Utrecht een gloednieuw event plaats dat volledig is gericht op IT-professionals:...

    Meer persberichten

    Footer

    Direct naar

    • Carrièretests
    • Kennisbank
    • Planning
    • Computable Awards
    • Magazine
    • Abonneren Magazine
    • Cybersec e-Magazine
    • Topics

    Producten

    • Adverteren en meer…
    • Jouw Producten en Bedrijfsprofiel
    • Whitepapers & Leads
    • Vacatures & Employer Branding
    • Persberichten

    Contact

    • Colofon
    • Computable en de AVG
    • Service & contact
    • Inschrijven nieuwsbrief
    • Inlog

    Social

    • Facebook
    • X
    • LinkedIn
    • YouTube
    • Instagram
    © 2025 Jaarbeurs
    • Disclaimer
    • Gebruikersvoorwaarden
    • Privacy statement
    Computable.nl is een product van Jaarbeurs