Ok

By continuing your visit to this site, you accept the use of cookies. These ensure the smooth running of our services. Learn more.

23/02/2008

Back Home

Na 2 weken in de States is mijn vrouwtje terug thuis.

/me is happy ;-)

15:13 Gepost in Varia, Werk | Permalink | Commentaren (0)

19/02/2008

Bug life cycles

Vandaag moet ik een collega van een andere unit introduceren in de wondere wereld van software testen.
Een van de topics gaat over de bug life cycle. Wat is het, wat doet het en waarom?

Uiteindelijk is de premisse heel simpel: welke weg volgt een bug van wanneer hij opgemerkt (geregistreerd) wordt, tot wanneer hij opgelost is.

Is dat wel correct? Stopt de levensduur van een bug wanneer hij opgelost is? Wat gebeurt er dan bij regressie-problemen, waarbij een oude bug opnieuw actief wordt? Met andere woorden: bezit een bug het eeuwige leven? Is het een perpetuum mobile?

Los van het eindpunt, bestaan er tal van variaties doorheen de levensloop. In kleine organisaties kunnen er slechts enkele statuswissels nodig zijn (new -> resolved -> verified), maar bij grotere projecten kan het aantal statussen algauw oplopen tot een tiental (new, open, postponed, assigned, resolved, verified, duplicate, no bug, ...).

Afhankelijk van de striktheid van de organisatie kunnen deze statuswissels dan nog eens eenwegs of tweewegs zijn: sommige teamleaders laten toe dat er een weg terug is van bijv. een status 'no bug', m.a.w.: dat de tester moet instemmen met de mening van de ontwikkelaar.
Ook al zijn zulke structuren iets complexer, en leveren ze vaak wat extra werk op, toch blijkt dat dergelijke vorm van concensus een duidelijke verbetering van de motivatie tot stand brengt: de tester voelt zich meer betrokken bij het project.

Wanneer we dat allemaal in ogenschouw nemen, wordt het heel moeilijk om een algemene definitie te geven van een bug lfe cycle, mar we zullen ons best doen. :-)

09:47 Gepost in Werk | Permalink | Commentaren (0) | Tags: testing, bug, bug life cycle

15/02/2008

Dikke-truiendag

Dat ons klimaat grondige wijzigingen aan het ondergaan is, daar kijkt niemand nog van op.

Wel: je kan er iets aan doen: vandaag is het immers dikke-truiendag!

81980175b9cbca286d48ffc39e26a0e3.jpg

 

Help het milieu een handje, trek een trui aan (of twee indien nodig) en draai de thermostaat van de verwarming één of meer graden naar beneden.

Bedankt!

10/02/2008

Abfahren

Mijn vrijgezellenbestaan voor 2 weken is begonnen: Godelieve is net opgestegen voor een opdracht in de States en Canada.

Gezien de drukte die er momenteel heerst, zullen die 2 weken naar alle waarschijnlijkheid voorbij vliegen...

05/02/2008

Vrijgezel

De komende weken breng ik door als vrijgezel: Godelieve voert een opdracht uit in de USA en Canada.

Zondag 10 februari vliegt ze eerst naar Schiphol (vertrek 13u30), om van daar door te vliegen naar Detroit (vetrek 15u40 - aankomst 18u40).

Daar zal ze een week lang in en rond Detroit werken, om dan met de auto verder te rijden naar Canada.

Op vrijdag 22 februari keert ze terug vanuit Detroit (vertrek 14u00), maakt een tussenlanding in Amsterdam (vertrek zondag 23 februari om 7u00) en landt tenslotte in Zaventem om 7u55.

Luchtvaartmaatschappij is deze keer KLM, maar voor de intercontinentale vluchten rekenen ze op Northwest Airlines.

04/02/2008

Enquêtes

Enquêtes, ik weet pertinent zeker dat ze hun nut hebben, maar soms werken ze toch echt op je systeem.

Daarnet vond ik weer zo'n maitlje in mijn elektronisch postbakje: blablabla... verbetering organisatie ... blablabla... uw mening is belangrijk ... blablabla...

Nu, mijn mening is inderdaad belangrijk. Net als die van mijn +/- 420 collega's.
Het grootste probleem van zo'n equêtes is dat je alleen de gemiddelden eruit haalt. Mensen die super tevreden zijn, vullen die niet in, vermits ze ervan uitgaan dat iedereen denkt zoals zij, en dat alles bij het oude mag blijven. Mensen die op het punt staan het bedrijf te verlaten, antwoorden eveneens niet, omdat ze hun feedback ondertussen ireelevant vinden, of 'omdat er toch niet neer mij geluisterd wordt'.

