We, testers, are we all alike? Looking back over the years I’ve been involved in testing, I would say I have met a whole bunch of different testers. Some shared my passion and fascination for testing, others were not testers they just happened to have the job title. However, I have always appreciated our craft for having such diversity of people. We have testers that have strong domain knowledge, programming skills and business knowledge. All of those are easy to connect the value to have in a test team, they find important information about the technical implementation of the product.

Then we have the other group, the ones who have capabilities in philosophy, cognition, history, economics, art, music and myself a drop out from statistics at university. We are not here because we love code or the coolest technologies, we are here because we love the way people and products interact and misunderstand each other. We are fascinated by the dance between a human and a machine. We find patterns in this dance, we find unintentional behaviors, and the unexpected surprises us. We look beyond constraints of the application, we go where no developer intended to go. By doing this we notice other kinds of things that might be a threat or a problem for the success of the product. Why are we doing this you may ask? It is because the technical solution does not impress us, we do not take particular interest or care in what specific way the code is written. What drives us is the question: will this solve a problem for a user and in which ways can it fail to do so? What we bring to the table is the social and behavioral science aspects of the product combined with the human element. At technology facing companies I sometimes see the above overlooked or under-valued.

But what worries me more is that we, testers, are walking away from my precious diversity. Strong forces favor uniformity among testers and the most obvious one is ISTQB. After going through their program of various certifications everyone knows the same, speaks the same language and uses the same templates. There is no problem replacing one ISTQB Advanced Level certified test manager with another one with same level of certification. The same goes with TMap, as long as you can read the book you know the answer to all testing problems, it’s easy!

But this is nothing new, I and many with me have been fighting both ISTQB and TMap for years. But here comes the kicker, have you heard of this cool new thing called “agile”? It’s a really sweet thing, close to a drug in our craft. It came and it has conquered. Nowadays there are almost no companies who dare say that they are not “agile”, instead they make the most ridiculous variations of what they call “agile”. Don’t get me wrong here, this new movement is quite appealing to me and I appreciate much of what it stands for.

Now getting back on track there is one thing that worries me about this agile thing. That is the view on us testers. Now to be an “agile tester” you basically need to be a developer with preferably some basic knowledge of testing, but it is much cooler if you know Selenium, TDD, ATDD and other strange abbreviations. If a tester according to the agile folks is basically a developer, why do you call them a tester, or wait you don’t! Everyone is a team member, I’m sorry.
Now we are walking from “must have a certification” to “must have programing skills”. Guys, don’t you see what is happening. We are just replacing one uniformity with another, beware of this!

We are running a great risk that all our testers are finding the same information and worse, are blind on the same spots. In testing we do not know what information we will get and we do not upfront know what questions to ask the product (don’t be mislead to believe anything else). We have to approach the testing from various different angles and have several different ears and eyes observing it. If one thing, we should love diversity among testers and we should encourage it.

This post came to my mind when I once again listened to Malcolm Gladwells brilliant TED Talk.

And no we do not all want black coffee!

Typecasting is the process by which a film, TV, or stage actor is strongly identified with a specific character, one or more particular roles, or characters with the same traits or ethnic grouping. For many actors this has been a nightmare, even if they have earned a fortune on it.

I believe that some of us testers are being typecast; and even though we might be good at what we do in our role, there is a problem for many to change their role once they have been typecast.

Sean Connery was once asked how to avoid being typecast, he said, “First you have to be good enough that they ask you to play it again and again”. And this could very well apply to typecast in testing; and notice that Sean’s explanation “good enough” means that you play the role good enough even if your role is to be “unskilled”.

Here are some examples on when you have become typecast; and why you should try to break out.

1. The novice tester
   We are all novice testers in the beginning, but for some testers, this label won’t go away. When work packages are dealt out in the team and you feel that you are always treated like the novice tester, it is time for you to step up and move away from this.
2. The technical expert
   We all have different backgrounds that we bring into testing. For some testers this has been a burden that they can’t get away from. Let’s say that you are a database expert or application server expert, then it is very likely that you will work with this in testing as well; at least in the beginning. But you know when you have been typecast when you always get to do the tests against the database even though you would like to try out other areas; you know that you have been typecast when you always are assigned to do the platform tests on different application servers even though you hate it.
3. The specific-persona tester
   Again, testers coming from different backgrounds might also affect you by always getting to the play the role of a certain persona when performing usage-centric testing (scenario testing, soap-opera testing, persona-based testing, etc). You know when you have become typecast when you with your clerk background always have to put on the clerk-persona mask every time there is a need for testing from a user perspective. Or if you come from sales and have been on the field for several years, there is a big chance that you always will be the sales-persona speaking for all sales persons in the field. Besides being boring for you, this is dangerous for at least two other reasons: the others make you responsible for all users of your category which enable for them to blame on you: “X said that this was what the users would expect”; and the others don’t need to think about these users and the problems that they might face leaving you with the task to come up with all problems yourself.
