The Different Dimensions of Accessibility: Cognitive: Training for Accessibility (Part 6)

While often overlooked, cognitive disabilities are perhaps one of the most common yet least seen of the disability families we have discussed. Cognitive disabilities are varied and present some challenges that can affect how navigate and interact with online content. 

word cloud for cognitive disabilities: words include cognitive, disability, area, attention, experience, fatigue, Hemingway, memory, situation, stress, user

Cognitive disabilities cover a broad range of conditions. Memory, attention, comprehension, and problem-solving are all affected, and for some people, all of the boxes are checked. 

Primary Disabilities

Down Syndrome: a genetic condition where people have an extra copy of chromosome 21. Cognitive impairments, delayed development, and distinctive physical features are often seen in this condition. Levels of cognitive impairment can vary from mild to severe.

Dyslexia: a learning disability that can affect reading, spelling, and language comprehension. They may swap letters or read certain characters out of order or need to step back and slowly read the text to process what they are seeing.

Dyspraxia: Also referred to as Developmental Coordination Disorder. While often considered a mobility disability, dyspraxia can also have an effect on the actions of writing and typing and cause stress to cognitive functions as well.

Traumatic Brain Injury: A sudden impact to the head such as a concussion or bone breakage in the skull can cause long-term issues with memory, attention, and problem-solving.

Fetal Alcohol Spectrum Disorders: people exposed to pre-natal alcohol in high amounts during their development in pregnancy can develop a range of disabilities. these can affect memory, attention, impulse control, and social skills.

Secondary/Situational Disabilities

Cognitive disabilities are perhaps one of the areas where situational disabilities may be the most prevalent. There are numerous situations that can put a strain on our mental faculties and can cause us issues that are not necessarily long standing. Many of these share similarities but these are all situations any of us could find ourselves dealing with.

Cognitive Overload: stressed, fatigue, or just having a million things coming at us all at once. These situations can make it more difficult for us to process information and make decisions.

Reduced Attention Span: again, stress and fatigue can contribute to this, as well as side effects of medication or recreational alcohol or drug consumption. 

Memory Impairment: there can be a lot of situations that lead to this. Again, stress and fatigue but also just being in an unfamiliar or foreign environment, especially one where the language that is spoken/written is foreign to you. 

Design Considerations for Cognitive Disabilities

When we want to address Accessibility and accessibile design for cognitive issues, it's important to realize that each area is unique, and individuals within these categories can have varying strengths, challenges, and needs. This is definitely the area where one size will not fit all and a lot more judgment calls are required. Still, here are several suggestions that should help considerably and make the experience better for all users.

Avoid Complex Navigation: having multiple layers of nested content or menus of menus is not ideal. It's easy to lose track of where a user is and then trying to get back to that location could be challenging if not impossible. Try to limit menus to one layer at maximum if possible.

Avoid Overwhelming With Information: A wall of text is not welcoming to anyone and for people with cognitive disabilities it is even more daunting. Try to use space, break up large paragraphs, and aim for a simplicity of message where it makes sense. 

Allow for Longer Time Limits: Aim to make it so that timers or time pressures are minimized. Some systems require this but make it so that the value can be adjusted reasonably

Provide Alternative Means for Content Display: Have clear labels and do not assume that users will get by inference what is meant by using a color in isolation or a metaphor that may be well known but some people may not be aware of that meaning. Provide clear labels and alternatives that will provide more context if necessary.

Avoid High Contrast or Flashing Content: this is an example of where a suggestion that works well for one group could be a distraction or a problem for another. High contrast screens that help those with vision issues could be too stressful to read or look at for people with cognitive disabilities. Having the ability to easily adjust the contrast can be a big help. Overly aggressive flashing and strobing is just a bad approach overall, IMO.

Use fonts that are not overly busy or decorative: font choice can have a profound effect o the readability of online text and for people with cognitive issues, overly fancy fonts can be a struggle to read. aim to make sans-serif fonts and typical typefaces a standard or make it easy for these typefaces to be selected. 

