The target? A simple calculator to estimate parking costs at the Gerald R. Ford International Airport (see the Parking Calculator). The participants? Testers on Twitter.  The result? Much fun, lots of learning, and many bugs found.

I had planned to do other work in my backlog this morning, but a testing challenge can’t often be ignored (by me, anyway).  As I work from home between gigs, I can afford a little leeway in my schedule some days.  :)

While I have actively managed and coached on testing over the last number of years, I haven’t actively tested anything in a while.  So this was a chance to see just how rusty my testing skills were.  And do it live with testing colleagues around the globe.  No pressure.

If you haven’t yet, go click on that link above and try out your testing prowess before you read further!

Highlights from my Session
My eye was immediately drawn to finding ways to find the boundaries in the date and time fields, check valid/invalid data, and max out the cost estimate.  After playing with it for a couple of minutes, I was able to obtain a $6.75 million charge for 1 day of short term parking.

A little bit odd, right?

Some more attempts saw my cost estimate creeping upwards to $2,500,000,000,000,041.00, by simply pushing a limit in the Leave Time field, as seen below.  Notice that I was given a parking duration of an exponential day?  Stranger yet.

From there, I started my attempts to max all of the data entry in an attempt to drive the cost higher still.

Some of the interesting things I observed along the way:

• No limit on amount of data that could be entered in Date and Time fields.
• No restriction on amount of time that Short-Term Parking applied to.
• In some situations, when Leave Date increased a large amount beyond Start Date, Cost decreased (while all other variables remained the same).
• When entering large numbers (around 10 digits & higher), data in Time fields had a larger impact on Cost than did data in date fields.
• Can enter negative numbers into Date and Time fields, and Cost is calculated.
• Can enter letters into Date and Time fields, and Cost is calculated.
• Can enter symbols into Date and Time fields, and Cost is calculated.
• I suspect you could enter php script into fields and do something interesting (possible security issue?), but my php skills are non-existent these days.
• Found a sort of boundary in each data entry points in Date & Time fields.  For each point X in (X:X, X/X/X) an additional digit added resulted in calculator producing an error, and then an additional digit beyond that resulted in a lower Cost than two attempts ago.
• Can get free parking over course of a day, provided Start Date = Leave Date, and Start Time > Leave Time where:  Start <=11:59, Leave >= 0:59 (both am, or both pm).  This reports negative days parked.

My maximum Cost? $5,014,609,699,998,504.00 (for 2.08942070833E+14 Days, 14 Hours, 47.4666666667 Minutes)

This was a quick session, so there was much more to be found that I didn’t attempt.  To see other experiences, check out the conversations and results reported on Twitter via the #parkcalc hashtag.

I was particularly impressed with the findings of James Bach, who followed Dave Liebreich’s lead, and used exponentials to achieve a higher estimate (why didn’t I think of that?!).  Try as I might, I couldn’t play off of his data to achieve a higher one yet.

And then Markus Gartner really wowed me.  He achieved highest (reported) cost using specific numbers in the year field, that I can’t for the life of me figure out why they were special to achieve that result.  Altering his data didn’t achieve anything higher either.

So What’s The Point?
The point wasn’t to find ways to maximize the parking cost estimate.  Nor to just find really weird bugs in the application.  The point also wasn’t to say whether the application Gerald R. Ford International Airport put on their website was of poor quality (Note: Data is being collected to send to them as a result of this exercise, so they can fix things if they choose to).

The point was simply to practice some testing skills, learn from other testers, and have some fun.

And I did!  I had a blast.  Thanks to all my fellow tweeps for the engaging exercise and 140-character limit conversations!

Stay tuned for highlights from the Debrief that will occur among some of the testers that got involved.

It was beneficial as I was able to help employees learn new concepts and improve skills,  in a manner that fit for them.  The added bonus for me was that I learned something new from them as well.  What powerful experiences those were!