4. The unskilled tester
   Similar to the Novice tester, you will end up doing all the easy and/or boring stuff that no one else need to do. This might happen because you once were unskilled, but even though you have evolved over the years you are still treated as the unskilled tester. You know when you have been typecast as the unskilled tester when your tasks always are the uncomplicated ones; or when you always have to do regression testing that no one else want to do. Also, as tempting as it might be sometimes, growing your strategic incompetence might as well make you end up being typecast as the unskilled tester – for life.
5. The bug verifier
   Even though it is good to learn about the product by verifying other peoples bugs, you might become so good at this that you are being typecast as the bug verifier. On every new build, you are assigned to verify bugs that have been fixed in the build, while the rest of the team start to test the new (and interesting) functionality. Being typecast as the bug verifier will inhibit you from a lot of creative thinking which is so important in testing; and this might make you blasé and start becoming inattentional blind to important things in the periphery.
6. The super tester
   Being a super tester is nice, but sometimes this might be a burden upon your shoulders. You are always expected to find all the hard things that no one else seems to find. Not only can this be too much of a burden for you, but it also enables for other testers in the team to say “Don’t bother with that, it is not our responsibility. Let mr Y have a look at it…”. Being typecast as the super tester might also cause a lot of negative stress e.g. if your social life is chaotic. All sapient testers are human beings, with all that comes with that.

Typecasting in testing is an easy way to stop your team from growing and developing. It is a way of letting people win the “Not my job”-award by not taking responsibility (or not been given responsibility). It is a way to foster specialists that might want to be generalists.

In order for you to get away from being typecast, you need to do some change.
You should try as many ways as possible, here are some suggestions:

• specialize in new areas (where you will become the expert in the team);
• learn more about testing – read books and take courses in testing;
• talk to the team leader about you wanting to learn more about the areas where you are currently kept away from – remember that all experts have once started as novices;
• partner up with your colleagues and work in pairs;
• make sure that you are involved in all parts of the testing;
• change employer;
• etc

But I guess that the most important thing is to realize if, and when, you are being typecast; and not being satisfied with that. Then you at least have a chance to break out.

Also see The Generalist vs. Specialist Paradox

When is a system small, non-complex or unprioritzed enough not to be tested? If there is a test organisation working on the bigger system that will be released to customer, what happens to the other smaller systems then? Is it so that they are almost always left untested? I usually identify these as applications that are created by one person, they can be used in critical parts of the product development, but are not viewed at as a product, sub-system or application that needs to be tested.

During mid 90′s I worked at a small localization company. At that time I was involved in a project where we were preparing a major translation of swedish material that was going to be translated to 20 languages. In order to succeed with such a translation it was important that we first translated the material into english and then went from there to the other languages. I did a little script to fix the glossaries for the various languages. It was just a small script to prepare for translation to the various languages. At that time we had a few testers but they were either testing commercial applications or testing for our customers, so there were no resources left for my stuff to be tested. Naturally there were loads of bugs in my code. I accidently made an offset in the script for each row, so each translated language used my glossaries with an offset of the translation. The proofreaders noticed the error eventually, but it had cost the company a few millions by then.

During another project we had a problem working with our customers files. A customer required us to use a specific program that used one working folder which contained close 100000 RTF-documents. Each time a translator checked the folder to find a specific document it took him a few hours just to see the file. So, when we wanted to do many changes to many files at the same time we calculated this to take 3 years time in order to implement our changes. So, we did a little perl script to do these changes we want by searching and replacing directly in the RTF-format (very dangerous way). First we did just one little change and when we saw that this worked well, we added more. Eventually we had a quite long list of changes being done to these 100000 files. We probably saved a few hundred years of time and budget, but eventually there were bugs in the script. One of these bugs where that I thought I had fixed issues with too many spaces and replaced them with just one space, but RTF sometimes needed two or more spaces. The result was that whole sections of text disappeared totally from being shown. This was just a small tool.

At most companies there are many such small systems floating around in the organisation. Shall the test organisation take a step toward testing those? If they are so small might it be so that testing also takes little effort? How about automation tests or production tests? Are they prioritized to be tested or do they fall into the same unimportant category?

If we see testing as a service, I think it is important that the test organisation involve themselves in all development, even if it is a few minutes time. Developers also need to involve testers, to give them a chance to do their job. Naturally it will be impossible to do everything, but in some cases it only takes such a short time to find a few bugs that it is worth it.

Not too long ago I had a test lead that I pretty soon recognised as someone that didn’t share my philosophy in software testing.

One day I reported to him that I had run all regression tests that were assigned to me.

