CAST 2013: Day 1, Live and Loud

The topics proposed range all over the place. Technical, motivation and interpersonal topics abound, and the idea is that people get to vote on the topics they’d be interested in discussing. When all was said and done, the top vote getter was “determining who might make good testers if they aren’t already a tester”. 

We started throw out ideas as to how we could help determine people’s abilities, such as the “salt shaker test” or the “pen test”, just to see the way they approach the problem, and how they build mental models. Some good examples were shared, such as “the computer doesn’t work, but there are other computers that work” and what do they do? Non-testers might just go to another computer and complete the task, while a tester might go and complete the task, but then walk back to the broken computer and try to figure out why? If the person’s inclination is “call tech support”… they may not be a good fit ;).  

There are a variety of “games” (Set, Zendo, etc.) that can be put to testers to help show how people pick up the game, explain the game, or how they can see parallels in the game that point to the ways that testers think in general and some testing specific ideas that can be reflected in the game. These aspects may or may not point to “testing” acumen, but they do point to how a person thinks, and if they think critically or the ways that they think critically. One of the factors that a participant mentioned is that those people who asked questions, the ones who made a point to try to really find out what the potential problem could be, were typically good candidates for being good testers. We voted to extend this conversation, and frankly, that was a well spent eight minutes (five initial minutes, and two three minute follow-ons). 

The second topic was compiling a “Tester’s Skill List”, not so much a taxonomy but some examples of skills testers should have. Programming skills are really not high on the list for the person, but it’s definitely required for a team, perhaps not a global skill for every tester, but it needs to be in the team.  I definitely like James Pulley’s recommendation of focusing on the scientific  method as the “lesson Zero” a tester needs to know and understand, as well as practice. The ability to focus/de-focus and to know when you are “thrashing”. 

Inattentional blindness and the identifying and recognizing of biases is also huge. Having social skills and the ability of interacting is also important, Having “business intelligence” and focusing on what people really need rather than what we are interested in but what may not be relevant. Some accounting skills and the ability to put things into a perspective that the executives can appreciate/understand are also important. Justin Rohrman made the point to compile this list, and I intend to look at this more closely later. The key thing is that specific tool based skills are not really important, but macro skills are.

The last topic that we covered was ‘Intelligent automation” and the issues we face when we misuse automation. One of the key things we should do is to really consider why we automate in the first place. Regression suites are an obvious focus, but there’s lots of places that automation can do more or at least be approached from a different viewpoint. Most of us do automation all the time, we just don’t realize it. Putting five commands into a batch file and running them is a way of automation. Using a tool like Texter or SublimeText to save keystrokes is also automation. I put in the fact that I like the term “Computer Aided Testing” and while I think some were skeptical (it is longer and more wordy) I like it because it disengaged the typical thinking about automation, an then gives people another way to consider it. There is a case that testers should use the same language and tools the developers use, but there’s also a good case that by using the same code and tools, there is maybe the potential of a self referencing feedback loop occurring. By having the tester’s tools be in a different language, we make a barrier to that. 

—

Woot! How’s that for a morning kick-off?!! Time to pack up and head over to Morona Terrace and get the day proper underway. As a Lean Coffee newbie, I *like* this, an I want to do it again!!!

—

The view from Morona Terrace. That’s Lake Morona just outside our window.

I had a good time chatting with some new friends during breakfast. One of the great things about conferences like this is the fact that we get to meet new people and learn about what they do and discover new insights and ideas based on what they do and have been through. We had some fun discussing the variety of situations where we test, ranging from games and web applications to power plant controllers (now that was interesting!).

I am both excited and maybe should be a little embarrassed that I am, for the third time, taking an Anne-Marie Charrett workshop in
three years. Embarrassed because I think she may feel like I’m stalking her at this point, but to be fair, each time she’s covered a topic that has been immediately relevant to me. This year, Anne-Marie is talking about “Coaching Testers”, and at this point I feel it necessary to make a disclaimer. This is a workshop day. Since most of the attendees who come to these pay for the the opportunity, I feel a moral obligation to not talk directly to the content. Having said that, I can give a personal overview of  thoughts and ideas that I am taking away without giving a full synopsis of the workshop.

We have a group of seven, some of which I know (virtually and having met and know in real life) and three which I’ve just met today. It’s been interesting to hear what each other does, and the experience levels within the group, ranging from three years to forty years of software testing.

We’ve covered a lot of territory between us, ranging from web apps and gadgets for fun to railroad systems, from the general interest to life critical. A variety of attributes come into play and how each context is a bit different. What would be relevant to me in a coaching arrangement would be different than what another member of this group might need or should cover. Having a breadth of testing experience helps those of us who want to coach than if we were specialists of a long term focus.

Another aspect that has been discussed is “generational”. Those of us from a particular generation have a different view than an older or younger generation might. Our world view was shaped by certain experiences, and when those we are mentoring don’t have those points of reference, or if we don’t have theirs, then it can be difficult to be understood or to be effective. It’s not impossible or insurmountable, but there is a challenge there. Our style and approach will differ talking to someone our age, someone older than we are and someone younger.

—

We were encouraged to take our group and break up an do a demonstration of a coach and a participant. For our purposes, we thought it would be fun to get a veteran and a (relative) newbie participate, but switch roles.

In this case, we recommended that Sabina take on the role of the coach, and Gwen took on the role of the person being coached. We were given a hotel room composite coffee cup and given the premise “test this”. Gwen is the tester, and Sabina is the mentor/coach.

