22 Wednesday Jun 2011
Posted in Experiments, Publications, Tea-time With Testers
In the June 2011 current issue, Tea-time with Testers has published an article I wrote as an expansion on my Esprit de Corps post.
Please contact me with any feedback. Thanks!
15 Wednesday Jun 2011
Posted in Certification, ISTQB, Training
Since I still hold the first job I obtained after college graduation, my training as a tester has been practical, sometimes specific to my circumstances. While this makes me very good at my work, I always feel that I could be better. Perhaps to satisfy that perfectionist urge, over the years I sought different ways to improve myself. One strategy that never fails me is certification. I know that some testers seek certification as a means to fulfill job description requirements or “level up” at their companies, but my situation is distinct. You see, I am a nerd. I love learning, sometimes for its own sake. Back in the day, I would have happily engaged you in conversation about tuple calculus or graph theory, but now testing software is clearly my calling and I want to be the ultimate quality engineer. I don’t feel compelled to compete with anyone else for this distinction; it is purely a competition against myself to see whether I have plateaued or can continue to improve. For this reason, I love certification as a chance to objectively measure my progress.
“I do not think it means what you think it means.” – Inigo Montoya, The Princess Bride
Both times I completed a certification class and the subsequent exam, I returned to work “fired up” for the next big push. Since my training has been largely on-the-job, I did not make distinctions between certain testing terms that my more experienced co-workers did not emphasize. Having exposure to industry standard definitions helps me to clarify problems. In addition, the precision appeals to me as a theory nerd. With the goal of establishing a common language within my testing team, I introduced some of the things I had learned and accepted the group’s idiomatic usage as well. After all, communicating with my testing team and my development teams is the most immediate and effective use of my book learning. I found the rigor and structure of the courses helpful. I did not take these courses expecting to learn the One True Way of Software Testing. I wanted to expand my horizons to include other approaches and viewpoints. Did the certification courses make me a better tester? Yes, they did. They renewed my passion for my work. Formal training increased my confidence in my understanding of the software testing field. I brought back insights about areas for our improvement and I think we are a better department for having this input. Did I need to use a certification course to accomplish this goal? Certainly not. I don’t think that all testers need to be certified. I could have completed self-study through textbooks, websites, blogs, and industry contacts. I suppose that is similar to the perspective of recent news articles declaring college to be a waste of time. For me, the formality and structure of training classes and the certification process help to reinforce learning, which may not be true for everyone. A friend recently posted thisto his blog:
There’s got to be a structure around the knowledge, and practice in applying it, for it to sink in. College works good for that. … Nowadays, I learn by reading textbooks on my own. And it’s harder, because I need to bring my own structure, motivation, and discipline.
As long as we continue to improve our testing skills, remain open to new possibilities, and continue to investigate pressing questions about the quality of our software, we can congratulate ourselves on being certifiable testing zealots, whether we are certified or not. Image credit
01 Wednesday Jun 2011
Posted in Training
Took the fam to see Kung Fu Panda 2 today. Traditional film can only support about 30 min of 3D, so seeing a whole movie in digital 3D for the first time was pretty cool. I loved it. Also, children have no inhibitions about talking through movies in the theatre. Fun times.
Every hero has an origin story. My favorite superhero is Batman. He overcame loss and through sheer determination – and a family fortune to buy some cool toys – turned it around to watch out for others, guarding them against the vicissitudes of the world, specifically the criminal underworld. Of course, I see Po’s origin story as an echo of Batman’s, but I’ll refrain from ruining it for my son.
Recently, some tester friends were discussing the nature of heroism on Twitter, including how it pertains to testing software. I’ve heard the word hero used with two completely different connotations in this context:
No doubt we are all familiar with work situations that embody the first definition of heroism. Inevitably, the needs of customers dictate swift resolutions to problems that require an extra effort from staff members, including software testers. We manage the current crisis, wipe our brows, and return to our regular work schedule. We don’t want to cultivate situations that necessitate this kind of deliverance: constantly fighting fires is a sign that we aren’t preventing the fires in the first place.
While admirable, accepting – or even taking initiative to seek – tough assignments may not accomplish our goals in a sustainable way. The champion who constantly faces down dangers may not be taking care to restore strength between bouts and can become burnt out. Although Sisyphus could be viewed as an absurdist hero, this is not heroism I choose to imitate. In addition, an environment with one superstar can actually prevent others on the team from cultivating their own courageous abilities. We need to take turns wrestling with the big problems so that we all become more capable, which might mean a less glamorous sacrifice such as familiar regression testing – though we could even take this opportunity to improve this routine material with the knowledge gained since our last encounter.
Then again, when we have individuals with heroic talent, do we want to spend it on tasks that do not require such skills? We must avoid the Harrison Bergeron solution of bringing heavyweights back to the average level. Would the group be better served accomplishing the routine tasks in a more efficient way, such as automation, and devoting able testers to the remaining unaddressed challenges? We want our testing staff to take initiative to seek knowledge in resolving tough problems so that when software crises occur our testers are prepared to face the present trials. Constantly improving our testing skills offers clear benefits to our team in an hour of decision. Our goal should be “building a fighting force of extraordinary magnitude,” where our metric is one of ability, that develops each person’s heroism.
Preventing the formation of heroes would not tamp out circumstances that call for heroics. Why do we create or foster circumstances that routinely demand a hero to set things right? Let’s not be Lois Lane, living for the moment of rescue to admire the Superman who has saved us. We need to stop tying the lady to the tracks, to stop distressing the damsel, and to free up our heroes for the real fight, facing external threats rather than internal ones. While the value of heroism is under discussion, the real topic of conversation should be why heroism is necessary.
