Markus Gärtner's Blog, page 18

Testing Tools Mash-Ups

One of the three things that bring innovations, is copulation. That’s basically two already good ideas having sex with each other. I learned this from Jerry Weinberg’s Becoming a technical leader. The longer I stay in test automation and agile, though, I think this does not hold for combinations of testing tools, like a testing framework, and a UI-driver.

There are a lot of so called mash-ups of functional testing tools. For example, there Selenesse which combines Selenium with FitNesse. Last week I also heard from FitKuli, which is a mash-up of Sikuli and FitNesse. I think we should call this one rather SikNesse.

All these mash-ups have one thing in common: They bring the team an opportunity to continue working in the same old silos. Testers can work on their own on test automation through the GUI, programmers don’t have to deal with the problems they are creating by not separating the concerns of the UI from the business logic. This is not only bad, it also misses completely the purpose of good test automation, and agile acceptance testing. The main point is that your team should be collaborating on it.

But there is more. Test automation is software development. By enabling testers to come up with scenario tables that are actually extracted functions in the SLiM language of the requirements, you eventually over time create a whole lot of a mess. Since you can’t unit test these scenarios, you might as likely end up with a bunch of legacy code – in your functional testing tool. I promise you, it won’t be long until you abandon the test automation efforts, because they have become a maintenance nightmare in the long-run.

There are also other tools like RIDE and Selenium IDE. When I spoke with Adam Goucher in July this year, he mentioned that he abandoned the project on Selenium IDE largely because he was helping companies to get rid of this stuff in the long run.

One of the key points in my keynote at the Agile Testing Days last week, was that I like to be not a T-shaped team member, but a circular one. I know some stuff about coding, I know some stuff about requirements gathering, I know some stuff about database, I know some stuff about testing. Putting it all together, I feel way more comfortable to serve the project when I have to. This is a comfortable position to work from – especially in an Agile context – since I can help so many people become better at whatever they do.

Tools like testing IDEs (don’t get me started on the commercial ones) or tool mash-ups prevent you from looking for circular shaped persons to facilitate between the testing and the programming perspective. In the end, you don’t deal with the real underlying problem: That no one knows how to do good test automation. Don’t go there. Instead, find the right people to get you started in your efforts, and help the team to collaborate based upon that.

Tell a story at the daily standup

Yesterday during my keynote at the Agile Testing Days 2012 I said I see a lot of standups, where testers report on their yesterday’s work in the following way:

Yesterday I tested the thing with the stuff. I found some bugs, and filed them. Today I will test the foo with the bar.

I think this is horrible test reporting. While concluding the fifth beta of Elisabeth Hendrickson‘s upcoming book Explore it! I found a few more hints in the same direction. On the same line I will relate good test reporting during the standup to what for example Michael Bolton talks about when it comes to test reporting – we should tell three stories during test reporting:

a story about the product
a story about testing
a story about the process

The story about the product

During a daily standup you will not only find programmers longing for feedback on their hot new stuff from yesterday’s hard day of work. There is likely to be a ProductOwner, and maybe even other stakeholders of the product that you build. As the purpose of the daily standup is to coordinate the team’s work, for the team to coordinate their work, it needs to have as much information as possible to make the right decision for the day. Therefore it needs to know whether you as the tester found so many bugs in that critical new area that your sprint goal cannot be fulfilled in the remaining five days, or whether that new feature works out sharmingly on your desk, The ProductOwner might need that feedback to prioritize the remainder of the product backlog, and the programmers need to be able to know how whether Pete has to work on these bugs, or whether he can start working on the sixth story in your iteration.

Therefore you should have a story prepared that you can tell about the product the particular area you have worked on yesterday, and what you think needs more exploration for tomorrow. If you do exploratory testing and schedule your debriefing right before the standup, it will be an even easier job to do. Don’t overwhelm your team and ProductOwner with too many details thought make sure to raise the major issues at the standup, and maybe ask for more one-on-one discussions later where more minor issues occurred.

The story about the testing

A good self-organizing team shold be able to overcome most of the obstacles that it encounters. As a programmer, when you hit the problem of loosing yourself in someone else’s code because it is too complicated, you will make the decision to pair up later during the standup. The same holds for the work of a tester. When you find yourself painted into the corner, your team does need to know it in order to coordinate in a way that you get the support to deliver even more awesome testing for tomorrow.

