Tips voor testen migratie van applicaties naar de cloud

Ik was laatst op www.testforum.nl en kwam een vraag tegen van iemand (funkyfish) over waar je op zou moeten letten bij een migratie traject (Windows) en de virtualisatie van applicaties. Hier heb ik ondertussen wel wat ervaring mee en had ook een aantal tips in een antwoord gegeven op het forum. Het forum is dezelfde (of de dag erna) uit de lucht gegaan, door voor mij onbekende redenen.

Het antwoord nu dan via mijn blog, ik hoop dat je het leest, funkyfish. Ik heb het antwoord hier en daar herschreven voor dit blog en is het wellicht ook voor anderen een mooie ideeën lijst.

De context
Een infrastructureel test traject, waarbij het Windows Platform wordt ge-upgrade, en tevens applicaties worden gevirtualiseerd. 'Naar de cloud gebracht', wordt tegenwoordig ook wel gezegd. Wat zijn nu punten waar je op kan letten bij het testen van de applicaties?

Het antwoord
Hieronder een aantal ideeën uit praktijkervaring die je verder op weg kunnen helpen. Mocht je als lezer van mijn blog opmerkingen, extra ideeën hebben, laat het mij weten via antwoord op het blog, mail, tweets... Ik ben zeer geïnteresseerd!!

Soorten applicaties
Verouderde applicaties
Worden die nog wel ondersteund door de leverancier bij virtualisatie? Deze zal je als eerste moeten testen, want de kans dat hier iets fout gaat (faalkans) is hoog. Is een applicatie niet zo van belang voor een bedrijf dan zou men in een vroeg stadium kunnen bedenken om deze niet mee te nemen met een migratie. Maar wil men het toch proberen, is het zaak om deze als eerste te testen.

Web applicaties
Kan zijn dat deze een specifieke Java versie nodig hebben of een andere plug in voor web browsers. In ieder geval niet vergeten dit soort applicaties ook te testen. Het kan zijn dat in een gevirtualiseerde omgeving niet de juiste Java / Silverlight / andere onderdelen worden geïnstalleerd. Verder hebben sommige websites specifieke certificaten nodig, dit wordt niet altijd van te voren opgemerkt. Bij bank applicaties met een calculator of iets dergelijks kan het zijn dat er software moet worden geïnstalleerd voordat men ermee aan de slag kan. Worden er meerdere browsers gebruikt, allemaal testen.

Standaard applicaties (zoals MS-office)
Deze worden vaak geïnstalleerd in de Windows omgeving en niet apart gevirtualiseerd. Het probleem hierbij kan zijn dat sommige WEL gevirtualiseerde applicaties samenwerken met deze NIET gevirtualiseerde applicaties. Het gaat hier bijvoorbeeld om MS-Office en Adobe PDF reader. Let goed op of er in de oude situatie applicaties met dit soort basis applicaties samenwerken en probeer een volledige checklist te maken.

Applicatie suites
Soms horen applicaties bij elkaar, maar dat is vanuit de gebruikers niet altijd duidelijk. Ook bij degene die de applicaties virtualiseert kan dit gemist worden. Dan worden applicaties apart gevirtualiseerd. Het gevolg is dat deze dan niet  meer samenwerken. Goed controleren of er combinaties zijn van applicaties die bij elkaar horen.

Grafische applicaties
Let op bij applicaties zoals: Photoshop, Illustrator en andere foto bewerking software, video bewerking, grafische wiskundige software. Bij virtualisatie kunnen diverse problemen optreden. Performance issues kunnen ontstaan, maar ik heb ook gezien dat de kleurenschema's compleet mis kunnen gaan, zodat elke foto een waas heeft met een bepaalde kleur. Probeer deze applicaties zo vroeg mogelijk te testen, want een oplossing zoeken kan veel hoofdbrekens geven.

Updates van applicaties
Het kan voorkomen dat applicaties in de migratie worden ge-update. Dit omdat een oudere versie niet werkt in een virtuele omgeving en deze dus ook gelijk meegenomen wordt in dit soort trajecten. Het kan zijn dat dan ook de achterliggende database wordt ge-upgrade. Dit is een apart traject waar je ook naar de backend moet kijken. Verder kan een applicatie zo afwijkend zijn na een upgrade dat het niet goed te vergelijken is met de 'oude' software. Nog een reden om hier kleine aparte trajecten van te maken.

Randapparatuur met eigen applicaties
Als een applicatie een driver nodig heeft, zoals bijvoorbeeld Dymo labelprinters, dan wil dit niet altijd goed gaan bij virtualisatie. Belangrijk om dit te inventariseren en te bespreken met degene die de software virtualiseert. En daarna goed te testen.

Basis checklist voor applicaties

• Start een applicatie meerdere keren op en sluit deze tussendoor een paar keer af. 
• Verander instellingen in een applicatie, sluit af. Weer opstarten en instellingen controleren.
• Sluit de PC af. Als je weer opstart zouden instellingen bewaard moeten zijn.
• Maak een nieuw bestand aan, verwerk gegevens en sla deze op. Weer openen en controleren.
• Open een bestaand bestand (grote bestanden ook proberen)
• In verkenner dubbelklikken op een bestand -> opent het juiste programma
• Met rechtermuisknop in Windows verkenner bestanden openen
• Kan je de help functie goed benaderen?
• Minimaliseer het scherm
• Maak het scherm weer originele grootte
• Spelling en grammatica controle
• Alle menu items hetzelfde als in de ‘oude’ omgeving
• Menu items bereikbaar via de shortcuts die je normaal ook gebruikt.
• Undo functionaliteit gebruiken, Redo 
• Afdrukken naar een printer, of een PDF maker.
• Sommige applicaties hebben een verzenden naar email functionaliteit
• Sommige applicaties hebben een samenvoeg functie met MS-Word
• Kopiëren tussen applicaties (ook met accenten é ö ç ø). Niet alleen teksten, ook plaatjes, Powerpoint presentaties, Visio  tekeningen e.d. 
• Werkt je applicatie samen met andere applicaties, probeer deze functionaliteiten dan zeker.

Verder punten voor de omgeving

