Find good/famous testers and follow them on LinkedIn (preferred) or social media (e.g. Twitter).
They obviously might not be able to spend a lot of time helping you, but they can often point you in the right direction when you have questions. The problem with social media is that it also has a lot of noise like cat photos, opinions on matters unrelated to work etc. So, you will end up wasting too much time trying to find useful content in the noise. But, if you want to see the personal side of your favorite testers, then follow them on social media. As an aside, avoid…actually do not post opinions on anything other than testing/work. There are too many judgemental & self-righteous people out there who can create real trouble for you in the real world. Some of these people can be famous testers
Always have your curiosity ON, on how things work. It should not be limited to the software that you are testing, but have a general curiosity about everything around you. What works on one domain might click an idea in a different domain several years later in a different way, which could lead to disruptive ideas! With loads of information channels available today, only sky is the limit!
There is no document telling you what you should test first. Requirements docs are like iron girders to a building, paint and plaster covers all but their value as a broad outline. You need to make your own maps here. Either study for or actually sit an ISTQB type exam so that you become fluent in the language of the natives.
Read the bug database carefully and learn about types of defect, defect impact and defect severity. Go and play with the software with a mind to visiting the areas that the most bugs got discovered in, in the past.
Discover who the stakeholders are, and try to see from their perspective, the entire machinery. It’s people, it’s processes and finally the code. Then go and interview them. Enter with just one good question about risk to the product, you will find that they spill the beans.
Understand your context (clients to your testing, the product, the users, the power dynamics, etc), even by asking “stupid questions”. Testing is a social activity, not a procedural activity that happens in the void.
Because when somebody says one of these things, they are unsure of what it’s supposed to be. Which means trouble & bugs inc! This is where you go back to the statement above of “Never Assume”
Keep asking questions about risk and use those questions to guide your testing activities.
Put another way, what questions do we need to answer to help us have a better collective understanding of the things that might threaten the value of the things we build & deliver?
To add to this, always be pushing for full understanding. As the lines between test and dev keep blurring, a strong tester today should understand why something fails, and when it’s fixed, how it’s fixed.
I’d push for not being the tester who does a superficial verification and think “oh, okay …” when someone comes back and says something like “there was a config error and we fixed it”.
Ideally, you should constantly be trying to grow and really grok things - what was the config error? What did they change? How/why did that fix things? What other impacts might there be from the “fix”?
I love this one, when I was new to testing, I used to read requirements and design docs and everywhere that words like this cropped up I would go do some testing and find bugs.