Friday, January 23, 2015 16:12 PMUncharted 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.
"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.
Monday, January 26, 2015 22:11 PM
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 :).
Wednesday, January 21, 2015 21:55 PMRyan 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 ;).
Wednesday, January 21, 2015 18:52 PM
- Go to the link and subscribe so that they can contact you when the survey goes live.
- Participate in the survey and give you honest feedback.
- Make a point to tell as many testers as you can to likewise participate in the survey.
Tuesday, January 06, 2015 21:23 PM
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:
- Avoid making assumptions about the the physical, mental, and sensory abilities of your users whenever possible.
- Your users’ technologies are capable of sending and receiving text. That’s about all you’ll ever be able to assume.
- Users’ time and technology belong to them, not to us. You should never take control of either without a really good reason.
- Provide good text alternatives for any non-text content.
- Use widely available technologies to reach your audience.
- Use clear language to communicate your message.
- Make your sites usable, searchable, and navigable.
- Design your content for semantic meaning and maintain separation between content and presentation.
- 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.
- 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.
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.
Thursday, January 01, 2015 19:38 PM
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" :).
Tuesday, December 30, 2014 15:58 PM
I am one for whom Dan Carlin's phrase "History has all but ruined fiction for me" rings true. I find that the real life exploits of historical figures, and the reality of their worlds, tends to make many aspects of fiction story telling, well, just not hold much interest. Fictional Mob Boss or the struggle for Alexander the Great's throne? Mythical marauders or real life Scythian warriors and their waves of descendants? Seriously, how can anyone top the Mongols, in fiction or elsewhere?
Still, there's a part of me that loves the "what if's" of both the near and distant future, with the possibilities, be they wondrous or terrifying, that make science fiction a place I enjoy spending time in. Added to that is my love of Role Playing Games, especially those that come from Japan (think the Final Fantasy series, Shin Megami Tensei, and Suikoden). Also, I love Animé series that look at the struggles of everyday people against overwhelming odds (think "07-Ghost" or "Gantz"). When something hits that sweet spot of all of those interests, and still focuses on the humanity of story telling, I pay attention. Add to that having an author of such material being a personal friend? Well, what else can I say? I want to share, and share I shall :).
M.C. Muhlenkamp is putting together a series of short stories that feel one part ancient Rome, one part Eurasian steppe, one part Japanese RPG and one part Young Adult dystopian struggle. Weave these all together and you get what is shaping up to be "Markram Battles". More to the point, "Markram Battles" takes a cue from the past, in that it is really a serialization. If you liked the idea of Alexandre Dumas publishing his "Three Musketeers" in small pieces, waiting to see where and when the next "dose" will appear, then here's an opportunity to do exactly that.
Genesis of an Uprising" and "Omens of Doom") focus on the interactions between Seven, a Unit Leader whose sole purpose is to lead recruits in battle, and Thirteen, an unwilling recruit who refuses to play the game, at least not in the way that the Markram want her to play.
The chapters are short and taut. The characters are believable even in their other-worldly space. Little in the way of useless exposition is given. The reader is expected to go with the story and figure out the world and its parameters without long winded explanations as to what has gone on before, except where it makes sense to give context to the situation. Even in the first short sections, you find yourself caring for the characters and wondering what will happen next, on both sides, Markram and human.
The cover sets the tone and the mood of the stories, and in this way, I can't help but feel drawn to parallels made in video games like "Shin Megami Tensei: Digital Devil Saga" or Anime like "07-Ghost", each with a fight to survive ethos and a shadowy "other" pulling the strings. The stories feel like they are designed for a YA audience, but don't let that dissuade you, as the themes and the stories focus are strong enough for all ages.
The serialization approach works well for this series. It feels like a Manga without the pictures, and that's meant as a solid compliment. Two issues in, I find myself asking "OK, so when will number three be ready?" If stories about human spirit and desire to not cave to the rules of an unfair system hit a sweet spot for you, give these stories a try. They are quick reads, and at $0.99 apiece, less expensive by far than a manga series, and every bit as engrossing and satisfying. Yes, MC and I are friends, but I'd dig this series even if we weren't ;).
Monday, December 29, 2014 19:17 PM
Monday, December 22, 2014 20:40 PM
As many of you saw last month, we had some dramatic happenings in the Bay Area Software Testers Meetup group. We want to usher in 2015 with a bang, and to that end, I am please to say I will be giving a talk on Thursday, January 8, 2015 and I want you all to come.
Now, granted, this is probably going to work best for people who will happen to be in the San Francisco Bay Area on Thursday, January 8, 2015, but hey, why be exclusive ;). Seriously, though, if you can make it, here's the details about the event and what we will be covering:
All for Web, and Web for All: Designing and Testing for Accessibility - Michael Larsen
As the web, mobile, and other devices we have yet to fully comprehend proliferate around us, we want to do our best to cater to the customers that best represent the users of our products. However, there is a population that is frequently left with little to work with, and that is those who have to deal with physical disabilities. Issues with sight, sound, motor movements, comprehension and other disabilities puts many sites and apps out of reach for those who would most like to use them.
Making products that are accessible is more than just implementing a few tags so a screen reader can spell out the terms, it involves designing a product from the top down to be navigated easily and seamlessly.
In this talk, I will present some challenges those with disabilities face, ways that we can design products to better work for those with various physical disabilities, and that testing for accessibility can be a fun, interesting and important part of your organizations product offerings.
To RSVP, please see the formal invitation and event details HERE.
Friday, December 19, 2014 14:07 PM
Saturday, December 20, 2014 20:21 PM
For the life of this blog, I have deliberately avoided any direct advertisement, or made any attempt to "monetize" it. I plan to keep it that way, since not accepting advertising allows me to say exactly what I want to say the way I want to say it.
Having said that, there's no question that several book publishers have been more than kind, giving me several dozen titles for free over the years as review copies. More than half my current technical library consists of these books, and many have been great helps over the years. If I can return the favor, even just a little bit, I am happy to do so.
Packt Publishing, located in the United Kingdom, is one of those publishers, and they are currently holding a special $5 E-book sale. Any and all e-book titles from Packt are available for $5 for a limited time (until January 6, 2015).
- Backbone.js Cookbook
- Java Script Security
- JMeter Cookbook
- Kali Linux Network Scanning Cookbook
- Learning Python Testing
- Responsive Web Design By Example
- Selenium Design Patterns and Best Practices
- Selenium webDriver Practical Guide
- Web Development with Django Cookbook
- Wireshark Essentials
Thursday, December 18, 2014 19:27 PMUncharted Waters blog titled "You Can Live Without a Resume!" I'm kidding of course. Not about wanting you to read the article, but about the shameless self promotion part. If I were really all about shameless self promotion, that's all I would say, but you all know me better than that (or at least I hope so ;) ).
When I say "Live without a Resume", I do not mean live without any reference to you or what you do. What I mean is "spend less time on the resume and spend more time on visible, tangible aspects of your work and what you can do".
If I were to try to convince someone I know my stuff about testing, and all I sent in was my resume, that may or may not get anyone's attention. What I do know is that, if it doesn't match their particular filtering criteria, it may never even get looked at. Personally, I don't want to start a conversation from that position. Frankly, I don't even want to have a conversation stemming from "hey, I looked over your resume, and..."
So what do I want to have happen? Personally, I'd prefer any of the following:
"Hey, I was looking over your LinkedIn profile and I noticed you had several talks posted. I listened to a couple of them, and I'm interested in talking more about what you said"
"I was looking at the Weekend Testing site, and I noticed your name listed on many of the sessions. I read a few, and hey, I think we might have something to discuss"
"I read several of your published articles. Could we get together and talk?"
"I spent an afternoon reading several posts from your blog. I think you're insane, but you might be a good fit for a friend of mine's company. Can I have them contact you?"
For the record, I have had every one of those things happen. No, this is not a way for me to strut and act cocky. Instead, it illustrates the power of having your work be on display in a way that steps outside of having a resume.
I owe this whole experiment to Seth Godin, and I've tried it now for almost five years. Granted, I could be proven wrong tomorrow. The bottom may fall out of the market, I could find myself unemployed, and then all of what I'm suggesting may not work any longer. That is of course possible. So far, though, Seth's hypothesis has proven to be sound, and for that, I am seriously grateful :).
Wednesday, December 17, 2014 21:20 PM
We've agreed to a simple goal, and for now, that goal is the Codecademy streak. I've told her I don't care if she only does one lesson on a given day, as long as she at least does that one lesson. Of course, I'd be really happy if she did two, or three, or ten, or heck, even do fifty like I did about seven months ago. Yes, I spent a free Saturday and completely pounded through the entire jQuery course. No, I'm not convinced that was the best use of my time, considering how much I still have to look up to write anything today.
What I realized from that particular experience was that my own enthusiasm to "push through" caused me to take shortcuts. I violated what I jokingly refer to as "The First Zed Commandment" which is "thou shalt not copy and paste". Those who have read any of Zed Shaw's books on "Learn [Language] The Hard Way" know that he espouses this pretty heavily, and I do too... most of the time. However, my own impatience often gets the better of me, and yes, I find myself cheating and copying and pasting. If I were looking to get in physical shape for a run, would I get the same benefits if I agreed to run 5K each day, but when I got impatient, I hopped on my bike and rode the rest of the way? Would I get the same training benefit? Would I get the same physical conditioning? The answer is, of course, no. Writing code is the same way.
At this stage, I may wish my daughter were moving faster, but if the net result is that she scores a lot of points, gets a lot of badges, but doesn't remember fundamental syntax or hasn't put the time in to recognize where she has made a mistake, what am I really teaching her? This has prompted me to, instead, ask her what time she wants to sit down with me, her with her computer, me with mine, and we work either face to face or side by side. This way, she sees what I am doing, and how I'm doing it. It may encourage her to do likewise, or she may say "hey, that looks odd, what are you doing?" Either way, it will start a conversation, and then we can discuss the fundamental details. I have to realize that it's better for her to pull from me rather than me push to her.
So fundamentally simple, so easy to say, yet so hard to do when "Dad Brain" wants to carry her along as fast as he can. On the positive side, this is also allowing me to step back and make sure I really understand what I think I understand, with the often neat realization that, hey, I really didn't know that as well as I thought I did. Consider this my solid recommendation to anyone wanting to learn how to code... teach your kid how to code. If you don't have one, see if you can volunteer at a school's computer club and offer your time. What I'm realizing anew is that the example of working through problems for them is a pretty amazing teacher in its own right.
Tuesday, December 16, 2014 22:00 PM
During the first couple years of Weekend Testing Americas, Albert Gareev assisted me in getting the group off the ground, working on some more interesting and technical topics, and even worked with me to propose and try out the "Project Sherwood" project. We decided that the Weekend Testing model as it was designed at the time wasn't the best model for this expanded idea, but Albert didn't give up the fight.
We've talked a number of times over the past couple of years about how the Weekend Testing model works both as a distributed communication model, but that it can also work well as a live and in person event. We realized that what "Project Sherwood" was missing was that in-person direct give and take element. Albert figured for that to work, it would make sense to try it with a group he already had familiarity with and in a community where such events could be developed and focused on. Since Albert is in Toronto, he figured "why not set up a Weekend Testing chapter in Toronto?"
Why not, indeed :)?!
For those on the East Coast, and especially those in the immediate Toronto area, you are going to get a cool opportunity. Albert is a dedicated and accomplished tester, with a wealth of knowledge and a fountain of ideas. For those wondering if this is going to dilute the current Weekend Testing Americas offerings and sessions, I'm going to say "unlikely", because those who enjoy participating in these events will go to those that make sense for them and their availability. I've attended events in just about every of the chapters over the past five years, so in my mind, the more the merrier. The real winners are the testers that want to participate and learn some cool things.
So what should you do? For starters, go and join the Weekend Testing Toronto Meetup. Follow @WT_Toronto on Twitter. Check Weekend Testing's main site for scheduled sessions. Most of all, get ready for a fun and engaging opportunity with an interesting and passionate advocate for testing.
Monday, December 15, 2014 22:53 PM
The common line is that they will hire someone to take over that role, but I've rarely seen it work that way. In fact, the large majority of the time, it falls to someone on the team who either has the misfortune of being assigned the task, or someone is crazy enough to jump into the breach.
I would recommend to any software tester, if you get the opportunity to find an area that is suddenly vacant, even if it may not be a skill or area you are entirely comfortable working in, take the person who is leaving out to lunch and ask them about that key area. It's possible they may not have time for you, but it's also possible they may be more than happy to show you how to work in that area.
As an example, we recently received word that one of our programmers was going to be leaving. There was some discussion in the Engineering meeting about some of the things this engineer was responsible for, and one of those areas (the management of virtual instances) was discussed as something that would need to be reassigned. I threw up my hand and said "I realize I may be out of the main flow of this at the moment, but in my past life I was responsible for handling the Hyper-V virtualization servers at a previous company. I wouldn't mind learning what might be different and where I could be helpful here".
Expecting to hear "Oh, that's OK, we can manage", I received an answer of "Wow, that's great! Yes, could you two get together and make that transfer happen?"
Truth be told, I felt pretty confident that this would be the case. Part of the reason was that I didn't ask permission, I just said "hey, I'd like to learn that". I relied on the fact that my company would have to either look for a person to fill the role, or let someone who volunteered try to take it on first. By voicing my interest, I solved a problem for them; they don't need to look for a new person to do that work. I also gave myself a jolt of electricity to take on something I wasn't currently doing, but felt would both help the organization and, additionally, help me ;). What I also did was couch the opportunity by saying I had a similar experience that I could use to draw upon. I wasn't saying "I know nothing about this, but I can learn". Instead, I phrased it as "I have some experience from this other domain that I think might help me bridge the gaps".
I can only speak for myself here, but I think we tend to wait for others to say it's OK for us to take on a particular responsibility, or to have someone tell us we will be doing something. We likewise might feel that we don't have the seniority or technical ability to take something on, or we may perceive our organization may believe we don't. My recommendation is, if you want to up the odds in your favor of getting an opportunity, ask after someone has announced they are leaving. I'm willing to bet that they would give you the benefit of the doubt. The alternative is to leave a vacuum, and companies abhor a vacuum ;).
Monday, December 15, 2014 01:04 AM
Saturday, December 13, 2014 22:13 PMHour of Code". Amber signed up for the "Intro to Java" class. The materials being used for this class can be seen at the Khan Academy, and is an "Intro to Drawing" using Java syntax.
I'll let Amber take it from here:
I would say that the web site we used was very "child friendly". It helped to make it possible for children and teenagers to work on code. It had videos, so instead of reading it, you could see it happen in front of you. We also worked on projects where we were able to make shapes and add colors and work with a palette. It was a good introduction and it was easily doable in an hour.
I think some of the explanations needed to be listened to a couple of times. Some of the other kids I was working with got stuck, but we were able to talk together and straighten it out. It reminded me of the HTML and CSS modules I have been working with in Codecademy.
Speaking of Codecademy, I think my having spent the last month working through the projects there helped me a lot, maybe too much. I finished the set of videos and projects 25 minutes before everyone else.
If I had to say there was anything I didn't like, it's that right away it told me if I made a simple mistake (well, sure, but I'm not finished yet, hang on!). Maybe it's because I'm used to the Codecademy approach, where you fill in what you want to write, and then submit the whole thing, and if there's an error, the screen shows it and it makes a suggestion, and you have to figure out what you did wrong. In a way, that felt more like "testing". With this, it came right out and told you what you were doing wrong. I think I might have learned more without the frequent reminders, but it was an intro, so I understand.
I think that instead of calling it an Intro to Java, it should be called an Intro to Drawing (using Java) because we focused more on the drawing (making lines, making rectangles and circles, filling them in) than we did on the Java. Having said all that, I think it makes sense to do what they did, because they want to make it interesting for kids to want to learn more, and with that, I think they did a pretty good job.
Saturday, December 13, 2014 01:07 AM
It is that time again. It's the end of another year, and it's the time that I do my typical retrospective on the year that was, what I wrote, what I learned, what I did and what I didn't do. I did a little search for my "Retrospective" tag and smiled, realizing that this is the fifth entry in this series, and an (almost) fifth year of writing this blog. I think that's somewhat noteworthy, as I have very few endeavors that I can point to that have survived for five years, much less thrived. Outside of my marriage and family, and a couple of jobs, this may well be the single longest running entity I've ever managed. No, that's not a sign I'm looking to end this, in fact I'm just getting warmed up. Also, yes, the title is, once again, a nod to the Talking Heads song 'Once in a Lifetime". I'm not sure how many more years I'll be able to keep this streak going, but it worked again for 2014.
- Testing as a Service? A Post-POST Post (workshop review)
- Read Articles, Blogs, Forum Posts: 99 Ways Workshop (how-to guide)
- Introvert? Extrovert? Or Both? (exploring diversity)
- Learning to Tell Different Stories (exploring diversity)
- Exercise 5: More Variables And Printing: Learn Ruby the Hard Way (how-to guide)
- Inflicting Help (lessons from home)
- BOOK CLUB: How We Test Software at Microsoft (5/16) (book review)
- Onboarding and Not Getting Mau Mau'd (interpersonal relationships)
- When Things Just Aren't What They Seem (interpersonal relationships)
- I Used To Be a Staffer… (volunteering and leading)
As the title says, Time is an Asterisk. It's not just a line to continue a theme (though it does that quite well ;)), it also reminds me that, truthfully, I don't know what next years letter will look like, or what forces are going to shape the next year, or what the flavor of the posts that come will contain, though I can probably offer some guesses. I have a lot of books I want to review. I have a lot of ideas I want to test out with my daughter to see if they work or not. I have a lot of goals I want to see myself obtain. Which ones I will actually cover, and which ones will be written about here, that remains to be seen, but I will do my best to make sure it's something interesting and unique to my own experiences. That I can pretty much guarantee. The rest is a wildcard ;).
Friday, December 12, 2014 17:57 PM
Zero to One is a book about being an entrepreneur. For many of us, we may stop right there and think “ehh, I’m not an entrepreneur, so this book isn’t for me”. I would encourage anyone with that attitude to not think that way. Regardless of whether or not we work for a company, or we are the founder of a company, or we do freelance work in various capacities, all of us are entrepreneurs. In the curation of our own careers, absolutely we are. To that end, we want to create, to do something interesting, and maybe, dare we say it, change the world.
Most businesses we will see tend to copy someone else in some capacity. They are content to copy what has been successful for others. This is what Peter refers to as "One to N” improvement. It’s incremental, it’s a shaving of time, it’s an improved efficiency, it’s streamlining of process. It may keep you afloat, but it will not rocket you ahead. For that, you need a different approach, a true sense of innovation, a mindset that will bring you from Zero to One.
Thiel presents many anecdotes from the past thirty years in Silicon Valley, with many familiar stories, ups and downs, and memories, oh the memories (having been at Cisco Systems in the 1990s, and with several smaller companies through the ensuing fourteen years, Thiel’s stories are not just memorable, they are my history, and some of the stories hit a little too close to home ;) ).
The book is structured around seven questions that any company (and any individual) should be ready and willing to ask themselves before they commit to a venture or creating what they believe will be a “killer startup”. Those questions are:
Zero to One: Can you create something new and revolutionary, rather than copy the work of others and improve upon it?
Timing: Is NOW the time to start your business? If so, why? If not, why?
Market Share: Are you starting as a big player in a small or underserved market?
People: Do you have the right people to help you meet your vision?
Channel: Can you create and effectively sell your product?
Defensibility: Can you hold your market position 10 and 20 years from now?
Secrets: Have you found a unique opportunity or niche others don’t know about?
Additionally, Thiel encourages that any product that will qualify as a Zero to One opportunity will not just compete with other options, but it will offer a 10X level of improvement over what has come before. If it doesn’t, then competition may overtake and erode anything you may offer. Harsh, but perfectly understandable.
Thiel addresses topics like success and failure, of disruption and collaboration, of replacement and complementarism, and of the fact that any real good technology, no matter how good, needs to be sold and marketed. Engineers believe that if their products is as good as they think it is, it will sell itself. History shows time and time again that that is not the case, and Thiel comes down hard on the side of sales being a driver, and that sales must be shepherded.
Bottom Line: Zero to One makes the case that true entrepreneurship needs to start from the idea of doing something unique, and being willing to look at the seven questions realistically and determinedly. If you cannot answer all seven of the questions with a YES, your odds of success are greatly diminished. Even if all seven can be answered with yes, there are no guarantees. This book is not a tell all guide as to how to be an entrepreneur, but it does give some concrete suggestions as to how to approach that goal. It’s a what and a why book, not a how book, at least not a "formula" how book. It does, however offer a lot of suggestions that the future entrepreneur, company worker, or freelance creator could learn a lot from. If you get the book, read it twice. If you get the audio version, listen to it three times. I think you’ll find the time well spent.
Saturday, December 13, 2014 01:08 AMIT Knowledge Exchange Uncharted Waters blog. It's titled, "You Keep Saying Diversity, Does it Mean What You Think it Means?"
As I discussed in my live blog posts at EuroSTAR a couple weeks back, many of the discussions are based around "external diversity". Understand, the current environment for many companies and events makes that conversation extremely relevant. I am sensitive to the fact that there is not a broad representation in the computer sciences or in information technology, and yes, gender, ethnicity, and mobility are important areas to focus on.
Less discussed are the areas inside of each of us that make us unique, and dare I say it, possibly hard to manage. This article is meant to keep the conversation going and look at the other less obvious areas where diversity may be taking a hit, even while we are focusing on external factors.
Please have a look, share your comments on the article page, and hey, while you're at it, perhaps consider making Uncharted Waters a regular stop. Between Matt, Justin and myself, we post a number of interesting articles about software delivery, technology, work, the changing technical landscape, and yes, even some software development and software testing, too.
Wednesday, December 10, 2014 15:16 PM
As I posted late last month, my daughter Amber has embarked on a journey to learn about software development and software testing, and has proven willing, most of the time, to work through the examples in Codecademy and some other example projects to learn more about code and how it works.
Tuesday marked a milestone point for her in that she has now set a 30 day coding streak. As of right now, she is most of the way through the HTML and CSS course, and is about 10% through the Python course on Codecademy. I figured it would be a good time to have Amber tell us a little bit about what she has been doing and her reaction to all of this so far.
It's been 30 days, and in that time, I've worked through about 150 exercises, and I have installed my own Python compiler and a program called Geany, which is a nice little window where I can write all of my code for different stuff. I can write HTML, CSS and Python code in this tool, and I can compile and run the Python code I am running.
Geany was a new tool to me, I learned about it when I was in Dublin, and it was used for the Programming for Testers workshop. What I like about it is that it is fairly unpretentious; it's a simple editor that gives the user color coding of different languages, the ability to hook up different compilers for different languages, and a stripped down interface that focuses on the core needs of the person using it. As an exercise for her, I asked her to download the code, get it installed, and get it working and try to do so with as little input from me as possible. By doing so, she had the chance to look at available sources, make a choice about what she downloaded and utilized, and then put it into use.
When I saw the different versions, I decided to download the newest one, which was Python 3.4.2. It was easy to install (I just followed the screens) and it was easy to put in the code and see the coloring of the letters. I noticed that the code I was working on in Codecademy wasn't working in Geany. I read a bit about Python 3 and found out that the print statement now needs parentheses. Since I'm just starting off, and I've only been doing this for a few days, I haven't really gotten into the habit of writing the code a certain way, so making the shift from Codecademy and Python 2 to Geany with Python 3... it's not hard, it's just something I need to do, and I just do it. It's a little bit of a challenge, but it's easy to handle.
One of the things I encouraged Amber to do with the materials she was working on and reviewing was to take the time to set up files in Geany that reflect what she is learning. Sure, there's a lot you can learn in Codecademy, and there's a list of all the exercises, but going back to review can take a long time, and locating the different items takes a while. When I worked through "Learn Ruby the Hard Way" a couple years back, I made local copies of each assignment, but even then, it was a litter of code and took time to find what I was looking for. As I was talking to Amber about organizing the things she was learning, I suggested that she make a personal project so that each item she learns, she can write it into the project and have it be part of a larger whole. I'm of the mind that we can learn a lot of things, but if we don't have an authentic problem to solve, or a way to put what we are learning into daily use, we will lose what we learn, or we will struggle to find it later.
I'll let Amber pick up from here...
As we were talking about gathering up each lesson, the idea was that I would make a set of files (a web site for HTML and CSS, some longer program in Python) and we'd make it grow and show examples, both on the screen itself and in comments. As we were talking about it, we were joking about the need for "sheet music" for the project. We both started talking about writing a "libretto" for the project, and we said "hey, that's a neat name", so we are now calling our project "Libretto". We are also using Dropbox to keep everything up to date so we can both look at it and "work on it" together.
As Amber said, we happened on the term "Libretto" to describe what we are making. Borrowing from Wikipedia:
Libretto (pl. libretti), from Italian, is the diminutive of the word libro (book). A libretto is distinct from a synopsis or scenario of the plot, in that the libretto contains all the words and stage directions, while a synopsis summarizes the plot.
This seemed the perfect metaphor for this project. Instead of words and stage directions, this project would contain examples of what she is working on, as well as comments in the code to explain the code itself. It will be verbose, it will have lots of comment space. It won't be particularly elegant, but over time, we want to make it become a collection of classes, methods, IDs pseudo-classes, and other aspects that she can look back to and say "Oh, yeah, I made a pseudo-class that does this one thing, and I can use that as a framework to make something else". The idea is that, as she learns each language, the "Libretto" will tell the same story for that language. By doing so, she can work with the pieces and see how different technologies would solve similar tasks, and do so in a space that can be periodically refactored. The cool thing is that, at least for the time being, Geany looks to be up to the task.
Friday, December 12, 2014 17:57 PM
Also, as a software tester, I often have to look at the calculations being made, and make sure they are right. For 90% of what I do, the math I have learned to date is fine, but there’s still that crazy rush I get when I look at higher order math, or math in areas I’m not familiar, and that door creaks open just enough for me to get a glimpse of something I didn’t understand before, or I feel I’ve come a bit closer to understanding it.
"Good Math” by Marc C. Chu-Carroll has proven to be very helpful in creaking that door and giving me a glimpse into things I thought I understood, but didn’t really understand. The subtitle of the book is "A Geek's Guide to the Beauty of Numbers, Logic, and Computation” and to be fair, the second two areas are the meat of the book. Yes, it goes into the classic popular numbers topics like the development of our numbering system, roman numerals, the discovery of pi, the concept of zero, etc. but it moves on from those pretty quickly.
Mark is the author of the "Good Math, Bad Math" blog. Many of the topics that are covered in this book (and many more that are not) can be read there. Those debates, and some of the confusion regarding different areas of math and computation inform much of this book.
Part 1 deals with Numbers, the one’s we are most familiar with, but also does so in a way that focuses on the rigor of mathematics to make the case for them. Natural numbers, Peano Induction, Integers, Real Numbers, and Irrational numbers get covered here.
Part 2 focuses on Funny Numbers, including the concepts of Zero, e, the Golden Ratio, and i (the imaginary number, what it does and what it means).
Part 3 focuses on the written numbers throughout history, including Roman Numerals, Egyptian Fractions, Fibonacci numbers, and the development of the arithmetic we so often take for granted.
Part 4 delves into Logic, or more specifically, the mathematical proofs that define logic. This section also covers ways of programming using logic and Peano arithmetic, with examples written in Prolog. Note: these examples are not comprehensive, but merely to give a taste of how to use the concepts.
Part 5 deals with Sets, and the variety of ways to look at sets in mathematics, including Axiomatic Set Theory, Models, Infinite Sets, and Group Theory/Symmetry.
Part 6 focuses on Mechanical Math, or Computation. Here is where the Computer Science aficionados may check out, but I was intrigued with clear descriptions of Finite Set Machines, Turing Machines, implementations of systems that are Turing Complete, and how Lambda Calculus is at the heart of the development of programming languages, especially Lisp and Scala.
As one who studied computers from an IT perspective rather than a CS perspective, I never fully got into the logical nuts and bolts of how computers really work. The sections on computation, as well as the sections of defining logic as a computer sees it, and in the strict notation of mathematical proofs, was fascinating.
Good Math is geared towards programmers, and is meant to introduce topics of higher math in ways that will help programmers understand how to implement the ideas, as well as to help them understand how computers actually go about doing what they do. Truth be told, for many of us who use higher level interpreted languages like Ruby, we can go a long way in writing code without ever being exposed to any of these concepts. There are several examples shown, but none worked out in detail. Again, that’s OK, as this is meant to be a survey book about mathematical concepts as relates to computing and logic, not a full blown course in how computer languages implement these models.
Bottom Line: If I were to suggest a core audience for this book, it would be to people like myself, people who have worked with programming languages, may even know a few cool tricks and have some system internals knowledge, but don’t have a strong foundation in higher math. Having said that, if you made your way through typical high school math courses, most of this will feel familiar and accessible. Some of it will feel strange, too (lots of symbols I’ve personally not used in years, if ever), but Mark writes about them in a way that makes them accessible. You still may find yourself reading various sections a few times. Well, I did in any event.
Tuesday, December 09, 2014 16:41 PM
The past three days have been, shall we say, emotional, frustrating, and wonderful, all at the same time. Most of all it has shown me that a group of vocal people can make a difference, but more on that in a bit.
First, some perspective. Last year, Curtis Stuehrenberg and I, along with Josh Meier, decided it was high time there was a software testing Meetup group in San Francisco. May not sound all that revolutionary, and wait, weren't their plenty of software testing groups already? Well, yes, if your main focus was on a specific tool. The Selenium Meetup group has been a de-facto testing group for years, and it's where a lot of software testers go to participate and share in testing topics from time to time, but what we noticed was missing was a focus on the "ilities" of software testing, as well as the areas that go beyond the programming aspects of software (or "paradev" aspects, to borrow from Alister Scott). Thus, we decided to inaugurate the Bay Area Software Testers group, or BAST, as we colloquially refer to it, with the following goals in mind:
The Bay Area Software Test Association originally formed as an impromptu attempt to provide software testers and quality engineers from San Francisco and the East Bay a place to meet and network without having to brave the Silicon Valley traffic snarl. Currently we meet on a monthly basis, providing a chance to hear people talk about general topics and socialize/network/schmooze some of the more interesting people on any software development team .... the testers!
We enjoyed several months of great talks, great conversations, and great activities, and then the summer and fall time frame saw less activity, due to scheduling challenges all of us were dealing with, and just a general challenge to get everyone on the same page. Sometime in this time frame, my Meetup account had been hacked, and I stopped receiving updates. Sad thing is, so much else was going on that I didn't get a feeling for what was happening until just a few days ago. A post to Twitter, though, definitely got my attention:
Friday, December 05, 2014 02:41 AM
As a software tester, this next recommendation is probably going to seem a little out there, but I think if you spend some quality time with it, you'll feel differently. Also, I'm a total fanboy of this series, and I want to make sure as many people know about it as possible.
Have you ever wanted to have an introduction and then a continued consideration of topics that are big, meaty and maybe just a little terrifying? Would you like to have those topics be fun to listen to, and be something you'd like to go back to again and again? Finally, would you like something that would be a great catalyst to help you change up the way you think about the world and, well, how you think in general.
Then Crash Course is for you :).
What's Crash Course, you ask? It's the brainchild of brothers John and Hank Greene. Put simply, it's a series of video collections that cover a variety of course areas. World History, U.S. History and Literature are taught by John. Chemistry, Biology, Ecology and Psychology are taught by Hank. A collection called "Big History" is taught by both of them with input from Emily Graslie of "The Brain Scoop". All of these "courses" are available via the Crash Course YouTube channel. Below is a sample video that explains the series:
Friday, December 12, 2014 17:57 PM
There are a handful of tools out there, and some books that describe what Accessibility means and things to consider when testing sites, but I was confused as to how to actually make the sites I was testing accessible in the first place. Katie Cunningham, the author of the Accessibility Handbook, felt the same way. Her goal was to make a book so that people who were programming websites would have a quick reference as to the what and the how of making sites accessible, with an emphasis on Section 508 Compliance, which is the primary standard for Accessibility in the United States. Akren stated her goal for the books as follows:
"I decided to write a book that focused on the disabilities rather than the patches. Yes, alt text should always be used and tables should always be scoped. What’s even more important to understand is how poor alt text or tables with no scopes affect the experience of a user. Understanding a user’s tools and limitations helps developers and designers make the next generation of web applications without excluding anyone.”
So how does the "Accessibility Handbook” measure up to that stated goal?
The book breaks each chapter up into different physical challenges, and what defines those challenges as per the recommendations spelled out in Section 508. The chapter describes a set of “Annoyances” that would be present for the user without accessibility considerations, a list of tools available for the users in that capacity, and the methods used to remedy those issues.
Chapter One focuses on “Complete Blindness” and the primary tool for those who are legally or medically blind, and that is the screen reader. Utilizing a variety of tools depending on the platform to be used, this section explores how to optimize HTML and CSS to use screen readers. In addition, aspects such as WAI-ARIA tags are discussed, and aspects of how the product can be tested as well.
Chapter Two focuses on other types of Visual Accessibility, including issues related to Color Blindness and contrasting colors as well as issues dealing with low vision (where the challenges are that text is too small rather than completely unreadable.
Chapter Three deals with Audio Accessibility, which could be for those who are deaf or seriously hearing impaired.
Chapter Four focuses on physical disabilities, and alternative ways to navigate around the page.
Chapter Five deals with a variety of Cognitive Disabilities, including Dyslexia and ADD/ADHD, and how a variety of formatting options can make working with these individuals easier.
Chapter Six is about Selling accessibility to the organization.
Chapter Seven is for Additional Resources to help get the most out of developing for accessibility, including resources for information, for testing, for design, and about the various tools available for them.
Bottom Line: This is a thin book, coming in at 98 pages total, 80 pages of specific content, but don’t let its size fool you. This book will pay for itself with the first usability issues you find. As you get better, you will be tempted to start creating unique personas for each of the areas, and by all means, do so. The process of seeing how solutions are presented, and how to make changes to those solutions, is well worth the purchase price.