Green Grass and High Tides: Day Three at #esconfs

It's been a great few days here in my briefly adopted home. So many great opportunities to speak with friends from the Twittersphere, blogosphere and other arenas where personal "meetspace" has not been a factor, but having that in person opportunity has proven to be so worthwhile.

I've had the pleasure of meeting so many virtual friends in person, with a highlight being meeting and enjoying dinner with Julie Gardiner (new in person acquaintance) and Dawn Haynes (who I've known in person and have worked with in various capacities the past few years), among others. The awards dinner was held last night at Croke Park, home to a rather large stadium dedicated to Hurling and Gaelic Football. Below for your amusement is a shot of yours truly trying to get his hand on hitting a ball with a hurling stick (and if I'm mangling the lingo, please forgive me ;).

A bit about Dublin. The city center is small, easily walkable, with lots to see and do. The blending of old and new is everywhere apparent. One of the buildings that I saw had an inscription over the top saying it was for the "British and Irish Steam Packet Company". I am not even going to pretend to know what a Steam packet is, but it was cool to see these old buildings now being the current homes of telecommunications and web design companies, among other things.

tody is the final day of the conference proper, and there's a change in the program. One of the Keynote speakers had to drop out at the last minute, so my friend Shmuel Gershon will be delivering the morning address. Speaking of which, I should get up there so I can actually report on it.

---

Shmuel started his talk with the fact that our world is completely dependent on software. Fifty years ago, this was not the case. Seventy five years ago, there was no software to speak of for the vast majority of people (and for those who did interact with it, it was in its infancy). Today, we cannot imagine living our lives without it. In some ways, we as people have a chance to have a taste of virtual immortality. It's both macabre and fascinating to think that things like my Twitter account, my Facebook feed, or this blog could conceivably live on after I do.  Our ability to "persist" outside of the memories of our families and friends has, up until now, been limited to a small number of celebrated people (politicians, philosophers, scientists, celebrities). today, common everyday people have a chance to have a piece of their ideas and ideals live on after them.

We look at books as a way to retain knowledge and transfer knowledge. This has been a means of transfer for hundreds of years. they are permanent, solid, and transmissable, but they are difficult to change (books need to be reprinted to get new versions into peoples hands. Today, with the development of software and electronic books, updating those titles is much easier, and the distribution is as simple as a button click.  In previous years, if a publisher wanted to send me a physical book to review, it incurred a printing cost and a shipping cost to get it to me. Today, most of the books I review come in the form of PDF's and through email messages, with links to download. There is a cost associated with it, but it is much smaller than before, and getting updated copies are, again, just a button click away.

Software is more than just a product. It is now a primary means of transferring knowledge and information. Having a product by itself is no longer sufficient. Now we need to be clear that the software we are producing is actually capturing and transferring the knowledge that we have and understand. This change is also filtering into the way that we test. Having the functions work the way we expect it to not enough. We need to make sure that we are transferring knowledge and sharing information with our software creations. Programmers are filling software with knowledge, bot tacit and explicit. we need to be clear that we are able to make sure that both the knowledge and the mechanisms to transfer it are intact. That's an interesting shift in mental paradigm.

Shmuel used the example of how Portugal was looking for a way to get to India via another route than around Africa. The mission was to find a new route to India, but in the process, the explorers discovered the South American country of Brazil. The technical mission could be considered a failure. What are you doing wasting time on this place called Brazil? You need to find a new route to India. Fortunately for Portugal, they saw that the discovery of Brazil was a fundamental change to their world and their interests. In other words, the goal of reaching one mission successfully could be seen as a failure, but the discovery and new opportunities that come from it can be substantial. Let's not be so myopic that we miss the great opportunities that we may literally stumble upon.

Most software that is developed that has staying power (think of many of the most prolific and long lasting UNIX tools) start as a need to "scratch a personal itch" for the programmers that are creating them. Most of the tools that we use and that are successful, especially the ones that have deep penetration and are freely available, their staying power is specifically because the needs that they met are generally universal. They scratch a personal itch, to be sure, but it's a good bet that the itch being scratched affects a lot of other people. Getting that feedback from others helps to determine which products will stand the test of time. The products that scratch the highest numbers of personal itches will have staying power.

When we are testing software, it may feel strange to think that we are really testing the transfer of knowledge, but once we do get that, our very vernacular of how we talk about the work we do changes. We live in an era where knowledge can be nurtured and developed in a variety of ways. Ultimately, we need to get out of the mindset of "have we shipped the product yet" to "are we providing our customers with the best way to help them transfer knowledge that is essential to how they do business". Shmuel gives us a bold statement to consider. "We are not shipping a product, we are sustaining and preserving civilization". Try that on for size for awhile, and see if that doesn't make you think about things a bit differently ;).

---

Next up is "Testing Traps to Avoid in Agile Teams" with Janet Gregory.  Having spent the past few years working as an embedded tester in an agile team, both as a Lone Tester and as a part of a broader testing team, I definitely have lived through much of this.

One of the aspects that has been a big change is the idea that we have to wait for a build before we can do any testing. I do remember this well in my previous team because we had a push to a demo machine that needed to be done. The term mini-watefall gets thrown around, but perhaps a better term is the "ketchup effect", where the testers are tapping on the ketchup bottle and waiting for the ketchup to come out. when it finally does, it hits the food with a big chunk of ketchup. testing is like this when we have to wait for the build to do our testing. In my current environment, we have set it up so that all of us have access to the build environment and build machines that we can access. I am able to load a build within minutes of a programmer committing changes. It's really cool that, on any given day, I can have a chat with the programmer about something they are working on, them alerting me that they have committed a change, an I can load that build within a few minutes of that change.

More to the point, there is a lot of testing that can be done between builds, and ways that we can loop around on the testing needed with the idea that, once we get the most recent build, we can get back to see the changes.

I know the feeling of having the programmers be the Agile component, where I was on the outside of the development process. I have had to wait until the stories come together before I can do any meaningful testing. This can still be a problem where I currently am, but we have been encouraged to be part of the process as early as possible. We practice the Three Amigos model, and that Three Amigos approach allows us to get involved very early in the process. Still, even with that, there are many times where we are waiting for DevComplete to occur before we get involved on a story beyond that first kickoff. At times, we have been able to do direct paired programming and testing, but it is more common to have the programmer do the initial work on the story before we get into the main testing. At times it can be valuable to get in immediately, at times it makes sense to wait until everything is in place for the first round of testing. We don't have to always be inserting ourselves into the initial programming, but if we can be helpful to the programmer during that early phase, then by all means, let's do that.

I've long struggled with the idea of being the "Quality Police" and trying to get out of the mindset of being the person who says "go or no go". By getting the team to focus on the quality of the product, rather than just the testers doing the legwork, we are able to get everyone's eyes involved and engaged. One of the things we do in our stories is we get into looking at acceptance criteria and the implementation. We don't file bugs for stories in process. Instead, we work through issues we discover and put the story back on the line. It's been a system that has worked pretty well, but there are ways we could probably do it more efficiently or with less turnaround time. A tighter feedback loop would certainly help with this. Additionally, testers should become more technically aware and understand the programmer's vernacular.

Automation is important, but there's a lot of testing that should be done manually. Having said that, there's a lot of repetitive work that should be automated, and keeping on top of that is a big job. Currently, my efforts are focused on more manual testing, but everyone on the team has both the ability and the chops to do some automation work. We have a dedicated automation toolsmith to handle the bulk of that work, but we all have the ability and the expectation to help out where we can. Still, there's a fair amount of automation that I think we could all be doing on the team to help us get ahead of the curve.

Having a large suite of automated tests, both at the unit test level and at the integration level, helps us keep on top of a number of things. There's also a fair amount of modification that has to be done from time to time. We try our best to make sure that the testability  is there, and that the automation doesn't need to be modified regularly, but of course, things happen and new features get added all the time. The key goal is to focus on getting our most general tests and workflows automated, so that we can look at the special cases, or allow us to explore and look with fresh eyes on the areas that we may not be covering yet (am I sounding like a broken record with that yet ;)?).

One of the bigger dangers is that we sometimes forget the big picture. When we work with big systems, (or when we do some large scale update) we can get myopic and focus on something too intently). Sometimes these large focuses conflict with what other people do (some changes for accessibility, as an example, have had to be reconsidered because large swaths of automated tests ended up breaking because we shut off access to elements that we didn't intend to. Making thorough workflows and making sure we can complete them from start to finish, and in parallel with other workflows, can be a big step in helping us see how workflows interact and have a carry-on effect with other workflows. In our environment, every story has a unique branch that gets merged to the main branch, and going through and making sure that these dozens of parallel branches keep the peace with each other is an interesting process.

So overall, I recognize areas where my team can improve here, but overall, I think we do pretty good, all things considered. I'm looking forward to seeing how we can refine this list over the coming weeks and months.

---

Next up, "Diversity in your Test Team: Embrace it or lose the best thing you have" with Julie Gardiner. Julie has been someone I have seen multiple times, but never in person. She's been recorded for various conferences, and I've enjoyed her delivery and sense of humor, and the people aspect she delivers in her message.

Just like there is no one size fits all in test cases, there's no one size fits all in testers, either. Diversity is a hot topic at the moment, but too often, we talk about diversity when it comes to the makeup of the team members alone. It's not just about their genetic makeup and the variety thereof, but the skill sets that they also bring to the table. When we look at getting different genders, different cultures, different life experiences, and then insist that they all do  the same work the same way, we are totally missing the point. True efficiency and effectiveness from the team needs to consider what each person brings to the table, and works to maximize those efforts and abilities, while respecting the fact that not everyone is interchangeable. Some are familiar with the Dreyfus Model of Skills Acquisition. It's a good bet that, even if we get a roomful of people with similar skills and technical background, we would be able to plot the levels each persons skills fall on the scale from one to five (or Novice, Advanced Beginner, Competent, Proficient, and Expert). If we are truly honest, there will be a continuum with all of the skills represented. By being honest with what each person can do, we can give them the guidance they need, or we can give them the freedom to do what they do best.

Group dynamics are also part of this equation, and the ways that people communicate varies. Julie put up a questionnaire and some ecxamples of communication styles. Julies'e examples are listed in the pictures. I'll post mine when I have a little more time ;).

