EuroSTAR 2015 – my third day in review

The third day kicked off with Rikard Edgren and his “Growing from a reckless bug hunter to a stakeholder conversationalist”. Rikard’s message was that you need earn respect by finding valuable information. Tester’s are in the information business. Testing is never better than the communication of the results!


Rikard described his way to become context-driven in three major steps. It started with his biggest mistake. He and his team found 30 bugs, and they were proud. And they wondered why nobody came back to them with a response. The reason was that they were context-unaware and failed to understand the real testing mission.
Second step was the poster story. Rikard and his colleagues published the famous poster of quality characteristics, I have it hanging next to my desk myself, and they felt as context-hipsters. His tip was to use the poster for finding test ideas and James Bach’s list for test strategy purpose.

But Rikard was not happy with the poster because it uses his namespace. His new approach suggests, start with a blank page and ask the stakeholders what is important for them. Use the customer’s words.

The last step is “The Conversationalist”. Rikard is doing more talking than testing nowadays and values information pull over information push. You have to adjust your language to the stakeholder, and invest the time to find out that you know you are testing the right thing.

Explain your testing, why are you testing and why is your test strategy good? Anchor you test strategy, often the test report is not the problem, it’s the strategy that is not understood.

My takeaways from that session are, that I am not the only one who made mistakes due to misunderstanding the mission. In my opinion it is important for a tester to speak the languages of the parties he is working with and that the tester is able to translate from his language/namespace to the stakeholders namespace. Rikard fortified my opinion.


Next on my list was Geoff Thompson talking about “Test Process Improvement – How hard can it be?” The talk was mostly about change, and why it’s so hard to improve your test process. I liked the statement “It seems to be easier to keep paying people doing things wrong.” The key messages of the talk were taken from John Kotter’s book “Our Iceberg is Melting”. There is also a nice video available.


The Dunning-Kruger effect is important to consider when going through change. The unskilled overrate their abilities, while the skilled underrate them. And there is also the dis-organized people accept change with open arms while organized people already think they are effective.
At the center of every process and every change to it stand people and culture. And there will always be someone in a change project who says: No! As change manager you have to concentrate on those people to be successful.

My takeaway was that “change is difficult”. Well, we are humans, ain’t we, and we don’t like change.


It was time for the next “Soap Box Session”, and it was my buddy Dan Billing up on the box. Dan gave a shout-out to the Weekend Testing Europe chapter, which is a great institution to improve your testing. So far I only joined Weekend Testing America sessions, but they are all worth attending. I can only affirm Dan’s statement: “Join Weekend Testing!”
It would not be Dan if he talked only about a non-security topic. So there was a second part. And it was about EXTERMINATE! Dan’s Dr. Who favorite villain related mnemonic about security testing!



Next up was Michael Bolton and his statement “No more exploratory testing!”. I have read Exploratory Testing 3.0, so I new roughly what was coming, but still it is a pleasure to see Michael on stage. That was obviously the view of many, because the auditorium was packed.

The beginning of the history of testing was very much confirming my experience of the past 13 years as a tester. In 1972 there was the book “Program Test Methods”, it was trying to structure testing and it ignored completely the human aspect to testing. Testing became confused with its artifacts. Testing became over-formalized by processes (see also the latest attempt: ISO29119), and testing was all about the test cases. Since computers are procedural, so have to follow procedures to test it.
It was also the time that “ad hoc” and “exploratory” got confused and many mix up “unscripted” with “unstructured” when talking about exploratory testing. Michael’s article “Testing without a map” shows that Exploratory Testing has a lot of structure. The key elements of exploratory testing are freedom and responsibility. Scripted testing is controlling the tester from the outside. And people seem to forget, that you need to do exploratory testing first to get to scripted testing.

We have to relax our degree of description to follow to give testers the freedom and responsibility they deserve to fulfill their tasks. And we always seem to forget, that there is no other cognitive profession using cases to frame and describe their work. And very important, don’t confuse checklists with test cases.

So the conclusion is, all testing is exploratory, so you can skip the “exploratory”. And “scripting” is just an approach.


My takeaway from this talk was learning about the background why in my former company, which was heavily iSTQB- and waterfall-driven, exploratory testing had a bad reputation: 1) they simply did not understand it, 2) they tried to reduce the human factor. Which can also be seen in the naming: Test Factory!
My second takeaway is that my approach of the last 2 years to start with heavy exploratory testing and then produce correct and useful test scripts for regression testing purpose was correct. Only some know why I had to abandon it, and I won’t state it here.


And we came to the closing keynote “Wild West Security” by Paco Hope. Paco designed his metaphor for his key message based on the famous western movie “The Magnificent Seven”. He described seven roles of an IT project who all have their responsibilities for security and have to contribute to it. All roles have certain specialties that make them predestined to contribute to security. He described how Testers, DevOps, Product Owner, Project Manager, Architects, Developers, and Security Specialists can help with making their product secure.


The key message was: “Everyone who has something to do with Software has something to do with Software Security”.

It was a fun metaphor to show how everyone can and has to contribute to software security. And my key takeaway is to learn more about security testing and aspects I need to be aware of.