That is why we also need to tell the story of our testing, how hard it was to setup a test, and whether maybe a better logging functionality could help improve the results that we can deliver. If a programmer finds out, that he could do most of the puzzling tests on a unit test level, you might even be more impressed if you paired up with him in order to find the right examples and checks and automate away some of your more tedious tasks for the future. You might also find out that your ProductOwner can reveal more details about the limitations of those acceptance tests for story xyz, that you automated yesterday, and you can have a meaningful discussion with her about that. The team might be able to help you support you in work – especially if you feel desperate because you feel you didn’t achieve anything due to these issues.

The story about the process

That leads to the final story, the story of the process. At some teams I find that issues in the team itself are withheld until the retrospective at the end of the iteration. Don’t do that. Instead provide what bothers you. If you don’t feel safe enough to talk about the problems that you face, your team might suffer from the lack of trust, that Patrick Lencioni refers to as the basis for great teamwork in The Five Dysfunctions of a team. Trust is the founding basis for great teamwork. That is why you should be able to talk about the problems in your process, the desperation that you face, and come up with short-term solutions to fix that. Don’t withhold this useful information until the retrospective in two weeks.

The story about the process includes for example that you were waiting for that first story since yesterday, but it couldn’t be finished Maybe your team decides that you as the tester should support the unit testing of the programmers so that the feature will ship in better quality for exploratory testing later, and that you will have some information about what your programmer already has covered in their tests, and consciously decide which other tests to skip for this iteration. Maybe you find out that there have been too many ambiguous acceptance criteria for that critical story, so that you are now fleshing out all of the details too late. Then you might decide to call in a speculation specification meeting to bring these ambiguities to the table, and clear them now. Leave the experiment to run these specification workshops more regularly for the retrospective meeting, maybe, when you have empirical evidence how these worked out.

So, at your next standup meeting, prepare these three stories: a story about the product, a story about the testing, and a story about your process. Your team will be able to coordinate better with this useful information.

Certified Scrum Manager – somewhat more than a rant

In the past I have been more than skeptic about certifications. I even wrote about my minimum requirements for a certification programme that might (or might not) add value in an article called Meaningful Certification?. Despite the split between the two larger organizations (and their early leaders) on Scrum – the Scrum Alliance and Scrum.org – yesterday I noticed that the certification scam has taken on new levels with a program called Certified Scrum Manager (IAPM). Here is my honest critique about it, and I will try to rant as few as possible about it.

First of all, what are the claims in the program? The program claims it is based on the Scrum Guide 1.0. The collaboratively maintained official Scrum Guide from Scrum.org and the Scrum Alliance do not provide version numbers like software, but use month and year relationships. The latest one for example is from October 2011. The official version also has a version history.

However, if you actually click on the link provided for the suspicious Scrum Guide 1.0, you end up on a page stating that the current version of the Scrum Guide is currently overworked, and you do not get any access to the basis of this great program. Interesting, and this makes a tester like me suspicious enough to go on.

Reading on, the website claims that you need to fill in your personal information together with up to five projects that you have managed. But wait, what does management mean in a scrum context? If you take the traditional responsibilities of a project manager, and map them to a Scrum context, you end up with a split responsibility for quality for example. The Development-Team is responsible for the quality of their work, while the ScrumMaster is responsible for the quality of the team, and the ProductOwner is responsible for the quality of the product. That would mean that I can apply for this brand new shiny certificate if I “just” have been a programmer or even a tester on a project? Awesome how easy it is to become a manager these days.

But wait, there’s more. While the English version of the program reveals some information, in my twitter stream (either Deb Preuss or Boris Gloger came up with it) also a German article popped up introducing the program. If you know German, read it here. The article provides the main motivation for this new certification: you can take the test online, so us busy managers don’t need to leave work for it, you don’t need to re-certify after i.e. 2 years, and it includes a certificate to work as ScrumMaster, ProductOwner, and even the Developer certificate. Wonderful! Let’s look at each of these in more detail.

