Whenever I go to conferences or meet up with new testers who are looking for some advice, I often get the same questions. And so, I thought it would be beneficial if I collate a lot of the common questions I tend to receive and provide some documented answers to them because I believe there are many people out there with similar questions looking for some advice on these topics. 

​

The questions range in nature, primarily focused on career or testing-related topics, but also some of a more technical nature or perhaps looking for my thoughts on the future. I will also be updating these questions over time as I get more feedback and questions from others. So, if there is a question that you would like my opinion on, please reach out to me and I will try and give you as best an answer as I can and if I feel others may benefit, I will add it to this page.  

 

These answers though are often just my opinions and based on my personal journey and so may not apply to everyone. Hopefully, though, it can still provide you with some insight and point you in the right direction as you find out the correct answers for yourself.  I have also found that over time, my opinions on certain testing subjects have changed as I've gained a different experience on things. and this has led me to realize that there are always many viewpoints and ways of doing things. So, view most of my suggestions as "a way" of doing things and not "the way" of doing things. 

​

Common Questions I am often asked:

​

How did I get into testing?

I want to get into testing what certifications do you recommend?

I am a manual tester who wants to move into test automation, what do you recommend I learn?

Should all testers learn to automate?

As a tester, will my job become obsolete with RPA tools?

When it comes to UI automation, which framework do you prefer, Selenium, Cypress, Playwright, or something else?

I want to learn how to code, which program language should I start with?

What skills separate a great tester from a good one?

As a tester, how can I get my team more involved in what I do?

You're a proponent of testers getting involved with unit tests, doesn't that take the responsibility away from the developer?

​

​

How did I get into testing?

I studied computer science at university and started out my career as a developer. Admittedly – in hindsight – I probably wasn’t a v very good developer because I didn’t do much testing. However, I received feedback in my second year that I have the mindset to be a tester in the way I analyze problems and so decided to make the change and try it out, thinking I’m still new in my career so now is as good a time as ever. It turns out, that I loved it and preferred testing to development, though because of my experience with code, I was able to adapt to test automation quite quickly.

​

I want to get into testing what certifications do you recommend?

Software testing is one of the most crucial parts f the software development space that is sadly under-supported by many educational institutions. Still, there are several certifications that set a good foundation for test theory (ISTQB being the most popular). However, in my experience, how testing is practiced in theory and reality can be quite different and so don’t rush to get certified and rather focus on practical skills. Doing some online courses that focus on more practical testing and automation experience might be a good first place to start before attempting any certifications.  

​

I am a manual tester who wants to move into test automation, what do you recommend I learn?

I think it’s great that manual testers want to improve their technical skills and take on automation. Automation plays a vital role in improving the delivery of software delivery and it’s a sought-after skill, so encourage all testers to try and develop these skills. I want to start off by saying though that in making strides to test automation – don’t forget your core testing skills. They are incredibly vital and your biggest asset, even in test automation. Secondly, I always advise prioritizing broad technical skills like understanding databases, pipelines, software architectures, and cloud computing over pure automation skills, because this helps you test better and will do more to improve the quality of the software.

​

However, test automation is still important, and you still need to develop these skills. In terms of where to start, I would first recommend trying to understand the automation usage and needs of your current company and then learning a language and tool that best meets those needs. This allows you to get actual practice at automation rather than just doing training. I’ve seen far too many people make the mistake of trying to learn how to automate by doing courses but then never getting to practice those skills and therefore never developing them. The best way to learn is a way that can be applied in your company and if your company doesn’t have automation in place, then it's perhaps best to peer with a developer and work on a solution with them to gain some exposure.

​

Don’t get me wrong training is useful and many courses out there are excellent, but without application, the effort is wasted.

​

Should all testers learn to automate?

I think technical skills are very important – testers' ability to be able to understand the technical composition of the applications they are testing – and non-negotiable. However, when it comes t automation, I understand that not everyone has the thinking skills to code, even if they have strong analytical skills that make them great testers. I would argue that you need to figure this out for yourself and if you find yourself struggling to wrap your head around coding despite making significant efforts at it, it might be an indication that automation is not for you. That doesn’t mean that you won’t make a great tester. There is still a massive need for critical thinking, and analytical skills and rather what you should work on is learning how to engage and work with others in the automation work that you can’t do and possibly even work more clearly with the developers on their unit tests.