Verder is het natuurlijk afhankelijk van wat er  nog meer verandert in je omgeving, wat je zou moeten bekijken, of in ieder geval de risico's in kaart brengen.

• Test altijd met gebruikers (productie like) accounts, zodat je niet mist als er iets geïnstalleerd moet worden (er wordt steeds meer automatisch geïnstalleerd tegenwoordig, zonder dat de gebruiker dat merkt)
• De werkplek zelf (Windows) moet ook goed bekeken worden, wordt nog wel eens vergeten of als minder belangrijk beschouwd: taal instellingen, inloggen, werkplek switchen, meerdere keren inloggen, configuratie instellingen, bestand extensies tonen of niet, ... paar voorbeelden.)
• outlook upgrade heeft zijn eigen specifieke aandacht nodig
• nieuwe AD structuur door virtualisatie waardoor gebruikers hun applicaties niet meer krijgen (proef migratie van paar gebruikers doen)

Toen ik dit aan het nalezen was kwamen er nog veel meer ideeën naar boven. Deze lijst is niet onuitputtelijk, maar ik vind dit nu wel genoeg. Het ging uiteindelijk om wat ideeën en tips. Misschien schrijf ik in de toekomst nog wel wat meer ideeën op, of uitgebreider in een white paper of mini boekje of iets dergelijks.

Funkyfish, als je dit leest, succes met het project. Verder voor iedereen: reacties welkom!!

3 of 3: Eurostar Testconference 2012 – Lessons learned and to learn...

The testlab and the community Hub

I didn't write down all the presentations I have seen or all discussions I've had during the conference. Nor all ideas that popped up.

But I would like to mention the Test lab, which was positioned in the expo hall. This was great, until now the test lab was hidden away somewhere in a conference room, but now it was  open and visible to see. They had computers to test on and real robots you could test. If you found a bug, you got a nice t-shirt and I wear it with proud. When you get to a conference where the Test Lab of Bart Knaack or James Lyndsay is, reserve a few hours to spend there. You could be testing software with some of the well known testers in the world and learn something new.

Testing the Robots in the testlab

Community Hub
Something new at the Eurostar conference, a room where five minutes talks were executed, discussion and to relax. Also the Eurostar minmap of learning was made in this room. This is something like a big beautiful mindmap where the visitors of Eurostar could put subjects (by yellow papers) on the map, that are drawn visually by Nathalie Roosenboom.

I visited the community hub a few times, even got a free book there: "Who wants this book?": Experiences of sofware test automation The authors (Dorothy Graham and Mark Fewster) were there, so they signed my copy. This was one of the new books I wanted to read, and didn't buy yet.

Detail of the mindmap 'what did I learn at Eurostar'

The workshop of Marcus Gärtner
I like subjects that are not really about testing but help you in your daily work. I also like to be challenged in thinking and this workshop had both aspects. Marcus Gärtner named his workshop "Beyond testing". It was really way beyond testing and we all had difficulty keeping up the pace.

We started of with some questions about testing, but very quickly we had to form groups and start thinking and discussing the question: What is System thinking? We created a mind map and got even to complexity theory and other subjects.

Later on I talked about systems thinking and was advised by to read Quality software systems Volume 1-2 by Jerry Weinberg. I knew the books, but now I finally ordered them.

The discussion in our group in mind map format.

The workshop continued about communication and aspects of communication, in combination with playing role games in this workshop. Also in blog 1 of 3 of this series I mentioned the cause effect diagram. This was discussed and tried out by ourselves. After that Marcus talked about change in organizations and a way to support that process via a certain method. And even the break in between was a communication exercise (talk to a member of another group how that group had interpreted systems thinking).

So this was a fully filled 2,5 hour, very interactive, much to learn and think about session. OK, I was lost there a few times, but the subjects are in my notes and will certainly guide me for more learning.

The end
A conference ends and then there is time to think and reflect. I guess the conference was better then I expected beforehand. So maybe next year again to Eurostar... Well, as I really like the 'big cheese'  who runs the show next time, there is no hesitating in that and I expect even a better conference next time.

To summarize the lessons learned and to learn
So to summarize this, also to check on later in the next year, these are things, because of this conference I will actively use. If other ideas pop up, that's great, but for now:

Some books were mentioned that I will have to read now

• Little black book on test design (R. Edgren) Well I read this already, but will have to revisit it, being some time ago.
• Quality software systems Volume 1-2 (Jerry Weinberg) In fact I ordered alsy volume 3
• The lean startup (Eric Ries)

Solving problems (is innovating)

• Is it really a problem, maybe there is a problem behind the problem, what is the real cause of the problem?
• Always check if the problem still exists.
• Defocus on what is perceived and try to see the bigger issue behind it.
• Start using cause-effect diagrams

Test reporting, explaining testing

• Study reporting by for example visualizing testing and testing results (Research blogs that write about this subject)
• Practice status reporting of a project: Stop where you are while working in a project and explain the status of the project in 30 seconds.
• Stop using as much as possible the ISTQB words and use the business language for this.
• Try to explain testing without using the word “test” in it. This is also something I heard from other presentations and on the Agile Testing Days. (Did the challenge this week, creating a plan to improve and structure testing, without using the word testing. That was a challenge, still have to refine this :-))

Create improving Testing within organizations checklist

• testing dojos, focus on learning and training for testers
• let people speak on conferences, introducing test work groups
• less documentation by using mind mapping techniques and low tech dashboards
• test improvement by session (session based test improvement?)

Cognitive biases

• create checklist for overcoming biases and he mentioned
• always be cautious when making decisions
• Reference class forecasting (check with other industries and compare).
• Double check the Michael Bolton presentation about confirmation bias

Skills I will work on the next months

• Influencing other people
• systems thinking

Lots of more ideas were going around, but I have to channelize this in this way. I hope it helps you too in some odd way that I wrote this down. See you!

And now on to my notes for the Agile Testing Days of last week... Pfew.

Pictures from Eurostar 2012

