The real "A Tale of Two Testers"

Lanette commented on my last post with a link to her original post. 

I guess I subconsciously swiped the title -- I thought the title came to me a few seconds sooner than most titles for my posts, so I googled the title plus either Lanette's name or username just in case that was the actual title of the original post but nothing appeared in the search results.  I was satisfied that I was just stealing the title from Dickens and hit the Publish button. 

I was glad to read the original again; it was posted just over six years ago and it has affected so many interactions with my coworkers. 

New Title! Now without subconscious plagiarism!

UPDATE:  Lanette shared a link to the original blog post! 

It was at least five years ago.  I read a post by blogger and all-around testing guru Lanette Creamer.  It has stuck with me.  I don't remember enough keywords to track it down but the gist of it was to imagine two testers, with let's say, way more work than they can reasonably do by a deadline.

One gets overwhelmed, frazzled, and angry. He works late hours and weekends, sighing about it the whole time, not helping out others with their questions, sleepily and grumpily doing the work he perceives is expected of him.

The other is calmer and remembers he's a member of a team.  He does solid work and puts in some extra hours but not so many that he loses passion and focus. He is available to help a new tester become better.  He gives updates on what he has done, and what concerns about risk remain.

And it had a "which one would you rather work with?" type of question posed at the end.

Whenever I get an extra task on top of my already-packed task list and my first instinct is to burn myself out to the point that I snap at people who dare stop by my desk with a question, I remind myself that I'd prefer to be the second tester.

Lean In....To Your Confusion

Today, I sent an email containing a list of all the things I'm unsure about.

Well, the things I'm unsure about for one particular work project anyway.

It's my job to ask potentially stupid questions. To expose myself as a fraud who has no business touching a computer.

I ask them anyway.

Because I've learned that sometimes when you ask a "stupid" question, you get two different answers, which surfaces some assumptions that hadn't yet been verbalized.

Sometimes you spark a conversation because they hadn't yet thought through the scenario you asked about. 

 (Image Credit: Charles Hutchins)

Sometimes you get an answer that's over your head but you can make a list of things to Google later so that you have a deeper understanding from which to ask future questions.

My understanding of a project builds itself like an imaginary house, and over the years I've built many imaginary houses.  My comfort level is high once I start seeing walls and a roof.  But sometimes I feel a tickle in my brain that's something like "Hmm, I didn't see a bathroom in this house yet.  I need to verify that we have a toilet.  Because that's kind of a big deal"

Trust the tickle in your brain.  It could be intuition taking the form of confusion.  And if it's not, your temporary feelings of embarrassment will help fertilize the ground from which your intuition grows.

(PS - I recall James Bach saying ideas of this sort in a YouTube video but I don't recall which one; hopefully my thoughts are more "inspired by" than "stolen from")

James Bach on providing meaningful, honest time estimates

Truthful Estimations by James Bach, ThinkTest 2015.  I couldn't believe this video only had 142 views!

Takeaway nuggets: 

• Testing closes the gap between what we know about the product and what we NEED to know about the product.  The riskier the product, the more we need to know.   Testing is like using headlights when driving at night.
• To be useful, estimates must be accurate and precise.  Don't lie, just give updates as more is known.  If you have to give an estimate, give three estimates to give customer an idea of the trade-offs involved.
• Low end, happy path, customer ends up assuming a lot of risk
• Conservative, test usability and all permutations of risk such as security
• Middle ground
• To the estimates, you need to add a public buffer that attempts to account for unpredictability.  The buffer can be estimated by looking at similar past projects and knowing what unexpected things happened so that you can do a better job of expecting them this time.  This requires an honest look at how we actually spend our days as opposed to how we ideally spend our days under perfect conditions.
• Reasons for unpredictability: 
• "Blocking unknowns" -- If there's a dependency of unknown length or complexity, you cannot estimate an end date for your work. Examples include setup of test environments or finalizing what the product is going to be.
• Finding bugs -- Estimates can be skewed by assuming everything will go smoothly.  In reality, there is a lot of time investigating, diagnosing, explaining, waiting, and retesting.
• Overestimation of time spent working on testing-related tasks.  One example is "team self-care", which on the surface look like people standing around talking about pleasantries but is a long term builder of trust and productivity. 

"You Can't Build a Reputation on What You're Going to Do" - Henry Ford

My previous post annoys me now, because in two places I mention plans. 

The first one - bullet point Weinberg's Perfect Software and Other Illusions About Testing, I'm not going to do.  Why?  Because anyone who is interested in the subject matter should just read it. What I actually did was take an excerpt outlining reasons to involve testers in technical meetings and shared it on an internal Confluence page at work.  This was the most useful passage to me as we move toward more agility in our development process, and it was nice to have an external authority to back up what I could only express before as intuition.

The second one - prepping a talk to submit for next year's Tulsa Tech Fest or wherever else it might be useful - it's on my perpetual to-do list now. 

Perpetual to-do list? It's my variation of structured procrastination.

Summary:

• I have a list of tasks in Google tasks, all with deadlines.  
• Some are one-time tasks, like "Call somebody to remove the ugly, buggy, weed-like tree in front yard"
• Some are weekly or monthly or every six months, like giving the dogs their pills or paying auto insurance bills
• Some are just big ongoing tasks, like "Clean the garage".  These have "deadlines" but if I don't accomplish anything by the deadline, I just move the deadline back. 

So as an example, I'm looking at my unfinished list from yesterday.  The first one is "write a blog" -- It looked to be the most interesting thing near the top of my list, far above "Cleaning floor in hall bathroom", so here we are.  I pushed that task to next week.  If cleaning the floor were more urgent, like if my mom were visiting this weekend, I'd feel more inclined to do it now instead of pushing it back.

So back to my talk -- It's there on my list now.  It's not that I'll sit down and prep a talk in one session.  I'll just make some kind of measurable progress when the mood strikes.  Which will likely be when I've just read some interesting material I want to add, and my other choices are "Clean the garage" and "change the unreachable light bulb"

It does require discipline to actually *work* on the to-do list. It's not going to solve the "I can't get anything done because I'm binge-watching Netflix" problems.  But I've found that actually having a system instead of being overwhelmed at the million things I haven't done is helpful to getting a thousand meaningful things done instead of zero.

Goodbye July: 30 Days of Testing Challenge over :-(

Even though I didn't complete every day of the 30 Day Testing Challenge, it was still enjoyable and thought-provoking. I loved seeing so much passion, creativity, and humor in my blog feed every day.  Keep it up!  Thanks to Rosie Sherry and the Ministry of Testing for bringing all of us software testers together.

I finished Perfect Software: And Other Illusions about Testing by Gerry Weinberg right before falling asleep last night.  I gave it five stars (out of five) on Goodreads. I'll go through it one more time to take down some of my favorite bullet points for discussion.

This Friday is Tulsa TechFest.  There are two empty slots for QA/Testing.  The empty slots have been in the back of my mind, haunting me, beckoning to me.  Getting a talk ready by Friday would probably raise my blood pressure to an explosive level....but it has prompted me to put together a Google doc where I can compile and cite material to have ready to go for opportunities like this in the future.  This is more exciting to me than scary, so I have apparently flipped a confidence switch in the past month or two. Yay personal and professional growth!