With numerous test automation tools and frameworks available today, many in the software testing industry are focused on learning them all. It is important to stay updated with new technology. But are testers losing something in the race to become more technical and equipped with automation skills?
In my article published at TestRail blog, I examine ways to see if your test automation is becoming so technical and code-intensive that it’s in danger of alienating the subject-matter expert testers who best know the core of your business?
Technology should serve people
It is important to understand and remember that test automation tools have been designed to make testers’ lives easier and better. They are not intended to replace testers or overpower them. They make tests execute faster, with more accuracy and fewer errors, so if they eliminate anything, it is redundancy and repetitive work. This technology is meant to serve testers — to save their time and effort and give them more freedom.
To this end, the first intent behind adopting any technology must be its fitness for use in the project, not its popularity in the market. The skills needed to adopt the tool and begin using it in the project should be easily obtained by hands-on learning or training. Read full article ->
Testing is creative
Testing is a creative job, and it always has been. The advent of new tools and technology has not changed this fact. Tools can do part of a tester’s job, but they still cannot test. Although some people may argue on behalf of artificial intelligence and machine learning that can take over many actively creative aspects, we are not there yet. We still want and need a human to capture the creative tests, discuss the pros and cons of design aspects, peer-review test cases, and report problems.
Everyone can contribute to test automation
When we look at testers’ resumes, the tendency is to look for tools they can work with. But the more important skill we need is their ability to contribute to test automation in one way or another. We cannot judge this fact just by asking if a person is able to write test automation scripts or knows a certain programming language. They may be able to learn the Gherkin format to design and write feature files for Cucumber tests. Or if you decide to adopt a keyword-driven framework, they could pick up the keywords and begin writing tests so that the same test cases can double as test scripts.
The main thing is for you to involve your testers in test automation, with or without the use of a tool.
Ask yourself these questions
Are you taking your human testers’ inputs when designing your test scripts? Are you using their domain knowledge to design the best end-to-end regression tests? Are you encouraging, supporting, and training them to learn and use the tools?
If not: Are you alienating them from test automation simply due to a lack of programming knowledge? You could be losing out on their precious skills and system knowledge when defining your tests.
If so: Are your tests really reflecting what the business intended to test? Or are they just a bunch of steps being executed by a tool?
Do you know what went into creating these tests? Or are you only relying on the knowledge of one automation expert? Won’t it be better if the same scripts were created with multiple brains put together and everybody’s ideas considered?
Read the complete article here-> https://blog.gurock.com/automation-alienating-business-testers/
<Image Credits – Stock photo from https://www.dreamstime.com/stock-illustration-alienation-dogs-alienate-crying-cat-image42929049>
testwithnishi 