O’Reilly zal dit jaar een nieuw Agile-boek uitbrengen, getiteld The art of Agile development. Het zal een zeer praktijkgericht boek worden dat met name gericht is op Agile-ontwikkelteams. Auteurs van het boek zijn James Shore en Shane Warden.

Wat opmerkelijk is aan de totstandkoming van het boek, en daarom begin ik er ook over, is de open reviewaanpak die beide auteurs hanteren. Het grootste gedeelte van de inhoud staat namelijk al online met als bedoeling om geïnteresseerden en vakgenoten uit te nodigen tot het indienen van reviewcommentaar. Hiervoor is een aparte Yahoo tech group opgericht waar je je reviewopmerkingen kunt deponeren. Gezien het aantal berichten in deze groep, lijkt genoemde aanpak haar vruchten af te werpen.

Ook gastschrijfster en exploratory testingspecialiste Elisabeth Hendrickson heeft haar bijdrage aan het boek online ter review aangeboden. Uiteraard betreft dit een hoofdstuk over de aanpak van exploratory testing binnen Agile-projecten. Een leerzaam verhaal met aan het einde een mooie literatuurlijst waarin het nodige materiaal over exploratory testen is te vinden.

Technorati Tags: Agile, exploratory testing, exploratory testen, James Shore, Shane Warden, Elisabeth Hendrickson, O’Reilly

Een oud-collega wees me op het feit dat afgelopen vrijdag in de Mediaplaza een boekpresentatie plaatsvond van het boek Agile testen - Testen als teamsport: het antwoord op innovatie in ontwikkelprocessen. Het boek is geschreven door testconsultant Anko Tijman die werkzaam is bij Ordina.

Het betreft een eerste Nederlandse publicatie over gestructureerd testen in Agile-projecten. Deze projecten wijken af van traditionele ontwikkeltrajecten in die zin dat er sprake is van een geïntegreerde ontwikkelaanpak met onder andere als kenmerken een zeer actieve businessparticipatie en dynamische requirements. Dit heeft natuurlijk directe gevolgen voor de testaanpak binnen een Agile-project.

Het boek moet onder meer antwoord gaan geven op de volgende vragen:

• Waarom voldoet het traditionele testproces niet in een Agile-project?
• Wat zijn de kenmerken van een Agile-testproces?
• Wat moet er aan het testen veranderen om effectief en efficiënt te blijven in een Agile-traject?
• Wat betekenen deze veranderingen op het niveau van de medewerker, de IT-organisatie én de business?

Ik heb het boek nog niet gezien en kan er ook nog niet naar linken, de geëigende verkoopkanalen vermelden het nog niet in hun aanbod. In ieder geval lijkt het een interessante aanwinst voor de testliteratuur. Op één van de vorige TestNet-bijeenkomsten heeft Anko al eens een presentatie over Agile gehouden. Deze presentatie is hier te downloaden.

Technorati Tags: Agile, Anko Tijman, Agile testen, Agile-project

Trouwe lezers van deze weblog hebben inmiddels wel gemerkt dat ik zo af en toe met een testgerelateerde posting kom. Een bewuste keuze waarmee ik me terdege besef dat het blogtechnisch gezien geen handige is. Want ondanks de goede argumenten die voortkomen uit de je-bent-baas-over-je-eigen-weblog-discussie, is een aantal zeer uiteenlopende onderwerpen binnen een blog vaak verwarrend voor een lezer.

Desalniettemin vind ik het zo nu en dan leuk om over mijn vakgebied te schrijven. Maar ik merk tegelijkertijd dat er nauwelijks wordt gereageerd op dit soort  berichten. Dat kan ik voor een deel mezelf aanrekenen (te weinig diepgang, te weinig uitdagend en testen niet als duidelijke blogscope), maar het kan ook zijn dat de materie zich (nog) niet leent voor een weblog. Als ik namelijk naar mijn statistieken kijk, zie ik wel degelijk regelmatig bezoekers via een zoekmachine binnenkomen op trefwoorden als TMap, PAT of testtools. Met andere woorden, jullie zijn er wel maar hebben blijkbaar geen behoefte aan discussie (verkeerde conclusie?). Ook mijn oproep in december om hier te komen gastbloggen over testen leverde slechts een enkele reactie op.

