PractiTest QA Blog

There’s a weird believe that we Testers need to be pessimistic in order to be good / professional / successful.

In a course I impart (where I am required to use slides made by a colleague) there is even a bullet saying that good testers require “professional pessimism” as one of our main traits.

I apologize to the person who came up with this notion, but what a bunch of crap!
Most of the greatest testers I know are Fearless Optimists, and I think this is actually one of the trait that makes them exceptional testers.

Testers need to be optimistic in order to be able to find a huge showstopper bug and instead of saying “This is it, this App is Busted!” and turn to another task, continue our testing task with even more strength to find additional issues that require fixing and make sure the App is released correctly.

A person needs to be first of all an optimist in order to be a dreamer, and only a dreamer can sit with a design document or a screen sketch and come up with user profiles and scenarios that will allow her to test the AUT realistically.

And maybe most importantly, only an optimist can come to work each day to find bugs and look for flaws in the work of others, and do this convinced that he is doing it for the greater good of his team, his friends, and his company.

So next time you hear someone saying that you need to be a pessimist in order to be a (good) tester do all of us a favor and correct this person, and remember to do it with a smile on your face

I beg forgiveness to all NBA fans, since this post relates mainly to all the rest of the basketball leagues (College-league, Euro-league, etc.) where most players are mere mortals

I read a comment on a newspaper this weekend saying that “Team X” had won a game due to its defense.  This reminded me of a game I saw last week while I was *running* in the gym where 2 college teams were playing and it was obvious that the team that was winning, and not by a short margin, did not really have a better percentage from the field but they were “kicking-ass” on Defense, specially winning almost every single defensive.

If you ever played basketball you know that you need to have talent to play good offense.  But in order to play defense you don’t need talent, you need physical endurance and most importantly you need DETERMINATION.  I learned this in my high-school basketball team where all my friends had talent and I decided I also wanted to be part of the team…

But what the heck has this to do with Software Testing???  Everything!

It is true that you can have a natural talent to “attract bugs to you” whenever you log into your Application Under Test, this will certainly not harm you as a tester.
But a great tester is the person who is 110% determined to do the best possible testing job all the time; who’ll work with all his heart even when the task may be less “glamorous” than the one being done by the developer sitting next to him; and who’ll play with his “eye on the ball” but with his head focused on the objectives and goals of the whole team all the time and specially during the hard times.

I think that in the same way as basketball games are won with points but lost with a bad defense, and the teams who succeed in the long run are those with a strong and stable defense; our companies and products sell in the short run with fast features and cool functionality, but in the long run the ones that succeed are those with a high quality and stable product.

So just like in basketball, you need to keep your eye on the ball but your head focused on the objective of the team; and…

DEFENSE – DEFENSE – DEFENSE!!!!

There is a Marketing Saying along the lines of:
“If you do something but you don’t advertise it, it’s like you didn’t do it at all”

This saying is also very accurate in the case of testing, where if you do a test that finds critical issues but then you fail to report them it is as if you had not done a thing (or worst!).

So the trivial lesson is: Find a bug, make sure you report it.

But as Test Managers our problem is more complex than this.  At times, even if we work right and report all our findings to the rest of the team, we see them disregarding our warnings and acting as if we had not said anything to them (e.g. choosing not to fix critical issues, or  releasing a product that is not ready for the market).

We can try to blame the rest of the Organization for failing to listen, but this would be “taking the easy way out”.  I think that most of the times when the rest of the team fails to understand what we are trying to say it is because we didn’t communicate correctly with them.  Or as a friend of mine once said, because our message was “clear as mud“.

Thinking about your audience before writing

Providing information is about telling people what they need to know, when they need to know it, and in a way that will be useful to them.  We need to think about our readers, in this case the rest of the Development or Management Team, and understand what information they need and in what format it will be useful to them.

Many times we write reports as if they were intended to be read by the QA team only.  They include information in a format and style that may not be easy to understand by people outside our team, or that can even be alienating for non-technical people.  In many cases we simply write too much information that is not useful to anyone!

Our external documents and reports need to be formatted based on the needs and customs of our readers, and include the important information in a way that will make immediate sense to them, and will allow them to make decisions quickly and easily without the need to decipher, analyze or in some cases even translate the information from our internal jargon to the non-techie language they understand.

Remember that many times, and specially in written reports, Form is as Important as Content.

Deciding what information should not go into the report

As I started writing above, one of the most important things is to decide what information to include and what to leave out of your reports and documents. Your audience (the people you want to read your stuff!) have limited time and they expect you to choose what information is relevant for their decisions.

People expect you to to understand what stuff is important and what is secondary to the decisions being made.  If you are not sure about this you can consult with one or two members of your audience, and try to understand not only what is important in your current report but what are the principles that make something important so that you won’t need to consult with them all the time.

