Bonus Round: #TLCAMP2013: Test Leadership Camp Live

It's been an amazing week, and we've covered so much ground, but we still have one more day of "doing the thing with the stuff", and that day is today. I am attending an un-conference dedicated to Test Leadership and Test Management.


Anna Royzman and Thomas Vaniotis, along with Matt Barcomb, are our facilitators and content owners for the day. The morning started with breakfast, and then we all gathered to introduce ourselves and explain what we hoped to get out of the sessions today.


At this point, after nearly a full week of engagement, we all know each other really well. Still, even with all the time we have spent together, we still have a lot of variation to what we are looking for and hoping to work on. We're putting together topics now, so this seems a good place to take a break.

We split up into three groups to generate ideas. Many of these may become actual sessions. We're going through and describing a variety of goals, based on where we are. Some of us are managers or directors, some of us are individual contributors, but each of us in our group has determined a variety of ideas to consider and pitch. I'm saying that vaguely because I don't really know what's been proposed; it's all on my laptop, as Ray Oei can attest (he took the shot ;) ).

Gotta' get in line to make my pitch...

---

We have put together an interesting program, lots of information and lots of great topics to cover. Many of them were blended together as there was a fair bit of cross- coverage in the topics that were provided. I proposed a topic called "Usurp the Throne: Don't Ask, Make" and as of right now, I will be blending my topic with Richard Robinson's, which is "Be Brave: Integrity and Bravery as a Tester and Test Leader". We will be covering that in the next session, but right now, we are discussing "Leading from the Front", or better stated, how can individual contributors manage their managers and executives of the organization.

What does leading from the front mean? It comes down to the reality that even individual contributors want to offer their own leadership and lead where they can and have opportunities to do so. We looked at the factors that helped us see where we can be leaders and can be effective in driving change. We discussed the metaphors of leading from the front and leading from behind as a military metaphor, and I might have gone a little overboard explaining how "lead from behind" came into such derision.


In truth, we need to lead from the front always. What we refer to as "leading from behind" is really delegating what we can to others so that they can likewise lead, and trust the individuals that we have delegated to that they will be able to do what they have set out to do. Autonomy is important for individual contributors, and even junior members of a team want to know that they have a certain sense of autonomy to accomplish what they need to (within the scope of their responsibilities and abilities).

If we as individual contributors want to develop our chops as leaders, we need to develop a thick skin, and the best way to do that is to practice effectively communicating.  While tact and diplomacy are critical, we can't be afraid to be blunt and tell the truth. We need to show courage, and part of that also comes into play when we do something wrong. We need to accept our failures honestly, and above and beyond that, we need to show what we have learned in the process of our failures. If we only celebrate successes and bury our failures, we will have a difficult time developing the trust necessary to be allowed to lead in our sphere. We also need to show trust to get trust.


One of the tools that we can use to help us make sure we are clearer in our communication is to make sure that we are listening well and asking clarifying questions where needed. there's a value in being direct, but it can be seen as steamrolling or being rude, or undermining direct communication. When we as a few clarifying questions, and make sure we use them to understand what we are being asked to do, we can also guide and lead those discussions using the Socratic method. the danger with overusing the Socratic method, especially with managers, is that you can be seen to be evasive at the most minor, and downright obstructionist in the worst case. Therefore, by all means, use the Socratic method to get clarification, but also use it to be direct and see if your opinion of the situation is correct, and if your course of action is clear.


---

The next session was a blending of thoughts and ideas regarding the courage it takes to be a leader and the attributes necessary to make the decision to be a leader even when there's not a direct mandate for you to be one. this is where my "Usurp the Throne" topic was deemed to fit alongside, so many of the comments below also fit that topic. In short, I suggested that, if you want to be a leader, then step up and lead. More times than not, if you do well, then you will be given more opportunities to lead. The traits that we discussed were similar in both cases. There is a need to be courageous and be direct in our focus and what we are intending to do. One comment was "do not be afraid to be fired". Other ways that we should be willing to act/embrace if this is how we want to work/be:


- Be clear about how you will be have in your job when you are being interviewed. Make clear that you see yourself as a leader, you intend to work and act as a leader, and you will demonstrate the competence and give them confidence that you should behave accordingly.