The ladies from the test lab took the stage:


Carly, Adina, Jyothi, Susan, and Guna made a fantastic job in providing challenges and riddles, hosting a wonderful area in the Expo where people could meet, discuss, and learn. Thank you lab rats! You did a fantastic job!

Then it was time to announce the next destination and the next conference chair for EuroSTAR 2016. And it will be in Stockholm from Oct 31st – Nov 3rd, with conference chair Shmuel Gershon! In my opinion two excellent choices!


And it was time for the do-over session. Attendees could vote for sessions that they wanted to see, to see again, or wanted others to see it. And it was a session I missed on Wednesday and wanted to see, lucky me. Julie Gardiner was talking about “Survival Skills for Testers”. That was my session of day 3, why I described it in an extra post.


To conclude a wonderful experience I went last to conference chair Ruud Teunissen’s “How to share your lessons learned”. I shared with you already a lot of information and insights of the 3 days of EuroSTAR, next will be my team.

Thanks for staying till the end, I hope you like my review of day 3 of EuroSTAR.

EuroSTAR 2015 – my second day in review

Day 2 of EuroSTAR 2015 kicked off, of course with the Ruudmap of the day, by conference chair Ruud Teunissen. The day was packed with one keynote, 24 track sessions, and “Lightning Strikes the Speakers”.

The keynote of the day was delivered by Jeffery Payne about “Test Automation. The DevOps Achilles Heel.” And in reference to yesterday’s keynote that was all about the future, DevOps is already here! DevOps is a philosophy to get everybody on the same page and to foster collaboration and communication. The statement “we can’t apply DevOps here” is just an excuse for Jeffery, because he saw the DevOps approach work in many different environments.

The essential conflict of Dev vs. Ops is, that devs have the desire for rapid rollout, while the ops people have the desire for stable conditions. As in yesterday’s talk from Sujay, Jeffery described Continuous Integration and Continuous Delivery as his key elements for a successful DevOps approach. Whereas the other CD thing – continuous deployment – might work well for some big companies and also lots of small ones, that component does not suit many.

IMG_3768 IMG_3773

Automation of everything along the chain makes it possible to “fail fast” and saves time on time-consuming activities, that can be better achieved by a machine or script.

“DevOps is the best thing that ever happened to testing.” I am not so sure about that. In the overall process of software development the DevOps approach forces collaboration, which is good for testing. Because most issues in a project are interpersonal and are not due to technical issues.

I found the “Test results are “blinky”” slide funny and sadly true in too many cases. But the ability of DevOps tools to create fancy and blinky test reports does not improve the situation that management doesn’t understand what testing is. The communication between testers and management needs to be improved and not be misrouted via blinky reports, just because you can.

One of the closing statements was that you can start running more automated tests. But do I really want to that? Why can I not use the tests that matter most and abandon the rest, because they will be difficult and expensive to maintain. After the test run, you need someone to interpret the results. Good testing is not that you simply count on passed tests and pass the quality gate to the next environment.

Overall I had mixed feelings about the keynote. It was a solid overview of the elements of DevOps, but especially towards the end I found that Jeffery was sending the wrong signals what DevOps is doing to testing. It might still be the best thing that ever happened to testing, but if so, then for some other reasons. At least from my point of view.

Next on schedule was the track session from Paul Coyne about “Everything I know about testing I learned from the scientific method”. I wrote about this experience in an extra blog post.

I had the honor that Michael Bolton took some, well not only some, but about 2 hours, of his precious time to review one of my upcoming blog posts. And the discussions we had in the test lab during the review, also with other people, like James Lyndsay, were intense and fantastic. I missed two track sessions due to that fact, but I hope everyone understands that it was for a very good reason.

I will end writing for tonight and continue tomorrow. Stay tuned for info about the ISO 29119 discussion track, Kevin Harris’ “Top 10 Mistakes Testing in Agile”, Grace O’Mahony’s “just one slide inspired me to be a better coach for testers in Agile” and the really intense but insightful “Lightning strikes the Speakers” session. And of course some photos from the Conference Awards Dinner.


During the lunch break I met Alan Page and had the chance to thank him for his inspiring podcast and the ideas he and Brent are sharing. If you haven’t listened to them before, do so now. They deserve a fourth listener. It’s great content.

After the lunch break I was going to the “Let’s talk about the ISO29119 Standards” talk/discussion. To be honest and frank it was a bit disappointing. The introduction was, due to the short amount of time, too shallow for the audience that had not heard about the standard before. When the questioning round was open the expected suspects raised their hands. The first question came from a person, whose name I sadly did not get, who was the first person I ever met who was actually using ISO29119 and likes it. His question was about a problem, that he struggles with the many “test plans” the standard describes, and if there isn’t a better nomenclature to name the different documents to produce. And there a lot of documents titled “test plan” something in the standard. After that Iain McCowatt asked for new evidence that proofs the standard to be correct, as mandated by ISO for a standard to have to be accepted. But it seems that part is still missing, and still the standard got accepted so far by the board. Michael Bolton questioned the standards that were used to produce the standard, and Karen Johnson asked a most fascinating question – at least for me – why are Anne Mette and Stuart are engaged personally professionally in creating such a standard. When speaking with Karen afterwards, which was an inspiring experience in just 5 minutes, she summarized the answers very well. They saw the different directions testing was heading (both have many years of experience) and feared the unstructured chaos the world of testing became over the years, and they wanted to bring structure back to chaos.