OK, I took some pictures during the conference with my phone. Mainly I use them for taking notes and use them to reflect later. But they also give a feeling of the overall conference I guess. So I share some pictures here that were good enough to publish on the blog. (if you want the original picture, don't hesitate to mail me)

Ideas is about solving the right problem, by Alan Page

Catch the whole potato, by Rikard Edgren

The passion of the tester. 'If you don't like testing, quit your job', by Huib Schoots

The testlab

Squeeze the chicken in the test lab when you  found a bug.

 

The community hub, small room. People sharing ideas.

The mind map of 'What did you learn at Eurostar', by Nathalie Rooseboom de Vries- van Delft

Community hub again, a five minute talk

Thinking and discussion at the workshop "Beyond testing" by Marcus Gärtner

Workshop "Beyond testing"

2 of 3: Eurostar Testconference 2012 – Lessons learned and to learn...

Part 1 of this posting is here

Huib Schoots and changing the context at the Rabobank
The world of testing is changing: As we have been using methods like TMap and ISTQB in the past, which could fit perfectly in your project or organization, the big differences in organizations and projects lead us to defer from these methods or even throw them away completely. This to rethink testing and get a better fit with testing in certain ways. The Rabobank is doing so and is a good example of introducing these (new) ideas in bigger organizations, where you would expect it not to be possible or at least too difficult to get this accomplished.

This because organizations such as banks have big IT machines that exist for a long time and have certain ways of working and people that do not want to change after working for 40 years in the same job.

Not only testing, but the world of IT is changing and the way we think about software development. The agile revolution is one of these changes. And this was also introduced in the bank and was as a hook to improve testing too.

Low tech dashboards as a way to replace comprehensive reporting

Some actions were taken, as doing testing dojos, focus on learning and training for testers, let people speak on conferences, experiment with Exploratory testing, less documentation by using mind mapping techniques and low tech dashboards, introducing test workgroups to figure things out and get the testability on a higher focus within the organisation.

These are all things I can put on my own test improvement checklist. I will do that and search out some more about those subjects and will think about how to introduce those within organizations when I'm on a project of such kind. 

Graham Freeburn and mapping your way to better testing
And the change is also happening in the way we look at test process improvement. Graham Freeburn had used Test Proces Improvement (TPI) in the past. But he learned that the TPI method is too much focused on processes and has less focus on actual skills.

So he created another way to improve testing processes. Now he uses sessions such as kick offs, presentations and creates an action plan from these sessions. Because of this there is constant communication between him and the people and between the teams in  organisations. He uses the Goals problem tree and checks constantly with the business goals. For working out and collaborating he mainly uses mind maps.

• Best quote: If you deliver value every time, the customer will worry less about costs
• Important skill he mentioned: Influencing other people.

The sessions he mentioned that he uses are good to put on my test improvement list. So instead of asking questions and do interviews, communicate, think, explore within these sessions to get the quality of testing higher. The outcome would fit an organization better than the standard formal process of TPI.

Cognitive biases
Martin Jansson (from the test lab) already mentioned this to me while talking in the test lab: “Knowing the requirements could cause you to not see certain aspects of a product and could eventually lead to missing some bugs.”

I checked ‘cognitive biases’ on Wikipedia: “A cognitive bias is a pattern of deviation in judgment that occurs in particular situations, which may sometimes lead to perceptual distortion, inaccurate judgment, illogical interpretation, or what is broadly called irrationality.”

The inaccurate judgment and perceptual distortion would be issues we as testers are dealing with every day.

"It is the human tendency to make systematic errors in certain
circumstances based on cognitive factors rather than evidence."

 
A human is easily influenced. The speaker gave an example of a scientific research project. People were asked to write down (or think) about the last two digits of their social security number. After they were asked about this, they participated in an auction. The result was that people with higher numbers in their head because of a higher number at the end of the social security number ended up bidding more than the others.

Some ways to overcome biases and he mentioned are the use of checklists, always be cautious when making decisions (black hat thinking), reference class forecasting (check with other industries and compare).

Later that day I spoke with Srikanth and about the difficulty I have with biases, namely not recognizing them, he said, that it is good to be aware at least these exist. (so a bit of curing from biases here in his talk)

I will have to update my checklists I already have and will use them also constantly. Until now my own checklists are all over the place and not structured to my needs. Rethink, use new ideas and structure this for future use.

Good to check: Michael Bolton has a presentation about the confirmation bias here http://www.developsense.com/presentations/2010-04-ConfirmationBias.pdf

To be continued in part 3

1 of 3: Eurostar Testconference 2012 – Lessons learned and to learn...

I’ve been to the Eurostar 2012 test conference in Amsterdam (November 2012). There were so many presentations about lots of subjects. If I would try to learn from all those wonderful ideas I would certainly get lost in this overload of information. But as Alan Page said in his keynote, ideas come from other ideas, so I will let that be a guidance.

So in the end these blog posts leads to:
-    some ideas to put on my self-study list
-    a list of books to read (or to put on my everlasting book pile).
-    some ideas I can use immediately in my daily practice as a tester.

So what did I learn?

The keynote of Alan Page was about ideas and innovation. I combined some learning from Alan Page and the workshop I followed on the third day: Beyond Testing, by Marcus Gärtner.

What is innovation? To solve the ‘right’ problem. But one should know what the problem is and then you should follow it up by questioning the problem: Is it really a problem, maybe there is a problem behind the problem, what is the real cause of the problem?

Furthermore: Always check if the problem still exists. Is there a bigger problem here than what we acknowledge until now. Defocus on what is perceived and try to see the bigger issue behind it.

One way to start solving issues and create some ideas is drawing up a a cause-effect diagram: What are the different aspects that influence each other, are these positive or negative influences. Do they increase the problem or are there any positive side effects we can think of? How can we change the negative relations between activities to get out of this downward spiral.

Cause-effect diagram, drawn by M. Gärtner in workshop

The binary disease

Am I on my way to complete health from the binary disease? Richard Edgren did a talk about some diseases we have as testers. The binary disease is one of them: Reporting test results in the form of pass/fail lists. Because real life isn’t that black and white, it is actually very strange to report test results in this binary way of “passed” and “failed” test cases.

In my current job I had discussions with the project managers about test reports I created. Instead of a big list of OK and Not OK they only wanted the most important defects, and no red blinking Not OK signs.

But only reporting on blocking issues wouldn’t give the overall picture, I still wanted more in the reports, but was not sure what to do about it in this context. Eventually it was a defect report combined with mentioning possible risks for going into production. Now I should study reporting more by checking those various blogs that are written about this. There are some blogs going on about visualizing testing and testing results, so that would be something to check out. Richard also mentioned a great exercise that I’m going to use: Stop where you are while working in a project and explain the status of the project in 30 seconds.

I connected the Richard talk with the Alan Richardson (aka Evil Tester) talk later on with the subject of using other words to describe testing, not using the standard words we all learn during ISTQB or TMap courses and trainings. Use words that fit the customer in a better way.

For example: system testing is an official standard, but in practice could mean something completely different from organization to organization. So instead of trying to use certain words from testing standards and methods , use the words that best describe the situation for a certain organization, project, software product. On what system testing really means for example, simply communicate and discuss with the people that are dealing with that kind of testing.

End of part 1 of 3

30% korting op Exploratory workshop van James Lyndsay!!

Op de Eurostar test conference 2012 dit jaar kwam ik James Lyndsay tegen...

Ik ben naar de Eurostar Conferences 2012 geweest in november en ik heb daar aardig wat geleerd. Daarover volgt nog een blog.

Een van de organisatoren is James Lyndsay. Ik ken hem via Twitter en zijn blog en volg hem al een tijdje. Ook heb ik hem ontmoet op de Agile testing Days van vorig jaar. Hij geeft, waar de vraag is, Exploratory Test workshops en ik wilde eigenlijk dit jaar al naar zijn workshop, maar ik kan niet alles tegelijk. Ik kwam hem tegen op het testevent en vroeg of hij nog van plan was om nog eens naar Nederland te komen. Hij gaf aan dat hij daar nog geen ideeën over had, maar als ik minstens vier mensen kon vinden die geïnteresseerd zijn, dat hij dan naar Amsterdam komt om een workshop te geven.

Via Linkedin en Twitter heb ik inderdaad een aantal mensen gevonden die interesse hebben in zijn workshop, dus ik hoef niet zelf naar Engeland te reizen, hij komt hierheen. Nu dat redelijk zeker is (mensen moeten straks nog wel gaan boeken natuurlijk), ga ik toch maar even door met het promoten van deze workshop.

Één van de meest ervaren testers en trainers in Exploratory Testing

Als je het over Exploratory testen hebt denken veel mensen aan James Bach en Michael Bolton, maar er zijn natuurlijk veel meer mensen actief en bezig met deze aanpak. Er worden echter nog niet zoveel trainingen gegeven op dit gebied. Zelfs als je de training van Michael of James hebt gehad is dit een aan te bevelen toevoeging op je kennis en kunde. Zijn workshops bestaan uit veel oefenen en oefenen en proberen. De workshop is daarmee dan ook geen monoloog van James, maar een samenwerking tussen James en de deelnemers. Wat mij betreft de beste manier om je kennis op te doen binnen een 'leslokaal principe'

30% korting als je nu al je interesse toont!!

Ik ben blij dat ik niet hoef af te reizen naar Engeland of ergens anders en misschien zie ik jou ook volgend jaar in de workshop?
James heeft een pagina gemaakt waar hij meer informatie op heeft gezet en als je je aanmeldt als geïnteresseerde dan krijg je 30% korting op de workshop, als je die dan later ook boekt. Dus zeker vrijblijvend, voor James om te peilen met hoeveel mensen hij rekening moet houden en zich voor te bereiden. Hij zal dan ook zelf de verdere communicatie doen.

Meld je snel aan op http://unbouncepages.com/exploratory-testing-in-amsterdam-2013/

Mocht je denken aan een in-house training, want die doet James ook, neem dan even contact op met James, of met mij, dan geef ik je contact informatie door.

Tot ziens op de workshop,
Rob van Steenbergen

Het constant verzamelen van gerichte test ideeën

Lekker TV kijken

Piet zit lekker TV te kijken. Zijn favoriete programma “Top Gear” wordt uitgezonden en de begintune galmt door zijn huiskamer. Lekker genieten dus. Biertje erbij en een bakje nootjes. Op ongeveer de helft van de show is men bezig met de gast van de week die in een “Reasonable Priced Car” op het circuit van Top Gear gaat racen voor de snelste tijd.

Al eerder zag Piet in zijn linkeroog een lamp aanstaan die zijn aandacht al een paar keer had getrokken en hem licht afleidde van de uitzending. De lamp in de keuken reflecteert namelijk via een glazen kast en de reflectie van de lamp kan hij zien als hij naar links kijkt. Hij probeert zich er niets van aan te trekken, wordt af en toe nog afgeleid  maar kan de show prima volgen. Nu begint men met een caravan race, waarbij de caravans gemonteerd zijn op race wagens.

Dan is er de verplichte reclame. Piet doet wat de meeste mensen doen tijdens de reclame en gaat naar de WC en vult zijn glas bij. De show begint weer en Piet gaat weer zitten om verder te genieten van zijn vrije avond. Na een aantal minuten beseft hij dat hij niet meer afgeleid wordt door de weerkaatsing van het licht in de keuken. Hij bedenkt dat hij het licht tijdens de pauze automatisch heeft uitgezet. Hij denkt er verder niet meer over na en geniet van de rest van Top Gear. In dit geval wel iets meer relaxed dan toen het licht aan stond.

Piet zijn aandacht werd niet meer weg getrokken van de show en voelt zich daarmee iets rustiger. Als hij het licht nu al de eerste keer dat hij het had gezien had uit gedaan, had hij misschien nog meer genoten van de show aan het begin. Maar het bewuste besef dat het licht hem stoorde had hij toen nog niet, omdat zijn aandacht op iets anders gericht was.

Focus verleggen naar iets wat stoort

Op mijn werk zei iemand: “Jeemig, alweer zo traag, dat netwerk… Ha het gaat al weer beter”.
Nu kan je zo’n opmerking makkelijk negeren, omdat je diep geconcentreerd bent met je testwerk. Dan vallen dit soort opmerkingen niet zo snel op. Dit soort kleine, niet echt verstorende aanwijzingen zouden wel eens een mogelijk groter probleem kunnen bevatten. Of in ieder geval een mogelijk risico voor de kwaliteit van het product of het project waarmee of waarin je bezig bent.

Als je de show wilt afkijken zonder verstoringen zal je toch ook aandacht moeten hebben voor de omgeving en alle ‘bij-signalen die je ontvangt’. Als tester ben je er voor om dit soort zaken te onderzoeken en onder de aandacht te brengen.

• Een losse opmerking van een collega over de snelheid van een systeem
• Een flikkering in je scherm die je nou wel of niet hebt gezien toen je op die knop klikte?
• De afwezigheid van een aantal belangrijke stakeholders bij een of meerdere vergaderingen
• Een document, mail of memo waar je de inhoud niet van begrijpt (Ligt dat aan jou of begrijpt niemand dat?)

Soms komen we er pas later achter dat dit tekenen waren die tot een bepaald probleem hebben geleid. Daarom moet je gevoelig blijven voor dit soort zaken en altijd scherp blijven.

Oefenen..
Ik ga oefenen hiermee en eens kijken of bepaalde zaken die mij normaal niet opgevallen waren nu wel onder mijn aandacht komen. Hierna ga ik de focus leggen op deze zaken die ik tegenkom. De oefening bestaat uit de volgende stappen:

• Extra opletten op verdachte signalen, ook opletten als ik geconcentreerd bezig ben (Alle input die ik krijg, opmerkingen, rare mail, het gevoel dat er iets niet klopt)
• Dit op een soort van actielijst plaatsen, gewoon kort in één zin, als een soort to-do lijst voor test ideeën 
• Als ik tijd heb loop ik de lijst door en onderzoek ik de punten, of het nu een onderzoek is van 5 seconden of een uur, het kan leiden tot een ontdekking van mogelijk grote problemen waar nog niemand aan gedacht heeft.

Resultaten

Op dit moment vind ik mijzelf al redelijk gevoelig voor dit soort zaken, maar nu wat actiever opletten. De resultaten plaats ik later op dit blog.

Vind je dit een goed idee? Wil je het ook proberen? Laat het mij eens weten hoe dit verloopt.

Weer een testevenement gemist.

In het weekend van 5 en 6 oktober heb ik een testevenement gemist, namelijk DEWT2. Dit keer door autopech en hierdoor veel geregel om toch weer mobiel te zijn de komende week. Je kunt het afdoen als: pech gehad, volgende keer beter.

Maar zo voelt het niet. Deze bijeenkomst was een kleinschalige bijeenkomst, niet meer dan 25 genodigden van ‘testnerds’, 24 uur pratend over testen. Geen markt met toolverkopers of wervers met commerciële belangen. Op dit specifieke evenement had ik graag eindelijk eens een paar mensen ontmoet die ik al een tijdje volg.

Relativerend: ik zal ze vast nog wel eens ontmoeten en begrijp dat deze bijeenkomst een succes was en een vervolg krijgt in “DEWT3”.

Verder dit jaar gemist door allerlei redenen, privé of werk gerelateerd:

• The Belgium Testing Days (kaartje gewonnen),
• TestNet voorjaarsevenement
• TestNet summer school
• TMap test tool event
• en nog één of twee die ik nu even ben vergeten...

Micheal Bolton met cursist

En dan de evenementen waar ik eigenlijk heen wilde, maar toch besloten heb niet heen te gaan, zoals het alom geprezen Let’s test, Testbash en een aantal testnet thema avonden. Maar ik wil natuurlijk teveel en je kunt niet alles meemaken.

Want wat ik wel heb meegemaakt dit jaar is de training van Anne-marie Charret (coaching testers) en van Michael Bolton de training 'Rapid testmanagement'.

Het najaarsevenement van TestNet

Tevens ben ik naar het najaarsevenement van Testnet geweest. Dit jaar waren er naast de standaard presentaties ook 'open spaces' en diverse workshops gepland. In deze sessies was je met een paar testers bezig om over een bepaald onderwerp te discussiëren. Ik zat bijvoorbeeld in een workshop met vier testcollega´s. Hierin waren we aan het praten / denken over het testen van modellen die voorspellingen kunnen doen over het aantal reizigers bij de NS in een bepaalde periode.

Heel specifiek, heel erg leerzaam. Over het onderwerp zelf, de NS en hoe een paar verschillende testers bij elkaar vanuit totaal verschillende perspectieven met elkaar een aantal test ideeën kunnen uitwerken. Ik weet niet of TestNet deze workshops zelf als succes ziet, maar ik zie dit wel als een zeer goede aanvulling. Praten met elkaar levert meer kennis en ideeën op dan alleen zitten luisteren naar een presentatie. En dat gaat beter met een kleiner groepje mensen dan een grote zaal.

De tutorials aan het begin van de dag zijn al de moeite waard, kleine klas (max 50 personen) en gemotiveerde leraren. Dit jaar heb ik bij de training mindmappen gezeten van Huib Schoots en Jean-Paul Varwijk. Ik ben aardig bekend met mindmaps, maar heb daar toch wat geleerd, niet alleen over het onderwerp, maar ook over de manier van lesgeven van deze mensen: interactieve les en zo leren en zelf nadenken over iets.

Paar mindmaps getekend in de genoemde tutorial

Naast deze zaken ontmoet ik altijd veel ex collega’s en nieuwe testvrienden, vaak al eerder ontmoet via Twitter of andere sociale media. En ik heb, zoals altijd bij congressen, veel goede gesprekken gehad en ideeën uitgewisseld. Dit Testnet krijgt van mij weer een dikke vette voldoende.

Het interessante van congressen
En daar gaat het om, een evenement of congres is niet alleen ‘een dagje uit’ of ‘weg van je werk’, wat veel mensen en managers denken. Zo, zo, hèhè, poeh: even een paar dagen rust. Of een vervelend saai luisteren naar saaie presentaties over onderwerpen waar je toch niets mee kan.

Van de saaiste presentatie kan je zelfs leren, ook al is het maar iets kleins, zoals een goede collega die dag beaamde. Het naar evenementen en congressen gaan vergt nadenken, opletten, luisteren, praten en lijkt erg veel op werken als je het goed doet.

Het is net werken, maar niet achter een bureau.

Ben je serieus over je dagelijks werk? Het is iets wat een groot deel van je leven vult. Wil je weten hoe je bepaalde test onderwerpen moet aanvliegen, hoe je vak collega’s over testen denken? Wil je van gedachte wisselen? Iemand merkte op dat concurrentie tussen bedrijven niet geldt op Testnet, je kunt over onderwerpen praten en kennis delen, puur om het testvak. Jij werkt voor Sogeti, zij voor Valori, hoe lossen jullie zaken op? En hoe doen ze dat hij de NS?

Pleidooi voor testevenementen
En zie hier, een pleidooi voor testbijeenkomsten, groot of klein. Heb ik je hiermee over de streep gehaald? Kom je ook? Jouw ideeën zijn ook nodig. Het testvak kan nog wel wat input gebruiken om nog betere ideeën te ontwikkelen.

Binnenkort ga ik in ieder geval nog naar Eurostar. En dan later in de maand naar de Agile Testing Days in Berlijn, waar een mix van testers en andere disciplines zijn vertegenwoordigd. Ik zal over beide op mijn blog schrijven.

Deze twee congressen overigens, beginnen beide op de eerste dag(en) met tutorials over testen. Bekijk altijd even de onderwerpen, wat dit is je kans om getraind te worden door de beste testers van de wereld.

Tot ziens op een testcongres!

Extra: Toen ik deze blog wilde plaatsen kwam de volgende blog uit van Matt Heusser (tester uit America) met tips hoe je een congres ‘kan doen’. Hier de link: http://www.softwaretestpro.com/Item/5689/How-to-%27Do%27-a-Conference/Testing-Software

Some free e-books about testing

I was browsing through my collection of test related material and found some great free e-books and white papers about testing.

So here some of my favourite free books, enjoy them!

• Agile for Dummies e-book
• Essentials of testdesign
• The Little Black Book on Test Design
• Exploratory Testing in an Agile Context Materials
• Web Load Testing for Dummies
• Pairwise Testing: A Best Practice that Isn't
• The problems with testing
• Software Engineering Metrics: What Do They Measure and How Do We Know?
• Performance Testing Guidance for Web Applications

So what are we all going to do?

The world of IT is changing with a speed that could go beyond comprehension if we don’t pay attention. People around the age of 60, and even earlier don’t know how to deal with computers. As our kids have an iPad in their cribs and learn how to interact with software, the elder are struggling to even try to understand a concept such as e-mail.

And as a tester of about middle-age, let’s say around 40, you’re in the middle of it. Maybe you started to work with computers on your twelfth birthday, maybe you started earlier or later. Did you for example use MS-DOS? Did you create a .bat file to make a menu on your green and black screen, so some tasks would be easier to do? Did you work with a word processor, that couldn’t show pictures on the screen yet, but appeared when printed on paper?

Not too long ago it seemed strange that a four voice harmony music could be created with a computer. Now we take it for granted that you can watch video in HD. You had a tape recorder that took 5 minutes to load a software program, now we go to an app store to get our software.

Not so long ago in my testing study I learned all the rules for a date field, with all its exceptions. Nowadays a date field has the least of our attention. We worry about virtualized Windows versions and virtualized apps in the cloud, that could be serviced from anywhere. We are trying to find ways to measure performance of systems that have millions of external influences. And how to verify if a system is secure enough. We struggle to automate our tests. We experiment with ways to get at least a test coverage that is important enough to test.


And this is still the beginning. At this moment testers are looking into other directions for measuring quality. Quality checks by building a model of the software in another system, quality of requirements and management of requirements. Building the right product, instead of building it right.

And time is going faster and faster. We build software that exists in that form only for a few months, weeks, days. Changes are going even faster than that, every minute the IT as a whole changes. Related software to your product could change even every second. With systems interconnecting all the time, the changes could go even faster than that.

Testing will not be the same any more in ten years, the principles will hold maybe, but until when? Commands such as ‘If, then, go, else’ don’t work in the new quantum computers of the future. Will we understand that technology? Is there any reason we need to understand that technology?

Wow, when I think about this I believe it will some exciting years to come and I want to be part of that revolution. You too, or are you getting afraid already?

Rapid Test Management course mind map

I've been to the Rapid Test Management course with Michael Bolton.

I really learned a lot of new things, but also got some things 'clicking together' in my mind with the stuff I learned at the Rapid Software Testing course and the Critical thinking course I did last year (also by Michael Bolton).

Do I recommend this course? Ha! If you get the chance to go to a Rapid Software Test course (or other subjects). Go!

Check schedules on the next websites:

• http://www.satisfice.com/jamesschedule.shtml
• http://www.developsense.com/

Also Paul Holland will be teaching the course in near future, but I couldn't find his schedule yet - http://www.linkedin.com/profile/view?id=924983&trk=tab_pro





Mindmap
More and more people share their mind maps on the internet, so I guess people like this. So this is my mind map of the two days.

It is somewhat collapsed, so not fully in detail. And all the objects are on one side, so that it fits in this page. So no full overview, but you will get a good idea about the subjects of the course.

Mail me, tweet, or use other media if you want the complete picture or Freemind file. And of course I am still working on it while I'm studying the subjects the next weeks, months, years :-)

 

OK, some pictures too :-)

