My take is simple and I put the bulk of the blame on us The Testers, because many times we bring this upon ourselves by not taking our jobs seriously enough and not behaving professionally in our work.

It was nice to get some encouraging comments from testers I respect, but what I’m after is additional inputs on the subject. Even if you don’t agree with me, I want to hear your feedback in order to learn from it and improve our work!

A look back at the first 5 reasons

I will not go over each of the reasons I already talked about, but it is good to list them here for reference and completeness.

I believe that at least part of the reasons why You are NOT treated as a Professional Tester in your company are:

1. You think testing is not a technical profession, and so you don’t even try to understand the code behind your product!

2. You are not involved in the process until you are hit in the head with a build by development and told to “go and test it”.

3. Your only interaction with a Customers is when your Support Team asks you to reproduce a bug from the field.

4. Risk management is something you practice only in the context of Life Insurance.

and

5. You don’t have a plan to improve the value of your testing.

Now a look at the next 5 reasons
Why You are NOT a Professional Tester!

6. You think your job is mainly about writing and running
predefined Test Case Scenarios

There is so much more than only running scripted tests:
- Providing feedback on the design of your application.
- Analyzing the Risks of your current development plan and project.
- Providing informal feedback during the development stages.
- Developing an automation framework that will help your developers maintain the stability of the product while they work on it.
- Running tests, but definitely not only those you scripted before hand.
- Analyzing the results of your tests and the rest of the information available to you, to provide insights into the status of your product.
- Providing feedback on the process.
And I could go on & on…

In short, the value of your job goes way beyond executing test-steps and setting them to pass or fail!

7. Automation (and scripting) is an Advanced Science, and a project you will work in the future – in your spare time.

STOP coming up with excuses why not to work on automation!!
This is another side of the technical shortcomings of some testers but from a different perspective.

Automation is not a magic pill or the cure to all the problems faced by testers, this is only a sales-pitch-lie from many tool vendors. But still, there are times when using scripts or tools to do part of your dirty-work will make it more efficient and save you time.

The problem is that, again here, some testers feel they are not technical enough to do this, and so they choose not to use automation or scripting to improve their testing. In a sense it is like striking stones or rubbing sticks to light a fire, and refusing to use a lighter while saying that for you it is easier this way…

8. You do most of your testing while standing high on top of you Ego

A good tester is a humble tester! We need to know how to provide feedback, and even more importantly how to receive feedback from teammates and peers.

Many testers get frustrated when team members (specially programmers) give them unrequested feedback on their testing, or when they are queried on a bug that was not found or a test that was not run. Many times there are good reasons for all these “misses” and we only need to keep calm and share this information, but lot’s of testers take these questions as personal attacks on their professional integrity and reply with loud tones or harsh words.

In the same way as you need to know how to report your bugs and provide negative feedback to your project team, you need to know how to receive constructive criticism from your peers.

No one expects you to be perfect, but they expect you to be professional about your mistakes and to learn from them as well as from the feedback you get from the team.

9. You don’t keep track of your professional skill set and the areas where you need to improve next
One of my best managers in the past used to talk about our personal “Virtual Toolbox” as the set of skills each of us carries with him and uses when needed.

- Do you know what tools you carry in your toolbox?

- What tools are in need of improvements or updating?

- Which are the tools that you keep needing, and that you may want to acquire next in order to improve the quality of your work?

Testing is without a doubt a craftsmanship, and without the proper tools (virtual and actual) you will not be able to create the required product.

10. The only idea you have about a career path involves becoming a manager or moving on to another career

Some people get into testing because they think it is a good path into programing. Others do because they don’t know what testing is about and it sounds cool to “play” with applications all day long. After all, how hard can it be, right?

Part of them can end up been good testers (at least I hope that I did!). But most of them will end up frustrated, counting the days until they can stop testing and start doing the work they really wanted to do. While others don’t appreciate the real challenges of testing, and think the only way to move forward is to start managing people.

It is true there are challenges and rewards to managing a testing team, but there are also countless disciplines to conquer that are not related to management and that may give you even more challenges and bigger rewards (and definitely a lot less headaches!)

My point is that, if all the time you are looking to do something else and not focusing on how to test better, there is no way you can do it more professionally. So think if you are in the right place, or if maybe you should simply be looking for something else…?

Want to be professional? Start by looking at testing as a profession!

Looking at these ten points from 20,000 feet I think the line connecting them is the call to change our general approach to testing.

The first step is to start considering testing as OUR Profession.

Once we absorb this first step, the second one is to look at what we are missing in order to become better testers. What areas should we develop? How do we need to approach our work and the relationships with our customers and teammates? And what can we do NOW in order to increase the value of our work?

The third and last step (at least for this short approach) is to plan ahead how to improve, and to realize that as a profession we have much to learn before considering ourselves gurus or experts (if there is such a thing…)

The important thing is to realize that the change needs to come from within, and not from some God-given decree or from the title next to the name in our email’s signatures.

And I don’t mean this because I wrote this post – there are countless other testers who have better stuff to share than I do!