Busy managers don’t need to leave work for getting certified. I think this sentence is a problem statement in itself. Two key lessons I learned from Weinberg’s Quality Software Management series were that busy managers might appear like good work but they are not. First of all, consider the controller fallacy from Volume 1 – Systems Thinking (page 197):

If the controller isn’t busy, it’s not doing a good job. If the controller is very busy, it must be a good controller.

It’s a trap to think that a busy manager is a good manager, just because he or she is busy. More often than not it might mean that this particular manager is not able to turn its attention to the problems that may arise in day-to-day work. But there is more. On page 276 of the same book, Weinberg points out the problem with managers not being available:

Busy managers mean bad management.

Just consider what self-revelation a busy manager offers in all due respect to his self-management abilities. How can a manager unable to manage himself be in charge of managing someone else? This certification program seems to especially open up for bad managers continuing to spread out into the Agile world.

And I hope that the larger world of software development will soon realize that mentioning the Certified Scrum Manager (IAPM) on your resume will become a point in your disadvantage for your application, not for your advantage.

Second, no re-certification is necessary. Take the cert, and live happily ever after. Despite the plans from Scrum.org and the Scrum Alliance to change their systems from every now and then, this seems to be a counter-position. The world changes, our understanding of Agile changes, and I think this makes it necessary to refine our understanding of the things we believed. This also means that we will continuously have to keep on learning new things. Take the questionnaire once, and then claim to know it all is the route to the misunderstandings in the future. Last year I lost my certificate as a professional swimming trainer, because I didn’t take the time (and the training practice) to extend it. I am fine with that. I still know some stuff, but I can’t (and I even won’t) claim that I know the latest trends in training professional swimmers. How come a field such as software development – or more precise management of software development – can do such an unprofessional thing?

Third thing, this new certificate is worth the same amount of learning as a CSM, CSPO, and CSD certificate. When considering the discussion about the split responsibilities you might think this is true. But there is more. I went through the CSM, CSPO, and the CSD program. I think I know enough about Continuous Integration, Test-driven Development, Acceptance Test-driven Development, Exploratory Testing, Design Patterns, Refactoring, Personality Types, team building, requirements trawling, leadership, psychology, epistemology, Scrum, XP, Crystal, Kanban, Lean, and facilitation that I am more than comfortable in either of these roles. I am not so certain about most of the managers I have run into.

The Agile community is more than suspicious about managers and management despite efforts like books on the Agile management, management is still a trend from the late 19th, early 20th century. Management as I get it from Taylor in his book means to separate the doing of work from the thinking about how to improve it. Since the traditional worker is too stupid to think about how to improve his own working steps, he needs a manager to tell him, how he has to arrange his separate working steps, so that he can be more productive while working.

In my experience this premise does not hold at all for knowledge work like software development, programming, software testing, and requirements gathering. We are working with highly educated people in software development. That’s why we should stop to treat them as unmotivated body-leases, and start to treat them as adults self-responsible for their actions, and able to learn how to do better work on their own. While it helps for line managers to know about stuff like CI, TDD, ATDD, ET, and so on, I find it worrying to see a management certification program claiming as one of their benefits that the managers will later on be able to work as Scrum developer.

Final point, I am on the edge to call this certification snake oil. Despite my efforts to find out which basis this program is built upon, or who has been involved in creating it, I could not figure it out on their web-site. If you read the English language version, you will even see a relict from the translation process in German there (as of this writing – I am quite certain, they will remove it later). Here is a screenshot.

I think there is a place for managers from traditional organizations understanding Scrum, and Agile, and enabling them to provide their value to high-productive, highly self-managed teams. I don’t think we need a certification for this, but I am afraid there will be more programs like this in the near future. I hope that the Scrum Alliance and Scrum.org can set aside their differences, and join forces in freeing the world of software development from this crap.

A testing landscape

On my way to EuroSTAR 2012 I was starting to think about the Cynefin model, and landscape diagrams which I know from giving some courses. I tried to relate them to software testing, different techniques, and I was not sure where this could lead me.

I had some exchanges with Michael Bolton, Bart Knaack and Huib Schoots on my early draft, and I wanted to share what I had ended up with. So, here it is.

Initially I had the idea to label the x-axis with skills, or rather required skills, and the y-axis with domain knowledge. While talking to Michael Bolton he convinced me that I am probably looking for something else, and that the problem I try to solve with this tool would provide information on how to label the axis.