Difficult customer (and brave tester)

Stopping heuristics exercise

Detail of Stopping heuristics exercise cards on the ground

De trends in sofware testing, wie kent ze nog niet?

Op 8 maart gaf internet pionier en test goeroe Lee Copeland een presentatie over de trends in de software test wereld. Dit deed hij op het testevenement van Polteq: "Cloutest". De presentaties van deze dag kunt u hier vinden.

Wat zijn de trends in de testwereld?
Wat Lee Copeland als trends ziet zijn de volgende onderwerpen:

• Process: Context-driven School , Checking vs. Testing, Crowdsourced Testing, The Weekend Testers, Exploratory Testing
• Agile: Test-First Development, Acceptance Test-driven Development (ATDD)
• Education: Really Good Books, Big and small Testing Conferences, (Small) Testing Workshops, Freedom of the Press
• Technology and Tools: Open-source tools, Virtualization, Testing in the Cloud
• Improvement:  TPI  en TMMi

Ik ben zelf wel bekend met alle onderwerpen die genoemd zijn in zijn presentatie. De meeste ben ik meer of minder mee bezig, of bezig geweest.

Wat ik mij afvroeg na deze presentatie was echter: Is testend Nederland eigenlijk over het algemeen bekend met deze trends? Als dat zo is, zou Lee Copeland een bekend verhaal vertellen voor iedereen en dus achterhaald zijn. Maar mijn gevoel en ervaringen zeggen van niet.

