Adam White

I’m sure there are lots of basic timer apps out there and I probably could write one myself but i’m just curious about what others do. The “obvious” answer is using the your computer clock. I find this method can be disruptive to thought and getting in the zone.

What do tools have you found that alert you to your session time being up without having to actively monitor it?

I LOVE this video by RSAorg. Their presentation method kept me very engaged.

I decided to blog this as several people have sent it to me…. make sure you check out RSA’s other videos

I was impressed by what Cong had done. I thought his summary was thoughtful and showed understanding of the concepts. I went through bugs and reviewed the answers to each of the 4 questions. I learned a few things about the details of our product that I didn’t know before.

I picked up the phone and called him to talk to him about his findings. I gave him credit for doing what he did. When discussing the bugs I asked him if he could do this process for every bug or if it would be too time consuming. His answer was something to this effect “Well even for bugs that I thought were trivial I still learned something from talking with the developer so I’ll have to use judgement in the future”

In discussion of one particular bug I asked him to think about whether it was something we should write down as a test idea for future release and also to help future testers learn about the product. I didn’t give explicit directions/instructions on whether this is an expctation/requirement for him. He will have to figure that out for himself and decide where the info would go.

One point we discussed was that there was no response to my initial request until it was done. Throughout the week I wasn’t sure if he was putting any effort into it. I’m also at fault for not setting expectations for an initial response. We both learned a lesson from this and can now communicate more effectively in the future.

I feel like now when I respond to his daily updates we can speak a common language and have a common understanding.

Here is my summary of this interaction

What went well

• Attempting to make Cong feel safe and that I wasn’t threatening or unhappy with his work. I am his boss’ boss afterall and I had never given him a direct request before
• Clearly set completion date
• Set out expectations on how the end result should be delivered
• Gave some local options for getting help
• Follow up via phone to discuss findings and do a little bit more coaching

What could be improved

• I could have picked up the phone in the beginning and explained the exercise, following up with the email writeup
• In my initial request I could have asked Cong to respond and either accept, reject or negotiate my request and give him a date to do this by
• I could have followed up with him mid-week to see how things were going with the task
• I could have set up a skype call with him

Things to remember when coaching remotely

1. Look for things that will teach you about something of interest to you – not only the person who you are coaching
2. It’s important to set two deadlines – one for the initial response/commitment and one for the actual deadline
3. If you’ve not met the person or had very little interaction with them make sure they don’t feel threatened
4. Give the person options for getting local help
5. Follow up via phone/skype, give feedback watching for anything from #1

I’d love to hear any comments on this situation or thoughts/experiences you have with remote coaching/training

I thought I would share something I did recently regarding remote coaching/training. My inspiration for sharing comes from here and here

I have always enjoyed training new software testers. Lately it’s been more difficult for me to do since I’m in a different office from the bulk of the testers on my team. See my linked in profile for an explanation as to why I’m away.

Given that I’m away I started looking for ways to continue engaging with my team. One opportunity came from reading Cong Zhao’s daily updates.

About Cong: Cong joined us from Waterloo for his second summer work term. His first work term was with ACRP. They provide testing fixtures to Rim to test blackberry. You can find out more about him on linked in

About daily updates: I have everyone on my team send a little summary of the interesting things they learned that day. It’s meant to resemble newspaper headlines that catch your eye, make you want to read further and hopefully learn something of value to you.

Note: I’ve asked Cong for permission to share the process we went through.

Here is the initial correspondence I sent to Cong based on something I read in his daily update.

Cong,

Mike and Herb are out so I’m going to do some remote mentoring with you. I reviewed your list of bugs. You did a good job at re-running the original steps and documenting that in the bug. I want to challenge you to figure out what other areas of the product might have been affected by the changes you are testing.

I want you to ask yourself (and others) “What else could have been broken as a result of this fix?” “What areas of the code where changed and what other areas depend on/use this area” This will cause you to become familiar with the code and will probably require talking with the developer who fixed it.

Questions you should be able to answer for every bug

• What area of the code was changed?
• Why was it changed (explain why the change fixes the bug).
• What needs to be done to verify that the fix resolves the original problem.
• What needs to be tested to prove that the fix does not cause the product to break in some related but different area.

For some guidance on different approaches to thinking about the software check out these articles

• More Than One Answer More Than One Question
• Is There A Problem Here
• Test Design With Risk In Mind
• The Proof Of The Pudding

Action items I expect you to complete by next Friday.

For Articles listed above

• Read these articles over the next week
• Write a summary of your learning from them
• Send summary to Mike, Herb and myself

Look for and document your exploration of bugs beyond the original description.

• Pick 5 issues that had code changes that you are assigned to close.
• Speak with the developer and get the questions from above answered. Document the answers in the bug when closing.
• Show evidence of the above to Mike, Herb and myself.

Given that Herb and Mike are out and I’m remote – you could also rely on Joseph for som
e guidance as well. Let me know if you have any questions or if you cannot complete this assignment by next Friday.

Thanks,

Adam

What I think I did well with this communication

• Explained to Cong what I was intending. I attempted to make Cong feel safe and that I wasn’t threatening or unhappy with his work. I am his boss’ boss afterall and I emailed him fairly out of the blue.
• Clearly set completion date
• Set out my expectations on how the end result of the work should be delivered
• Gave him some local options for getting help