We ended up with formality on the x-axis with very formal methods to the left, and informal to the right. On the y-axis we ended up with the amount of individual accountability for the testing being done.

The problem I think I try to solve with this tool is to make transparent when test cases, and other more formal and traditional test approaches can be useful, and when other more lightweight or informal approaches are useful, like things we do in Agile testing or when using Exploratory testing. The landscape diagram then becomes a tool to have a conversation about the degree of formality necessary in a given context – hopefully (we haven’t applied it at a client so far, just pin-pointed some ideas back and forth).

Later I had a discussion on a flipchart with Bart Knaack and Huib Schoots extending on it. We started with the basis model I had discussed with Michael Bolton in the morning, and Bart and Huib provided some great input into that. We ended with the following flip chart, hopwing to get some extensions over the course of the conference.

As you can see we went away from the idea to put test cases into context of something like that, more in the direction, what type of bubbles do you apply in a situation where you have informal testing with low accountability for the individual tester, or what happens if you have high accountability for the individual tester, and have more informal testing needed to be done.

We started with different companies, and types of projects. Agile and Scrum in this sense ended up in the top right quadrant of the landscape, while more regulated environments ended up in the top left corner. Factory-testing ended up more in the lower left corner.

I don’t think this discussion about the landscape is over, yet. Instead I hope that this will trigger some discussions in the direction of putting testing more into context, so that we as a profession can get over the “it depends” trap that I think we currently fall into too often.

EuroSTAR 2012: ISO 29119 – The New International Software Testing Standard

At EuroSTAR 2012 I took the opportunity to learn something about the new international software testing standard since I wouldn’t take the time to read through all this stuff, anyways.

Stuart Reid explained that he’s convinced that we need testing standards. Reid explained that there are few standards for software testing, and they merely cover parts. For example, take unit testing: there are two standards: british and IEEE, they conflict with each other. Reid claimed there is no standard for integration testing, acceptance testing, and so on.

The ISO 29119 standard consists of the processes module, the documentation module, and the testing techniques module. They are based upon the concepts and vocabulary part. Reid claimed that each individual part can stand on its own. The new ISO standard will also send the already existing IEEE standards to its retirement.

In the first part, concepts and vocabulary are covered. This includes scope, conformance, normative references, and definitions. There are also different software testing concepts, and testing in different lifecycle models. FInally, it covers roles and responsibilities.

Part 2 consists of the testing process. These are organizational test process, test management test processes, and dynamic test processes. Part 3 is on test documentation. Reid didn’t break it down to a clearer level for me, other than saying “Test Documentation”. I think it’s mostly consisting of IEEE 839 stuff. In part 4 the techniques are covered. Black box vs. white box testing, test coverage measurements, and some examples for applying the techniques, and testing of quality characteristics (or non-functional requirements). The annex part also gives hints on the election of particular techniques and how to assess the effectiveness of different techniques.

What stroke me most about the things that Reid described was the level of outrages treatment. Getting such a standard seems to be a touch job. More over, things become political. I couldn’t count the number of times Reid mentioned blacklisting other people in the process of coming up with this particular standard. Maybe it’s more my interpretation, but I noticed a lot of people interested more in getting the name and influence into this piece, rather than trying to help coming up with a working testing model.

One example that I would like to repeat to give a hint. In the second part, Reid mentioned that static testing is missing because one country’s votes voted for getting this thing out. Once they had taken out the static testing techniques, that particular country voted to get them back again. Puzzled, I wonder why anyone would ever make the effort to work in such a work(-avoidance?-)group.

Reid explained that the standard is meant to be tailored to the needs of the company. They cover Agile and traditional, Reid claimed. I wonder where the explanation for Agile testing projects came from, and what sort of evidence the working group took to put the Agile pieces in place. Overall the description seemed to be too generous to be useful for me. Considering the world of ScrumButs out there, I think the ISO 29119 assessment will end up in “whatever we would like to do”.

Code Coverage – useful or misuseful?

This year I took all three courses on Black-box Software Testing. Each of them means an investment of four weeks of my time, usually up to 2-4 hours per day. This was quite a blast, and I am happy that I made it through the courses.