De gemiddelde tester is over het algemeen niet op de hoogte

• Sterker nog, ik heb IT’ers gesproken dit jaar (2012) die mij vroegen wat ik bedoel met “agile”.
• Op een Testnet bijeenkomst, waar James Bach en Michael Bolton via een live verbinding over testen aan het praten waren over testen hoorde ik: “Ik ga mijn testers toch niet loslaten zonder daar verder overzicht over te behouden”  en kreeg ik de vraag: “Is die manier van testen dan heel anders?”

Pijn aan mijn oren
En daar krijg ik pijn van aan mijn oren. Als je elke dag bezig bent met het testen van software vind ik wel dat je minstens op de hoogte moet zijn van de laatste ontwikkelingen. Agile is niet iets wat je kan negeren en Session Based Test Management is niet iets waar je echt lang naar hoeft te zoeken op internet.

Een lijst van interessante links over deze trends
En natuurlijk kan je ook niet alles weten wat er in de testwereld gebeurt, dus speciaal voor de lezers van deze blog een link-overzicht van de genoemde onderwerpen van Lee Copeland waar je eens lekker je testkennis kan ophalen over de laatste trends. Hierna ben je weer goed up-to-date. Het zijn allemaal korte stukjes, maar bij elkaar toch wel wat leeswerk. Dus mijn tip: kom af en toe eens terug bij deze blog en lees elke keer wat over een onderwerp.

