Data-driven tests in Junit5.0.0-SNAPSHOT

It’s been a while since I wrote code these days. Back in late April however I found myself in a Coding Dojo at the Düsseldorf Softwerkskammer meet-up working on the Mars Rover Kata. I have a story to share from that meeting. However, since I tried to reproduce the code we ended up with that night, and I decided to give JUnit5 (and Java8) a go for that, I ended up with a struggle.

Back in the days with JUnit4 I used the ParameterizedRunner quite often to use data-driven tests. I never remembered the signature of the @Parameters function, though. The Mars Rover Kata also includes some behavior that I wanted to run through a data-driven test, but how do you do that in JUnit5? I couldn’t find good answers for that on the Internet, so I decided to put my solution up here – probably for lots of critique.

Please note that I used JUnit 5.0.0-SNAPSHOT which is a later version than the alpha, but probably not the final one.

Continue reading Data-driven tests in Junit5.0.0-SNAPSHOT

State of Testing 2016 – My view

Usually I don’t write many promotions for other’s contents on this blog as I try to keep it personal and focused on my personal views. Recently I was contacted on the International 2016 State of Testing report, and whether I would like to do a write-up about it. I asked whether it would be ok to post a personal view, so here it is.

Continue reading State of Testing 2016 – My view

Testing inside one sprint’s time

Recently I was reminded about a blog entry from Kent Beck way back in 2008. He called the method he discovered during pairing the Saff Squeeze after his pair partner David Saff. The general idea is this: Write a failing test on a level that you can, then inline all code to the test, and remove everything that you don’t need to set up the test. Repeat this cycle until you have a minimal error reproducing test procedure. I realized that this approach may be used in a more general way to enable faster feedback within a Sprint’s worth of time. I sensed a pattern there. That’s why I thought to get my thoughts down while they were still fresh – in a pattern format.

Continue reading Testing inside one sprint’s time

Save Our Scrum – Tools, Tips, and Techniques for Teams in Trouble

During the Agile 2014 conference in Orlando, I talked a lot with Matt Heusser. Over the conference we bounced back and forth one or another idea. In the end, we had an idea for a new book: Save Our Scrum. A self-help book on many of the troubles we see out there happening with this wide-spread approach. We had the vision to base some of the lessons we learned in our consultant work, and see how we may help others with this. That’s the whole vision.

Skip forward one year, and we made some progress. We finished off the first few chapters with a more general introduction to Scrum itself alongside with some of the problems we are seeing. At one point we decided to put out what we had created thus far, in order to receive feedback from the people that are seeking such help. That’s why we recently put it up on LeanPub, so that folks can get access to it, and help us continue the momentum with great feedback.

Matt and I are pretty busy in our consultant work. That slowed down progress a bit in the past months. Right now, though, we seem to be in a writing burst with new content created constantly throughout the week. We started work on getting down the nuggets – that’s what we call the little lessons from all over the world with teams struggling with Scrum.

That said, if you get the book now, you will receive weekly updates – that’s what we promise you. Every week we publish anything that we have created throughout the week. We hope to keep progress flowing. I think this week both of us each worked on getting down at least four nuggets. That’s eight new lessons for you to read. If we can maintain this progress, we expect a good draft finished by end of September.

But, wait, there is more. You can get famous by helping us. We opened up feedback channels. We created a Slack team for open discussions. This is not limited to typos and missed commata, but you may also leave us your thoughts on nuggets that we forgot there, or share struggles that you have to improve our book.

We really look forward to your feedback and ideas and suggestions to advance our book. Hope you will enjoy it. And if not… well, at least you know some channels now to let us know.

Working in a distributed company

In my courses, one or more of the participants almost always raise a question like this:

How do you set up a team across many sites?

Almost always when digging deeper I find out that they are currently working in a setting with many sites involved. Almost always they have a project organization set up with single-skill specialists involved. These single-skill specialists are almost always working on at least three different projects at the same time. In the better cases, the remote team members are spread across a single timezone. In the worst cases I have seen so far, it had been a timezone difference of ten hours.

I will leave how to deal with such a setting for a later blog entry. Today, I want to focus on some tips and tricks for working with remote team members and remote colleagues.

Tripit reported that I was on the road in 2012 for 304 days. I hardly believe that since I stayed at home for our newborn son Nico the whole June back then. (I think they have had a bug there.) But it was close. I have worked with remote team members and remote project teams in distributed companies since 2006. I hope I have some nuggets worth sharing.

Continue reading Working in a distributed company

Why you should go to CAST

