Testing Titans: Bas Dijkstra, test automation trainer and consultant
Welcome to Testing Titans!
Consider this the first in a series of many in-depth interviews with movers and shakers in the software testing and quality assurance industry. The goal behind these interviews and, the series as a whole, is to lift the veil on the software testing world and shine a light on the concepts, tools, and people that are shaping the industry.
You can look forward to interviews from highly experienced and influential experts on the subjects of DevOps, test automation, cybersecurity, and software development — all from the perspective of software testing.
This first interview discusses the challenges and future of test automation with test automation trainer and consultant, Bas Dijkstra. Bas has worked with organisations like Holland Casino, Ultimaker, De Telegraaf Media Group, Buma Stemra and even Lectured Software Quality Assurance and Testing at the University of Groningen.
If it isn’t owned by a team, then your test automation will not see its full potential.
Bas, thanks for taking part in this interview, we are really looking forward to your thoughts on testing and test automation. It might be helpful to give our readers a little background information about yourself. Could you tell us who you are and what you do?
I’m Bas Dijkstra, a test automation trainer and consultant with some 14 years of experience. After having worked for a large and a smaller consultancy organization (for about 3 and 5 years, respectively), I’ve started out as a freelancer in 2014. I typically describe what I do as ‘helping teams and organizations improve the efficiency of their testing activities through the smart application of tools’. Typically, I do this through providing training on a variety of subjects in the test automation space, or through consulting with clients on site.
What do you typically find are the challenges to an organisation undertaking test automation?
I see many organizations still struggling with test automation, for various reasons. Most of these reasons — in the end — come down to one of these two (or a combination of both):
Time
Test automation is not something that will bring you overnight success. It requires a significant investment in terms of time, and therefore money, to get the results you’re looking for. This means that teams and organizations should treat test automation as a ‘first-class citizen’ activity by dedicating time and people to write, maintain and run test automation.
I haven’t seen any organization yet that actively disagrees with this, but I often see that time allotted for test automation is one of the first things to go when there’s pressure to release new features quickly. While this might seem like a good idea in the short term, it is not something that will enable your team to release new features at a predictable speed, with predictable quality in the long run.
Skills
To be able to do test automation well, you need specific skills to be present in your team and organization. These skills are not taught in a single class, nor can they be obtained simply by doing one or two single- or two-day courses. It takes months, if not years, to hone these skills and become a skilled test automation engineer. It also goes way beyond learning how to use a single tool, framework or programming language.
I recently wrote an article that expands on my views on how to become a skilled test automation engineer.
Read Bas’ article about the test automation learning path on LinkedIn Pulse.
What would you say are common misconceptions that managers or developers have regarding test automation?
I’m not sure these are specific to managers or developers, but to name just a couple:
That test automation is the responsibility of a single person or role. If it isn’t owned by a team, then your test automation will not see its full potential.
That test automation is about tools. It is not, or at least not just about the tools. The ‘why?’ and the ‘what?’ of test automation, i.e., what is the rationale behind automation in the first place, and what are we going to automate (and more importantly: what are we not going to automate?) are, in my opinion, far more important things to address than the ‘how?’ of test automation, which is the part of the test automation strategy where tools come into play.
That test automation is a do-once, repeat-forever effort. Essentially, when you start with test automation, you’re starting an entirely new software development project, which you should plan and budget for accordingly.
You work as a trainer and consultant for test automation so you have your finger on the pulse of test automation, what are interesting trends we should be aware of?
Instead of focusing on trends, I would much rather see that we as test automation engineers, but also the teams and organizations that employ us, would pay more attention to the basics first. I still see too many people trying to use the latest shiny tools and then make a mess of it because they don’t have a solid grasp of the fundamentals of test automation and (object-oriented) software development.
Of course, it is fun and interesting to experiment with the latest tools and techniques (AI or visual testing, to name a few), but essentially, tools and the principles behind them haven’t changed that radically. Also, never stop asking ‘what problem am I trying to solve with this tool or technique?’
What do you think of the discussion around low-code or no-code test automation solutions? What are its implications on the quality of testing?
First of all, I believe there’s no such thing as no-code test automation. They are all tools to create software, some tools just put an abstraction layer on top of the code (these are what I call low-code solutions). I don’t think creating test automation in code is better or worse than creating test automation with low-code tools. It’s all a matter of finding out what is the best fit for your specific context. Most of the time, it comes down to a trade-off between the initial learning curve (steeper for code-based tools) and long-term flexibility (typically higher for code-based tools, given that the code is well-designed).
Having said that, over the years I’ve found that it’s often easier to integrate code-based tools in a version control system and a Continuous Integration setup. That doesn’t mean you should always go for the code-based solution, though. Again, ask yourself ‘what is the best fit for my context?’.
Where do you see DevOps influencing Test Automation? Or how does the demand for greater speed in DevOps influence test automation?
With DevOps, as with Agile, CI/CD and other related practices, it’s all about delivering high-quality software faster. Test automation, when done well, is one of the techniques you can apply to achieve faster feedback on the quality of your software, and therefore the rise of popularity of DevOps leads to an increased demand for people with test automation skills. We shouldn’t forget, though, that test automation in itself is not going to solve all your problems and magically enable you to deliver quality software at blazing speed. It can be an enabler to achieve this, but it is a means to an end. Automation itself is not the end goal.
Thanks for the thought-provoking interview Bas!
If you enjoyed what you just read be sure to check out the rest of the Testing Titans series (more coming soon) as well the rest of our blog.
If you are active in test automation — you are reading this so you probably are — you should follow Bas Dijkstra on LinkedIn and GitHub as well as check his website, OnTestAutomation, for more in-depth articles on Test Automation.
Originally published at https://www.spritecloud.com.
