There are some main stream test events, which I cannot ignore. I just need to be there. Enter TestNet Spring Event 2016.

The Dutch Special interest Group in Software Testing, TestNet, had another free congress for his members: workshops, lectures, meals, etc. from 9 am to 10 pm. All for a yearly contribution under 90 Euro, which also includes an Autumn Event, peer meetings, and a congress with sponsored workshops. Did I mention the working parties?
It’s not cheap, it’s good.

Disclosure: I confess that I was a board member of this SIG, your honour.

5 lifehacks in a beginning scrum team

Eric van der Marck was called a first time speaker, who took his listeners with him on his journey through the scrum world. He talked his encounters with end users. He started to walk like a cowboy: “They are wearing a can of pepper spray and a gun.”

In order to illustrate his points he had nice examples with lots of interactions with the attendees. Pairing was useful even with different roles. He asked a programmer during a review about the code. He knew that he would ask irrelevant questions. And still there were some moments of hesitation and insight from the programmer’s side.

He also worked for a Police project. The agents needed a handheld device, which could be used in a simple way. My first reaction was unbelief, until he explained the context. If an agent talks to a possibly dangerous person, he /she wants to watch the person all the time. The same with a victim.

Eric had a preference for good documentation. Not only for the dreaded audit, but also for helping team members. An attendee asked why the documentation was not in the code. Eric responded that the documentation was also used by end users. Then he described the reaction of an agent looking at code.
“The moment I show him code I lose him. [Silence of 3 seconds]
They are smart. [Silence of 1 second]
In other way.”

With all kind of tools available he described, what happened, when test cases are attached to Jira tickets.
“For a regression test you have to browse through all these tickets.”
A rather unpleasant task indeed.
He advocated Confluence for test case administration and Gliffy, an add on for Confluence, to make process flows in order to track the test coverage.

Eric ended the story with coaching. How to make people better scrum members.

Agile Testing Survival Guide

Ingo Philip is an employee of a test tool supplier. I groaned inside. I was sitting in the front row and suppressed my urge to flee to another session. Ingo promised, that he would not mention his company again. I relaxed a bit.

Ingo remarked that there were redundant test cases. The basic cause is user stories, which might have overlapping acceptance criteria. These had corresponding test cases in turn. So he suggested to consider functionality grouped test cases. While blogging I started to miss a process flow test or data flow test.

Next he suggested to look at patterns in the past. Risk analysis was a helpful tool. For each feature good risk coverage should be obtained during testing. In an example some features had risk coverage of 50 %. Nice for statistics, but pretty abstract for me. Then I added all risk coverages of the features and got a result over 100%.

That was the moment to raise my arm for a clarification. Ingo noticed me and delayed the question to the Q & A section.

Heading towards the wall he described how test cases could be weighted using information from the past. He turned the steering wheel a bit by pointing out that deviations could not be predicted. Then unexpectedly he mentioned Exploratory Testing as a good supplement for test cases. ET could address unseen or other risks than test cases. Just missed the wall by a few nanometres.

In the last part of the talk Ingo described a case about a regression test: test case reduction using the previously described method including the risk coverage, automatic test data generation, automated tests in several forms and frequencies. I recognised a pattern of another talk: determine a small set, which can be used for a fastback feedback, and distribute the tests over several servers to reduce the execution time.

At the end I finally got a chance to ask about risk coverage. I picked up factors like frequency and potential damage, then the facilitator stopped the explanation. Ingo gave me an invitation to go to the booth for more information. But I came for the talk. His talk.

So
time to leave the premises. A few things to mulch about. Or blog about.

A few weeks ago I had ordered the afternoon ticket which included the last sessions of the afternoon, a dinner, and the evening sessions. (I am still figuring out, what an afternoon actually is.) A complete day filled with sessions would spoil my appetite for knowledge.
Luckily I was right.

Open Space