I mean in general, if you are reading a QA-related article in your free time in order to improve your testing skills, you fall into the small (& hopefully growing) number of engineers determined to be Professional Testers.

In search of the Perfect Excuse

Last week I saw another discussion in LinkedIn asking “Why is testing not considered a profession?“ by many people in the Industry.

There were answers ranging from “because testing is not formally taught in Universities” and all the way to “because testing is new and people are still learning how to do it professionally“.

I searched in vane for someone to come and throw the blame back at us, the testers, saying the reason we are not considered a profession is because many of us are not professionals in the way we do our work.

But I guess people were too busy been self-pitying and unjustly-victimized in order to notice that most of the blame resided on us.

Looking for the answers in the mirror

Let’s be honest, wherever we are not treated as (testing) professionals it is because we have not made it a priority to behave like professional testers.

Based on my limited experience, everywhere I’ve seen testers taking their work seriously and striving to improve intelligently, I’ve also seen how they were treated with respect and how their work was appreciated thanks to the value it provided to the Organization.

So to the point:
What are the 10 main reasons
you are not a Professional Tester?

1. You think testing is not a technical profession, and so you don’t even try to understand the code behind your product!

If you work on Software Development you should understand at least a little about software engineering.

As a tester, you need to be able to read code in order to analyze your product and understand how changes and fixes can affect it and cause additional bugs. The days of hiding behind “black box” vs. “white box” testing are over.

You can still get away without writing any code if you don’t want to, but as long as you refrain from reading the code you will be missing a very important input to your overall testing process.

2. You are not involved in the process until you are hit in the head with a build by development and told to “go and test it”

Answer yourself truthfully: When do you start getting involved in the development process?

In theory we’d like to start during the requirements gathering and analysis phase, together with the rest of the team. But in practice we hardly provide any inputs before we are “hit in the head” by the first build from our developers looking for feedback on their features.

Why does this keep happening? Most testers will say that it is because of the “viscous-circle” of been the last link in the development chain; we are always extremely busy testing when “the others” start planning.

But in truth, if you cannot spare 2 hours a day to take part of a feature design meeting it means you are a lousy time manager. It also means that the only reason you are not part of the development process earlier is because you don’t make it a priority; or in other words because you don’t want to!

3. Your only interaction with a Customers is when your Support Team asks you to reproduce a bug from the field.

Part of your job description is to test your product based on the way it will be used on the field and to catch the bugs that will be important to your users once the product is released.

In fact, your job is to be your customer’s advocate within the development team. To plan your tests and set up your environments based on their working behavior. You are also expected to provide functional feedback based on their needs and constraints.

If this is the case, then how can you simulate field work and represent your users if you don’t know them? When was the last time you visited a user to understand how he or she uses your product? Can you really relate to the work they do with your system and with the constraints of their working environment?
I guess the answer is NO.

Go and visit some of your customers! Until you know and understand your users, you will keep doing a lousy job as a tester.

4. Risk management is something you practice only in the context of
Life Insurance.

There are a small number of simple truths in testing; maybe the most trivial of them is that “no tester will ever have enough time to test everything”. This is where Basic Risk Management comes into play, helping us prioritize our work in order to know what needs to be tested (and tested first) and what can be assumed to work based on the results of other tests.

But as I said, this is only the basic side of Risk Management… The more advanced side of it, and one that provides no less value to your team is the one that is not directly related to testing at all!

Every testers knows there are areas of his product that are more risky; areas where there are always more bugs and where the work of the team is always delayed due to unscheduled and unplanned circumstances.

It is part of our job as testers to be aware of these areas and remind the team about them during all stages of our projects. This way we can choose whether to develop the features using different areas of the product, or if necessary schedule more time to stabilize the system, accounting for these “unplanned issues” that will always present themselves.

You should strive to shed light on the issues, whether existing or potential, affecting your product. Helping the team to set realistic objectives and reach your goals on time and on budget.

5. You don’t have a plan to improve the value of your testing.

The Testing Profession is in many ways uncharted territory. There are many paths that will take you into testing, and as many ways to improve professionally once you are part of the Testing World.

Most of these “testing improvements paths” are individual, and will be a mix of the individual capacities of the tester, together with the needs and constraints of his current workplace, and the information sources available to him at the present time.

In short, there is no ONE WAY to develop yourself professionally as a tester, and these improvements will not be easy or come quickly. So, unless you decide you want to seriously invest in your development process, and only after you understand how to achieve this goal, will you be able to really improve your testing skills and the value you provide to your organization.

How do you achieve this?
Start by mapping your strengths and weaknesses as a tester, then decide what areas do you want to develop (that will also be valuable to your Organization), and finally look for the means available to you to develop these skills.

One thing is certain, it will be completely impossible to improve if you leave it to chance, or to another tester to tow you along during his personal development process.

To be continued in the next post…

I made myself a promise not to write posts that are too long. So I will cut this one here and write a follow-up post later this week (or at the beginning of the next week) with the additional 5 reasons why you are not a Testing Professional.

