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.


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?”

The Most Important IT Skill

My wife and I attended Curriculum Night at the high school where our boys attend.  It had already been a busy week (and frustrating one if you count the removal of a poorly designed kitchen faucet).  But Curriculum Night is something I have enjoyed for many years and would not consider missing it!

My son is enrolled in AP Programming so I was very curious about the curriculum AND the teacher.  I was impressed with the cognitive level of assignments he had last year, and this AP course had my expectations high.  I sat through informative yet similar sounding sessions on Pre-Calc, English, and Physics before hearing about the AP Programming course.

When I arrived for the session on AP Programming, the teacher greeted me with a hardy handshake, an excited “Welcome!”, and invited me to sit where my son usually sits.  He was animated and nerdy (cool).  He had spent ten years in the industry before deciding to teach (nice).

He started talking about the curriculum, noted the students receive one new programming concept per week (they are working on arrays this week), and finished with how their work is evaluated.  My interest grew.

Students are expected to review each others’ work, note the differences between the implementations, and they are invited to speak in front of the class about their discoveries.  The teacher stated the ability to communicate was as important as learning how to write programs!

I was elated.  An experience in collaboration and empathy respectfully facilitated by the students is a great IT lesson.  In my journey through my testing career, I discovered that, as a Test Lead or Tester, testing is a very social activity.  The ability to convey and negotiate ideas, collaborate with multiple personalities, and develop a working team has been as rewarding as writing programs and tests.  Getting that experience in high school is like preventing defects early in the project!

Testing is not for the Shy

I recently joined the Test Design Exploration team.  This is one of many groups within our enterprise available to mentor testers.  Our charter is to explore test design techniques, provide opportunities to use them, and discuss how techniques might be used in projects.  We establish a schedule of test design topics and testers sign up to attend sessions.  For example, we’ll be exploring All Pairs in an upcoming session.

Our team has been meeting regularly to prepare the sessions and set up a schedule.  I like our group – they are very experienced and bring some fresh ideas to our topics.  Recently, we provided a status update and some clarifications around our scheduled start date.  With the business complete, someone suggested that our team create a SharePoint site where testers might ask questions of our team should they be to shy to ask during a session. I liked the idea of having a place to follow up from our sessions.  Accessible to everyone, it makes our team more transparent, and I think we are willing to support it.  What stuck with me was the description of a tester to shy to ask a question.

When I started as a developer in this organization a while back, the fact that there was a whole group of people dedicated to testing was new to me.  I thought it was pretty cool!  But I rarely saw them during a project and heard from them even less.  When I moved to a testing job family, I tended to be very vocal.  Actually, it might have been called pushy or obnoxious.  But with a lot of feedback and practice, I found a testing voice that is more collaborative.  I also learned that testing demands more of a presence from a tester. I suggested to my test design teammates that we should encourage testers to ask questions.  The sessions are a safe place to do this, asking questions in a group gives them great practice and confidence, and maybe we can deliver more than test design mentoring.  They all agreed.

Testing is not for the shy.  There are developers that will push you around with very technical language, dispute defects, question the credibility of your tests, or just ignore you.  There are project managers that will pressure you to reduce testing.  In my opinion, this is not the identity of a tester.  Take back your identity!

You are a tester and quite capable of

  • Learning C#, Java, or any other language
  • Defending your defects both at a technical level and, more importantly, at a business level
  • Establishing credibility through early collaboration and shared goals
  • Being a contributing member of any project team
  • Expressing the risks of reduced testing

I’m looking forward to exploring test design with testers in my organization.  But I think they can learn more by asking questions in the sessions or anywhere they go.  The bigger challenge for me is encouraging them to believe in their capabilities, and to have them respectfully act on the behalf of the quality in the products they evaluate.

My Holiday Binge

I confess.  During the holidays, I binged.  Not only did I binge, I ignored some work required for an upcoming presentation, I didn’t write or blog, I didn’t shave, and I didn’t get regular meals for almost four days.  As you might have guessed, I was profoundly indulgent in writing and testing software.

I know what you’re thinking.  I could have said no, I could have more self control, I could have asked for help.  But I saw my new laptop sitting there, Visual Studio Community Edition 2013 looking sleek and installed and all, and an engaging hobby project at the ready.  “I’ll try just a few experiments for feasibility”, I told myself.  “It won’t take long.”

