Test Pappy

My current feeling: panic.

It’s only 8 days until take-off to Let’s Test. You read in a tester’s blog and don’t know the Let’s Test Conference? Under which rock were you hiding the past years?

When I joined the CDT community on Twitter back in late 2012, I became aware of really cool testing conferences going on out there in the world of testing. In May 2013 I became aware of the second Let’s Test Conference in Runö, Sweden. For me it became THE tester conference to go to. To add here, I have never been to a tester conference until this day, and it will be another week until I do.
Following Let’s Test 2014 from home, thanks to several attendees via Twitter and blogs enforced my urge to attend this very conference. Thankfully, after a busy and stressful year so far, in October 2014 my boss asked me about the budget 2015, and I said I wanna attend a tester conference. He agreed and asked if there is one on my mind, and if I know what the cost is, so he can put it in the budget. So I made a few calculations and entered the amount for Let’s Test in the budget. When my boss asked me in January, if there is an early bird for the conference I chose, I was aware that the budget is nearly approved. I told him there is, but it’s only until the end of January. And end of that month I got the approval, 2 days before early bird ended. And I registered. One of the best moments so far in 2015.

But now reality is coming closer. I got the conference schedule up my office wall, frequently looking at it. I am following Twitter comments from presenters at Let’s Test getting their presentations together and on first trials. But having lots of tasks currently both at work and at home, my conference preparations are a bit behind.

There are so many folks on the schedule presenting, whom I want to meet in person, because I have discussed with them on Twitter, read their blogs and articles, helped reviewing the book they are writing, or working with them on the Software Testing World Cup judging team for Europe last year. Facing a 12h+ hour program per day, I hope to have the chance to talk with all of them. I am already sorry, that I will miss a lot of presentations that I would really love to see, because there are four awesome threads of presentations going on, and you can only participate at one. The first choice was already to be made when booking, choosing from EIGHT different work shops, of which I would spontaneasouly book 5 to 6, and the remaining 2 to 3 would be interesting, too. But one it is, and I am still happy with the decision.

For the rest of the conferenc I made the decision to decide nothing up front. I read in blogs and comments from last year, that too many people switched their minds over and over, so why make a plan in the first place, when there is no chance for a bad choice on the schedule.

Finally I started investing ways to go from the airport to Runö. The next week will be busy with preparations, that is guaranteed. Maybe that’s the reason for my panic. I hope, when I finally arrive at Munich airport next Sunday, that this will be over and the fun can begin.

I haven’t blogged in quite a while. This thing here lay around 9 weeks till today.

Today, I learned to appreciate quite a few things from my hobbies, that are absolutely essential for my job, too. To have a chance on really focusing on your job, and have a chance to get in the zone, it’s important to prepare your work environment, so that you don’t have to care about things around you. As a team lead, it is – or at least should be – your job, to prepare and provide such a safe environment for your team members, especially the more unexperienced.

When turning wood, you have to prepare of course a block of wood, your lathe and a gouge or two and a skew chisel. But that is by far not enough. You have to prepare your environment. Are there things in my way when I move the tool, is there anything lying around loose, that might be rattled around. Switch on your air cleaning devices, clean up the floor around you, wear something that can get dirty, wear your safety gadgets, like visors, ear protection, and mouth protection. Then you can fully concentrate on your piece of wood. Wood chips flying around, dust in the air, a wider reach with your tool handle, nothing should distract you from turning that piece of wood into something round and beautiful.

When sewing this afternoon it was the same. Clean up everywhere, when ironing the cloth you don’t want to care about stuff on the board. When sewing some meters of cloth, you don’t want to think about needles falling down, where are my scissors, is there enough thread on the spindle, and so on. You just want to concentrate on that seam. So you need to prepare.

In testing it is the same. When preparing for a test session you should have everything prepared. Specifications are there, clear and precise, questions have been answered, test data is there as far as possible, the environment is in use exclusively by the test team, the latest build is deployed. All devices are there and in the condition you need them. Of course that sounds like preparation work that every tester needs to take care of by herself, but as a team lead you can prepare as much as possible for all of them.