Context-driven School
Voor dit onderwerp op testgebied verwijs ik graag naar http://context-driven-testing.com/

Checking vs. Testing
Voor dit onderwerp een link uit de goed gevulde blog collectie van Michael Bolton: http://www.developsense.com/blog/2009/08/testing-vs-checking/

Crowdsourced Testing
Op deze site kan je gaan testen en verdien je geld per bug die je vindt. Dit is Crowdsourced testing. Maak het zelf mee op: http://www.utest.com/

The Weekend Testers
Oefen je testvaardigheden in het weekend, samen met andere testers op http://weekendtesting.com/

Exploratory Testing
Nee, exploratory testing is niet hetzelfde als error guessing of monkey testing. Een PDF bestand van James Bach uit 2003 (!!) over wat exploratory testing is: http://www.satisfice.com/articles/et-article.pdf

Test-First Development
Een onderwerp waar ik zelf ook nog niet in thuis ben, maar je kan er hier wat meer over lezen: http://www.extremeprogramming.org/rules/testfirst.html

Acceptance Test-driven Development (ATDD)
Wordt tegenwoording ook wel “Specification by Example” genoemd. Vind hier iets over dit onderwerp: http://testobsessed.com/blog/2008/12/08/acceptance-test-driven-development-atdd-an-overview/