I created my first project and successfully embedded Google Maps on the web page.  “Wow”, I thought, “this is easier than I thought.”  I opened another project to explore the use of a web service for retrieving data I could place on my map.  All I had to do was port some code I already had (no one would know and I would save time).

I copied the code into my web service project and gave it a try.  Working.  I added more code to accommodate the web service and gave it a try.  Working.  I needed more, these small successes are great.  More is good, right?  After a few iterations of coding and testing, it was working well enough to integrate with the first project.  “This is going pretty well – why stop now since I’m so close?”

I had my web site call the web service.  Error.  I Googled the error and found a feasible resolution.  A small success.  More, I need more.  I added a secure call, a database connection, and some simple UI interaction.  Working.

A welcome development buzz was setting in.  After weeks of thinking about this project, planning its construction, designing an interface, the pent up creativity was released.  The cycles of build and test fueled my desire to continue and laser-focused my attention.  The total design was becoming clear and I had to pursue it.

I had enough code working that I could deploy to my website.  “This was it!”, I realized, “I would see my dream a reality.”  I elevated all the files and navigated to the page with the map.  I entered my information and submitted it.  I had such anticipation to see the data on the map.

The failure was frustrating.  My ISP did not allow web services on shared accounts.  I should have known but I didn’t care. I was already considering alternative solutions.  Somewhere through my thoughts, I recalled the Raspberry Pi my son had.  “You could run a website on it, Dad,” echoed in my head.

I investigated the Pi and ordered my own.  “I can experiment with his – he won’t miss it.”  Suddenly, I was working, most clumsily I might add, in Linux (download a TTY application; I tested and coded).  The web service could be written in Java (download an editor; I coded and tested).  It had to be deployed through something called Tomcat (install on the Pi; I coded.  I tested.).  The database (pant, pant), I need a database (install MySQL on the Pi; I tested.  I coded.).

In the quiet twilight of a Sunday afternoon and with the benefit of my favorite (caffeinated) tea, I navigated to the page with the map.  I entered my information and submitted it.  In the brief milliseconds awaiting a response, the world was still and my eyes focused on a blinking cursor.  With the innate agility of a cat, the browser displayed my data on the map.  The final code/test/deploy cycle was successful and I was breathless.  I sat there looking at the map and my data.  “Wow!”, I whispered to only our cat.

I started programming as a product engineer and moved into IT 15 years ago.  The joy in my programming has often been matched or exceeded by testing my code.  The initial creative impulse coupled with the quick feedback of a running program makes for some long and satisfying weekend afternoons.
If you code, I encourage you to test.  There is certainly a very satisfying quality in implementing business requirements in short, organized, syntactically appealing and patterned phrases.  But, like music, the real beauty is in when code plays and plays well.

My Testing Platform – One Year Retrospecitve

In a previous post (opens in a new tab), I declared a Testing Platform and an intent to review it one year hence.   Since that post, I completed one project and started another.  In my new project, I am working with new people and on a different platform.
In a somewhat agile fashion, I offer my retrospective on what has gone well, and where I might improve.  My perspective is from my role as Test Lead.

Testing Purpose
During the first part of the year, we loosely pursued a testing purpose in our tests.  With the start of a new phase of the project and the addition of more testers, I request the tester describe an information objective for their assigned story cards.  Not every tester on my team has attended BBST Foundations so I mentor them in this concept.
I believe this helps frame the testing effort however we’re just a few iterations into the phase.  I don’t have enough information to determine if my team has seen benefit from describing a testing objective so I plan to be diligent.

I started using more automated unit tests for my home programming projects and experimented with creating an MVC-based website.  I feel the exposure to both of these technologies keeps my programming and testing skills sharp.  They provide a perspective I can use in testing and a foundation for interacting with developers.
As a Test Lead, thinking is still very valuable.  I frequently offer thoughts and impressions on implementation ideas, on testability, on maintenance, or on people.  In my experience, a Test Lead is part of the core team guiding the project, and should offer a testing perspective on many project aspects.
Lastly, I benefit from participating in this community.  Both blogs and books offer perspectives, ideas, and experience that I find useful.  I think I can do better in offering the same, and encourage other testers to participate as well.

Early in the project, I established good credibility with the core project team.  I engaged them in conversations about their experience and background, project objectives, and testing.
I find that conversations about testing are more of continuous journey to help others understand testing value.  Just when I think everyone is on the same page, the testing team suffers some small, unintended slight, and my journey begins again.
Everyone agrees that testing is required, but they soon forget the conversation.  While this is often frustrating, perseverance without arrogance, I believe, helps the testing team and the project.
To date, I must say my project team is one of the more considerate of testing, understanding of its benefits, and engaging in quality as a team sport than I usually experience.