​

As a tester, will my job become obsolete with RPA tools?

This is an understandable question given the rise and advancement of RPA tools. However, in my personal opinion, testers are not in danger of being replaced by any form of AI – at least not anytime soon. While many AI tools are good at looking through code or UI screens and designing test cases based on that, this is better for unit tests. One of the key parts of testing is understanding user behavior and business purposes and aligning software and testability to this. Something which AI-driven tools are far from achieving so far.

​

Does this mean that they will never get there, no, I believe they will? But even then, I believe it will lead to simply just quicker and more accurate test automation at a regression level with testers focusing more on exploratory testing, while still needing some coding skills to maintain the AI-driven frameworks.  

 

When it comes to UI automation, which framework do you prefer, Selenium, Cypress, Playwright, or something else?

I believe that we should place less emphasis on the tool we use to automate and more on the framework. All these tools have their own pros and cons that will apply differently to different teams and companies. What matters more is designing a solid framework that is built on proper test design principles and preferably tool agnostic so you can interchange between different tools depending on your need.

​

I want to learn how to code, which program language should I start with?

In my opinion, try and learn the concepts of computer coding rather than trying to become a specific language expert as programming languages will come and go based on new development and application trends. A person needs to start somewhere and so as a first language, it really depends on what you intend to do. If you want to get into data science Python would be good to learn first if it's web development, consider JavaScript. Java for Mobile Development and C# for Games Development. If you’re not sure, I would start with Java. It’s not the easiest language to learn but has a wide range of use cases and the object-oriented principles you will learn from it will come in handy. Though, as I mentioned focus not so much on becoming a language expert and try and focus on the problem-solving mindset required for programming.

​

What skills separate a great tester from a good one?

This answer may surprise you, but the answer – in my opinion – has little to do with your testing or technical ability, but rather soft skills. A great tester is able to communicate testing and quality very effectively, is able to raise key questions in team meetings, and can get an entire team to understand their respective roles in achieving software quality and how responsibility for it can be shared. They can communicate easily with developers, business analysts, and other testers and deliver the impact of testing to all parties in a way that is relevant to them. This doesn’t mean a great tester needs to be extroverted – I myself am introverted and prefer not to communicate most times – but it means they need to find a way of communicating effectively within their own personality.

​

As a tester, how can I get my team more involved in what I do?

Quality is a team responsibility and not the sole responsibility of testers in a team and this should be a basic understanding of all involved. However, if you sadly find yourself in a team that pays little attention to testing, then there is a lot that can still be done. As mentioned in the previous question, soft skills are helpful here and the better you can communicate the effectiveness of testing, the better you can convince your team of its importance and how they can play a role.

​

Another key element though is how you measure quality in your project. I don’t believe in using metrics just for the sake of it, but when the correct metrics are used that paint a holistic view of quality and delivery, it will be clear how all parts of a project play a role and everyone can see the benefit of good testing and move in the right direction.

​

And even though I do speak about testing the secret is not to focus on testing effort, but rather on the quality and delivery of the software. Those are things that are more readily understood and if you can show how quality issues, limited testing, or untestable software affects these, you can generally convince a team more easily to change their habits.

​

You're a proponent of testers getting involved with unit tests, doesn't that take the responsibility away from the developer?

I definitely do believe more testers should get involved at a unit test level (admittedly it's not for everyone as it is often more technical in nature) and believe it can add great value to the overall testing effort and quality of a project.

 

I don't think this takes away from developer responsibility as firstly, the developer still needs to write the code that can pass all the tests. But also, typically how I see this working is not so many testers and developers working in isolation on this, but rather together. The developers know the code and are perhaps best placed to set up some of the complex mocking required for some scenarios, while the tester addresses coverage and looks for gaps that should be covered. Solid unit testing doesn't remove the need for component and integration testing elsewhere, but it greatly reduces the number of scenarios needed to assure coverage and with automation and execution of unit tests far quicker, this provides for more benefit in CI/CD terms and the entire life-cycle of an application. 

​