Accessibility WTAmericas #WTBlitz Session: 30 Days of Accessibility Testing

This is not on the checklist, and in fact, this will be an additional part of the 30 days challenge. As I was working through the checklist, I realized that this would make for a great potential chat session for #WTBlitz, so that's what we will be doing for May.

Details:

On Wednesday, May 17, 207 at 1:00 p.m. Pacific (4:00 p.m. Eastern), we will hold a  one-hour #WTBlitz chat session on Twitter. We have asked Alicia Jarvis to join us as a special guest, and I have also asked additional Accessibility advocates if they would be willing to participate. To be part of it, just use the hashtag #WTBlitz and reply to the Questions posed directly to the threads.

Example, if I were to post:

Q1. Why is Accessibility important, and why should we test for it? #WTBlitz

we would like you to respond directly to the question thread with something like:

A1. [text of answer] #WTBlitz

This will allow us to keep the threads together and gather them for our experience reports and future referencing of answers.

These details will be duplicated on the Weekend Testing website, but I want to use here to get the ball rolling.

Why?

Because I want to see if we can get to what you all out there would find important, pertinent and interesting. To that end, I am going to start compiling a list of questions, and you can ask them/add them here. Likewise, I will encourage anyone who wants to tweet to me questions they would like to ask, and I will update and add the questions to the master list.

To get the ball rolling, here's a starting list of questions:

1. Why is Accessibility important, and why should we test for it?
2. Do you need to specialize in Accessibility to be effective?
3. Is WCAG the best standard to follow?
4. What tools are available to test for Accessibility?
5. If you had to recommend one tool to test Accessibility, what would it be?
6. Can you recommend good tutorial/reference material for Accessibility testing?
7. What is the difference between Accessibility and Inclusive Design?
8. How can I as a tester better advocate for Accessibility/Inclusive Design?

This is a list off the top of my head. They would seem to be natural questions to have a chat about to me, but again, I'm much more interested in what would be interesting to you. If this list is a good enough representation, then great, we'll go with it. If, however, you have better questions or ideas, then please, reply and leave them in the comments section. If the questions you ask are better than the ones listed here, I have no problem bumping these for better questions :).

The Humans In the Machine - Talking Machine Learning

This weekend was one of the more interesting Weekend Testing Americas sessions I've hosted. Hurricane Matthew was making itself known and people were dealing with getting in and out of a broad section of the Southeastern United States on Saturday, as well as looking at whether or not their homes were OK. Under those circumstances, I can understand getting together to talk testing may not have been a high priority. We had several people ask to attend, but by the time it started, there were just two of us, Anna Royzman and myself. Anna and I both decided "hey, we're here, Anna's never done a Weekend Testing session before, let's make the most of it" and so we did :).

