Herken je deze uitspraak? Anders gezegd, ben jij iemand die dit wel eens heeft uitgesproken? Geloof jij erin dat de testdiscipline in z’n volle breedte de kwaliteit erin kan testen? Eigenlijk zou je eens zonder door te lezen en zonder er lang over na te denken een antwoord moeten geven op deze vraag. Dit kun je doen door onderaan deze column een reactie achter te laten, gewoon je primaire reactie. Daarna pas doorlezen, herkauwen en nog eens je reactie geven.
Mijn primaire reactie op deze opmerking is gelijk aan die van @clemensreijen, @marcelhogenhout en @vjburns: nee dit kan niet, als tester kun je niet zomaar de kwaliteit erin testen.
Gek genoeg reageren @iriseL, @adorsek en @jjcannegieter tegenovergesteld en geven respectievelijk aan dat de opdrachtgever dit wel denkt, het in een nieuwe wereld zo zal gebeuren maar dat het echter wel erg prijzig is.
Op mijn vraag (@andreasprins), of vroegtijdig valideren en verifiëren van bijvoorbeeld de requirements er niet voor zorgt dat je vroegtijdig de kwaliteit kunt verhogen, vraagt @marcelhogenhout zich toch af of je op z’n minst kwaliteitsverlies kunt voorkomen, de vraag is hoe je het bekijkt.
Dit is waar ik een soort van spanningsveld zie ontstaan, nee testers bouwen niet dus kunnen niet de kwaliteit erin testen of bouwen, en toch kunnen we een positieve bijdrage leveren aan de kwaliteit van de software. Volgens mij gaat het er om of we de kwaliteit erin kunnen testen. Het woord erin suggereert iets van er is al iets gebouwd en daarna doen wij als testers er nog iets in of bij. Terwijl de woorden een positieve bijdrage leveren voor mij iets suggereert van vroeg betrokken zijn en dan actief een positieve bijdrage leveren aan de kwaliteit.
Dit overdacht hebbende, zouden we dan het volgende kunnen concluderen:
- De kwaliteit er achteraf in testen is niet mogelijk omdat het product er dan al staat
- Vroege betrokkenheid kan kwaliteitsverlies voorkomen
- We moeten naar een nieuwe manier van denken waar we ons niet alleen verantwoordelijk voelen voor het inzichtelijk maken van de kwaliteit maar ons ook verantwoordelijk voelen voor de kwaliteit zelf.
Op het moment dat we ons als testers ook verantwoordelijk voelen voor de kwaliteit, en we zijn 1 team dus testers zijn ook daadwerkelijk verantwoordelijk voor de kwaliteit, dan zullen we ons ook vroeg moeten inzetten om deze kwaliteit samen te realiseren.
Daarmee verandert mijn primaire reactie, de kwaliteit, die helpen we mee erin te testen. De vraag is dan alleen of gezien de lading die het woord testen heeft, dit het juiste woord is.
De kwaliteit? O, dat is ook een aangelegenheid van testen, kunnen we al beginnen met toetsen? Dan bouwen we samen de kwaliteit erin!
Wat is jou primaire, secundaire of morgen zelfs tertiaire reactie? Laat deze hier achter, je kunt natuurlijk ook reageren middels #erintesten.
————————————————–
Andréas Prins is testconsultant, lid van het R&D team bij Software Control Sogeti en houdt een blog bij op TestingTheFuture.net
Naar mijn mening; Ja, dat kunnen we.
Onze bijdrage in de voortbrenging is het zorgen dat obv onze bevindingen ontwerp en realisatie de kwaliteit van het product verhogen. Daarmee leveren we,weliswaar indirect, een bijdrage welke de kwaliteit van het product verhoogt.
Kwaliteit is van toepassing op alle disciplines binnen het (project)team. Kwaliteit in het maken requirements, kwaliteit in bouwen, kwaliteit in de uitvoer van projectmanagement, kwaliteit in het proces van testen.
Dat is 1 kant van kwaliteit, kort gezegd kwaliteit van werken.
Als we – en de ‘we’ in dit geval beslaat alle disciplines- bemerken dat de manier van werken niet optimaal is, zullen we dit melden, en het liefst met oplossingen komen. Doen alleen testers dit? Welnee.
Dan is er de kwaliteit van de opgeleverde producten.
In eerste instantie zijn de disciplines daar zelf verantwoordelijk voor. In tweede instantie zijn we daar allemaal verantwoordelijk voor. Niet alleen het testteam. Het zou ook een beetje zot zijn als alleen testers zich druk maakten over de output van anderen. Wat nu als een bouwer constateert dat een functioneel ontwerp onvolledig is en de tester dit niet heeft gezien? De bouwer zal dan zelf zijn mond open trekken om een beter ontwerp te krijgen. Hopla. Kwaliteitsverbetering.
We zijn een team, en we werken gezamenlijk een product.
Natuurlijk voeren de testers de testen uit, om de kwaliteit van de opgeleverde producten te testen en te toetsen. Dit doen we in overleg met de anderen. Als we bemerken dat de kwaliteit niet voldoet aan de standaarden die we samen hebben vastgesteld, dan wordt het desbetreffende product aangepast.
Testers zijn degenen die zich primair bezighouden met kwaliteit. Maar dat houdt niet in dat de anderen zich aan de verantwoordelijk van kwaliteit kunnen onttrekken.
Anders gezegd: het hele team test de kwaliteit erin.
Tja, het nadeel van een reactie via Twitter is dat die maar 140 karakters mag zijn. Tuurlijk verandert alleen testen de kwaliteit van een systeem niet, het gaat dan om testen en het verwerken van de bevindingen door de programmeurs. Maar dat is een semantische discussie, dus niet interessant.
Wat ik aan wil geven is dat je best door middel van testen-aanpassen best de kwaliteit van een systeem kan verhogen en op het gewenste peil kan brengen. Sterker nog: je kan er zelfs de kwaliteitscriteria waaronder de requirements mee bepalen. Talloze organisaties doen dat, dus het kan zeker. Het is alleen ontzettend duur en kost veel tijd. Dus efficient is het niet.
Waar ik me echt over op kan winden zijn testers c.q. testbureaus die hun vak heel beperkt benaderen. Als we willen zorgen dat het project kwaliteit (conform de eisen van de klant) levert moeten we niet alleen eindproducten testen. We moeten dan ook de vroegtijdige kwaliteitsmaatregelen naar ons toetrekken.
En als ik het goed lees zijn Andreas en ik het dan toch weer met elkaar eens.
Zoals Juran ooit heeft gezegd: “Quality is designed in, not inspected in.” en daarmee ben ik volledig akkoord. Testing is per slot van rekening quality control en geen quality assurance. Als er met andere woorden rommel wordt opgeleverd, wordt er rommel getest. Testing levert natuurlijk een positieve bijdrage aan de kwaliteitskenmerken van een product, maar voor een volledige kwaliteitsinjectie is het dan simpelweg te laat (cf. de kostengrafiek van Boehm). Op dit tijdstip kan je dan beter spreken over damage control.
Interessante aanpak door gebruik te maken van Twitter. Ben het met Jan Jaap eens dat je daardoor mogelijk wel beperkt kan worden door de 140 tekens…
Mijn primaire reactie, via twitter, was:
Mag ik een emmer? RT @AndreasPrins: Vraagje: klopt dit statement? De #kwaliteit? Die #testen we er wel even in!
Daarna las ik deze tweet van Jan Jaap:
@AndreasPrins De stelling: “kwaliteit testen we er wel in” klopt wel, het is alleen wel ontzettend duur en tijdsintensief.
Mijn reactie:
@jjcannegieter @AndreasPrins nee, nooit waar…. Kwaliteit test je er niet in, die /bouw/ je erin!
Vervolgens reageerde Andreas op tweets van mij en Jeroen Rosink:
@huibschoots, @jeroenro dank heldere reacties, deel de mening dat je t r niet in test, je bent wel gezamelijk verantwoordlk hoe doe je dat?
Mijn reactie:
@AndreasPrins @jeroenro Door samen te werken! Testers helpen developers de kwaliteit te verbeteren. Te lang voor een tweet. Wil je een blog?
Dan de “nog eens” reactie waar Andreas om vroeg. Nog steeds: nee, nee en nog eens nee! Je kunt nog zoveel testen, daarmee zal /de tester/ de kwaliteit niet verhogen. dat doet de developer. Een sematische discussie misschien, maar wel interessant! Want het gaat om de uitspraak die fundamenteel onjuist is. En daarmee voor een bepaalde perceptie zorgt. De perceptie van de organisatie is vaak dat testers de kwaliteit er nog wel in testen. De regressie test zal de belangrijkste fouten er wel uithalen.
Testers verantwoordelijk maken voor de kwaliteit is fundamenteel verkeerd. Zelfs als onderdeel van een team, zijn testers nog steeds niet verantwoordelijk voor de kwaliteit. Het team is! Testers zijn er om anderen te helpen, met hun service dat we testen noemen. Dat is een intelligente activiteit die producten onderzoekt. Het helpt het team (of onze client) om weloverwogen beslissingen te nemen over software te maken door kritisch te denken (zie ook: RST door James Bach en Michael Bolton).
Maar ik heb het gevoel dat ik de reactie van Jan Jaap verkeerd begrijp. Daarom twee vragen:
1) “testers die hun vak heel beperkt benaderen”, wat bedoel je precies? Kan je een voorbeeld geven?
2) “vroegtijdige kwaliteitsmaatregelen naar ons toetrekken”, over welke maatregelen hebben we het dan?
@Bjorn, dank, ik deel die mening inderdaad, door positief vroeg betrokken te zijn kun je voor goede kwaliteitsborging zorgen zodat deze niet terugloopt gedurende de verschillende fasen. De vraag blijft kun je het er achteraf nog in testen?
@Martine, in de eerste alinea stel je dat het gaat om de kwaliteit van requirements, bouwen en projectmanagement. Voor testen stel je dat het gaat om kwaliteit in het proces van testen. Is dit bewust? Waarom alleen het proces en niet het eigenlijke testen zoals bij bouw en req? Of lees ik dan iets wat er niet staat?
Leuk om te zien hoe je het eigenlijk weer omdraaid en de bal bij de rest neerlegd. Testen kan er inderdaad in z’n eentje niet voor zorgen is een team effort…
@Jan Jaap, Het laatste zijn we het inderdaad overeens, testers die zich alleen richten op testen zijn denk ik effectief in hun deel van de keten maar sub optimaal voor de rest van de voortbrengingsketen.
Kun je wel eens uitleggen hoe alinea 2 in z’n werk gaat? Ik ken het zelf niet zo of snap niet precies at je bedoelt..
@Gert, ben het met je eens, de vraag is dus wat verstaan we onder testen, en als we laat beginnen is het vaak slechts damage control, vroegtijdig beginnen met quality assurance zou het doel moeten zijn.
@Willem, vandaar de mogelijkheid voor geven van comments ;)
@Huib, dat is inderdaad een blog apart :) interessante gedachte:
“Testers verantwoordelijk maken voor de kwaliteit is fundamenteel verkeerd. Zelfs als onderdeel van een team, zijn testers nog steeds niet verantwoordelijk voor de kwaliteit.”
Dat de testdiscipline de enige is verantwoordelijk voor kwaliteit deel ik met je, maar ik ben van mening dat ze als onderdeel van het team een hele grote rol spelen. Net zo groot als ontwikkelaars. Een verzorger in ziekenhuis is toch medeverantwoordelijk voor welzijn client? Niet alleen de arts? Dan heeft het grote werk al plaatsgevonden. Een keuringsafdeling bij Unilever is toch oko verantwoordelijk? Niet alleen de mensen achter de machines? Of zijn wij een uitzonderlijke branche met daarin een bijzondere positie?
Je vragen aan @Jan Jaap heb ik ook, ben benieuwd naar de antwoorden.
@Huib en @Andreas: volgens mij hebben jullie twee vragen:
1) “testers die hun vak heel beperkt benaderen”, wat bedoel je precies? Kan je een voorbeeld geven?
2) “vroegtijdige kwaliteitsmaatregelen naar ons toetrekken”, over welke maatregelen hebben we het dan?
Bij 1) bedoel ik testers die zich beperken tot het testen van het eindproduct en een lijst bevindingen zien als ultieme output. Wat dat betreft doen de Engelsen het beter: waar wij een onderscheid maken tussen testen en toetsen maken de Engelsen dat niet: alles is testing en testers moeten ook naar de kwaliteit van tussenproducten kijken. Het doel van testen is niet het opstellen van een teststrategie, opstellen van testcases, uitvoeren van de test en rapporteren van bevindingen. Het doel van testen is bijdragen aan de projectdoelen met de focus op kwaliteit. Wat ik eerder opsomde (teststrategie, cases, uitvoering, bevindingen) zijn enkele van de middelen. En veel testers beperken zich tot deze middelen. En testers kunnen zoveel meer bijdragen!
Dat brengt me bij vraag 2). Reviews, inspecties, walkthroughs, procesaudits, gateway reviews, requirementsvalidaties.
Testers aller bedrijven: verbreed je blik!
Het is afhankelijk met welke blik je naar de stelling kijkt of je in het “kamp” van Huib terecht komt, of in het “kamp” van Jan Jaap.
Wat ik bedoel te zeggen is dit:
Als je puur naar een oplevering kijkt die getest moet worden, kan een tester inderdaad geen kwaliteit toevoegen aan de oplevering. De tester stelt slechts de kwaliteit van de oplevering vast. In dat opzicht ben ik het met Huib eens, en kan je kwaliteit niet ergens “in” testen.
Als je echter naar grotere tijdsspanne kijkt, van meerdere opleveringen achter elkaar, kunnen bevindingen uit de testen van een éérdere oplevering de ontwikkelaars wel behouden deze of soortgelijke fouten voor latere opleveringen te maken. Over de tijd gezien heeft de tester dan wel degelijk invloed op de opgeleverde kwaliteit. Alleen gebeurt dit door de lessen die getrokken worden van eerdere testen.
Voorwaarde om kwaliteit toe te voegen is wel dat tester als een vakman te werk gaat (niet oplevering na oplevering hetzelfde lijstje afvinken, maar met verstand van testen en het product zinnige testen uitvoeren) en dat de tester langere tijd meerdere opleveringen van hetzelfde product moet testen. Al met al blijft het wel een aanpak van de lange adem. Kwaliteit kan zo toegevoegd worden, maar zeker niet “even”.
In de hele discussie wordt over kwaliteit gesproken als iets dat in meer of mindere mate in producten zit. Dit is misleidend omdat kwaliteit voor een belangrijk deel subjectief is. De enige objectieve maat voor productkwaliteit ligt, paradoxaal genoeg, in de kwaliteit van het voortbrengingsproces. Hierop hebben we als testers indirect invloed. Onze rol is louter ondersteunend. Of het uiteindelijke product goed is, is een vraag die alleen beantwoordt kan worden door de gebruikers, op het moment dat ze het product daadwerkelijk gebruiken.
Kwaliteit bereik je alleen als alle betrokken partijen (zoals gebruikers, opdrachtgever, projectleider, analisten, bouwers en testers) zich inzetten om een kwalitatief goed product op te leveren. Testers tonen de kwaliteit aan en geven daarmee anderen de kans om op die punten waar de kwaliteit onvoldoende is, de kwaliteit te verhogen. Daarmee leveren ze een bijdrage aan een hogere kwaliteit.
@Jan Jaap: Jij schrijft “Het doel van testen is bijdragen aan de projectdoelen met de focus op kwaliteit.” Helemaal mee eens. Maar dat is niet alleen in Engeland zo. Dat is ook hier valide.
@all: In mijn beleving trekt deze discussie het testen juist weer terug waar we hem niet willen. Het gaat uit van testen als een test uitvoerende en bug zoekende activiteit. Terwijl zoals jan jaap terecht opmerkt, testen veel breder is. Het gaat niet om wie de code intypt, het gaat om de opbouwende krachten die zorgen dat de business uiteindelijk tevreden is.
Zeggen dat testen niet verantwoordelijk is voor kwalitieit, betekend dat je als tester niet je verantwoordelijkheid neemt, en deze dus afschuift.
Wie is er dan wel verantwoordelijk?
De programmeur, die typt de bug letterlijk in het systeem, of nee…
de analist want die had geen onduidelijkheid in de spec moeten laten staan, of toch…
de gebruiker. Hij had eerst maar echt eens goed moeten nadenken over wat hij wilde, en het was verstandig geweest als hij in zijn carrière wat meet IT kennis had opgedaan. Dan snapte hij tenminste waar het over ging. Of is het…
de projectmanager, die heeft moedwillig de druk op het project gezet waardoor er geen tijd was om de zaken goed te doen.
Nee eigenlijk ligt het bij de business, doordat zij niet willen luisteren naar de problemen die IT aankaart, draait alles in de soep.
Misschien toch de tester, als deze zich maar had opgesteld als een team player die vanuit zijn rol, het maximale doet om de kwaliteit te verhogen. Door vroegtijdig checks en maatregelen te nemen en zijn bevindingen na te jagen opdat er daadwerkelijk iets mee gedaan wordt en de kwaliteit verbeterd wordt. Niet aan het einde als voldongen feit, maar along te way, gedurende het project, zodat er nog effectief wat mee gedaan kan worden.
Testen draagt bij aan betere kwaliteit, en “test het er dus in”. Maar wel geld dat de tester randvoorwaarden heeft om zijn werk te kunnen doen. Als deze niet zijn ingevuld, heb je een probleem, maar voor de andere betrokkenen geldt hetzelfde. De discussie gaat mijns inziens niet om ‘testen we kwaliteit in het systeem’ maar over hoe krijgen we onze randvoorwaarden ingevuld. Terugtrekken in onze schuld, en roepen dat we NIET verantwoordelijk zijn, maar slechts tester, gaat daar niet bij helpen.
@Martijn: Huib en ik zitten in hetzelfde kamp! Net zoals andreas, Derk-Jan, Bert, Bjorn, Martine en wie ik nog meer vergeten ben. Ik denk alleen dat ik (en met mij vele anderen) testen net wat breder benader dan sommige anderen. Mijn punt is dat we in Nederland onnodig en verschil maken tussen testen en toetsen. Als je gewoon net doet of toetsen (reviewen, inspecties) ook tot je verantwoordelijkheid hoort neemt je toegevoegde waarde enorm toe, net zoals de waardering voor je werk.
Ik blijf bij mijn stelling: testers aller organisaties: verbreed je blik/werkzaamheden/verandelijkheden
@Derk-Jan. Jij stelt dat we testen terug stoppen in het uitvoerende hokje, maar dat zie ik niet in de reacties terug komen?
Testen draagt bij aan de kwaliteit, van de processen en de producten. Of we dat nou toetsen of testen noemen, maakt mij niet zoveel uit. Reviews horen toch bij het testerstakenpakket? Je inspannen voor een gestroomlijnd proces als je ziet dat het beter kan hoort toch ook bij je takenpakket? Juist testers ‘zien’ wat er verbeterd kan worden, op alle fronten.
Volgens mij zijn we het daar allemaal wel over eens.
De stelling was “de kwaliteit, die testen we er wel even in”.
Ook na een paar dagen denk ik, vind ik, “nee”.
Vergelijk het met een voetbalteam. Het hele team wil winnen. De tester staat op goal. Als laatste man om een tegendoelpunt tegen te houden.
Om tot een tegendoelpunt te komen, moet de tegenstander eerst langs de spitsen, dan langs het middenveld, dan langs de verdediging, en als laatste de doelman/vrouw.
Is een tegendoelpunt de schuld van de doelman alleen? Nee. Is de doelman als enige verantwoordelijk om te winnen? Nee.
Natuurlijk loopt deze vergelijking op een aantal punten mank, maar het geeft wel aan dat de tester, net als de doelman, de gatekeeper is, en afhankelijk is van de rest van het team. Net zoals de rest van het team afhankelijk is van de doelman. Nog straffer: het hele team is afhankelijk van een elkaar.
De winst van een voetbalteam hangt af van de kwaliteit van het (samen)spel van het team. Dat is net zo met software maken. En net zoals in een voetbalteam zijn we daar allemaal bij betrokken.
“De kwaliteit? O, die testen we er wel even in!” dat kan misschien als we Test Driven Development gebruiken. Hierbij moeten we wel realizeren dat software ontwikkelen een competentie is die uit meerdere disciplines bestaat, laten we eens stoppen met het differentieren van bouwers en testers, testen (en bouwen) is iets wat iedereen moet leren.
@all
In TMap NEXT staat in de strategiematrix gewoon een kolom voor toetsen (blz 108). En als tester kan je goed op consistentie toetsen en voor de rest moet je de uitvoering aan experts over laten (gebruikers voor gebruikersvriendelijkheid en functionaliteit, beveiligingskenners voor beveiliging enz.). In een klassiek project ligt die verantwoordelijkheid voor het bemensen bij het projectmanagement. In een agile project bij de producteigenaar.
Ik mis in de discussie nog quality gates.
Wie is er eigenlijk verantwoordelijk voor de kwaliteit? Om die vraag te kunnen beantwoorden, stel ik mezelf twee vragen: wat is kwaliteit? En wat is verantwoordelijk? Kwaliteit is een lastig begrip.
In trainingen stel ik vaak de vraag: “is de koffie lekker?” waarop je de meest uiteenlopende antwoorden krijgt. Sommigen antwoorden: “voor automaten koffie is het goed te doen!”. Als iemand zegt: “niet te drinken!” is mijn reactie: “waarom neem je dan toch koffie?”. Een leuke discussie om het begrip kwaliteit in te luiden. Kwaliteit is waarde, voor iemand die “er toe doet”, op een bepaald tijdstip. Dus de koffie, ook al is deze niet echt lekker, kan toch waarde hebben: bijvoorbeeld om wakker te worden/blijven! Waardoor de koffie dus kwaliteit in zich heeft. En als de drinker dat goed genoeg vind, dan is de koffie wat dat betreft kwalitatief goed (genoeg).
Dan verantwoordelijkheid. Wie is er verantwoordelijk voor de software? Wie weleens met een RACI matrix gewerkt heeft, weet dat er verschillende “soorten” verantwoordelijkheid zijn. Responsible (eindverantwoordelijk) en Accountable (verantwoordelijk). In deze context kijk ik naar het vraagstuk: wie is er verantwoordelijk voor de kwaliteit? De projectmanager (of projectboard) voor de productie ervan. En de rest van het team dan?
Andreas zegt: “Een verzorger in ziekenhuis is toch medeverantwoordelijk voor welzijn client? Niet alleen de arts? Dan heeft het grote werk al plaatsgevonden. Een keuringsafdeling bij Unilever is toch ook verantwoordelijk? Niet alleen de mensen achter de machines?”. Het voorbeeld van de arts en de verzorger, is een mooi voorbeeld. Natuurlijk heeft de verpleegkundige verantwoordelijkheden in het geheel. Namelijk de verzorging van de patiënt op aanwijzing van de arts die op zijn beurt weer een diagnose en behandelplan stelt. Ieder zijn taak en samen verantwoordelijk. Maar beide zijn niet eindverantwoordelijk voor de gezondheid van de patiënt! Wel voor het zo goed mogelijk uitvoeren van hun vak. Als een patiënt besluit tijdens de behandeling het ziekenhuis te verlaten dan is dat zijn keuze! Vergelijkbaar met: als de klant besluit de software in productie te nemen. Dankzij of ondanks de resultaten van het testen.
Ik ben het helemaal eens met Jan Jaap die zegt: “veel testers beperken zich….” en “testers aller bedrijven: verbreed je blik!”. Want het is inderdaad zeker niet alleen een plan maken, cases schrijven, uitvoeren, rapporteren. Het kan en het moet veel meer zijn. Alleen het doel van testen zou ik toch anders willen formuleren. Niet “bijdragen aan de projectdoelen met de focus op kwaliteit”. Ik ga liever voor de definitie van Cem Kaner: “Het testen van software is een technisch, empirisch onderzoek van een product, uitgevoerd in opdracht van belanghebbenden, met de bedoeling de kwaliteit-gerelateerde informatie van het soort dat zij zoeken te verstrekken” of de kortere definitie van Jerry Weinberg: “testen is het verzamelen van informatie met de bedoeling een beslissing te informeren”. Het doel is dus informatie verstrekken! En daarmee draagt de tester inderdaad bij aan het projectdoel.
Bij vroegtijdige kwaliteitsmaatregelen denk ik ook aan reviews, inspecties, etc. Maar ook hier is zoveel meer te bereiken dan alleen maar documentatie bezig te zijn. Ik denk aan: pair programming, helpen unit testen (te verbeteren), testbaarheid van applicaties verbeteren door bijv. om logging goede te vragen, acceptatie criteria opstellen door ze (nog voor dat er volledig uitgeschreven requirements en specificaties zijn) in acceptatie testen te gieten. En er is zo veel meer te verzinnen.
@verantwoordelijkheid
Johan Vink heeft enige tijd gelden voor TestNet (archief is even zoek) een presentatie gegeven over een projectmanager die ’speelde’ met het budget voor de gebruikersreview onder leiding van de testconsultant. Inderdaad: bij weinig reviewtijd veel productieproblemen, bij voldoende reviewtijd weinig productieproblemen.
Conclusie: de projectmamanger/leider is verantwoordelijk. Eigenlij samen met diens opdrachtgever. Maar dat werkt niet zo in Nederland.
Ooit een contract gezien met kwaliteit als oplevercriterium?
@Huib: Kwaliteit is een lastig begrip voor jou, op dit moment. Ik ga een heel eind met je mee in het koffieverhaal, maar je conclusie klopt niet. Koffie heeft geen kwaliteit in zich. Wat voor de één goed (genoeg) is, is voor de ander niet goed (genoeg). Kwaliteit manifesteert zich pas in de interactie tussen product en gebruiker.
@kwaliteit
ISO heeft een definitie gegevens met daarin expliciete en impliciete (niet beschreven) eisen als norm. Voor IT is dat geconcretiseerd met de kwaliteitsattributen.
Werkt allemaal als een speer als de projectmanager dat begrijpt.
@Ben: dat is precies wat ik probeerde te zeggen! Misschien moet ik daar iets scherper zijn in de woorden die ik gebruik.
Ik had moeten zeggen: “En als de drinker dat goed genoeg vind, dan is de koffie wat dat betreft voor hem kwalitatief goed (genoeg).”
@Rob: project managers begrijpen die vaak idd niet, maar dat is volgens mij het probleem niet. Het probleem is dat kwaliteit voor iedereen anders is en dus lastig is vast te leggen. ISO normen maken het wat mij betreft alleen maar ingewikkelder.
Ieder handelen, dus ook testen, gaat gepaard met verantwoordelijkheid. Verantwoordelijkheid kan van binnenuit komen (verantwoordelijkheid nemen) of van buitenaf worden opgelegd (verantwoordelijk gesteld worden). Die twee leiden altijd tot spanning :-). Als tester wil je natuurlijk je verantwoordelijkheid nemen (interne sturing), door de kwaliteit ‘erin’ te testen. Maar als tester wil je uiteindelijk niet alleen verantwoordelijk gesteld worden (externe sturing). Je mag van andere professies verwachten (maar zorg ervoor dat je er niet op gaat rekenen) dat ook zij kwaliteit erin ‘bouwen’, ‘projectleideren’, ’stand-uppen’ of ‘analyseren’. Als de interne sturing niet aangevuld hoeft te worden met externe sturing heb je een gouden team te pakken. Niks aan doen dan. Maar lukt dat niet, zorg dan dat je niet alleen het haasje wordt als de externe sturing een ‘bokje’ zoekt ;-). Niet door een duikende beweging, maar door midden in het project te blijven staan en oog te hebben voor alle belangen.
Overigens is de discussie erg leuk, maar mogen we er niet op rekenen dat we tot een conclusie komen. Wel tot een gevarieerde verzameling van inzichten. En da’s genoeg hoor :-)
@allen,
Dank voor jullie reacties en inbreng, volgens mij een goede discussie. Ik heb het elke dag met plezier zitten lezen. Ik ben het geheel met Rik eens als het gaat om zn laatste drie zinnen… dat we maar veel discussies mogen hebben om te leren.
als het op QC en QA aankomt is de gemiddelde overbetaalde ict-er nog slechts een neanderthaler….