One thing that stroke me in the first course was the different uses and misuses of code coverage discussed in the first part, the Foundations course. Here is a short description of things I have seen working, and not working so much.

The main point in the paper by Brian Marick on How to misuse code coverage is that you may use code coverage to measure things that your tests cover in your code, or you can use it as a hint for where you haven’t tested anything – and decide in brain-on mode whether to cover that particular area or not.

The former point is a measurement, and might become a management metric. Especially in Theory X thinking code coverage becomes a metric for the performance of individuals or teams. This has some drawbacks, as Kaner and Bond point out in their classic paper on Software Engineering Metrics – What do they measure and how do we know?. The main distinction is that measuring code coverage is a second-order measurement for something else. It’s a substitution, as Kahneman describes in Thinking Fast and Slow in the sense that we are answering a different question. The question we are trying to answer is whether this code is sufficiently tested, and how maintainable it might be in the long-run.

When putting in place a code coverage metric I have seen dysfunctions as Kaner and Bond describe them. Recently I heard from a company that demanded 100% code coverage. Though Robert C. Martin demands that this should be a goal for any great development team, when put into a measurement metric or in a contract, it more often than not becomes a problem. I also heard about a company where the development team was given the goal to reach at least 50% code coverage. This setting led to generated tests that aim for code coverage, but not for useful tests that help you drive and maintain the application in the long run.

On the other hand, when using code coverage to check what has not been covered with automated checks, we get a clearer picture about our situation. With our brains switched on we can distinguish between code that should better get some more tests to cover that particular complicated flow through the application, or whether to leave that empty try-catch-block as it is right now.

In the past I have applied code coverage more often successful from inside the team as a measurement to measure pieces of code that we did not (yet) cover. Think about it as an information radiator. Code coverage makes then clear which pieces of your code are not covered, yet, and you can think through whether you need more tests. Code coverage then becomes a first-order measurement, which the team uses to bring forward their development efforts.

Code coverage can be used in useful and misuseful ways. How are you using code coverage in your company?

GATE No. 2: A transpection report

Two weeks ago the second GATE workshop took place in our offices in Munich. Unfortunately some of the participants couldn’t make it. So, there were the three of us, Meike Mertsch, Alexander Simic, and myself. Although we were a bit low on energy in the morning, the day turned out to be a wholesome day of transpection – or if you prefer, we did a lot of test chat. Here’s what still sticks with me from the day.

Tester vs. Programmer

In the morning we had a lot of discussions around the topic of testers vs. programmers. I don’t know what happened in the conversation, but at some point we reached the understanding, that we usually have testing programmers, and programming testers. In the past I mostly thought about how to convince testers to become part of the development. But two weeks ago it clicked for me in my head why that is indeed not the purpose. Looking back to two examinations from Elisabeth Hendrickson, there are close to no job ads for testers alone. Companies look for testers who are also able to do some coding, at least.

As it turns out, the thinking that we just need to teach some testers how to become better programmers, or how to test better, does no longer look like a business model to draw on. With the uprising of agile methodologies, with test-driven development, and developers doing unit testing, the biggest struggle lies in getting programmers and testers to understand each other better. I ended up with the understanding, that we need to teach programmers that have become test-infected, and tester that have become programming-infected, how to become better at whatever they are doing right now, or trying to do tomorrow. At least I draw a bigger growth hypothesis to this problem right now.

BBST, RTI, and testing courses

We talked a lot about different courses. Alex and I went through most of BBST, Alex was an onsite participant at the Rapid Testing Intensive (RTI) course, I was an online participant. We exchanged thoughts on different courses between each other, exchanged our experiences. Especially to me the onsite vs. online experiences from RTI were pretty interesting. I see some potential for future improvements there, and I am quite convinced the Bach brothers will contribute their share to future RTI courses.

On BBST, I exchanged lots of ideas. This was quite interesting to me since the next day my Test Design courses started, and I am close to half-way through it right now. So bare with me if I don’t update my blog that often right now.

Test coaching

Last, but not least, Alex and I talked a lot about test coaching. I have taken nearly two lessons with James, and he is actively more involved with him right now. We exchanged our experiences with the different experiences we had, and where a possible future for test coaching might lie.

