Lean Café, a Half a World Away - Live Blog From #AgileTD

The past few days have been extraordinary, to say the least. Starting with a flight from San Francisco to Instanbul via Turkish Airlines, I had a too brief layover in Istanbul (one of the few times I've genuinely wished that I had more time between flights so I could get out of the airport and explore the city). The stopover in Istanbul was also noteworthy in that this is the farthest east I have ever traveled from where I have lived most of my life (i.e. California). Sure, it was just a stopover to get another flight to Berlin, but I set my feet down there, so it counts ;).

The flight to Berlin was enjoyable, and for the record, Turkish Airlines offers wonderful service, even to the economy passengers like myself. If you get a chance to fly with them, I encourage it. I landed in Berlin about 10:00 p.m. local time, and most of the services in the airport were closed. I was fortunate to have the information desk open, and when I asked them how I could get to the the Dorint-Sanssouci resort in Potsdam, she returned with a printout that had a bus route to a train, and then a train to a tram line, and then a walk to the destination. Part of me was dismayed (seriously, are there no cabs at this hour?), but the tester in me also smiled and said "OK, challenge accepted!" It made for a much more fun experience, and I had a change to see a lot more of the city this way, as well as the approach out to Potsdam. I will confess, the tram dropped me off at Park Sanssouci, and as I walked off at just before midnight, not a soul was around. No cars, no streetlights, no house lights, and I really wondered "where the heck am I?" Fortunately, a brief walk to the west, and I saw the destination. Made it!

Monday was a day to adjust and get used to being nine hours ahead, and also to get a chance to see the sights in and around Potsdam (courtesy my friend Mieke Mertsche, who showed me around and introduced me to several of the local details, including Red Bull Cola, and its characteristic pine tree flavor (seriously, it's in there :) ). Additionally, the speakers dinner took place in the central area of town, with good dinner, great conversation, and a chance to catch up with many friends both personal and virtual (it's still a little strange each time I have someone walk up to me and say hi, and then realizing they know me through my blog or via Twitter. Awesome, but still strange :) ).

Today being Tuesday, the Agile Testing Days conference has gotten underway proper, and first order of business is Lean Coffee (or Lean Café as the sign says). For those not familiar with Lean Coffee, the idea is that everyone writes down topics that they would like to talk about, then everyone votes on the topics they want to discuss, and a queue is made based on the votes. Each topic gets seven minutes to start, and then based on the energy in the group, more time is given to those topics until the energy runs out.

A topic I put into play received the top votes, so I presented the topic of "Testing and 'that other stuff'". In my daily reality, I test, but I do other things, specifically related to being a release manager. At times, it seems that I get more interest and attention towards my efforts to improve the release management process than i do as a software tester. Part of that, I think, stems from the fact that release management is an infrastructure and delivery problem, and it has a very concrete problem. either the builds are deployable, or they aren't. Testing has a lot of fuzz around it, i nthe sense that there is a lot of work done, but there's also a lot of judgment that can be applied to what is to be taken care of and what can be deferred. IT's all important, but in smaller teams, I don't have the luxury of being "just a tester", I need to be able to adapt to additional roles and needs. Frankly, I'm totally cool with that, and I've appreciated the opportunities to get involved in other areas. Still, at times, I've wanted to see what could be done to help encourage and improve the visibility of the testing work I and my team are doing. One suggestion to increase the visibility of testing is to have specific stories that showcase the testing effort, as well as the time it takes to do the testing. Fact is, people respond to the immediate needs, and if your role affects immediate needs, chances are people will pay closer attention to what you are doing when it directly affects what your team needs to accomplish their goals.

The next topic was "how do we incorporate more UX and UI design options into our work". For me, the biggest way that we can help with this is to get involved early in the design and discussion process. We use a three amigos approach to story development, and in that way, design, programming and testing get together to discuss the options available, and how we can put testability into the design, and to encourage UX from the beginning, rather than having to improve it later. One way that I have started to think about this especially (and a foreshadow of my talk tomorrow) is to focus on ideas of "inclusive design" where possible, and to encourage the idea of making the product as usable as possible by the largest volume of people. That process can really help drive UX discussion.

"How to do BDD 'Right'" was the next topic, and there have been a variety of experiences with trying to use it in organizations. Cucumber is a popular framework for this, so it's not uncommon to have people think of Cucumber as BDD, but it's just one way of doing it. The real focus behind BDD is the fact that Behavior is the primary focus, and the testing is based around the desired vs. actual behavior of an application. BDD affects UX and UI interactions, as well as other "ilities" of a product. Ideally, making tests that focus on individual behavior characteristics are going to be the most effective. Trying to cram multiple behaviors into a single test will make tests more complex and more difficult to maintain as time goes on. By keeping the behavior characteristics as simple as possible, and as atomic as possible, then tests are more specific, and ultimately easier to maintain.

"Starting a new team" focused on the issues of creating a new QA organization in a company. I've been in this situation a few times, and each time has been as unique as the teams hoping to implement the new approach. Testing is important, and it needs to happen at all levels of the product and process. Having a QA "role" may or may not be appropriate, but testing is going to happen, and absolutely needs to happen. Everyone needs to own quality, and everyone needs  toe be a part of the testing equation. Encouraging a culture of continuous testing takes communication and setting an expectation that everyone needs to be involved in testing. If there is a dedicate tester role, more important than just testing is being able to share important and actionable information. Learn what the team does to share information. Learn how the team wants to deal with issues and defects, and the tools and infrastructure that is in place. Most important, testers need to learn the application they are working on and get as much experience with it as possible. It seems obvious, but that step alone really helps to get a feel for what is a nice to have and what is absolutely essential.

All told, a great start to the day. Looking forward to the next session. stay tuned for further posts (as I did at CAST, I will make a new post for each talk or topic). More to come, stay tuned :)!!!