- Know when to say "no", and say it. More to the point, mean it when you say it.


- Do not be afraid to be open to comments or criticism. Do not overreact when problems arise (as they will) or if someone blames you for a failure (which they will). Instead, address the situation honestly, own up to mistakes, and work to do better in the future.


- Be a shield / support for others on your team. Not a martyr or a whipping post, but know when others are being problematic for your team, and back them if they are doing tie right thing, and counsel them when they re not and help to guide them.


- When discussing challenging questions, take a walk with the team member, sit in front of a computer with them, sit side by side with them when discussing issues and challenges. The biggest benefit of doing this is that it sets you up as peers, and lets the person being counseled know that you do not feel like you are putting yourself above them or that you are dictating to them. By talking in front of a screen, or on a walk, then it's a totally different dynamic, and much less likely to be seen as contentious.


- Avoid pathetic compliance. If there is a business process that is wasteful, or is unnecessary, or is done as C.Y.A. work "just in case", get together with the decision makers and discuss why we are doing what we are doing. In extreme cases, be prepared to say "I'm not doing this. It's a worthless task, and it costs us in time and energy for other testing." Note, see the section where "do not be afraid to be fired" is listed ;).


- Don't discourage discussion you might disagree with! This is a big one. If you really aspire to be a leader, then you need to be willing and able to take some lumps, or talk about things that might not be pleasant or fun. More to the point, other members on your team may have a difference of opinion compared to you. Be willing to discuss that from that position, but let them talk, share their views and in the same collegial environment, be willing to share your own views and reasoning. If their views make for the stronger argument, admit it, and be willing to see if what they are saying should be tried.


- Recognize personality mismatches (and the severity thereof). If there is an issue or a clash of personalities or culture, don't wait and delay to address it. These situations rarely get better over time. Focus on the conflict and try to address them. It's possible that the other party (or you) may need to modify approach and behavior, or leave the organization and find something else that's a better fit. Both demonstrate real leadership. Don't be afraid of either, but use and counsel for each.


- Blame others (when discovered and appropriate). This comes down to being honest, being credible, and standing up for what you know and believe in. If bad behavior or bad decisions have been made, address them. Do not be contentious, but be frank and be direct.


- Offer positive deviance. Great suggestion, and a little clarification might be in order with this comment. If you want to shake up the system, and go against the normal order, be prepared to show examples of what you are doing and why it is good to do it.


---


There were several talks that I recorded but didn't actually get to attend. Each of those deserve a bit of time of their own, and will more than likely get their own blog posts in the coming days. As it stands now, I'm back home and getting ready to take my daughters out camping, which means I will be of the grid for the next few days. It's been seriously fun hanging out with and learning from everyone this past week, but I need to disengage for awhile and recharge. Thanks to all the attendees of TestRetreat, CAST and TestLeaderCamp. It's been a fun run. Let's do it again next year :).

Larger than Live, #CAST2013 Day 3

I cannot explain how leaden it felt to see the alarm clock ringing this morning. Not because I was dreading the day, but because I had so much energizing and amazing conversation yesterday that I felt genuinely drained this morning. It made getting up a little painful, but I wouldn't trade this week's conferring for anything...

A quick piece of news. We had five people running for the board this year and three spots. I was considering what life would be like not being on the Board of Directors, but that's not to be the case. My thanks to the membership of AST and your vote of confidence in me. I will be spending another two years as a member of the Board, and that's because you who voted for me feel I should be here. I thank you, I will never forget that, and seriously, I am here to do the things that you elected me to do. Please do not hesitate to contact me and let me know what AST can and should be doing. The board also welcomes newcomer Markus Gartner and fellow re-electee Pete Walen, who will be joining standing members Ben Yaroch, Dee Ann Pizzica, Doug Hoffman, and Keith Klain.


The opening keynote today is being given by Dawn Haynes, who confessed that this is the first time, outside of a Lightning Talk, that she has ever spoken at CAST. Most of us, however, know Dawn very well, because she has been there, behind the scene, at almost every CAST since its inception.


Dawn is focusing her keynote on personalizing retrospectives. Dawn is not a fan of best practices. She's not one that says she can really learn any way but experientially, so there's a great deal of this in her talk. Part of the focus of retrospectives is to give advice moving forward, to compare successes, and to recognize and review failures.


