A World Without "Heroes"?

As is often the case, there is a two level thought process that goes into every one of my "Uncharted Waters" blog posts. The first is the thought and consideration that goes into the lead up to, the writing of and the making public of the post. The second is what happens usually within the first twenty-four to forty-eight hours after the post goes live, because I will get a comment or a thought from someone that will make me slap my head and say "Oh! Yes! That! That would have made sense to say!"

In my most recent Uncharted Waters entry "Heroes, Hubris and Nemesis", I decided to take on the "hero culture" that tends to exist in various companies, and the fact that, instead of them being shining examples of excellence, instead, those so called heroes are very likely the bottleneck to their team. I then spent the rest of the article giving advice about how to deal with all of that.

After the post went live, Michael Bolton posted a comment that was, quite frankly, the perfect follow on:

"Oh! Yes! That! That would have made sense to say!"


Here's where I think we really could make a difference. What if, instead of calling the person that does these things a hero, we used terminology like this instead? What if, for the people that hoard expertise, we called them out for doing exactly that? What if we made the perpetual online and self-flagellating martyr of the team out to be the problem rather than the savior of the organization? Would behavior change? I believe the answer is yes.

Alan Page and Brent Jenson talked about this in Episode 14 of "AB Testing" back in December. They likewise described a "hero" on their team and the way they did things. Brent described the challenge he had with a person that had no desire to teach others, because if others were taught, they wouldn't be special any longer. In addition, what was really happening was that, due to the existence of this particular hero on the team, management didn't have to invest the time or emotional energy in the rest of their team, because their hero was there to save the day.

What if, instead of extolling the hero, this team instead called out that behavior as anathema to their success? What if management had instead insisted that this person be given advancement based on how well and how frequently this person crossed trained the team, and made it clear that any opportunity for advancement would hinge on their ability to teach others and bring the whole team up to that person's level? What if, instead of praising the "hero" instincts, the management instead called out their opaque approach and unwillingness to share as fatal detriments? Do you think the entire culture of that team would have changed? I certainly do. One of two things would have happened. Either that person would have worked hard to train up the team, or that person would have left of their own accord because they would realize that their "heroics" were not going to be their differentiation. Either way, the team would have been better off, because the team as a whole would have to deal with the imbalance of skills. By relying on the hero, management was taking the lazy way out. They (management) didn't have to invest the time and energy in the rest of their team, the hero got to play the public martyr, and everyone was happy... at least until a crisis came where the hero couldn't step up.

My solution was to make a team of heroes, but perhaps the better way, the more appropriate way, is to try to remove the hero moniker from those who are not working to help the entire organization succeed. It would take a lot of guts, but I think the teams willing to do the latter will long term be better off than those who don't.

Do You Want to Move Testing Forward?

The Association for Software Testing (AST) is holding its tenth annual conference this year. The Conference for the Association for Software Testing (CAST) will be held in downtown Grand Rapids, Michigan on August 3-5, 2015. Ten years is a cause for celebration in my book, and we are throwing a party. I say "we" because I am part of the Board of Directors and the President of AST, and therefore this conference is a big part of what 2015 will be shaping up to be for me.

The theme of the conference this year is “Moving Testing Forward”, and to that effect, I want to reach out and encourage my fellow software testers, programmers, quality advocates, or whatever area you see yourself, to put in a proposal for this year’s conference.

My belief is that the best way to move testing forward is to do so with more voices, and CAST is well known for being the conference where new and unique voices are heard. Several great speakers have developed over the years, and CAST has been quoted as being where many of them first had the opportunity to present. We want to encourage that approach further, so I am sending out a personal call to those software testers who might still be on the fence.

- Maybe you are a relative newcomer.
- Maybe you have not spoken in front of a large group before.
- Maybe you work in an industry and an environment where you think “oh, nobody would be interested in hearing what I have to say”.