The session was a bit disappointing for me, the discussion part was rather unstructured, and I missed information actually showing that the standard can be helpful, besides creating huge amounts of documents. And I stay with my statement, for what they intended to do, why not create a body of knowledge, like the PMBoK. You can have all elements and simply pick those you need or want, without having a huge bureaucracy of justifying why not to use several parts of a standard. Stuart answered that question for me months ago with, “because the ISO doesn’t produce BoK”. My question today would be, did ISO ask Stuart to write a standard or was Stuart asking ISO to create one? Is there really a need for that standard in form of a standard?

And to conclude for now: As long as bugs don’t obey to standards, why should I?

Next up was one of the many NewVoiceMedia speakers, Kevin Harris. Sadly I missed Rob’s and Raji’s talks earlier that day. The room was packed, people were even sitting on the floor.
I thought about writing an extra blog post about Kevin’s experience report and his lessons learned, but that might give away a bit too much for people who want to see that talk in the future. For me it was an interesting talk from two different perspectives. The presentation itself was well crafted, with the right amount of slides, the right speed and a balanced amount of information for a 45 minute talk. I don’t know who influenced whom, but it reminded me a bit of Rob Lambert’s talk from NTD earlier this year. Since they are colleagues, the idea might not be that wrong. The show was really good!

Now to the content. The topic was about Kevin’s “Top 10 Mistakes Testing in Agile”. In my current projects we are far from Agile and the first ~10 years of my career was pure waterfall. So I have no personal experience with Agile in any form. All I know about Agile is from talks, articles and discussions. So I was looking forward to see what could go wrong with Agile. To give a short summary, the important takeaways described some of the basic principles of Agile and SCRUM projects, as far as I know theoretically. But it was interesting to hear the examples Kevin gave, why it went wrong in the first place, when they should’ve known better.

Value the kick-off and ask all the questions, especially as a tester. Put EVERYTHING on the Kanban board that needs to be done in the project. Make stories as small as possible to decrease the complexity. Outsourcing testing, especially into a different time zone, increases cycle time and silo thinking, which brings us back to waterfall. So keep your team together. Which was also the next message. Try to keep the team stable.  Let developers automate the checks. Communication is key and can save you valuable time. Don’t do more than necessary. Share responsibilities and tasks, don’t create key players. For Agilists that should be nothing too surprising, right? Well for waterfall, V-model, and whatever-not-SCRUM people, this is often like the complete opposite of their reality.

Well that was only nine. The 10th takeaway was that testers should not brag about the bugs they found. For me that would mean a rough change in motivation for many testers. Yes, we should shift left and find the bugs as early as possible, but why should we not be proud that we caught some? I think I will ask Kevin to find more about it.

And then it was time to hear Iain McCowatt stand up on the Soap Box and give his version on the topic of ISO 29119. I hope it will be soon available on the TestHuddle. I will update my blog as soon as I know it’s up.

Next on my agenda was Grace O’Mahony and the topic of “Just one slide inspired me to be a better coach for testers in agile teams”. To be honest I did not expect much more than one slide, but it was a whole more. Grace told us her experience about introducing 20 teams to Agile and their different problems and how she was able to overcome them. “The slide” was from Fran O’Hara from his talk about “Acceptance Testing in Agile – what does it mean to you?” Sadly the slide was not at the center of the presentation, and Grace went pretty quick over it. She described auditing her teams and realizing that the testers were not as proactive as they should be in an Agile context. The result was even that most of the teams categorized themselves as A or B. They had to accept that change is slow, but they got through the transformation, released the stress from the testers and had more happy people. All in all, Grace presented her success story on how the model from Fran O’Hara helped her to improve her teams. I would have liked to hear more about THE slide, what was the key element that made her realize how to benefit from that and how it changed her approach. The presentation had lots of slides and Grace was rushing a bit through them. For me the title was a bit misleading. But that’s just my view.


After a short visit to the TestHuddle and the Testlab people filled the auditorium for “Lightning strikes the Speakers!”

The show started with a special ensemble. I’ve made a video, but still need to edit it. It will be published here soon.

“Lightning strikes the Speakers” are seven speakers with 5 minutes each. If the 5 minutes are out and the speaker is still speaking, he is struck by lightning, and yikes, that was loud. The topic was “Testing in the year 2030”.

Iris Pinkster – from team *T*E*S*T – Clinic – started with the “Human Factor”. Humans are good at throwing things over the fence, but in Agile / DevOps approaches you have to work together. So think up a new process and realize that you are a team!

Jeffery Payne referenced to the opening keynote and the future of testing the Internet of Things. It will be the age of non-functional testing. 1. Fault Tolerance, 2. Robustness in Error-handling, 3. Privacy