Dus bij deze de vraag aan testers, testmanagers en andere vakgenoten, in hoeverre is er behoefte aan een Nederlandstalige testblog? Waar zijn jullie naar op zoek als je hier via Google op testgerelateerde zoekwoorden binnenkomt, wat verwacht je aan onderwerpen en diepgang? Daarnaast ook de vraag of testen zich meer leent voor een forum of dat het wel in blogform kan, daar dan dedicated, dus niet naast tal van andere onderwerpen. Zul je zien dat het opnieuw stil blijft, maar dan heb ik mijn best gedaan. De lezer is aan het woord, maar moet dan ook wel in de pen klimmen. En ten slotte, kritiek mag hoor, graag zelfs!

Technorati Tags: testen, testblog

Naast de grote hoeveelheid online leesvoer op testgebied is er ook aardig wat aanbod van videos over testen te vinden. Gelukkig zijn er ook sites waar links naar deze videos worden verzameld. Zo heeft Rosie Sherry een aardige lijst opgebouwd met de logische naam Software Testing Videos.

Volledig is deze lijst absoluut niet. Zo stond Beyond Test Driven Development: Behavior Driven Development, een video uit de serie Google techtalks er bijvoorbeeld al niet tussen. Maar desalniettemin biedt bovengenoemde verzameling uren aan testgerelateerd videomateriaal. Waar je de tijd vandaan moet halen om het allemaal te bekijken, ik weet het niet, maar over die 7 * 24 uur is al genoeg geklaagd.

Technorati Tags: Software testing, testing, software testing videos

Alsof er nog niet voldoende leesvoer op het gebied van testen klaarligt, wat een prachtige bron vind ik zojuist via NNSeek: meer dan 200 artikelen over software QA and testing. Een eerste snelle blik laat zien dat het om vrij uitgebreide en recente berichten gaat. Een heel kleine en willekeurige greep:

A metric leading to agility
Exploratory testing and the planning myth
Lessons learned in software quality assurance
Test-driven development isn’t testing
What is exploratory testing?

Testers, wat een wereldbron. Ik ben hier zelf wel een tijdje zoet mee, het is altijd maar even afwachten of een dergelijke source online blijft staan maar dat lijkt er eigenlijk wel op. Ken je meer van dit soort bronnen, ik hoor ze natuurlijk graag!

Technorati Tags: testing, testen, software quality

Via een aantal smartfeeds binnen BlogBridge probeer ik zoveel mogelijk op de hoogte te blijven van nieuwe berichtgeving en resources op het gebied van softwaretesten. Zo liep ik vanochtend weer tegen een aardige bron aan, getiteld Software testing by Jagan.

In de eerste plaats aardig omdat er een behoorlijke hoeveelheid leesbare testdocumentatie is verzameld. Naast artikelen en papers vind je er ook een groot aantal templates terug, bijvoorbeeld voor het opstellen van testplannen en testscripts. Ik vind het altijd interessant om eens te kijken hoe andere templates zijn opgebouwd, wat er anders zou kunnen en hoe op basis van andere testmethodieken wordt gewerkt. Dat vergelijken blijft leerzaam en ik kom vaak wel iets tegen wat geschikt is voor hergebruik.

Daarnaast vind ik de bron interessant omdat gebruik wordt gemaakt van eSnips, een voor mij nieuwe toepassing waarbij ondermeer file sharing mogelijk is. Niet dat dit nu zo bijzonder is, dergelijke tools kom je wel meer tegen, maar eSnips heeft enkele handige features toegevoegd waarmee je files vervolgens weer met anderen kunt delen. Zo is er bijvoorbeeld de mogelijkheid per file een widget aan te maken, die ik dan weer op mijn blog kan plaatsen. Dit levert het volgende resultaat op:

