I realized the other day that I’ve been involved with something for years that I’ve failed to mention here. Since 2011 I’ve hosted an evening show at CAST where I interview interesting testers as part of AST’s conference live-stream.
If you didn’t know about it or haven’t had a chance to check it out please do.
I will be at the helm again this year running the livestream for CAST 2014. It’s totally free and worth checking out! I’ll also be hosting an evening show called “CAST Live” on the 12th and 13th at the end of the conference day.
Reminder: Have twitter open while you are watching so you can ask questions of the speakers via the tweet printer.
A few weeks ago a writer for Dice.com approached me about interviewing testers. She was doing a series centered around interview questions for technical positions; good responses, bad responses, and rational. I’ve written about interviewing and been part of panel discussions before (Part I, Part II) so I was honored to have the opportunity to chat with her about interviewing. Check it out and comment if you feel compelled.
“Interview Questions for Novice Software Testers” – Dice.com
A while back I created a software testing patch. While I never had it made I thought it was still worth sharing.
The eye is for observation, the lightning bolt is for action, the day is knowledge, the night is the unknown, the square waves are software, and the banner reads “Light From Darkness.”
Tirelessly I shall defend my craft as cognitively complex, empirical, and scientific.
Energetically I will meet each challenge set before me. For each challenge allows me to stretch my abilities which makes me a stronger, more skilled tester.
Stakeholders shall be the cornerstone of my existence, and I shall strive to provide quality-related information in a timely manner.
Thoughtfully I will design and execute my testing, keeping context at the forefront of my mind.
Education shall be my lifeblood. I will strive to improve my knowledge and skills so I can better my craft.
Readily I will display my passion for testing while remaining ethical, and technically competent.
Frequently throughout my career I’ve had people say to me “we should test like company X” or “lets do technique Y here because it worked for person Z there.”
On this surface this seems like a good idea, just follow the path blazed by others because it leads to success, right? However I’ve learned that replicating someone else’s approach or methods has rarely lead to success. Usually the opposite, it leads to failure. That’s because no two people, companies, or situations are the same.
So instead of testing like company X or person Z study how they test, ask lots of questions, and experiment with the things you think might be useful in your company and on your projects. Don’t just replicate what others are doing and assume that what they are doing has to be better than what you are doing. Strive to be your own leader instead of seeking out people or companies to follow.
Fair warning, if you do decide to replicate someone else you may end up replicating all their mistakes and none of their successes.
As a tester, I provide a service to the projects I work on. I help my stakeholders (developers, project managers, customers) by gathering important information about the product and reporting it. Often this information isn’t positive because I am highlighting things that could reduce the value of the product. Even so typically my work is perceived as a benefit to the project; however at times that perception can flip to one of hindrance.
This is especially true when time is short and pressure is high. When this happens my stakeholders can move from cooperation to contempt. Suddenly the information I’m providing is no longer welcomed, which makes for an interesting dilemma. If my feedback is no longer welcomed am I still providing a valuable service to my stakeholders and this project? If it isn’t welcomed should I still provide it? How do I get back to being seen as benefit and re-inspire cooperation?
Over the years I’ve found that there is a very fine line between cooperation and contempt during stressful times and I’ve struggled with this. On one hand I’m tasked with discovering important information but on the other hand the project is horribly delayed and each new thing I find jeopardizes shipping the product on time.
Regardless the climate we testers have a responsibility to highlight both good and not so good information about the product. We should strive for cooperation but we must be ready to steer around contempt. We must avoid the temptation of withholding or not seeking out information about the software because regardless the state of the project the information we discover is still valuable. In the end we need to stay focused on whats important which is information gathering and realize that stressful times are often short lived.
While our stakeholders may not be happy with what they are hearing now they are often far less happy hearing it from the field later.
When I was a kid a army soldier told me, “you are only as strong as your weakest man.”
Recently I was reflecting on this statement in the context of software test teams and planning. I recognize that each member on a test team has a unique skill-set. When I lead teams I try to discover not only what each member is good at (strength) but also what they are not good at (weakness).
During project planning I consider these strengths and weaknesses and try to determine the effect they might have on our testing mission. While strengths are good I’ve found that I tend to pay special attention to each team member’s weaknesses. An individual weakness can translate into a limitation for the entire team which could lead to a failure of the mission. That failure would be due to me over committing the team, functionally setting them up to fail. I try to build my plans around individual limitations and discover paths for success. If I can’t find a path for success then I need to make my stakeholders aware of these limitations and let them know that I’m concerned about whether we can succeed in a given mission as stated.
Like most things it taken a fair amount of time to develop this ability. At times I struggle with it, I think most leaders do but I recognize that this is something my team(s) needs me to be good at. Ultimately they want to succeed and they don’t need me setting them up for failure by ignoring our limitations and weaknesses. Beyond that my stakeholders don’t want any surprises and expect that if we can’t accomplish the mission’s goals then they will know sooner rather than later. So the better I am at this the better we are overall.
So I’ve found that being aware individual weaknesses and planning around it is an interesting way to build team strength. The stronger we are as a team the stronger we are as a company.
Periodically I gain insight or inspiration from studying unrelated areas or industries, this was the case when I was struck by the similarities between testing and cooking. On the surface they seem drastically different but as you dig deeper you start to see the similarities.
The most basic type of cooking involves following recipes. These recipes are typically created by someone else and offer not only the items needed to create the entree, but also step-by-step instructions. The ingredients and steps working together will, in theory, create the perfect replication of the dish. But many of us know that even after following the recipe to the letter things don’t always turn out so perfectly. You can accidentally over or under cook the meal because of variations with your stove. The instructions could make assumptions about your level of knowledge or terminologies (simmer being my favorite) that cause the dish to not turn out correctly. Or you may find that even after making the dish its not really what you had hoped it would be, sounded better on paper.
As a tester I hear these things and immediately think of scripts and test cases. These sorts of “tests” (checks) are usually made by someone else and outline the prerequisites for the test, the steps to be followed, and if all goes well you get the “expected results.” But this method has the same problems as a recipe. Your setup may not exactly match, or you may misunderstand a term, or worse you could expend all this time and effort and the test(s) aren’t as good as they seemed on paper.
Taking this analogy further lets consider the difference between a cook and a chef. A cook follows a recipe created by someone else, usually a head chef. He rarely, A cooks job is to recreate the same exact entree consistently, over and over again. Whereas a chef is looking for new an interesting culinary experiences, they won’t settle for the same thing over and over again. A chef not only needs to understand the science of food but also the aesthetics, and they must be highly creative. Chefs understand that repeating the same thing over and over again numbs the palette and doesn’t advance their craft. To this end a chef is constantly looking for the next new food combination. They are often sought out not for what they have done in the past but what they can do in the future.
Here again as a tester I see parallels, in this case “checkers” versus” testers.” A checker is someone who performs scripts that someone else created with the intention of consistently repeating the test(s) looking for the excepted results. But here is where things get interesting, in software testing often we aren’t looking for the same thing over and over again, we need to find something new. This is where a tester steps in. A tester, not unlike a chef, understands there is little value in doing the same things over and over again. A tester also has a high level of skill and must be knowledgeable in their craft. They often aren’t satisfied with the work they’ve done in the past and are looking for new an interesting testing opportunities. Testers are often sought out not for what they have done in the past but what they can do in the future.
So are you a cook (checker) or a chef (tester)?
My father, whom I’m very proud of, was a firefighter and EMT for most of his working career. In firefighting when you arrive on scene you need to quickly assess whether there are victims or occupants in the structure that need rescue. The first step and most important duty of the responding firemen is to perform a “Primary Search” of the structure. This search is typically a wide sweep of the structure but more often than not doesn’t include the entire structure.
Take a look at this article about the challenges of a Primary Search: Conducting a Primary Search
This really caught my attention because this is similar what I face as a tester on a daily basis. Granted what I’m dealing with is not life or death but the environment is equally uncertain. As testers we can’t go everywhere in the software looking for problems. As testers we must learn how to quickly assess whats important, and recognize that each situation is different. Frequently I find that what worked last time won’t work this time, which means I must be cognizant of my context as it changes and switches.
Just as each fire scene is unique, each application, project, build, and request is unique. Like firemen we need to know how to do a Primary Search of our software knowing that it might be different each time. Project to project, week to week, day to day, we need to be flexible and willing to change our approach.
Ultimately there is no one right way to do this search , but search we must. Embrace your changing context and change with it.
Benjamin Yaroch's Blog 