Especially based on the premise that I mostly deal with testing programmers and programming testers, there are a lot of interesting conclusions to draw from this.

What about the future?

Oh, the main topic was the future of testing. We talked about certifications, different courses, how the landscape of testing in Germany looks like, and the like. It was quite inspiring, but there are not many conclusions that you can draw about the state of the art in software testing in Germany based on the observations of three people. Anyways, we took the opportunity to learn a lot from each other. Unfortunately Meike left in the afternoon, but I had five to six more hours of conversation with Alex in the biergarten, after having talked for about six to seven hours at our office already. Overall, it was very inspiring.

What about the future of GATE? Well, we also talked about that, and we hope that we an attract more folks next time. We will definitely settle the date with an eye on the traveling plans from some well-known folks. So, stay tuned for further announcements. I also hope that I will find out how the DEWT-guys do it next month when I will join them for their second workshop in the Netherlands.

ALE2012 Lookback

It has been about three weeks right now since the second Agile Lean Europe in Barcelona. Although I had the best intentions back then, I promised to write a blog entry about my experiences there, I didn’t do it until now. It seems the best stuff I take away from the break-out conversations in the coffee breaks these days when at conferences, not so much from the session itself. This also holds for the ALE 2012.

Day One

I arrived late on the first day of the conference. Just right on time for lunch, but also just after the first set of planned sessions in the morning. I had a nice chat with Marc Löffler from the taxi-ride to the conference venue. We talked about various things, from retrospectives, to different traveling habits that each of us started with.

On the lunch table I had interesting conversations with some folks about how it-agile is organized internally, and the different democratic ways of working that we share. Among the more interesting stuff are things like peer groups, a democratic way to settle individual salaries, and using the pull principle throughout the whole company. Some of my colleagues have written about that stuff in the past, for example here, here, or here.

In the afternoon I joined an open space session on books – only to find myself with five new books to read in the next few months (years probably with a shelf of 50 unread books now). Among the most interesting one is the book named “Quiet” which explains a lot of habits us introverts take on, i.e. when leaving a party only to read a good book.This recommendation form Jurgen Appelo made a kick-start to number two in my to-read list, and I hope to start with it during this week.

One thing we learned the hard way was that there were just few programmers willing to work through the brutal refactoring game together with Adrian and myself. We exchanged the thoughts on the concept in the time being, and exchanged some thoughts on software craftsmanship.

Day Two

On the second day of the conference, I woke up early enough to join the opening in the morning. Since I had a longer chat with Marc Löffler the day before, I joined his session on retrospectives. He proposed to include purpose into the sprint retrospective, and made a motivating case for it.

Among other sessions, I enjoyed the chat I had with my colleague Christian Dähn in the evening. The busy times in Germany don’t provide us with too much time to talk about our company. We discussed some of the things that we saw during the day, and things we would like to try out at it-agile GmbH over the course of the next few weeks, or months, maybe. It was an inspiring evening.

Day Three

On the final of the conference, I had my talk on testing with a stranger. I had chatted with the Open Space software development team, and was willing to test their application in a testing dojo way. It was amazing. We went through a tour through the application first, and then came up with individual focused sessions. In the end we raised after one hour of testing enough concerns on various topics, that it took me half an hour to explain all the different things to the product owners and stakeholders. I think it was time worth spent. I would love to join the development team the next time. The pure separation of the team and the testers led to a lot of hate when we delivered our information. That was interesting information to me.

Later I also joined the retrospective of the Open Space development team. It turned out that they were able to get started with a first minimal version of the application pretty soon. Unfortunately they went without tests, which was not a problem at first, but the lack of a safety-net over time became a burden to team’s ability to deliver quickly. As Duarta Vasco expressed it:

You can bootstrap without testing, but you miss it at some point.

This was an interesting insight for me as well.

In the afternoon there were two absolute highlights. First, when the kids of all the families joined, and presented their achievements back to the group of adults who chatted all day about Agile, Lean, and coaching, there was whole different atmosphere in the room. The kids brought such a natural feeling of joy. The thing that amazed me the most was the fact that most of the kids did not speak English at all, yet they were able to play with the other kids over the course of three days. And they brought so much fun back to their parents when they joined us, it was just amazing.