But I tend to say, that there are more things to take care of, and it’s mostly the lead’s job to take care. Reducing the amount of distraction, try to be the point of contact for your team, while they are testing. Assist your team by taking care of and reducing administrational stuff where possible. If your company has lengthy general information meetings, try to keep them outta there and deliver them necessary information summarized. Make their jobs easier.

As a lead you should be used to distraction. SQUIRREL!!! So, take the extra tasks to cover your team’s back to give them the focus they need.

This is hard sometimes, especially when you are stuck in meetings, or want to test for yourself finally for half an hour. But in my opinion it is more important to keep the team concentrated and focused, because you won’t finish the half hour anyway without an email popping in or a colleague asking for something. So get used to it and be the concierge of the team.

Isn’t that a nice title: test concierge?

When I told my boss at the beginning of the year, that my only goal is to survive the year somehow, I did not thought of getting so many health problems until the end of the year. The reason for that “goal” was, that the budget for 2014 was not big enough to hire new people for my team, but there was more than enough work clearly visible on the horizon. I was not able to convince my managers, that there is really a need for more people. Sadly I was right and the work came and we were not enough people, ending up with bad quality testing and unhappy customers on all fronts.

Late summer I was struck with some sort of gastritis, which was underestimated by both me and my doctor. So it took 15 kilograms and ~10 weeks to be back to a closer to normal health condition again. Finally in October I changed managers and got approved a new person for the team. In November I even found a good candidate and can’t wait for January to work with him. End of November my only other colleague cleaned up her desk to take her year’s portion of vacation to fly home to India. So I was all alone, the year came slowly to an end, and with the help of my new boss I got some order in the remaining projects until the end of the year. I finally had time to do some higher quality testing again and take care of some achy back problems. Everything looked like a nice and cozy year-end. I was glad to have survived the year.

And then I got this strange feeling in my throat over and over again, feeling like a wrong hard beat. December 10th, that feeling came over and over again. After walking and talking with a colleague on the way to the underground it became more frequent and after a very short sprint to the train, I had it nearly all way home. Panic began to rise. Something was wrong with me. Since my doctor was already closed for the day and I was not patient enough to wait for the next day, I drove to the county hospital.

Of course I stayed there for a couple of days and some examinations to find out what was wrong with my heart. I tried to stay calm, relax a bit, spend not too much thoughts on my work, and I stayed away from Twitter since that day. Get some rest and get that high blood pressure under control. Every now and then I had an examination and once a day (at least Thursday, Friday and Monday) I saw a doctor. I am not much of a TV guy, and I was not in the mood for reading all day, so I was walking up and down the ward’s hallway most of the day.

Now starts the testing of the hospital, well not the whole hospital only the ward for cardiology. I am a curious person and I am fascinated to try finding patterns and processes everywhere. I did not want to disturb anyone from doing their job, so I  was mostly watching what was happening around me. I was doing some basic checks, like how many steps long is the hallway. I found out that the nurses’ room was not exactly half way down the floor, especially since some rooms close to the stairway and elevators do not belong to the cardiology. Some checks of the windows showed, that there was one window that could be opened, even if it should not be.

There is an alarm monitor in the hallway (two to be exact) showing usually the time, but also the bed number if an alarm was raised. And there were some additional markers. If the alarm was raised on the toilet of the room, if there is a technical problem with the alarm, if the heart monitor is raising the alarm, and sadly I also found out one night, when I had problems sleeping and was looking for someone to measure my blood pressure, there is an extra symbol for cardiac arrest.

There is a strict distinction between nurses’ and doctors’ responsibility. Well of course there is, but in several aspects it seems so absurd, especially from the view of a patient. I will not elaborate on this any more. Some discussions I had, and especially other patients were enough for me. And I don’t want to raise my blood pressure again.

I got a 24h ECG and for one night a heart monitor. And of course I didn’t want to check out all the buttons what they do and don’t do, because I did not want to corrupt my own medical information. But accidentally I found out that I can set a marker on the 24h ECG device, that I used, when experiencing the strange feeling in the throat again. Funny enough the software for analyzing the ECG seemed to be new, and the doctor checking my heart beats was not aware of the functionality, neither was the nurse handing me out or better wiring the device to my body. When I asked a ward’s nurse if I accidentally did something wrong with the device, nobody could help me. Come on, this is cardiology, there are several patients wearing these things every day.