Our topic this go around was a chance to look at a new feature of LoseIt called SnapIt. The purpose of SnapIt is to take pictures of food items, and based on what the app thinks the picture is, select the food item in question and get a macronutrient breakdown. This is a new feature, so I anticipated that there may well be some gaps in the database, or that we might get some interesting tags to appear. We were not disappointed. In many of the pictures, well known food items were easy to identify (apples, bananas, etc.) and some a little less so (a small pear variety that had a darkish green skin was flagged as Guacamole, which isn't really too far of a stretch, since I could see it interpreting it as a small avocado):

Complex and packaged foods it struggled a little more with, but in those cases, if it has a bar code, most of the time, reading the bar code would deliver the information we needed, so SnapIt was less important in that setting, but it was interesting to see what it flagged things like granola bars or shelled walnuts as.

During the session, we did discover one interesting bug. On my iPhone, if a user takes two pictures, and discards them, and tries to take a third picture, the camera button on the screen appears as a half circle. The bottom of the button is missing. Exit the camera and open it again, and the camera button appears complete again. Shoot two pictures and throw out the two, you will get the half button on the third try.

Outside of the actual testing of SnapIt, we had a pretty good discussion of machine learning in general and the idea that many of the algorithms used for these processes are pretty good, but can often have unintended consequences. The past few weeks, I've been listening to a number of podcasts that have featured Carina C. Zona and her talk "Consequences of an Insightful Algorithm" (talk and slides). She has appeared on both the Code Newbie podcast and the Ruby Rogues podcast, and both treatments made me want to explore this topic further. One comment from Carina's presentation that stood out to me is the idea that "math (algorithms) are objective conceptually, but their implementation hardly ever is, because it's people who create them, and we create algorithms with our prejudices, biases and fallacies intact. In short, we do not see our algorithms for that they are, we see them for who we are (paraphrase of Anais Nin, but you get the point, I hope ;) ).

I'd encourage anyone who wants to get a better understanding of the potential dangers of relying too heavily on machine learning, as well as the human aspects that we need to bring to both coding and testing those algorithms, please check out Carina's talk. For those who want to see some of the terrain that Anna and I riffed on, please feel free to read the chat transcript of the WTA session.

New Year, New Weekend Testing Americas, Come Join Us!

Normally, these announcements would go up on the Weekend Testing website, but the site is down at the time of this posting, so I am taking matters into my own hands and posting it here until that gets resolved.

With that out the way... Happy New Year, everyone! Here's wishing you all a  happy and healthy and productive 2016, and what better way to get into the groove than with your friends at Weekend Testing Americas (well, sure, you can join a session of any of the other Weekend Testing Chapters, but why not come to our first ;) ). Without further ado, here's what's happening, and when/where:

WTA-68:  Mobile Website Testing
Date:  1/9/16
Time:  1pm EST/10am PST - 3pm EST/12noon PST (check your own time zone for start and end times)
Facilitator:  Jean Ann Harrison


As websites are being overhauled for viewing on mobile devices, are we checking a normally viewed website viewed on a device?  What should you consider important to tests?  Can we automate all these tests?  Yes, and we can talk about what tests can and should be automated and those that can be done faster manually.

For this weekend testing session, we're going to focus on the type of user who uses the Weather Channel website on  mobile devices.

This means we'll be using the browser on the device and not downloading any apps.

1.  What is the first thing any user expects to be able to view?
2.  What kind of view is the user expecting?   Fill the screen?  Scrolling?
3.  Is the font readable? Or does the user need to do something to make the website readable?
4.  Can the user view the videos?  Can the user pause the video and rotate the device and continue viewing the video?
5.  Is the website easy to access the various pages?  Think about the size of fingers or is a stylus needed?
6.  Is it easy to find the latest news?  How to navigate to the news page?
7.  How is the response time?  How is the painting of different pages?
8.  Is there a balance of content and ads?

Logistics:

You may RSVP to the event by sending a request to "weekendtestersamericas" on Skype and letting us know you wish to take part in the session (if you have not initiated a Contact Request, please do that and mention in the body of your message that you would like to participate in this Saturday's session.

On Saturday, January 9, 2016, please be online and ready to connect to the session about twenty minutes before the start of the session. We are willing to add latecomers, but it gets distracting if we have to reiterate everything that happened in the earlier part of the session, so we generally limit new attendees fifteen minutes after the start of the session. We may add more people at that point, but will likely not go back and review what was covered beforehand.

Also, if this sounds like a great way to spend a Saturday to you, perhaps share this message with a number of your friends and encourage them to participate as well.

We look forward to seeing you there.

Regards,
Your Weekend Testing Americas Facilitation Team
(Albert Gareev, Jean Ann Harrison, Michael Larsen and Justin Rohrman)

Concentration on Information Radiation

Ever have an experience at a conference that just sticks with you, that one thing that seems like such a little thing and then, as you consider it more and more, you just slap your forehead and say to yourself "for cryin' out loud, why didn't I think of that?!"

On Monday while I was at CAST, I was the room helper for Dhanasekar Subramaniam's tutorial about "Using Mind Maps for Mobile Testing". Much of the session was around heuristics for mobile testing and the ability to capture heuristics elegantly inside of mind maps. as part of the process, we spent a bit of time creating mind maps in XMind to use later with our chartered test sessions. I've done this before. I've even created a full mind map of the entire James Bach Heuristic Test Strategy Model (yes, one mind map and yes, when fully expended it is massive. Probably too massive). As we were working to create nodes and sub-nodes, Sekar pointed out that there were many labels that could be applied to the nodes, and that the labels were additive. In other words, each node could have several labels applied to them. 

As I was looking at this, and seeing labels such as pie chart fill, green check boxes, people silhouettes of several different colors, red x's, green yellow and red explanation points, and many others, I started thinking about how, by color and proximity, we could gauge how much coverage we have given a particular mindmap (or in this case, how completely we have applied a heuristic to testing) and what the results were for that. Instead of stopping to write down lots of notes, each node we were testing would get a label placed, and each label would have a semantic meaning. Green check box meant good, red X would mean failed or something wrong, a quarter pie chart would mean a quarter done, a yellow square would mean something that was a warning, but maybe not an error. Different color people icons would mean the person who performed that set of steps, and so on.

As I was looking at this, I joked with Sekar that we could tell the entire testing story for a feature or the way we applied a heuristic to a story in one place with one relatively small map. We both chuckled at that, and went on to do other things.

The more I thought about this, though, the more I liked the idea. In a previous company, we set up a machine and had a couple of flat screen monitors attached. These flat screens were placed in the main area and left on, cycling the images that were shown, only in this case, they were graphs and pages of results that were relevant to us. In short, they were acting as information radiators for our team. At a glance, we could know if the build had failed, if deployment was successful or not, and where the issue would be if there was one. We could also use this technique for information radiation. Imagine a charter or set of charters. Each one had their own mind map. Each mind map could be cycled through presentation on the monitor(s). the benefit would be that, at a glance, the team would know how testing was going fort that area, and we could update it all very quickly. I kept experimenting with it, and the more I did, the more I became convinced this just might work.

To that end, I am holding a Weekend Testing session this coming Saturday, August 8, 2015 at 10:00 a.m. PDT. We will look at mind mapping in general and XMind in particular, and we will develop a small heuristic for a feature (within XMind itself) to test and to update. I really like this idea, but I want to see if it can be tinkered with, and if it might be a useful approach to others.

If you think this might be a fun way to spend a couple of hours, come join us on Skype. Contact "weekendtestersamericas" and add us as a contact. On Saturday, get on Skype about 20 minutes before the session and say you want to be added to the session. Prerequisite, if you want to follow along and actually do the exercise, would be to download the XMind app for your platform.

 Again, I apologize for the short notice, but I hope to see you Saturday.

Ever Had Your Screen Talk Back To You?

As many TESTHEAD readers will notice, I've been on a tear with regard to Accessibility this year. It's become my monomaniacal focus, and I've entered a semi-crazy co-dependent relationship on this topic with Albert Gareev. It's been a lot of fun talking about and focusing on this topic the past few months, as each time I think I understand what's happening and how we can do better, I learn something more that shows me just how far we have to go.

I remember back during STP-CON at the beginning of April witnessing an "A-Ha" moment for a roomful of people. that moment was when I asked the attendees in my session to open their laptops if they had them, or other devices, and turn on a screen reader just so they could "hear" what various sites were saying. Since a majority of the users in the room at that time had Macs, loading VoiceOver was quick. They started VoiceOver... and then things got interesting. As I watched people's faces, I could see the curling of lips, the furrowing of brows, and the nervous laughter pop up at points. The blast of electronic voices that erupted from system speakers was very enlightening, and watching a roomful of people realize just how difficult it was to listen to the output of their favorite sites made it crystal clear how hard it was for sight impaired users to get useful information from an average web site (or at least, a site that hadn't made considerations for accessibility).

This coming Saturday, we will be doing a session on screen readers with Weekend Testing Americas. I'm suggesting Mac users configure VoiceOver, and PC users download NVDA.

This session will be an introduction to Accessibility through the use of Screen Reader applications. My goal is to give people a chance to play with these features on common sites and see how well those sites make the general information on the page accessible to users, and how much useless information they receive. We will use these examples to have a discussion about how to address issues related to Accessibility, as well as building a case for making Accessibility part of an overall testing strategy.

If you would like to join us on Saturday, please send a request to “weekendtestersamericas” to add your SkypeID. In your request, mention that you want to join this Saturday’s session. On Saturday, twenty minutes before the start of the session, please contact us and ask to be added to the session, and we will do so. Here's hoping you can make it ;).

The Weekend Testing Family is Expanding

It is with great pleasure, and a little bit of familial pride, that I announce there is a new kid on the Weekend Testing block.

During the first couple years of Weekend Testing Americas, Albert Gareev assisted me in getting the group off the ground, working on some more interesting and technical topics, and even worked with me to propose and try out the "Project Sherwood" project. We decided that the Weekend Testing model as it was designed at the time wasn't the best model for this expanded idea, but Albert didn't give up the fight.

We've talked a number of times over the past couple of years about how the Weekend Testing model works both as a distributed communication model, but that it can also work well as a live and in person event. We realized that what "Project Sherwood" was missing was that in-person direct give and take element. Albert figured for that to work, it would make sense to try it with a group he already had familiarity with and in a community where such events could be developed and focused on. Since Albert is in Toronto, he figured "why not set up a Weekend Testing chapter in Toronto?"

Why not, indeed :)?!

