Category Archives: Training

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?



The Explorer

Imagine you are an explorer.  You often explore jungles and forests, and occasionally cities and villages.  People regard your exploring skill highly but with some reserve.  One day, a builder comes to you who wants you to explore a bit of pasture.  They are interested in changing the pasture so that many people might live there.

  • Given your skill and experience in exploring, when you go out to the pasture, then the builder wants to know your opinion on having people live there.

You decide to visit the pasture.

After a day’s journey, you arrive at the pasture.  From your vantage point, you can see it is bordered on one side by a large hill.  While there are many groups of healthy trees, there are also inviting clearings.  You think that if people lived here, they would enjoy the area.  As you walk around the pasture, you take notice of the types of trees, variety of animals and insects, and appreciate the small river.

Upon your return, you describe what you saw and what you found.  In your opinion, people would be able to live in the pasture.  The builder asks many questions and you respond with your experience in the pasture.  The builder asks if you found any bugs.  You reply that you found many bugs for they were plentiful on the ground and on the trees.  The builder thanks you and gives you a special token of their appreciation.

A few weeks later, the builder asks you to explore a city.  They are interested in making changes in the city.

  • Given your skill and experience in exploring, when you go to the city, then the builder wants to know your opinion on making changes in the city.

You decide to visit the city.

After a day’s journey, you arrive at the city.  From your vantage point, you can see a few buildings, neighborhoods, streets, and people.  Beyond the city limits, there is a forest.  You think that if the city had some changes, the city would readily adapt.  As you walk around the city, you take notice of the population, the clean streets, the commerce, and the services.  You recall the builder asked about bugs so you also pay special attention to the ground and the few trees you find.

Upon your return, you describe what you saw and what you found.  In your opinion, the city was ready for changes.  The builder asks many questions and you respond with your experience in the city.  Some of their questions about infrastructure and services were challenging so you express your regret in not gathering more information about them.  The builder asks if you found any bugs.  You reply that you found no bugs.

Surprised, the builder asks, “Where did you look for bugs?”

“On the ground and in the trees.  The ground was often covered in concrete and there were few trees.”

“Did you look under the concrete, or in the buildings?”

“I did not.  Since I found bugs on the ground and in the trees in the pasture, that is where I looked for them in the city.”

The builder explains how the city is different from the pasture.  While the bugs were easy to find in the pasture, bugs in the city may hide in buildings or houses.  They may also hide in the way services operate in the city.  The builder suggests you review information about how cities are different from pastures.

The builder expresses their disappointment in your report.  They believe the changes to the city will be delayed because your information may not be accurate.  They thank you and leave.

A few weeks later, the builder asks you to explore the city again.  Not to be disappointed, they ask about your understanding of cities.

“I have explored cities occasionally and they contain many things that I don’t understand.”

The builder thanks you and says they know of another explorer more familiar with cities.  They will ask them to explore the city.

Imagine YOU are the explorer.  What would you do next?



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.

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?

20 Things to Improve Your Testing Career

Jump start your testing career by trying a few things on this list!  Then, try a few more!

  1. Experience all the BBST courses
  2. Help a student with Algebra (there are built in tests!)
  3. Learn a programming language
  4. Become familiar with the works of Weinberg, Kaner, Bach, and others
  5. Organize and maintain a testing forum where you work
  6. Attend a testing conference
  7. Engage an RST course near you
  8. Coach a Science Olympiad of FIRST Lego League team
  9. Participate in Weekend Testing
  10. Read to learn and to diversify your thinking
  11. Attend local testing meet ups regularly
  12. Publish an article on a testing topic
  13. Speak at a testing conference
  14. Plan and propose one change to improve the way you test at work (then, do it again)
  15. Find a hobby that requires some kind of testing
  16. How about those conversational, listening, and collaboration skills?
  17. Exchange new testing ideas with project managers, developers, stakeholders, and others
  18. Read blogs and start your own blog
  19. Create your own website
  20. Offer to design a low level test (also known as a unit test) for a developer
  21. Follow the testing community on Twitter
  22. Learn to be effective with a word processor and spreadsheet

What might you add to this list?

The Project Scavenger Hunt

Near the middle of my last project, I met with my project manager and iteration manager to discuss the addition of new team members.  We were adding both developers and testers and, as you might expect, it was important they learn about the project, the application, and meet everyone in a short amount of time.

We reviewed the documentation we had for training and thought about a training schedule.  Then, I recalled something I did on another team.  I suggested a project scavenger hunt might reduce the training time and help new team members engage the project and team members faster.

The Project Scavenger Hunt
A scavenger hunt is a popular party game where participants are separated into teams and given a list of items to find or “scavenge”.  The items might be a paper sack, a paper clip, an empty soda can, and the like.  The object of the hunt is to locate as many items as possible in a fixed time period.  The team that brought back the most items won.

The primary intent is to have a new team member engage the team in learning about the project.  I craft my scavenger hunt questions so they must introduce themselves and ask for information.  I encourage new testing team members to talk to people – testing is a very social activity!  A list of categories includes:

  • Location of Information
  • Names of Team Members
  • Names of Stakeholders
  • Project Purpose
  • Product Details
  • Product Use
  • Legacy Product Information
  • Project Metadata (status of a specific product or defect)
  • Product or Project Processes

Here are some examples:

  • Who is the Test Lead?  How long have they worked at this company?
  • What is the business value of this project?
  • The payment transaction accepts: A. Cash  B. Visa  C. IOUs (a little humor is welcome!)
  • What is the state of Defect 123?

A little creativity and imagination can generate up to 20 questions.

To round out the scavenger hunt, I include activities the help the new team member engage the product or set up their work environment:

  • Exercise a Product
  • Install Software

Some examples:

  • Make a Payment Using a Credit Card in the Payment Transaction
  • Install XMind and Map the Payment Transaction

Test It!
For a fun alternative to lecturing or reading on-boarding material, I invite you to try a Project Scavenger Hunt.  After you create one, test it with your existing team!