Manual and Automation Testers

There’s a lot of controversy between being a manual tester and an automation tester, but what does that actually mean? Do they both need the same kind of skills or are they completely different in characters and focus (in everyday life)?   

In my opinion, you first need to have the right aptitude for testing. This is your basis. Where do you start from. If you’re passionate about testing, then you’re in the right track.

Characteristics of Manual Testers 

A manual tester is a person who performs testing activities with or without the need of tools. However, you do need some skills to become a good manual tester. Some of them will be the ability to read, understand and challenge the requirements being put in front of you, hopefully without causing conflicts.   

You should be creative 

As a tester you should be creative and imagine all possible solutions and results that come from those requirements (think outside the box). This brings me to another point: you MUST be a team player! You really need to understand how your creativity and input will affect other people on your team and how this will help deliver better software (or whatever else you’re testing – no. Testing doesn’t just exist in the software areas, it also exists in Medicine, Army, etc.). Which makes me say you should also be a very good listener and interpreter of other people’s minds.   

You should never judge people, but give constructive feedback through your great communication skills and your attention to details. 

Being able to communicate and report your discoveries

  Also a very important skill that you must possess. The purpose of testing is to show in which cases the product will not work or work incorrectly.  

Remember that your customer is the one who will be using the software (or hardware) in the future, so, keep in mind what’s best for him, what he really needs (not what he says he does). Be smart and attentive, for all minor items can become a big improvement, in the long run, when you deliver value to your customer. Having business knowledge will help you a lot in this aspect of the customer, however, this is something you can learn on the job and you do not really need it to start. But above all, you must have an open and curious mind to learn fast and adapt as much as possible. 

You should never give up! Be patient and try to find as many bugs as possible (especially in the earlier stages as it will save you a lot of trouble further down the line).   

Besides all of this, you should identify and understand the risks involved in what you’re testing. You should never compromise on quality at any testing stage. But, for that, you need to be able to prioritize and organize the fundamental aspects of the tests you’re going to cover, and also make sure you keep track of time and effort spent. If your effort is too time-consuming and not worth the work you are doing to offer this functionality, it may be best to rethink and prioritize the internal testing backlog. 

There are different stages of testing, unit, integration, system, user acceptance, operational acceptance testing, contract and regulation acceptance testing, factory acceptance testing, sanity, alpha and beta testing, release or even deployment testing (there are more to cover). They all rely on the work done previously by testers, whether it’s the work done in the requirements phase, when you make sure the acceptance criteria are there, or when you write down the steps (making a script) of what you’re really trying to test. You stop the testing when you reach the agreed definition of done and the exploratory time frame you have assigned to it. 

When it comes to an automation tester most of these qualities should be there anyway. You will have access to the various stages of testing so that you can never escape it again. 

Characteristics of Automation Testers

 You also need a bit of logical thinking (perhaps engineering)

You need to know how to use tools that will help you create your tests in a way that they become repeatable at the click of a button, and some logical reasoning. This is, when you need a little bit of knowledge of how a software development life cycle works because in the end, you will end up building software that will test other people's software.   

This is where technical knowledge comes in. 

You should be able to interpret the existing test scripts 

Interpreting and understanding the existing test scripts (or whatever your team is trying to deliver from the requirements stage) are in order to know what you will be able to automate and at what level you should automate it. Leave it for the developers whether it is a unit test or create your own integration layer? Are you the owner of Continuous Integration and Team DevOps? If so, are you sure they are well configured and have all the necessary environments and test data so your automation runs smoothly on the developer code without any issues? You must be a team member, in this case, otherwise you will have a huge workload and might not be able to achieve close to 100% of the automation test coverage that we would normally like to see in our builds.  

Test automation is a process of designing a solution, implementing testes, monitoring and controlling test execution, but also interpreting, reporting and logging the results of automated testing. Because it is a complex solution, it needs to be sustainable, have great performance, and be consistent (solid principles help create this kind of code structure). The goals of automation are to improve test efficiency (less prone to human errors in running scripts), providing wider coverage, reducing total tests costs, performing non-human capacity tests, shortening the test period, and increasing the test frequency by reducing the time it takes for the test cycles to run. This will help free some time for manual testers to cover more exploratory testing and to find bugs that have not even been considered.  

Although automation can run in parallel, have more complex tests, be faster, improve test quality and system reliability (and also improve collaboration with the developers), we must also consider that not all tests can be automated and that automation can only check machine-interpretable results and actual results that can be verified by an automated oracle. That's where the automation experts come in.  

In sum

So far, you should have identified many of the differences between a manual and an automation tester, these go from simple things like being creative, imaginative, passionate, attentive to details, and a team player. To more complex things like a little bit more understanding of the story behind what is being built and how (engineering mindset), in order to create your own bit of software which will help the manual testers by allowing them more time to do interesting tests instead of repetitive ones.

Does this mean that a manual can never become an automation and vice-versa? Well, that will depend on how much they are willing to learn and how much effort they would like to put into their development in the test career, but that is a completely new topic to discuss in another article.