Since I don’t want to leave you hanging, the next 5 reasons are around your career path as a tester, working mainly with scripted testing, not using automation as a tool, and general skill-set management.

Feel free to provide your feedback on these reason, or even provide additional reasons why you think we are not treated as Professional Testers by our peers. I am sure each of us has something good and insightful to contribute on this subject!

Sometimes measuring only one thing
can be worst than not measuring anything at all.

A QA colleague forwarded me a report he sent to his management where he pointed at the fact that the whole R&D Organization was not delivering products at the pace they used to do it in the past.

He was airing out a “known” general concern shared by many testers and developers, and to do this he searched for some “hard data” that would prove this point.

The report was very simple, and it compared the number of releases by all the teams for the last period vs. the period immediately before this one; and it showed that in the last period all the teams together had only delivered about 40% of the releases they did previously.

Simple, right? – WRONG!

What happened with the report?

Immediately after he sent the report, the Team Leads of two of the development teams answered with short emails “explaining” that in the last period they had also had a number of holidays, and attributing everything to this fact.

With this excuse the value the report went down and the subject was erased from Management’s mind and agenda…

The “funny thing” is that my friend had also seen this point, but he thought everyone would see the difference was too large in order to be caused solely because of the holidays!

What can we learn?

There are some basic lessons we can learn from this issue that apply to most organizations

1. Don’t use only one number in order to draw a complete picture

A basic mistake made by many testers and QA Managers is to base all their conclusions on only one number or metric. Basing everything in one measurement is like reaching your conclusions based on only one side of the story instead of collecting information from all possible sides.

So what do you need to do? Look for more than one angle in order to draw a complete picture.

In the case above, the manager could have looked for information about the number of issues detected during the process, or amount of rejections from the field, or at least start by “normalizing” the number of deliveries based on the total number of working days in both periods.

2. Take into account your workplace politics

It is naive to thing that you will send a report pointing at a serious problem and whoever is responsible for it will simply step forward and happily take the responsibility. Victories have thousands of parents, while defeats are usually orphans.

This means that whenever you point to an issue in the system you need to make sure to cover all your angles and to provide information that is, as much as possible, irrefutable.

An important (& ethical) thing to do is to contact the person who may be responsible for the issue and make sure you communicate your findings to him ahead of time, before sending out the report to everyone else. This will give him a chance to come up with ideas on what caused this and even provide as some solutions that you can include in your report.

3. Metrics should include comparable historical information

In the case above, what could have taken down the argument about the holidays?
To compare the number of deliverables not to the period before, but to the same period last year!

Not all metrics are trivial by themselves, and so you may need to compare information in order to see the real differences (or similarities) between them.

In the case of time-based measurements, you need to think about seasonality factors such as:
- Season or time of year
- Part of the quarter
- Time of day
etc.

4. Take into account external factors

As much as you want to be able to measure everything with raw numbers there will always be things you cannot measure that affect your process. You need to research these factors and take them into account in your report.

In the case above, it would have been as simple as stating that in the last period there were also some out of the ordinary holidays, and then add a note saying that even if you factor them into account they would not lower the productivity bellow 80% of the regular level, leaving another 40% decrease in productivity unaccounted for.

External factors will vary all the time, they are the out-of-the-ordinary things that will be trivially visible for people who are living the process. Some examples can be:
- Extraordinary team growth or reduction
- Extreme product shifts or market disruptions
- Things like prolonged strikes
- And even in some cases, as I saw not too long ago in a company, unusual number of births in a team (5 out of 8 team members received a child in a period of 3 months)

Bottom line

One of the main difference between a credible story and plain gossip is that a story has more than angle to it. Your metric’s-based-report is basically a way to tell a story of what is happening in your product/process/team.

So, in your next report or fact-based email make sure you take into account:
1. To have more than one metric or angle measured
2. Company politics
3. Historical information
and
4. Extraordinary factors

It’s not only about what you have in your metrics,
it’s also about what you leave outside of them.

This story begins one day, just like any other day…

The whole R&D department of company XYZ Ltd. is sitting in the Open Space area, listening to an interesting presentation about Kanban by one of the Team Leads.  He is explaining how this process is helping his team to achieve faster deliveries and how it provides better visibility and control over the end-to-end process.

The idea of the Company is that starting from the next sprint (Agile sprint, just in case), all the teams will switch from working under Scrum to some sort of Scramban (Scrum + Kanban) that will allow them to focus on a limited number of tasks, in order to develop their product faster and with more visibility to all the company stakeholders.

The last slide of the presentation is about the 5 things that are “very important” to measure, to ensure the team is working under the principle of Kaizen or continuous improvement:

1. WIP (Work in Progress)
2. Lead Time
3. Waste (efficiency)
4. Throughput
5. Quality

And here is where the session turned interesting.  When someone in the crowd (someone, for example Me) asked the Team Lead how do they measure Quality in his team?  And then all hell broke loose…

Tell me who I am and I will tell you where to find me