Derk-Jan de Grood‘s message was, that we have to improve our testing. In Agile the responsibility is placed low. And before he was struck by lightning he asked the important question, is testing at the level we want it to be?

Michael Bolton was criticizing that we are sloppy on thinking and that testers and managers don’t communicate well. Exchange “verify that” with “challenge the idea that”, and “validate” with “investigate” or “look for problems”. Many testers are demoralized by management and processes, and are not curious and playful anymore. Change your language and improve your communication.

Rikard Edgren’s topic was that tester’s bring new perspectives and ideas. He described his first assignment, where the developers were all trained on the same academy. Rikard studied philospohy and other non-IT-related topics. Rikard was the first one to bring new perspectives to the project. Rikard challenged all testers “what are the new perspectives we will find?”

Rob Lambert‘s view into the future was that by 2030 there should be more qualified people to hire. He has the problem that it’s hard to find good people today. And he presented us his “10 things to improve”.


Last, but not least, Kristoffer Nordström predicted that in 15 years most testers don’t work in testing anymore. Because we get what we pay for, and a low price brings you low skills. But testers in Agile need lots of skills. Cheap outsourcing is the norm and there are many bad/non-thinking testers out there. Kristoffer’s dream is to hire sapient testers and companies should invest in their people, also to reduce turnover. Companies need to change from quick wins to long term investment in their people, who take pride in building skills.

The keynote with its seven messages was very intense and had great messages.

At 6.45pm the buses left for “La Caverne” in Valkenburg for the EuroSTAR Conference Awards Dinner. A nice restaurant located in a cave, yes again in a cave. The caves were full, dinner was delicious, and there was plenty of wine. I had the honor to share my table with Carly Dyson, Kristoffer Nordström, community-report Nick Shaw, Paul Coyne, and Iain McCowatt. Folks, I enjoyed the passionate discussions, it was fantastic!

And the winners are:

Best Tutorial: Rob Lambert

Best paper: James Thomas

Tester of the Year: James Lyndsay

Well deserved!

The evening was fun, but after ~19 hours I was glad the day was finally over.

EuroSTAR 2015 – my first day in review

This is just to say, that I had a first great day at EuroSTAR. I was meeting a lot of old and new and brand new people. Sometimes you realize how small the world of testing is, and sometimes how big it is.

Thank you to team EuroSTAR. It’s a wonderful experience after only half a day.

Don’t worry, I will write more about my first day. But first I need some sleep.


I am writing this about the first day even if the second day is just coming to an end.

After about 6 hours of travelling I arrived at the venue, registered and met the EuroSTAR team the first time in real live. I am thankful that you gave me the chance to join you here in Maastricht.

When I turned around I ran into Richard Bradshaw and Huib Schoots and went to lunch with them, so my first contact with the conference was a bit delayed, but it was good to start with some familiar faces, even if it’s Richard and Huib. Just kidding.

Then I went down to the Expo and tried to get sorted where the Testlab is, where the Community Huddle is, and trying to meet some of the people I wanted to say hello to, first time in real life. The location was nicely chosen amidst all the sponsors in the Expo, which made it a humming place all day, even during tracks, when most people were enjoying the talks. EuroSTAR is my first bigger conference (of only two overall, so not much to compare with) and it was amazing to see so many people involved in software testing in one place.

At 1:30pm the Conference part of EuroSTAR officially started with the introduction by Ruud Teunissen and the keynote from Richard van Hooijdonk. You can read about that here.

After that I went to meet more people some again, some for the first time in real life. And I met the Community blogger Colin Cherry, or should I say Klaas Kers. It was wonderful to finally meet Colin in person. He is such a wonderful and insightful person, it was a pleasure to meet up with him every now and then during the conference and exchange thoughts on what we just experienced. You can read Colin’s blog posts all on the TestHuddle.


Then I was off to “Can Testers Lead DevOps Adoption? Yes We Can!” with Sujay Honnamane. He gave a short overview of the key elements of the DevOps approach, and it is a lot to conquer. But how do you eat an elephant? One bite at a time! So you have to start somewhere and implement the tools and automate the processes. Sujay described his challenge with his team, that sounded like a scenario that could happen at my place as well, and it happened at several other places already, from what I heard from speaking with other testers. But the ecosystem of a DevOps environment is quite complicated and you have to get the most out of it. Sadly he ran out of time, so several agenda points were not covered in the talk. But I am looking forward to the slides to read some more and find out more about the tools used in DevOps. All in all a good DevOps talk, but sadly delivered only half of the promised content. But with not much background knowledge about DevOps it was a start about the components, approaches and common struggles with DevOps.

As a tester working in an environment with nearly no automation, it sounds like a lot to change and introduce. But it would be interesting to make an analysis of what we gain with such an approach and what we would loose.

After spending an hour in the testlab to mingle with the wonderful TestLabRats I enjoyed the keynote from Kristoffer Nordström about “Kanban Testing and Lego”. You can read it all here.