The idea is that, if we take the number of each side (x and y axis, we can plot where each person lands on the XY grid. As you might guess, few people will be in the same place. There will be a broad distribution, and the more people we have on the team, the more likely the list will be distributed. The general breakdown has four quadrants, and in those quadrants, we have The Pragmatist, The Facilitator, The Analyst, and the Pioneer.

Each are an archetype, and if we are honest, each person falls on a continuum of each (few are totally one quadrant). The point is, each person is going to approach their work, their communication, and their methodology. managing these people are going to require different approaches, and each will have different needs.

Change and process improvement also fall on a continuum with people. Not everyone is comfortable with dramatic changes. The Pioneers are more likely to be, while the pragmatists are less likely to be. The facilitators are game if they can collaborate on the process, an the analysts will want to see the theory and work the problems to be sure they are on the right track. Do you recognize yourself in these representations? Do you recognize your team members? Are they duplicates of you? Of course they aren't. They have their own distributions and their own avenues for how they like to work.

The key takeaway is that we need to be more aware of the fact that diversity is more than just gender, ethnic background, sexual orientation and the typical breakdown that we keep hearing about. Don't get me wrong, those are very important, and the greater the distribution of those items, the more likely you will get diversity in the areas of thought, personality, problem solving and skills. If we do all of this work to get people with differences, only to insist they shape themselves to be replaceable cogs, we are doing both them and our teams a huge disservice.

---

The closing keynote with Zeger van Hese, titled "Everything is Connected - Exploring Diversity, Innovation & Leaership" started with an explanation of Myers-Briggs types, and Zeger's personal distribution and what those things mean. The inspiration for the theme looks at a tribar of  diversity, leadership and innovation, and the interconnectedness of those aspects.

There's linguistic diversity, which introduces some interesting terms I had never heard before, and how those terms are unique to their cultures (it's cool to see there's a term in Japanese that's a single word that stands for "the condition of buying books but not reading them so that they pile up in a great big stack on your desk". I needed that sentence. Japanese have one word ;). A variety of responses are needed to be able to meet the demands of an organization. Hiring variety allows for the ability to get people from a variety of backgrounds to make a diverse and creative team. If we focus too hard on getting people like us, or that think and act like us, we should not be surprised when what we get is a generic and bland response, because everyone basically is the same.

