Notebook on table. Showing texts “A Delegate Report About TestNet Spring Event 2016” and “mindfultester.com/a-delegate-report-about-testnet-spring-event-2016”!

A Delegate Report about TestNet Spring Event 2016

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.