Almost 5 years ago, I've started my QA journey as a student (AKA Junior) and didn't even know what QA was! Little by little, I started picking up pieces of what QA might actually be and how to do it properly. A lot of mistakes were done in the first year (tbh, it was the hardest one for me personally), but as the years went by, it gradually became easier because of all the knowledge I've managed to gather. This post will have a few tips for all my fellow Junior QAs' that are just starting out and hopefully, you can learn from my mistakes.
This is the most crucial part that will make your life much easier. When you are testing web app, mobile app, TV app, etc., you HAVE to write down every single thing you notice while testing. Reason for that is very simple: You'll forget to report it later. That's it. It happened to me and it happens to everyone. We're not robots that can remember every scenario that we've tested, step by step. We're only humans that have errors. Those things that you'll write down (whether it's on plain paper, notepad, code comments, etc.), they will become useful when an unexpected issue appears and someone asks you if it happened before. And guess what, you'll have a log of it written somewhere and explain that it was tested and eventually reported issue.
You might think this is not possible, but when it happens, it's the best relationship within a project (or a whole company) you can have. At the beginning, devs will hate you, prepare for that mentally, because it can be exhausting to hear "It's a feature, not a bug" a million times. In those moments, if you are really certain that it's actually a bug, you can ask another dev for a second opinion. In some cases, it really can happen that it's a feature, no matter how hard you really see it as a bug, and that is perfectly fine. You've done your part and move on for more testing. Just remember that, in this relationship, you have your best intentions to break their code for better product at the end. :)
Usually as a junior, forgetting what's on your plate for testing is really easy. You want to prove yourself to the others by reporting as many bugs as possible, and it's completely natural to do that, but one thing to understand: You've been given a goal to accomplish under defined deadline and with certain requirements. Follow those requirements and you'll be golden. By reporting visual issues (icons and pixels misaligned, missing exclamation mark, colour is 5% brighter than in design, etc.) before incoming release, you'll create a mess inside your team and nobody needs to think that product is not working properly. Your time for reporting those issues will come. Sticking to your main goal is something you should have on your mind, day by day, as you're testing a product.
Everyone can test it, and you're not everyone. You are QA, and your job is to think outside of acceptance criteria (AC). Every issue that you'll discover will mainly be between the lines of written AC and it's your job to turn on your special QA skillset that you possess and break the AC, little by little. It's your time to get into the shoes of all those end users that will be using your tested product. Think of every possible way they can use it, convert it into cases and test it.
Hopefully these tips might come in handy to some of you, as they would certainly have helped me when I started as a junior. What do you think about them?
Let me know in the comments if you have any other tips or disagreements you'd like to share.