Day 2 at #CAST2013: Live and Dangerous

It's an early morning start time, and once again, we have an early bird gathering coming together to hold another Lean Coffee. This is the second day and we have new people coming out to participate. As a primer again, Lean Coffee is people getting together, deciding on topics, and then discussing them.

This morning, we've been talking about how we can bring information back to our team and encouraging new techniques. For many of us that attend conferences or are otherwise digging in and engaged with the broader community sometimes find ourselves at these events being surrounded by the faithful, and then getting back to our teams and finding that implementing new ideas is a challenge and a struggle.


The general consensus is to come back and try to find small key things that we can implement ourselves that do not require a lot of buy in or permission, and let those ideas filter in naturally. If that's not possible, then use a number of techniques to introduce ideas in a casual environment, such as an end of week happy hour, or a tool day.

Visual coverage maps are an area that people had a lot of interest in, and how to use them. The implementation ranged from computer based systems to a white board and sticky notes. The key was to find a way to get the the information to be seen, and to allow people to add and modify the data.

In open office plans, a question was to see how people could deal with heads down time vs. being available and dealing with issues. Finding a balance and respecting others space was something a number of people dealt with, and shared some interesting ideas. Using group Pomodoros, or having an IRC chat with an agreement that pings will be acknowledged, but name changes respected for quiet time were championed.

I'm not sure if the late night last night had an effect, or if it was just that we were doing this the second day, but the atmosphere was a bit more... subdued this morning. Still, it was a lot of fun and I'm grateful that there are so many creative and passionate testers to confer with.

---

We are starting the day with Jon Bach's Keynote "Lessons Learned From Argument".  He opens with a rather provocative quote from his brother James:

"Some one has to be an ass----.
  Polite people are not going to change the industry
  --- they are the ones who made it the way it is."

The point that Jon wanted to make was the fact that there are many ways we could respond to such a statement, from calm and polite to brash and aggressive.

Jon makes the following thoughts about why argument is important. First, we need to claim our own territory before we can/will recognize my opponent's side. If we say we all just want to get along, then there's no side to argue, because there's no position. There's no territory.  Territory isn't  meant to be belligerent, it's a way of declaring "this is who I am". Once we declare who we are, we can determine if we want to stay that way, or if we want to be different. It lets us know what we think we know, and where we feel safe. It also helps us determine our values, and what really matters to us. Th point is, all of that needs to be declared for there to be an argument. Are we willing to say that we don't have any of the above? If so, then we are saying we represent nothing... and I've just staked territory making that statement, and I'm willing to bet some people will want to argue with me now ;).

If you want to avoid argument, if you want to be free of contention, then you probably should choose another career other than software testing. Wait, what?!! Well, step back and think about it. What are doing when we file a bug. We are, effectively, looking at a situation, staking some territory on its state and condition, and we are willing to invest both technical and emotional capital to see it get resolved. That's argument, plain and simple. Arguing is "exchanging reasons face to face" (Dale Hample).

Are there other ways we can approach the issues? Do we have to be the proverbial "ass----" to make our point or get to a place where we can be heard or change opinions? Jon suggests that we can argue without maiming ourselves in the process. This reminds me a lot of the situation in the Bruce Lee movie "Enter the Dragon" where Bruce Lee takes down a bully with the phrase "my style is the art of fighting without fighting". I won't spoil it for anyone who hasn't seen the movie, but let's just say that Bruce does win the day, and does so brilliantly. Jon is making a beautiful case for the art of "fighting without fighting". Not "capitulate". Not "be wishy washy". Instead, argue for more information. Argue to understand their point of view. Argue to get more information. Argue for the privilege to be proven wrong. Yes, reread that last statement. Argue for the privilege to be proven wrong. That requires you to be willing to state your opinion, stand by your convictions, and share your reasoning, but be open to the reasoning of the other party. Then actively consider what they have to say, and make a decision or a consideration based on the evidence. You may be right, but you may be wrong. At the end of the day, does it really matter, as long as truth an sound thinking wins out?

James Bach said something akin to the following on an earlier TWiST podcast, and it paraphrases to "I am a man of strong convictions, but I hold them very lightly". What does that mean? It means that James will fight tooth and nail for the things he believes, the things he holds dear, the convictions he has, but he reserves the right to be convinced otherwise, and if he can be convinced, he is perfectly willing to drop the previous conviction. Some might call that being "wishy-washy". I call that active reasoning and application of reason. Dogmatism is what causes many of us to be mired in fallacious thinking and reasoning, and we argue at a disadvantage when we do that.