Value your audience’s time and they will value your opinion.

When to speak up and when to keep quiet

A critical aspect when taking part of a meeting or review process is to decide when to speak up and when to keep quiet.  What you are trying to avoid here is to be taken as the guy (or girl) who is always bringing forward the negatives points on each decision, and when there are not negatives points to make them up just for sport.

Even if your task is to bring forward the risks, bugs and drawbacks you need to make sure to point them out only when relevant and not to fall under the definition of “the boy who cried wolf” in your team.

Provide Information and Stop Being the Gate-Keeper

To summarize, we need to keep in mind that our Job as Testers is to provide the information that will allow the Management Team to make the right decisions.

Management are not very interested in our tests, mostly in our information.  These guys want to know whether the product can be released.  If yes with what risks or potential bugs, and if no why and what needs to be achieved (or fixed) before we can do it.

Some of the most impressive testers (and some of the greatest developers) I’ve worked with have one personal attribute that sets them apart from the rest of the team: They are always learning new things to apply to their work.

Take a look around your work-place and think about one or two members of your team who fit this criteria.   These guys always know about the new methodologies, tools and practices making waves; and they are the ones who introduce these things to the rest of the team.  Their opinion is respected since they are a reliable sources of knowledge.  And maybe most importantly they are valued because of the way they improve the work of the organization.

How do they do it?
You can go and ask the guys sitting close to you, but from my experience it is really straight-forward:
1.  Make a list of sites and blogs that regularly post the important stuff, if possible subscribe to their daily letter or news feed.
2. Whenever you have some free time, or when you need a break of what you are doing, go over these sites and mails making notes of the stuff that sounds interesting or important.
3. Set time aside and instead of surfing through facebook or playing solitaire review the articles, download and play with the new software, or simply think about how you can use the information you just read in your day-to-day work.

Once you start doing this you will see that not everything you read or “play with” will be worth using, many times it will be as little as 10%, but with time and experience you start differentiating gold from dust quickly enough.  And even when you learn and try something that is not good enough, the experience will help you to tell your company why not to use this when someone brings it up in a meeting 3 or 4 months from now.

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!

I am presenting the subject of Testing Intelligence on next month’s CAST Conference.

One of the things I like about the CAST approach is the fact that they promote the dialogue and (safe/constructive) discussions around the topics and sessions presented, allowing presenters and audience to gain from the experience.

The other thing I like, this time solely as a presenter, is the fact that even before the event starts you begin getting feedback on your paper and presentation in order to reach your session as ready and “polished” as possible.
In my case this means that some very insightful people went over my paper and gave me good feedback that will make it more focused and help me communicate my message in a clearer and more effective way.

Last week I was busy providing an ISTQB Certification course (will write more about it later).
There is a whole chapter in the course dedicated to “static testing & reviews”.  Two central objectives of this chapter are (1) to emphasize that reviews can be done on any document; and (2) to explain that the value gained from reviews is extremely high even though people tend to underestimate this value.

I think that the review process for my CAST paper is a great example of these 2 points and some additional personal inputs I just realized.

Going back to the feedback I got on my paper, the reviewers asked questions that made me realize my paper did not communicate the message in a clear way.   They also offered suggestions to make it more easy to follow and comprehend.  And finally one of them gave me and idea to add to the initial model to make it more robust and applicable to more organizations.  In short, I GOT EXCELLENT FEEDBACK FOR FREE!!!

The funny (or sad?) thing is that I had not thought of asking for feedback or peer reviews before I submitted this paper, or all the other papers I’ve published in different conferences and magazines up to now…
This made me wonder why, and come up with a couple of interesting thoughts on the subject, at least focusing on myself.

Why didn’t I seek feedback previously?

1.  I was not sure I would get real value.
I had not realized that there are exceptional colleagues out there that take the time to do a thorough read and provide insightful comments just for the sake helping out.

2.  I was afraid of criticism.
I think this is true for all of us: we are afraid of rejection or getting hard criticism on the things we hold dear, even if we are talking about an idea or a paper.
Then I realized it is better to get a partial or total rejection earlier from people I trust, than later from total strangers.
In any case it is not easy to get comments and criticism, but it is definitely something we all need to work on.

3. I didn’t realize it would be so easy.
I never thought it would be so easy to get the feedback in the first place.
There really are (high quality) people out there willing to take time of their busy schedule to help you out just for the sake of good comradeship.

NOW I’M SOLD!!!

I made a mental vow to make sure I reach out to my peers and colleagues and ask for their feedback whenever it might prove valuable.

Since nothing in life is free, I am also opening myself to anyone who would like to get feedback on the things they are writting/developing/thinking/etc.  Just drop me a line and I will do my best to serve as a white-board where you can bounce your ideas in order to get (hopefully good) feedback.