Over the course of the project, I provided alternative opinions to bring clarity to a few requirements however, assisting with the direction of our project was the most rewarding.  I suggested a path of more learning which could result in a shorter final testing cycle.  A faster delivery often appeals to project managers however I believe a few of my tenets in this platform assisted in his decision to use my suggestion.
Early in the first phase of our project, I did a poor job of communication.  I made assumptions about a few tasks, actions, and ideas.  I failed to realize that I was working with new people.  They did not understand me as well as those on my previous project (where we had worked together for two years).  I made a post-it note to ask myself if I am making an assumption which assisted in clarifying my emails and preparing for conversations.  I learned that I should not get to comfortable in language, words, and conversations for these may be as context-driven as my next test.

My conversations advocating testability have grown into collaborations on how to make products testable.  Additionally, I encourage my testers to discuss testability with developers, and our design reviews include a review on testability.  In my opinion, succeeding in improving testability one project at a time is good; when my testers join new projects, I hope they spread the word.
In a new project I find that, in addition to introducing the idea of testability, I must also convey my thoughts on what testability means to me.  While it may sound like a simple concept, offering your thoughts to testers or developers will generate a good conversation, and everyone lands on a working definition for the project.

My experiment in estimates includes factors that impact testing work: environment stability and availability, developer testing, defect density, and product familiarity.  I use these to adjust a base estimate (e.g., a large defect density increases the estimate) and then apply a confidence factor.  I also set the expectation that I would change my estimate as I learn more about the products and project.
Again, I don’t have enough iterations to draw conclusions on this approach.

I’ve been experimenting with wireless technology for some embedded development, and researching motors and controllers for some ideas around robotics.  While each has unique challenges in testing, neither is associated with the testing I perform for my employer.  However, I often find the defocus valuable and, serendipitously, occasionally useful.

During the first phase of my current project, I found no opportunity to use automated testing.  The implementation was not complex so I could not justify the cost.
In our second phase, the implementation is more complex and has a few opportunities for automation.  Specifically, I expect to extend a tester’s reach by providing them the ability to explore product behaviors with a greater diversity of data combinations, and an opportunity to review more data in a shorter amount of time.

While the feedback I receive on collaboration has been good, I was elated to hear that our business sponsor would like to know more about what we test and how we test.  I look forward to sharing more than a report or a defect.  I hope to share testing stories and help them understand the impact to the products we create.

How was testing for you in the last year?


YOU Can Improve Testing in Your Enterprise

Can a single blog post describe how to make a change in your enterprise?  Maybe! If you came this far, then I believe you can be the catalyst.

You know your organization needs a change.  It’s a nagging awareness that things could be better, or an annoying realization that other companies are doing it better, or dream-like world where testing is integral to the project, part of a team, part of a solution.

Am I the Only One Who Knows?
Perhaps you’re asking, “Is it just me that knows?  Do others know?”  Maybe – but think about the conversations at lunch, in the hallways, at happy hour – has anyone ever vented about testing?  Perhaps someone was subtly dismissed by another team member, or another felt they let a project down in not testing enough.  In all the venting, has anyone said, “It can be different”?

Maybe you can say it.  Maybe you have said it at happy hour.  It might have felt as if you just said y’all gonna climb Mt Everest.  Some look at their drink, some take a drink, and some review jukebox selections.  Then, everyone went back to work the next week.

You Were Right
When you said, “It can be different”, you were right.  You were also suggesting everyone climb Mt Everest.  Making a change in an enterprise is an uphill climb, requires a dedicated team, must demonstrate benefit, and must demonstrate repeatability by anyone.  So, you should start today.

Even the first step towards a lofty summit begins with some small action, some small preparation.  You know you want something different, but what does different really mean?  It might mean more respect for some, more time for testing for another.  That small action could be to identify what could be different.  Make a list and look for themes.

Your Opportunity
Does your list suggest better team dynamics?  More test planning?  Support for training?

Two questions:

  1. Can you prioritize the list based on value to your testing?
  2. Does anything on the list align with what your enterprise needs?

Where there is alignment of your list and enterprise needs, YOU have an opportunity.  That opportunity is to demonstrate value in testing as a benefit to your enterprise.