For those on the East Coast, and especially those in the immediate Toronto area, you are going to get a cool opportunity. Albert is a dedicated and accomplished tester, with a wealth of knowledge and a fountain of ideas. For those wondering if this is going to dilute the current Weekend Testing Americas offerings and sessions, I'm going to say "unlikely", because those who enjoy participating in these events will go to those that make sense for them and their availability. I've attended events in just about every of the chapters over the past five years, so in my mind, the more the merrier. The real winners are the testers that want to participate and learn some cool things.

So what should you do? For starters, go and join the Weekend Testing Toronto Meetup. Follow @WT_Toronto on Twitter. Check Weekend Testing's main site for scheduled sessions. Most of all, get ready for a fun and engaging opportunity with an interesting and passionate advocate for testing.

Weekend Testing Americas is Looking to "Go Deep" This Saturday

Yes, it's been quiet here for quite awhile. Too quiet, and I needed to break the silence. What better way than with an announcement of a Weekend Testing Americas session, you say? I agree wholeheartedly!

With that, I would like to cordially invite each and every one of you reading this to come and join us this Saturday, July 5, 2014.

Weekend Testing Americas #52 - Going Deep with "Deep Testing"
Date: Saturday, July 5, 2014
Time: 09:00 a.m. - 11:00 a.m. Pacific Daylight Time
Facilitator: Michael Larsen


So what does "deep testing" mean? well, if I told you all that now, it wouldn't make much sense to hold the session now, would it? Still, I can't just leave it at that. If that's all I was going to do, I'd just as well have you look at the Weekend Testing site announcement and be done with it.


Justin Rohrman and I were discussing what would make for a good session for July, and he suggested the idea of "deep testing", and in the process, he suggested that we consider a few questions:


What if, instead of just having an unfocused bug hunt, we as a group decided to take a look at a specific feature (or two or three depending on the size of the group) and do what we could to really drill down as far as we could with that particular feature. Heck, why not just dig into a single screen and see what we could find? We have an exercise in the AST BBST Test Design class that does exactly this, only it takes it to the component level (we're talking one button, one dial, one element, period). we're not looking to be that restrictive, but it's an interesting way of looking at a problem (well, we thought so, in any event).


As part of the session, we are going to focus on some of these ideas (there may be lots more, but expect us to, for sure, talk about these:

- how do we know what we are doing is deep testing?

- what do we do differently (thought process, approach, techniques, etc.)?

- how do we actually perform deep testing (hint: staring at a feature longer doesn't make it "deep")?

- how do we know when enough is enough?

If this sounds like an interesting use of part of your Saturday, then please, come join us July 5, 2014. We will be starting at 9:00 a.m. Pacific time for this session, and it will run until 11:00 a.m. Pacific.


For those who have done this before, you already know the procedure. For those who have not, please add "weekendterstersamericas" to your Skype ID list and send us a contact request. More specifically, tell us via Skype that you would like to participate in this upcoming session. We will build a preliminary list from those who send us those requests.


On Saturday, at least 15 minutes before the session starts, please be on Skype and ready to join the session (send us a message to say you're ready; it makes it that much easier to build the session) and we will take it from there.

Here's hoping to see you Saturday.

A Weekend Testing Follow Up: Ubertesters Wants to Talk To You :)

Earlier in February, the Weekend Testing Americas chapter held a session for and with an app called Ubertesters. This is a wrapper/SDK around an app that can allow for people on mobile devices the ability to report what they see and send in their feedback to programmers and stakeholders without having to move to a different machine.

One of the benefits of Weekend Testing is that we also get feedback from the organizations providing the apps to test. This was shared with me after the session:

I was amazed with the passion of your team to testing and new technologies and tried to stay on track on the way to the way to the airport. I carefully read all the comments and feedback and appreciate them a lot. All the members did a great job, and it will help us to improve Ubertesters user experience for sure.

Additionally, Ubertesters contacted me and asked if I'd be willing to share this with the Weekend Testing community, and those who are part of this "passionate" group of testers. I said I'd be happy to.

From Ubertesters:

'Would you like to become part of a global testing provider and join Ubertesters team (http://ubertesters.com/)? 

Ubertesters is announcing enrollment to their team for testers who are passionate about testing, want to take part in various interesting projects and make some money in the process. For more details, please, contact info@ubertesters.com.'

I think this is pretty cool, and it's becoming part of a neat trend I've seen as of late. When the product owners and stakeholders of products take part in the sessions, they see and learn a great deal. Not just about their product in action, but their product in action in the hands of testers who really care about their craft. I've had a number of people who have participated in sessions say afterwards that they've been contacted by stakeholders and asking them if they'd be interested in talking to them for further opportunities. This is a continuation of that, and it's a result I"m happy to see.

To those who would like to follow up with Ubertesters, a favor. If you do, please mention you are coming to them via Weekend Testers. I can't guarantee that that will give you a better chance of getting in on what they are looking to do, but judging from the feedback and the direct request, I'd say the odds are pretty good ;).

Again, thanks to all who participate in these monthly events. Your energy and enthusiasm is what makes them worthwhile and fun to do. Additionally, as I hope the above illustrates, it's noticed.

Start a Community of Practice: 99 Ways Workshop #56

The Software Testing Club recently put out an eBook called "99 Things You Can Do to Become a Better Tester". Some of them are really general and vague. Some of them are remarkably specific.

My goal for the next few weeks is to take the "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions. 

Suggestion #56: If it doesn't exist: Start a community of practice or other forum where you and colleagues can talk testing, share ideas/experiences and improve as testers together. - Erik Brickarp

Software testing is a skill. There are many components that go into developing that skill. A woodworker learns over time, with practice, and probably a knowledgeable mentor how to use a variety of tools (table saw, planing joiner, router, sander, lathe and a variety of augers/chisels, etc.) to make beautiful furniture. So it is with software testers and with testing. We need opportunities to work with skilled crafts-people, learn from their experiences, try out our own ideas, and see techniques in action. We develop skills with a variety of tools along the way.

Much is said about using tools, writing test plans, creating automation scripts, but if your experience is similar to mine, those metaphorical "guilds and artisan groups for improvement among your peers" didn't seem to exist anywhere in the vicinity of where I worked. Short of a patient co-worker or two, a regular forum to actually improve and practice testing didn't exist. 

Fortunately, we live in a different world now, and such "peer learning" options do exist. I'm going to talk at length about one of them here... and I'm amazed I've been able to go this long in this project without directly referencing this as a workshop topic.

Workshop #56: Participate in sessions of Weekend Testing. Work with and understand the model. Learn how to facilitate session. Encourage others to facilitate. Create a literal or virtual Weekend Testing "chapter" and conduct your own Weekend Testing style sessions.

The truth is, there are a variety of ways that software testers can share their ideas, learn from each other, and help develop and model skill improvements in their testing. Hack sessions, lunch or after work gatherings, meet ups, etc. All fill this need in different ways. 

The approach I'm going to talk about is one that's well documented, has a high level of learnability, repeatability, and portability. As long as participants have a network connection, it can be done anywhere, any time, with any number of people across many time zones and continents. It's the model that is referred to as "Weekend Testing", and yes, standard declaimer time: I happen to be an active proponent of the methods. I co-founded the Americas chapter of Weekend Testing back in 2010, and I am the "resident facilitator" here in the Americas, along with several dedicated individuals who likewise take turns facilitating sessions.

Weekend Testing is a movement. It is a global community. It is a model and a highly portable "process framework" that, after participating a few times, anyone could take the approach and run their own "sessions". 

We actively encourage people to do this. 

To get a familiarity with how things work, I recommend going to the main Weekend Testing site and review previous sessions we have run. For the most part, all sessions are roughly structured the same way. The principal individual(s) in a Weekend Testing session is the Facilitator(s). In most cases, saying that you will be a facilitator means you will be the one seeing the session through from concept to execution to reporting of results. as a quick start guideline, here are the steps that I go through each time I propose, plan, schedule, conduct, and report a testing session.

1. The session is announced in advance, with a date, time, name of the facilitator and basic information about the session posted as an upcoming event on the weekend testing site.

2. Facilitators and other interested parties announce the session dates and times and encourage people to participate. We have an email contact list, and we use Twitter heavily for this purpose. There are dedicated Twitter ID's associated with Weekend Testing chapters. The Americas chapter Twitter ID is @WTAmericas. 

3. A central place to gather communication is proposed and publicized. The traditional tool for this is Skype, since it allows people with a variety of environments to participate, and since chat transcripts are easy to capture and archive for future reference. Most of the time, we limit the sessions to chat only, since that's the easiest to capture and it allows testers from all over the world to participate without taxing bandwidth.

4. A facilitator establishes an overall Mission and specific Charters around what will be tested. The Mission and Charter are generally chosen to help focus on a particular testing topic or testing technique as the "theme for the session. The facilitator also sets a time limit for the session. Usually, it is two hours. The facilitator also chooses the application to be tested. Often, it's an open source tool or a general purpose application to allow for most participants to feel familiar and be able to participate, no matter their skill level. We also get requests from companies to have us hold sessions to directly test a new version of software for them. When this happens, a representative of that companyparticipates in the session as the "product owner".

5. Sessions start at the designated time,  the facilitator will start the actual group chat session about fifteen minutes before the official start of the session. As the Facilitator is contacted by interested participants, they are added to the group chat.

6. At the designated time, the session starts, and then is managed by the Facilitator for the determined amount of time. the facilitator's primary role is to encourage conversation, the completion of the mission and charters, and a discussion/debrief around the designated theme of the session. 

Though not set in stone, the de facto standard session runs for two hours, with the following general guidelines for conducting the session:

00:00:00 - 00:05:00 - Introductions of Facilitator and Participants.

00:05:00 - 00:15:00 - Declaration of Mission, Charter(s) and Purpose of the Session, with time to clarify questions from participants.

00:15:00 - 01:00:00 - Active Testing (with discussion in main group or with pairs of testers working together).

01:00:00 - 01:15:00 - Checkpoint of group. Sometimes, it's warranted to extend testing, and if se, we add 10 to 15 minutes to the clock. Regroup if extra time is not needed and go to the next section.

01:15:00 - 01:45:00 - Debrief and discussion. Facilitator asks questions, encourages discussion on the theme, sees what went well, what didn't, what could be improved in the future.

01:45:00 - 02:00:00 - Closing comments, announcements of next session, etc.

7. After the session wraps, the facilitator gathers up any artifacts of the session. Examples are the main chat transcript, additional side chat transcripts from pair testing, if desired, notes, mind maps, bug entries, etc. and packages them together in a location that all participants can later share or reference. This can be as informal as a Google Drive or Dropbox Public folder, or it can be as formal as actually posting to a dedicated web server.

8. Finally, the facilitator or any number of other participants creates an "experience report", which is a basic summary of the session, the focus of the mission and charters, interesting comments that came out during the session, general takeaways, and a link to the full session chat transcript. Generally, the names of all the participants are included in the experience report as well. Here's an example of an experience report on the Weekend Testing site.

Wow, sounds like a lot to handle, huh? In some ways, it is, but it has the benefit of being very modular. Sessions can be handled by one person, or responsibilities shared among a group. The beauty of the Weekend Testing model is that it is very portable. It can be done anywhere, at any time, with any number of participants. 

Caveat: it makes sense to keep session participants to a manageable volume. My experience indicates that sessions with five people makes for a good minimum number to keep the discussions interesting and active. Twenty-five people is a reasonable limit, so that everyone gets a chance to meaningfully participate. Beyond that, it becomes very hard to keep the group focused (the phrase "herding cats" is appropriate).

The Skype model (IRC, other chat client, etc.) makes it possible for sessions to be recorded, uploaded, read and reviewed later with context preserved, and acts as a document of learning, teaching and managing others.

One other long standing hallmark: Weekend Testers by design is "school agnostic". You can come from any background, experience level, and approach. We won't judge. We won't criticize. We consider Weekend Testing and the sessions conducted to be a "safe space" to learn, ask questions, get answers, and try out ideas. Anyone looking to carry this idea to their own efforts, we in the Weekend Testing movement ask that you carry that philosophy with you as well.

Bottom Line: 

The Weekend Testing model is not the only one out there, but it is, in my opinion, my personal favorite model for a genuine, engaged peer participation method. While we have some standards and protocols we use to help make sessions run smoothly, they can be adapted and modified by those who wish to experiment with different approaches. 

I am serious when I say "take the model and run with it". If you want to make a "team version", it's easy to do. If you want to make a go as "Weekend Testing on Campus", go for it. You may even find that you have enough critical mass and interest in creating your own oft meeting chapter. 

Regardless of how you choose to do it, just do it. Make a commitment to get a group of people with varying interests, strengths and skills, learn from each other, and provide a way that will help others who come along later.

What's the Risk? Weekend Testing Americas Returns August 10, 2013

Again, I figured some of you would like to have a break from the barrage of 99 Things posts, and what better way than to announce our next Weekend Testing Americas session.

First, the formalities:


Weekend Testing Americas - Session 42

Date: Saturday, Aug 10, 2013

Time: 12 p.m. - 2 p.m. (Eastern Daylight Time).

World Time: http://www.timeanddate.com/worldclock/fixedtime.html?msg=Weekend+Testers+Americas+%2342&iso=20130810T12&p1=179&ah=2

Facilitator: JeanAnn Harrison


Risk Based Testing for Mobile Application

All will need to download onto their mobile device a mobile email application. You can use either Yahoo Email app or Gmail app. Set up an email account if you do not already have one. Be sure to have notifications set up to be sent to phone when a new email is sent.


Agenda:


1) Brief discussion of risk.

2) Group participates in creating a risk based plan/approach for testing