Load - Stress Test…

Hosted by eSnips

Ook kan ik via RSS op de hoogte blijven van nieuwe toevoegingen en kun je met behulp van tags binnen eSnips zoeken naar andere resources voor hetzelfde aandachtsgebied. Een mooie verzameling van testmateriaal en een handige en snelle web 2.0 toepassing.

Technorati Tags: Software testing, eSnips

IT Service Magazine refereert vandaag aan een persbericht van Compuware. Volgens dit bericht geven Europese IT-managers in meerderheid aan dat meer dan de helft van de ingebruiknames van nieuwe applicaties faalt. De nadruk wordt vooral gelegd op het feit dat bij implementatie van applicaties er onverwachte prestatieproblemen optreden.

Wat me opvalt aan het persbericht is dat het woord ‘testen’ precies nul keer wordt genoemd, laat staan dat er gesproken wordt over de Productie Acceptatie Test, in testjargon afgekort tot PAT. Als er ergens een moment in een ontwikkel- en testproces is waar je kunt achterhalen of er mogelijkerwijs prestatieproblemen kunnen treden, dan is het tijdens de PAT. Pikant detail is dat Compuware in de slotalinea aangeeft dat organisaties de verkeerde processen volgen en dat het opstellen van prestatieklassen niet als een essentiële stap binnen applicatieontwikkeling wordt beschouwd. Je kunt het echter ook omdraaien en je afvragen waartegen een applicatie dan beoordeeld wordt, als dat soort eisen hardnekkig blijft ontbreken. Is er dan niemand die zich bekommert om acceptatiecriteria?

Het blijkt maar weer eens hoe onderbelicht de inrichting en uitvoering van een PAT is binnen veel organisaties. Testtrajecten leggen in veel gevallen voornamelijk de nadruk op de functionele acceptatie van een applicatie. Maar na een vlekkeloos testtraject en een goed onderbouwd functioneel akkoord kan er nog van alles misgaan. Het opnemen van een Productie Acceptatie Test in je testaanpak kan een boel ellende voorkomen. Ik vraag me af hoe groot bovengenoemde prestatieproblemen zouden zijn als organisaties massaal tijdens de PAT de poort dicht zouden gooien. Zijn er geen prestatieklassen opgesteld? Zijn er geen afspraken vastgelegd in een SLA? Oké, dan hebben we geen testbasis, wordt er dus niet getest en komt er dus ook geen groen licht voor implementatie. Beheerafdelingen zouden deze aanpak alleen maar toejuichen, zij zijn immers degenen die als eerste met de productieproblemen worden geconfronteerd. Werk aan de winkel dus.

Technorati Tags: PAT, Productie Acceptatie Test

Eind vorige maand besteedde het Java Developers Journal aandacht aan een onderzoek van Gartner en Forrester Research waaruit bleek dat veel ontwikkelde .NET applicaties in productie onderuit gaan. Als belangrijkste oorzaak wordt het gebrek aan (performance-)testtooling genoemd waardoor .NET-ontwikkelaars vooralsnog onvoldoende middelen hebben om een goed testtraject uit te voeren.

Toevallig, of misschien ook wel weer logisch, om dit soort geluiden uit het Java-kamp te horen, de grote tegenhanger van .NET. De cijfers liegen er in ieder geval niet om: 71% van de problemen met .NET applicaties wordt niet gevonden gedurende een testtraject maar pas in productie. Excuse me!

In other words, despite all the effort and expense to assure application quality, actual users are still being used as QA and optimization tools.

By spanning multiple components inside and outside the data center, the complexity of .NET Web applications has diminished the efficacy of existing lab-oriented simulation or load-testing tools in predicting and monitoring application performance. For example, your development environment probably has a totally different configuration and load from your production infrastructure. Furthermore, the increasing trend toward virtualization and shared infrastructure means that an application that runs well in isolation in the lab could be sluggish “in the wild.” As a result, actionable information like the call tree shown above is needed to efficiently complete a .NET development project.