Write For Everyone (and Learn to Love Hemingway): this is perhaps one of my favorite cognitive tools to use, the Hemingway Editor. I get occasional raised eyebrows when I mention that I think of Hemingway as an Accessibility tool but I really see it as such. Hemingway is designed to help you improve writing from a clarity standpoint and also to help fix/avoid overly complex prose or impenetrable walls of text. You can also set a reading comprehension level and see how well your writing falls into that level (or doesn't).

As I stated at the beginning, cognitive disabilities are perhaps the most common and also the most neglected because we don't necessarily "see' them. Understanding how many there are and how varied they are, we can see a lot of areas that we can do better and can look out for to help make the experience of being online and using digital products better and more usable. Again, it doesn't take much in this stressful and fast-moving world to feel overwhelmed. These additional Accessibility features might be the ticket to making better interfaces and experiences for all of us.

The Different Dimensions of Accessibility: Auditory: Training for Accessibility (Part 4)

 I was hopeful yesterday when I was making my post on the dimensions of accessibility that I'd be able to cover all four of the main areas in one blog post. I could have if I wanted to make a post that was exceptionally long but that's not my point in doing this. Instead, I realized that it made sense to break the main areas up and look at them independently and consider the realities that each area faces, both in the way of chronic/persistent conditions, as well as those that are transient/situational. If you are enjoying this series, thanks for coming along for the ride, there are lots more coming in the next several days.

Wordcloud for Auditory Accessibility: Keywords include: sound, difficulty, auditory accessibility, hearing, individual, disease, auditory information, person, Ménière's

Auditory Accessibility

When we are discussing auditory accessibility, we are specifically looking at challenges faced by individuals with hearing impairments. Just as visual impairment is a spectrum, so is auditory impairment. Additionally, there are both chronic/persistent issues that we consider to be primary issues as well as situational challenges that may be transient but certainly matter at that moment.

Chronic Auditory Challenges

Deafness: This term is not as cut and dry as many would believe. Just like blindness does not mean a 100% loss of sight, deafness does not necessarily mean a 100% loss of hearing. The term "deaf" refers to individuals with significant or profound hearing loss. What is significant or profound? A medical Audiologist would consider the severity of hearing loss in decibels (dB). In other words, at what decibel level would a sound have to be for a person to hear it? I am not an audiologist, so do not take what I am saying as gospel but the following values come from the American Speech-Language-Hearing Association (ASHA). 

Degree of hearing loss	Hearing loss range (dB HL)
Normal	–10 to 15
Slight	16 to 25
Mild	26 to 40
Moderate	41 to 55
Moderately severe	56 to 70
Severe	71 to 90
Profound	91+
Source: Clark, J. G. (1981). Uses and abuses of hearing loss classification. Asha, 23, 493–500.

To put this into perspective, a person with normal hearing would be able to distinguish sounds within the -10 to 15 dB range, while a person with severe or profound hearing loss would need to have the same sound ramped up to 71dB or above 91dB to hear the same sound. Those people within the severe to the profound range are what we consider to be "deaf". These are people for whom traditional methods of using devices like hearing aids or cochlear implants will not help.

Hard of Hearing: This is a broader category and may include people on any level of the auditory spectrum. For that matter, hard of hearing can absolutely be situational. People with mild or moderate hearing loss may struggle to understand or interpret sounds in noisy environments or may be limited to the frequencies that they can hear. We can also include conditions such as Tinnitus and Ménière's Disease. Tinnitus is the perception of sound where there is a ringing, buzzing, or hissing sound in the ears. It can prove to be a distraction when. auditory information is present. Ménière's disease is a disorder of the inner ear that affects both hearing and balance. People with Ménière's disease often describe experiencing vertigo, fluctuation of hearing levels, experiencing tinnitus, and a feeling of pressure inside their ears.

Auditory Processing Disorders: these are difficulties in processing and interpreting auditory information by the brain, even when the person experiencing them has normal hearing sensitivity. There are a variety of these disorders.  They may include:

• Auditory Discrimination Disorder: difficulty in differentiating similar sounds ('P', 'B', and 'D' may sound similar). 
• Auditory Figure-Ground Discrimination Disorder: difficulty understanding speech/sounds in the presence of background noise or many sources of sound.
• Auditory Sequencing Disorder: difficulty understanding and/or recalling the sequence of sounds or words.
• Auditory Integration Disorder: difficulty localizing or integrating sounds coming from different directions.
• Auditory Closure Disorder: difficulty filling in details of missing or incomplete sound information.
• Auditory Memory Disorder: difficulty recalling spoken information or sequences of instructions. 
• Auditory Attention Disorder: difficulty concentrating on sound/information presentation and keeping that focus for an extended period.

Situational Challenges

While the above examples could be seen as being persistent or chronic issues, any of them are also situational or temporary. More common examples of situational auditory issues would include:

Noisy Environments: Background noise in public spaces, workplaces, or crowded areas. My favorite example of this is trying to take a phone call in the middle of a rock concert. That's gijg to be an issue for just about everyone, not just hearing-impaired individuals.

Poor Audio Quality: As a podcast producer, I have had occasions where the recordings we had to work with were... not optimal. In some cases, they were downright bad because the technology we had at the time was just not up to the task but we had to run with it anyway.

Multitasking and Distraction: having to divide attention between numerous audio sources.

So that's a pretty big list of things to have to consider. How do we code and test for accessibility in these situations?

Captions and Transcripts: Provide accurate and synchronized captions or transcripts for audio and video content. Many services do this automatically and the results vary. Still, having a mostly correct transcript is better than not having one at all but if possible, provide a sequenced file that can be displayed in time with the information and that has been proofread and is as close to the audio as possible.

Volume Controls: allowing users to amplify the sound to their specific needs and levels.

Visual Cues and Alerts: Do not rely solely on auditory cues. Create visual options, such as flashing light, varying color or brightness for icons, or allowing for vibration through the mouse or keyboard, if possible.

Clear and Concise Content: where possible, provide simple and clean audio tracks. Avoid the background music if it can be seen as distracting, or allow for an option to separate the vocal track so that it doesn't compete with other sounds.

Avoid Audio-Only Interactions: Minimize interactions that are specifically sound driven. Make text-based or visual alternatives if possible.

Consider Multimodal Options: incorporate sign language interpreters, transcripts, or visual aids for presentations, conferences, or online events.

Sometimes, addressing auditory accessibility may conflict with other accessibility areas. There is no one-size-fits-all approach here. Changes made for auditory accessibility may not be ideal for visibility, mobility, or cognitive accessibility. This is where we have to make judgment calls and not only focus on compliance from a checklist. Still, by considering and implementing appropriate design and coding, and testing for them, we can ensure individuals with hearing impairments have as much access to auditory information and content as possible.

The Different Dimensions of Accessibility: Visual : Training for Accessibility (Part 3)

There are many ways in which we have made great strides in focusing on accessibility. The tools we have at our disposal to both allow for information to be accessible and the tools that are available to help us develop for, test for, and advocate for accessibility are growing all the time. It's an area that can be as deep and wide as you want to make it.

Word cloud for Visual Accessibility issues. Keywords used: Content, device, eye, images, accessibility, user, visual accessibility, contrast, fact, issue.

One factor that gets overlooked, however, is. that accessibility is not a one size fits all problem. In fact, what may work well as an accessibility fix for one issue may be totally inadequate for another. When we discuss accessibility, we typically group these issues into four main areas: visual, auditory, mobility, and cognitive. We can also consider the fact that there are levels of barriers faced depending on the severity and permanence of a particular disability. These range from total to partial, everyday to temporary, and even situational, where the environment a person is in may benefit from accessibility features that would not be necessary were they not in that particular environment at that time.

Today I'm going to focus on the area that tends to get the most attention, which is visual accessibility.

Visual Accessibility

There is a broad range of visual disabilities and impairments that people deal with. These can range from diminished vision and the way that light hits the eyes. There are a variety of visual challenges people can deal with at varying levels.

Persistent (or Chronic) Issues

At the top end of the spectrum are people who deal with complete or profound blindness. Being blind is not necessarily the total absence of light or color (for some, it is) but there are conditions where the inability to get a clear focus on something is significant enough to be considered total blindness. Less severe but as persistent is color blindness. This is where people have difficulty seeing a specific color or picking different colors from one another. In a world where color combinations are often used to impart meaning, this can lock out certain people or at the least make the intended message ambiguous. Photophobiamakes people sensitive to bright light, so very bright backgrounds or flashing content make it challenging to look at certain pages or apps, much less navigate them.

Less severe are conditions such as near and far-sightedness as well as amblyopia (often called "lazy eye"), strabismus (misalignment of the eyes), and astigmatism (the curvature of the eye is off, resulting in distorted vision). Age also plays a factor in the flexibility of the cornea. It's why so many people have to shift to using reading glasses when they reach about age 45 (perhaps the largest market for accessibility technology is the market for reading glasses).

Situational Challenges

There are also a variety of situations that people may find themselves in where their vision can be affected temporarily. eye injury, surgery, or everyday eye strain can put an everyday person with normative vision in a situation where they need to have accommodations to see effectively for a time. 

Often the lighting can change in which if a device or application cannot adjust the brightness or change the size of fonts, it can become a challenge in low or bright light environments. One example that is still common is the fact that many websites are not scaled or modified to work with phones or smaller devices, making the navigation and reading of these sites difficult if not impossible.

Perhaps the most common aspect of accessibility is the use of screen readers and by saying that an application or a service allows a screen reader to work with it, that makes the system accessible. It's definitely a good start but there's much more to visual accessibility than using a screen reader.

Some Basic Accommodations

Alt Text: by including alt text with images, the users of screen readers can hear what the image is displaying and can get a better understanding of what the image is looking to convey (note: descriptive text should explain what the image would be trying to convey to a sighted user).

Color Contrast: By making it possible to either have sufficient contrast o making it possible for the user to easily adjust the contrast, we make it so that backgrounds and foregrounds don't blend together and make the site unreadable to those who would have trouble differentiating the shades.

Use clear and legible fonts: this is an art but having fonts that are easy to distinguish, contrast strongly between letters, numbers, and symbols, and use space effectively will allow for more people to better ready the content that is displayed.

Responsive Design: this is where we can resize and reorder content depending on the display being used (and specifically using and defining an agent that reflects the screen/device being used. Responsive designs allow for a better layout specific to the device displaying the information and eliminate having to resize and zoom in to key areas.

Text Resizing: this will allow the users to adjust the text size easily, either through browser settings or built-in controls on the pages themselves to allow for resizing of fonts and yet and having those resizes scale to the rest of the page elements.

Screen Reader Adaptability: It's important to make sure that the content that we want to have people access can be understood clearly and that we don't burden them with words or content that doesn't matter to them. Also, most visually impaired users will not be able to rely on a mouse for navigation. Using a keyboard or a device that effectively moves focus to different elements is critical. Also, it is important to limit the number of steps required to perform certain actions unless absolutely necessary.

Forms, Buttons, and Sliders: Many of the "eye candy" elements of web pages and apps are difficult to maneuver through when using only the keyboard or screen reader prompts. Make it possible to allow for these interactions with the least amount of interference or the necessity for detailed shortcut steps where possible.

As you can see, there are a number of avenues to consider and situations to get familiar with when it comes to dealing with visual issues. With time and practice, we can all get a better feel and understanding for these challenges and make it possible that there are ways that people can interact with our content when they can't see it the same way that we do.

Regarding Comments and Interaction on TESTHEAD

As I've been going through the site to determine changes I want to make regarding Accessibility and Inclusive Design, I've been doing a review of past posts (with more than 1,000, this is taking awhile, but I'm getting there). In the process, I've also noticed a recent uptick in comments. At first, I was excited, but quickly saw that most of them tended to be the same:


nice blog has been shared by you. before i read this blog i didn't have any knowledge about this but now i got some knowledge. so keep on sharing such kind of an interesting blogs.

This would then be followed by a link to some other site, usually offering training of some kind.

At first, I tended to approach this with a bit of a buzzsaw approach, just deleting them out of hand, but during CAST, I talked to a friend and colleague and described my frustration with this approach. They suggested something I hadn't considered. It may be SPAM. It probably is SPAM if it is linking to a commercial link, but there is a possibility that this is also a new student fulfilling a class assignment to find a technical blog, read a post and comment on it.

Fact is, I don't know, but the better, possibly more naive part of me wants to believe that some of this traffic might be legitimate, so I'm going to make a few requests.

1. If you read something that you appreciate, let me know specifically what you like about the post. That at least gives me an indication that you have read it.

2. Ask me a question about the post. This may be a mild psych thing with me, and I may regret admitting this down the road, but I'm the type of person that, if you ask me a question in social media or via blog posts, I feel compelled to answer. My answer may be "I don't know" or "I'd have to point you to [x]" but I will answer :).

3. If you are posting a link to a site that supports or substantiates what I'm saying, or disproves what I'm saying, that's fair game. Posting a link to your training site without at least explaining why you are doing so is just rude. If you are saying "Hey, I like the pattern matching examples you gave in your post. I'm currently attending a training academy that also covers this, and you might find this useful (link to a specific example that corresponds with the blog post)", seriously, I'm fine with that.

Nonsensical praise like what's posted above tells me that you haven't even read the blog post, you want to get your link on as many of my page as possible, and will guarantee that I will go through and mow such comments out of my feed aggressively. Also, the time I have to spend chopping out bunches of bogus comment posts limits the time and attention I can spend writing new stuff.

For those who have posted informative and inquisitive comments, I thank you and appreciate the fact that you do so. For those who want to do so, but aren't sure how I promise, I'm a rather wordy fellow who is happy to answer questions and do not mind sharing links of a genuinely informative nature. Let's make this a place where we can communicate ideas and not a jumble of SPAM comments that I have to consistently prune.

Aedificamus: Everything Works, Until it Doesn't

I started this little all consuming project on August 14, 2015. At the time, I weighed 263 pounds (yes, posts earlier stated I weighed 260, but the scale I was using at first and the one I use now have a three pound discrepancy. To be consistent, since I'm using the Health-O-Meter LoseIt Scale, I adjusted to keep the numbers consistent). I embarked on an approach that I tinkered with over several months, and for quite some time, felt I had come up with a winning formula. My results certainly seemed to confirm that line of thinking. I did offer a caveat that, what works at one point may stop working or be less effective later on.

That's the reality I'm dealing with today.

First, let's look at the numbers:

My LoseIt graph of bodyweight, current as of May 19, 2016.

Yep, things have been interesting the past few months. In some ways, I feel like I am more active than ever. I'm focused on the food I prepare. I'm getting ready for what will likely be a challenging but fun two week long backpacking trip. I should have had this in the bag a long time ago, and yet...

Not only has progress slowed, at certain points it has stopped completely and reversed. Ups and downs and fluctuations day to day are to be expected, but this is different. Using a moving average, when all is said and done, I have been virtually parked at around 193 for three months. I got down to 190 for a day, and then later I reached 188 for a few days, but then rocketed back to around 194. I blamed it on a weekend at a scouting activity where my prime responsibility was cooking (and yes, cooking the fun stuff :) ). I also bring my culinary skills to a variety of pirate festivals (in addition to being a living history docent, I also act with the Quartermaster crew as galley cook, which, let's face it, is fun). Still, I've been keeping track of my calories, I've been diligent about syncing my Fitbit with my apps, and sure, there are some days I don't make target, but the high majority of the time, I do. 

So what gives?

Data is interesting. If you focus on just one thing, it can tell you something specific, but it may not tell you the whole story. The image above deals with weight by itself. The following image, which is a graph of my Body Mass Index (BMI) adds another dimension:

My LoseIt graph of BMI, current as of May 19, 2016

I'll be the first to tell you that BMI is a flawed measure. No two people are exactly alike, and I have some unique morphology that messes with the very premise of BMI. I have a classic Viking build. I often joke that my scant Danish heritage is really only represented in my name, as I am basically 1/8 Danish, with a full half of my heritage Italian and Spanish/Mexican, and the rest a mixture in various parts of English, Irish and Welsh. For those who are fans of history, you probably already jumped to the point where you would say "yeah, but there's lots of Danish/Scandinavian in that mix of English, Irish and Welsh... that's who the Saxon's were", and you'd be right. Long story short, classic Viking morphology defines my body. I have broad shoulders. I have a long torso. I have a long neck. Most important, I have stubby legs. I'm 6 feet, 2 inches, but I have a 31" inseam. A typical height for that inseam length is about 5 feet 10 inches, so four inches of my cross section are coming out of my torso. There' a lot more mass in the torso than in the legs, all things considered. My point being, just getting to a green zone BMI may or may not be a proper target, but since hospitals and the insurance industry use it, and pretty heavily, for making health related decisions (and assigning risk factors), I abide by it. I hit 24.9 BMI (the highest I can be and still be in the green zone) on February 27, 2016. The green line in the graph represents that 24.9 goal. 

Do you notice anything interesting? Yes, there are dips, even some significant ones, and there are setbacks (yep, a significant pair of them as you can see), but overall, when averaged out, I'm holding altitude at that 24.9 spot. This is, I assure you, not intentional. I really want to hit that 185 target I made for myself, but my body has been fighting me tooth and nail... or has it?

What's different between now and what I was doing in the Autumn of 2015 and the Winter of 2016? 

One interesting variable change is the addition of the FitBit into the equation. It's a really neat tool in that it tells me my caloric burn for each day, and it tracks steps for me. However, I have noticed something interesting. Back when I was using my phone as my pedometer, it seemed to take me an hour and forty minutes of cumulative walking to get to 10,000 steps. I stopped keeping track time wise or distance wise, but I've had the nagging suspicion that my FitBit may be a little too generous with my step count. It certainly seems I hit that value much sooner. It's also possible that my phone registers the distance differently, and since I started wearing the FitBit, I don't carry my phone with me everywhere all the time, so I can't compare the two values in a meaningful way. 

Additionally, I've been training for a two week backpacking trek, with conditioning hikes covering five to seven miles, with elevation climbs of about 1,000 feet up and down, with a 45 pound backpack. Seems I should be losing weight left and right with that kind of regimen, except... now that I'm doing these long hikes, I have had mornings where my typical physical training sessions, be they yoga or strength training stuff, have diminished. Also, I've been producing a podcast that takes up a fair amount of editing time, so a lot of my previous exercise focus has been shifted. In short, while I want to say I'm doing the same thing I was doing before, the truth is, I'm not. I've changed the load, both physically and cognitively. I may not be getting all of the exercise and calorie burn I think I am getting.

Yeah, but my food regimen has been rock solid, right? 

Well... I can go back and see a whole bunch of things that, if I were to be 100% objective, I thumb ruled and used experience to provide numbers. Did I include the pat of butter that went in to lubricate the pan? How about the salt used in the blanching process? Did I really know the make-up of that rice noodle I used? When I eat out at a Mexican place and get ceviche, do I really know the caloric breakdown of what I have eaten? Have I truly been making my own meals, or have I slowly worked in social lunches at the office to help balance things? Sure, I hit my fruits and vegetable quota religiously, and have for months, but there's a lot in the mix I am probably not accounting for, or I am willfully ignoring. In short, I may be eating more than I am giving myself credit for. Mix that with a changed workout regimen, a possibly overgenerous accounting of my thermal output, and a very real underreporting of my caloric intake, and I think it's very possible that my lack of progress is my own darn fault. 

Additionally, it's also entirely possible that I've biased myself by having hit the BMI target. It's not the weight goal, but it's put me in the green zone for healthy weight, and perhaps my sub-conscious is saying "OK, body, that's enough, we need to overrule this darn fool, by whatever means necessary."

There's one final detail I think may be important, and that's time. Time using a caloric budget. Time planning workouts. Time going out of my way to train. Time avoiding certain foods or food combinations. Time researching alternatives to help me lower sodium or excess sugar. All of this adds up, and results in "Weight Loss Fatigue". Yep, I'll admit it, some days, I just want to say "the hell with all of this!" It manifests itself some times in my going days without weighing myself. I'd been an advocate of daily weighing and found the daily fluctuations to be a wonderful source of daily angst, so I cut them back to once a week. Problem is with once a week, I'm not getting that daily feedback or getting the motivation to course correct. Holding ground isn't so bad, but it also makes me a little complacent. Having a spike in weight makes me less want to weigh daily. Therefore, even though the daily weigh-in irritates me, it really does give me daily input that I can act on, so I'm going back to it, or as daily as I can realistically do.

It's easy to lament a lack of progress and think "oh, things have just gotten so much harder, I'm doing the same thing and not getting results any longer". It's possible that could be the case; the body is highly adaptable, and I could be developing muscle from all my exertions, but with a reduced calorie load, I'm highly dubious. No, I think the real facts are that I'm not doing the same thing. I've drifted off my course and routine. I'm not as diligent as I was. I'm using the tools to provide a false sense of accomplishment. I'm getting a dose of dopamine each time I meet a goal and see the bar and icons turn green. That in and of itself is its own reward, and it distracts from my ultimate goal. To that effect, it's back to some of my tried and true methods. An hour and forty minutes daily walking time, measured some other way than just letting my FitBit tell me. It's time to get back into those FitStar workouts that I've let become less frequent. It's time to say "no, thank you" to team lunches, or at least go less frequently, and take my cooking and food preparation back. Mostly, I need to really take the time to think about what I ingest (and more importantly, digest), and realize that there may be lots of hidden stuff I'm not accounting for, but I better figure out how.

So there it is, nine months in, almost seventy pounds down, but those last eight pounds are proving to be frustratingly difficult to say goodbye to. Whatever the reason, what I relied on before isn't working the same way, so it's time to pivot. Check back in a couple of months and we'll see how well I do with that ;).

AST Re-Election: Do I Deserve Your Vote?

This is going to be very much a niche post. For many, this won't make a lot of sense. For others, it will make a great deal of sense, and it's all of you that it will make sense to that I am hoping will read and consider this post.

Members of the Association for Software Testing, CAST 2013 will be starting just under two weeks from today. I will be there. I will be speaking, helping out where I can, and, I hope, acting as a positive representative of this organization.

This year also marks the end of my inaugural term as a member of the Board of Directors. I am up for re-election. I have considered why I should run for the Board again, and why I should ask each and every one of you to give me your support and your vote.

Short version:

I am running once again, and I am asking for your vote of support for a second term.

Longer Version:

I have enjoyed interacting with all of you over the past two years. I've served in the role of being the "BBST Headmaster",  keeping track of the books for the organization as the Association's Treasurer, and working as the Chair of the Education Special Interest Group, most notably with the group of dedicated individuals who have helped compile and curate the materials that are developing to be the basis of educational modules for SummerQAmp.

I'll be blunt. I'm not an academic. I'm not a consultant. I'm a software tester. A practitioner. I'm an everyday, regular person who works for a regular company. I'm also one who wants to see our profession, craft, discipline, "call it what you will" grow, develop and flourish.

I enjoy being actively involved in those efforts, and being part of the Board of Directors allows me the opportunity to try and see these initiatives, and others, be pushed forward. There are long time projects that need updating, and delivery options that we may want to consider, as an organization, to enhance or replace what we currently use. Frankly, I think I'm just crazy enough to take a number of these on and make them happen.

As a practitioner, I'm also a bit of a cynic (it comes with the territory of being a software tester). I know some of you are thinking... "OK, so what's in it for you?" That's a totally fair question. The fact is, I get opportunities to learn about software testing education in avenues I would not were I not part of this Board. I get the chance to help see grant opportunities develop for international testing conferences, and help see them get funded. I get a lot of satisfaction out of knowing that we as an organization are making a difference around the world, spreading a message of "sapient testing" that breaks free of old methods and default "factory paradigms" that, frankly, don't make sense in an ever adapting digital world.

Yes, I want to see those opportunities continue. I want to champion excellent software testing. I want to get involved with more initiatives that will help make software testing education more available, better performing, more engaging, and yes, dare I say it... FUN! There are many avenues where that could happen,  but I like the mission and purpose of the Association for Software Testing, and everyone involved in it as members. I could approach these opportunities in a number of places, but I'd rather approach it here, with all of you.

Really, that's all I have to say. The final vote is yours. I have enjoyed very much these past two years working with you, and on your behalf. I'd like to ask you for two more years... membership willing :).

Aedificamus: The Power of Precrastination

Heh, I see what you're doing there. You're thinking "Oh, Michael, you are so lame. Mis-spelling your main idea in the title. Seriously? Didn't someone proof read this first?"

OK, I'd not be offended if some of you actually have thought that, especially those who have read my "Live Blog" posts before cleanup. This time, though, I'm actually not mis-spelling. Misappropriating, maybe, but I know exactly what I mean when I say "pre-crastination". It's the polar opposite of "procrastination". If procrastination is the virtue (or folly) of waiting until the last minute, then precrastination is the folly (or virtue) of front-loading and doing what you can before your lizard brain can talk you out of it.

In short, instead of the power of "later", you harness the power of "now" to not be the slave to "later".

Today was a good day, in a number of ways. First, I sighed with relief when I saw that my daughter's plane from Japan landed at Seattle-Tacoma International Airport today without incident. Hurrah! My daughter is back in the U.S.A. I will have to wait until tomorrow morning to hear more about her trip, because she will be held over in Seattle until early tomorrow morning, when she can catch a return flight back to SFO. Today was also a good day in that, right about as Karina was touching down at SEA-TAC, I was getting the staples removed from my leg surgery. With this, plus an X-ray and a consult with the Orthopedic surgeon, I've been given a (relatively) clean bill of health, all things considered, and my "graduation papers" from severe injury rehab.

I asked the doctor what was next and he said "physical therapy". OK, cool, for how long?

"Well, considering the extent of your injury... probably the rest of your life. That is, if you want to bring back and keep full range of motion and operation to that leg."

Wow! OK! Well, when should I start?

"As soon as you get home. Start today. Start now. It doesn't have to be elaborate or aggressive, just do something to get moving, but do it today. Your first legitimate 'break', commit to doing whatever you decide to do. Start a journal and plug it in. Doesn't matter what it is, but do it, own it, and follow up on it."

Thus, I got home, caught up on work, set a time for lunch, changed into running gear, stepped out of the house, turned on the iTouch for a little Daft Punk, set the stopwatch... and I ran.

Let me re-emphasize that... I walked out of the house and RAN!

It wasn't elegant.
It wasn't fast.
It was one mile.
The distance of the housing tract I live in by its perimeter streets door to door of my house.
I played "One More Time", "Aerodynamc" and "Digital Love" from start to finish.
That's a cagey way of saying it took me exactly thirteen minutes.
To run a mile.

Yeah, that's pretty embarrassing, but let me emphasize a point one more time... I RAN!!!
You know, running. Something I thought I would never really be able to do again. I thought my bones, my nerves, my muscles, something was causing me to stagger if I got much above a slow jog. Today, I received a firm and concrete answer as to what the problem was. Actually, I received a stainless steel answer. It was my hardware. It was the inflexibility of the stainless steel that caused me to stagger. Removing that steel brought the natural spring back to my bones. I managed a halfway decent running pace, about a level 4 on a stationary treadmill, or the equivalent of an Allegro at the start and a Moderato towards the end (maybe 135 BPM - 110 BPM pace wise).

That's not going to set the world on fire. For some, that's considered embarrassingly slow. For me, it's the start of something I never imagined I'd be able to do again. But I can... and I did... and I did it before I could talk myself out of it!

Not a bad start... now let's see if I can do better on it tomorrow morning. Bright and early, so I have to do it before I can pick up my daughter.

This "precrastination" thing... there just might be something to it. It goes against my nature, but as Roland Orzabel so eloquently put it... "nothing ever changes, unless there's some pain".

TESTHEAD REDUX: Testing Training? What's That?

Wow, what a difference two and a half years makes!

When I first started my blog, this was one of my first entries (entry number 5, to be exact). It was my first firing salvo, aimed at my frustration as to the value of the testing training I had seen to date, most of which, even then, I was not really thrilled with. I should also note that this is the first entry that received a comment... and it was from Matt Heusser! Interesting to think that this would be my first "formal" meeting of Matt, and what has transpired in the 30 months since would be, well, amazing to discuss... but that's another story (possibly a book's worth of material, to tell the truth).

Having said all that, my point was, I felt it was time to come back and see what I said and what I believe today, now that I'm older and, supposedly, wiser... or more jaded and cynical. Sometimes the two can be hard to tell apart ;).

To be fair, the above statement isn’t as common as it used to be. There are now many options regarding testing training and how to get it. However, up until just a few years ago, being a tester and getting actual training related to testing was not an easy endeavor. Training for programming? Yes. Training for systems administration? Definitely. Training for engineering principles? Just look at MIT or Caltech or any number of engineering schools. Still, you would have been hard pressed to find a school that had an actual course of study related to software testing (and for that matter, just finding a single course was not a wide spread available option).

Today's reality is that there are two types of testing training that exist, and they can vary in value. There is what I call "vocabulary training", where the goal is to cover a lot of ground at a fairly theoretical level, and then take an exam or series of exams to show how well you know the material. The other is what I call "experiential training", where you actually get your hands dirty and test, try things out, talk about your experiences, and have others review your progress. I currently help run and facilitate two versions of this today.

The first and most formal version is the Association for Software Testing's Black Box Software Testing classes. These combine both the theoretical and the experiential aspects, and they allow testers the chance to test their understanding and challenge other participants understanding. So whereas, before, I would say there's nothing out there, today I would say that is absolutely not true.

The second source of "experiential learning" that I am involved with is Weekend Testing, and these events are almost exclusively experiential, done with a Skype connection and a group of willing and active participants. There are chapters around the world, but the India and Americas chapters seem to be the most active at this immediate point in time. Experience level varies dramatically, peer testing is an attribute, and each session is different from the one before. There's no need to feel "I don't know enough to participate." We treat it as a safe environment for everyone to come in, learn, practice their craft, and make connections and share ideas. It's also a lot of fun.

Show of hands, how many testers had any genuinely formal training in how to do their job short of perhaps a quick orientation from a test team lead or test manager? How many people actually participated in training beyond this introductory level? If my experience is indicative of the majority of testers, I’m willing to bet that number is probably very low.  

Today, while there are many who have sought out formal training, the vast majority of testers that I talk to still have this issue. Things are changing, in that I think the Meet-up culture is starting to encourage people to get out and talk about these things and offer alternatives to official training activities.

Testing Blogs: If you look to the side of these posts, you will notice that I have a roll of a number of test blogs. There are hundreds, but these are the ones I keep returning to again and again. I return to them because they challenge the way that I think about things, or they provide me with solid information and ideas to explore. There are hundreds more out there, and to be totally honest, I’d love to have TESTHEAD fill that role for people as well (it’s going to take awhile to develop the credibility so that it will be worth that to someone, but hey, I aim to try :) ).

This has become my number one source for information. several sites do aggregation of just tester's blogs, so those sites are my first stop if I am really interested in seeing what testers have to say and what ideas are being discussed. What's interesting to see if who has changed in my blog roll since I started this. That's to be expected; bloggers come and go based on their energy levels and what they are involved in. What is cool is to see how many are still there two and a half years later that were on my original list :).

Testing Magazines and Communities: There are several magazines and groups that publish information that is readily available to everyone, and while they still require a subscription fee to get everything they offer, the amount of information they offer to the general public for free is substantial. Some of my personal favorites are Software Test and Performance magazine and their online collaboration site and Better Software magazine and the folks at Sticky Minds.

Still mostly true, but I have to add two more well deserving groups. The first is the Association for Software Testing (AST). I didn't even know they existed when I first started my blog, but I've certainly gotten to know a lot more about them since then! Helping deliver, maintain and develop their educational offerings has been an eye opening experience, and it has helped me interact with a bunch of terrific people, many of whom have become good friends since. The second is the Software Testing Club and "The Testing Planet". This loose knit confederation of testers has some great discussions, and I always look forward to when the next issue of TTP is available.

Webinars and Online Training Sessions: both STP and Better Software listed above host a series of webinars that cover different areas of software testing on a regular basis. Most of the sessions are free and are open to the public, and many of the sessions are “tool agnostic”, meaning that they talk about principles and practices that can be used with any of the common test tools, or applied to home grown solutions. 

Since this was written, I've discovered lots of areas where we can get more information and see live screencasts and pre-recorded webinars of topics useful to testers. Add to that the phenomenon of entire courses of study being made available online. Think of Coursera, Khan Academy, and other initiatives that have become well known that are making it possible for anyone willing to invest the time and energy to learn about any topic. I've also found myself branching into more software development discussions and groups, even though my primary focus is not programming. Codecademy and NetTuts+ are two great sites for this type of interaction.

Books: These were the titles that made my short list two and a half years ago:

• “Testing Computer Software” by Kaner, Falk and Nguyen
• “Effective Methods of Software Testing” by William Perry
• “Linchpin” by Seth Godin 
• “Secrets of a Buccaneer Scholar” by James Bach
• “Software Testing: Fundamental Principles and Essential Knowledge” by James McCaffrey
• “Software Test Automation” by Mark Fewster and Dorothy Graham
• “Surviving the Top Ten Challenges of Software Testing” by William Perry and Randy Rice

What titles do I consider essential today? While many of these are still valid, I've found that I'm turning to different resources now. "Testing Computer Software" has been replaced by "Lessons Learned in Software Testing" (Kaner, Bach & Pettichord) as my backbone "go to" testing book. In addition, Gerald Weinberg's "Perfect Software and Other Illusions About Testing" has become a perennial favorite. I will still recommend "Linchpin" and "Secrets of a Buccaneer Scholar", and add "Explore It" by Elisabeth Hendrickson.

Interestingly, the books that have helped my testing the most have been, shall we say, not testing books at all, but rather, those that focus on philosophy and inquiry, and help us see things in a different way, or at least understand how we have come to see different things over time. I'll also give a plug for my favorite "book discovery" of them all, in that it's not really a book, but a companion volume to a television series; "The Day the Universe Changed" by James Burke.

Wikipedia’s Software Testing Portal: [...] The Wikipedia software testing portal is an example of where this vast resource of people and small contributions comes together to make for a very large repository of information related to testing. Note: a phrase I famously use among friends and colleagues is “Caveat Lektor Wiki”, and this is no exception. Using Wikipedia as a sole resource for anything is never a good idea, but to get started and develop some basic ideas and understanding, it’s a great tool, and again, will provide many jumping off points if you wish to explore them.

Having had a chance to see many discussions about the content and the accuracy of the information, I will now say that "Caveat Lektor Wiki" still applies, but yes, much of the information would stand to being an introduction to ideas that testers may not be as familiar with. Having said that, I also think that we as a community have the responsibility to review the information, and if we see it is in error, challenge it or add our own voices to explain why. It's our collection of experiences that makes that repository, so if you find something is in error or is badly worded, do your part to help make the explanations better (said with a healthy dose of 'Physician, heal thyself!", I might add).

Just like two years ago, I still agree that knowledge begets knowledge, training begets training, and opportunity begets opportunity. Also, as Matt mentioned in the comment to my original post, if you can't get to an official training opportunity, band together with other testers in your area and make your own. Hold a local peer conference for a day, have a writing workshop on testing ideas, host your own local bug party. Whatever it takes, there's rich ore to be mined out there, it just requires that we pick up a shovel and dig.

A Dude's Thoughts for Testing Education

Yesterday I posted an entry for the Association for Software Testing blog. It was also forwarded to the rest of the membership via their newsletter. In it, I made clear the fact that I will be taking over as the chair of the Education Special Interest Group (EdSIG) on March 31, 2012. But that wasn't all. I also stated that I had another "bold boast" up my sleeve, potentially my boldest boast yet.

I stated that, while I both admired the work and value of the content that is available through the Black Box Software Testing (BBST) courses, and I personally found them to be very valuable, there are many members of AST who will never take the classes. The reasons are varied but they often come down to one thing. BBST's three classes, as designed, is the equivalent of a university semester course on software testing. You get a lot of one on one time with instructors and assistants, we provide feedback and direct grading, we coach people directly. For those willing to commit to it, it is immensely beneficial, but there's no question about it, you are being asked to set aside a significant amount of time to do it.

For the people that will take the classes, there's little that needs to be done to convince them to do so. For those that will not take them, there's little that we can do to convince them to do so. With this in mind, I'd like to try something different.

I've seen these examples in things like NetTuts+ and Zed Shaw's and Rob Sobers' "Learn Ruby the Hard Way". These are specific, targeted, longer examples of learning, ways to get into the muck and do stuff, directly, with a dose of humor, and a lot of practical focus. There are many topics in testing that are just causally touched upon, because going into them in depth would be a huge undertaking. Describing context-driven testing principles alone has so many possible variations. Is it any wonder that we often reach for the overtired phrase "it depends"? It's 100% true, it's totally accurate, and most of the time, it's completely unhelpful. Wouldn't it be much more beneficial to gather a number of examples and actually show the differences? We often speak of polar opposites like a MMO video game and a pacemaker, and set these up as our examples of why context matters. I do not disagree, but specifically, what do they do that is different? What do they do that is similar? Why do they make the decisions they do? How can we encapsulate that in a meaningful way for testers to see, experience and consider?

It's with this that I want to look at the areas I'm already familiar with and expand the conversation to them. I'd like to see AST podcasts, screen-casts and video-casts taking on these areas. What's more, I'd like to see more voices included in the discussions. Cem has devoted literally thousands of hours over the years to recording the lectures he uses for BBST. It's been a monumental work on his part and  I have no intention to redo or replace them. I also know that I personally don't have the time all on my own to do new video entirely. What I'd like to see is video conversations and examples explained by people in various industries. We hear all the time about the differences between finance, web, medical, government and academia, and many others. There are testers in all of those spheres. Who would you rather hear talk about their testing challenges and triumphs. Me? Or them? I'd much rather hear from them, from YOU, and I hope to find ways to include YOU in on the conversations and developments we make.

All this is my possibly over zealous and San Juan Hill charging way (or it might be a Little Big Horn charging way, time will tell) of saying "this dude is looking to make some new ways to look at testing education". I am not going to be able to do it alone. Are you willing to help me by lending your voice, your experience and your successes with me, so that we can help teach others and give US the tools to do more and be more? If so, Dudes and Dudettes, leave me a reply and lets get rockin'!!!

Chain... Keeps Goals Together

We're homing in on the end of the year, and many are abuzz with the "New Years Resolution" virus. For those curious, I never make New Year's Resolutions. Well, OK, I used to make them when I was younger, but I gave up when I realized that I was more times than not just setting myself up for failure. I realized something several years ago. Resolutions are weak willed things, and they are easy to break. Specific goals, with detailed and measurable progress points, are much more likely to lead to success.


Unlike resolutions, I believe wholeheartedly in setting regular goals, and I believe in setting small ones. Things I can work on for a given day, week, month, etc. Big, life-changing goals are good, and occasionally, there is a specific incentive to take on one of those big massive goals, but most of the time, the human constitution just can't wrap its head around a massive life-altering change. At least not in big extended chunks. Let's take an example of losing weight. It's a popular New Year's Resolution topic.

• "I'm going to lose 50 pounds!"
• "I'm going to work out every day!"
• "I'm going to give up all processed foods!"

These are classic weight related resolutions, and more times than not, they are scrapped in a rapid order, often within two weeks. Why? Because they give an impression of being specific, but they aren't. They are very nebulous, with the exception of the "losing 50 pounds". Could be a great goal, but how will you go about doing it? How long will you allow yourself? and what will you do once you get there? The truth is, most long term goals are notoriously unfinished, because we don't really give ourselves realistic parameters.


I'm much more a fan of making very specific small and short term goals, and along with the goals, charting my progress with "chains". I love chains! It's an idea I got from an old Lifehacker piece called "Jerry Seinfeld's Productivity Secret". In a  nutshell, the idea is to take a goal, and when you do something related to that goal, mark it on a wall calendar that displays a full year. Each day you do something towards your goal, write down a mark with a red pen, and after doing it multiple days, make a chain. From there, don't break the chain.


What's great about this advice is that is emphasizes consistency and regular practice of whatever it is you are doing. Jerry Seinfeld used this to meet a writing goal. The same could be used for reading, for exercise, for cessation of a bad habit, or practicing a musical instrument. Whatever the goal, start a  chain and make small links to keep building the chain.


Having said all this, you may be wondering what some of my "chains" are. Glad you asked. Some of them I have kept in a focused manner and have some long ones. Some others are collections of short chains interrupted here and there. The col thing is that, if you can create a lot of little chains, even if they are separated by a day here and there, you will still have a hefty chunk of chains to look back on, and likely a lot of accomplished goals to go with them. Learn Ruby the Hard Way is a chain. Any BOOK CLUB synopsis I do is a chain. My 10 a day SET practice is a chain (I use it as a drill to see how quickly I can recognize patterns and if I am getting faster at seeing them). So what are my "goals" that I want to focus on in 2012? Here's a basic list.

* Complete Learn Ruby the Hard Way synopsis and then move on to other Hard Way projects.
* Commit to a once-per-month, 1st Saturday unless impossible to attend Weekend Testing Americas Schedule.
* Get back into the swing of doing a book review each week.
* Work through my stack of Ruby and Rails books, and create more Practicum entries
* Curate and mark-up TESTHEAD, so that topics that are related link posts.
* Go through and do editorial on TESTHEAD, correcting spelling mistakes and grammatical faux pas' (I already know there's an embarrassing amount of them).
* Focus more on topics specific to advances in coding and automation.
* Declutter and dejunk my home and work area.
* Focus on opportunities to develop presentation of testing experience and ideas; create a back log of talk and seminar material.