Now, as a manager for 18 testers who are spread across several different agile teams, I find it difficult, if not impossible, to coach testing skills one-on-one.  On a weekly basis I also spend time coaching the agile teams, management-level initiatives to improve company-wide practices, and the usual management administration.  Such is life in a ‘start-up’ type of company.  As a result, my one-on-one time with each person is limited to 30-60 minutes over two weeks.  This seems a miniscule amount given they are working a minimum of 80 hours in that same time period!

I am someone who is motivated and energized in working with others to learn new skills, to understand and be able to apply new skills appropriately, and to have those ‘light bulb’ moments where things just click.  Given my work situation, I have been frustrated with how little I have been able to do this.  This left me with a problem!

How can I increase the amount of coaching and teaching time each individual is receiving?

Solutions:

• Forget about it: Nope! I’m too invested in helping others learn and grow.
• Clone myself: Not feasible, as in I don’t know how, and it is kind of icky to think about.
• Shift responsibilities to other people: The possible people to offload to are just as overloaded as me.
• Find additional ways to teach and coach skills so each individual gets more opportunities to learn and improve: There are lots of ways to do this!  I just need to invest some more time to create these opportunities.  Some possibilities:
  • Coach a smaller group, and have them coach small subsets of the larger group.
  • Direct them to other people who I trust will coach them appropriately.
  • Move our 1:1′s to their work space & turn it into a paired testing session.
  • Create workshops where they can learn and practice skills.
  • Coach other people to create workshops where they can learn and practice skills.

What I’m Doing:

Ongoing learning and growth are important to me.  Happily, I discovered that they are important to my department as well.  They requested regularly scheduled workshops/training sessions to be reinstated after being cancelled during the agile training the entire engineering organization went through over the summer.  They missed them!  They missed the learning, new perspectives, and much needed ‘down time’ at work.

So, regular department workshops / training sessions were reinstated on a biweekly basis.  We are currently shifting to make them weekly.

Our first workshop back was a brainstorming session to come up with a list of loosely prioritized workshops the team members would like to have provided.   They came up with a lot of great topics, which we are adding to on an ongoing basis, and are adapting priorities as needed.

The workshops we are doing are typically 2 hours long, and are created by myself or a team member, and contain both teaching of concepts, and time to explore, practice and apply concepts.  We customize workshop focus and content based on the people involved, what they want to learn about, and their current knowledge-base and skill sets.  A blend of ‘teaching’ time and ‘experience’ time are proving vital to help people go back to their day-to-day work and integrate new learnings – which when applied to hands-on work become new-found skills when they invest time in practicing them.

The workshops also allow me to engage with everyone both as a group and individually, and determine how I can add more value for them when we have our regular one-on-one conversations.

Final Thoughts:

I am not yet satisfied with the amount of coaching and teaching I am able to provide to each individual. However, I am happy with the progress I am making in increasing the amount of learning opportunities they are getting from me.  These workshops have allowed me to stretch the limited time I have to teach, coach, and add more value for all of my department members.   This is an improvement, and a step forward to incorporating other learning opportunities for my department.

I plan to share some of the workshop experiences in future blog entries, so keep an eye out for those!

On Teaching Software Testing:

My thoughts on this have been bouncing around in my head for a while – how can we improve on how testing skills are taught?  What is the best way to teach and coach them?

For myself, there are things I am doing now which are helpful, but there is so much more I would like to do, and I’m sure could be doing that I haven’t considered yet.  I know I am not the only person in that position.  So where do we begin?

Matthew Heusser recently blogged on this very topic.  He invited people to comment on what types of teaching and training are wanted by organizations for their employees, and what would be most effective for the employees.   I added my comments to that entry, alongside some brilliant thinkers in this field.  Thank you to Matt for starting a great conversation thread!  You can read it at http://blogs.stpcollaborative.com/matt/2009/11/18/you-say-you-want-a-revolution/.

Your turn!

What are your experiences and thoughts on how to coach and teach software testing skills?  As a coach/teacher/trainer, what have you done to do this when you have had little time to do it well?  As a tester, how do you want to be coached and taught – what would be most effective for you?

I welcome your comments, and encourage you to share them both here and on Matthew’s blog.