Archive for September, 2009

7 habits of highly effective testers

Posted in Best Practices, Management, On-Going Improvement on September 17th, 2009 by Joel Montvelisky – 1 Comment

I’m currently reading a book by Stephen R. Covey called “The seven habits of highly effective people”, highly recommended if you need to understand how to balance and focus your life and your work.
The book got me thinking about the fact that looking back over my career I have also noticed some habits that seem to be present in many of what I would call the most effective testers I’ve worked with.

The list does not follow any specific order…

1. Context awareness: always understand the higher objective of what you are doing
An effective tester always knows how the task she is doing helps to answer an important and relevant question for the project.
Instead of blindly running tests these testers understand the current context of the project, what areas are important and how to contribute as part of the team. They clearly understand their role within the project and look for ways to play it in the best possible way, based on the current and ever-changing state of affairs.

2. Self awareness: realize your personal advantages and limitations
A good tester knows what he’s good at and in what areas he needs help. This doesn’t mean that he will run away from a task if he has a limitation with it, but he will accept and even look for help without feeling he is being undermined or professionally hurt.
Whenever possible he will try to look for tasks in the areas where his marginal contribution is higher.

3. Hands on attitude: a need to stay connected with the concrete tasks taking place
This is more relevant for managers and team leaders, but an important habit of a good test manager is not to get disconnected from the tasks taking place in his team. Even if this means sacrificing (or better yet, delegating!) some managerial tasks in favor of some manual testing work “in the trenches”.
Not only does this help improve the moral of the team, but it gives real visibility and understanding of the application under test and the real issues affecting the project.

4. Value of communication: explain simply and correctly
An indispensable trait of an effective testers is to be understood.
Not only does she test the correct things right, but she is able to explain to everyone in the team (technical or not!) what she found and how does it affect the overall project.

5. Teamwork: collaborate to achieve synergies
There are obviously tasks that are better done alone, but whenever necessary good testers know how to reach for help or even lend a hand.
Effective testers are usually liked and respected by the whole team, and they understand that teamwork and collaboration are a key to doing things more effectively, faster and better.

6. On-Going Improvement: self & external criticism to keep-on growing
The realization that we can always make things better is a distinctive trait in many of the testers I classify as great. These people are always open to criticism and understand that (in most cases) the feedback comes from a friend who wants to help them improve.
Most importantly, these people are not only open to external criticism, but they develop tools and techniques that allow them to evaluate their own work and look for ways to improve it.

7. Urge to learn: thirst for the expansion of knowledge
Maybe linked to the on-going improvement habit is the one to keep learning and looking for new knowledge sources.
Effective testers will be the ones bringing up new technologies, tools and techniques to do things better; they will try them out, and adopt or discard them based on the results they got. They will surf the Internet, participate in all sorts of forums and communities, and read books looking for new knowledge sources that will benefit them and the team.



The fact that I came up with 7 habits is pure chance and I will be happy if other people can keep adding to this list and take it to 8, 9 or even 20 habits we should all have to be effective testers!

Welcome to the United States, we’re sorry but the system is down…

Posted in Curious & Off-Topic, Test Process on September 7th, 2009 by Joel Montvelisky – Be the first to comment

I have nothing but the top-most respect for immigration officials at US airports. They sit all day quickly interviewing people who barely speak English, making sure no unwanted person is allowed to enter the US.  Not an easy task regardless how you look at it; and last week I was able to see how this task became even less trivial, for them the officers and for us the travelers.

We arrived in the US on a flight from Costa Rica on a Sunday evening, I am guessing that my flight had something like 120 or 130 passengers and crew.  After disembarking we proceeded to the immigration section and right away noticed something was wrong.  There was a line of about 1,000 passengers; but while all the immigration officers were in their places no one was interviewing passengers, all were talking among themselves or simply resting and staring at the sealing.

When we got to the line we understood the problem as the person in charge of managing the line came to us and said: “Welcome to the US, we are sorry but the system is down“, then after seeing the frustration in our eyes she said this had never happened before and she couldn’t tell us how long we would need to wait.

Here I need to say that my wife is a genius!! Her maternal instincts immediately kicked-in as she told the line manager that we were traveling with 2 small children and had a 12-hour connection in less than 90 minutes…  this gave us direct access to the beginning of the line (and generated angry looks from many people standing in front of us).

When I got closer to the boots I realized how not-out-of-the-ordinary the immigrations computer system was, and how I had already seen situations like this happen to my clients and even to me as a customer.  From the conversations between the officers I understood that the system had fallen some 15 minutes before we arrived, the computers had frozen and they were not able to process any visitors.

During the next 20 minutes I saw how an “IT related officer” (on Sunday night you won’t expect a real IT geek to be around, right?) tried to troubleshoot the problem.  He went through the rest of the officers’ boots and asked them to do different operations based on a printed guide he had with him.  Stuff like resetting the computer, trying to access via a secondary account, taking out stored laptops and trying to log into the system, nothing seemed to work and everyone remained standing there.

The gateway to “the land of opportunity” was right in front of us but it was being blocked by a simple computer that would not connect to a remote system and allow it to make sure neither me nor my family were a “Persona non grata” in the US.

Then, all of a sudden something magically positive happened; one of the officers was finally able to log into his computer and regain partial access to the system.  It took him twice the time to process each person, but 10 minutes later we were able to continue our journey home by stepping out of immigration, getting our bags, rechecking them to our flight to Israel, and reaching the gate running 5 minutes before the final boarding call.

I imagine that in due time the posts managed to get back on-line and eventually all the people in the line, that by the time we left already numbered a couple of thousand, got through the system (or not!).  But this certainly changed the plans and trips arrangements for many passengers, some of whom arrived late to their homes while others must have certainly missed their flights altogether.

This is just another example of how we are all dependent and controlled by Information Systems (in more ways than we care to accept), and how a flaw in one of them can turn our day (or trip!) into mayhem.  Nothing we can do, but learn our lesson well and make sure that as Testers we add “alternative system access and recovery” scenarios to our test plans, to make sure other people will not need to suffer due to the fact that we did not foresee out-of-the-ordinary scenarios that will eventually happen to our systems under test.