Vroeger kon je een stuk software nog helemaal in quarantaine testen. Tegenwoordig is veel software afhankelijk van andere componenten in een keten. Denk aan een nieuwe e-mail client of webtoepassing, die je alleen goed kan testen over een netwerk en met een directory van gebruikersgegevens.
De projectleider die zo'n component door de acceptatietest moet krijgen heeft meestal een forse uitdaging aan de infrastructuurkant. Hij kan de hele productieketen nabouwen en daar zijn acceptatietest op doen, maar dat kan behoorlijk in de papieren lopen. Het alternatief is om de test op de productieketen te doen, maar dat wil nog wel eens op ‘njet' stuiten bij de beheerders daarvan. Als deze discussie niet op tijd gevoerd wordt krijgt men vertraging en/of kostenoverschrijdingen. En of de projectleider nu het een of het ander kiest, het is nooit goed.
De keten loopt altijd risico's, ongeacht de keuze die de projectleider en de eigenaar van de productieketen maken. Een risico is dat testen in een afzonderlijke acceptatieomgeving onvoldoende representatief is. Omdat die altijd afwijkt van de productieomgeving is het maar de vraag of alle fouten er in de test uitkomen. Het is ook een risico om je applicatie te testen op de productieomgeving. Zo is het denkbaar dat die overmatig wordt belast en productietoepassingen worden gestoord.
Hoe komen we hier uit? Testen dient om risico's te verminderen, maar je kunt ze nooit helemaal uitsluiten. Bij ketentesten mag je zelf kiezen welk risico het zwaarste weegt. Maar die afweging wordt zelden bewust gemaakt.
Ik denk zelf dat testen van componenten in productie uiteindelijk onvermijdelijk is. Daar horen wel maatregelen bij als een toegangstest, actuele bewaking, en een ‘noodremprocedure', als die maatregelen maar in balans zijn met de risico's die worden gelopen. Die maatregelen zijn altijd nodig, ook voor componenten die allang in productie zijn. Het ontbreken van die maatregelen kan dus geen excuus zijn voor de eigenaar van de productieketen.
Peter van Eijk is onafhankelijk adviseur (http://www.digitalinfrastructures.nl/).
Dat is toch niets nieuws? ik zit al vanaf 1996 in de IT en in 1997 heb ik dit soort tests al uitgevoerd..
Doen wij bij Sogeti al jaren!
en niet alleen bij Sogeti!!
Bij Sogeti doen ze het al jaren verkeerd. 🙂
Testen bij Sogeti?? 😉 tegen de tijd dat je nog moet uitleggen wat er getest moet worden……
Helaas wordt de plank wel erg misgeslagen aan het einde van het artikel.
Juist omdat veel mensen denken dat productie testen het beste is, ontstaan er veel problemen.
Mensen die dit denken moeten rekening houden dat dit de bron is van veel ellende in de informatie stroom.
Niet bepaald een adviseur met kijk op de zaak, laat staan vernieuwende inzichten. Artikeltje vol met open deuren en een raar slot. Er komt heel wat kijken bij ketentesten, dat is waar, maar het lijkt me zinvol als je daarbij iemand betrekt met echt verstand van zaken.
Ketenbewaking? is een verzameling van activiteiten om complexe ICT systemen onder controle te houden, met als uitgangspunt het bewaken van de kernactiviteiten die een eindgebruiker op de applicatie uitvoert. Ondank de complexiteit van dit onderwerp is het YMOR gelukt om bij verschillende klanten Ketenbewaking? tijdens ontwikkel, test, acceptatie en productie fasen vanuit eindgebruikerperspectief succesvol in te zetten. Bezoek onze website voor een paar praktijk voorbeelden.