Skip to main content

Motivation of tester types

In my testing career span of close to 7 years, i have come across various testers. Every tester has unique skill sets and things that motivate them. Based on the various tasks a tester has to do on a daily basis or during a project, I would like to categorise these testers into 3 types
  • Manual tester
  • Automated tester
  • Hybrid tester
Manual testers are mainly non-technical and are focussed more on testing applications manually. These types of testers have good domain knowledge.

Automated testers are technical testers who mainly deal with tools to help them test applications. They are given a set of test scenarios and all they need to do is automate these scenarios.

Hybrid testers are like superman. They are expected to do whatever is thrown at them and it is these types of testers that are in demand these days.

Now the interesting aspect is what motivates these testers in their day jobs. Lets take a look at this in the form of a graph where x-axis represents the various activities involved in the life of a tester and y -axis represents motivation levels.


As we can see, the motivation levels of manual testers for technically oriented tasks is fairly low and that of automated testers is high. It is the opposite for automated testers where their motivation is fairly low for tasks that are less technical.

However, the hybrid testers seem to be motivated consistently across all tasks and this is what makes them stand out amongst the herd of testers.

So in order to provide value to teams, testers should strive to become hybrid testers

Comments

Post a Comment

Popular posts from this blog

BDD is over-rated

Over the past few years, I have tried to justify the use of a BDD (Behavioral Driven Development)  framework to express my tests, but not once have been able to say BDD has helped me address a  problem which writing tests the non BDD way would not have addressed. I do understand the value BDD brings to the table, but in most projects that I have implemented BDD on, we have tried to provide a solution (BDD) to a problem that does not exist.

Let me try and explain. Lets look at the key benefits of expressing tests the BDD way (There could be more)
Collaboration between Business and DevelopmentUbiquitous Domain LanguageFocus on the behavior of the application Now, more often than not unless your business is co-located with the team, collaboration is not the easiest.

The value BDD brings here, is the business validating our understanding by reading our tests expressed in the Given When Then format (BDD) and providing feedback, as BDD expresses the behavior of the system in a language that…

Build quality in early and often

One of the most important aspects of building good software is to encourage the concept of build, measure and learn. For companies to be able to innovate and be quick to market they must encourage a good engineering culture that sets up teams for success. In an ideal world, you should deliver to production daily. However, if you deliver software fast, but it is full of bugs, your product has a lower chance of succeeding. As an agile tester, one of your focus points has to be to speed up the feedback loop while maintaining good quality. Over the years I have laid across a few good practices that make teams build the product right and also build the right product.

Engage Test Engineers as early as possible in the development cycle Test Engineers are often treated as the last stand against finding problems before release, yet like all software activity; their focus is affected by the information available to them. In order to better understand the risk associated with changes and its poten…