By looking at the situation abstractly, we went through a number of scenarios (can the cup hold liquid? Is the cup insulated? What is the most typical use case? What do we know about the properties of the cup? Does the lid seal the liquid inside?). The questions rolled and they discussed a number of factors as to what would work and why. We want outside and actually grabbed some hot black coffee to continue the test and see if we could determine a realistic and straightforward approach. Additionally, there are a number of human factors elements that were discussed, as well as how to make sure that the cup was easy and comfortable to use.

What made this experiment interesting was the fact that, while the example might seem “unusual”, much of the test modeling and test design process, and how to guide that process, was very similar to what we would do with designing a software testing approach. By taking the product out of the realm of the software products and what we are used to using, we were able to show that we could have even a less experienced tester be effective as coach. There were certainly challenges to work through. The immediate goal was to see what test cases we could generate, and which approaches would be effective. It’s natural to want to jump right into the testing, before we have agreed on what the value of the testing will provide and why we would want to do it in the first place.

An interesting topic, and one that is helpful when we talk about testing, and the way we speak, it eh use of “safety language”. There’s a variety of places this is used, and many of us who have been around for awhile tend to use it unconsciously. If you have ever told some one when they asked you “have you tested this” and you replied with “on these browsers, and on these operating systems, I have run the following scenarios, and based on that…”, that is safety language.

It can be very helpful to clarify in the best sense. In the worst case, it can be sen as annoying or “CYA” language. I mentioned that, often, if there is resistance to “safety language”, it may well be because the tester in question had never used it before, but started using it after a crisis situation. In my opinion, most testers tend to go out and dig into and learn about things after a crisis situation has occurred. Using “safety language” now, may well come across as hindering and frustrating, because people are already on edge. The point to safety language is not to CYA, but t make sure that communication is clear, precise and represents what we really know and what we really have done.

Also, if I were to be the one suggesting this… During a retrospective or end of week meeting, let people know you have been reading about this technique, and think it may be valuable to practice it to help communication. The benefit to doing it this way is that it shows that you are looking to help the team do better, and you are doing it at a less emotional moment. When the passions cool down, making this kind of suggestion will be handled much more objectively.

—

So this was interesting… we had earlier had a number of questions we were asked to fill in earlier in the day, and for one of the workshop examples, we took the answers of another group, and from their answers, we had to create a “Story” that we could tell to Anne Marie’s children. We had just a few minutes to write it, and no priming, just go. we came up with a silly story about the seekers of MSTC (Magical Stones of Test Coaching, which we pronounced “mystic”).

It was corny and fun, but it definitely showed something interesting. While it was fun, and a bit silly, it was also effective in generating positive energy. We were all having un, and each line was getting more sillier than the previous one. As we laughed and shared ideas, we all got into it, and while we were laughing about where the story was going, everyone was getting involved and providing some direction for the story. The emphasis on focus and time pressure can be good or bad, depending on the group gathered. We didn’t know where this was going to end up, but fortunately, we had a great time doing this.

Another interesting aspect, and one that makes a lot of sense, is that energy builds as trust builds. if we lose trust, we will likely lose energy, or develop negative energy, so it’s important in a coaching situation to emphasize ways to build trust.

—

One of the things I was discussing earlier was some of the interesting things that we can see when we work through Weekend Testing transcripts. Since there are a lot of participan
ts, we can often see a variety of personalities take part and follow energy as it waxes and wanes in participants. So yes, I thought it was amusing to see that we would be doing a chat transcript observation. The trick here is that I’m removed from the overall communication, so the context is somewhat indirect.  Seeing where the changes in energy took place, when the original questioner was challenged, was also very interesting. We can also see where defensiveness crept in, and where, when Anne-Marie lightened up the mood, the interaction would change.  These reactions are similar to what I have often seen in Weekend Testing sessions, and people’s reactions.

What was fascinating was to see how genuinely noticeable the change in tone or the change in attitude was. There were interesting tell-tale signs of frustration; spelling getting progressively worse, answers becoming curt or defensive, etc. Each table had a different example, so we didn’t go into too many details, but we were able to see in a number of situations very similar behaviors. Frustration is a real emotion and all of us deal at some level with it, but everyone has a different way of dealing with it. What’s important is that we understand when someone is being pushed and challenged, and where they feel trapped or despondent, then we need to adjust our approach. By going through these examples, we can see, albeit second hand, just how this can be done.

—

Why use printed transcripts when you an make your own, right? That was the last part of the session today, and that’s where’ve been the past couple hours (with no time to type in anything else 😉 ).  I had a chance to be both a coach and a “student”. The fun thing about these sessions were that I could make up something really out there and see ho the coach would react. I won’t go into details (and it was a fictitious situation anyway) but I played off a situation as a person who was mad about a co-worker’s “laziness”, but in truth was lazy and apathetic himself. It was fun to watch the coach pull details out and let me answer in a variety of ways, so that I would go one of two directions I’d determined I wanted to be. Either avenue would have been fun to see what the result would have been, and we did reach a natural conclusion to the issue. Had we gone the other way, it would have been a bit more intense or maybe defensive discussion, but it likely would have reached a natural conclusion, so my hat is off to my partner for this session :).

—

Final thoughts on the workshop… this was a really cool and timely topic for me. as both a lone tester who has stopped being a loner and now working with a team, as well as facilitating Weekend Testing, I think there’s a lot of great material and resources from this course. For those who want to get into learning about this, you can make appointments with Anne-Marie and try it for yourself (and if you are a member of AST, it’s a member benefit… hint hint 😉 ).

—