The heart monitor was also an interesting device. It was sending the heart beat via WLAN to a monitor in the ward’s room to help check on the patients. Of course there was a limit on the reach, and the device began beeping. Sadly my neighbor seems to have had a bad device, and it lost contact even if he was lying in bed. More interesting for me was, walking by the ward’s room and looking on my own heart monitor. On the second evening I raised an alarm by simply walking down the hallway. Well, that was the start to an unpleasant night. Every now and then the device raised an alarm which led to a visit from a nurse, when trying to sleep.

In my 5 days and nights in the county hospital I collected lots of information how the cardiology and in some parts the hospital works. I can’t let go of testing, even if I try to.

Now I am getting some more rest to recover and get used to the medication and do some preparations for Christmas.

For 2015 I am looking happily forward to get at least one new colleague, visiting my first conference and doing better work than the last year. And of course I want to learn a lot, and not again about hospitals and doctors.

I wish all of you a very merry Christmas and a happy new year 2015!

Kim Knup’s (@punkmik) blog about the parallels between climbing and testing inspired me to pull this draft out of the drawer and finally write it.

As a tester the performance of testing is usually the craft and your product is information. Information in form of test reports, bug reports, and knowledge to share is what you produce in your daily work. To have something more substantial at the end of the day I started woodworking about 10 years ago. Some day I found my love for wooden bowls, so I started interest in woodturning. And when we finally moved to our house 6 years ago I took wood turning training with a master of his art on the other side of Munich. He did not only show me bowl turning, but also pen turning. And now the fever for both was on.

I take this chance now to compare two of my fevers. Testing and Woodturning.

Simon Shrijver just wrote a nice article about testers being craftsman. And last year, someone on Twitter mentioned that good testing is also an art. I really liked that idea, but I came to the conclusion, that testers are not artists, but artisans. That fits in my eyes good to the craftmanship.
Woodturners are at first also craftsman. You learn the craft of woodturning and you need a lot of practice. The same is true for testers. There are a lot of basic techniques and tools that you need to learn and master. But same as for testing, also in woodturning there are multiple tools useful for different and overlapping situations. You like to use one better than the other for a situation where both would fit, while your colleague uses the other. There are of course the old school tools, that are around for some centuries now. But also new tools come to the market every now and then, improving or changing the way of reaching your goal. (Of course with the same ranting as everywhere from the “oldies” that real woodturning is only when using the old techniques.)
While for the customer the way doesn’t matter in both testing and woodturning, for the tester/woodturner, the way is the use of your crafts and describes what you do every day. Of course you can tell that you turn bowls, and everyone looks at the bowl. But nobody can imagine the work behind it. In testing you create test reports, bug reports and some even test cases. But testing is nothing of all those write-ups. But it’s what you do – hopefully – most time of the day.

To be productive in woodturning and getting the best result you need sharp tools. And you often have to resharpen often. Some wood needs more resharpening than others. Same is true for your testing and your tools. They need not to be sharp, but aligned to your needs. And if the context changes, you need to realign your tools to be effective.

To be effective in your daily work you need a lot of machines and jigs, same as a tester needs many tools and scripts. For pen-turning for example you can do nearly everything on your lathe. But you are more productive with a table saw, a drill press, a disc sander, several jigs and of course your lathe. For bowl turning you might add a bandsaw or a chainsaw, and a drill to help your sanding (yes, the drill is for sanding). And some techniques or products need several more tools and jigs.
In testing you can do everything manually, but to be honest, there are so many cool tools, templates and scripts to help, assist, improve and speed up your testing, that it would be a waste of time not to use them.

In woodturning you can also have a factory-approach, of course. You simply turn the form you want a couple hundred times. You mostly improve the way to turn it even faster, but the product rarely changes. But since the product is the goal, that approach is legitimate. The context-driven approach in woodturning is when you go from craftsmanship to artisan. The wood dictates the form you turn and the tool you use. There are those artisans who take a piece of wood and see the beauty in there and make it even more beautiful. The others know what they want to turn and select the wood accordingly.

But the most common thing between woodturning and testing is the community. At least the context-driven community is like the woodturning community. There a big forums in the internet to interact online and share information, knowledge, and of course pictures of the results (later is not so true for testing).