The question may sound simple at first – how do you measure quality? -  but if you ask 10 persons from different teams in your organization to define Quality, you will find between 7 and 15 different definitions (some people will not be able to provide you only “one” answer…).  So, who’s Quality will you choose to measure?

Let’s move further down this road, when I asked the forum of Development Team Leaders, once the session was over and we got together to review this point in more detail, we were able to reach the conclusion that we wanted to measure Quality by taking a look at the bugs (bugs are not the only indication to measure quality, but it is usually the simplest and fastest way to start measuring!).

But then we immediately started arguing about what bugs to measure?  Bugs reported “as part of the development”, bugs detected “once the product was released”, or bugs “detected AND corrected once the product was released”…

In short, everybody has an opinion and all of them are valid in one way or another.

What you measure may improve,
what you don’t measure will always fall behind

The biggest problem with metrics is the psychological effect it has on the people being evaluated.

Start measuring something and you will see how it improves:

• How far or fast you run.
• How much food you eat.
• How many hours a week you spend with your wife and family.
• How many bugs you find or tests you run.
• etc.

But since your resources and your capacity are limited, then for every thing you improve there will need to be something else that “pays the price” for it:

• You will be able run farther or faster because you train a lot, but your grades at school may come down because you don’t have enough time to study for your tests.
• You will eat less, but you will also smoke more because you are always hungry.
• You will spend more hours a week with your wife and family (and you will still work the same amount of hours because you don’t want to get fired!), but you will have less friends since you don’t have time to spend with them anymore.
• You will find more bugs, but more of your bugs will be rejected as “not clear enough”, as “unable to reproduce” or as “duplicates” because you spend less time writing them and reviewing them.
• You will run more tests, but since you don’t have more time to run them they will be less complex and won’t represent the user’s scenarios good enough, so in the end you end up releasing more bugs to the field.

What’s the solution?  Is it to stop measuring?
Definitely NO!

The solution is not to stop measuring, as I said before measurements are one of the most effective ways or tools you have to improve things.  But you need to be SMART and take into account that it’s not only about what you have in your metrics, it’s also about what you leave outside of them.

For example, if you will start measuring the speed with which you develop each of your features make sure you also measure the quality of your deliverables.  Take also into account that if you develop each feature faster and don’t harm the level of quality, then you will most probably need to develop less features overall – at least at the beginning of the process.

The same goes for every other measure you can think of!  There’s no free lunch, someone or something will always need to eventually pay the bill (or wash the dishes…)

Define an acceptable price you are willing to pay up-front

A good way to go around when you define a “Set of Measurements” for your team is to take into account the following 3 principles:

1. Keep your metrics simple, easy to calculate, and logical to understand.
2. Don’t use a single metric.  Define a set of measurements with the intention of covering your process and your needs from 4 or 5 different and complementary angles.  On the other hand don’t set more than 4 or 5 metrics at a single time!
3. Provide guidance to your team, either by stating this in writing or by making this common knowledge, about the price you are willing to pay in order to improve your measurements.  In plain English: what other aspects of your operation will you be willing to harm in order to achieve improvements on the measured areas.

By doing this you are making sure that all your team is in sync and this will increase your chances of really improving your process, and maybe more importantly of getting the correct feedback needed in order to modify your process (and your measurements) quickly in case they are harmful or counter-productive.

Got any experiences to share?  Feel free!

Maybe you have some interesting stories to share about metrics, please feel free to add them as comments!

From my experience, many of us have “lived through” metrics-abuse-catastrophes in one or more occasions, so I’ll be happy if for a change some of you have been part of experiences or have insights about situations when metrics were used smartly (maybe also in an unconventional way!) and were able to really make a difference…

There’s the challenge of working with new technologies, new languages and even new platforms; forcing us to investigate and learn how to cope with these new paradigms.  But in a sense all these technical issues can be easily solved by turning to the best-friend of most geeks (like me).

Chances are that if you are asking yourself what tools to use in order to automatically test a new technology, how to write tests for a specific scripting language, or what are the weak spots on an operating system or mobile platform; the answers will already be available on the Internet, written by some early adopter or tester who took on the challenge and posted a paper or blog explaining what he did and how.

But the real challenge is coping with the things that cannot be searched on the Internet, and the ones you will need to figure out by yourself. I am referring to the functional and business aspects of your new application and the way your users will work and interact with your product once it is released.

Who do I  talk to in order to get information?

The first question to ask is “Who do you need to talk to in order understand what to test?” and the answer, at least in the beginning of the process, is simple – TALK TO EVERYONE YOU CAN.

When you start a new project or when you’re asked to test a new application you need to start by mapping all the people who can provide you with information.  So make a list of everyone you can talk to – Marketing, Development, Sales, Support, the CEO – and try to talk to each of them in order to understand what you need to test (and why)!!!???

Even if you don’t manage to talk to all of them (sometimes it can be tricky to get a 30 min session with your CEO…) at least try to make the list and cover as many different people as possible in order to get different perspectives and testing inputs.

What questions to ask?

Here is the hard part of the problem…

Imagine the following scenario:

You finally schedule the meeting with your CEO in order to get her inputs into what should be tested in the system. You arrive at the meeting and ask her: “Mrs. CEO, I have been given the task of testing the new product, and I wanted to ask you what do you think should be tested?”.
She stops and looks at you for a couple of seconds before answering: “Well, I don’t know, aren’t you the testing expert here…?  I guess you better test everything, right?  We don’t want any bugs slipping out the door, do we?”

What’s wrong with the scenario above?  Well, basically we came to the person and asked him the wrong questions…

If you pay attention to what the CEO said she was right, we are the testing experts.  She expects you to come up with what should be tested in the system, but on the other hand she is also living under the illusion that everything should or even can be tested (something we all know is impossible and even when possible, not economical in the long run).

The problem here is that we asked someone else to do our work for us, to come up with what to test, instead of asking for the input we need to understand by ourselves what needs to be tested and how.

So going back to our CEO meeting scenario, what questions would have been valuable to ask?  Well, you need to ask for her inputs on the system, without even talking about the testing operations.  Try to understand what areas are important from a user perspective, or based on our competitive advantages, or based on what makes our application unique, etc.  You should focus your questions on what is important for them.

Here are a couple of examples you can ask your CEO or VP Marketing or even Director of Sales:
- What are the most important aspects of our Product?  The things that make us unique?
- What areas in the product are the most widely used by our customers?  What type of things would make our users angry and make them choose not to work with our product?
- Where is the market focusing on today?
- How are we better than our competitors?  What areas are the ones that are the most problematic in our competitors, the same areas where we want to exceed?
- Are there any risks you think we should be specially aware off?  Risks in our technology, risks in the product?

Notice that we didn’t ask them what to test, but we did ask what’s important in their eyes (based on their experience).

In the case of the CEO, Marketing and Sales functions we will want to talk about stuff that relates to the functionality of the product.

If we were to talk to our Support Team we would ask them questions related to the areas in which our users find bugs, focusing both on the places where there are the largest amount of bugs as well as where the most critical issues are found.

Finally, when talking to our development peers we will ask them about technological risks, as well as places where they are making the most changes, or where the product is relatively weak or complex and so where we should be putting more testing efforts.

The art of listening (and putting together the puzzle)

So what do you do with all the information?  Basically you need to take the stuff you got, and process it in order to get a 360-degree reading of your application.  What do I mean by 360-degrees?  I mean from all the different angles that matter: Technology, Usability, Supportability, Competitiveness, etc.

After all, your work is to test and to provide visibility into whether the application is meeting the quality standards of your users and stakeholders.  The only way to do this is by understanding what’s important to all of them and creating a test plan (or work plan!) that will effectively cover it.

In any case it was good that it took me some time because it helped me refine my ideas and consider some points I had not included during my first revision of the subject.  Only thing is that because I don’t like very long blogs I won’t be finishing this subject on this post, but will be writing a third (and hopefully last) one later this week.

Revisiting the game-changing factors

In the first part of the article I mentioned 4 game-changing factors:

1. Time to market revolution
2. Commoditisation of technology
3. Globalization
and
4. Virtualization / Cloud Computing

While talking to a friend last week I realized there is one human-behavioral-pattern that serves as the underlying motivation for all four of them (and many other less significant ones) and unifies them into a single change-wave:
Our race to shorten the time we are willing to wait to get what we want, or using the psychological terminology -

Our unwillingness to Defer or Delay Gratification

I will give a couple of examples of this race:

Example 1 – Food Sources & Alimentation
- Some 10,000 years ago we (the human race) developed agriculture as an alternative to of collecting fruits and vegetables from the wild.
- The first recorded restaurant dates to the 11th century in China
- Around 1850 the refrigerator is developed to maintain food and other products available for making food.
- In 1921, the first Fast Food Restaurant is opened, White Castle, serving hamburgers in the Eastern United States.
- In 1953 the first TV (frozen) dinner is sold in supermarkets.
- In 1967 Amana Corporation delivers the first “Personal Microwave Oven“, by the mid 70′s the technology was economic enough to make it a house-hold item.

Following this train of events, the day is not very far when we’ll have a “food replicator” like the one in Star Treck that instantly creates any food we want (regardless of what planet it originated from) in a matter of seconds.

Example 2 – Communication & Messaging
- Some 3,000 years ago people communicated sending a personal courier or simply walking/riding to the place where the other person was.
- Around 550 BC in Persia someone invented the first Postal Service, in Europe this was around 1500; but even before that there are references to homing pigeons or pigeon post.
- In the 1800′s the world is revolutionized by the invention of the telegraph. Then once again in 1844 with the invention of Morse Code.
- In 1876 Bell invents the telephone.
- In 1973 we took a big step forward with the invention of the cellphone.
- Some 100 years after bell on 1983 (there is no one date, but this one seems like the best to me) the Internet is established.
- Today we have email, twitter, sms, and Skype on our cellphones, and I didn’t even mentioned regular phone calls.  It takes less time for news to travel around the world than it does to get to the other side of town, and the truth is that people want to be in touch and up-to-date all the time!

