Hond en het bot

/images/hond.jpg

Een arme hond kwam op een dag langs een slagerij. Hij merkte op dat op de toonbank een heerlijk bot lag. Hij keek rond, zag niemand in de buurt, en nam toen vliegensvlug het bot in zijn muil en rende ermee weg.

Een poosje later, liep de hond over een bruggetje. Halfweg het bruggetje kijk hij naar beneden en zag toen de rivier die onder hem liep. Hij zag zijn eigen spiegelbeeld in het water beneden zich. Omdat hij dacht dat dat spiegelbeeld een andere hond was, die een nog lekkerdere bot in zijn bek had, besloot hij dat hij toch liever dat bot van die andere hond had.

Hij begon te grommen en te happen naar de hond daar beneden. Hij deed zijn kaken van elkaar om zijn scherpe tanden te laten zien en zo zijn tegenstander bang te maken. Helaas, het bot dat in zijn eigen bek stak, viel naar beneden en plonste in het water. Het bot zonk tot op de bodem van de rivier, ver buiten zijn bereik en het bot was voor altijd weg.

Ethiek

Onlangs gaf Nathalie Rooseboom de Vries van Delft een presentatie op het najaarsevenement van testnet over ethiek bij het testen van software. Ze had het over of we alle data wel mogen verzamelen. Volgens de (Nederlandse) wet mag het alvast niet. Maar wat dan met alle bedrijven die je geboortedatum of andere zaken proberen op te slaan? Op zich niet zo er, maar wat als iemand die gaat misbruiken, of als die gegevens gestolen worden? Zijn wij als testers mee verantwoordelijk voor deze gegevens? Moeten we niet aan de alarmbel trekken als we dat ontdekken of laten we het oogluikend toch toe?

Dit doet me denken aan het schandaal dat nog steeds in de media zit, namelijk van Volkswagen.

/images/autos.jpg

Maar hierover wil ik het niet hebben. Wel over een ander feit. Er rijden in Amerika al geruime tijd zelfrijdende auto's. De zogenaamde google car's. Tot nu toe hebben ze nog geen ongeluk veroorzaakt. Wow, prachtig, wat een software. Knap van al die software die in die zelfrijdende wagens zit. Ik bewonder al degene die daaraan hebben meegewerkt.

Maar stel nu even dat we volgend jaar starten met zelfrijdende auto's te produceren. Iets later rijden ze op onze wegen. Zouden er dan minder ongevallen gebeuren? Misschien wel, daar zal waarschijnlijk de software in de auto's wel voor gemaakt worden. Maar stel nu even dat je zelf in zo een auto zit en ineens loopt er een groep mensen over de straat. Wat moet deze auto dan doen?

De eerste reactie zal zijn: Remmen. Terecht, want we willen zo weinig mogelijk slachtoffers. Maar wat als het al te laat is om zonder kleerscheuren te remmen? Dan zal de wagen moeten uitwijken. Stel je voor dat hij dan tegen een muur aanrijdt. Waarom? Omdat in de software staat dat er zo weinig mogelijk slachtoffers mogen zijn. En tegen de muur langs de straat rijden is de manier om die groep mensen te ontwijken. Zo is er ook maar 1 slachtoffer, namelijk de persoon die de auto bestuurt.

Stel nu dat er een kind voor die muur staat. Wat dan? Is de doorsnee mens bereidt om een wagen te kopen die dat obstakels ontwijkt ten nadele van dat de bestuurder kan doden? Wat als die groep mensen een groep bejaarden was, wat moet de auto dan doen? Allemaal vragen die je als software tester moet hebben als je de software van zulke wagens test.

Zulke software testen is moeilijk, dit omdat hier een ethisch kantje aan hangt. Wat de wagen ook zal doen, er zullen altijd slachtoffers zijn. En dan moet men misschien wel gaan kiezen tussen commerce en moraal. Een zeer interessant debat, dat zeker de komende jaren nog gevoerd zal worden.

Royco

Je kent het wel, de zakjes met Royco soep in. Tegenwoordig staat op vele zakjes een raadseltje om je even mee bezig te houden. Vandaag zag ik een zakje met de volgende opdracht:

De tas, stoom en de tomaat vormen een logische volgorde. Teken een weg door het
rooster naar de ster door deze logica te volgen.
/images/royco.jpg

Ik vond het zeer simpel, te simpel voor woorden zelfs. Toen ging ik even naar de oplossing kijken, en die was veel moeilijker, raar dat ze niet aan mijn oplossing hadden gedacht. Zo zie je in de figuur dat rood de oplossing is van Royco, maar groen is mijn oplossing.

De vraag is nu, heeft de opdracht een bug in zich? Had men niet een voorwaarde moeten stellen dat men niet schuin mag gaan? Want dat heb ik dus wel gedaan. Aangezien er geen restrictie was, mag ik dat doen, en vind ik dat mijn oplossing ook wel juist is.

Dit is zo ook in het dagelijkse leven van een tester, moeten we niet kijken of onze user stories geen gaten bevatten? Moeten we niet gaan kijken of we zaken anders kunnen interpreteren? Zijn de requirements niet dubieus opgesteld? Zien we alternatieven die veel simpelder zijn dan de vooropgestelde oplossing? Zaken om over na te denken dus.

Evolution of testing

Testen bij de BBC, zelfs daar schrijft men dus software. Aangezien ze software hebben, moet er ook getest worden. Of althans, zou moeten. Gelukkig voor hun, doen ze dat ook bij de BBC. Woensdag 14 oktober, was dus Paul Rutter, een testmanager bij de BBC te gast als preker bij het najaarsevent van Testnet.

Zijn presentatie zat vol leuke weetjes. Wisten jullie voorbeeld dat er 315 miljoen request per maand zijn om een programma van de BBC nog eens terug te horen of te bekijken? Wisten jullie dat bij de BBC er een software team is dat enkel en alleen test-tools maakt voor de testafdeling?

Super, niet?

Er kwamen 5 principes van software testen aan bod:

  1. Radiate a clear visibility of state

    Zorg ervoor dat men overal kan zien hoever het project staat. Bij de BBC doen ze dat door vele TV schermen te plaatsen in de gangen en daarop de status van de projecten te tonen. De TV schermen worden aangestuurd door een raspberry pi.

  2. Smooth the flow of work

    Focus op het afwerken van taken, zorg ervoor dat blokkerende taken eerst worden afgewerkt, nog voor dat er aan een nieuwe story begonnen wordt.

  3. Deliver at a regular and predictable cadence

    Zorg voor kortere tijden om iets af te werken, en zorg er dan ook voor dat je altijd zo stabiel mogelijk bent. Aangezien er steeds korte tijden tussen verschillende releases zijn, is er ook minder dat er tussen 2 releases bijkomt of wijzigt, en dus minder kans dat er iets fundamenteels fout is.

  4. Implement feedback loops

    Zorg voor korte feedback loops door ondermeer een build server of door onderzoeken te doen bij je klanten. Zorg er ook voor dat commentaren van de klanten zo snel mogelijk worden aangekaart en opgelost.

  5. Improve collaboratively with experiments

    Experimenteer met nieuwe tools, nieuwe technieken, kortom alles wat er uit een retrospective kan komen om te verbeteren, probeer het, want het loont.

Deze zaken zijn dus volgens hem de sleutel tot succes.