This is an excellent question and the answer would highly depend on your context.
Testing is way more than interacting with the software, but I do try to maximise my time exploring the application (in my case, a mobile app).
I also think a primary task for me is to âshift leftâ, so I try to involve myself in the things that happen before code is written: refinements, risk sessions, asking questions. All to try and figure out things before code is written.
My test mission is: I want to be a catalyst, inspirator, facilitator to improve testing as a whole with other people. So I make sure my team ALSO does a lot for testing. The developers in my team help with testing primary tasks as they create most of the automation in testing.
This mission helps to keep me grounded and I check in regularly to make sure I donât go off track.
What do you think are primary tasks for testing? Answer this yourself, and map it to your current work situation and see what you can improve (if needed).
I try to minimise tasks that I think donât add value, like writing extensive test reports. I try to do âjust enoughâ for everything. My reports are short, but contain the information that I think the reader needs to know. I prefer talking to my colleagues over communicating in JIRA tickets, if you get my drift.
There is one heuristic that can help guide you in this, itâs from the book The 7 Habits of Highly Effective People. In the book, a quadrant is described.
important / urgent | important / NOT-urgent
NOT-important / urgent | not-important / not-urgent
A lot of people can fall in the trap of spending most of their time in the top-left quadrant because it feels so good. The sense of urgency is there. But donât forget that most of our valuable work is done in the top-right quadrant: important work that isnât that urgent.
The 2 bottom quadrants you want to minimise because THIS is where the bullshit happens, imo.
The constant barrage of emails, status reports, interruptions that could have waited, the self-chosen distractions.
Most importantly though: MAKE your work tangible. At my current client (I just started a month ago ) my mission is also to be very public about how I test and what I test. So every exploratory test session I do I write a nice little story in the JIRA ticket so people KNOW what I have done. I want to be accountable for what I do. The automated tests are clear tangible pieces of work, but the rest of testing can be like that too! Just keep it simple, keep it small. But communicate about what you do.