Testers and Automated Testing

We all know the value a tester brings to projects and the industry is now finally valuing testers as equals to developers. However, one thing that is often a debate is the input or role a tester has on automated testing. Testers can have a major influence in automated testing without having to write all tests on their own.

In my company, testers are expected to be technical and be able to write automated tests on their own. In fact the expectation is to create the Automation Framework too. I am not a fan of testers creating automation frameworks or writing automated tests on their own. I would prefer for testers to pair with developers on any automated testing activity, be it the framework or writing automated tests.

Testers understand the application backwards and they are the best candidates to identify what should be tested. Now, by collaborating with the developers, both can make an informed decision as to what can be tested and at what level. For e.g. Some tests are worth writing at the UI level as the tests which are written on the underlying layers do not cover that. This also gives both tester and developer confidence on the test coverage.

As a result of this, the tester need not waste time testing all those weird cases manually as they have automated tests to validate them and the tester can focus on other edge/weird/negative/boundary cases which could detect some defects.

Also, another benefit of this is that the testers would be able to learn better coding techniques by pairing with developers and have a better understanding of the codebase. This would help them to read the code better and possibly find defects by reading code as well.

Comments

How does one decide what to automate?

A question that has been troubling me for years is how much to automate. We all like to achieve maximum coverage and build a robust safety net where possible in order to give us confidence about the system under test. Given there is ample time i would like to automate almost everything, but in the real world, this isn't possible. This is when we introduced the concept of Value and Cost for a test scenario. Every test scenario would be assigned either of these attributes. Lets call the attribute automation classification High Value - Low Cost High Value - High Cost Low Value - Low Cost Low Value - High Cost What this translates into is we are associating business value and cost to automate to every scenario. So, when a test scenario is of high business value and the cost to automate it is low, then this becomes our ideal automation candidate. You would like to start automating all test scenarios that fit into the High Value - Low Cost category first. See picture below If tim...

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 Development Ubiquitous Domain Language Focus 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 syst...

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 activit...

The Shaolin of testing

Search This Blog