Last year, when the Association for Software Testing announced the location for their next annual conference CAST 2015, Grand Rapids, MI, there was an up-roar happening on social media and back channels like Skype and private conversations. To my own surprise, I saw members of the context-driven testing community falling short of their very own principles. Rather than observing and interacting with people, it seemed that some persons preferred to derive their knowledge about Grand Rapids based upon a prior CAST conference there. Experience may be a good resource to start looking at, but I found that I should trust the folks from the local area that I knew to put together an awesome conference – more so since they could explain to me why the past experience was not so well received. When it came to the October 2014 AST board member meeting, Pete Walen, the conference chair, the guy who managed to send in a proposal prior to CAST 2014 so that the AST board could decide upon it, invited us to the conference location, so that it was easy to see for us where we were going with the proposal. Here is what I learned during my two nights in the conference venue – and why I think you should attend.

Continue reading Why you should go to CAST

Not so fast food

A while ago I considered adding some new type pf posts to my blog. There are many things that I notice in my leisure time at all the different spots that makes most folks wouldn’t think about, yet I see a relation to some of the stuff that I learned while diving into Agile software development. This blog entry kicks off these new type of posts.

I am not sure about other places on Earth, but in Germany the McDonald’s corporation recently started to re-design their restaurants. (Yes, I admit that at times a McDonald’s is one of my choices to take something to eat while switching trains.) They are now offering two types of counters together with a self-service counter using credit cards or bank cards. The in-person counters a split by the counter where you order and pay for your meal, and the counter where you can then pick your meal. Based upon subjective experiences, I think this move is a dramatic move away from customer friendliness.

What’s the problem?

My observation into many of these encounters was, that I needed to wait way longer to get food than it was the case before this re-design. Waiting times used to annoying to us customers even in the old design, but now with the new design, things got worse according to my personal experiences. Of course, it’s not much of a problem if there are few other customers. But imagine the situation when a full train arrives with hundreds of passengers during lunchtime at a local train station. Some of them at least will walk into the nearest McDonald’s to grab some food.

In the old workflow design, there were usually three to five counters open during such high times. There were several queues forming in front of these counters, you would be waiting in line for your turn, order, pay, wait for your meal to be prepared, and then leave. Overall this had been between 5-15 minutes at times for me.

Now let’s take a look at the new workflow design. You enter the restaurant, see two open counters with lots of folks waiting there, and you see the full list of already ordered meals on the screen above the counter for the pick-up. If you’re like me you check the self-service machines in such case. Funny thing is that in 95% of the times I ran into such a situation, these were out of order.

So, we get in line in front of the in-person counters. We wait until it’s our turn, order, pay, and receive a receipt with a number for the pick-up counter. There you queue up until it’s your turn to pick up your meal. But wait, there is only one guy serving the pick-up counter. So, all the customers from the two in-person order counters end up in a single queue to get their food. It would be even worse if one or more of the three self-service machines worked.

What’s happening here?

As Mary Poppendieck taught me a while ago, whenever there is a queue, there is certainly sub-optimization happening. What’s the sub-optimization here? McDonald’s seems to optimize for cash-flows and sparing personell costs from my point of view. Two in-person counters, and one guy serving the meals is three quarters of the salary they used to pay before the re-design.

Of course, people wouldn’t buy into that without some benefits. The self-service machines and the new fancy restaurant layout seem to be the selling points here. But it seems that they have under-estimated the demand and the necessary queues for such a move.

So, what’s better about the old system?

Did you notice the hand-off between the two counters? Yeah, I think this is the major culprit. On face value, you saved one person’s salary with the new workflow. On the other hand, you made it way harder for people to support each other.

Consider this situation that I observed last week. The pick-up counter was heavily under stress with 5-10 items still in line. At some point one of the in-person counters clerks decided to help them out, move from the counter, and got into the kitchen. Unfortunately the other cashier also had to leave for some reason I didn’t get. I observed five new customers stepping into the restaurant totally confused about where to get food, since none of the cashier stations was served.

The problem is that the new workflow makes it close to impossible for other people in the restaurant to help out the current bottleneck in the overall system. In the past I have observed folks from McCafe stepping in to help out others if there was a need. Now, it’s impossible.

All of this came with the specialization that slipped into the workflow from separating cashing and food preparations. The one additional hand-off made it less likely for me personally to enter a McDonald’s restaurant if I want to use my 15 minutes train switching time to grab something to eat. Maybe my wife will like this in the long, but on face value, I think McDonald’s harmed their overall business more than necessary with this one additional hand-off and specialization that happened alongside.

I certainly don’t know any business numbers from McDonald’s, but I imagine that client happiness with the new workflow restaurants dropped dramatically probably resulting in fewer returning customers.

Now, think what happened when the software industry introduced hand-offs between Analysis, Design, Architecture, Coding, and Testing.

Software Testing, Craftsmanship, Leadership and beyond