That's plenty to keep me busy this year, and there's enough variety in there to keep me busy for, well, many years going forward. Tackling them all simultaneously and with 100% focus would be impractical and likely to fail. But doing one or two at a time, and chaining the small bits I can do each day, as well as staggering the ones I do at a given time, will help me approach many of these goals. A small step each day on the ones I want to see move forward will help me keep moving. If I get bogged down on one, I have many more to jump off to. Yes, SMART goals are good, and yes, being realistic in expectations is also good. Above all of these, though, is the commitment to a little bit each day where you can, and when and where possible, do not break the chain :).

Ruby For Newbies?

In my never ending quest to find ways to better understand the things that I do, I like to find new approaches and different formats to help me appreciate what I'm learning. For many people out there, a book with examples is great. For others, a website tutorial works well. For others, videos or screen casts are able to scratch that particular itch the best. Me? I tend to like them all, because each has their strengths and limitations, and each scratches my brain a little bit differently.

So today's find, Ruby for Newbies, is brought to us by the folks over at Tuts+, an interesting source of a lot of tutorial content, screencasts and podcasts related to various technologies and areas of interest. The y have a listing of all their but the one's that fit my purposes today are a 13 part series dedicated to Ruby, which can be read as tutorials or watched as screen casts. The beauty of a screen cast is that you can rewind and watch as many times as you want. The series starts at the very beginning with installing Ruby on either Windows or a Mac, and then walks through several screen casts (each about a half hour long) to discuss various topics in Ruby and how to work with them. Note, there is a Premium service offered by Tuts+, but if you don't want to make that commitment, that's OK, Tuts+ offers a lot of content 100% free, including each of these screencasts (the source code can be downloaded by Premium members, so if that's a big deal to you, well, consider it :) ).

The Ruby for Newbies tutorials are written and presented by Andrew Burgess (@andrew8088 on Twitter, happy to give him a plug here :) ) and provide good information directly at the level to help you understand the concepts. There's only so much that can be covered in 30 minutes, of course, so there's certainly limitations to the format. The ideas are covered in a rudimentary way, you will of course need to do considerably more playing around with it if you would like to get more in depth and understand the details better. The tutorial that follows also provides concise details and the specifics of what the screencast covers.

