Adam White

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?

Read the rest of this entry »

I was using a mind mapping tool called BrainMine. I found a bug that exhibited itself if you printed the mind map and then edited and/or moved a node afterwards. What do you think is going on underneath the covers here?  Would your automation have caught this? How would you automate this test?

The video is here

I wasn’t up on my BB Test assitant skills when this video was taken so you’ll have to infer my troubleshooting process from what you see in the video.

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

Back in March I was exploring my artistic side. While reading a book on drawing I noticed similarities to software testing. I wrote up my thoughts and sent them to STP Mag. They decided to publish what I had.

Drawing on the Future of Testing

Writing the article was an interesting exercise. I find it fun to take two seemingly unrelated activities and tie them together in a way that makes sense to me.  The writing gave me a change to work with Michael Hunter

who graciously gave me some tips and pointers on how to tighten the article up making it more “me” instead of a bunch of quotes. I also have to thank Alan Martin of refraction arts for taking the photograph. I’ve taken a few photography lessons from him. He needed a test subject for his portfolio work so I wound up getting some pretty nice portraits

They wouldn’t post my email or website so it’s been difficult to know how my article was interpreted. I’d love to get something back on it. What do you think of it? Am I onto something? Am I out ot lunch? Does it make sense to you? Ever experience someting similar? Is it good writing? Engaging? Poorly written? Boring? Help me out here!

Drawing on the Future of Testing

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?

Thought we could actually use the application under test to get exchange feedback

Are these blogs posts providing value to you? Comment here.

https://www.rypple.com/adamkwhite/valuetoyou