Dawn was discussing the Big Dig that took place in Boston, and some of the stories that were shared with Dawn from the perspective of one of the top program managers, and how what was meant to be a relatively straightforward project and how it spiraled out of control and grew to be one of the biggest and longest urban projects in modern history.

Dawn took on the challenge of taking up figure skating as an adult, with the idea of first learning how to skate, and then to start competing. It started small, and she started at the bottom of the ranks. She won, and surprised herself in the process. She then went to the a more national level event, and while training for the event, she injured herself. In the process of getting ready and considering going, she decided to do whatever it took to get out there and make it happen.


She described some of the ups and downs of her competition (and video footage from an old VHS tape, for those who remember what those are ;) ). She said that she was both "mortified but intrigued" by how everything turned out. The good, the bad and the "ugly" of the event was on display. The interesting thing was being a participant gave one perspective, and those of us watching the video had a different perspective. I thought she did great. As an "adult competitor" in a sport (in my case, snowboarding) I can totally appreciate how these perspectives can be impacted.


Introspection is an important  component when it comes to learning and understanding where we have been and where we want to go. Reflection is difficult when you have failed, or think you have failed. When we judge, we tend to miss great opportunities to consider other interesting aspects and avenues. Judge less, explore more.


Dawn described some of the challenges she faced as she first became a tester, and discovering some of the ways she learned that she could be... problematic. As she grew into her testing roles, she sought out people who could help her see where she could improve, where she might be abrasive, and how she might overcome some of those aspects in her personality and approach. In the process she learned a lot, improved a lot and decided that she had more to give. In the process, she decided to start teaching. Since she learned so much from so many others, she decided that she wanted to and needed to give back. for those familiar with Dawn, you know that she gives back in spades! She left us with one simple question... What will you do? Will you write? Will you train? Will you mentor? Will you coach? Will you speak? Will you inspire? Whatever you do, just get out there and do it. Live... with no regrets. Give... with no regrets. Two thumbs up, Dawn! That was awesome!

---

Next up, and a session I've been looking forward to for quite awhile, is Rob Bowyer and Sabina Simons talk about Mentorship, and the way that the mentoring relationship is often a two-way street. I've heard Sabina talk a bit about her journey last year at CAST, so I was excited to see that Rob was going to be part of this discussion, since I was curious to hear about his side of the equation.

Sabina walked us through the education initiatives she went through while studying for a CS degree, and the fateful decision via an internship that made her decide to make software testing her primary focus and goal going forward.


As she was working with other testers, she also felt the frustration of working with a group of testers that were not enthusiastic, not engaged, and just going through the motions. Very antithetical to the testing community that she had been hearing and learning about, so she decided to reach out and learn more about her options in the broader community, specifically in the local area of Kitchener-Waterloo (shout out to Selena Delesie and Paul Carvalho, I'm sure you were influential in this :) ). Through this, she came in contact with Rob Bowyer, and decided that she wanted to seek out a mentor, and as he was a recent hire, she felt she could trust him, and he encouraged her to attend CAST. The rest they say, is history :).


Rob's story was a little different. He came into the testing world in the late 90s, from a background in personal computer nerdery while studying English in University. He figured that technical writing would be his gig, but without credentials, how would he be able to do that. By getting some experience, he found himself gravitating to testing jobs and found himself interviewing for  QA position. His desire to tweak was greater than his desire to write. His "mentor" introduced him to Cem Kaner's "Testing Computer Software". He worked a variety of different jobs over the years, ultimately bringing him to his current gig. He considered certification, but the cost and the, in his opinion, dubious quaifications of the cert options, he looked elsewhere, and decided to approach a community level of involvement and qualification (one that as an instructor in Miagi-do I can totally appreciate :) ).


There's lots of management literature, and there's lots of leadership literature, but much of what is out there is very "by the numbers". as anyone who has spent any time as a tester can attest, this is a business where "by the numbers" just doesn't work. Leadership needs to be personal, it needs to be servant leadership, and it needs to be strongly mentoring focused. Rob makes the case that mentoring doesn't need to be hierarchical; it also needs to be a relationship where we don't give them the answer, but help guide them to the answer.