It would be not a testing conference, if it would be over after the closing keynote of the day. About 4 buses full of people went off to Château Neercanne, a one-star restaurant placed in a 17th century castle. It was a lovely location, dinner was delicious, and I enjoyed chatting with the great folks at my table. And I learned some new stuff about kosher food that evening, thanks to sitting vis-a-vis of Shmuel Gershon.

After writing my two keynote blog posts, a long and eventful day ended. Stay tuned for more about day 2.

IMG_3748 IMG_3750 IMG_3753 IMG_3754

EuroSTAR 2015 – Second keynote about “Testing Kanban and Lego”

The second keynote of the EuroSTAR day 1 was Kristoffer Nordström‘s talk about “Testing Kanban and Lego”. A very promising topic and to give it already away, the promises were fulfilled.

Kristoffer describes himself as a Test Developer who loves to automate, so that testers can focus on quality human testing, and he is utterly fascinated by the human side in software development. He has a favor for the humanistic approach, and he presents us his heros, who can be characterized by “putting the people first”. My photo does not reveal all the names and the big hero in the middle is missing: Jerry Weinberg, but from the pictures you might recognize them all.


The story Kristoffer was about to tell us from his personal experience needed some more introduction of the humanistic approach. “Software Development is a social activity.” – Jerry Weinberg.

And he described to us what he calls the Human Software Development Manifesto:


After setting the context straight for everyone his experience report began. Years ago Kristoffer worked for a telecommunication provider and back then every department had sort of started building their own test framework. Most of them ending up unmaintained and barely usable. When the need came up to create non-functional tests, he and his team created a generic test framework for non-functional tests. But it took time until it was accepted, which was at a time when he already had left the company. But it found acceptance, and short story even shorter, Kristoffer went back to that company to take over again the non-functional test framework.

The situation he found was not very promising. There was no successful build within 5 months, technical debt has piled up, the simple approach of using text files was changed to using Java instead, and users were disillusioned. But he took the challenge, built up a team and conquered the mess one by one.

They repaired the build system, they implemented continuous integration and continuous deployment tools, and they were able to produce stable builds and over time increasingly stable nightly builds. The backlog was trimmed to what really still mattered, and while they were at it, they introduced Kanban.

The approach worked, the framework became more popular and testers became engaged. To get them even more engaged, Kristoffer introduced gamification, which added a new level of engagement.

The Kanban board is made out of Lego tiles. Every team member has three same figures of his choice. There was a price-limit though, because we learned that “Darth Vader” is very expensive. The photos looked really cool. Sadly I did not take a good one.

But management wanted them to use an “Agile” tool they dictated for the whole company to use. And since the tool was horrible to use and for Kristoffer’s team a waste of time, they invented something really fun, geeky and nerdy. With a Raspberry Pi, a webcam and OpenCV there were able to capture their Lego Kanban board every 5 minutes, register which Lego figure is doing which task, in which status, and sending an update to the horrible Agile tool via an interface.


For Kristoffer culture sets the constraints, especially in a “It won’t work” attitude he was working in. But he managed to overcome this constraint. His approach was a more holistic systems thinking approach, and a lot of factors influenced the success of his project.



My summary: A brilliant presentation with great timing and the right amount of content. And the moomins can be proud of Kristoffer once again.

The Manifesto he presented, that stands for his view on how software should be developed, is a great example how you can put people in the center of software development and lead a project to success.

Most people I talked with afterwards want to have such a Lego Kanban board. I hope that there will be many created and used.

The factors to success are very important, and if one or two of them fail, the outcome won’t even be half as good. So you have a lot to balance or juggle, but when you do, it seems to be very rewarding.

EuroSTAR 2015 – First keynote about “Trendz 2030”

EuroSTAR kicked off with the nice sounds of Coldplay, setting high expectations for the next couple of days. Ruud Teunissen gave a warm welcome to everyone and showed us how many people were involved in organizing this year’s EuroSTAR besides the EuroSTAR core team.

The first keynote of the day was a look into the future by Richard van Hooijdonk called TRENDZ 2030. For the next 45 minutes Richard showed us several areas and how the future will look like for them.

Richard started with drawing a picture of what a personal RFID chip could mean for you. Not needing keys, passwords or cash and cards with you. Just with a swipe of your hand.

Things that fly are already there. Google is piloting its balloons over Sri Lanka. Amazon tests their delivery drones, and in the Netherland emergency drones with medical equipment already fly in case of an emergency with heart problems. And in agriculture drones monitor your fields and crops.

Robots are getting better and better. Boston Dynamics and others are creating robots that might replace soldiers in the near future. By 2025, Richard says, there will already be Humanoids helping with our daily life. By 2050 robots and machines might already be smarter than people. What happens then? Good question and hard to answer. It might be an answer we don’t like.

Robot Revolution

Healthcare will be the leading topic of the next 5-10 years in the technological revolution. In 5-10 years apps and devices will replace the family doctor. Richard himself will swallow a pill in January that monitors about 160 values of his body and sends those telemetry data into the cloud.