Right after that, Henrik Kniberg held the closing keynote. In it he explained how his family made up the plan to travel all over the world in six months, and how they got to do that. One of his daughters had joined him for the final Q&A, and it directly brought the spirit from the children dancing about an hour before that back. It was amazing, and inspiring at the same time. The topic of his presentation was

ALE 2013

With the fun the kids brought to ALE 2012 in mind, and with the keynote from Henrik Kniberg, I would love to bring my wife and the kids to next year’s conference. I had some longer chats with Adrian Bolboaca as well as Martin Klose about different things like software craftsmanship in Germany, and various code retreats all over Germany. I especially liked Adrian’s motivation to become a European bumblebee, and bring different practices and exercises to the folks all over Europe.

Trip report from the Ukrainian Testing Days

Last weekend I was invited to Odessa, Ukraine for the Ukrainian Testing Days, a conference that Andrii Dzynia co-organized. Andrii has organized public testing dojos in the Ukraine in the past. He asked me to put the reports from their sessions on my blog in an English translation. I think he does great work there for the Ukrainian community. So, I was eager to see that community in action. I had a pleasant trip, staying in Odessa was very comfortable to me, especially since Julia Cherniak dropped me from the airport, and led me around in town on the first day. Here is a full report from my roughly two days in the Ukraine.

Arrival on Friday

I arrived on Friday. Julia dropped me from the airport, and brought me to my hotel, the Londonskaya, nearby Odessa’s city center. Since I didn’t have time to get lunch on my trip, we went together to a close-by grill restaurant. Later I was showed around in town, the weather was superb, so I had a really pleasant time upon arrival.

The conference had already begun with the usual tutorials on the first day. In the evening, there was a reception planned at the bar. There were Lightning Talks planned for the evening. All of them were in Russian, so I had to ask my seat neighbors to translate me pieces of the talks. I didn’t get the names – due to the language, or maybe due to the alcohol involved. So, forgive me, if I can’t provide you with names of the speakers.

The first one was on bug patterns. The speaker collects together bug patterns at http://www.itsfeature.com. I didn’t manage to give him the feedback during my stay, but I think he might want to run some of them through the next pattern conference like EuroPLoP, or any other of the PLoP conferences around.

The second talk came from a lady who described how to take care for your own education. She explained a lot of things that I also had incorporated into my talk on self-education two years back. Later I asked her about finding a mentor, and other things like deliberate practice at testing dojos, and weekend testing that I found worthwhile.

The third speaker that I had the pleasure to get translated explained 10 things every tester should know. I don’t remember the details, but I found his list compelling.

After that I left with Dima, a colleague from Julia, for a bar at the beach. We had a long chat about various things like software development, software craftsmanship, exchanged different thoughts on talks and practical sessions, and what I have seen. Dima is also writing for infoq. So we also had a chat about writing articles, and books.

Keynote day

I had the pleasure to talk about the past, the present, and the future in my keynote at the morning of the official conference. After the talk there were some folks approaching me asking various things. One girl sticked particular, as she asked me how many earrings I have, and found it curious that I had been a swimmer, and a swimming trainer later. I am quite certain that she already is a great tester. ;)

Out of curiosity I asked for people to raise their hands if they had followed software testing as a career for their live. I was surprised to see so many hands raised. At CAST 2012 I had for the first time the impression that a tester did not “fall” into testing, but pursued it as a career since school. I think Ukraine is sort of special in this regard – or at least the Ukrainian Testing Days have been for me. Looking back, I feel awesome having been part of such a great community of testers.

After my talk, I talked to several people, before we headed to lunch at a Spanish restaurant. Later Dima, a colleague from Julia led me around in town, and had me interview. I hope this interview will be published in the near future. So stay tuned.

Odessa seems to be a quite interesting city. Despite the nice weather, there were about a gazillion weddings going on during my time there. We walked by the opera house in Odessa, which is a reconstruction of the Vienna opera house, I was told. There were nice little parks, bridges with locks from love partners, and other tiny little things which made the stay so pleasant. Overall, it felt like holiday and time travelling with all the music from the 1980s and 1990s played in pubs and restaurants.

