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

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

Problem or no problem?

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?

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?

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

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

• 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

Using metrics to reward people

Using metrics to reward people can get you into the slippery slope of people gaming the system.  So one tester logged 10 bug and the other 5.  Who is the better tester? Need more info right?  Thought so.  4 bugs slipped out in one area and 1 in a different area.  Who is the better tester? What if it’s the same tester working on both areas? What if one of those areas was not tested because the dev team said it “there were no changes”?  Doesn’t seem fair does it? It doesn’t seem reasonable to me.

My approach

I find the best way to reward people is with appreciation right at the time they do something you like!

Here is how I go about this.

I wrote a list of expectations that I have of the team and a list of what they can expect from me as their leader. I reviewed this list with the team on multiple occasions. During the week I watch, listen and observe the teams interactions with their peers on the team and in other departments (development, support, product management, project management etc.) If they do something I like I note it down on a printed list of my expectations.

Sometimes I approach them immediately afterwards and tell them what I liked about the interaction and sometimes I wait until our weekly team meeting. Sometimes I read off the list things I observed that I liked and sometimes I don’t. I read the energy of the room and from myself and decide if it’s the best time to deliver appreciation.

I also randomly give out movie gift cards to go along with my appreciation as well. I also let teams testing a product leave early on Friday or come in late (depending on the circumstances).

When new projects come up I give people who have done good work and met my expectations a chance to run with the new stuff.

Flaws/Drawbacks with this approach

First problem is the random gift card approach. Some people tend to like a specific algorithm to receive a reward. “If I do X I receive Y”.  This can lead some people to feel left out because they aren’t receiving monetary recognition for their efforts while others are.

Second sometimes there is a really good interaction that I miss because I’m in a meeting or away from my teams area. Most of the time if it’s a really good interaction multiple people on the team will tell me about it. Sometimes the person involved will tell me directly. I also enjoy hearing these stories as well.

Side note: Wanting to see these interactions is one of the reasons I refuse to sit in an office that is away from my team. I would miss out on all the rich context!

Third - there are times when some people don’t receive appreciation for activities done throughout the week. Why? Well it could be because of the reason stated above, or any other of a multitude of reasons.

Despite the flaws I do it anyway

Why? Because I’ve seen the power of rewarding people with appreciation. On one instance I took an employee aside, looked him in the eyes said “Ron - I appreciate you for helping me run the team while I was away on vacation. It really meant a lot to me and people are telling me you did a great job. I like hearing that” Ron’s eyes started to tear up. I don’t think I could have given him a monetary reward that would have had the same impact as that simple sentence. Was it tough for me to do? No.  Did it cost me a lot? No did it have an impact that I wasn’t expecting? YES. Ron’s productivity went through the roof.

Rewards people takes effort

It’s up to me to know what motivates each person individually. I don’t feel there is a reward system you can put in place that blankets every tester on the team. For some people it’s money, for others it is intellectually stimulating work, for others it is camaraderie.

Having a blanket system or method doesn’t seem reasonable to me. It’s easy to do - anyone can pull metrics out of the bug tracking system to reward people. This method is not exactly fair and doesn’t take into consideration the nuances of things that are important to you

Keep in mind

The main thing to remember when rewarding your team is to be reasonable, pay attention to they are doing AND tell them when you notice it. Money helps but it doesn’t always work for everyone. My method is a lot of work but has paid off for me in the support and dedication of my team.