Changing the domain you're testing in

There was a question from the masterclass with Damian last week that I think would be useful to post here to get a wider perspective on it. Perhaps you can advise the original poster:

How can we change the domain in which we are working on, for example, some is working in management systems, automobile etc. from 3-4 years, now they want to move to banking and finance. what could be the right approach to achieve this?


I’m assuming this is interview related?
As far as i’m concerned, Domain is largely irrelevant. A good /open minded tester can learn domain knowledge.
I think the key is to identify how you can use the skills in your current domain in a different domain - identify their “transferability”. For example, you may currently use your skills to write a python script that checks a log from a car ECU to find a particular log entry - you can apply that in a financial system to search through big data to find a particular financial entry.

1 Like

As far as you are concerned, it is. As far as I’m concerned, it is somewhat irrelevant.

However, I’m not the hiring manager/ team manager/ HR person/ etc. to whom it may be highly relevant in their opinion.

But you do bring a good point, the use of the skill and the sale of the skill are two entirely different beasties.

So we can break this down into some smaller questions:

  • How could we prepare ourselves for the process of switching domains?
  • How do we get the attention of a company who doesn’t work in our domain (i.e. via networking, motivation letter and/or CV)?
  • How do we steer an interview to subjects which will motivate them to give us a chance? (Technical or non-technical interviewers?)
  • Assuming we still have their attention, what do we do in the time between interviews or before our first day of work (also assuming time is available to do something)?
  • What next?

Even these questions are broad and absent of context, advice which worked for me (I used a job hunting coach… if you can afford a good one, I highly recommend it!), may not work for everyone.

1 Like

There is this piece* for the #ministry-of-testing:the-testing-planet modelling competencies both towards the business domain and towards technologies… etc. Switching domain could be to focus on what skills are not domain dependent and train to raise those.

*: I wrote it :wink:


I did actually switch domains myself a while ago, about 6 months, switching from financial services to mobile testing.

What I did beforehand was to read up on mobile testing, seeing what commonality was there between what I currently know and what is expected in the role. Understanding any major differences there is between the industries. And also trying to do some work on app’s (that I knew the company I was trying to move to) built so I could get an idea of what to expect.

Got the job, but nothing I did before hand really prepared me for it, so my advice would be similar to both Brian and Stephen’s, but also be don’t have any preconceived notions that its going to be too much like what you expected.


I switched domains a while back, from ticketing and capacity management, to payroll & HR. If you have little to no knowledge of the business domain, your best option is to be able to demonstrate that you can learn quickly and that you’re rock solid in the testing domain. And be prepared to have a significant ramp-up, especially if the business has a large amount of legacy software for you to work with (as my switch did).

HR people might make a big thing of domain knowledge, but I’ve found that the issue of having or not having domain knowledge is relatively minor compared to the differences in the company operations and software - which is where the biggest learning curve will happen.


I’ve switched domain a few times. Telecoms; to VoIP servers; to Boundary Security (Not firewalls, EMail and Internet scanning/Anti-Virus at the boundary); to EMail/Exchange automation, added signatures to emails automatically, and formatted them; to Security testing of Full Network Servers/Clients/AD/SMS/etc,; to ITIL Services and CRM.

In some cases it was a simple evolution. E.g. Traditional Telecoms to VoIP. And the VoIP product was product that enabled secure VoIP across a network boundary, so the next transition was to network boundary security, but with EMail.

The big changes were from the adding signatures and forcing format rules to emails, to full networks and security testing.

I have always approached everything I do in a conceptual way. e.g. Software, and even machines are about input and output (although learning machines/software aren’t quite the same anymore). So when you boil it down testing/checking is about taking a requirement that defines an output from an input and the appropriate design and making sure that with both predicted input and unexpected input you know what is coming out. It’s an oversimplification. But said with confidence in and interview has generally helped get a conversation going. It’s then about how you approach a problem. e.g. how would you test a mobile application? I’ve not tested Mobile applications, but I would start with the basic software inputs and output. Then add the hardware it is designed to work on and then introduce network conditions. So I would test on a variety of platforms (IOS, Android, Windows, Balckberry, etc) and either find out how people emulate mobile networks or think of ways myself.

The thing to remember is that there are few domains that haven’t been done and don’t have people around you to help you learn and improve. Maybe Artificial Intelligence and Learning Machines are a bit new, but there is a huge community now that would love to wrap their brains around that problem and talk about it with you.