Sabina threw a grenade at Rob and asked if he'd even seen her fail, and I liked Rob's answer;  "I didn't necessarily see you fail, I let you make decisions that I might not have agreed with, but watched what you learned from those decisions and witnessed where you went forward from there."


An example that Rob mentioned was when Sabina started mentoring "co-ops" (similar to work internships for college students). Rob has occasionally given prescriptive advice, but tried to limit the way that he presented it. Sabina shared an experience where she had a co-op who was not interested in testing AT ALL. He'd actualy fall asleep at his desk (she'd bring him bak to attention by shooting him with a Nerf dart... Oh Sabina, I LOVE your style ;) ). Those are frustrating, and sometimes, you just have to move on or let people go and be mentored by others, or find what they really want to be doing. Sabina said that, in mentoring, if there is an issue, address it immediately, don't let it sit or fester. Break bad news early. It never gets better later.


Learning styles differ, an we don't get the opportunity to determine how someone we mentor learns. as a positive mentor, it's on us to adapt to the way that they learn best, not having them adapt to the way that we prefer to teach. Also, as mentors, we often have to let go of our original roles and focus so that we can better mentor others. We also have blind spots in ourselves that we need to become aware of to help us better mentor others. To do this, it also helps to have someone spend some time working with us to help us see in ourselves areas we might not be aware of. I've certainly appreciated the two way model where someone I am mentoring for one area or aspect acts as my mentor for another area.


Good attributes of mentors care broad and varied. I mentioned a friend of mine from way back at the beginning of my career who was an excellent mentor, and that his carefree attitude was hugely influential for me. Developing a continuous relationship is vital, and having an interest beyond just the job is important. The ability to be non-judgmental is critical. We need to step back and let testers discover many things for themselves, and to do that, we sometimes have to let opinions and our own judgments take a back seat. Good mentors also try to push limits and help those they are mentoring grow and take on new challenges.


Sabina did great in her first track talk, and I'm hoping to see future presentations with her (Rob did great as well, but you can tell, this is not a new experience for him :) ).


---

Lunch is over, and now I'm watching Manuel Mattke and Dee Ann Pizzica talk about the occasionally contentious relationship between software testing groups and C-Class executives. Part of this challenge is the fact that testers are seen differently in different organizations.


Some teams are directly tied to development, some are treated as part of IT, and other arrangements are not uncommon. Manuel suggested that a potential better alignment would be to have testers and test teams associated with the product group, not the technology team. What would this benefit? One potential benefit is that the product group is more focused on the customer needs and requirements, being closer to the ground with them. So the first thought being shared is "align the Org Chart" for the best fit for the organization and the organizations goals.


The second consideration is to focus on customer experience. The better customer experience we can provide, the overall better product we will produce, both from a technical and a design level. User experience has been, in my estimation, one of the most vital elements for testing, and leaving it for last or to not give it proper weight is a mistake.


The third area we should be focusing on is to analyze product risks. When the risks are placed up front, and considered at each level for the stakeholders, we can get s clearer indiction of which risks are the biggest, and from there, we can really prioritize what matters in conjunctions with a weighted understanding from each group.


The fourth is timing. When we focus too much on sprints or release dates, but often the bigger challenge is getting all moving parts together at the appropriate time, and having our estimates be less accurate or, perhaps, totally wrong. By identifying what needs to happen in the necessary time period, we can make prioritization decisions and determine what needs to be tested critically and what may not get much exposure at all.


Fifth is to be a positive voice. Yes, it's true, testers are often the bearers of bad news, but I think a lot of that is bad marketing and an unfair focus. Testers have long been placed into the role of being the ones who were the guardians of the gate, who gleefully said "hah, I found this bug!" For many, that's not just dis-spiriting, it's also annoying. For me, I personally prefer being able to focus on the positive aspects that we have tested and why I feel god about it, as well as the issues that we should consider fixing and why. In short, don't whine :).


Sixth is Lead Automation, as in software testers should take the lead and drive the test automation effort. I think this is a good opportunity, but again, a caveat, it's a good opportunity if there is a strong programmer in the group, and if the automation makes sense for the context. The testing group can do a huge service to the company and the executives by helping define where the automation really should be used. Also, we need to be clear that automation will not solve all problems, and automation performed "checks" can be helpful in covering areas to allow us to look at situations that could be more interesting.