Randomness and serendipity is also important, since there is an interesting variety of options that can take place when we are ope to allowing that randomness to take place. However, don't misconstrue randomness and serendipity with just winging it. Preparation and readiness is necessary for randomness and seendipity to be effective. It takes time and effort to be prepared, but when yo uare ready for anything, then anything can make its appearance ;).

Ask yourself, are you creative? Most people will probably say they aren't (about a third of the room said they were). I think we short change ourselves. Many of us are able to be very creative at times, but we assume that, unless we are insanely creative and productive all the time, that we do not have true creativity. That's a false equivalence. Being creative is a state of mind and action based on stimulus and a willingness to respond. We equate creativity with quality, and frankly, most of us do not start out with quality creations. We frequently suck when we start something. I appreciate the long time readers of my blog, and those who think I write cool things. as of today, I've put 926 posts up on this blog, and that does not include the dozens of entries that I deleted mid way, and perhaps the hundreds of entries that never made it into a post at all because I thought it was junk.

Creativity is not just a spark of inspiration. Often is starts that way, but if you haven't put in the time and energy to develop the skills necessary to use it, it won't matter very much. Don't take that to be to pessimistic, it's not meant to be. What I mean with that is that many of our efforts are going to be less than masterpieces. Of those 926 posts, half of them are below average (by definition ;) ). Half of them fall below the median of quality as well. Still, if you were to ask ten different people which of my posts deserve to be above or below that median line, you might get a broad variety of answers. that's because what is good matters to the person who is consuming the data, not the person writing it. You may think the Princess Bride is one of the greatest movies of all time. Someone else may decide it is a completely corny movie. What matters is not what other people think, but what you think. Your desires and motivations will help decide how you feel bout certain things.

