11 maart 2008 -
IT-projecten mislukken vaak omdat ze te duur zijn of te lang duren. Maar ook vaak omdat er niet genoeg getest is voor de lancering. Dit schrijft 6Minutes.be.
Testen is het eerste wapen tegen gebrekkige software en procedures, maar kan het beste zelf ook aan een aantal strikte procedures onderworpen worden. CTG, specialist in het opzetten en uitrollen van softwaretesten, zette daarvoor zeven vuistregels op een rij.
1. Maak voldoende budget vrij
Een testbudget betaalt zichzelf eenvoudig terug: denk aan tien procent besparing op het totale projectbudget en tot 80 procent besparing op onderhoud.
2. Investeer in testtools
Er zijn diverse, goed automatische testtools beschikbaar.
3. Zorg voor een goed testhandboek
Beschrijf hierin niveaus, types, procedures, templates, organisatie en woordenboek. Zet een kort en duidelijk handboek vervolgens op intranet.
4. Test voordat de code geschreven wordt Procedures beschrijven en testen kan al zodra de projectspecificaties bekend zijn. Scheelt tijd!
5. Organiseer strategische testen
Zoek dus fouten en inconsistenties in documentatie van requirements en design.
6. Baseer de testen op mogelijke risico's
U kunt niet alles testen, test dus wat het meest risicovol is.
7. Geef werknemers de mogelijkheid van testen hun beroep te maken
Speel in op de interesse van bepaalde mensen en geef hen de kans zich te ontwikkelen tot een bekwame tester.
Bron:6minutes
Ik denk niet dat testen het hoofdprobleem van ICT oplost. Het grote probleem is de attitude van de doorsnee ICTer. Neem daarbij het simpele feit dat veel opdrachtgevers van ICT een kwaliteit accepteren die van een paperclip nog niet accepteren.
Wat de ICT moet doen is een gaan kijken bij, bijvoorbeeld, de automotive, hoe daar de excellence systemen werken. Deze systemen zijn met name gericht op attitude van werknemers en daar is dus voor de ICT veel winst te halen. Zeker als je weet dat een auto vaak veel ingewikkelder is dan de software die de ICT-jongens in elkaar smijten.
Testen lost het hoofdprobleem van de ICT inderdaad niet op. Het is nog wel veel te vaak een ondergeschoven kindje. Als laatste fase in een ICT project is er vaak te weinig tijd over, omdat eerdere fasen zijn uitgelopen. Bovendien heeft testen maar al te vaak een negatief image (vervelend werk). Tenslotte zijn opdrachtgevers zich nog te weinig bewust dat ze met behulp van testresultaten hun ICT project beter op kwaliteit kunnen sturen. Kortom er is inderdaad veel efficiëncy-winst te halen!
Met de meeste tips kan ik het als ervaren (11 jaar) testmanager wel eens zijn. Een aantal is niet zonder meer toepasbaar en kan zelfs negatief uitpakken.
Al met al is het goed dat er steeds meer aandacht is voor testen vanuit het perspectief van de opdrachtgever. Een goed boek over dit onderwerp is SmarTEST (auteur: Egbert Bouman; ISBN 9789012125970).
Arvel
|
|
9
-
07
-
2008
|
16
:
00
uur
Ik kan me prima vinden in de punten uit het artikel. Het is behoorlijk kort door de bocht om te stellen dat auto's vaak ingewikkelder in elkaar steken dan softwaresystemen.
Uiteraard zijn er tientallen voorbeelden waar dat wel zo is, maar evenzo makkelijk vind je honderden systemen die bijzonder complex zijn.
Testen is één van de dingen die kunnen helpen bij het verbeteren van de kwaliteit.
Het beter managen van het zich constant wijzigend verwachtingspatroon bij de gebruikersorganisatie is een andere verbetermogelijkheid.
En inderdaad, voor standaard projecten kun je leren uit de toyota way. Voor specialistische projecten met veel bijzondere functies, zou ik dat maar liever snel vergeten.
Ik stel niet dat software makkelijker in elkaar zit dan auto's. Als auto's op dezelfde wijze zouden worden gebouwd als software dan waren ze zo zwaar dat Wouter Bos helemaal gelukkig zou zijn van de opbrengsten van de wegenbelasting
De Toyota way is maar één van de systemen binnen de automotive. Echter, mocht de ICT haar arrogantie even opzij zetten en eens kijken in andere sectoren, dan zal de kwaliteit van de ICT snel stijgen.
Het grote probleem van de ICT is namelijk dat men niet in staat is om via de KISS methode te werken.
Als je overigens zou weten hoe vaak er binnen de automotive wordt getest, dan zou je ook wel anders praten denk ik.
A Velstra
|
|
10
-
07
-
2008
|
07
:
35
uur
@Ad
U hebt waarschijnlijk meer verstand van ontwikkel-, productie- en testprocessen in de automotive sector en ik van ICT.
ICTers realiseren zich als geen ander dat ze een relatief nieuwe sector zijn en proberen daarom inderdaad veel te leren van anderen.
ICTers proberen het hun klanten naar de zin te maken ook als die elke dag een ander idee heeft over wat ie nou eigenlijk wil, laat staan over wat ie nodig heeft.
Als voorbeeld:
De overheid moet als gevolg van europese regels, haar projecten aanbesteden. Omdat iedereen dan wel over hetzelfde moet praten, want anders zijn de aanbieders niet op prijs te vergelijken, worden de functionele eisen bevroren. Als de software dan wordt gebouwd, blijkt dat de reden inmiddels is gewijzigd en mislukt het project. Achteraf wijzigen van de eisen leidt tot juridisch gesteggel met afgewezen aanbieders. Zie het rapport vd rekenkamer.
Marcel
|
|
10
-
07
-
2008
|
23
:
27
uur
Tip 8:
Druk het in productienemen van software niet ten koste van alles door. Tijdslijnen worden steeds kritischer. Het dan even doordrukken door ICT-leverancier of door opdrachtgever (business) pakt vaak niet goed uit.
Tip 9:
Zorg dat de gebruikersorganisatie haar verantwoordelijkheid neemt bij de gebruikersacceptatietesten. Deze testen worden vaak als te tijdrovend of overbodig gezien, terwijl het goed nalopen van goed toegesneden testscripts (nadat systeemtesten al zijn uitgevoerd) in het oogspringde problemen juist voor kan zijn. Dus een kwestie van de juiste prioriteiten stellen.
Overigens is testen vaak een sluitpost in de planning. Vaak gaat er al teveel tijd op aan de bouw en wordt de testperiode ingedikt om de deadline alsnog te kunnen halen.
@Ad
Altijd weer grappig om te zien hoe jij tegen ICT-ers aankijkt. Ik vraag me wel eens af welke teleurstellingen jij hebt gehad op het ICT vlak waardoor je altijd zo rancuneus reageert tegen ICT en ICT-ers.
Overigens is de automotive een volledig gecontroleerde omgeving en niet vergelijkbaar met de uitdagingen die ICT dagelijks heeft. Terwijl ICT in opdracht van de business bezig is een ''vliegdekschip'' te bouwen dat alleen moet kunnen varen, wordt op ongeveer 80% van de realisatie als donderslag bij heldere hemel door de business ineens geroepen dat het ook in een woestijn moet kunnen voortbewegen. Extra tijd is er niet en liefst ook niet duurder. Bovendien moet het vaar/voertuig vanuit de bouw direct kunnen aansluiten op het ISS ruimtestation. En, oja, de ISS heeft geen testomgeving maar moet alles wel in een keer werken anders is het momentum om de markt op tijd te penetreren voorbij. Of ik overdrijf? Nee, niet eens. Sterk uiteenlopende software omgevingen moeten werken alsof je even 3 word documentjes samenvoegt tot 1 document.
Gewoon jaren ervaring. Ik heb een leuke boterham verdiend aan het opruimen van de puinhopen die ICT implementaties hebben achtergelaten. Kortom, geen echte teleurstellingen.
Wat me het meeste tegen de borst stuit is het introverte gedrag van de ICT. Ook nu weer, je zegt dat de automotive een beheerste omgeving is, nou, ik kan daar wel andere dingen over vertellen. Zeker in de ontwerpfase.
Ik ken de ICT wereld inmiddels ook aardig en die is zeker te vergelijken met iedere sector, alleen wenst de ICT in haar arrogantie ''bijzonder'' te blijven. Steeds wordt de klant de schuld gegeven, terwijl in 90% van de gevallen de ICTer gewoon niet luistert naar de klant, maar de klant met oplossingen bestookt die de klant helemaal niet wil.
De klant vroeg wel degelijk een vliegdekschip dat in de woestijn uit de voeten kan en aan het ISS kan dokken, maar na het woord vliegdekschip hoort de ICTer de rest van de wensen niet meer.
De ISS is overigens uitvoerig getest. Wel maakt men in de ruimtevaart gebruik van Chips uit de jaren '80, omdat die meestal redelijk bugfree zijn.
Maar ja, iedere keer weer zie ik dat de ICT zichzelf een bijzondere plaats toedicht en arrogant omgaat met klanten. Er wordt een oplossing geboden zonder naar het probleem te luisteren en vervolgens krijgt de klant weer de schuld.
Als de ICT zich aan de klant zou aanpassen, dan gaat het imago van de sector echt wel omhoog. En mocht het imago niet omhoog gaan, dan de kwaliteit wel.
Het voorbeeld van velstra zegt wat dat betreft meer dan genoeg.
J Willems
|
|
11
-
07
-
2008
|
09
:
22
uur
If can draw it you can build it. Software systemen zijn modellen van de realiteit. Het standpunt om éérst (de gemodelleerde processen) met de gebruikersgroep te testen vóórdat je code schrijft is essentiëel.
Dus flowsheets i.p.v. lappen tekst.
mijn 5€.
A Velstra
|
|
11
-
07
-
2008
|
10
:
48
uur
We kennen de frustratie van Ad de Beer inmiddels wel, dus laten we maar niet meer op hem reageren.
Het onderwerp: Testen, is wezenlijk. Alle suggesties, zoals die uit het artikeltje en de aanvullingen van Willem, Teun en Marcel zijn waardevol.
Ik voeg daar graag aan toe, dat het ook verstandig is om eerst de basisfunctionaliteit van de toepassing te testen en dan in een 2e tesfase pas naar uitzonderingen te kijken. Dat scheelt veel ontwikkeltijd en energie.
A Velstra
|
|
11
-
07
-
2008
|
11
:
15
uur
@Ad
Als u naar het door mij gebruikte voorbeeld verwijst, dan is het prettig als u ook begrijpt wat ik heb bedoeld.
In het voorbeeld (en in de rapporten van de Rekenkamer) wordt immers aangegeven dat de starre functie-eisen worden veroorzaakt door de regels voor Europese aanbesteding.
Die vereisen dat iedere aanbieder een prijs etc afgeeft op basis van dezelfde informatie.
Die vereisen dat je daar achteraf niets meer aan mag veranderen, want dat ondergraaft de eerlijkheid van die aanbesteding (of leidt tot juridische gevechten met aanbieders die de opdracht niet hebben gekregen).
Die gaan volledig voorbij aan het feit dat de wereld (mede op basis van politieke besluitvorming) voortdurend verandert en dat daarmee juist een softwareproject zelden of nooit tevoren is vast te pinnen op strakke functie-eisen.
Die zijn dus gemaakt voor simpele overheidsaankopen, zoals de auto's waar u kennelijk verstand van heeft.
Hoe u dit voorbeeld nou weer kunt verdraaien naar arrogant gedrag van ICTers is me echt een raadsel.
Marcel
|
|
11
-
07
-
2008
|
21
:
36
uur
@Ad
Uiteraard overdreef ik met de automative om je uit de tent te lokken. Jij serveert de complete ICT en ICT-ers af vanwege arrogantie etc en scheert alles over één kam.
Overigens, er gaat buiten de ICT ook het nodige fout op het gebied van niet-ict projecten (haagse tramtunnel, betuwelijn, hsl-lijn, noord-zuid metro, etc), die ''strategisch noodzakelijke'' fusies (waar het bedrijf niet beter wordt, maar de bonus van de top wel), die fantastische financiele producten (o.a. beleggingsverzekeringen) en talloze commerciele initiatieven die het soms maken maar vaak ook niet. Daarover lees ik nooit zoveel kritiek over van van jou, maar dat terzijde.
Als het dan een mind-set of attidude is die bij ICT-ers ontbreekt hoe kan jij dan als HRM-er ''ons'' daarbij (wel) helpen? Je vakbroeders die ik bij een aantal multinationals ben tegen gekomen hielpen alles en iedereen met vacatures en opleidingen, behalve de ICT-afdelingen. Want dat konden / wilden ze er niet bij hebben. Hopelijk word jij onze rots in de branding en is er nog hoop!
