I'm in a similar position as yourself as being the only tester in the company.
In terms of approaching testing for a project, my advice is to find an approach/ process that works best for you and your company as each company/tester is different.
Experiment with different approaches and see which one works best. Approaches I've used in the past are:
- Test plan following ISO/ISEE
- Mind map
Each one started with gaining an idea of what was in scope and what was out with relevant stakeholders.
From these conversations, I got an idea of what was needed for the release not just functional testing (i.e making sure it worked, ensuring existing functionality still works (regression)) but also non-functional (performance, security, usability).
Depending on how your company work, you can break these down by feature/ requirement: For each feature/requirement:
- does it work as it should
- does existing functionality integrated with it work as it should?
- does it perform?
- is it secure?
- is it usable?
Then it's a case of deciding what to automate and what not as per the approaches above. I generally follow a risk-based testing strategy based on the technical and the business risk
Severity = business impact (high, medium, low)
Probability = technical/testability risk (high, medium, low)
This forms a matrix and helps me decide priority, what is important to automate and other decisions.
Most important is to always have a definition of done/ release criteria that everyone can agree on - stakeholders, developers, testers etc. There will always be lots of things to test, new and imaginative ways to find defects etc so this is important to help know when to finish and by getting everyone to agree, it helps brings everyone together to help get a release out.
Hope that helped?