Specialist vs Generalist

šŸ™‹ Questions
,
1

Software Testing is a huge and varied discipline with a vast amount of different role titles covering every possible combination of general and specialist subject.

The other week, I came across a post via LinkedIn on The dangers of becoming a full-stack tester. I knew at the time it didnā€™t sit right with me, but that it would take me a while to reflect fully as to why it triggered me so greatly.

In the article, Michael Fritzius suggests the way to mitigate the dangers of becoming full-stack is ā€œnichingā€, his word for specialising.

Now to understand why I think this shouldnā€™t be considered the only approach to a successful career in Testing, let me lay down a few things that Iā€™ve experienced in my career:

  • Only the biggest companies have the funding to invest in specialist testers who focus only on a single niche
  • You donā€™t need a special job title to be the go-to person on a specialist subject
  • Over a multi-year career, you have the chance to pick up multiple deep specialties
  • One of the greatest advantages and privileges of being a software tester, is having the capacity to learn about the full system, built by multiple people or even multiple teams of people
  • The sector changes, and companies keep coming up with new names for the same thing. Focusing too far only on one speciality can hurt your employability long-term
  • Whatever you specialise in, automation as a persistent theme and it can be difficult in the current market to pick up any testing job without it

Why do I care so much? I consider myself to be a Full Stack Tester, despite having never had this as a job title or official role. I take pride in having gone deep on multiple topics, and gained broad experience.

I take great motivation in being able to switch to new topics, within the Testing craft, so I can keep my interest levels and motivation high. There is always more to learn, and while I continue to learn and grow I keep adding more value as I go.

Iā€™ve seen members of the community who struggle to switch roles and get work within their niche, and others who have a diverse skill set thrive. However, I only have anecdotal data on this.

So, I guess it depends on your interests, skill set, what part of your career youā€™re in and what youā€™re optimising for. The job market changes over time, so sticking with one niche within a single role might help in the short term, but is it really the way to make more money and be happier long term?

I would suggest that over a career of 5-10 years or more, going from mid to senior levels or higher, I would expect things will go better for you if youā€™ve gone deep on multiple subjects and can go broad on any topic as needed.

What are your thoughts? Have you felt held back by being a generalist? Had success, or pain, in specialising? I want to hear more.

12 Likes
2

Iā€™m a happy generalist with several strong specialties. I canā€™t say much on the career front, since Iā€™ve been effectively a solo tester for the last 10 years - although in that time Iā€™ve taught myself a lot of different things: C#, how to customize Team Foundation Server, how to administer TFS, how to build a TFS CI/CD pipeline and keep it running, enough about Ruby to maintain the sync tools that keep Rally and TFS working together, and so onā€¦ (If I went through the whole list of things Iā€™ve taught myself weā€™d never finish).

Iā€™d definitely say that being a generalist who can quickly gear up to deal with almost any testing setting beats being a specialist with a defined niche. Being able to state with confidence that it doesnā€™t really matter what the programming language of the automation tool happens to be because in your experience what matters is being able to determine what to use as locators and how to build the underlying logic in your automation doesnā€™t need a specific language. It needs enough programming analysis skill to break down the problem into easily solvable chunks. Being able to state this in an interview helps a lot because it means to a potential employer that even if you arenā€™t familiar with their language of choice (or tool of choice), youā€™ll be able to learn it quickly because you know the underlying fundamentals.

The same goes with business domains: being able to learn the critical aspects quickly matters as much or more than prior experience in said domain. Being able to explain this to an interviewer matters even more.

I donā€™t specialize. From what Iā€™ve seen, specialization is only going to happen consistently in companies with massive testing - and developing - teams. Everywhere else will need generalists because for them someone whoā€™s good enough at many different areas of the field will be more useful than someone whoā€™s stellar at one narrow aspect and not much use anywhere else.

8 Likes
3

In this talk, around 12 minutes in

Mr Bach talks about the perspective of the generalist and specialist from the perspective of the generalist and specialist, and how the definition and perspective can change as you shift up and down the specialism scale.

I found it very impactful and helpful when thinking about levels of specialism.

5 Likes
4