The final idea is.... (drum roll)... Engage Early! The earlier we as testers can get involved, the sooner we can get into the particulars and find important issues. It also gives testers a chance to look at and consider potential pitfalls, traps, conflicts, blockers and understanding how to frame the testing story. Getting in early also gives us the most leverage to work with the programmers to make testing and testability possible.


Ultimately, we have an issue with credibility. If there is a contentious relationship, it comes down to credibility and trust. If there's low trust and low credibility, it's going to be a challenging relationship. If we can help build and maintain credibility and trust, by being involved in the process from the beginning, and being more visible through the whole project, we will have a much better opportunity to show our value all through the life cycle of software development.


---


Hmmm, so wait, there wasn't an update for the last talk session... what gives? Well, what gives is  that someone came up to me to ask about getting involved in the SummerQAmp initiative and what they could do to be helpful.

We did come back in to see the top vote getters for the Lightning Talks last night, and it was fun to see the participants who took the most votes and thus were given the opportunity to present in the main ballroom and on the web stream. Those winners?

Julie Hurst:
"Why am I Standing Here? The
Tale of a new Conference Speaker"

Alessandra Moreira:
"Getting Teams to Warm
Up to Exploratory Testing"

Rachel Carson:
"More Powerful Pair Testing"

Jesse Alford:
"Focusing the Mind's Eye -
an Optics Analogy"

We now come to the closing keynote, and Scott Barber and Rob Sabourin are going through and describing what they have learned from the other speakers. From Jon Bach's keynote through individual talks, there are a number of cool takeaways from the talks mentioned.

Such examples of cool takeaways:

We can argue and still be civil. Argument is the application of reason against reason. Let the better reasoning win.

You do not have to fight for every bug.

Lack of Priority, not a Lack of Time.

Describing tests at a high level can be a preventative measure against unintentional blindness.

Once you start to see things and thinking about things like a tester... you start to see everything that way.

I can learn, even if I get it wrong.

Design of experiments is a more valuable method of testing than QA.

Know your mission two levels up... does my context align with my boss and their bosses mission? How can I potentially match my context to theirs and the tasks at hand?

Build bridges, dare to disagree, be willing to be wrong, build on limitations, seeing as forgetting the names of things, testers make mistakes.

True mentoring is a two way, lifetime contract predicated on trust, respect and a mutual commitment to continuous improvement.

Learn in a safe haven, model testing as part of an ecosystem, regression as a swear word, be vigilant and like a sponge, build trust with matriarchs, daily debrief even when alone, expect the unexpected and respect it.

"Don't throw Excel spreadsheets at me. Don't whine. Articulate your strategy or replace yourself" - advice from a CEO of a company to software testers.

Role of a quality leader in an Agile transition, learn by sharing stories, get the whole team on the same page wrt quality standards for the team.

The Four Schools of Software Testing... stop talking about schools, discuss culture instead.

The final slide has asked us...

What Did You Learn at CAST?

Where did you learn it?

How will you apply it?

If I had to pick any one item, by itself, it would have to be from Manuel and Dee's talk, and it is as follows... "Articulate your strategy or replace yourself". This is an encapsulating question, and it covers so much. We need to tell a better story. With all of the journalism metaphors that are floating around out there, and the emphasis on telling a compelling story, it feels like few are really tapping into this the way we should. How will I apply this? I will focus on the stories I work on at the very beginning of the process and trying to see the full "story", work towards that full story, and better articulate the vision and focus of the testing team. The tools to do that? Genuine testing skills, better writing, sharpened tools, and a desire to truly understand the needs of my customers... all my customers."


---

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 :).

CAST 2013: Day 1, Live and Loud

Here's wishing everyone a Happy Monday from Madison, Wisconsin. Test Retreat was Saturday, the AST Board Meting and some other things happened Sunday, and today we are getting a bright and early start at Colectivo Coffee on Capitol Square. Thirteen stalwart and early morning willing people assembled at 7 a.m. to discuss topics related to testing, the world we live in and life in general.