Screen casts that I have personally found immediate value in were Ruby for Newbies: Testing Web Apps with Capybara and Cucumber and Ruby For Newbies: Testing with RSpec. I'm curious to see what more I can learn by looking over the earlier entries in the series. You may enjoy them as well, so if you are so inclined, give Ruby for Newbies a look.

Weekend Testing Americas: Developing Effective Charters with James Bach

This Saturday, Weekend Testing Americas is having a special guest. During last week's session, I had James Bach and Michael Bolton both attend and participate with the group (talk about feeling like a T.A. and then having the professors walk in (LOL!).

Actually, I'm glad they did, because they helped me realize something I've been struggling with for some time. It'[s one thing to make a test charter or a test mission, but how can we make them more effective? More to the point, how can we craft them so that they are appropriate for the testing session at that time?

To help explain this, imagine you have a group of people you are going to send out to test something. They have one hour. they have to maximize that time, and therefore they need to be able to hit the ground running as fast as humanly possible. Can you adequately describe what needs to be done so that everyone in the group can do that? What if we had a whole group of testers specifically trained to be able to do that, not just for Weekend Testing sessions, but all the time?

This is the skill that James Bach will be working with us to develop and improve this Saturday. Normally, I would be cautious to not over-hype or over-promote these sessions because we might be overrun, but in this case, I think it will prove worth it, so I'm breaking my "limited distribution" promotion (Twitter and direct email) to talk about and announce this session.

