Testmanager: software van banken erg slecht

testbeeld

Gepubliceerd: Woensdag 10 maart 2010

De kredietcrisis heeft korte metten gemaakt met het betrouwbare imago van banken en verzekeraars. Terecht, meent een testmanager, die te vaak slechte software in productie ziet gaan.

Toon volledig artikel

Megumi op Woensdag 10 Maart 2010 14:59

image

Dit is overal zo. Er wordt zelden voelende budget en middelen vrijgemaakt voor testen. Of een test omgeving.

mspartner op Woensdag 10 Maart 2010 16:17

image

Toch heb ik het gevoel dat als er één branche is waar ze tenminste nog iets doen aan testen, dat de financiele sector is. In vrijwel alle andere branches is het helemaal onverkoopbaar: daar begrijpt men gewoon niet waarom ze naast programmeurs (die men al te duur vind) ook nog testers nodig zouden hebben.

Het probleem zit vooral in de organisatie. Testen moet beginnen zodra de eerste regel code is geschreven: direct vanaf de start van het project. En het moet binnen het project plaatsvinden, en niet daarbuiten, in een aparte QA of testafdeling. Als het testen niet binnen je project haalt en pas aan het einde van het project gaat testen krijg je het sneue effect dat dit artikel erg treffend beschrijft.

Een ander probleem is dat testen vaak op laag niveau wordt uitgevoerd: veel handmatig testen in plaats van geautomatiseerd. Dat wordt al snel te kostbaar en het levert weinig op.

Jesse van Bekkum op Woensdag 10 Maart 2010 16:25

image

Het moet zelfs al ver voor de eerste regel code geschreven is: testprocedures horen een onderdeel van het ontwerp te zijn.

Stoffer op Woensdag 10 Maart 2010 20:09

image

Helaas, als er één type organisatie is die penny wise pound foolish werkt is het wel een bank of verzekeraar. Dat is de laatste 10 jaar heel erg geworden. Inkopers die willen scoren bepalen dat voor minimum tarieven mensen worden ingehuurd (if you pay peanuts ..) terwijl er intern bakken met geld wordt weggegooid door niet vooraf goed na te denken over functionaliteit of gebruik van de juiste techniek.

Vroeger werd er heel goed nagedachjt over architectuur en enorm veel getest bij banken met zelfs nagebouwde kantoren en teststraten die 24 uur user input naspeelden (dat was 20 jaar terug!). Testers liepen vanaf de eerste specs al mee. Het kan dus wel, alleen heb je dan wel goede mensen nodig en die zijn allemaal weggejaagd of worden 'uit kostenoverweging' niet ingehuurd. Hoe dom kun je zijn als grootbank.

Lennart op Woensdag 10 Maart 2010 15:14

image zomerhack badge 3

Herkenbaar verhaal. Het gebeurt te vaak dat iets als testen het kind van de rekening is, omdat de managers en cententellertjes dat zien als iets dat alleen maar duur is, tijd kost, en in hun ogen niks oplevert. Maar als er dan door het in productie zetten van slecht geteste code achteraf problemen ontstaan (die voorkomen zouden zijn door beter testen) dan zijn diezelfde managers ook niet de beroerdste om de verantwoordelijkheid doodleuk af te schuiven op de developers.

MajinZ op Woensdag 10 Maart 2010 15:41

image

Was jij die eikel?!? Maak jezelf bekend, lafaard!

Maar even voor de goede orde: goed verhaal :-) Inderdaad herkenbaar. Dat het geld kost staat als een paal boven water. Maar wat kost het als het op den duur mis gaat, en je een grove fout had kunnen voorkomen door afdoende te testen?

M Wegman op Woensdag 10 Maart 2010 15:49

image

Dat is nou juist de essentie van het verhaal, uiteindelijk is het een kosten baten verhaal, waar meer naar de kosten gekeken wordt, dan naar de baten.

Testen betekend niet alleen meer kosten maar ook een veel langere ontwikkelingstijd.

Dat is helaas maar vaak genoeg de realiteit.

Anonymous Coward op Woensdag 10 Maart 2010 16:01

image

Blij vliegtuigen en hart-longmachines nemen we die moeite wel, maar voor software is het te duur. Prima, maar dat heeft consequenties voor de betrouwbaarheid. Managers die die afweging niet eens maken, zijn een verspilling van kostbare zuurstof.

steltenpower op Woensdag 10 Maart 2010 15:49

image

Zelfs als klant van toen nog mijnPostbank.nl (wat helaas als basis heeft gediend voor mijnING.nl) heb ik meerdere malen fouten gerapporteerd. Als reply kreeg ik natuurlijk een 'ga rustig slapen, wij weten het beter' verhaal van een Drs. digibeet van de 'klantenservice'.

