Category Archives: soft skills

Perry Mason and Assumptions

That’s twice!  Twice this week my assumptions caused a bit of trouble.  Last Saturday, I placed an order for parts.  They are not expensive but I’m careful about my selections and want to verify multiple times that I have the right parts.  On Saturday, I was confident in my selections and I placed the order.

On Sunday, I performed a test with a voltage regulator.  By design, voltage goes in and exactly 3.3 volts comes out.   I connected my 3.7 volt battery to the input and found 2.9 volts at the output.  My assumption was the battery voltage was greater than the output (that is, 3.7 > 3.3) so the regulator should work.  I didn’t have the right parts.  Fortunately, I was able to remedy this assumption by amending my order.

Today, I was updating a Java program.  I needed a string representation of date and time so I used the SimpleDateFormat object to create the representation.  I handed the format() method a Calendar object and started the program.  I was not getting the expected result.  Ignoring sarcastic little voices, I reviewed my changes and added some logging.  The voices were correct; it was the format() method.  My assumption was I needed only to provide the method a Calendar object.  It needed a DateTime object.  Fortunately, I was able to remedy this assumption.

Assumptions are sneaky.  Sometimes we know about them and discuss them, other times they drift in like a slow forming fog.  You don’t know its there but you discern some challenge.  It’s too subtle to change a direction but you’re cognizant of it.

I have many example of this experience through my recent Earl Stanley Gardner binge reading.  Gardner brought us Perry Mason.  If you are aware of Perry Mason only as a TV series, I strongly recommend the books.  They are engaging, humorous, and full of clues.  There are strong analogs to story cards.  When a story card goes awry, check assumptions and check the story.  One or two facts get misaligned and a defect is created.  Gardner weaves multiple facts and multiple explanations for facts.  It the end, Perry Mason, in the role of tester, fights through the fog of assumption, illuminates small details, and finds the one true story to exonerate his client.

As a tester, you will benefit greatly by having your assumptions dashed, and attention to detail challenged.  This week, two assumptions caused some delay in executing my hobby.  What assumptions might we be making that could cause a delay in our projects?

 

Advertisements

Lead Testers and Lead Testing

As I exit a project with disappointing results for me personally, I’m motivated to re-invent my role by combining select experiences from past projects.  At the start of my next project, my conversation with project team members might take on this flavor.

My role as test lead is to facilitate testing, advocate for smart testing, and to guide testing within our project.  Developers may create and execute unit tests, and analysts may evaluate product definitions; both are testing activities.  I encourage them to collaborate early with project testers for feedback, to augment the testing, and to identify automation opportunities.  The goal is not a fully tested product; the goal is verifying business behavior that delivers value at a rapid pace.

I go into the project with a position of achieving 100% automation.  I’m not advocating for 100% rather I’m setting a goal of 100%.  I want to use automation to demonstrate behavior not just after a product is complete, but frequently as we make changes to the product.  I want our automation to provide confidence to our team so they can continue to add functionality, explore different implementations, optimize the product for performance, and verify we still deliver business value.

I will foster a sense of community as we explore the details of the design.  Together, I want to create definitions of our products that we can build and evaluate quickly, products that we are proud to demonstrate, value that distinguishes us in the marketplace.  As equals at the drawing board, I want our team to collaborate, to challenge, and to bring their diverse talents for a common purpose.

Our project will likely required services and integration with other parts of our enterprise.  I want to meet with them soon, share our story and engage their team to assist us.  I believe a proactive approach helps them prepare better, makes them more willing to participate, and contributes to our mutual success.

The Shift Left
The role of Test Lead is no longer confined to leading a team of testers, it must lead all testing within the project.  With “Shift Left” continuing to gain momentum, the Test Lead’s focus and responsibility grows to guide the testing of the project such that product definitions are clear, small bits of code are exercised, and value is demonstrated.  Success will depend more on your ability to support team building and encourage effective collaboration than testing or technical skill.

The Power of “I don’t know”

My teammate, an experienced and wise System Architect, related an experience from a meeting where they reviewed and discussed processes.  He provided feedback along with everyone else.  When they read back everyone’s contribution, his was missing or skipped.  He asked about it and they assured him his feedback was included.
When the facilitator emailed the minutes of the meeting to the group, he found that she placed his suggestions under the “Other” category.  Mildly frustrated, he responded simply “Sounds good”.  A few minutes later, the facilitator wrote back.  She said she recalled some of his comments but they were a little technical for her.  She was hoping he might provide more detail through email.  In other words, she didn’t understand what he said during the meeting, and did not feel comfortable enough to ask for clarification.

When I hear things like this, I get frustrated, and then motivated.  In this case, I was motivated to encourage people to express “I don’t know” more often.

6OctTweet

I was overwhelmed and humbled at the response – thank you!

I want to encourage you again.  When you aren’t following along with a concept, or have trouble grasping an idea, or the language is unfamiliar, you have two opportunities: explore the limits of your fear, and help others who may be experiencing the same.

Form your response clearly in your mind, politely request the speaker’s attention, and say it: “I didn’t follow…”, or “I don’t understand how…”, or “I’m unfamiliar with some of those words, would you…”.  Make it clear that you “don’t know”, and that you really want to know!

The Flip Side
If you are the speaker and a participant in the meeting, the lecture, or the conference presentation bravely confronts their fear with strength and humility, you have, in my opinion, an obligation and an opportunity to engage them fully.  Welcome their comment as you would feedback from a peer for that is what it is.
Neither of you is uniformed/lost/dumb; both of you want to communicate and understand because you both found value in some expressed idea.  Messages between people are garbled for a variety of reasons.

“Thank you for your honesty”, I would start.  “Where might we begin again?”