I wonder how long it will be until we get direct streaming of news and messages directly to a chip in our heads in order to save the time it takes to see the news or read an email or sms message.

How is all this related to testing???

To drive the point home, the World is in a constant race to make things faster and to get results quicker.  This is also what’s driving our industry (the Development and IT industries) to deliver products faster than ever before, and in many ways it will dictate the future of our testing careers.

What will change for the testers?

As I wrote, I think that changes will centered around 3 mains paths:

- The Tasks of the Tester (his responsibilities whiting the team)
- The Testing Infrastructure (the tools used during the testing tasks)
and
- The Profile of the Tester

The Role (tasks) of the Tester

The biggest change for us as tester of the future will be in the role we play as part of the process:
- Who do we serve?
- What value do we provide?
- How do we interact with the rest of the team?
All these aspects will change in the future in order to make the development process faster and to complete our products and deliverable faster.
1. The new objective of the tester:

“To ensure the stability of the product throughout the development process”

If up to now our objective was mainly seen as stopping bugs from being delivered with the product, we will see how the value of testing starts flowing up-stream within the development process, and how the biggest value of the tester in the future will be to provide tools (tests, risk assessments, etc) that ensure the product is stable all the time, and not that it only reaches stability a couple of weeks before release.

How will we do this?
- By concentrating more on automation that helps developers constantly test their changes.
- By helping the team understand the risks in the changes being done to the product, avoiding flaws and bugs before they are written into the code.
- By working together with the programmers, catching the bugs they are writing into the code as they do this, instead of testing the product and reporting the them 2 weeks or 2 months after the code was written.

There are many things we will do to ensure stability; but the important thing is that instead of focusing on bug detection, we will really be working on bug prevention as part of our process.
2. No more Organic Testing Teams, testers will be a part of the Atomic Development Teams.
The second change in the role of the tester is related to the place in the Organization where we do our work.  I see Organic Testing Teams disappearing, leaving way to testers being part of Atomic Development Teams, and in some cases creating a kind of matrix-reporting structure to a Director of QA that oversees the quality and testing processes for the whole organization.

The reason for this is that the QA Engineers will need to work more and more time directly with their programming colleagues and it will “make more sense” to have them as part of the development team than for them to report to a QA Manager that is not qualified to help them control their priorities or working schedules.

We see this very strongly in SCRUM teams, but I believe this behavior is not singular to scrum and we will see more and more teams shifting from separate organizations structures in order to increase the communication and the interaction between the testers and their programming colleagues.
3. Coordinators or ambassadors of the development to external teams.
The last thing changing about the role of the tester of the future is that she will be more and more in charge of coordinating the communication with other teams (product, support, other development teams, customers, etc).

This will happen due to the communication requirements we have for testers and also due to the fact that we require from them to be more connected to the “business aspects” of the process and to be fully aware of all external factors that may influence the product and the team.

Being more fitted to communicate and interrelate with other players of the Organization, I expect we will see testers taking a more active roles in representing the team with other teams.

Changes to the Tools and to the Profile of the tester of the future

Since this blog has gotten to big I prefer to close these 2 last points on a third post that I hope to publish by the end of the week.

My apologies for keeping you in suspense

I was asked last week by Qualitest, a test outsourcing firm in Israel, to take part on a Half-Day Seminar around the Future of Testing.  I was flattered by the invitation, specially since they asked me to do the closing presentation titled “Testing in 2020″ where I would present how I foresee the Testing World 10 years from now.

In preparation for the talk I did some research on the subject, asked for opinions from fellow tester both in Twitter and QAForums, listened to an interesting web presentation by Dr. James Whittaker sponsored by uTest, and finally decided that my best approach would be to look at the subject from my own experience and perspective.

Taking a look at the year 2000

So let’s start by looking back at how the testing world looked like 10 years ago…

• Testing activities were isolated from the rest of the development tasks, and they got performed mostly after all the programming tasks had already been completed (in many cases when most of the development team was already working on their next project!).
• Our “Test Engineers” where mostly developers fresh out of college and without any experience.  Trying to be sincere, these guys were mainly trying to land their first jobs as programmers and somehow ended up testing…  There were other cases were testers were not developers or people with formal technical skills but regular Joe’s (like me!) who got offered college jobs by some friend or relative.
• Automation projects were something we saw as extremely complex or altogether unreachable objectives, and to make things worst due to the selling tactics of some software vendors our managers thought of automation as the magical cure that would solve all their bug and quality problems.
• Lastly, between 1998 and 2001 was when the vast majority of us started doing some sort of outsourcing.  Back then we did it because our managers thought it would radically lower their costs, even tough we knew it would elevate the risk in our projects in a disproportional way to any cost advantage gained by it.

Factors defining the future of the Testing World

The Change Engine is a big machine that starts moving slowly and gains speed with time as more and more people recognize the potential of the new technology or simply adapt to the economic reality changing around them.

I believe that the factors that will define the future of the testing (and the development) world in 10 years are already present around us.