En het internetbankieren voor particulieren is slechts een heel klein deel van alle software bij een bank.

lodi op Woensdag 10 Maart 2010 16:07

image

Dus de kans is groot dat de fundamentele beveilingsfout bij ING ook nog eens niet goed getest is.

olafmol op Woensdag 10 Maart 2010 15:56

image

Daarom is voor mission-critical IT-systemen Test Driven Development (TDD) (http://en.wikipedia.org/wiki/Test-driven_development) ook eigenlijk de enige optie.

webwab op Woensdag 10 Maart 2010 16:54

image

Ja de banken hebben ook wel gelijk, ik test ook altijd in productie. Tenslotte komen dan de meeste bugs naar boven.

Duinwandelaar op Woensdag 10 Maart 2010 18:44

image zomerhack badge 1

Testen doe je voor je in productie gaat.
Als je test in productie geef je daarmee ook het 'gelijk' toe van de managers die de time-to-market belangrijker vinden dan enige kwaliteit van de software.

MajinZ op Woensdag 10 Maart 2010 19:07

image

Er zitten een aantal fundamentele verschillen tussen testen en "go-live en we zien wel wat er van terecht komt". In de live-omgeving zul je ongetwijfeld veel bugs tegenkomen, daar kun je ook vrij weinig aan doen. Je kunt echter wel voor de go-live fase zoveel mogelijk testen, zodat je in ieder geval geen absoluut baggerproduct de productie ingooit.

Wat test jij eigenlijk precies in productie? Een bedrijfsintranet met absoluut geen koppeling naar de buitenwereld kan ik me nog enigszins voorstellen, maar dat is wel van een "iets" andere orde dan een bank! De gevolgen die kunnen (en uiteindelijk zullen) optreden als daar iets mis mee is kunnen immers behoorlijk desastreus uitpakken.

henkbos op Woensdag 10 Maart 2010 17:15

image

Hum ..., het is een algemeen probleem in de IT-wereld. Men begint met wat business ideeën en dan wil men snel resultaat zien. Het begint al bij het vertalen van die business ideeën naar fatsoenlijke requirements. Requirements moeten van die orde zijn dat de business 'begrijpt' wat ze vragen, de testers weten wat ze moeten gaan testen en de bouwers weten wat ze moeten testen.
Gisteren was op het DREAM10 event daar uitvoering aandacht voor. Vooral de key-note speaker, Prof. G.J Nijssen had daar een uitstekend betoog over.
Zonder goed geformuleerde requirements weten de bouwers onvoldoende wat er gemaakt moet worden en dus zie je dat het testen oneigenlijk wordt gebruikt om 'achteraf' alsnog de requirements scherp te krijgen.

@Nixpro, wat je aanhaalt is de embedded industrie. In deze industrietak word al veel langer gedisciplineerd gewerkt. De kern is dat hardware nu eenmaal beperkingen heeft en je heel strak moet definiëren wat wel en niet mogelijk is. Daarnaast is in de embedded wereld de focus op kosten vele malen groter dan in de andere IT-takken (vreemd genoeg).

Wellicht dat deze economische crises daar nu in gaat helpen.

zwart-wit op Woensdag 10 Maart 2010 22:28

image

“Een paar jaar terug heb ik bij zo'n lul een ruitje van zijn auto ingetikt. Die verdiende het echt. Hij zou 's middags op vakantie gaan. Had hij ook een keer tijdsdruk”, zegt Overdonk lachend.

Ten eerste had Webwereld geen naam hoeven te verbloemen. Op basis van zijn 'verweer' kan de betreffende organisatie nu wel bedenken wie hij is. Ook het feit dat hij (of wellicht een zij) onder behandeling van een psycholoog heeft gestaan zal alleen al een narrow down tov de mogelijke 'klokkenluider'/'vernieler' zijn.

Als je je 'test'-organisatie niet op normale wijze kan overtuigen van problemen met de programmatuur, dan ben je niet geschikt voor die 'test'-organisatie.

Misschien toch maar een baantje zoeken als veegmachinetester bij de gemeentereiniging? Kan hij/zij in ieder geval niet veel problemen veroorzaken.

Atheistus op Woensdag 10 Maart 2010 23:54

image

De testafdeling wordt voornamelijk bevolkt door weggepromoveerde medewerkers. Het is meestal niet een afdeling waar mensen voor in de rij staan.
Dat is een belangrijke reden dat iedereen om deze afdeling heen probeert te werken.

Baf op Donderdag 11 Maart 2010 07:59

image

Het lijkt af en toe ook wel of testen, ook bij sommige softwarehuizen, simpelweg niet meer gedaan wordt. Wij ontwikkelen niet zelf, maar kopen uiteraard wel software in of laten software ontwikkelen. Als je ziet wat voor bagger je af en toe binnenhaalt dan vraag ik me echt af of er uberhaubt nog wel getest wordt.

Bijvoorbeeld, we hadden een applicatie laten ontwikkelen voor een agendafunctie op een Intranet omgeving. Bij het aanmaken van een afspraak (lijkt me basisfunctionaliteit) meteen een foutmelding. Afspraak kon dus niet ingepland worden. Je kan mij dan niet vertellen dat er bij het softwarehuis getest is...

Lief op Donderdag 11 Maart 2010 11:18

image

Persoonlijk vind ik, als testprofessional werkzaam in de financiële wereld, dat de houding van de geïnterviewde testmanager beneden alle peil is.

Die slachtofferrol die wordt aangenomen door velen in dit vak maakt dat mensen inderdaad niet luisteren naar je; daar heb je immers weer zo'n zeikerd.

In de reacties hier zie ik vervolgens een zelfde serie dooddoeners en cliches:
* automatisch testen is beter dan handmatig testen--> nou niet perse, dat is compleet afhankelijk van de situatie en als we het hebben over kosten-baten komt automatisch testen er vaak niet rooskleurig uit
* bij testafdelingen werken voornamelijk wegbezuinigde mensen; nee dat is alleen als het werk niet serieus wordt genomen, ik ben niet de enige professional die voor dit vak kiest
* testen is het controleren van code; nee, ik kan geen letter code lezen ( bij wijze van spreken dan)

Ik heb lol in mijn werk, maar ik vind ook wel dat je er de persoonlijkheid bij moet hebben. Deze testmanager zou wat ballen mogen kweken; wanneer met mijn resultaten niets wordt gedaan ga ik niet zitten janken in een hoekje, maar meld ik aan betreffende projectleider dat als hij er toch niets mee doet, ik mijn team wel elders voor inzet; kan hij het geld aan iets anders besteden ( bijvoorbeeld een programmeur voor het puinruimen na inproductiename).

Je kunt geen foutloze software afleveren, testen gaat over verwachtingsmanagement enerzijds en gerichte, gestructureerde controle op de belangrijke delen anderzijds.

TM bij een bank op Donderdag 11 Maart 2010 13:58

image

Wat ik in de reacties mis is het risico gedreven testen. En, ja helaas, het falen van de gemiddelde bank applicatie leidt niet tot het verlies van mensenlevens (in tegenstelling tot medische apperatuur en embeddeds oftware in de automotive hoek).

Daarbij dwingen wij consumenten zelf wel een snelle time-to-markt af met ons switch gedrag. Daarmee zijn wij zelf mede de oorzaak dat de business een afweging maakt tussen de business belangen en de kwaliteit van de software.

Zoals al gezegd, foutloze software bestaat niet. Is hij daarentegen fit for purpose is de juiste vraag. Wij herinneren ons allemaal de studentenhouding die we zelf hebben gehad "een 6 is (meer dan) goed genoeg". Dit geldt ook voor software. En we moeten dus (met zijn allen) accpeteren dat er volop fouten in de software zitten. Ook de software die ik test gaat met fouten in productie, maar als ik zie wat er aan drama's wel ontdekt en opgelost is dan zijn het "maar" de lichtere fouten die met de software op de productiemachine's terecht komen.

Kun je daar niet tegen dan moet je niet gaan janken maar een ander vak kiezen. Ook een mogelijkheid is de weg van de diplomatie, overtuigingskracht en argumenten. Alleen met kwaliteit van je eigen test organisatie en process verbetering wordt je langzaam maar zeker serieus genomen en beland je aan de tafel van de management teams.

Succes met je carriere en zet je passie, die je zeker hebt, nu maar eens om naar positiviteit.

Anonymous Coward op Donderdag 11 Maart 2010 17:44

image

“Een paar jaar terug heb ik bij zo'n lul een ruitje van zijn auto ingetikt. Die verdiende het echt. Hij zou 's middags op vakantie gaan. Had hij ook een keer tijdsdruk”, zegt Overdonk lachend.

Tja... als dat de testmethodieken zijn ;)

Om te kunnen reageren, dient u ingelogd te zijn.

Nieuwsbrief

Ontvang dagelijks een overzicht van het laatste ICT-Nieuws in uw mailbox

Peiling

Loading Poll

Video: World Tech Update: Darpa's robot oorl...

World Tech Update: Darpa's robot oorlogspaard (video)

Verleden nieuws