Lately I’ve been focusing hard on several other forms of testing to help setup more robust checks around my software. (namely UI automation, performance tests and API tests)
Having spent a good part of my career doing interactive and experiential testing mainly with the GUI, I’ve found the other types to be more intriguing.
So much so that I sometimes find it hard to switch contexts between the hands on tests for releases vs the other ones.
It could be that I’m on the same product for several years now and therefore the “Ooh i found a new bug” becomes the “Oh God! they left out another bug!”
So this got me thinking if I’m chasing too many skillsets at once? Normally you’d have a team where several people pursue different areas related to the testing framework.
Or maybe I need to write a test report on some other product (as a goodwill gesture) to freshen up my mind a bit and find the groove again in the trade I feel I’m a master of!
Testers are either generalists or specialists.
Most are specialists. Some breakdown example: Seven Kinds of Testers - Satisfice, Inc.
The generalists can adapt quickly to multiple contexts and do a decent job for most tasks. Most probably not as good as specialists.
I also notice the difficulty in switching context from the above.
I think to become better, you need more focus on each topic you jump on, develop the specific skills for that topic, plus practice switching over a longer time, like several years.
A third, is that there might be some boredom, caused by repeating some things without trying something different. One way is to give little thought and just do them as if it’s a task/check/chore. Or vary something: go with the developer through some testing pairing/coaching them, go through the code review/inspect/walkthrough instead of GUI, and start guessing the bug by just studying people, their interpretations, and available information without even touching the product, exchange tasks with another person(a BA, an automation engineer, a developer, another tester), get involved into things and find issues much earlier than immediately before the release(design/architecture meetings, ui/ux study design, debating implicit or confusing requirements or specs with a designer, ba or pm, take the product code on the local machine and check it before the developer merges their branch to the main one, etc…)
If being a generalist is something you strive for, go for it. But don’t neglect things where you can improve. If you don’t feel like doing something for a while, talk to the manager, switch the job, and focus on developing a single other skill.
It sounds like you’re just developing as a tester/QA, to be honest. Which is great! I can definitely relate to getting more interested in other aspects of testing/quality that are new to you. It’s quite hard to pick things up in the way you’ve done for years before after discovering new things like you say. Personally, I struggle with being a bit bored doing some testing that I would have enjoyed a year ago because it was relatively new to me.
For your career progression it’s great to develop in the way you are and also for your product/team as it’s a sign of maturing. But it’s possibly worth being aware (and I’m sure you are already) that there could be some testing that will still need doing even if you find it boring. Maybe it’s something someone else could do?
That might not be the case with startups and lean companies, where there may be more generalists. But for bigger companies or as they grow, the team builds out with specialists potentially.
You highlight a lot of things testers will hit at one point or another in their career.
My usual highest value remains interactive and experiential testing and by no coincidence its the one I enjoy the most. Given the choice that’s usually what I prefer about 80% of my time on though it rarely works like that. To keep that higher I am generally on 3 products at the same time.
If single product then I mix more with automation. I personally find I can switch context fairly easily with experiential testing. Automation though I prefer full time focus, I can easily spend a day solving an issue at times and if i step away I find I tend to start again the next time.
Some of the products I am on, I’ve been on a few years but my contribution is down to around a day a week, fairly standard mobile apps tend not to need more than that when its a small team with only a few features being release every week.
I do not think you are chasing too many skillsets but do consider what you enjoy the most and feel you offer the most value at, try and find a way to do more of that than the other things.
It can get a bit demotivating if you spend 90% of your time on secondary skill tasks because its normal to feel you can contribute more when working to your strengths. It’s normal in IT business though for short periods, long term though it can be harmful.
In the earlier days I would spend time reporting issues that would be related to literal instructions (use cases). But since then I have managed to improve my team’s performance by constantly talking about the aforementioned.
as @ipstefan also said, sometimes you have to tell yourself you gotta do what you gotta do!
You could also consider the job market. I see far more roles out there where they’re after manual testers who can do security testing, performance testing etc. After all we’re all here to get paid and earn a living, so we have to adapt to the current demands. I’m a performance testing specialist, but it’s been a long time since I’ve seen a ‘performance tester’ role.
Of course, the rates for these so-called ‘masters of everything testing related’ are pathetically low, but that’s an entirely separate discussion!
I find myself being trapped in this. Since years I’m the only tester on the team and every part of our complex product needs specific, deep knowledge, even for basic things. And we have a rich desktop client as well as a web client and APIs. In other companies I also had to cover mobile devices.
I also do different automation.
One approach to handle this that I often delegate testing of features to developers, supervising and consulting them.
I’m the expert in testing methodology and they have the domain knowledge.
(Don’t call me a test manager. At best Responsible Tester. Sometimes I say Test Consultant)
Don’t expect anything to be normal. It might be reasonable, but just look at what Boing did.
@hananurrehman I’m not sure how much this anecdotes help you.
I’m a sole tester and see myself as a Jack of All Trades. Surely with some shortcomings in some areas.
And being most times alone with my thoughts about testing, having no real test manager who cares for his people, isn’t a thing which makes me happy.
(namely UI automation, performance tests and API tests)
becomes the “Oh God! they left out another bug!” 
Normally you’d have a team where several people pursue different areas related to the testing framework.