3) Group implements testing (we can split up into groups to cover more testing)

4) Debrief: includes did we follow our risk based testing plan, how much test coverage do we feel we achieved


Logistics:


Add "weekendtestersamericas" to your Skype contact list if you have not done so already.


About 20 minutes prior to the start of the session, contact us on Skype and let us know you would like to participate.


Please let us know if you have any questions.

Weekend Testing Americas This Saturday: Fitness Software & Domain Knowledge

I've been asked a number of times if Domain Knowledge is essential to being an effective software tester. Part of me says "well, of course... if you don't understand the domain, how could you really understand the potential problems that users could have?" Makes sense, but sometimes I wonder if that's really true. If one has a "universal toolkit", would they be able to find important problems even if the area in question was not something they knew a lot about?

It's with this idea, and my own interest in geting back into shape after my surgery, that I felt it would be great fun to put that theory to the test. The app I'm interested in testing is called GAIN Fitness, and it is available for browsers and for smart devices (iphone, Android, tablet, etc.). It's designed to help people make workouts based on their goals, their fitness levels, and other details. It promises to be a one stop shop to help get someone in shape.

Cool, so can we test this? I'd say, of course, yes, but the even deeper question would be "Does a tester who knows a lot about fitness and training have an advantage over a tester who doesn't?" In the past, I'd say "well, of course" (see, I said it again), but again, now I'm really curious if that's true. It would be great if we could get a cross section of testers who are knowledgeable about fitness and training, and at different levels. Example: weight lifting, I know a lot about. Yoga, I know next to nothing about. Does that mean that I can't effectively test the Yoga components?

Either way, this is a different kind of app to test, and I figured it would make for a fun session. My cardinal belief is that, if you have an interest in something, it's possible others will, too. One never knows until they put it out there.

So with that...

WTA-41 – Getting in Shape with Domain Knowledge

Date: Saturday, July 6, 2013
Time: 10:00 a.m. – 12:00 p.m. PDT

Click for World Clock and Time in Your Area

Attendees: TBD
Facilitator: Michael Larsen


Joining Weekend Testing Americas Sessions

1. Make sure to add “weekendtestersamericas” to your Skype contact list.

2. Send us in advance a request that you want to join the session (any RSVP’s we receive will automatically be added to the session). Also, if you contact us about twenty minutes before the start of the session and say you want in, we’ll add you. Simple as that.

Weekend Testing Australia/New Zealand: Reloaded

This evening (well, this evening for me, your time most certainly will vary), we will witness the return of Weekend Testing Australia/New Zealand (WTANZ)!

When Marlena Compton made her trek across the Pacific from Sydney to San Francisco, WTANZ went into hibernation. This made me a bit sad, since the WTANZ sessions were the ones I attended as a participant, rather than as a facilitator.

Alessandra Moreira and I have been in discussions over the past couple of months. When I saw that she was willing to get up at 3:00 a.m. Australia time to participate in Weekend Testing Americas sessions, I had a pretty good hunch that I'd found someone crazy enough to be willing to facilitate closer to home. That hunch turned out to be true :).

Thus, today (which is Saturday already in Australia), from 2:00 p.m. to 4:00 p.m. Sydney time (which translates to 9:00 p.m. to 11:00 p.m. Pacific time), WTANZ will be hosting a session dedicated to test oracles, using the mail.com web client as the product under test.

The Mission:
Using an alternative web email client: mail.com, the focus will be on finding bugs and observing how Oracles play a part in deciding if something we see is a bug or not.

From the Weekend Testing site:

Oracles are principles or mechanisms by which we recognise a problem. Below are links with more information on Oracles in Software Testing:

http://www.developsense.com/blog/2012/07/few-hiccupps/
http://www.developsense.com/blog/category/oracles/
http://www.associationforsoftwaretesting.org/2012/06/12/observation-inference-oracle/#comments

For those who want to participate, the session will be held over Skype, as usual. No video or voice required, just chat. To join this session add "WeekendTestingANZ" to your Skype contact list, and then be on Skype 15 minutes prior to the start of the session. From there, you will be added to the discussion. 

To keep in touch with WTANZ and upcoming events, follow @WTANZ_ on Twitter.

It's great to see this old friend back and active. Looking forward to coming out to play with you all tonight!

Weekend Testing Americas: Passing the Baton

Tomorrow will be an interesting day for me, not so much by what I will be doing, but for what I will not be doing.

So far, only once in Weekend Testing Americas history have I physically not been part of a session, and that was because I had just been released from the hospital with a broken leg. Albert Gareev gamely stepped up and took my place for that session, and I'm grateful to him for doing that.

This time, while I have something else I need to do, as I was considering postponing the session until I was available, Justin Rohrman contacted me and said he had a session plan, and wanted to know if he could run with it. I realized that, if I was actually going to have others be facilitators, I had to actually let them facilitate. Thus, rather than wait and postpone until I could be available, I've asked Justin to take the lead and facilitate tomorrows Weekend Testing Americas session completely in my stead. Just as Ajay and Markus had to finally decide I could lead sessions on my own, now is the time to for me to put my faith in Justin and let him lead this one on his own.

I'm sure he'll do fine :).

I shared some thoughts with Justin, and I realized that a lot of the advice I gave him was appropriate to any other testing endeavor, and wasn't just specific to our Weekend Testing environment. With that, I offer the following.

A Facilitator for Weekend Testing events is really responsible for just three things. They need to manage time. They need to articulate the session goals. They need to encourage participants to get involved. That's the core of what we do. The rest (setting up sessions, promoting them, adding people to the Skype chat, typing up an experience report, etc.) that's all mechanics and "busy work". It's important, don't get me wrong, but the first three items really are the most important. Manage the clock. Articulate the goals. Encourage participation and effort. Any test manager in any organization is really responsible for the same things.

Managing time: This is important because we have a two hour block of time. We could do longer, I'm sure, but then it cuts into people's other commitments, and really, we're already asking a lot to get testers to willingly give up part of their weekend as it is (don't get me started on the testers in India that join us at 12:30 a.m. for these sessions... yes, that's after midnight their time. That puts a whole new spin on dedication in my book :) ). Thus, it's vital that we keep a focus on the time that we have, and that we accomplish what we set out to do in that short time period with focus and clarity. That leads to...

Articulate the goals: I remember well a couple of years ago when James Bach attended a session and he, rightly, called me out for our sessions being too vague. Since we had such a short time together, it was vital that we were able to make missions and charters that were clear, specific, and targeted to specific tasks. I was worried that such targeted missions and charters would be too limiting. He proved to me that, in most cases, that's not the case. Even with just testing one simple area of a site, we were able to have a conversation that spanned almost two hours of active dialog, and that was with us looking at just one screen. It wasn't that the screen was any different than any other, but that the goal was focused and specific, so that we were able to discuss and consider the aspects of that one screen without distraction or loss of direction. It was a worthwhile lesson, and one I try to practice still.