Let me assure you, that last one is categorically false. In my opinion, the best talks and presentations are not built around theories or tools. They are built around real world experiences, the good, the bad, the occasionally ugly, and the often unintentionally hilarious.

I had the pleasure of having dinner last night with a couple of friends, both involved in various levels of software delivery, including software testing, and the stories we were sharing, and frequently laughing about, came from our core experiences, what we have witnessed, and what we have learned from those experiences. As I listened and participated with my friends, I mentally ticked off six or seven talk ideas and said “wow, these stories, and the lessons learned from them, would be so great if we could get them out to more people”. I have a pretty good feeling that several of these conversations will become talks at CAST, but the main point I want to encourage is that “your real world experiences make for great talks!”

The Call for Participation for CAST 2015 ends on January 31, 2015. That’s a little under ten days from now. I’d like to encourage all of you, if you are able, to propose a talk for CAST. How are you moving testing forward? There’s a very good bet that what you are doing (or perhaps wish you were doing, or perhaps not doing) will be of great value to your fellow software testers. We encourage people from all arenas, all experiences, and all backgrounds to come share in each others ideas and approaches. There will be a lot of fun things happening at CAST 2015. We want you to be part of it :).

Experience is Earned, Expertise is Granted

This title is meant to be a little provocative, and some may disagree with it, but I've been thinking about this topic quite a bit recently. First of all, I want to say thank you to Ryan Arsenault and the folks over at uTest for showcasing me in their first "Ask the Expert" blog entry. The questions I was asked centered around career choices for testers and ways that we can succeed, or at least do better than we are now.

I cannot help it, part of me feels very strange using the word "expert" to describe myself at anything. I'm happy to use words like experienced, educated, practiced or even proficient, but "expert" carries a strange weight to it. It's so subjective, and it feels like, once you've been branded one, that there's only one way to go from there, and that's down. Moreover, I don't really believe there is such a thing as an "expert", because that implies that that person has learned all there is to learn and has mastered all there is to master... and that's just fundamentally wrong on so many levels.

I've come to realize that we all own our experiences, and that we all have opportunities to learn from our successes and our mistakes (oh, how much I have learned from my mistakes). This is why I have no problems talking about my experiences or my observations. They are mine, and as such, are certainly open to interpretation, or debate, or scrutiny, or even outright ridicule at times, but they are wholly mine. Expertise, however, is a judgment call. I personally have very little trust in people who proclaim themselves to be "experts" at anything. However, I place a lot of credence on other people who tell me that someone is an expert. Why? because they are witnesses to the skill, acumen and judgment being displayed, and they can then decide if the term "expert" makes sense.

It also often comes down to "expert compared to who?" I have many interests, and things that I spend a lot of time getting into. When I tell people I was a competitive snowboarder for several years, it conjures up an image in their minds; I must be an expert snowboarder. They may even watch me ride, and come to that conclusion because of the technique I can muster and the terrain I can ride on. Yet put me alongside other riders I used to compete with, and any questions of my so called "expert" level goes right out the window. That doesn't take away from what I have learned, the events I've participated in and the medals I won, but to use those hallmarks to say I am an "expert" is, in my mind, misleading. Still, to others who have never raced, or are newcomers to the sport, to them I am an expert, insomuch as I can show or teach them things that they do not know.

Again, I thank uTest for giving me an opportunity to share my experiences, and I am honored to be part of their "Expert" panel. I don't know if I deserve the moniker, but they seem to think so, and so do their readers, and ultimately, I guess that just means it's up to me from here on out to either prove them right, or prove them wrong. Here's hoping my actions and efforts do more to strengthen the belief in the former, rather than proving the latter ;).

Take Two: A Survey on “The 2015 State of Testing”

So let me set the stage here….

Joel Montvelisky wanted to write a post about the advances that have taken place in the tester-verse in the last 5-10 years. While he was trying to put this post together, he came to the conclusion that there really isn’t a centralized set of information or trends as to what is happening in the testing world.