Die commentaar komt dan nog meestal van mensen die nooit antwoorden op enquêtes, amper feedback geven tijdens evaluatiesessies en de tijd niet willen vrijmaken om een mailtje te sturen met hun ideeën naar een collega, een CD'er of (desnoods) het hoofd van HR.
Als je je mening niet kenbaar maakt, kan het bedrijf er niet op reageren.

Dus: enquêtes zijn nuttig.
Maar: enquêtes zijn ook lastig :-)

De enquête van vanmorgen was weer zo'n typevoorbeeld: maar liefst 175 vragen. Moesten het nu nog representatieve vragen geweest zijn, dan was er niet zo'n probleme geweest, maar het was een standaard enquête van Vlerick, waarbij alleen de naam van het bedrijf was aangepast. Aangezien CTG ietswat uit de band springt qua interne organisatie, kwam het grootste deel van de vragen hoogst artificieel naar voren, alsof ze niet op onze organisatie geënt waren.

Dat was dan nog niet het ergste: het bleek of leek ook nog eens zo'n enquête te zijn waarbij men elke vraag 5 keer stelt, op verschillende momenten en elke keer met een andere klemtoon of woordkeuze. Wat is het doel ervan? Kijken of je tussen de lijnen kan lezen? Zeker weten of jouw antwoorden correct zijn (de OXO-spelers ervan tussen halen)? Of worden ze betaald per vraag en was de inspiratie op?

Ik heb me dus door de vragenlijst geworsteld en in eer en geweten geantwoord op de vragen, hoe dubbelzinnig of articieel dan ook. Een klein steentje als bijdrage, maar wie weet bouwen we zo ook een grote pyramide...

11:27 Gepost in Varia, Werk | Permalink | Commentaren (0) | Tags: CTG, enquête, Vlerick

30/01/2008

Waar stopt verificatie

Gisteravond woonde ik een voordacht bij van het KVIV, in het Ingenieurshuis in Antwerpen.
Een sessie door Willy Druyts, over end-to-end testing.

Zeker een boeiend onderwerp, en zoals elk goed onderwerp zette het me aan het denken.

Uiteindelijk moet je beseffen dat, hoe goed je testproces ook is, je nog steeds met een geaccidenteerd model werkt, waarvan je verschillende elementen (zo niet de meeste) niet onder controle hebt of kan hebben.

Wie in de jeugdbeweging heeft gezeten kent waarschijnlijk wel het doorzeg-spelletje: je maakt een kring. Persoon A zegt een zin of paragraaf tegen persoon B, die het vervolgens doorzegt aan persoon C, enz.
Per extra stap verdwijnt een deel van de context en acuraatheid, zelfs exponentieel.

Binnen software-ontwikkeling merken we hetzelfde.

  1. De klant heeft een behoefte, of onze verkoopsafdeling merkt een behoefte bij de klant.
  2. We trachten die behoefte te vertalen naar functionele specificaties.
  3. We gieten deze specificaties in use cases
  4. De use cases worden omgezet naar technische specificaties
  5. We coderen de technische specificaties
  6. We testen op verschillende niveau's: unit (component), unit-integratie, systeem, systeem-intergratie, ... Het hele V-model dus.
  7. Er volgt (in een ideale situatie) ook nog een acceptatietest.

Wat we hier zin zijn 7 niveau's van abstractie, waarbij telkens informatie wordt geabstraheerd en de context vertroebeld.
Wat heeft het eindproduct dan nog gemeen met de oorspronkelijke vraag of behoefte? De praktijk leert het ons: bitter weinig!

Dit is dan nog een ideaal voorbeeld. Vaak zijn het de functionele testers of functionele analisten die instaan voor de acceptatietesten, zonder enig besef van de wens van de klant, afgaand op het gevoel.

Een derde probleem: zelfs na de acceptatietest, wanneer het stukje software gefinaliseerd is, zijn er nog tal van processen die inspelen op de kwaliteitsbeleving van de klant: de handleiding, de manier van transport, de installatie, ...

We testen inderdaad goed, maar wie neemt er eens de handleiding bij, en test de handleiding? Niemand, omdat de handleiding pas wordt geschreven na het testen (en vaak na validatie/acceptatie)

23/01/2008