In the evening, I joined the after party at a beach at the black sea. There were some party games going on, but me being a huge nerd continued to talk to other nerds while the polonaise was going on. Also, it seemed that more people approached me, and had a chat with me, after giving out beers. Andrii made me aware of this the day after this.

Some folks went to the charaoke bar after the beach party. I felt too tired, and really needed some rest before the final day where Andrii and I were going to run a testing dojo at the office of Lohika, one of the sponsors.

Testing Dojo

We had decided to run a testing dojo in the testing with a stranger format that Huib Schoots and I had used at the TestBash in Cambridge, UK. We ran in pairs in three different sessions. The first one was to a touring session to get to know the application. The second one would continue from the debriefing to the interesting areas of the product, and the final one would probably deal with different techniques for note taking.

Unfortunately I had to leave to lunch and the airport after the first session, so I didn’t see how the plan worked out. I received lots of gifts like a cup, and a t-shirt from the conference. I also handed out some copies of my book, ATDD by Example – also signing it for the folks I had a chat with.

After all I came back from a three day trip to a conference very relaxed. I received a lot of hospitality from the Ukrainians, and I had a very pleasant stay. Hope to get back next year, or maybe in some other near future? Thanks for all who talked to me, and who led me around.

Testautomation Coderetreat No. 1 – A report

Last Saturday we had the first testautomation coderetreat in Munich. Woohoo! This was a kickstart for this new coderetreat format – besides the original one from Corey Haines, and the Legacy Coderetreat format from J.B. Rainsberger. Here is my report from the facilitator’s point of view and with some hints about what I am going to try at different other follow-up coderetreats.

It was Saturday morning, we had an appointment with some buns, and I had a plan zero on what we were going to do. My colleague Meike Mertsch and I arrived at around 8:25 in the morning at our office in Munich, only to find the first of the participants already there. While preparing the office, we managed to get some coffee cooked, a sign outside for the remaining participants to find us, and arrange the room for the coderetreat. We were going to start at 9.

Then it happened! No coffee today! While cooking coffee one of the participants broke the coffeemaker, and we didn’t manage to get coffee for quite some time – it seemed. Then one of our colleague entered, and was able to help us out with the espresso machine long enough for the participants not to fall asleep due to lack of caffeine.

We started the first rough hour with introductions, expectation management, some general explanations on what the participants were going to expect. I had become a bit unsure while speaking with some folks from the SoCraTes conference about the plan. Plan zero consisted of six sessions automating tests on an acceptance test level for a web site. Nothing special, some business rules, and not too boring, I hoped. Well, one week earlier I had received mixed feedback about that plan. So I started suspicious, willing to switch plans whenever necessary.

It turned out that I didn’t have to worry too much, although not all of the participants were familiar with test automation. We left the first round pretty open. Folks were able to automate one to two tests in the first 45 minutes overall. In the second round I introduced the different formats, Given/When/Then, table styles, and arrange-act-assert, and let the new pairs off for new frontiers. We actually had lots of people familiar with BDD and ATDD in the room, and others who were not as familiar. It was great to see that the folks with more knowledge jumped right in to help the people with less knowledge out. That was a great experience. So, in the second round people were able to automate some more tests in the given 45 minutes.

For the third session I had noticed rather long code fragments in the test automation code. So I put a constraint on the pairs: no methods and step definitions longer than five lines, and no else-conditional logic in the code. That worked quite well, despite that there were no else-conditionals in the code beforehand, so maybe I should drop that. After the third round it was time for lunch – pizza – and some wakening game.

In the fourth session we went for pairing. We had observed that people were sticky at the keyboard. We decided to change that with a keyboard change whenever three codelines had been touched (or written). That engaged people more, and I saw many more keyboard changes there. Although in the debriefing folks pointed out that this can be a burden while working with a new framework.

In the fifth session I asked for outside-in development style, and to replace the web application with an own implementation. I think that at least one pair managed to get one fifth of the functions ready, but I had to ask them to remove the code afterwards. In the sixth session we went for open season. One pair focused on automating the CI behind the system, but they didn’t manage get the build steps automated in 45 minutes.

At the end of the day, I think all the attendees had fun, despite the variety of previous knowledge and experience. I will facilitate the next testautomation codetreat on August 25th in Bielefeld together with Martin Klose. Please sign up if you have become interested.