What does a tester do when they can’t find that information? They take it upon themselves to make their own. Trust me, I understand this logic completely ;).

Thus, Joel reach out to Lalit Bhamare (who edits Tea Time with Testers) to create and conduct a State of Testing Survey. The purpose? To provide a “ snapshot” of what the “ reality” of the testing world is, and see if we can follow various  trends as they shift year by year.

For those feeling that this post is a dose of “deja vu”, well… yes, it is! The above couple of paragraphs are pretty much word for word what I wrote towards the end of 2013, when the last version of the survey was posted. Joel, Lalit and others who were asked to contribute to it are now bringing forward the 2015 State of Testing survey. I had a small hand in reviewing and helping shape this second go around for the survey.

Also, just like in December of 2013, for this survey to be effective, many people need to participate. With that in mind, I’m doing my part once again to help spread the word and encourage everyone to participate

2015 STATE OF TESTING SURVEY

This survey will be going live roughly 00:00 Thursday, January 22, 2015 (Pacific Time). Right now, there’s a countdown saying when it will go live, so if you go there right now, you’ll see the countdown. Come back when it tells you it’s done, or subscribe to get the official go-live message. Like last time, I am anticipating the survey will be up for about ten days.

So here’s what I am asking… again ;):

1. Go to the link and subscribe so that they can contact you when the survey goes live.
2. Participate in the survey and give you honest feedback.
3. Make a point to tell as many testers as you can to likewise participate in the survey.

For those who would like to see what the end of 2013 survey looked like, at least as far as the survey responders said, the link to the results are on the page as well. Also, a disclaimer; this survey is, like all things, subjective and reflective of the respondents as a whole. It may or may not reflect your own reality, but then, if you don’t participate, it definitely will not reflect your reality, or even a statistical sliver of it. If you want to give your opinion or have your voice heard, well, now’s your chance :).

Book Review: Design Accessible Web Sites

This is a bit of a retro review, but since I’m in the process of putting together a talk about the design and testing aspects of sites as relates to accessibility, this came recommended as a good starting point.

Many books that talk about designing for accessibility tell you a lot of the what and the way around accessible design, but don’t put much emphasis on the how. Jeremy Sydik’s book “Design Accessible Web Sites: Thirty-six Keys to Creating Content for All Audiences and Platforms" does an admirable job on explaining the "how" of accessible design.

This book was originally published in 2007, so the technical underpinnings of the web have certainly changed a bit, but the overall message of “Design Accessible Web Sites” is still very relevant and still very usable. In the current rush for the latest and greatest, with frameworks abounding to handle just about every conceivable interaction, there comes a need for programmers and site designers to step back and consider if they are making it possible for the most people to use the sites and access the content they provide.

The core of the book revolves around what Sydik calls the Ten Principles for Web Accessibility:

1. Avoid making assumptions about the the physical, mental, and sensory abilities of your users whenever possible.
2. Your users’ technologies are capable of sending and receiving text. That’s about all you’ll ever be able to assume.
3. Users’ time and technology belong to them, not to us. You should never take control of either without a really good reason.
4. Provide good text alternatives for any non-text content.
5. Use widely available technologies to reach your audience.
6. Use clear language to communicate your message.
7. Make your sites usable, searchable, and navigable.
8. Design your content for semantic meaning and maintain separation between content and presentation.
9. Progressively enhance your basic content by adding extra features. Allow it to degrade gracefully for users who can’t or don’t wish to use them.
10. As you encounter new web technologies, apply these same principles when making them accessible.

Part 1 lays out the case for why accessibility is important (it’s good business, it;s the right thing to do, it’s the law in many places, and accessible sites are more usable for everyone). This section also steps through a variety of disabilities, some of which we automatically associate with Accessibility (visual, auditory and mobility impairments, as well as a variety of cognitive impairments and those who deal with a combination of the previous issues, specifically due to the results of aging). It also introduces the first eight “keys” of preparing for making an accessible site, including planning, making multiple access paths, avoiding the WET trap (WET stands for “Write Everything Twice”), and to set a solid foundation of accessibility testing, which really does require sapient skills to do. Automation can tell you if a tag is there or not, but it cannot tell you if a user experience for a disabled user is comparable to one for a normative user.