Environment(al) Testing

Na mijn presentatie op het Software Testing Seminar kwam een man naar me toe met een intrigerende vraag: "Wat verstaar u onder Environment Testing?"
Om de vraag te kaderen: ik had het tijdens mijn presentatie o.a. over de mogelijke inzetbaarheid van automatische tests op verschillende domeinen, zoals performantie, regressie, ... en dus ook environmental.

Blijkbaar betekende voor die man, aan de slag als test manager bij de NATO, environment testing het testen van een computer of een andere elektronisch toestel in verschillende natuurkundige omstandigheden. Zo'n beetje zoals Wikipedia het beschrijft.

Wel, voor mij persoonlijk is die definitie te eng. Als tester moet je sowieso open staan voor een bredere kijk op de dingen, dus zo verbazend kan dat niet zijn.

Voor mij environment testing het testen van om het even wat, op zaken die er verband mee houden, maar niet onlosmakelijk mee verbonden zijn.
Oké: moeilijk zin: ik geef het toe.
Sta me toe dat even te verduidelijken aan de hand van wat voorbeelden.

  • Eerder zoals de enge definitie: je ontwerpt bijv. een computer, en gaat testen tot welke minimum -en maximumtemperatuur hij blijft werken, of onder welke vochtigheidsgraad.
  • De bredere definitie: je ontwerpt software voor een specifiek type computer, besturingssysteem, browser, ... en gaat proberen (misschien door middel van geautomatiseerde tests) of de software ook onder die omstandigheden blijft werken.

Als je het zo beschouwt, kan je iedere stap hoger op de linkerzijde van het V-Model beschouwen als het toevoegen van een niveau van environmental testing.
Zo kan bijvoorbeeld het wijzigen van een onafhankelijke variabele een effect hebben bij unit-tests.

Ik weet zeker dat je nog tal van voorbeelden en situaties kan bedenken waarvoor je de term environmental testing kan gebruiken. Immers, testen is altijd een beetje out-of-the-box, environmental dus, denken!

17/01/2008

Mission accomplished

Een dagje stressen, maar het is goed geweest. meer dan 45 klanten, en een hele hoop van onze test professionals waren vandag samen in congrescentrum Ter Elst (Edegem), om elkaar wat te leren over software testing.

In het eerste deel van deze sessies (eind december) gaf ik al een presentatie, maar voor deze sessie had ik, de raadgevingen en evaluatie van de vorige sessie indachtig, mijn presentatie grondig aangepast.

En dat wierp zijn vruchten af! OK, de zenuwen waren er nog, al was het iets minder. Maar blijkbaar zouden deze nooit echt verdwijnen.

De presentatie zelf was stukken beter dan de vorige keer: minder onderwerpen betekende duidelijk dieper ingaan op de resterende onderwerpen. Dat, in combinatie met een betere voorbereiding en iets minder zenuwen, zorgde ervoor dat de boodschap duidelijker overkwam, indien ik tenminste mag afgaan op de reacties van klanten en collega's.

De finale analyse komt er binnen enkele dagen, wanneer de evaluatieformulieren verwerkt zijn.

Hoe dan ook: dit smaakte naar meer, vermits je presenteren enkel onder de knie krijgt door het te doen. Een beetje zoals testen dus: in het begin wat gecrispeerd, je angstvallig vastklampend aan het testscript. Maar naarmate je aan ervaring wint durf je al eens out-of-the box beginnen denken en met meer overtuiging je ideeën presenteren.

16/01/2008

Software Testing Seminar

Morgen staat het tweede deel van het Software Testing Seminar van CTG op het programma. Het eerste deel (eind december) werd al bezocht door tal van CTG'ers en klanten, en nu is het tijd voor de overige CTG'ers, maar nog een pak meer klanten.

De agenda blijft dezelfde, dus kan je mij ook op het podium terugvinden.
De presentatie is echter wel wat aangepast, als een gevolg van de evaluatieformulieren. Inderdaad, CTG luistert effectief naar zowel klanten als medewerkers en tracht daarop in te spelen.

De titel van de presentatie is daarom verandert naar 10 Lessons Learned in Software Testing (ipv 15). Op die manier kan er dieper ingegaan worden op de topics. Verder is de presentatie wat afgeslankt: minder tekst op de slides, zodat er meer ruimte is voor voorbeelden en off-slide commentaar.

Hopdelijk wordt de presentatie goed gesmaakt. Ik kijk er alleszins naar uit!