All tests were executed on the same build (we had monthly iterations and this was done in the first week); and a couple of bugs were found and reported. I also verified a couple of bugs that I had reported earlier and that had been fixed and included in the current build. The suite took 3 days to execute and it consisted of rigorously documented tests that had little to offer to your fantasy. The system that was tested did not have any UI and the final results could only be checked via a secondary tool and/or by monitoring several log files; so it was a bit cumbersome to test.

I guess that I was pretty fast or efficient because the suite was supposed to take 5 days or so to run, so I was rather glad to have done this in almost half the time; and believe me when I say that I wasn’t sloppy.
And especially if it is a rather boring task I tend to think that it is better to do it as quick as possible, without being sloppy, in order to get rid of the boring stuff.

Well, after I had said that I was finished I expected to hear from my test lead what to do next.
Perhaps having a look at the new functionality that we should have tested last iteration but didn’t have time to do (i.e. we were a bit behind the schedule)?
Or perhaps helping the other testers out with their suite?
Maybe verify some bug fixes reported by others that were included in the build?

No, this was nothing that he said. Instead his response was:
“Hmm, OK… Could you test it again?” And I saw that he was trying me with this sentence because I caught a nervous smile in his face that he was trying to hide.

I just shook my head and said “Are you serious? What sense would it make to run it twice?”

He did not have any good answer to that. And of course I did not run the same tests once again…

But that incident made me wonder how many times he had done that to other people before. And in general, I wondered how many test suites are rerun several times on exactly the same configuration just in order to make it look good for some reason.

This article is about combining the role of the tester with other roles. These are observations based on my own experiences. I’ve not studied any books or other articles about this.

I assume that each role has its own mind set, focus and goals. I will try to identify the agendas and possible mind sets that I had at each time and then try to form an opinion on how a certain combination worked together with the tester role. I will cover the roles of test lead, test manager, project manager and documentation specialist.

A few objectives/goals of the tester are (taken from materials from Cem Kaner):

• Find defects that matter
• Find important bugs, to get them fixed
• Maximize bug count
• Block premature product releases
• Help managers make ship / no-ship decisions
• Check interoperability with other products
• Minimize technical support costs
• Assess conformance to specification
• Conform to regulations
• Minimize safety-related lawsuit risk
• Find safe scenarios for use of the product
• Assess quality
• Elucidate the design and prevent errors

The tester and test lead have similar, if not almost the same objectives. One observation I can share is that as a test lead or team lead for testing you sometimes dwell a lot on resource planning, keeping everyone occupied at testing. This stole a lot of focus from thinking of new test ideas.

The tester and test manager is a bit different. Depending on which stage you are in organization you will have different agendas as a manager. If you are focused on test processes, propaganda around testing, selling the test concept to the organization or whatever it is, you will behave differently. What I experienced was taking a step away from the actual testing and putting more focus on the processes. I even considered letting certain issues pass, thus not dwelling on them so that the organization can learn from the mistakes. I thought that going in to do this temporary fix would be good in the short run, but it is better for it to fail so that we can have good discussions and perhaps doing something in the long run. Many of these thoughts were contradictory to what I usually thought as a tester. So, in order for this to work I needed to be very clear when I was the tester or test lead in the project and not acting the test manager.

Another experience from being test manager combined with being a tester is the first months of my employment as a test manager. I entered as a tester in a project while at the same time was supposed to build the test organization at the company with everything from introducing tools to having presentations about what testing was. In the project there was a test lead that had no experience from being test lead and little experience from testing. We clashed several times since it was very hard to go from being a tester to being a test manager, often in the same discussion. As a test manager I wanted us to use a bug tracking system and a test management system in a certain way, while he saw no use for these. In any case, it was very hard to do a good job either as a tester or as test manager having different agendas at the same time.

In another situation I was project manager, test lead and tester. I was also supposed to be documentation specialist, but I was able to duck that in the last seconds since I was incapable of taking on a whole new focus in my work. Actually, I almost broke down completely since as a documentation specialist I needed to have full focus on the documentation and manuals. I would not have been able to maintain the meta-perspective as a test lead or project manager at that stage. Combining the project manager and test lead was not that hard, in some cases I made project management decisions with a touch of test lead focus. Still, it was easy to notice that the dominant role was project management having the focus on deliverables, time, cost and resources. In those situations quality was pushed down on the list automatically. When I took on the test role I had to be very clear on that I was tester and that I was allowed to focus on that. Combining these roles was very hard and sad to say, quality and testing did not get the attention that they should have seeing that project management became dominant.

As a summary, if possible do not combine the tester with any other role than test lead. It is too easy to push away the strengths of the tester’s mind-set and objectives. Seeing that project management becomes dominant might also mean that it can be hard to keep the focus on so many things as a project manager. If you think about all the things that testers and test leads do, it will just become too much. In projects where you do not have someone who have the role of tester and test lead you will miss so much. In projects where you have someone acting tester and test lead in combination with other roles, do know that you will not be able to use their full strength and expertise.