Part 2 focuses on building a solid structure for your pages, with thirteen additional keys to help you design your pages with accessibility in mind, such as keeping the site design simple, removing style from structure as much as possible, using links effectively, designing interfaces that emphasize the selecting of elements and actions rather than drag and drop movement, breaking away from tables and creating forms that are easy to follow and intact with without losing their interactivity or power.

Part 3 focuses on the visual aspects of the web, specifically how we deal with photographs and video clips. the nine keys in this section focus on selecting colors that contrast and don’t blend together, utilizing alt tags as more than just a place holder for generic text, and encouraging a design that can describe itself and allow the user to “see” the whole picture, or “hear” the whole story, even if those options are not on the table.

Part 4 looks at some additional aspects of accessibility and rounds out the last six of the thirty-six keys with how to work with documents that are not traditional for the web, options for dealing with PDF files, scripted output, as well as with Flash and Java apps.

Part 5 is a reference to a variety of web accessibility guidelines including WCAG, US Section 508, and examples from around the world, including Australia, Canada, European Union, Japan, United Kingdom, United Nations, etc.

Bottom Line:

To design sites that are accessible, we have to think differently, but the differences need not be radical. Also, accessible design need not be boring design. There are plenty of techniques and approaches to use that will help make sites easier to interact with for a broad population, and for those willing to embrace this approach, having the capability of designing sites that are accessible could be a differentiator for you as compared to other designers, programmers and testers.  As the tenth principle says, "As you encounter new web technologies, apply these same principles when making them accessible.” Technology moves on, but the advice and methodology is still sound, making ‘Design Accessible Web Sites” an evergreen title to consider for years to come.

In Through the Side Door: Advice from an Unconventional Career

First off, Happy New Year to all of my friends and readers out there. I wish you all a great 2015 with the hope that what you strive to do and accomplish will be met.

About two years ago, I was given the opportunity to do a talk for a conference that would be happening in India called ThinkTest. My friend Smita Mishra extended an invitation to me to participate, and while I could not actually travel to India at that time, we decided to try something unorthodox. Why not video-tape my talk, and we would whittle it down to a presentation length and make it available to those who wanted to view it? Since I found myself in a hotel room near Chicago for an extra day, I decided to turn the room into a makeshift film studio and talk about my career as a software tester, its ups and downs, and other things that helped make it a reality.

Sadly, due to an automobile accident that incapacitated Smita for awhile, the conference had to be canceled. The talk project was, of course, put on hold, and then, over time, other initiatives took center stage, and I forgot about the talk and the recordings... that is, until a couple of months ago. Lalit Bhamare of Tea Time With Testers, asked me if we could use the material for his new project, TV for Testers. I said "sure", and he then proceeded to gather the clips I had recorded and delivered to Smita into the talk that is presented here.

In Through The Side Door

First, I feel it only appropriate to say... this is a long talk! I had originally recorded it with the idea that we would cherry pick the best parts and make a shorter presentation (something around forty minutes) but through correspondence with Lalit, he asked if it would be OK to present the entire talk, in its (mostly) unfiltered form. He felt that there was a lot of insights I offered that would be of value to those who, likewise, came to their careers from peripheral avenues, and the asides and segues, in his opinion, actually added to the value of the talk. So, again, that's what we decided to do. Lalit posted the talk on TV for Testers today, and I am now saying to those who would like to check it out, please do so.

Again, my thanks to Smita for asking me to put this together, and my thanks to Lalit for deciding he wanted to have it be seen. If you take the time to watch it, I also thank you for doing exactly that. To borrow from and paraphrase the recording artist Seal, "I hope you enjoy the presentation; it was the best material I had at the time" :).