Encourage participants: Some people are just not comfortable with talking out loud, even in chat clients. There may be many reasons for this. Some may be novices, some may have language barriers, and some might not want to be seen to "appear the fool". I've learned to never underestimate the terror of that last one. For many, they fear that they will say something foolish, or appear to be "less smart" among their peers. For this purpose, I often put my own ignorance on display in these sessions. Yes, I'm facilitating, but that doesn't mean I'm an expert on the topic. Often, I know less than most of the participants... and that's OK. My goal isn't to be the one saying everything, it's to encourage dialog and learning. I can do that best by asking about things I genuinely don't know, and often, that's a lot. By my doing so, in many cases, it helps others open up and ask questions, too. We're not here because we are experts. We're here because we all can learn from each other, and that's the whole point of Weekend Testing. We learn from each other, sometimes in small ways, sometimes in much larger ways.  As long as we each learn something to bring to our craft, that's what matters.

Tomorrow is a new day. A new facilitator will step up and run with the session, and I will not be there. I do, however, want to encourage all who can be there to do so. Details on tomorrow's session can be found here.

Some Thoughts on Mobile Usability

Today was an interesting Weekend Testing session, as they often are. More to the point, it was interesting because we looked at a topic we hadn't covered in WTA as of yet, usability as it relates to Mobile Devices.

 For today's session, I decided to take out my Kindle Fire, load up the Facebook app, and see if I could actually make sense of the interface and what it was supposed to have me do. Others used the devices that they had available (and one participant commented that they were rather frustrated that they would have to use their iPhone as they'd much rather use their iPad Mini, proving the point that usability is indeed a moving target).

 One of my first discoveries was that all of my old Messages that I had read on the desktop app were now marked unread. I had to scroll through a lot of messages to make sure how far back we went. In some cases, two years! Needless to say, there's some variance between what the the mobile app and the desktop app are sharing. Another observation... The side bar controls lists something for "Close Friends", shows two names, and then is says "More Friends". As I am expecting it to expand and show me a list of "Close Friends", instead, it takes me to a listing of news feeds from all of my "Close Friends". Well, OK, I guess... except what I really wanted to see was a list of who was in that group. Before I got to indignant, though, i decided to do the same thing on my desktop app... and it does the same thing. So yeah, consistent, but still not what I would LIKE to have it do.

 Justin asked us to consider a number of questions as we were doing these exercises: 

Initial Learning:
How did you learn to use the software?
What made the experience difficult?
What made the experience easy? 
What would make the software easier to learn?

For me, the biggest factor was that there are certain "standards" that mobile device designers use, and the more that apps use those standards, ultimately, the "easier" it is to learn. that's not to say that their system is the best design, but it's true that, if our experience is consistent, then it's safe to say that those apps that follow those standards are most likely to be picked up and adopted by lots of people.

Memorability/Learnability:
Was the functionality easy to recall? why? why not? 
What would make the software more memorable?

Again, with this batch of questions, moving around the app and seeing where it took me was the way to actually understand and get a feel for these options. I am still one of those people who uses the back button to go from page to page, and it's becoming painfully obvious to me that that paradigm is not very helpful in the mobile space.

Error Rate:  
Describe the errors you made while learning.
What lead to you making these errors?
What helped you to not make errors?
What improvements would help reduce user error rate?

For me, seriously, the error rate is largest simply because I'm not use to touching buttons and hitting keys that are represented as buttons. I'm not very fast, and my hands are not petite. as such I a make a lot of errors. Since I do, I often find myself wishing I could just pull out my laptop and just do what I want to do already. That also may be a simple conceit of my working with what I do and where I do. For many out there, their iPhone is really their only "computer".

Efficiency:
Were you able to use the software in an efficient manner?
 Describe what made the product efficient or inefficient for you.
 How would you improve the efficiency?

This was the toughest area, in that I really don't find mobile apps to be very efficient, and the biggest reason is real estate. With a laptop screen, I can perform certain tasks in two or three steps. ON a mobile device, I am finding that it requires six to eight steps to do the same thing. Multiply that by lots of interactions, and it's easy to see why, at least for me, I'm more willing to just wait until I can get on a desktop to do those things. For others, they think and do things differently,and that's all cool.

Mostly, this was a god session to get a number of testers together and discuss different aspects of usability, and to reiterate and rephrase what Jerry Weinberg said about quality:

Quality is value to some person (that matters).

We can just as easily say the same thing about usability. Usability is value to some person who matters, and in this case the person who matters is "us". We all will have different impressions about what is usable and what is not. The danger, though, is that we place to much of an emphasis on what WE consider usable. that may work in many cases, but it also may prove to be misleading. What I may find usable may be utterly unusable to someone else. Keeping an open eye and open mind, and getting multiple points of feedback is very helpful in this case.

Weekend Testing Americas #37: Mobile Usability

Yep, it's that time again, time to get the word out about our next session and what we are going to cover.

One of the things we tried last time, and it seems to great effect, is to do some sessions that are broader reaching, focusing on bigger topics, and giving people a chance to plan for them and to participate. Usually, we keep the sessions kinda' hush hush, so there's no "favoritism" for certain participants, but we decided that, with some topics, there's really no need for any of that.

On Saturday, March 2, 2013, fledgling facilitator Justin Rohrman will be leading us in a discussion and testing session around Usability. The preliminary notes for this session, courtesy of Justin,  are below. If you find them helpful, please let Justin know. Also, if these early bird posts are helping to encourage you to participate in these events, please, let us know that as well :).



Weekend Testing Americas #37: Usability testing On Mobile Devices

Date: March 2, 2013

Time: 10:00 a.m. Pacific, 1:00 p.m. Eastern
Suggested Mission and Charters: Explore the Facebook Mobile interface and specifically test for usability