So do you want in? If so here's what you need to know and what you've gotta' do:

Date: Saturday, August 27, 2011
Time: 11:00 a.m. - 1:00 p.m. PDT (2:00 p.m. - 4:00 p.m. EDT)

To join the session:


1. Please send an email message to wtamericas@gmail.com with the subject line "WTA18" and a confirmation that you would like to attend the session.


2. Please add "weekendtestersamericas" to your Skype ID list if you have not already done so. Please ask us to add you to our contact list.

3. On Saturday, August 27th, approx. 20 minutes before the start of the session, I will set up the group. If you ping me on Skype at that time, I will add you to the session. If you have replied via email and stated that you will be attending the session, if you are online at that time, I will automatically add you.

Remember, these sessions are "chat" only, no call in is necessary, but you have to be on Skype to participate.

Look forward to seeing you there :).

Selling the Story and Combating Apathy: TESTHEAD Branches Out!

This is exciting. Two different articles, on two different sites, within two days.  How cool is that :)?!

First, I want to give thanks to the folks over at Software Quality Connection for running my story about "Selling the Test Automation Story". This was a step out of my comfort zone, but I'm glad I wrote it. Too often, I think we get frustrated that we can't be as effective as we want to be, that we think things will just come to us and we will just naturally be effective. Automation is one of my biggest bugaboos; it doesn't come to me naturally, and it doesn't match my normal way of thinking. Still, if I only wrote about my successes, this blog would have a lot fewer entries in it... a LOT fewer entries (LOL!). The simple truth is, I learn more from my shortcomings and challenges than I ever do from my easy successes, so thank goodness for small blessings. It's not that we fail, but that we get up and try again after we fail that's important. Anyway, I'd appreciate it if you could go check out the article and then tell your friends about it :).