Your Next Step
Pick something on your list and describe what you could do to achieve it.  Let’s say you pick more training.  Training is a broad topic so you want to take a small step.  What might be a small first step?  Read a testing magazine (there are many), read a testing book (there are many), or watch a testing training video (there are a few).

Regardless of the small step you take, apply what you learn and share what you learn!  By applying a new skill, you demonstrate to yourself that change is possible.  By sharing what you learn, you begin to influence others.

The Beginning
Your small step is a beginning.  A beginning that could embody the change or changes that echo off your office cubicles.  Good change starts from within, and it continues with good people.  You will need help and should not be afraid to ask for it.  Often.  Change is possible – find those like-minded testers, find a business sponsor, collaborate on a purpose and principle, and propose a beneficial, sustainable, and exciting change in testing for your enterprise.

What will you do today to be that change?

Learning to Read Code? Here’s my Short Primer!

I support the idea of testers learning to read code. It’s also a great opportunity to build rapport with developers. If you want to learn how to write programs, I support that also.
However, I think reading code will benefit you more when you know more about it. For example, when you read a mystery book, you look for certain type of characters (a detective), and certain types of activity (discovering a clue). Reading code is much the same. Here’s my primer.

Core Constructs
There are four basic code constructs supported by just about every language. These are important to understand because each has implications to your testing. The constructs are assignment, If statements, loops, and math. Programming is an act of combining these constructs to accomplish business goals.

Code Construct How to Identify It (in most languages)
Assignment Look for an equals sign (=) between words and numbers
dateOfBirth = 6/30/2001
If Statements Search for the word ‘if’
Loops Loops contain with the word ‘for’ or the word ‘while’
Math Most languages use common symbols to perform arithmetic. The exception is multiplication which is often represented by the asterisk (*).

In addition to the core constructs, code supports collecting and reporting of information (input/output), and storage of information.

Assignment sets the value of a variable. For example, when you enter a date into a program, the program probably assigns it to a variable (temporary storage – see below) so that it might act on it. This allows the program to verify the date is valid and other tests before it is used elsewhere.
Testing Implication: Information collected from a user by the program is always suspect. This includes data collected from a web page, an application form, a file, or a web service. A healthy dose of Domain testing is in order.

The If statement provides a program the ability to evaluate data, and to direct workflow. For example, you want to open a credit card account and the company has a business rule requiring applicants be at least 25 years old. If you provide your birthday as today, the program evaluates that date and rejects it.
Testing Implication: Business rules may have multiple outcomes. In the example above, there are at least three. Your testing may need to functionally evaluate the program for each outcome: (1)the applicant is 25 years old, and the applicant is (2)more than or (3)less than 25 years old. Additionally, the program’s workflow may be different for each outcome.

Loops allow the program perform the same code sequence many times. For example, when your music program displays a list of songs, the same code sequence executes to display each line but the data it uses, the song name, changes each time through the code sequence.
Testing Implication: The number of times a code sequence executes may depend on the data, it may execute a fixed number of times, it may change program behavior if there is an error, and in some cases it may never stop. Review programs for loops and evaluate what controls the execution of loop.

Programs perform basic math to trigonometry. For example, a spreadsheet performs many arithmetic functions.
Testing Implication: The arithmetic equations themselves should be evaluated in isolation. Once you have confidence it the equations, the inputs to those equations may require Domain analysis and testing.

We are probably most familiar with the input and output of programs. We enter data into a screen, and we see data displayed on a screen or printed report. Programs accept data from other programs, web services, files, or cameras. Conversely, programs deliver information as files or strings of characters.
Testing Implication: There are many forms of input and output and they vary based on source (input) and destination (output).
How to Recognize It: Theses are largely code sequences specific to the requirement of the program. This is a great opportunity to review the functionality with your developers, collaborate on the testability of inputs and outputs, and learn.

Programs store data in two forms: temporarily and permanently. Temporary storage (known as variables) allows the program to work with data to meet the business needs. Permanent storage provides for persistence of information over a long period of time (disk drives and databases are examples of permanent storage).
Testing Implication: Temporary storage may be an issue in embedded applications where memory is scarce. Permanent storage can improve program testability when used to create logs or journals of transactions.
How to Recognize It: Temporary storage is declared explicitly in many languages. The syntax includes a data type identifier and a variable name. Permanent storage usually requires code libraries to read and write information to a file or database – another opportunity to talk to your developer.

Now, go find some code and practice!  Leave some feedback on the examples you found!