Iā€™ve never really enjoyed my time in bigger companies where you do end up specializing, I loose sight of the entire customer experience, which for me, makes me a less effective tester. But when a system is so complex that one person cannot hold it in their head, by all means you have to specialise. I think we all do become specialists over time, or ā€œsubject matter expertsā€, even in a small company.

Right now as the company grows I can feel that ā€œslideā€ down the scale from generalist to specialist, and although I enjoy being the goto-person for my teamā€™s own area of work, I do miss the broad knowledge of everything I used to be able to hold. But I see it as a role change, NOT as a skills change.
But deep down I do prefer the term specialist.

3 Likes
5

Well I think it might be a bit different for everyone. I work as a consultant so knowing a bit about everything really helps me. Iā€™m mainly focusing on API Testing & Security myself but I like to know more about the rest also.

I mainly deep-dive into the technology and things required for my current client.
But when I have to swap clients, there is a chance Iā€™ll never see the previous technology again.

Which is oke for me. I guess this comes back to the shapes people talk about I T N M
=> CertiBanks ā€“ From I-Shaped to T-Shaped ā€“ Why IT Professionals Need to be Multi-Skilled

Iā€™m not saying Iā€™m pro shapes, nor am I con. But itā€™s kind of how you wish to be.

I-T-PI-Comb-Shaped
I-T-PI-Comb-Shaped1014Ɨ361 65.8 KB

7 Likes
6

This is a really excellent point, thank you so much for sharing!

Even within the same job, the project youā€™re working on can change, and different projects need different skills. So being flexible to adapt to what is needed is very important, even more so when consulting.

2 Likes
7

This is very power, thank you for sharing you experience Conrad. I have a feeling I may have been working with you at one of those companies!

3 Likes
8

Iā€™ve observed this as well. I do enjoy having the freedom to temporarily specialise within an area, diving deep for a while. But ultimately is all part of my broader generalist journey.

3 Likes
9

Really hard question and a very good topic/point.

When I first got into testing I had no idea how big it is, I was happy to be part of a team and to help the team to the best of my abilities deliver quality.

That last sentence became harder and harder as time passed because even though on the one hand I was happy to learn new skills and new technologies at one point you can become overwhelmed.

If I am trully honest I would love to do what @kristof is doing on the Security Testing side but having no projects that do security is not really helping my learning curve :).

To try to answer the question here is my answer: Personally I think we need to be Generalists with some areas or Speciality.

2 Likes
10

Testing is a very broad area and to date Iā€™ve never encountered anyone specialised in the full spectrum of testing.

Where I am now we have a small group of testers, 4 of us to around 80 developers. What we all have is a strong core in testing but each of us also have multiple specialisations so we have that call a friend option.

These specialisations include automation architect level, penetration testing specialist, customer and support management.

I have my own specialisations in quality management and planning alongside coaching and training areas though I prefer to spend at least half my time in the core testing activity area.

If we consider automation as one specialisation, all of us can use automation tools but occasionally Iā€™ll run into things that I need a chat with the team member who does specialise in this area, similarly with security testing I can discover and investigate the risks but often Iā€™ll raise a flag that Iā€™ve found something that needs a bit more in depth investigation at a skill level Iā€™m not quite at yet so I leverage from then.

As a team we can pretty much cover most needs on the testing front, as individuals were about 80 percent.

Another key element is enjoying what you do, if you enjoy an area it is a great motivator to build skill and knowledge in that area.

2 Likes
11

Thatā€™s the catch, every project ā€˜needsā€™ security but does none. Just test it (with approval). Nobody is going to say ā€˜No, need for securityā€™ :stuck_out_tongue:

3 Likes
12

You would be surprized.
In some projects usability, performance and security are either ignored or done quick and dirty because there is no budget :frowning:

2 Likes
13

Yea but thatā€™s exactly my point, in my cases itā€™s always like this, Iā€™ve only been once on a project where security was a focus. Thatā€™s why I suggest to do it myself :slight_smile:

3 Likes
14

Iā€™ve found my career, and the options available to me, have really grown as I moved towards becoming more of a generalist (although with a core specialism). These days I say that Iā€™m an all-around or full stack tester with a specialism in exploratory testing & human factors.