Second, The Testing Planet #5 is out today, and I am tickled pink to discover that my story on "Combating Tester Apathy" made the front page :). As of right now, the Testing planet is available as an actual print newspaper, and can be downloaded through Amazon, via Kindle or E-Reader format, or you can buy the first run PDF version. Later this month, the free PDF will be made available to one and all. This story owes a lot to Larry Winget, a guy I'm sure that regular readers see pop into my writing from time to time :). In fact, it was his book "That Makes Me Sick" that prompted me to apply the techniques to testing and to testers in general, starting with me. After writing the article, I realized that there was one other great danger that needs to be addressed, but wasn't included in the original article. I'm hoping to expand on it and maybe make another presentation for Issue #6 (hint; the three danger signs I originally talk about are stupidity (I rephrased it as "ignorance"), laziness and apathy. The fourth, I firmly believe, is distraction. I'll be expanding on that idea, be sure about it... as soon as I finish up everything else I need to (LOL!) ).

Again, my thanks to everyone over this past year and a half who have made TESTHEAD a regular reading stop. I was quite surprised to see how many page hits and reads there were when I was away at Scout Camp. Though not a huge number, for a niche subject matter like software testing, it was amazing to see how many people took the time to come and read my blog during the ten days I was nowhere near a computer. I really appreciate the word of mouth and people who have linked to my site, included me in their blog roll, and otherwise help me spread the word about TESTHEAD. You are the reason I'm getting the opportunity to write in other venues, and hopefully spread my message of continuous learning, overcoming obstacles, and hopefully not taking ourselves too seriously. I really am grateful!