Then there are big meetings with international audience, and of course local meet-ups. You talk about turning and all the stuff around. You can watch tool builders present their tools, you can try some your own. And you meet a lot of other turners with whom to talk, discuss, exchange knowledge and of course drink beer.

And another thing that is true for both is, that you learn most by watching. In both worlds you can write up a lot of explicit knowledge of how to turn/test. But you learn more from watching someone actually turn/test. Like James Bach said it in his keynote at CAST 2014. About every second of testing you could talk like 30 seconds. Same is true for woodturning.

And as a last feature of both I want to say that the openess to share knowledge is the same. When visiting a woodturning show two years ago I watched two of the turners for several hours, and I asked lots of questions, and also others asked lots of questions. And they never were tired of answering or hiding anything. They wanted to share their knowledge and techniques. Same was true, when I approached a woodturner from the US around the same time via email. I was totally fascinated from his work that was presented in wood turning magazines, and art shows mostly in the US, but also all over the world. But I could not imagine how he did it. So I finally simply asked him. And he not only told me in words how to do it and gave me tips, he also sent me pictures of the jigs he used. And I experience the same openess in the context-driven community.

And I want to close with the same question that Kim asked in her blog:
Do you ever compare an everyday activity or hobby to testing?

At my job it was very busy the last year. Unfortunately that meant I had not much time to take good care of my team members when it comes to coaching and mentoring. One of the things that I am interested most in my colleagues is the way how they think while testing. How does their model look like, how do they approach the situation. If I know about that, I can adapt my language and my “public” model, I can help them to understand things better and faster. And that also gives me the opportunity to know what articles, books, webinars or courses to push forward to them to help improve their skills.

Lately I had some spare hours and I tried to improve their testing skills a bit further. My intention was that they actively think about the actions they take when they analyse a requirement document and create a test plan and strategy for approaching and testing that requirement. So I gave them the following instructions:

When you read and transfer an information from the BRD (business requirement document) to a test idea, try to find out some answers to the following questions for yourself:

• how you came up with this idea?
• why you came up with this idea?
• was this the first thing that popped up?
• are there other things to mention (ideas, information, etc.)?
• will I write down other ideas as well?
  • if not, why not?
  • if yes, all of them?
    • if not, why not?
• where does this thing fit in the existing picture/model?
• what picture/model you ask?
  • if there is no picture/model, why not? Are you sure?
• are there questions you want to ask?
  • to whom?
• are there sources you want to use for more test ideas?
  • why did you not already use them?

Don’t answer them to me in the first place, answer them to yourself. Answer them for every single idea you come up with. If you start giving the same answers over and over again. Why is that? Would you like to change something? If yes, where and why? There is a good reason for all of those questions, so please take them serious and take your time to think about them.

I can give you several reasons for all of the above questions, can you too?

I know that this list of questions is not even close to complete. The intention was to start an active thinking process, what they are doing when and WHY. That way they might enable themselves to a more structured approach and get ideas where to improve themselves or find opportunities, where I can help them to improve or learn new things.

Just a short piece on a metapher I like to use, when someone tries to explain me how important bug metrics are.

“Bugs are like a piece of fruit!” But, every bug is a different piece of fruit, of different size, different degree of ripeness, and different amount of calories. Now give that fruit to a developer. How many fruits can a developer eat (fix bugs), before he is stuffed (end of the day). Do you know how the developer is eating the piece of fruit? Why not take a single grape, wash it, slice it up, remove the seeds, enjoy every bite and clean up afterwards. Or slice a watermelon, and eat a couple of bites of every slice in the same time. Leaving lots of water melon still to eat. Which means, the bug is not fully fixed, maybe to a certain acceptable degree, or not. So back to the slices and have more water melon. If the fruit is not ripe yet (bug not fully described), it needs to ripe some more. What if the developer grabs a bite, finds out he doesn’t like the taste and gives it to some other developer.

So, why do you count melons and apples and grapes with the same numbers and compare them. Or you try to get any additional information out of those numbers.

Without more information on the sort of bug, how long did it take to fix, what was the root cause, did the retest fail – maybe more than once. You just know there was a box full of fruit that development had to eat.

Just my 2 cents, why basic bug metrics are of no good use without additional information or even the story behind them.