The "Testing is Dead" meme of course gets play (second year in a row as part of a CAST keynote; Elisabeth Hendrickson addressed the theme as well in last year's keynote). There are many ways we can respond to this, ranging from full force bluster to active questioning, i.e. "what do you really mean when you say that?" You can play the partisan, or you can notice the contradictions, and point them out. When I, personally, say I'm not interested in Partisanism, I mean it. I would rather know why people feel the way that they do and what reasoning they are applying. In many cases, when we actually understand the full context, we may get a fuller picture of what they are saying and why they are saying it. If Testing is Dead means that the traditional "brain dead" approach to testing, the fake checking and rubber stamping, then let it die, and replace it with something much better.


Final takeaway, argument isn't the problem, I AM! What we argue reflects what we are, so let's decide if we are what we want to be first. Additionally, if we are willing to be open to who we really want to be, then we have a much better chance of creating persuasive, non-partisan, genuine arguments. Let's elevate the fight, and let reason do battle. The better reasoning has a much better chance of winning, but both parties need to be willing to set aside the partisanship to make that happen. Again, that's not "can't we all just get along". It's "let's reason from a position of respect" and if it gets heated, that's OK. Stick to facts, and be truthful with your opponent and yourself. With that, argue away :)!!!


---

The second session that I am attending is one about how Rapid Software Testing (RST) was applied to and used by Primera. This talk, by Paul Holland (RST Instructor) and Brian Demers. As one who alone knows a lot about RST, and personally tries to apply it to my daily work, I was curious to see how this could be applied to a broader organization and, possibly, see ways I might be able to use and evangelize the approach in my own organization. In other words, how does a solo RST advocate encourage an organization to "go corporate" with the initiative as a cultural norm?

Between December 12012 and January 2013, they ran a "Keep, Stop< start" session with each corporate QA group, and came up with a set of goals as to why they would feel RST would be a logical approach. One of the challenges was that, when stressed, many testers and organizations would revert to their traditional methods. Also, they feared that a top-down mandate would be counter-productive. Instead, they worked to see what the people in the trenches who were actually using it felt, and where it was effective.

Numerous individual testimonials from testers helped to spell out where the RST approach actually helped transform their testing, an ways that they could leverage the benefit of spending less time on documentation and procedure, resulting in more focused and better testing. Paul makes the case that about 20% of the time spent with traditional/factory approaches is roughly 20%. By putting a greater focus on the RST approaches, the time spent in testing rose considerably. The challenge, though, is that a lot of this data is self reporting and subjective. One of the bigger challenges that they faced in this process was to find ways to be able to make more objective the evidence of better results and more productive testing by using RST. As they went through and did some analysis, they discovered that about 70% of the bugs they found (objectively) were found by active testing and exploration. Scripted test cases found around 30% of the bugs.  They are continuing to monitor and determine if the changes made are yielding positive and measurable benefits. While it's still early, the evidence looks to strongly be in RST's favor.


---


Next up is IlariHendrik Aegerter, and he is talking about failure... What is it? How does it affect us? Failure is a word that invokes strong emotions. It has a bad connotation in most instances, and we would hope that we could learn from our failures.  We all have failed at various points in our lives, in both minor and possibly major ways. Pradeep Soundararajan points out that "the best way to recover from failure is to learn from it."

There are multiple paths to a failure. generally, if we set out to do something,, we either succeed in completing the objective, or we do not complete the objective (i.e. we fail). But aren't there more options here? Jut because something "works", is it really doing what it should do? Failure can also be seen as not doing something (block a file from being erased, etc.).


Failures have scope. They range from personal to group, to company, to community and beyond (we hope we don't end up seeing a World Failure anytime soon).


There are ways that we can accelerate the chances of failure occurring. We can neglect relationships, we can crete a hostile environment, we personally can be a "pedantic ass----", and there are a host of other potential options. Incompetence can come into play. If you can't program, writing automation may not be a good choice. Your competence would be a huge factor here. Prioritizing time can be a huge issue. Being afraid or avoiding areas leads to failure by never attempting to do it. Procrastination or lack of motivation can definitely do you in. There's a long standing joke when it comes to putting together talks and presentations that many of us wait until the "last irresponsible moment". No, that's not a typo. A lot of us have done this, and probably continue to do this (I owe a lot of thanks to Ale Moreira, since without here willingness to review material for me, I might well still be modifying my talk and presentation.


In the software testing world, we tend to suffer from a large amount of ignorance about our choice of career. I'm talking about the entire body of software testers out there, which admittedly run a wide gamut of experiences and understanding. We also put so much emphasis on documentation and secondary products of our work. Test reports, test cases, matrices, etc. They can be important, but we tend to put too much emphasis on what they provide, and what they often provide is greatly outweighed by the amount of time and energy put into creating and maintaining them.

We understand that there are may ways that failure comes about, but if we learn from the failures and move on to do better work, then that need not be a tragedy. However, if we are failing and not learning, and repeating the actions over and over again, then we have a big problem on our hands. Are we doing all we can to learn from our mistakes? What can we do to not repeat mistakes? If we are anti-certification, what are we offering that will countermand that? If we are peer-certifying, how do we know we are able to really vouch for the skills of the testers we are endorsing? How can we build better relationships with executives? What other ways might we be able to do better and learn from  and act on our mistakes? How do we produce leaders that are influential outside of our own circle? How can we help support better "evidence"?

My take... there's a lot of things we can do, and a lot of where we fail and get trapped are areas we can actually control. First, for each person, find the persistent failing areas that are closes to you. Why? They are the ones that you are going to be most likely to do something about. From there, reach out, join with others, and tackle the persistent failures that are further away. It may be impractical to talk about solving broader community failures (world failures an even bigger order of magnitude) but we are much more likely to take care of those failures that are farther away if we can tackle and resolve the failures that are closer to us.


--

The live blog will be taking a break at 3:00 p.m. Central time... because I will be speaking live. For those who want to watch it, the webcast is streaming here.

...and I'm back. That was amazing, scary, fascinating, frustrating, crazy, cool, freaky and awesome all rolled into one :). Overall I think the talk went well. My thanks to those who came to view my talk in person, and to those who watched my talk online. I thank everyone for their support, their questions, and those who have offered to help bring this program further forward.


I was a late arrival for Erick Brickarp's talk about "Making Learning my Top Priority", and how he focused on becoming a more dedicated "autodidact", By focusing on how to recognize areas where we can leverage our skills to learn, and how to dovetail initiatives into other areas.

I love this topic, and it's one that I likewise spend a lot of time thinking about. Erick shared some examples and some methods on how he took on a number of learning initiatives, including preparing to speak at a conference after he was convinced he couldn't do any such thing. I'm glad he changed his mind because I think he did a great job. 

It was interesting to see how he prioritized his approach to learning, and his answers rang true with my own. I find it somewhat hard to take on bigger learning projects, since there's a big body of knowledge to digest, but when I can condense or collapse ideas into smaller areas, it's something that make even massive projects doable.


--

The day's presentations are now over, but there's more testing and facilitating to come. It's Lightning talk Time, where five minutes to speak and a few minutes to facilitate are all ya' get, and we can tal;k about anything.


Julie Hurst came up and explained what it tok to get her up on the stand to begin with.


Peter Schriver talked about how the decisions for product deliver can have a detrimental effect on the work life of testers. Work to be realistic in your schedule, and be realistic with your estimations. Slip the schedule, save the emotional and physical well being of your testers.


Rachel Carson shared some ideas about how to do more powerful paired testing, and making the changes necessary to leverage the pairing relationship.  Great suggestions related to chartering and SBTM.


Lanessa Hunter did a talk about Lessons she learned about testing from GUMBY (yes, the cartoon/claymation character). These lessons relate to areas like relationships, challenges with structure vs. no structure, how things are vs. how things should be. He's clay, things bounce off of him. She learned to speak up, she learned to lighten up and not take things so seriously.

Natalie Bennett talked about being "The Weird Aunt With Obnoxious Toys", and the fact that she decided she didn't want to consider herself as being an antagonistic tester, and in the process, she started thinking about her uncle who brought he most obnoxious toys possible. He wanted to bring cool toys for the kids, and the noise was a bit annoying to the dad, but overall was a good dude and fun. In many ways, she as a tester makes her the crazy aunt bearing gifts, and she loves it :).


Ale Moreira is a context driven tester who works in a factory testing environment. She's been on  crusade about how she's shaking things up. If you are going to talk to someone who is agains context-driven testing, try to focus on what they don't like, and try to se if you can explain it in a away that may make them reconsider. Don't change a big thing, but start with a small project or try to rework or refactor a project that is already in place.  Be prepared to compromise and understand how to work within their comfort zone as you aim to move in new directions. Have evidence and demonstrate it.


Jessie Alford did a talk about focusing and defocusing called "Focusing the Mind's Eye - An Optics Analogy. Focusing and defocusing is not easy. It can be a challenge to stop focusing. The professional photographer is an interesting parallel to the software tester, and their ability to frame the information in the context that they care about. If you are really focused on something and you can't get it resolved, take some time to get away from it. Defocus.

Olivier Mireault has made the suggestion that software testers should become Toastmasters, which is focused primarily on public speaking. Toastmasters has a public speaking element, they have a leadership component and both are good ways to improve communication.


Take the time to do both and get involved. Being able to practice and prepare helps everyone get better at speaking, leading and contributing to a broader community.



Jon Bach talked about an idea related to "Open Book Testing" and used eBay as an example. I enjoyed hearing how quickly he could pull off the top of his head the various ways his software would respond to various questions. I've seen him give this talk before, but it never ceases to amaze me how quickly he can rattle this stuff off. The Open Book Exam approach is a great way to see how quickly test ideas can be spawned and created.

The last lightning talk position fell to me, and I talked about the idea of making action plans of our good intentions, tackling stuff that is scary and encouraged everyone to "Just Do Something, Already!"

And with that, it's off to dinner and socializing. Thanks for coming along today :).