The change is easier than you think, if you are willing to try and ask for help. Getting a HR manager to agree with you can be harder, but that’s the skill of interviewing. And the same with any move of job that stretches you. Change of domain, or moving up the ladder.

Note: In at least one of my moves I did move into a new role as the lone tester. Sometimes that’s easier to persuade the hiring manager, because they don’t know any better, but it can be harder to make the change because there is no one to tell you how it is done. In that case work close with the developers.

Changing methodology is similar challenge. Waterfall to Agile for example. Don’t stress, just dig in.

Additionally, I’ve moved from Commissioning (Old name for Client Demo) to System Integration Testing > System Testing and System of Systems Testing > Security Testing (Not Pen) > User Acceptance > and now Service Acceptance (not just software, but Software/Hardware/Training/Support/Agents/End Users/Process/Communications(Both initiating a work flow and during a work flow)/Permissions/Reporting/etc as a holistic end to end test of the complete service being sold.

I’ve not done performance or unit testing, or usability (not properly).And I’m sure there is a whole set of worlds of testing I have not touched. But with support and drive, I’m sure I could do good job.


How can we change the domain?
Easy: quit your current job, apply to another(or apply then quit), start working in the new place
What could be the right approach to achieve this?

  • If you have a network contact for the job you’d like to switch to - get in touch with him/her.
  • If you are jobless - apply to all the jobs. Go to interviews. If you’re a good fit for the hiring manager, he might hire you without the domain knowledge.
  • Switch the testing style/type you’re doing. Some jobs for testers don’t require domain knowledge, they will however require knowledge of specific tools or programming languages. Learn how to use those in advance. You might have to repeat this anyway each couple of years.
  • If the years of experience in the domain aren’t mentioned in the job ad, and you’ve managed to get to an interview, try to find common ground and things that could apply from your past experience to the current situation. This could be appreciated. For example: I’ve worked in e-commerce and applied to an air cargo transport software company. I’ve mentioned my previous experiences with testing api’s and crawling the shipment carriers that we tried to integrate within the platform; tracking and following statuses and syncing with the interface.

Good luck

Before you get hired in an industry, you’re not going to have any direct knowledge or experience of it. Unless it’s a hobby: like videogames or sports. So if the hiring manager values that - and I’d argue they shouldn’t - you’re at a disadvantage against anyone who does. So a wise strategy is to double down on your strengths.

Your strengths should be the ability to learn quickly, have a great understanding of the fundamentals, and other transferrable skills everyone should value: teamwork, charisma, analytics, technical ability.

Unless anybody has discovered a quick fix which I’m not aware of, there’s not a lot you can do about ‘learning quickly’ - that’s an innate thing. So I’d concentrate on the fundamentals. Things like:

  • Are you good at automation and coding?
  • Have you tested different types of interfaces (e.g. apis, web, unit tests, files, terminal, etc…)?
  • Could you design a CI pipeline with tests?
  • Can you identify - and prioritise - test cases for a complex application?
  • How’s your dev/testing knowledge - the testing pyramid, microservices, agile, devops…
  • Do you read books on software like the Phoenix Project, The Mythical Man Month, etc?
  • Do you read blogs and test articles?
  • Do you work on side projects (and test those too…)?
  • Write your own blogs about testing?
  • Attend conferences and meetups?
  • Even better, do you talk at or organise conferences/meetups?

You don’t need to do all of the above. You don’t even need to brag about them directly during the interview! But you need to give the impression that you’re good enough to adapt, and that’ll make up for any lack of direct experience. I’d much rather have a tester that did lots of the above with no direct domain experience, than someone with 10 years and barely did any of them. You need to convince the hiring manager that’s what they want too.


Learn how to test anything, and learn how to learn quickly, and then in terms of being capable in a new domain it basically doesn’t matter at all. It’s then just about learning the domain language, the new types of risks… it’s about learning a new context and how that defines the value of your testing.


I switched domains a few times, most recently from automotive to ERP and it has never been much of a problem. Relating to the great diagram Jesper posted, the major overhaul happens in the business facing side, you don’t suddenly forget about all the other things :wink: What helps me most getting my feet wet quickly is getting in contact with users, knowing their pains, knowing what’s important to them. My current company has a 6 week schooling for new employees teaching the basics of accounting, finances and other things. That was a nice thing as well,


That 6 week schooling is a really good idea. Simple but a great way to on board new people who may not be familiar with the domain.