Archive for April, 2009

Productivity Tip – Set a weekly meeting with yourself

Posted in Best Practices, Management, On-Going Improvement on April 30th, 2009 by Joel Montvelisky – Be the first to comment

One of my biggest on-going challenges is managing my time, tasks and obligations.

Between PractiTest’s Agile development process, overseeing the writing and executing of test cases, interacting with customers, collaborating with colleagues, and all the rest of the daily tasks, sometimes the week appears to fly-by and many things I planned to do become at risk of being left aside and forgotten.

Other than making sure all my tasks are managed in a single place (we use PractiTest to manage not only our bugs, but also our tasks and enhancement requests), I always set aside time once a week to review all my tasks, mails, meetings and obligations.

It may sound silly but to make sure I have the time and privacy to concentrate on my stuff I’ve scheduled a recurrent meeting with myself at the end of the working week.
During this time I go over all the tasks, inboxes, to-do lists, meetings, etc; and I am able to achieve 2 main things:
(1) Handle anything that I might have missed from the week that is ending
and
(2) Plan ahead my schedule and agenda for the week (or sometime weeks!) ahead.

For me having this time to make a stop at the rushing week and concentrate on evaluating and planning helps me to understand where I need to focus my time and even perform mini self-evaluations to understand if I’ve been misusing it, forgetting to handle important stuff, or simply prioritizing wrong between all the tasks that I have and those that suddenly appear.

I’ll be happy to hear if someone has additional tips on how to stay on top of everything!

Improve your Testing Skills, take a look at your Kids!

Posted in Best Practices, On-Going Improvement on April 24th, 2009 by Joel Montvelisky – 2 Comments

I will need to give Rob Lambert credit for planting the seed for this post with a comment he left on a totally unrelated post about Company Politics and QA, when he mentioned learning from his kid how to pick his fights.  This got me thinking that we have many more things to learn from our kids, specially the way to improve how we approach our tests.

I got 2 kids at home; a boy who’s almost 2 years old, and a girl who’s almost 2 months old.  From playing, interacting, and simply from looking at them I’ve been able to grasp some practices and approachesto improve my testing tasks and results.

Curiosity – even if he has seen the same closed box hundreds of times, my son needs to open it in order to know what’s in it.

Skepticism - he doesn’t believe me when I tell him there is nothing in the box, he opens it just in case I might have forgotten something cool inside.

Emotional motivation – regardless if he wants to climb to the sofa, to climb up the stairs, or hold the dog’s leash when we go out for a walk, you can always perceive the motivation in my son’s eyes that make him give everything he has in order perform the task.

Get on your feet fast and keep on going -  Kids are not ashamed to fall down while learning to walk, they lick their bruises (sometimes literally) and get up to continue trying.

Not getting stuck too long in one thing – Children are excellent smoke-testers, they know how to play exactly 15 seconds with each of their toys until they reach the one that is interesting enough to spend more time with it.  And even with the interesting toy, after 5 minutes they know to move along to the next toy in line until they’ve gone over all their repertoire (some times twice!).

Analyze and take stuff apart -  I’ve seen Ariel (my old boy) take apart stuff that I didn’t know could be separated, just give him time and he will understand what pieces can fall apart. Then he will examine each one of them individually to try and find fun things to do with it too.

Watch and learn – They are constantly looking at what’s happening around them and learning, they sometimes are even able to learn from the experience of others (something I wish I was able to do myself!)

Not afraid or ashamed to ask for help – When my kid wants to play with something and he’s not able to get it functioning, once he is done throwing it and expecting it to work he brings it to me so that I can help him.  Just imagine how great it would be having an employee, a boss or even a peer smart enough to try to work a problem by himself, and then if he gets stuck or fails to ask for help…

Use all your senses – Give something new to a kid and he will start by looking at it from all sides, then he will touch it and try to find if there are buttons or stuff to take apart, then he will simultaneously smell and lick it; and only then he will throw it to see if something cool happens when it falls.  Kids use all their senses when trying to understand something.

Personally I think the most important thing I can learn from my kids is to look at all other kids without prejudices, and to give each new person an equal chance the first (and sometimes also the second and third) time they meet them.

So next time you have the opportunity, take a look at your kids (or your nieces and nephews if you are too young!) and try to learn something from them about how to do your tests.
If you have something additional to learn from our kids please send it to me so that I can add it to my training list!

You need to become a Project Trusted Adviser!

Posted in Management, On-Going Improvement, Testing Intelligence on April 19th, 2009 by Joel Montvelisky – 2 Comments

I was taking part on a discussion started by Rob Lambert on the SoftwareTestingClub where he talked about “hitting a brick wall”.  By this he meant the all-too-familiar feeling that regardless how much you raise your voice and warn all the project stakeholders about the imminent danger of following a certain path, they decide against your advice and follow it anyway.

Who hasn’t gone through this before?
I’ve certainly been in the same situation enough times myself, and over the years I’ve learned some tricks and developed a couple of techniques that help me avoid such situations, or at least reduce their number significantly.