What could have made this communication stronger

• I could have asked Cong to respond and either accept, reject or negotiate my request and give him a date to do this by

I’d love to hear any comments on this situation or thoughts/experiences you have with remote coaching/training

Statistics may be defined as “a body of methods for making wise decisions in the face of uncertainty.”  W.A. Wallis

Here’s the Situation. Jim needs to release software on a specific date for a big trade show. It’s currently Monday and ship is Friday. Everyone is pumped! Marketing has their message for Friday morning ready. Brochures are printed. Sales team is pumped. Support and services have been trained. Everything is set!

Jim is the project manager for this release. From the information he has there doesn’t appear to be any  issue with hitting the deadline. During the mid-morning bug triage the test manager Neil reported that 45 bugs out of the 74 for this project need to be fixed for release.

Jim doesn’t see a problem. “Seem like a reasonable goal – 45 bugs in 5 days.. with all our coding resources dedicated to fixing this it should be no problem. We’ll work on them in priority order – P1′s first, P2′s second, P3′s third. With 6 developers working full time we will fix them in no time.”

“This is how humans are: we question all our beliefs, except for the ones we really believe, and those we never think to question.” -Orson Scott Card

In the last week of software projects things can get pretty heated. Lots of buzz. Lots of teamwork and camaraderie. Lots of great questions from management too! How long will it take to fix these bugs? Will we ship on time? Can we do it? What will it take? Can we put more people on the project and get more of these bugs fixed? There can also be an insane amount of pressure

Neil isn’t so sure of what Jim is saying. Of the 45 must fix bugs the priorities were as 4 P1, 21 P2, 8 P3, 12 P4. Jim kept getting hounded by upper management – “are we going to make the date?”. To answer Jim did something to get a quick and easy response that not even Neil was expecting.. He applied a linear trend analysis to the bug counts and predicted the release would be ok.   ”Well – it’s now Wednesday morning and we are fixing 10 bugs a day. We have 25 bugs left so we will be done in 2.5 days. That should leave us with a half of day buffer.” Jim proudly noted!

What do you think happened to the project and to Jim?

(more…)

One is the one thing that needs to fall into place before testers can start operating the product? The build has to be successful!

One day I was looking at some statistics about our build process.

Project 1

Month fo Feb – 80% pass

Month of March  – 72% pass

As I looked at these stats I was having a hard time deciding what action to take because of them. I said outloud ”I  wish I could see these numbers in a visual way – like on a calander or something. We could put a big green check mark when the build passes and a big red X when it fails.

John Sterne, a student from Waterloo, who has done 4 or 5 work terms with us, decided to run with my “I wish” statement.

Much to my surprise I was able to get a better feel for the state of the build and it’s impact on my team by looking at the following graphics

80 % pass rate or 20% failure rate

72% pass rate or 27 % failure rate (6/22)

Which one communicates more powerfully to you?

If you like the pictures – then take a guess at how the testing for this product was going

Here is another example why.

Problem or no problem?

My laptop blue screen with a .sys file error. Upon rebooting an IE window was opened automatically by the system suggesting that the file could be corrupt or be from maleware. The window suggest I install Windows Live OneCare. I decided to do this.

OneCare told me that I had to defrag my drive. I found this curious so I ran the defrag tool that came with the system.

Question for you – problem or no problem? How do I go about sovling this inconsistency?

Recently I had lunch with a group of testers here in Toronto.  The topic of bug tracking, support ticket tracking and backend systems in general came up.  Each person at the the table had a story to tell about their bug tracking systems or their support ticket tracking systems. Most of the stories weren’t positive. From what I recall every person at the table felt that at least one (or more) of systems their company used didn’t support their work. They weren’t being as effecient and effective as they could be based on their experience with other tools

Why is it that companies do this?

The tools the people at the table were forced asked to use came from above in an attempt to “bring systems together” and to “have one central spot to access everything” of interest.

The general trend seemed to be that this goal was achieved. The information wasall in one spot but the tool did not help in achieving the goal of getting things done quickly and effeciently. One person at the table had a story about a particular test case database that had a front end that so horrible and time consuming to use that the testers wrote automation to populate test cases db from a flat file. Sound like a tool that supports effective and effecient testing doesn’t it?

What’s the solution?

Each person at the table had their own way of dealing with the problem.  Solutions ranged from “Well – it’s the system they told me to use so I guess I have to use it” to something like “Yeah – X is the corporate standard but we still use Y anyway. They don’t complain too much about it as long as we give them the metrics they want.”

How would you go about bringing this type of problem to light? This is a problem that involves making your team more productive and effecient. It might also involve changing the “coroporate standard”.

How would you/do you approach this type of thing?

So far based on what I have learned from my exploration and my emails with Tiho I have been able to create an unprioritized charter list.

• Test for max characters in text boxes
• Research share feedback functionality
• Research labels under review my feedback.
• Explore download CSV functionality
• Explore Expand all and collapse all
• Create a workflow diagram of all the dialogs and their functionality.
• Find a way to do some automatic data input and exercise the workflow.
• Explore error messages
• Test SSL
• Run through the install process for promoting code to production
• Try to migrate the system to a new server
• Learn more about the enterprise version of the product