Connected cities will be a big thing on the rise. City lighting wasting enormous amounts of energy on empty roads. Imagine what would happen if the lights are on only, when there are people or cars on the road.

3D printers will make it possible to produce whatever you want at a place near you. What will happen to many factories then?

Richard painted more happy pictures of the Internet of Things (IoT), that show the positive things and amenities the IoT will bring, like the fridge remembering you to buy milk on the way home or even ordering it online and let the car pick it up while you are at work. With the IoT the next big thing on the rise will be and already is the API economy. New businesses will come up with new ideas and business models every day.

And with that Big Data is coming. There are devices, cameras and sensors collecting huge amounts of data. In 2020 there will be four times the amount of data than we have in 2015. And the algorithms using those data are getting better every day. So if you think you are doing big data today, wait for tomorrow, when you will really have BIG data. The algorithms will have so many input that they can tell you more about yourself than you yourself.

Moore’s law, which was suitable for many aspects of the technological evolution, doesn’t count anymore for most areas. The time for doubling is now way shorter than 20 months.

Whole sectors will be disrupted by technology in the next couple of years, like it happened to the photo industry since the invention of digital cameras and smartphones. A few years ago you could not imagine self-driving cars and many more things. They are reality now or very soon. So you need to adapt, but people are not made for change. And change is the only constant factor. The time your skillset is valid changed from 30 to just 5 years. So we also need our education to change.

Richard describes at the end how the company of the future needs to look to handle all those challenges. Small will be the new big.

The future is here!

More about Richard can be found on his website.

So far the summary of an intense 45 minute keynote with pure information overflow. You can see in the page above, just how many topics were covered, that will bring change in the future.
Richard mostly painted a positive image of the upcoming changes that will improve our life. He asked only two really interesting questions about the downside of the technical revolution that is going on.
What happens when robots become more intelligent than people?
What happens to so many factories, when decentralized 3D-printing of lots of things will make them unnecessary?
I would have liked to see some more critical aspects for the future about the changes and inventions he described. So many things can be misused or are against the free will of people? What if I don’t know all these information some fancy algorithms find out, before I do? What if the machine takes away my decision for the food I want to eat? Just because my telemetry data is showing I need something different for lunch? And what about all the downsides, when those things get hacked and misused. How will those inventions influence us negatively? How many people won’t have a job in the future, because we can produce robots for nearly everything, making people unnecessary?
As Ruud put it in the introduction of the second keynote, the good thing for us (testes) is that we need to test all this! And 10 years ago most of these things were unimaginable, but we are getting there.

Going to EuroSTAR 2015 in Maastricht

It’s only 4 weeks now and I am happily looking forward to be part of the EuroSTAR conference this year in Maastricht, happening from 2-5 November. EuroSTAR invited me as media partner / blogger to share my experience with the world. And I can’t wait for the event start.

It will be only my second testing conference, but I am looking forward to meet many of the great people again whom I met at my first one. And I am looking forward to meet lots of new people. Testers that I know only from Twitter or not all yet. It’s the biggest testing conference of Europe, so I have the chance to meet LOTS of people.

The line-up is awesome. It’s hard to decide which tracks to follow. I made a rough plan already where to go to, but I keep my options open to decide onsite where to go. I already know that I will miss other great talks, and with that knowledge it’s easier to decide where to go. From what I see in the program, everything is great. I can only hope that more folks will blog about the talks that I don’t attend.

For those of you looking for a workshop to attend, check out the list of full-day (Monday) and half-day (Tuesday morning) tutorials / workshops. A lot of great names with a lot of great topics are on the agenda! Use this chance to meet and interact with them.

I will arrive Tuesday around noon, in time before the keynote by Richard van Hooijdonk kicks off the conference part of the event. It will be a look into the future of testing. That’s it for now with my look into the future. Watch this place for updates, especially from November 3rd on!

Thank you Team EuroSTAR for giving me this fantastic chance. Can’t wait to meet you now.

QA people are not testers, or are they?

The world of software companies is full of testers and test departments named as Quality Assurance. There is a long ongoing quarrel if QA and Test is the same or not. Long story short, no they are not the same! But a person working in QA needs a lot of skills a good tester has.

My official job title is QA Lead, but I deliberately use the term Test Lead and have it proudly in my signature. Because that’s what I am doing, and that is even what my job description says. Calling software testers by the name of quality assurance implies for many that there is a step in the “production” process that assures the quality. And this is wrong!

Quality Assurance is a term coming from the world of manufacturing. People working in Quality Assurance are monitoring and auditing the production process and keep an eye on it, that everything is done accordingly to the pre-defined process models, that describe the current best way in the eyes of the company to produce this item, whatever it is. That way you have a rather good chance that the quality of each item that leaves the factory is as similiar as possible and fulfills the company’s standards. You can also see the Wikipedia articles about Quality Assurance and Software Quality Assurance.

In my view on this topic, people working in Quality Assurance are testers, but they don’t test software or a product, they are testing processes and process models. The skill set you need is similiar to that of a good tester and much more (skills that don’t do harm for a tester either). You need to collect information, analyze processes, audit and inspect projects, create models, monitor quality gates, ask lots of questions, and inform a stakeholder of the situation you found. But you don’t test software.