Ik kan nog wel meer opvallende uitspraken en conclusies uit het artikel citeren, maar interessanter is het om zelf het hele verhaal even te lezen. In ieder geval wordt uit de cijfers duidelijk dat de grote toename van .NET projecten en ontwikkelteams nog niet gepaard gaat met de ontwikkeling van specifieke testtools die in deze omgeving kunnen worden ingezet. Werk aan de winkel voor de ontwikkelaars van testtooling zou ik zeggen.

Technorati Tags: .NET, testtooling

Ik krijg geregeld vragen over de inhoud van het nieuwe boek TMap Next dat in december van dit jaar zal worden gepubliceerd. Enkele collega’s en vakgenoten zijn nauw betrokken geweest bij de totstandkoming van het boek. Uiteraard zijn ze gehouden aan de afspraken die rondom het vrijgeven van informatie zijn gemaakt. Het is dus nog even geduld hebben tot begin december.

Op Internet wordt echter wel hier en daar een tipje van de sluier opgelicht. Zo is op de TMap-site van Sogeti al onthuld dat het zogenaamde essentiemodel centraal zal staan in TMap Next. Dit model staat voor de volgende vier essenties, zo valt te lezen in het persbericht:

• Gebaseerd op een Business Driven Test Management aanpak (BDTM);
• Geeft een volledige beschrijving van het totale testproces;
• Er is sprake van een complete gereedschapskist met betrekking tot technieken, infrastructuur en organisatie;
• Een adaptieve methode en daardoor toepasbaar in de meeste ontwikkelomgevingen.

Met het centraal positioneren van deze essenties zal het bekende “TIFO-model” (Technieken, Infrastructuur, Fasering en Organisatie) naar ik aanneem niet meer worden gebruikt. Dat valt ook al min of meer af te leiden uit het feit dat de meeste componenten van dit model terugkomen in de gereedschapskist (essentie 3).

Ook geeft het persbericht globale informatie over de indeling van het boek. Zo zal er sprake zijn van een algemeen deel (introductie testen en TMap), worden de processen beschreven (zoals mastertestplanning, acceptatietesten, et cetera) en zullen verschillende componenten worden besproken (o.a. productrisicoanalyse en begrotingstechnieken).

Technorati Tags: TMap Next, essentiemodel

Een leuk artikel op Yahoo! News - Macworld. Onder de kop “Could a 30-in. monitor help you do your job faster?“, buigt een aantal experts zich over de testresultaten van een onderzoek naar productiviteit in relatie tot de grootte van een scherm waarachter wordt gewerkt. In dit rapport wordt verslag gedaan van een aantal productiviteitstesten met een 30-inch Apple Cinema HD Display.

The study, which evaluated Apple’s 30-inch Apple Cinema Display, concluded that large screens can offer gains of up to 50 percent to 65 percent in productivity on a variety of specific office tasks and can earn back their extra costs in time savings over several years. The 30-in. display costs $1,999.

But other experts say those conclusions are wrong, arguing that the productivity improvement estimates are too high and that using two monitors side by side would likely be a better productivity booster than one larger monitor.

Ik heb zelf het idee dat e.e.a. afhankelijk is van het soort werk dat je op het scherm verricht. Als ik veel documenten tegelijk open wil hebben, lijkt me één groot scherm ideaal, zeker als er het nodige geknipt en geplakt moet worden. Maar doe ik twee totaal verschillende dingen, bijvoorbeeld een document schrijven en op Internet surfen, dan lijken me twee monitoren naast elkaar (van een “normaal” formaat) net zo practisch. Maar ik geef toe, zo’n 30-inch Apple speeltje op mijn bureau lijkt me niet verkeerd. Ik zal morgen eens een businesscase schrijven, kijken of het wat gaat opleveren.

Technorati Tags: productiviteit, schermgrootte