Automated Test Developers
In September of last year, I spoke about the trends in the world of Software Testing & QA in 2018. A major trend across the year that seems to have continued into early 2019 is the consideration that automated testers are, by definition, software developers.
In the 2018 ‘State of Testing’ report published by QA Blog, 46% of respondents claimed that they spent less than 75% of their time on testing related activities.
This aligns with my own experiences of the market, as more and more businesses look for multi-skilled testing engineers that can develop products as well as assuring their quality through automated processes.
At a recent Ministry of Testing meet-up event a question from guest speaker, Louise Gibbs of Malvern Panalytical, sparked debate as she asked;
“As Automation testers, do you consider yourselves to be Developers?”
A discussion followed where I think its fair to say we ended no closer to a definitive answer. However, it was interesting to experience first-hand the conversation that this sparked.
Manual v Automation
Linked with this debate is another theme of the last 12 months has been the continued shift from manual to automated testing.
This stemmed mainly from the continued development of cloud technologies and the reliance on products that require continuous delivery methods such as; Amazon Alexa, Google Home, Smart bulbs & Lightwave RF radiators.
However, this theme also ruffled one or two feathers with the Ministry of Testing group. There is a strong feeling that there is a differentiation between a manual engineer and an automated engineer.
Manual testing fanatic Lee Marshall from Coventry Building Society:
In Software testing help’s recent update of the most used automation testing tools, Selenium retained the top spot.
Being an open source tool, I’m sure this came as a surprise to no one. However, the lack of a paywall comes at the cost of a lack of technical support. This is perhaps the main driver of the adoption of TestComplete.
Honourable mentions from the comprehensive list include Appium, HPE UFT, Soap UI, Cucumber & Silk Test.
It seems that there is a tool available for all requirements by test engineers, whether it be; data-driven testing, behaviour driven development, regression, performance or smoke testing.
Another area where testers and developers came together is Unit Testing. Popular with Agile projects, a unit test is likely to be carried out at the end of a sprint cycle. Test Driven Development (TDD) relies on these short, repetitive cycles. This close level of quality control allows for bugs in the code / Test to be identified & tracked efficiently.
The objective of this exercise is to, one by one, isolate parts of the code to demonstrate they are correct. A successful unit test will identify bugs & errors early in the development cycle.
However, unit testing will not be able to test the full functionality of a program. A set of code is susceptible to false-positive / false-negative readings. Unit testing alone is unlikely to determine the validity of these readings, so a secondary usability test may be required.
I leave with an excellent question brought up by Louise;
“When one person writes the automated test, another runs the test, and a third identifies the bug. Who really found the bug?”
By Guv Johal