As youā€™ve said @fullsnacktester, many orgs now want embedded technical testers; so we need to be able to showcase this ability in order to be palatable to a wider part of the market. Thatā€™s why I looked at becoming more technical and wrote about this:

3 Likes
15

I tried to find something to specialize in many times, but I never really found anything that would hold my interest.

Thatā€™s when I realized that Iā€™m meant to be a generalist, everything interests me but only to a degree, Iā€™m the happiest when Iā€™m doing a lot of different things.

As much as multi-tasking harms productivity I donā€™t find it hard, on the other hand dealing with a single task that requires me to focus on it deeply is very challenging for me.

1 Like
16

Being a generalist with the occasional deep dive on a specific niche is probably best for personal and career growth. If I have to put a shape to it, it would probably be a small ā€œmā€

One part of the original article does not sit well with me; there are only four areas listed, ā€œfunctional testing, performance testing, security testing, penetration testingā€ (and I would consider penetration testing part of security testing). I also donā€™t agree about testing only in a certain industry.

Are there other areas to specialize in?
I imagine one can break down the functional testing into UAT, Backend, API, and Database? However, I rarely see a job posting for ā€œDatabase testerā€ or ā€œAPI testerā€.

3 Likes
17

There are a fair many different role titles, one useful list can be found here:

I havenā€™t reviewed it to sort into specialisms, but you could give it a go if you like.

3 Likes
18

Thanks for the list.

Nice! ā€œDatabase testerā€ and ā€œAPI testerā€ are on the list :smiley:

I skimmed the list and most are generic terms for QA, and not necessary specialization.

2 Likes
19

My thought process about finding something to specialize in was around:

  1. What is FUN?
  2. What does nobody do or what are people scared of?
  3. What topic is out there that people donā€™t know enough about?

And for me here in Belgium, itā€™s APIā€™s & Security. People are scared of security and APIā€™s are just APIā€™s for them (back in the days) because many checks were still in the Front end ā€¦ until a funky tester comes by and goes all out of his way with crazy tests to break APIā€™s :stuck_out_tongue_winking_eye:

So that was kind of my thought process, security Iā€™ve already been doing since I was 15 and APIā€™s well, at the time when people only wrote front end checks, APIā€™s were heaven to play with :joy:

4 Likes
20

That feels like a excellent opening line to your CV :slight_smile:

OK. So Iā€™m trying to define more clearly what I understand QA specialization to mean. In 3 roles I worked with >1000 engineers I was doing what I call ā€œspecializingā€. Let me expand on that in the specialization context and why that mattered to me.

  • ~16 years back I was on a team called PAN, which means personal area network. We built the comms stacks for infra-red (yes), serial, USB and bluetooth, (wifi was tiny.) This meant I learned a lot about session, transport, network and data link layer as it applies to those stacks. The testing I did was largely non e2e. Vendors were responsible for applications, not us.

As a specialization the PAN team testing I did was like doing back end web service work today, invisible, but if it does not work, everything is pretty much pointless. So very much mission-critical.

  • My next specialization would take me into the realm of building testing tools in the virtualization and OS arena. I had only used a few test tools at that time, but I had had to build a lot of tooling before, because the closed interfaces of mission-critical and back-end code is actually very hard to test remotely well using traditional tools.

So I have specialized as a tool writing and framework writing person for almost 8 years, toward the end of that I moved away from making tools, to actually using the tool, which was much more fun than writing the tool.

  • Recently did a stint at a large company building an open source library stack for hardware. I was able to lean on background from my very first specialization because this was all about USB, Bluetooth, serial and a bunch of new network stacks.

It was specialized in the same way as that first specialist tester role. Working at those lower layers of the network stacks, testing that the lower layers were not just bomb-proof reliable, but also secure. Knowing how to test a component is super robust and reliable is a specialist skill, much like security testing is.
Today Iā€™m a mobile tester, we are a small team, there is little room for specialization, and everything I we do, we share out in the team. I used to think I was still the process and documentation specialist person. Lately I am even finding that my skill at diligently documenting is being surpassed by a colleague. Being across everything at once finally feels like my bag.

3 Likes