Software Testing is usually one or more steps in the software production process, and Quality Assurance will make sure that these steps are included and followed in the process.

In my eyes there is a problem with using terms and roles derived from the manufacturing industry in an IT context. Software development is unique, you don’t produce the same software twice. Software development, either called product development or project business, all are projects, and one of the ground-rules for projects is, they are unique! Using industrial/production terms doesn’t help in many cases, because it is so different. It creates an illusion that can only be realized by either hard planning and meticiulous management of the project or by serendipity. Believing that standarized process models will create the desired results every time is in my opinion dangerous to the business.

The process of producing software consists of many steps and a lot of roles and parties are involved. And each and every person has the responsibility to perform her steps in accordance to the defined rules, process models, standards or whatever has been decided to follow. Developers usually produce a certain amount of common rules to follow when producing code, like style guides, naming conventions, code reviews, rules for writing unit tests, and way more. In the first place it’s the developers responsibility to follow them all. But there is in some or maybe even many companies a department called Quality Assurance, that should regularly send someone to audit the process, make sure all the rules are followed and look for steps to improve based on the feedback they collect.


People woking in Quality Assurance need a skill set that overlaps a whole lot with that of testers, because they are testing processes. If your job is testing software, you are not part of the Quality Assurance team, you are a part of the Quality Assurance process.

So I want to close with statement which is the title to a blog that just came to my mind, while I finished my article. Testers get out of the Quality Assurance business!

What I learned from my RC-model car about testing

There are a lot of stories out there from testers who compare their hobby to testing, and what they learned from their hobby about testing. Today I want to tell you what I learned about testing from driving and repairing my small RC-model car: Nothing! Absolutely nothing!

The message might irritate you, but I can tell you why. When I am driving my RC-car I have fun watching a 30cm (1 foot) plastic car making about 50+ km/h (30+ mp/h) and making squeeking turns on asphalt. If something breaks, I have to repair it. Since I don’t have a 3D printer or a CNC lathe and mill, I have to simply buy the spare parts and exchange them, when they break. I don’t want to tune or pimp my RC-car. I maintain it as good as I can, I recharge my LiPo-batteries, and I have fun driving the little thing. It’s a few minutes every few weeks, that I pull that thing out, and do something with it. And I don’t think about testing in that time. It’s called relaxing.

Testing is a discipline, that is using so many skills, way more than anyone can ever conquer. Just look at some of the skills inventories that contributors to the testing world have published.

Skills range from technical skills and knowledge, thinking skills, scientific methods, technical knowledge, coding, communication, organization, and many more. So whatever you do outside of work in your spare time or as volunteer that needs one of the skills that is on the list for testing, you practice a skill that you could also use at your work place. Which is good.

But there is also another important part: Relax! If everything around you that’s going on reminds you of testing, then you can never relax. And you and your brain need time-outs from work to relax and recover. Otherwise you will quickly hit the symptoms list for burnout and other severe physical and psychological problems.

My message for you today is: Relax, stop thinking about testing on a regular basis, don’t think about work. Enjoy life, meet friends and family, do nothing, or buy an RC-model and go out there and have 20 minutes of fun every now and then.


Vaterra Kemora


“Follow up on one idea!”

Being a testing sponge

For the past 3 years I am functioning like a sponge for all things related testing. I read lots of blogs, watched videos of conference keynotes, and piled up several books related more or less to testing and even read some of them. I wrote three articles for testing magazines. And of course I follow my Twitter timeline with many, many testers. I try to do all of that mainly on my way to work and back (each roughly 45 minutes), some things I do in parallel to work, if time allows, and sometimes I read something in the early morning or late evening, shortly after getting up or before going to bed. I am deeply into catching up with testing. I missed too much in my first 10 years as a tester, I have the constant fear to loose this world, that I have discovered.

Recently I was at the Let’s Test conference in Sweden, my first one ever, and it was awesome. Michael Bolton said in a tweet after Let’s Test, that it seems, that I was everywhere, and indeed I was. I was trying to sponge up everything. I licked blood! I want to attend more of those conferences, participate, and feel the atmosphere. And chat with all those fantastic and inspiring people. I had not enough time at Let’s Test to start many deeper conversations, because I wanted to meet more people and learn more stuff.

Too much going on

But it’s getting too much. I am not only busy at work, thanks to an understaffed team, but also at home. Besides my wife and my daughter, there are some renovation projects coming up. And I have several hobbies that I want to pay some attention to.

“Multitasking is the best way to get nothing done.” This is quoted by many wise people, and it’s absolutely true. Especially at work I can confirm that constantly switching projects, switching tasks, attending meetings, taking care of questions from my teammates, administrative stuff, and more is not very helpful when it’s comes to getting things done.

I watched this short interview with Ilari Aegerter with Helena from Nordic Testing Days today. And Ilari said, that his goal is to “Follow up on one idea!” and that he has not decided yet which one. And maybe this would be a better approach for me, to focus on one topic at a time to dive deeper and keep the rest at a more shallow level.