1.  I make my homework before the meetings
I always try to talk about the important issues with the project stakeholders One-on-One before the actual meeting where the decision will take place.  This way I can spend the necessary time to thoroughly explain the issues and go over the repercussions it may have for each person and team individually; this also gives them time to think about the issue quietly and ask additional questions if necessary.
If possible I also try to understand from the people I meet what’s their position and thus I know what’s my status before going to the meeting itself.

2.  I make my objective to become the Trusted Adviser of my project Heavy-Weights
This one is easier said than done, but it is the most effective method.
In principle it means that you need to create a reputation for yourself that will make people listen whenever you speak your mind.
How to do this is a science by itself, and it’s definitely not something that happens overnight.
Personally I try achieving this using the principles of Testing Intelligence: “By providing correct and timely visibility into the product and process, that helps my Organization’s Stakeholders make the correct tactical and strategic decisions.”
An additional good approach is also to map your project heavy-weights (the stakeholders who usually carry the most weight in the important decisions) and start by becoming their trusted advisers, as soon as the other stakeholders realize these guys are listening to you they will start doing so themselves.

3. I’m open to change my mind when I understand new things about the problem at hand
Don’t be a hard-head and learn to change your mind, this is the reason I make a point of really listening to the other side when I’m arguing.  One of the dumbest mistakes you can make is to continue fighting for an argument even when everyone realizes you are not right.
The most common cases are when someone presents a new argument you were not aware off (e.g. customer pressure, market reality, etc) and you need to understand that the good of the Company and the Product require the team to take the path you did not support initially.
Smart people need to be smart enough to know when to change their minds…

4. I learned to pick my fights
Since I cannot fight over every decision, I make sure to choose what things are worth fighting for and what battles I need to conceive in order to concentrate on the important stuff.

5.  Learn how to communicate
Maybe the most important, and yet one of the hardest to things to achieve.  We all need to learn how to transmit our messages clearly to the other side.
Just to show a good example of how to do this I will point to another article by Rob Lambert that illustrates one of these techniques (and no, I am not getting any royalties from Rob today…).

To summarize, there are many things you can do in order to confront and even succeed on these kind of situations, and all of them start by recognizing you have additional human beings in front of you.
Try to think what you can do in order to help them understand your argument and your point of view, then you will have no choice but to let them make their own decisions.

Back to Basics, write down your objective before you start testing

Posted in Best Practices on April 17th, 2009 by Joel Montvelisky – 3 Comments

It happens to me all the time that I start testing and as I move along my steps (or my application if I am working on an exploratory task) the thoughts in my head and bugs that I find take me along paths and routes I didn’t plan ahead.
This is not an issue by itself, but the problem is that sometimes I finish my run and then I realize that I completely missed the objectives that prompted me to start testing in the first place…

This is why I started doing a simple exercise each time I start a test: write down my testing objectives on a piece of paper.  I then place this piece of paper next to my keyboard and start my test.

As I find or think of additional things that should be tested or reviewed I make an additional note on the piece or paper and continue; sometimes I start immediately with these new cases, other times I continue with my previous ones, but now I am sure I won’t forget them.
As I cover the things in my dynamic-yet-static list I mark them down and move on.

Since the piece of paper is right in front of my eyes, it is not something that I need to constantly open or refresh, its simply there.  And I always know what I need to cover in my tests before I can call my test complete and done.

Sometimes the beauty in life comes from the simple things…

On-Going Improvement – running a Marathon one step at a time

Posted in Best Practices, Management, On-Going Improvement on April 7th, 2009 by Joel Montvelisky – Be the first to comment

Two things brought this subject to mind lately…

The first one is that I noticed that once again I am overweight, and I set myself a goal to run a 10 Km race in 8 weeks from now.
The second, I was a bit frustrated yesterday with the fact that one of my projects is not advancing fast enough.  Or so I though until I took time off and started appreciating all the stuff we accomplished in the last 6 weeks, and the advances were definitely impressive.

The fact is that I beleive in working based on On-Going Improvements, instead of big and revolutionary changes.  Like the training schedule I found in order to prepare for the race, that increases the distance about 400m each week, but at the end gets you to the place you want to be at a pace you can maintain. The same goes for most of my projects, I believe in working based on a succession of small improvements.

Basically I think that this strategy has a bigger chance of success since:
1. Smaller changes are easier to implement than larger ones, specially on projects that are running at full speed.
2. Changes that come from on-going improvements are born from the process itself, so they usually have a direct and immediate effect (even if a small effect) on your system that can be measured.
3. Smaller changes are easier to roll-back in case you decide the effect was not the one you were lucking for.

The best part about on-going improvements is that you can start with them today without an overblown statement, objective or kick-off party.  It is as simple as taking a look at whatever you feel requires improving and thinking about small changes that will bring you value.  Sometimes it is easier to start with a Pareto Analysis to select the low hanging fruit that will give you the biggest gains.

On-going improvements are not new and definitely not revolutionary, they’ve been around for a long time and are used in all sorts of methodologies such as Project Retrospectives and even in as part of the Scrum Methodology.  I simply think that we can take advantage of them and apply their principles to most daily processes and projects.

Give them a try and tell me what you think!