For me the biggest or more important of these factors are:

- The Time-to-Market Revolution - shrinking the time-windows we have available to deliver our products and still be competitive in the eyes of our customers. If some years ago we could release versions every 12-18 months, today many of us run delivery cycles of 1-2 months, and I believe this will go down to 1-2 days in the next 5 to 10 years.
- The commoditisation of technology – reducing or eliminating the cost of most of the technological products needed for our work today.  If for example some years ago we needed to invest thousands of dollars to get good automation tools, today we can use Selenium or Watir for free; if back then a good test management system meant using something like QualityCenter and paying tens of thousands of dollars a year, today you can get a good test management tool like PractiTest for prices affordable by most organizations.
- Globalization - where international and cultural boundaries have been blured and are slowly dissapearing (at least in all that’s related to the IT and Development worlds).  Today most of us are already “masters” in cultural and communication bridging techniques, necessary to talk to our teams spread all over China, India, Europe, the US, Australia and soon enough the Moon and Mars too.
- The Cloud / Virtualization Revolution – that together with the comoditization of technology, make it possible for us not only to access cheaply unlimited computational resources, but to do this practically instantly.

What will change in 10 years from now?

I think the testing world will change mainly in 3 aspects:
-  The tasks performed by the testers - or what will be the main responsibility of each testers within her team.
-  The testing infrastructure - or the tools we will use to manage and perform our testing tasks.
and
- The profile of the tester - or what will be the profile and the qualifications of the testers of the future.

I will expand on each of these changes in my second post, that I hope will be out in the next 2 to 3 days, for now I will be happy to hear if you have any additional ideas about the points I wrote up to now.

Guys, this is a lie! The lie we tell ourselves when we need to rationalize why we are not doing our jobs right.

As testers our job is not to be the gate-keepers standing in the way of buggy software from being released. But on the other hand we should not limit ourselves to reporting bugs and then keeping quiet in the corner while the “big boys” decide on whether the product can be released now or later. If this is the way it works in your company then the problem resides on YOU and not in the rest of the team.

Respect needs to be earned

If your team does not listen to you it might be because you have nothing interesting to say. Take the time to understand what is the value you are providing.  If all you do is write down bugs, then don’t expect them to come and ask for your opinion on the readiness product.

If on the other hand you are constantly providing feedback on the product and its functionality, doing this based on your understanding of the users and the business needs, you will see how developers and product managers alike start adding you to their decision forums and seeking your opinion constantly.

Define your job as providing information and visibility and you will be adding more value than simply reporting bugs. The amount of respect you get depends on the value you add to the team.

No one likes a “party pooper“

I’ve seen many test engineers who are happy to find bugs that end up delaying the product. They feel pride in walking to the development manager with their chest up high and telling him about the show-stopper bug that will certainly delay the product for another 2 weeks.

Sometimes there is nothing we can do about it, part of our job is to deliver the bad news to the team but there are always more than one way to do this.

As a team player you need to “want to deliver the product” and the value it will provide to your team and your users.

If you don’t want to release on time, chances are you are not going to do it. But if you work release-driven, you will proactively plan your tests with the development team in order to “attack” the high risk areas first and find the complicated bugs as early as possible allowing enough time to fix them before the release is due out.

Change your mind-set and become a team player. Understand that you are working with the programmers and not against them.

Don’t be “the boy who cried wolf”

Lastly, many tester like having all their bugs fixed (who doesn’t it!).  But we need to understand that business value comes first and so it’s OK that not all our bugs will be fixed. This is specially true for bugs that are found late in the process or bugs with low user-value.

Your job as a tester is not only to report all bugs, but also to give them a severity and to provide information that will help other team members asses your view. If you make a fight for every bug you open (or if you give high priorities to all of them), soon enough people will stop paying attention to your bugs or to the times you take a stand to defend them.

Choose your fights and concentrate on the things that matter.

The change starts with you!

Make no mistake, the first step on getting recognition starts with you. Take the time today to understand how you can add more value to your team and to your product.

In the beginning it will take time, and you may even get some strange comments from your team on the “new approach” you are taking, but if you are on the right track soon enough people will start changing their attitude towards your work and you will see the difference.

Good Luck!

This break from writing was not intentional and it was not really a break since I was really busy with tons of PractiTest work and some additional heavy-duty chores related to caring for 2 small children during their summer vacations.   But there was also a positive side to this pause since it gave me a chance to reflect on what I’ve written on the blog so far, the subjects I’ve covered and those I haven’t gotten to yet.

I did something interesting, using “wordle” (a very cool app!) I generated a word map of the blog’s content:

Word Cloud for the QABlog

It was no surprise that the word TESTING came so strong and central, but there were also some other words that took an important place and I want to take this chance to review them.


SHARE – Sharing is (almost) always positive, but in Software Development and specially in Agile Teams it becomes one of the biggest success or failure factors.
I am currently reading “Agile Testing” by Lisa Crispin and Janet Gregory and it covers this point broadly with many reasons why sharing and collaboration are two of the most important factors for succeeding in agile processes.  By the way, the book is a great read and I recommend it even to testers who are not part of Agile Teams.


