Domain Knowledge - Always Starting Back From Zero

This is something I’ve been think about a lot lately, from my personal experience, testers are generally viewed as the most knowledgeable people in terms of the domain related knowledge of the product. I’ve seen a lot of testers who are well acquainted with the business logic of the product they’re testing, but, sadly lacking in other skills. In general such individuals are the first ones to be made redundant when the project is over and/or there is a budget cut.

Whenever a tester changes jobs, or just goes to another project in the same company, we have to start acquiring the knowledge about the new domain, starting from scratch yet again and sometimes I feel like I’m wasting those little grey cells! From my side, I’ve been trying to get into more technical kinds of testing and trying to get a better grasp of recurring patters in testing, to get more of that “meta” knowledge, the heuristic kind of stuff and also pondering of some test management/lead paths and the idea of being a hired gun - a freelance consultant focusing on process improvements and such.

I’m curios what are your though about this issue?

Sometimes it can feel like this mythological Greek dude:
image

4 Likes

I don’t think you always start back from zero. You’ve always but always learned something new on your projects. Think bigger, developers have the same issue. They learn their technical skills on the project but on the next project they will work with let’s say C# instead of Java. + They have to learn the product again anyways.

I currently work as a consultant and none of my projects have been the same. Sometimes I spend 3 months on a project or sometimes a year. There is always a learning curve when moving to different projects but the things you learn are takeaways and you’ll be able to fit them into your new project but just under different tech.

That’s going to work out great if you’ve seen a lot of projects and tech. Imagine being a freelancer who worked on 1 project with 1 kind of tech. A lot of companies still see this as a junior profile. Even though he can have 3-5 years of experience. Imagine now a freelancer consultant with 3-5 years of experience who has seen a lot of tech and is able to adapt to different environments. :wink:

4 Likes

That’s quite valuable perspective @kristof thank for the fresh view on things!

1 Like

yea I speak from experience :stuck_out_tongue:

I’ve worked 5 years in the same company and then I moved to consultancy. I’ve been doing consultancy now for almost 4 years and if you look at my resume, you’ll see a big difference in those timelines and the tech I saw! :smiley:

2 Likes

hi @mirza , Partially agree to you its not domain its more about product, may be domain like telecom, finance , banking etc might remains the same or may differ but in the same domain product will definitely going to change but YES QA is the one who knows all the sub-system and have end to end knowledge of project and expectation form QA is to acquire the same knowledge when moving to another project / company.

But the good part that remains the same are QA concepts and learnings , Process etc.

2 Likes

@theology That is something that I’ve noticed with some testers, for instance, I know couple of people who worked in a lot of companies but they were always let’s say on insurance related projects, I wager that working in the same domain can help you gain a lot of transferable meta knowledge. :nerd_face:

1 Like

Though not directly contributing to the discussion, wanted to add, if/as need to start near zero between projects/jobs, it might be worthwhile to consider working across domains/industry/field, when feasible.

Granted working within the same industry/field helps keep and build your domain knowledge, it’s kind of a the same stuff again with some new flavor alterations. And this can provide some job security as well based on experience & expertise.

On the other hand, expanding to other industry/field allows you to be more versatile and similarly employable within your respective career (i.e. for tester, that can mean test many different things, processes, as well as test automation for different things). You probably get this more with consultancy that @kristof mentions, it’s not just tech that can change but the domain/industry/field as well.

2 Likes

True, but when you do consultancy you can also choose to stick to your domain/industry. Which is a double win! :slight_smile:

2 Likes

Good point about sticking to domain/industry for consultancy.

On that note, I don’t think it that helpful to stay in same field for years, a decade should be good. But does one really want to be that much an expert to be over 10 yrs in a particular industry like in the past where folks would work for ages at the same place and retire? Same type of role is ok compared to being in same industry. Although, if one really loves the particular industry, that makes sense to stay. Otherwise after enough years, might be time for a fresh start in something slightly different (same role, different industry, etc.).

Or, for some semblance of familiarity while offering some fresh-ness migrate to a field or sub-field that is closer to current field. Some examples might be like telecom to networking (and vice versa) or bio-tech vs healthcare, finance vs insurance.

At the same time changing too frequently across industries unless can’t be helped is not a good idea. That reminds me of people who change jobs frequently every year or two.

2 Likes

I’ve moved from real estate, to gambling, to parking industries while climbing the “QA ladder”.

With every job I got more comfortable with the fact that it will take 3-6 months to get up to speed with the new domain knowledge and maybe a year to back to that “go to person” status.

But it’s the experience and confidence in your ability to build and test great software that helps cut that down. There’s always tons to take forward, you just might not notice until you are in a situation and you’re able to say “oh yea, I’ve done something similar and we should watch out for xyz”.

5 Likes

Personally, I don’t think I do ever start at zero when joining a new project/domain. But adding to the knowledge I already have.
With that said, about that particular product/project/domain it might not be much, though. But still, there are maybe patterns to recognize, methods that could be re-used, and parallels to be drawn, that could help familiarize with the new, the yet unknown.
I’d like to believe, with every project we have done, we add some more skills, tools, knowledge, and methods to our tester backpack. So whenever we start again from ‘zero’ we could use the already available and build up onto. And with every new learning, we learn something about the learning process itself. By retrospecting what worked well, what helps and boost the learning, the ability to get into something new grows as well.

3 Likes

I’ve always stuck to a few domain core areas. For example if the product does not care how long it takes a packet to get from A to B, it’s probably not my bag. Being close to the metal is my thing, if it’s not possible to Yeet it out of the window or even restart it, I would struggle. I like to stick to my strengths and keep away from my weaknesses unless I have a strength they want. I guess it’s good to start from zero, but if you live near a technology hub, you have much more choice and can find companies that have jobs that touch your domain. Being near the kind of jobs you like helps.

But these days, a lot of companies are keen to bring on people who are from disparate domains to their own, because someone who is happy to move domain is also going to be happy to experiment and show you some tricks much more readily than an old hand who is not in the mood for taking a risk.

2 Likes

I qualified as a librarian, then worked in the Government sector (social security clerical factories, then industrial injuries and finally twenty years in utilities regulation), then went freelancing, working in business administration (law and the travel industry), medical equipment software and finally facilities management (working on workflow and call centre management systems). In the meantime, I had side hustles in industrial relations, event management, publishing and photo-journalism. My current role is in the realm of university timetabling. I think my employers took me on precisely because I had a wide range of experience in different business and tech domains!

2 Likes