This model of early morning conversation is what is referred to as "Lean Coffee". For those not familiar with this format, Lean Coffee is a structured, but agenda-less meeting. Participants gather, build an agenda, and begin talking. Conversations are directed and productive because the agenda for the meeting was democratically generated. as can be anticipated, today's group is mostly testers, so most of the commentary are topics related to software testing.

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 participants, 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 ;) ).


---

Live from Madison... it's TestRetreat

It's time to switch gears. First, hello everyone, TESTHEAD is is Madison, Wisconsin for the next week. It's going to be a software testing focused, with all the likely nerdiness, awkwardness and discomforting realizations that come with all of that... translation, it is going to be a lot of fun. It also means I will probably be posting a LOT, and in a live format.

For long time readers, you know that means there wil be frequent updates, tweets, pictures, and most imortant, a blog stream that may be scatter-shot and stream of consciousness. If you are cool with that, then as long as you see "More to come, stay tuned", it means exactly that. Refresh every hour or so and you'll get the newest stuff. If you see "End of section", then that means I'm done with that post (and then you can give me grief for typos, run on sentences, etc ;) ).




Today is TestRetreat, and this is happening at the Fluno Center in downtown Madison, a few block s from the capital building. Almost everyone in this room is someone I have either met, worked with or know through my blog or trough Twitter. It's so fun to see so many of you all in one place!

The goal of TestRetreat is that we are looking to take on new initiatives. This is not an event for "consumers", it's an event for "producers" and "collaborators". Our goal is to make something this weekend. the beauty of it is I have no idea what I'm going to walk out of here committing to taking on, though I have come in with a few ideas of my own. It's possible that I may have some collaborators to help me when I leave today. It's also possible I may level here abandoning some of my ideas and committing to something completely new. That's what I love about these events; you genuinely never know what's going to happen.

For those wondering, TestRetreat is what you would refer to as an un-conference. Sessions are unstructured, they are proposed and people gravitate to the things that matter to them. It's possible that my idea may generate some buzz, it's possible that they might generate no interest whatsoever. the great thing is "that's totally OK".

As of right now, we are in the process of gathering ideas and proposing our pitches. I'm currently pitching three session ideas. the first is "Let's stop faking it", which as many of you know is an article I wrote earlier this year, and I've been expanding it through blog posts since. I want to make this into a more cohesive and coherent set of ideas and genuine action plans surrounding this idea.

My second pitch is to talk about "Releasing Software for Real People" and the fact that people are unpredictable and rarely fit into the ideals that we often create for people. Personas are helpful, but unfortunately, they are not real, and very often, they really don't reflect real human behavior. My goal is to see if we can create more realistic software for more realistic people.

My third talk is, really, what everyone has seen me doing for the last several weeks. It's titled "Do Something Already" and it stems into the 99 Things I've been talking about, but for this session, it's really all about how action plans are created and how we can better take a suggestion and turn it into a real world, actionable thing.

...and here's the board an all the sessions.
So many great options, so little time!!!

---


The first session I am participating in is all about Experiential Learning, and one very fun
aspect of this is that two Weekend Testing facilitators are sitting right next to each other (Ale Moreira, the current facilitator for Weekend Testing Australia/New Zealand is at my immediate left as I'm writing this). We just shared some thoughts about how Weekend Testing is a rich experiential environment with two primary follow-on effects. First is the real time struggle of comprehension, and what we mean and how we come to it.

WTANZ and WTA come together on a mid-west Saturday.
All is well with the world :).

The problem with a lot of experiential learning activities is that the immediate participants get a great benefit, but it's difficult to help others who weren't there understand what is happening. By contrast, Weekend Testing has an added benefit that, if a person wants to read through the chat transcripts, they get a real world real time (as relates to that session) appreciation for the actual learning as it takes place.

There is another challenge to structured experiential learning in that there is often an agenda that the developers of a course have. First, they tend to want to get paid (nothing wrong with that, but it tends to inform a lot of what happens). the second is that they have a specific outcome in mind. Personally, I think that's a failing to "canned" experiential learning. When we go in with the idea that "you will practice these ideas, but at the end of it you will be able to do 'X' and do it in this manner".