From Yeomen To Archers: Weekend Testing Plus?

A couple of months ago, Albert Gareev and I were discussing an idea relative to the way that Weekend Testing is constructed. In part, we have focused most of our efforts on one-off sessions, where the product does not repeat, and the testing goal doesn't repeat. It's self contained, people can come in when they want to, participate when they want to, and then go about their business. For most of the sessions, this is a perfectly logical model and it works well in most situations.


There comes a time, though, when the testing challenges or testing ideas need more time, or need multiple sessions to get a real handle on and have real discussions and practice with. Testing a website for an hour is one thing. Working on and practicing with a testing framework, or going through an extended level of testing RESTful services in a rich data web site, is a very different undertaking. The question we had was, how could we focus on testing that would fulfill both goals. Did it make sense to develop a second set of longer engagement Weekend Testing sessions?


Albert gave me a comparison to consider using Ancient Greece as an example (he knows I'm a total geek for history, so this metaphor worked for me :) ). The greatest body of Greek Hoplite troops, or for that matter English or French troops in the middle ages, were yeoman farmers. Another group that was developed were the Archers. Unlike the group of yeomen, the archers were expected to drill together and perfect their craft, often for years. It was with this comparison that Albert and I considered... what if we likewise were to develop some more open ended, more advanced test training ideas? Perhaps longer projects, related to one application with a greater level of engagement, possibly with the idea of making a squad of testers who worked on computer aided or automated testing, or in addition to finding bugs, worked and focused on fixing bugs where appropriate?

The first biggest challenge, of course, is that this would need to be a group of people that would meet regularly, and for longer than the two hour block normally set up for Weekend Testing. It might require an invite list, or some other self-selecting mechanism where team members would "sign on" for a project and commit to a particular period of time (Weeks?  Months?). The idea would be that there would be a deeper and more involved commitment for a group, and that that group would actively mentor each other even more actively than we do in the current Weekend Testing structure.

So here's the question  (and I welcome any feedback, positive or negative, on this idea)... Is there interest in pursuing such an approach, and if so, what would you as a tester like to see such a group cover?

Foundations is Over, and the Class Survived :)!!!