Wil je nog meer informatie dan zijn de boeken van Gojko Adzic zeker aan te raden.
-    Bridging the communication gap
-    Specification by example

Really Good Books
Er komen steeds meer  goede boeken uit over testen. Zie een recommended sectie in de Testevents.com boekwinkel die ik (en ook vele andere testers) aanraad om te lezen.

Big and small Testing Conferences, (Small) Testing Workshops
Misschien vind je het wat vervelend worden, maar ook voor een overzicht van testevenementen verwijs ik je graag door naar de site www.testevents.com  In Nederland zijn best wel veel testevenementen die je kan bezoeken.

Freedom of the Press
Hiermee doelde Lee Copeland op de vele blogs die geschreven worden. Iedereen kan zijn verhaal vertellen over testen en hoeft daar niet voor naar een blad, krant of enig andere uitgeverij. Een lijst van 100 testblogs: http://www.testingminded.com/2010/04/top-100-software-testing-blogs.html

Reading a testing blog every day, keeps the boredom away... :-)

Open-source tools
Ook het gebruik van bevindingen-, testmanagement- en automatische testuitvoer tooling hoef je niet meer duizenden Euro's te besteden. Zeker niet in kleinere teams en bij het wennen aan testtooling. Hier een website met een uitgebreid overzicht: http://www.opensourcetesting.org/

Virtualization
Niet meer zeuren om een OTAP straat, maar gewoon zelf een testomgeving aanvragen en opbouwen: http://www.soasta.com/cloudtest/
Ik heb hier zelf overigens nog geen specifieke ervaring mee, gezien ik al een paar jaar in de infrastructuur wereld zit en het daar tegenwoordig op neer komt dat ik de cloud zelf aan het testen ben.

Testing in the Cloud
Maar goed, testing in the cloud. Veel testers zijn druk op zoek naar de juiste manier om in de cloud te gaan testen. Hoe verandert deze technologie het werk van de tester? Ik begon deze blog met een verwijzing naar het testevenement van Polteq. Zij hebben net een boek uitgegeven: Cloutest 

U bent weer helemaal op de hoogte
Bent u hier doorheen gebladerd, of heeft u de tijd genomen om de diverse links te bezoeken. Dan bent u weer helemaal op de hoogte. Misschien heeft u zelfs wat ideeën gekregen hierdoor. Het vakgebied van testen gaat verder dan de dagelijkse werkzaamheden en als er ook maar één vakbroeder in de IT is geholpen met deze lijst dan is mijn dag weer goed.

Waarom zou je naar de Dutch testing Conference gaan?