Leadership needs to be able to handle the diversity mix for it to be effective. Again, leadership is something that we as a general population seem to have a problem it. Part o this is the fact that Leadership is sold as this insanely altruistic or hyper-focused attitude. We automatically think that the leader is the alpha dog, and that's not necessarily the case. Everyone has a bit of leadership ability in them, and under the right circumstances, those leadership opportunities can be sought out and applied without feeling one has to be a general or a manager/director.

Sometimes we suffer rom the status quo bias, where we tend to struggle with reconciling "new" with "useful". We may miss opportunities because we do not see the benefit. If we were more honest,  we might even say that the opportunity scares us. we can't turn off that fear, but perhaps we can channel those feelings more effectively. ure, there will be abrasion, there may even be genuine fear and frustration, but by embracing and making room for that ambiguity, we can let real creativity develop.

With that the official program ends, and an announcement of Eurostar to be held next November in Maastricht, Netherlands has been made. My congratulations to Ruud Teunissen for being the conference chair this year, and my thanks and gratitude to Paul Gerrard for a Yeoman's work at being conference chair this year. To Paul and the staff that helped put on EuroSTAR this year, may I say "well done and thank you".

---

You thought I would be finished, but you'd be wrong. There was an after conference session about "Programming for Testers" that I found to compelling to pass up.

Anyone familiar with my blog knows I have answered this question many times. Do testers need to be professional programmers? No. Is it advantageous? Absolutely! Do I code? Enough to be dangerous. Am I a professional coder? Nope, but I strive to learn enough to be both dangerous and effective.


Therefore, I'm glad to put myself into a play time situation to see how the two instructors want to cover this topic. More than just write "Hello World", we're actually going to control some external devices, such as a robotic arm using a Raspberri Pi device.



A hop, skip and a jump, a Python distribution download and a Geany download later, I am ready to go... I think ;).

Python installed, Geany installed.

A few lines of basic code, a compile and an execute, and here we are:

wow, this feels like "Learn Ruby the Hard Way" all over again (LOL!)

Create two numbers? Sure, we can do that :):

declare two numbers and print the two numbers. Whee!!!

And now let's multiple two numbers and print out the string:

it works, and it feels good :)!!!

Something a little more interesting? OK, here's a loop.

And here's a comparison:

Moving along very fast, here's a Raspberry Pi, running a robotic arm, controlled by a Wii Controller. Yep, a bit of a code jump, but not too insane ;).


And with that, I'm off to tour the Guinness Storehouse... cue the jokes about the guy who doesn't drink touring a world famous beer factory. It's OK, I'm used to it ;). Again, thanks very much for playing along, it's been a fun several days. Dublin, you've been fantastic, Eurostar, you have likewise been amazing. Happy Thanksgiving to all of my U.S. friends, and to all else, enjoy the rest of your Thursday :).

Making testers very happy... OK, who wants mine (LOL!)?!