Advice for people new to testing

So there are lots of people discover MoT through the essentials training, looking to start a career in testing.

I thought I’d ask a question to help people like us/me. So…

If there was one piece of advice or information you wish you had been given earlier in your testing career what would it be?

7 Likes

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 :slight_smile:

Good luck!

4 Likes

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!

9 Likes

Listen to a wide range of opinions from inside and outside your organisation. And learn how to ask for help effectively.

8 Likes

I love this advice :grinning:

2 Likes

I’ve written a few blog posts on this topic :slight_smile:

4 Likes
  1. 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.
  2. 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.
  3. 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.
6 Likes

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.

8 Likes

For me it’s got to be “there is a better way to do things, and plenty of people have already figured it out”

There are tonnes of great people and places to learn from. Seek them out and keep trying to get better.

5 Likes

Probably one of the best things there is:

neverAssume

Things Testers like to hear:

  • Normally …
  • It should …
  • Perhaps …
  • Maybe …
  • “all good”

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”

7 Likes

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?

4 Likes

I’ve often thought of testing as the “art of asking the right questions, repeatedly, and then asking some more”.

4 Likes

I love that description, @bencf1. :grinning:

3 Likes

I’m loving reading these tips and hope other newbies do too. Thanks everyone!

4 Likes

No question is a stupid one - always ask!

3 Likes

That’s what QA stand for: Question Asker.

5 Likes

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”?

6 Likes

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.

6 Likes

I’m also new in Software Testing, so this is very helpful. Thank you all!

1 Like

I love this blog! Thanks for sharing.

2 Likes