Assumption: Attendees must have Facebook running in a mobile environment. Native or mobile browser versions are fine.
Topic: LearnabilityPick an area of the app you are not familiar with (pair up however makes sense. Spend some time getting familiar. Discuss your learning experience. How did you learn to use the software? What made the experience difficult? What made the experience easy? What would make the software easier to learn?

Topic: MemorabilityFor your group, describe the part of the software you just learned. Was the functionality easy to recall? why? why not? What would make the software more memorable?

Topic: Error RateDescribe the errors you made while learning. What lead to you making these errors? What helped you to not make errors? What improvements would help reduce user error rate?

Topic: Efficiency Were you able to use the software in an efficient manner? describe what made the product efficient or inefficient for you. How would you improve the efficiency?

Retrospective/Debrief:
What did we learn in this session?
Would anyone describe usability testing in a different way after the hands on exercise
What kinds of tests can you apply when you go back to work
Was this a useful session

References:
http://www.nngroup.com/articles/usability-101-introduction-to-usability/

http://www.amazon.com/Donald-A.-Norman/e/B000APP96A/ref=sr_ntt_srch_lnk_3?qid=1360688055&sr=1-3

Weekend Testing Americas 36 This Saturday

First, I need to say thanks to JeanAnn Harrison who has been going above and beyond the call of duty to help run these sessions and come up to speed as a facilitator. It's unlikely that I will ever disengage completely from Weekend Testing, I think it's a valuable service and i want to encourage its growth. Having said that, it's nice to know there are other facilitators who are willing and able to run things if for some reason I cannot be there :).

The following is from JeanAnn and would be a good starting point for everyone if they want to participate this Saturday.

Mobile Test Experience Opportunity on Weekend Testing Americas Session -
Configuration Tests on Mobile Devices
Come join me on Saturday 2/9 at 1PM EST/10AM PST for the February session of Weekend Testers Americas.

We will be performing tests on the Facebook versions for the Mobile Phone, Tablet and Laptop/Desktop.

Out mission and charter will include the following (we may not hit it all, but these are the questions you should be prepared to consider as we do this session):

• What kinds of tests should be performed on all 3 configurations and what different tests need to be performed based on the configuration? 
• What are the differences pertinent to the desktop application in comparison to the mobile version? 
• How are the advertisements presented on the desktop version vs the mobile phone and tablet versions? What about the newsfeed on each configuration? Are they the same? 

What else can we find? 

• What are the differences of the application on the phone, tablet and desktop? 
• Will the Android version be very different than an iPhone or iPad? 
• What can we learn in how we test all configurations? Does the operating system make a difference from device to device? 
• Does the device make a difference: mobile phone over tablet? 

To join this session, please do the following:

1. Add “weekendtestersamericas” to your Skype contacts if you haven’t already.

2. Fifteen minutes prior to the start of the session, please message “weekendtestingamericas”
and ask to be added to the chat session. Once we see you, we will add you to the session.

We hope to see you there!

Weekend Testing 2.0?

Today was an interesting experiment. I say "interesting" in that I set out to do one thing, and I ended up doing something completely different and highly unexpected. For starters, we scheduled a session to discuss and talk about Accessibility Testing, and some of the interesting aspects of it and how we could encourage others to consider it and methods they could use. From that, we compiled a good list of ideas for accessibility approaches, design and testing. For those interested in the resources we discussed and shared, those are below:

Accessibility Testing Ideas, Resources, And Tools

• Web Accessibility at a Glance (W3C)
• Accessibility Testing Wiki Entry (W3C)
• Complete List of Web Accessibility Evaluation Tools (W3C)
• Web Accessibility Testing (Jim Thatcher's site)
• Section 508 Standards for Accessibility (EPA site)
• Accessibility Testing (webnauts site)
• Screen Reader User Survey
• Accessibility Mind Map (Ministry of Testing)
• Accessibility Options (Apple)
• Testing For Accessibility (msdn)
• Non-Visual Desktop Access (open source screen reader)

With that, I could also mention that we had four active participants on the call (thank you Amy, Teri and JeanAnn, and thank you Lalit and Shmuel for trying your hardest to get in and stay in, but alas, 'twas not meant to be), and call it a day and say "good show, all is great", but that isn't really the case. I will say it was a good and productive discussion... except that I did most of the talking. This isn't for a lack of trying on the part of the other participants. This seems to be a limitation on the medium we've been experimenting with the past couple of months (we have been using Concert-oh as a meeting tool), and we have been emphasizing conversation and real time talking over the standard model we have used in the past, which has been a Skype session with a bunch of participants.

Because of these challenges, it's led us to ask a deeper, more fundamental question, and I will confess, at the immediate moment, I don't have a clear answer for this...

What is it that we want to accomplish with Weekend Testing, anyway?

Now, understand, I'm asking this as a bit of an interloper. I wasn't there at the beginning, I came in about a year after this got off the ground, and my focus has been on the Americas, though the number of participants that we get from outside the Americas often eclipses those of us here in the Western Hemisphere (just sayin'). We have to ask ourselves a different set of questions at this point:

Who is the primary audience for Weekend Testing?
Is it for beginners or relative novices to have a place to practice testing?
Is it a social environment for seasoned testers to congregate?
Is it a place to mentor and be mentored by testers of different backgrounds?
Is it a place to learn new techniques and discover new ideas?
It it a place to challenge assumptions and debate ideas?
Is it a place to do new and exciting things in the world of testing?

See, personally, I think it is all of those things. It's not that we have a lack of things to cover, but that the amount of what we can cover is so dense, there's no way we could do it all. There's also possibly a hundred things that we could do, and of those hundred things, I might be able to address a few dozen of them with something approaching a half of a brain. This means we need to have a chat. All of us. What do you value in Weekend Testing? Do you value it? If you have been a participant in the past, what's stopped you from coming? If you haven't participated, what turns you off about it? If we are covering the same tired ground, what would you like to see us cover in the future? If you're sick of hearing from me, who would you like to hear from?

The fact is, we're at a bit of a crossroads now, and we have to make a decision where it is we want to go. I see the value of Weekend Testing and I genuinely enjoy facilitating sessions, but I think we need to make some changes in both what we do and how we do them. We've tried some the past few months, with mixed success. Now I'd like to hear what you would like to see WT2.0 become. Let me know your feedback, either in the comments, or feel free to email me if you prefer (mkltesthead at gmail dot com).

A Call for Participation: Accessibility Testing Weekend Testing

On Saturday, January 12th, 2013, I will be hosting another Weekend Testing session from 10:00 a.m. to 12:00 p.m. Many of you familiar with this type of thing already know the drill. We pick an application, we structure a theme around it, and we go to town for two hours. It's usually fun, engaging, and a chance to share testing knowledge and skills. I enjoy being the facilitator for these events.

This time, I would like to do something a little different, and yes, I'm asking for help. Specifically, I would like to look at the challenges, approaches, and ideas around testing accessibility software. In the past few weeks, I have become more aware of this market and the needs of understanding the challenges that people face. I'm currently using two tools that are part of our testing (JAWS, which is a screen reader, and Dragon Naturally Speaking, which is a dictation/voice recognition package). These tools have one distinct drawback... they are expensive. They are also large downloads, and may be difficult to get for some participants.

Thus, I want to do something different this time. Rather than do a bug bash, I'd like to see if participants would be willing to share their experiences, their frustrations, and their successes working with accessibility software, share tools and tips, and be willing to talk about and share those experiences with their fellow testers. Oh, and quite possibly, the most rapt and attentive attendee will very likely be me! In short, I have a need, and a desire, to better understand this market and the issues that people face when using accessibility software. If you would like to help me learn more (and I'm willing to bet others out there would be as well), then please come and join us next Saturday.

This meeting will be held through Concert-Oh. Meeting links is:
http://www.concert-oh.com/web/meetingDetail/xbPOfvifO0AF9YBCTyUJ3A%3D%3D

Deconstructing Weekend Testing: A Test Coach Camp Talk

As I was preparing talks for the Test Coach Camp session that preceded CAST this year, I had a number of ideas I wanted to discuss. Most of them were centered around Weekend Testing, since in my "coaching" career per se, that has been where I've done most of it and most regularly. As I was preparing materials for explaining the Weekend Testing model, I had a heretical thought... what if I ran a session completely deconstructing Weekend Testing? If for some reason, the main site were hacked and destroyed, and we had to start it all over again, what would we do?

With that, I decided to make that a core element of what we discussed. It was interesting to hear some of the feedback from participants, those who were interested but never did a session, and those who knew nothing about it at all. I hope this isn't seen as a blind side to the founders or other facilitators, it's not meant to be. It is shared with the spirit and understanding that we have something awesome, but even awesome can strive to do more, be more and get better.

What are some thing we discussed?

The first and most obvious aspects that were discussed was the main site itself.  When we go to the Weekend Testing site, we see prominently displayed the last three sessions of weekend testing that were held. these are experience reports,and they are displayed at the top. On one hand, this is helpful, because it shows what we have done and what we do. This is great for regulars who have missed a session and want to get caught up or see what happened. However, for most curious lurkers, they don't really want to know what has already happened, they want to know what will happen. When is the next session going to occur? Many of the commenters on my talk said that, instead of giving such prominence to past activities, we should be using that slide show to advertise the next testing sessions.

Tied into the previous aspect is how we find out about sessions. As I explained, the tradition has been that we advertise on twitter and via email about a week prior to sessions. It's also been to put the sessions up on the weekend testing site in the forum for announcing sessions. One participant explained to me the process of finding a session. They first:

Had to navigate to the site.
Click on the Forum link.
Click on Next Weekend Testing Session.
Scroll through and find the one that was in their geographical area or time zone that worked for them.

It's been proposed that these sessions and their times and details should be front and center, the first thing people see when they get to the site. I think that's a very reasonable request :).

Other comments related to how we construct the sessions. This is a common question, and one in which each chapter has addressed in different ways. For most of the sessions, we need to expect that they will be one-offs. That means that we need to make sure that what we present, what we discuss, and how we discuss it will be handled in our two hour meeting time. because of this, there are certain topics that we just don't have the time to get in to, such as more advanced automation techniques, or more detailed explorations of a product. We tried this with a approach that we called Project Sherwood a while back, and while it worked well the first few times, the problem was getting people to commit to a regular meeting time. This has led to questions about "asynchronous sessions", or making a weekend testing model that utilized the forums and allowed for a more in-depth discussion that, rather than just being for two hours, might continue for a week or more.

Another thought that was brought up was an interesting question... how could we encourage more facilitation? Right now, we have sessions that have one or maybe two facilitators? What if we were to make it so that there were many potential facilitators in a given session? How would we do that? What roles could we give them? What if one of the goals was a rapid capture of the session, so that the experience report was published within minutes of completing a session, rather than hours or days, which is sometimes the norm? What if there were ways that we could leverage the skills of the collective of testers to help streamline the process of making experience reports, so that the announcements become the experience reports, and the next announcements go up as quickly as possible? It may mess with the egalitarian model of everyone coming into the sessions on the same footing, but maybe that's OK.

There was a lot of other areas we talked about as well, and I am looking to engage the other facilitators and maintainers of the Weekend Testing site and approach as to how we can scale our creation and help it to grow and be useful to our participants. To that end, I'll ask all of you the same question... if for some reason, the Weekend Testing site were destroyed and we had to rebuild it, what would you like to see us do. More to the point, what would YOU be willing to do to see that vision become a reality :)?

Weekend Testers Americas Is Looking For Facilitators

For the past year and a half, I’ve happily run the Weekend testing Americas sessions and, with few exceptions, I’ve been the primary facilitator for these events. So far, it’s worked great… except when things happen where I can’t be there. Then we have a problem.

Sadly, due to some automobile challenges and some needed reshuffling of drivers for my Boy Scout Troop and those attending Scout Camp starting July 7th, and since we are now no longer self contained (originally all Adult leaders attending were driving there and back, now we need to recruit some drivers to go up and come back the same day) there’s no way I can get kids to Scout Camp and facilitate the session at the same time.

This is a known danger with me, and it stems from being a lone gun much of my career. I tend to do things and just, well, do them. My biggest weakness is that I rarely ask for help, and because I rarely ask for help, it tends to leave a vacuum when I can’t be there to do something. So starting today, I’m actively recruiting for Weekend Testing Americas facilitators to be.

What does being a facilitator entail. At its core, it means committing a few hours on a Saturday (or any other day, really, the facilitator sets the schedule) so that they can do the following:

- Set up a Skype session (using the “weekendtestersamericas” account)
- Welcome and add attendees to the group discussion
- Introduce the topic, the testing objective and the charter(s)
- Encourage newer testers to participate (often pairing with people who are very new to the process)
- Keep track of the time and make sure that the discussion moves well and freely
- Ask questions to keep the conversation moving
- Make sure the session ends on time

After all is said and done, they capture the Skype chat transcript and save it as a document, and then the final steps would be to write an experience report and post it, along with the chat transcript, to the Weekend Testing site.

There are some additional steps as well, usually involving posting announcements of sessions to Twitter and sending an email to the list of contacts, getting more testers to likewise advertise the sessions, and posting the “next session" details on the weekendtesting.com site.

Is that asking a lot? I honestly don’t know. I’ve done this for so long now that it’s mostly automatic. It may be a lot to ask one person to do, but it may not be too much to ask two or three people to do (and to be fair, I frequently get facilitation assistance in sessions from Albert Gareev and Ajay Balamurugadas, so even if you go it alone, you most likely will not be “going it alone”).

So yes, this is a call to arms, and a request. I have been remiss in sharing how to do this, and I want to help spread the ability and knowledge so that, when I cannot be around, Weekend Testing Americas doesn't just stop. Here’s another thing, you do not have to be in the Americas to facilitate the sessions. You can be from anywhere in the world and do this. My only request is that you schedule the session(s) at a time that participants in the Americas can reasonably be there (we’ve typically used a range of from 9:00 a.m. – 3:00 p.m Pacific, with 10:00 a.m. Pacific being the sweet spot).

If you are game, please feel free to email WTAmericas@gmail.com and I will most certainly get back to you… very quickly, I’m willing to bet ;).