My plan for the near future – simplify

I had this short but inspiring discussion with Pekka on Twitter about how to generate ideas for conferences. Since one of my next big personal goals is to enter some proposals for upcoming test conferences, I liked what Pekka suggested. Draw a 10×10 matrix and start entering ideas for topics. Then elaborate on a few. So currently I am looking in all directions of my portfolio about topics that might be worth a 45 minute conference talk and might – most of all – be interesting to an audience. So much for “following up on one idea” for now.

To be able to maneuver myself out of the misery I am currently in, I need to focus and I need to simplfy my life. So I will re-evaluate some goals that I set myself and try to get rid of some – at least for now.

This will also mean that I won’t be on Twitter so much, and that I will miss an interesting article or two to read. I still hope, that the best stuff is going so viral in the community, that I don’t miss it. I will re-order my book pile. And I will clean up my Pocket again, which shows again over 140 items to read and watch, building pressure.

I will continue on selecting conference topics for a few more days. And once I have collected a serious number of conference-possible topics, I will try to focus on only a few promising topics and investigate those to the best possible level. Maybe some end up only as blog, but who knows.

I will also try not to pick up new hobbies, new areas of interest in testing, and hopefully not too many new books. This will be a hard change in my personal behavior, that I worked so hard on in the past three years. But to find my inner peace again and be able to relax, this is absolutely essential. At least I hope that this approach will help. I will try to schedule a retrospective in a few months and see how it worked out.

My visit to Let’s Test 2015 – Day 3

Waking up a bit early to pack my stuff and check out before breakfast. I am a bit tired, but I guess I also got used to it.

Fun moment of the morning was to receive the newsletter from Testing Circus about the May issue, featuring the guy I spend the three past evenings with playing board and card games. Erik Davis! Great job, Erik!

I had breakfast and a chat with Emma and Dan Ashby. So far I only had the chance to shake hands with Dan.

Jean-Paul Varwijk “ISO 29119”

The last day went by way too fast. I decided to visit Jean-Pauls session on ISO29119, which was a good choice. It was not only good talk, but also a great discussion afterwards. I already knew a big bite before that talk, but I got also a good portion of new information lighting the spirit to fight that standard. I joined in the chorus of Ben Kelly, Iain McCowatt and John Stevenson against that standard, and I hope I helped answering questions of the people from the right side of the room, that seemed to have their first encounter with ISO29119. Thanks Jean-Paul for a great opportunity to refresh and add information there and planning it already with an intense discussion part, and Dan Billing did a great job facilitating the Q&A for this difficult topic.

Alexandra Casapu’s “Examine Your Testing Skills”

It was time for a last workshop. It was Alexandra Casapu‘s “Examine Your Testing Skills”. I worked one last time together with Chris and a new face for me in Michael. Since both were from Switzerland and I am from Bavaria, we decided to speak in sort of German. It was hard not only for me to think and speak again in German after three days completely in English. So we ended up speaking a mixture. I took away lots from that session, if you want to know what, read it here soon. But for now I will share my key takeaway with you, that reflects also on all of Let’s Test. To become a good or even great tester, you need way more than just technical skills. There is so much to learn about communication and thinking skills, which I became a great supporter of in the last 2,5 years. Alexandra’s session showed all the different aspects and skills you use when challenging a problem. And all of Let’s Test was about improving critical thinking, creativity, communication and so many more skills, that usually don’t end up on a skill improvment list. And Alexandra did a great job sharing her experience how to analyze and list your skills, showing so many from us skills that are useful and need to be improved by reading, training, reflection and more. A big thank you to Alexandra for this wonderful closing workshop.

“Testing in the Pub” with Dan Ashby

After a last lunch with Megan and others, I sat down with both Dans (Billing and Ashby) and Christina reflecting the last days. We were sad that we missed the chance to record a “Testing in the pub” session the last days. So Dan pulled out his mobile and we set up a quick recording session reflecting Let’s Test. Thanks Dan for having me as a guest in your great series of podcasts. It’s a real honor. And kudos for setting up a structured episode in about 3 minutes.

It was time for the closing keynote about “Detetecting the heartbleed bug”. After lots of insights in the technical aspects of heartbleed, the coincidence of three bugs coming together and the serendipity of finding it.

I sat on one of those nice couches in the back with some of the great folks that I spend the last three days with. Saying goodbye came closer and since I had to catch a taxi to the airport rather quick after the keynote, I made my round, shaking hands, hugging and patting backs. It was sad to leave after three and a half days after being sort of accepted as part of the big family.

Besides my key takeaway that Let’s Test is about those skills, that make you become a better tester, it is all about the people. I met a lot of wonderful people, I put real life faces to twitter handles, and know I want to meet each and every one again to talk more with them.

One last key aspect of visiting this conference for me was to find out, how a conference talk looks like, and imagine how it would be, to host one on my own. On the way home I already started thinking about topics that I want to present at conferences.  So open up those CfPs, I already found some topics I want to speak about. Beware of the TestPappy!

Good bye, Runö. I hope to see you again next year!