Hoe kies je het juiste testcongres om heen te gaan?
Er is veel keuze in congressen waar je heen kan gaan als tester. Er zijn steeds meer testevenementen over de hele wereld en het worden er elk jaar weer meer. Testers proberen van elkaar te leren en kennis te delen via deze evenementen.

Waarom ga je naar een testevenement?
Voor veel mensen zal de belangrijkste reden zijn om te netwerken, maar daarna volgt de inhoud van de presentaties. Als je er wat van kan leren is dat mooi meegenomen. Een derde reden is het discussiëren over de presentaties. Napraten over presentaties en over testen in het algemeen, met iemand anders dan je directe collega. Ik noem dit niet direct ‘netwerken’, aangezien het hoofddoel hierbij niet het leggen van contacten is.

Wat zijn mijn eisen aan een testevenement?

• Interessante presentaties 
• Interessante mensen, niet alleen testers, maar ook andere disciplines 
• Genoeg ruimte om rond te hangen en te converseren

Het volgende evenement waar ik heen ga is bijvoorbeeld “The Dutch Testing Conference” 

Één van de zaken die mij aanspreekt bij dit evenement is het feit dat testen benaderd wordt vanuit het perspectief van een klant, een eindgebruiker van de testmethode zo te zeggen. Niet alleen testers van grote consultancy bedrijven die praten over de laatste ontwikkelingen, maar ook verhalen vanuit een andere perspectief. Wat minder theoretisch en meer praktijkgericht. Betaalbaarheid, locatie Verder is het een betaalbare dag, wat natuurlijk helpt om een keuze te maken. Lekker dichtbij in Nederland helpt erg goed.

Dus de interessante bedrijven en mensen zijn er en de prijs en locatie (Bussum) zijn ook pluspunten wat mij betreft. Parkeren bij dit evenement is ook geen probleem. En dan de ruimte om rond te hangen en te converseren. Ik ben afgelopen jaar naar de “Agile Testing Days” geweest. Daar was het heel goed vertoeven, veel zitplaatsen en hoekjes waar je terecht kon. Ook dit geldt net zo voor de Dutch Testing conference.

Het programma
Het programma van de Dutch Testing conference is best wel groot, vijf tracks tegelijk, waarvan twee commerciële tracks. De onderwerpen dit jaar zijn agile testen, de cloud, organisatie en business. Niet echt verrassend, maar het zijn wel de onderwerpen waar iedereen het over heeft vandaag de dag. Er zijn nog wel veel presentaties van ´test consultancy bedrijven´, maar ook veel mensen uit andere organisaties, de eindklant. In het programma zie ik Ebay, Nederlandse Politie, de Rabobank en een hogeschool. Hoe pakken zij testen aan? Volgen ze een bepaalde testmethodiek of gaan ze hun eigen weg. Wat werkt het beste?

Gojko Adzic komt ook!!

En dan is er nog een hele interessante key note dit jaar van Gojko Adzic! Voor wie hem nog niet kent: Als je aan het twijfelen was of je naar de Dutch Testing Conference zou willen gaan, dan is dit alleen al een goede reden. Gojko heeft nieuwe en zeer praktisch toepasbare ideeën voor het verbeteren van kwaliteit in de IT. En hij kan zeer goed vertellen met veel humor. Veel mensen in de IT zijn al geïnspireerd door hem. Hier een interview met Gojko Adzic.


Wat mij betreft al genoeg om mij de gehele dag te vermaken, en dan vraag ik me af, wat is toch die Super-Brainstorming Session om 16:00?

Nog wat meer over nadenken: wat is een goed testevenement?
Ik onderhoud ook een website, www.testevents.com, waar ik een wereldwijde kalender bijhoud van testevenementen. Toegevoegde waarde aan deze kalender zou zijn om bepaalde kwaliteit eigenschappen aan een testevenement te kunnen geven, zodat het uitkiezen van het juiste evenement wat makkelijker wordt als potentiële bezoeker. Maar het specificeren en indelen in bepaalde groepen moet ik nog wel verder over nadenken.

Dit artikel was een eerste gedachte hieromtrent, waarbij ik gebruik maakte van een praktijkvoorbeeld. Heb jij misschien ideeën hoe ik hier het beste naar kan gaan kijken? Laat het me weten!

Everybody should test.

We have the professional tester who is trying to make an overview of all aspects of software and create their own plan. The tester plays the ears and eyes for all. But with interchanging information and views, a lot of information is lost, simply because of communication between people is always distorted. Everybody translates their ideas to their own perspective on the world, and the tester or test team will also do that.

So everybody should test. What do I mean exactly with “Everybody”? At least I mean all IT people should test. Test their own work, test their colleagues work and not be afraid to make and recognize errors we all make. As we are human beings and humans make mistakes.

The software developer that creates software is the best person to review code and test the smallest units of software. This is because he or she knows the code, knows how programming patterns work and knows how to program some automated checks for this level.

The user tests the way he or she likes to work, she knows what the daily work is, how customers are satisfied, how the process works with information from a phone call, email and how the digital shopping cart is handled in their line of business. She knows the domain of their business and she talks the talk of it.

The designer translated the wishes and demands of the user into a new IT system, or upgrade and should be aware of the product risks that are also introduced with introducing this new software. The risks can be (partially) mitigated by writing these mitigations already in design documentation.

The functional owner of the software can be right in the middle and keep communication open, up and running between the business people and the technical people.
The support engineer can search for possible risks in the new system. Can we support it later on, has it got enough monitoring and logs, can we easily fix things or change the software by configuring it via a configuration file or settings in the software? Is it extendable and compatible with other tools we use? Because this is his focus area, the support engineer is the guy (or girl) that can check this. And also she has the power of knowledge of issues from the past in her incident system. Issues from the past could arise again with new releases.

Conclusion
This are some ideas about testing by everyone. If we in IT (and it is a big and differentiated world) all test our own concerns and views on a new product the quality control could be better than the way we do it nowadays.

So testers, let’s help our colleagues, we are not learning to test at school, but we have the experience and knowledge to upgrade testing to the next level, as part of the daily IT job.