Hello and welcome!
I wanted to ask, when I start, what should I focus on as the sole tester?
Learning the product, project and people.
Product
The product is the thing your company makes, obviously, which you can explore through the UI. But you can also explore it through the code, a database, any APIs, the manual, the website, any stored data, and so on.
Learning the product will give you an appreciation of more dimensions of the product, and will also force you to ask for access to stuff that you need.
Project
The project is the building, testing, maintaining, debugging, shipping, scheduling, designing, etc of the product. Learn how your product gets from an idea to a user. Look at the processes. Look at how developers work. See who you can look to for help.
Understanding the project will help you make sensible decisions when it comes to coming up with a strategy. If all your users only use one browser, or your product only supports one browser, then cross-browser testing would be silly. It may be harder to lean more on automation if the product changes all the time. If you have more influence over process you may want to make improvements, but you need to know who you are affecting when you make changes - who is connected to that process. Your testing schedule will likely have to adjust to your release schedule.
People
People include fellow testers, people on your team, management, operations, support. Consider who the users might be. Learn what they pay and how they pay for your product. Establish good relationships with people involved in the product you’ll be testing, especially those people that write code for it.
People are everything in software development. The people you work with are the ones who can help you achieve what you need. Your understanding of their needs and wants helps you to provide for them better. A good relationship with your team will help you to make process improvement changes more smoothly. Understanding your users and customers better helps you understand what a problem is and is not when it comes to your product.
You can only get out a good product if you can figure out what “good” means, and to whom. What would a good, high-quality product look like to a user? How about a different kind of user? Or to your company, or your team?
Also, do you think being the only tester will be good for my career path?
Yes. I was the solo tester for a company setting up testing from scratch. They had a pile of written test cases that were simultaneously vague and overly-specific. They were also tedious and numerous. It wasn’t a good fit for one tester to build, maintain and grow a mountain of documentation. So I did a little research, found out about RST, and learned how to deformalize our processes so I could do more in less time without losing my mind, and better support our team.
The opportunity you may have to guide processes and establish good strategy is huge. Obviously this is more responsibility, but honestly I wouldn’t have it any other way. Quite literally; I don’t work where I can’t be responsible for my work.
So it’s an exciting opportunity for learning, experimentation and change!
I still feel unsure about my abilities and lack confidence.
Same. I think I’m just going to say that you’re more capable than you might assume. The real basics of testing, like exploration, is already known to you. If I hand you something and say “what do you think of this?” you can already explore the thing, ask questions about it, learn more about it, make judgements and report your findings. Testing is basically that, but more so.
Your abilities, knowledge and skills will grow from now until well after you retire. Your employer should know about your experience and predict your need to start somewhere and learn. Keep researching and you’ll do great - you’re already here asking questions which is a better start than you might imagine.
I take a long time to write test cases
My immediate recommendation, which is a surprise to nobody that knows me even a little, is to deformalize those cases. Consider shifting the focus of the case from what you are supposed to do to what you want to achieve. The disadvantage of this is that you now have to achieve your goal yourself without instruction, but the advantage is that you can adapt what you need to do at any time. The case no longer needs heavy maintenance as the product and project changes, nor takes forever to write or execute, and you can focus on actually exploring the product. So take what you think the test case is for and make the purpose of the case the subject, instead of step-by-step instructions. You still take notes of what you do, and what you find, and what you need, and what questions you now have, and can store those notes instead of test case steps.
So instead of “1. enter username X, 2. enter password Y, 3. Check “login success” is displayed” you could write “Login with X/Y and confirm successful login”. If you really need to write down what makes a successful login, then do so.
Writing stuff down is a cost. Try to give yourself the opportunity to only be as specific and detailed as you need to be. If you have to write down every possible path under specific conditions for some reason, then do that. If you don’t, then don’t bother. Decide what you want to achieve, and only do that.
If you’re thinking “oh no, how do I figure all that out?” then start with a big question, and do a session of exploration where you just find stuff out. You write down something like “learn about this functionality” then make notes as you walk yourself through it, and discover stuff. Sometimes that stuff will be “oh, that looks crazy important, that’d suck if that goes wrong” and that’s an important risk in your product that you note down. Then later you might do a session exploring that risk, thinking about all the ways it can go wrong, and all the different scenarios that might throw up problems. That’ll give you a bunch more testing to do around those scenarios. And so on. Testing is exploratory by nature, and as you learn about a product you’ll understand better what you need to learn about the product.
I worry that I’m not covering all the requirements
Same. Here’s the problem you will face from now until forever: there are infinite requirements. “Software should not contain offensive language” and “product should not wipe the hard drive” are requirements that nobody writes down because we all tacitly know and understand that those are things software should not do. Except when it should. Hard drive wiping software probably should wipe hard drives. Anyway, if you learn the product, and who uses it, and what they value, then you can do a better job of guessing what those requirements are going to be. Requirements documents are a great source of ideas for requirements, as are people you can ask about what things should or should not do. You can put important requirements in your deformalised test cases, so you know what’s important to cover.
Testing is about learning stuff and telling people. Your goal is to learn important things about your product and then tell your test clients (usually developers on your team and managers who take an interest) about what you found so they are better informed and can make better decisions. Finding out what information is important, and how much information is enough, is part of what you’ll find out as you explore the product, project and people.
My biggest fear is disappointing my boss.
Keep your boss in the loop, or at least offer to. Perhaps keep your notes in a place they can access. Try to talk to them regularly about what’s going on, and consider reporting your findings at some point. This way if your boss is unhappy with what you are doing you’ll know early and can adjust accordingly. Obviously there may be a hierarchy, but find someone in charge of you and connect with them. The whole point is to get the best out of you, and any half-decent manager will want you to keep them updated so they know you are making progress in a direction you both agree on.
Decide not only on what you’re going to do, but consider why. That way you can better explain it to others, and make them feel more comfortable with your decisions. Even if it’s “let’s give this a go, it won’t cost much and it’s worth a try”, which is how I sold my deformalisation project to my manager after I realised that our UI was highly resistant to automation hooks. Saved us a fortune.
Keep at it, and if something looks too big and scary either break it down into steps or leap straight into it and give it a go knowing you can stop any time you want. Remember that we’re all only human, and all we can do is try.
Best of luck on your new journey!