The really interesting thing about truly experiential learning is that different people tend to get different takeaways, and the takeaways they leave with do not always mesh with the desired outcomes of the instructors. that's a challenge that we do not have a really good answer for. We do pretty well when it comes to reverse-engineering activities (the Pen Test, the Dice Game, etc.). We don't do so well when it comes to actual critiquing of examples we work with. How can we better approach ways of actually critiquing exercises that don't also go down the paths that the instructor intents (or become a referendum for the exercise itself).

---

Session two is underway now, and we are talking about how we visualize testing data and information. Andy Tinkham is faciliating this session.

We have had a vigorous discussion about the value of dashboarding, and what information is relevant and which isn't.

One early disagreement (a good one) is to consider what needs to be displayed. Perhaps I took too narrow a view, but I said that visualizations need to display the critical information so that we can get to the meat of what we need quickly. Yes, there was vigorous disagreement (what, testers disagreeing? Shocking! (LOL!) ), but Thomas Vaniotis and Rich Robinson gave a really good rebuttal to my statement. It's not that we want the most critical information to be displayed, its that we want to have as much information as possible so that we can examine and determine for ourselves what is the most critical.

Another hard nut to crack is do we care about numerical and quantitative aspects, or do we care about more qualitative details. Even if we give a thumbs-up or a thumbs-down, we count the thumbs-up/thumbs-down, and that's numerical/quantitative. By contrast, creating a test like the kind that Steven Krug describes in "Rocket Surgery Made Easy", where actual actions are associated with image captures of the users face and body language, is much more qualitative. We could visualize it but capturing those snapshots and posting them in a group, what Cristina Lalley referred to as an "image quilt" or a broad representation that we could view in a way that lets us make a quick decision but without boiling it down to a number.

Visualizing data can have a variety of methods. The goal of any visualization is to be able to tell a story to someone who needs to hear that story so that they can act on what they hear. The use of colors is something that has always interested me. We typically consider the three colors that we use are almost always green, yellow and red. Reason? Because metaphorically most of us are used to seeing and interacting with traffic lights. For me, I tend to use six total colors (not counting white or black) to represent most situations. Those are the direct primary colors (red, blue, yellow) and the resulting secondary colors (purple, green, and orange) and typically, I use those colors to represent absolutes (primaries) and transitional states (secondaries). Other aspects such as depth, texture,  physical placement, and other visual "rules" can also help make systems and information more visually understood.

---

Well, I apologize for the delay, but alas, I can't live blog while delivering my own session. Yes, I discussed "not faking it", and in the process, opening up to the room about what I felt it meant to be faking it vs. being early on the learning curve and not really understanding completely what we are doing. In the process of the session, we mentioned and discussed a few areas that we felt brought us to the edge of learning a competence and "faking it". Learning a competence and being open about what you can and can't do does not fall into the realm of faking it. Hiding your ignorance from others so that you can develop the competence without having to own up to what you don't know, or representing yourself as a competent professional when really you aren't or selling yourself as more competent than you are... then yes, that is faking it.

One metaphor that I like and often mention, though it can be overplayed and over-emphasized, it the idea of deliberately seeking to be the worst player on your team (or in your band). I've often said that, if you find that you are he strongest member of your team or of your band, then you might want to find a new band. Through Twitter, Ron Jeffries made a very good point and emphasizes what I really mean with this quote. If we are always seeking to be the worst player in the band or the team, then that can be taken to extreme and there will never be a band or team good enough. That's going beyond what I mean, and frankly, you may thoroughly enjoy being on the team/band you are with. If that's the case, then you have three choices; improve on your own with the idea that you will have to be self determined, stay where you are and enjoy your role as it is, or seek to help those on your team rise to where you are at.

Teachers and mentors do not have to be very distant from their peers to still be helpful and give them an opportunity to learn. Sometimes the best breakthroughs knowledge and skill wise that I have made have been when my kids have asked me questions or asked why I did things the way that I did. Often they can help me see bad habits I have developed and put them in the proper perspective. A final point that came up, and one I want to explore more thoroughly, is the idea of the "embarrassment quotient". I personally find that if I'm wiling to be embarrassed, I am much more likely to learn and grow. If I am not willing to be embarrassed, or I try to prevent situations where I don't open myself up to embarrassment, I really slow down the opportunities I have to learn and develop.

