Interview with Marie Drake
Marie Drake is a Quality Engineering Manager at Zoopla. Previously, she was a Principal Test Automation Engineer at News UK within the Product Platforms team where she was responsible for setting up the overall QA strategy and ensuring that they deliver a high quality product to end users. Part of her role is to also educate everyone about Software Testing and Test Automation so the responsibility of testing is shared across the team.
In the past, she has worked as a Test Automation Consultant having worked with different clients from different industries to help them speed up their testing cycles.
She is also a Cypress ambassador, an accessibility advocate and an online course instructor at Ministry of Testing and Test Automation University.
What are the most common mistakes you see people make when it comes to test automation and what can be done to avoid them?
The first mistake that I think people make is over reliance on user interface (UI) automation and not implementing the correct tests on different levels. One of the main problems is that as testers, the first thing that we are told to learn is UI automation and so we are led to this belief that this is the only way to implement test automation. Since our users interact with the UI on a daily basis, it makes sense that as testers, we have to verify the user flows are not impacted when our team makes changes to the codebase. However, we all know that UI automation poses some problems. They are valuable but provide a slow feedback loop, require high maintenance and can sometimes be flaky. Rather than over relying too much on UI automation, collaborate with your team on what tests we need on the unit and integration level.
The second mistake that I have seen personally from projects is test automation code being separated from the development code. Test automation is a development activity. Having it separated increases the chance of test automation code being ignored when there are new changes on the development code. If one of your goals is to encourage developers to write more tests, I feel that having test automation code on the same code base will provide more value since it will be refactored and updated if needed alongside.
Another mistake is choosing the wrong tooling for your requirements. Every project has different requirements and so you need to make sure that when choosing an automation tool, that it fits most or all of your requirements. Spend a bit of time in your research and include your team in the decision making. Test automation should not just be the responsibility of testers so ask inputs from the developers too as to what tooling they would like to choose.
When it comes to Test Automation and/Testing in general, is there anything you have changed your mind about? If so, what?
That when it comes to test automation, developers are best suited to do it. However, this doesn’t mean that testers cannot do it too. It’s definitely a collaborative effort. The one thing that I advise various teams now is not to have a dedicated tester who’s sole responsibility is to write tests. This slows down the process massively. We now have a lot of developer friendly testing tools so having one person write automated tests is not an ideal situation anymore.
You write a lot of useful how-to articles, were there any that you found particularly challenging to write? Or any you are really proud of having written? (e.g. lack of any useful resources on similar topics elsewhere)
I would probably say that this article here Using Tags To Filter Your Cypress Tests is one that I am most proud of. It’s my second most popular article and I’ve received great feedback from it from fellow testers on how it has helped them on their projects too. The reason I wrote this article was my previous project had a specific requirement to run specific tests only on feature branches. With using Cucumber, this would have been a quick fix through the use of tagging. However, we weren’t using Cucumber and so I had to find an alternative way of running our Cypress tests based on tags. During that time, there was no direct support from Cypress so I had to create some custom code to support it. Nowadays, this plugin cypress-grep is now available which can do the same thing but I’m still proud that my custom code was very useful :)
I read that “you try your best to amplify your voice in the hope that you can inspire other women to do the same”. At the start of your career, did you have women you could look up to professionally? How do you feel other women have inspired and influenced you in your career?
At the start of my career, I have to admit that I didn’t really have anyone specific that I looked up to professionally. It was only when I started to network with the testing community and started my public speaking journey that I now have people that I look up to. I look up to Angie Jones for her continuous contribution to the tech community and she also calls out any negative behaviour towards women in tech. Other women that have inspired me through my career include Rafaela Azevedo, a good friend of mine who started her blogging journey 10 years ago, Suman Bala who gives great advices (work and life advices both!) and is ready to help out when you need it, Julia Pottinger for her countless number of useful meetups, tutorial videos and blog posts.
I see you are a Cypress Ambassador. What got you initially interested in using Cypress and how did the opportunity to become an ambassador come up?
I first heard about Cypress late 2017 and during this time, they were still in beta phase. After their public release, I was given the opportunity to speak at my previous workplace’s first ever women in tech meetup and do an introductory talk about Cypress. It’s one of the tools that I enjoy using because it is developer friendly and the setup to get started is so quick.
When I started blogging late 2019, I started to write posts about Cypress to share my learnings to other people.
Then, during the start of 2020, I first heard about the Ambassador program. I have to admit that I applied without putting too much thought into it! I gave them evidence of the meetup and the blog posts that I have done. When they accepted me into the program, I was jumping with joy! Being part of the Cypress Ambassador program has given me access to connect with the other ambassadors.
It has also led to the Cypress UK meetup which has almost 1000 members, and it has given me other amazing opportunities such as hosting workshops, further meetups and being a guest at a podcast episode.
You’ve also an Accessibility advocate, what is one thing you want everyone to remember when it comes to building for or testing for accessibility?
When it comes to testing for accessibility, we have to remember that it’s not just the responsibility of the testers and embedding it right at the beginning is best. You need to have a change of mindset and build a culture of inclusivity first in order to be successful with it. Accessibility should be part of every stage of the development lifecycle and even as far left as possible from the planning stages. Automated accessibility tests can help you catch basic accessibility issues but it doesn’t mean that your product is accessible. Human intervention is still very much needed and it’s still best to test with real users with disabilities.
✍️ For more interviews, go here
📹 For my video interviews, go here
#Interviews #Test Automation