One of the strangest elements of the conference was the Open Space. It was a group of testers looking for answers and testers willing to share those. It was a setting requiring special attention and a good moderator. Alex Schladebeck took her role seriously by pointing out the rules (Look mom. Without slides!) and using her candour to illustrate several examples. With more questions than available slots two groups started discussing their questions separately.

Once again I noticed that there was not a single right answer. Looking at the context was very important. Attendees go to a conference to get more insights or answers for questions. And an open space is a safe environment to exchange thoughts with other peers.

Nowhere And Back Again

Thom Bradford is An American in Berlin. He was using cue cards like Gambit. No special effects were used, so the stage was not damaged during his talk. He recalled his last decades as a software engineer, who had some unpleasant experiences. It was obvious that he was reluctant to switch company.

Thom described the symptoms of companies which he tried to avoid: “Monolithic piece of code” or “Working students” assigned to solve bugs. Then he mentioned Drive of Daniel Pink. Good companies looked at

• Autonomy
• Mastery
• Purpose

It led to the following situation. He had to break mastery: he showed Clojure to appalled Java programmers.

Thom had real doubts about code coverage as KPI or Key Performance Indicator. During the presentation he started an automated test, which showed an impressive 100 % coverage and only positive test results. Clean Code and TDD were better than code coverage. This sounded like a SOLID advice to me.  (Pun intended).

The Need For Speed

Emanuil Slavov had somehow dehydrated his ATD 2015 talk to 30 minutes. And he had more to tell than it was humanly possible in the allotted time slot. So the speed was really necessary. It was Flash as a Speaker.

With impressive numbers he showed the reduction of automated tests from 3 hours to 3 minutes.
“Three minutes sounded nice, so we aimed on this limit.”
A lot of measures sounded logical in hindsight like a separate test environment and a test database, which had a minimal set of records. There was also an unexpected (temporary) setback like moving to containers.

Emanuil also referred to three books:

1. The Goal:A Process of Ongoing Improvement
2. Toyota Kata
3. Flashboys

I had read only one. Number 3 was unexpected.

Collaborative Infrastructure Delivery

“This session will be more technical than the previous one.”, Christoph Lukas began.
I smiled inwardly.

Infrastructure as a code has the same characteristics as code. Using TDD he first developed a test. The first test run led to an error. Of course! Nothing was executed or set up. Using a flurry of Xterms (?) he slowly built the desired environment with components.

Workshop previously known as Understanding and testing RESTful Web Services

Mark Winteringham introduced the delegates to Postman, which can be dowloaded for free from getpostman.com. This tool looked to me as a small and compact tool. Ideal to explore the interface.

In the briefing Mark explained, how http is used. He introduced his thoughts about web testing and then encouraged the attendees to go to explore his example web service.

Because of some technical restrictions I paired with another tester. I fell in a familiar trap: test without note taking.
(What could possibly go wrong in 10 minutes? A lot.)
Mark did a debriefing which provided a decent way to catch up with my notes.

In between I discussed the use of SoapUI with another tester. It was a more powerful tool with a subscription.

How we connect to the Internet of Things

In the last keynote at 08:15 in the afternoon Bart Knaack and James Lyndsay had a look at the latest hottest topic IoT or Internet of Things. Or Ignore other Things :). They started to model the internet and then focused on Things.
“This is Thing”, Bart explained.
An orange super hero was shown on the slide.

Then the gentlemen connected an electronic device with the Internet utilising IFTTT or IF This, Then That. This rule based web service was used to change the behaviour of the device i.e. flashing in the assigned colour in the assigned frequency. A Twitter message led to pink flashing LEDs laid out in a circle. It was cumbersome to connect with the smartphones of the attendees. Establishing the right connection for testing was really difficult.

Was IoT really different from other systems under Test? There was no difference with GSM testing on a higher level: protocol testing was demonstrated by 3 processes impersonated by Bart, James, and Alex.

Then I got the message:

• Look at the differences in technologies.
• Find a way to address them.
• Look at tests performed in the past and
• Reuse those test ideas.

And then

I hurried to catch my bus. I did not wait until the last one. This one was big enough for me.