TIME – If I had 3 wishes they would be happiness for my kids, world peace, and a 32 hour day!  Time is one of our most valuable assets and so we need to learn to manage it correctly.
But managing time is not enough, we also need to learn to respect it, both our time and that of our colleagues.  For me personally the biggest time waster is context switching. When I stop what I’m doing to read mails, answer IM’s or phone calls, or even when someone walks up to me to ask “just one small question” it takes me between 5 to 10 minutes to reach the level of concentration I was before the interrupt.  If you do this 2 or 3 times an hour you end up spending half the time just getting to restart your work.  Can you relate to this?


THINK – this is a big one!
Most of us don’t really think as much as we’d like to accept, we are mostly busy reacting to what is going on around us.
To really think we need to take a time-out, breath deeply for a couple of minutes and clear our heads from all the urgent things in order to focus on the important ones (notice that most times the urgent things are not necessarily the most important ones!).  When was the last time you did this??
Whenever we take the time to THINK we use our resources better by investing them on the tasks that are really needed.  It’s a shame we don’t get to do this more often…


DEVELOPERS – these guys and galls are our biggest allies, and yet they’re also the ones with whom we tend to be most in-conflict during our projects.
Our relationship with developers makes me think about the classic book “Men are from Mars & Women are from Venus” by John Grey.  In fact we need to understand that the issues between developers and testers are mainly linked to the fact that we are 2 different species (or at the least belong to 2 different cultures) and in order to communicate and work together we need to understand and respect the principles of the other side, what’s important for each of us, and how each one approaches problems and challenges in his own way.
The key lies in understanding & communicating with your colleagues- just like in all types of relationships.


PERSPECTIVE – one of my personal favorites and closely related to thinking.
When you are in the middle of the forest it becomes too hard to look at the trees.  Perspective allows us to take a new look at the issues we are working on and check for new and interesting stuff even in the places we’ve already visited multiple times before.
Gaining perspective is relatively easy, you just need to fully focus your attention on another subject for some time and then revisit your previous task.  Just by switching context you will be able to see things under a different light.
I use this all the time: when testing to make sure I really covered all the important scenarios; when trying to solve problems by looking for different approaches that may give a better result; and even when in I find myself arguing with a colleague when I take time-off to cool down and think about the stuff that is really important.  Give it a try, and tell me if it worked for you!


Lastly an interesting pairing of words that came out of the random image:
GOOD SCENARIOS – something I have not talked about much in the blog but a subject I think I will write about in the near future


I am hoping that now that summer vacations are reaching their end, and after having released some pretty amazing stuff in PractiTest that we were working on for a number of weeks, I will have some more time in my hands to continue posting more regularly…

It all started while talking about parenting…

I had a short chat with James Bach the other day.  We didn’t talk about testing, certifications or software development; we talked about the challenges of being a good father, a more challenging task than any software project I’ve ever seen.

After that I tweeted with James and he sent me a very encouraging message saying (don’t remember the exact words but along the lines of) that he thought I would be a good father since I was self-critical.

The term SELF-CRITICAL got me thinking.
I started by analyzing how my self-criticism has helped me in almost every aspect of my adult and professional life.  Then I looked at the people around me, and realized that I was (and still am) able to work and communicate better with those in my environment who are able to auto-evaluate themselves and accept criticism more openly.

My conclusion was that the most valuable asset a self-critical person brings into a relationship is his ability to improve it by dynamically learning from the wins and losses, and evolving as the circumstances continue to change all around us.

What does this has to do with Testing?!

Well, the trivial answer is that it has EVERYTHING to do with testing!
The tester is the player in the development team that needs this quality more than anyone else.  The main reasons for this being that:

1.  Testing is a constant-learning activity.  As you run your tests, you analyze the result and evaluate them in light of your previous assumptions, in order to modify and even re-determine your testing path(/s).  The only way to do this effectively is if you are constantly open to self learning and ready to throw away your previous assumptions based on the feedback you get.

and

2.  You will never be able to provide good and deep criticism to the people around you if you are not able to accept such feedback yourself.

The most brilliant testers I’ve worked with share at least one common trait: they’re happy to learn from their mistakes, and are always willing to learn from what others tell them about what they were doing wrong and how to do it better.  Once you start accepting criticism freely you develop the ability not only to give and accept it from others, but also to give it to yourself and get it by constantly questioning if you are doing the right things.

So what is self-criticism?

It is the realization you are not expected to be perfect, since apparently no one is.
It is also the “permission” to make mistakes and errors in fair judgment, as long as you are willing to learn from them in order to make a better future.

It doesn’t mean that there are no consequences to your mistakes, but that these consequences don’t mean you cannot correct your actions the next time you have a chance to do it right.

Going back to raising kids, self-criticism might be the most important instinct we posses and one of the things we need to help develop in our kids; it is the principle that allows us to learn to walk by letting go, falling down and trying it again, realizing that falling-down doesn’t really matter in the long run.