---

We all went down the street to lunch and split up into groups to have a Lean Coffee session. we split up into two groups, but unfortunately, I think that me and JeanAnn Harrison overwhelmed the conversations a bit. We did have some fun talking about a lot of varied topics, ranging everywhere from the riddles of culture to the linguistic characteristics of old Hollywood actors due to recording technology at the time. Lot of fun, and yes, I had to at least have Cheese Curds and Ranch at least once. Level cleared :).

---

One of the in-between and informal sessions we referred to as "Tester's Anonymous". I promised not to Live Blog this session, but the idea is great. It's a discussion of a variety of hot topic issues and button pushing issues that we all deal with, and the ability to share those with our peers is, quite frankly, very cathartic.

Inspired by "HYPEHARVEST" and some of the challenges that some programmers and testers face, this session was proposed to help some of us see in ourselves some of the emotional  challenges that can beset us, and the fact that, some times, we need help in dealing with them.

Help in this case ranges from a friendly pat on the back, a hand with a project, or a good word to someone, all the way to a potential medical diagnosis and treatment. The point is, there are a lot of things we as programmers and testers deal with that often get swept under the rug. When left to fester, they can become genuinely toxic and even dangerous.

---

Ale Moreira lead a discussion about Motivating Testers, and the challenges that we face when we try to help others become more motivated. How did we encourage others? Does extrinsic motivation work? In acute and immediate ways, it can, but long term, the effect is not as strong. Intrinsically, we definitely have more control  and more long term desire if internally we decide to motivate ourselves.


Often the issues that cause testers to become apathetic are the fact that they really wanted to do something else, or they were resentful that they don't have enough resources or support in what they do.

Additionally, having the feeling that we are not valued or respected can also contribute to boredom and apathy.  How can we find the passion? There has to be something that we can look for. We decided to try an experiment. What if we were to see what we all considered the factor that made us jump from less motivated to wanting to be more involved?

We decided to record the experiences, and the raw audio from that session is here. I will probably condense and clean this up to make a better produced "podcast" but for now, here's a taste of some TestRetreat attendees and what motivates them.

---


Claire Moss and Ale Moreira tweeted a whole bunch for me and shared my second session, which was based around developing software for real people. I wrote about this from the perspective that, very often, when we create a feature, we get all sorts of excitement and comments that the feature being developed. Then when we deliver the product, we get radio silence. Once we do get in touch with them we see that the enthusiasm has waned, and they tell us it's not really what they wanted.

Frustrating? Yes, but also perfectly natural and even to be expected. The problem is, you didn't deliver the product they wanted, you delivered the product they thought they wanted. We make software for what people believe the ideal person, under the ideal situation, would excel while using it. the problem is, human beings are not ideal, they are more complicated than that. 

As individuals, we do not fit 'ideals'. However, we build software around ideals. Hence we are missing the mark as "we are all special".


Some thoughts captured by Ale (thank you so much for the forward :) ):

- When using personas for testing, the more specific we make the persona the better
- Nominal situations
- Knowing the product you are testing intimately
- Imediate access to customers - other ideas are to build ad-hoc personas, attempts to think up what real users could do and validate it with research. Be explicit about assumptions when letting people know how personas were built. Create models.

- - Risk is that it could be hard to create personas that are not closely related to our own situations or universe (i.e. a blind person, etc), and even if you can think up the persona, you wouldn't be able to test like they would use the software.

- What are ways that we can practically, and realistically, design software for real people:
- - If you can speak to the real users - do it
- - After that, invite the real user to a planning meeting, get their feedback directly
- - Iterate with the development team, create a working prototype, get the the customers to see and try it. - - Have a prototype party!!
- - Once it is in the wild, follow up quickly with the customer. Ask questions, get feedback fast - within 24 hours.
- - Remember - even then we won't get it right every time. We might still miss the mark.

Yep, that about covered it :).

---

From here, we are getting ready for closing comments and a trip to Teppen-yaki out at Ginza of Tokyo. I'll post some additional closing comments later, but for now, I need to head out and get some food. We'll talk later and thanks for following along :).

End of post.