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 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.
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.
---
---
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.
---
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.
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.
- 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.
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.
No comments:
Post a Comment