So last Saturday, I had the chance to bring to a close my first AST BBST Foundations class with me as the Lead Instructor. This was a cool experience in the sense that, while I've been part of this class for five iterations, this was the first time where I was setting the pace and the expectations.

It's a strange feeling. On one hand, after five times through Foundations, I figured this would be easy to do, but the truth is, there's a lot to keep track of and try to keep everything on track. For those who've taken the class, this may seem obvious, but for those who haven't, this is not an easy class. There's a lot to learn, to accomplish, and to encourage other students to work together over a surprisingly short period of time. It's a month long, but that month flies by very fast.

Each class is different, in the sense that each group of participants brings their own experiences to the course, and as such, each sees things a little bit differently. Each class, it seems a different set of questions develop as people determine the answers for the questions in the class. Oftentimes, I feel inadequate to answer those questions. Not because I don't understand the questions, but because I understand the questions as they relate to me and my experiences. My breakthroughs are mine, and other people's breakthroughs are theirs and come in their own time. My frustration is that, try as hard as I might, I can't teach someone anything they themselves aren't ready or willing to learn.

I remember as a kid reading Guitar Player magazine. Back in 1980, when I was 12 years old, I read an interview with Lesie West (legendary blues rock guitar player in the 70's who went on to teach guitar in New York years later). Leslie said something that I have been thinking a lot about lately... he said "I can't teach you how to play guitar. I can show you how to play guitar, but that's it. I can teach you how to teach yourself!" I had that experience during this class.

Now, don't get me wrong, it's not like we had a bunch of people who were not already good at testing (yes, there were many different levels of experience, some long time practitioners balanced out by some junior testers, as always). What was clear, though, was that the class offers a framework for testing and understanding testing, and each person approached that framework a little bit differently. Were I to take the idea that I would teach them, then I would be teaching them my understanding of it. That's not the point, though, as the challenges I face are not the same ones they will face. The tools and the approaches are context driven, and understanding the context (I believe) is important.

I deal with a podcast each week, and literally each one I produce, I learn some new trick or method that helps make that one better than the week before (subjectively speaking, of course). After more than 40 podcasts, I find it interesting that I still learn some new trick each time I do it, often when I'm doing something I've done dozens of times. Why is that? Is it because I've suddenly become aware of something that was obvious before, or is it because I experimented with something, saw the results, and finally put 1+1+1+1+1 together? I think it's more of the latter, because we are learning at our rate, and often that rate will be different for different people, because they will focus on what is relevant to them over everything else. The other details are nice and interesting, but they will not be at the forefront of my mind if I'm not actually doing something with it beyond curiosity.

This is a long winded way for me to say that I've had a great time being the Lead Instructor for Foundations, and I'm happy that my participants enjoyed and learned through the experience. Whether it was because of me or in spite of me will remain to be seen (and is ultimately irrelevant, really). I think you all were awesome, and it was a pleasure and a privilege to lead your class. I hope to see you in future classes, and thanks for teaching me a lot more than I probably taught you :).

BBST Foundations (BBST_101E): Starts This Saturday

This Saturday, in addition to a session of Weekend Testing Americas, another session of the Association for Software Testing's Black Box Software Testing Foundations class will begin. It will be another four weeks of all volunteer effort, with a number of dedicated instructors helping to teach the class. It will be challenging, it will be fun, it will be a chance to learn even more than I already have from this great class, and this time I will probably learn more than all other times combined. Why you might ask? Because I'm going to be the Lead Instructor for this course!

I am excited and anxious about this turn of events. Excited because I want to see how well I can do in this environment, but anxious because I'm going to be the guy in the driver's seat this time. there's a lot that goes on behind the scenes for these classes to run smoothly, and a lot of the details associated with the class running smoothly are because the lead instructor makes sure to take care of many of those pieces. In previous classes, those responsibilities belonged to someone else. This time, they belong to ME!

However, I am not alone in this endeavor. I have two great assistants this time around (Mimi Mendenhall and Doug Hoffman). Mimi will be doing it for the first time, and Doug has been around since the courses were first offered, and could probably teach this class in his sleep (LOL!).

Registration is still open until Wednesday, 3/30/2011, so if you are interested in seeing if you can still get into the class, please follow the link to register and take part. If the class is over-booked, you can of course sign up for the next one. I may not be teaching that go-around, but it will still be a great class with whoever is teaching it. If, however, you can get in, I'll look forward to having you be a part of my class :).

Weekend Testing Americas #9 This Saturday

Hoping to make sure that more people know about the sessions are are alerted enough in advance to be able to participate in them. Our next session for Weekend Testing Americas will be held this coming Saturday, April 2nd, 2011.

While we keep the sessions somewhat close to the vest, we will say that the problem we are looking to work on this weekend will be somewhat unique, and that it will require some "hackerly" thinking to get the most out of it. We feel it should be rather "newsworthy" (and that's all the hints you are going to get ;) ).


In addition, I would also like to mention that Albert Gareev, who has put a lot of effort and attention into helping develop ideas and approaches for Weekend Testing sessions, has also agreed to take on the role of assistant facilitator for these events. this is what we call "redundancy" in the hardware world, but that doesn't really seem fair to Albert; he and I are to very different people with different strengths, and Albert will be able to bring plenty to this endeavor.

Another reason for this move is that we are considering shaking up the schedule a bit. For many people Weekend testing gigs work well on the weekends, but for many others, they are not able to participate due to family commitments and other things that pull at their time (what, you mean testers have lives, too?!). Because of this Albert and I have been mulling over the idea of having occasional WeekNIGHT Testing sessions for the Americas, sessions that would be easier to attend for folks in the Western Hemisphere. The challenge, though is to be able to schedule those sessions so that people can attend them conveniently (a 6:00 PM start time for the East Coast would be a 3:00 PM start time for the West Coast, a little challenging for some of us who would still be working. A 6:00 PM start time on the West Coast would be 9:00 PM on the East Coast, not ideal for a week night by any means. The solution? Alternate between the times, and have Albert facilitate the East Coast sessions and me facilitate the West Coast sessions.

In any event, the ability of having multiple facilitators makes it possible to have additional sessions, or vary the scheduling. we're going to be keeping track and seeing how well this approach works and who participates and responds, and that will help us tailor these sessions so that the Weekend Testing attendees will be able to get the most out of these sessions.