In discussions about quality engineering and leadership, I’ve often talked about the bigger picture, and not letting your job title hold you back. The idea being that you can influence more than you may realise, and be a leader even without official authority.
But looking on the other side of that, there may be reasons to be selective about what kind of work / tasks you take on. For example, to:
Manage your workload
Avoid burn-out
Allow others to step up
Focus on other tasks / work on developing other skills
Avoid becoming expected to pick up all “unloved” tasks / glue work
It occurs to me that, “everything in moderation,” applies to our work too - it’s great to be enthusiastic and go above and beyond, but how much is too much? As quality and testing professionals, what kind of work / tasks do you deliberately choose not to do, or do very little of?
I no longer accept tasks that are assigned to me verbally, whether by seniors or leads. Even though I never questioned or argued when tasks were brought to me, regardless of how time-consuming they were, I noticed a pattern. When I explained that my task was delayed because I picked up XYZ task that was assigned verbally, the people who had assigned it would often claim that I had chosen to take it on myself and they hadn’t pressured me to prioritize it.
After several such incidents, I decided to draw a line. I informed everyone that I would no longer take on any tasks assigned verbally. If something truly needs to be prioritized, they must either email the ticket with my manager in cc or tag both of us in the team message. Sure, this decision upset a few people, but it has also brought some clear benefits.
Benefits of drawing this line:
No one brings tasks to me verbally anymore.
My manager is now in the loop and knows exactly what tickets I’m working on.
I can manage my workload better without being distracted by unplanned tasks.
With better workload management, I can dedicate more time to testing.
For me, it would be avoid meetings and calls unless necessary, and avoid manual testing of documented test cases, especially regression tests - I only assist when short on resources, because those tasks are better left to others who specialize in that or whose main role is (manual) testing, my time & skills are more valuable to apply elsewhere.
I try to avoid writing “scripted” manual test cases (having long lists of actions and expected results). They seldom fulfill a need aside obeying to imaginations of other people how they think testing should be done. Mostly managers.
Doing testing more exploratory and the reporting of that tailored to the need of the team is in my context way more helpful.
Knowing where / how you can add the most value and concentrating on that sounds like a good approach. What has the response been like when you’ve declined meetings / calls that you don’t find necessary?
Great approach to focus on what’s actually needed and bringing value. Probably a good idea to check in every so often and ask whether what we’re spending time on matches that.
There are so many monotonous work on daily basis that i dont enjoy doing like : Most of them already mentioning attending meetings, but sometimes arranging those meetings, after checking with everyone’s calendar and coordinating teams for better communication is very important , but time consuming and often is not recognized and appreciated , and i dont enjoy that… Also sometimes root cause analysis of each every bug small and big critical not critical for the sake of those retrospective meetings is also not a fun process or task that if i asked i would definitely skip it
I choose to NOT develope a test so deep while the envihronment is not fully set. Sometimes happen that my leaders want to add new features, test types, assertions but the Testbench is not ready. So I can not prove actually if the things I implemented works in reality. So when I develope this new features so hard happenns that when I have the real thing to test my implementation, I need to make a lot of changes as most things do not work right away. So the time used to develope fancy stuff is lost as I have to do big changes. Hope you got my point
Sometimes the simplest fix is to stop work at the end of your work day. If work is regularly piling up, it is your manager’s task to prioritise those things ultimately. Do your your job of course - we are professionals after all, but if the job regaularly requires unpaid overtime or uncompensated training, then it’s worth discussion. And that goes for doing work on behalf of lazy colleagues
The avoid burn-out problem is far more complicated for anyone with ADHD. Recently spoke to someone who copes by doing a lot of martial arts and free-running. And he told me, yeah he even got diagnosed for chronic fatigue as a kid at one point. Some people thrive by pushing themselves, and then having no buffer. A lot of tools and time-awareness help. A Pomodoro timer to remind you to take breaks often and step back, once you start using it continuously, can make a huge difference.
Myself? I do choose not to do the more repetitive or boring bits of tasks. That sometimes blocks a task I’m then not motivated to do anymore. I do need to say no a lot more often.
This very frequently happened to my tech team as a whole. Once we were able to root out the “back door tickets” and other invisible work, planning became easier and sprints were less stressful.
Enforcing an SOP for work also encouraged improved stakeholder meetings; this allowed all stakeholders to have a voice but demonstrated the competing priorities. Funny enough though, it also surfaced many overlapping needs that easily bubbled certain work to the top sooner making everyone happy.
“Ticket or I kick it”. Thats awful. I don’t know, felt like I needed to end this on a mnemonic.
I think for this RACI document will be helpful at the organziation as it brings clarity to who is accountable for which task and there will be no confusion or over-burdening of the unassigned task.
I like the “Ticket or I kick it”! While I was admiring this mnemonic I also thought about “Ticket or Leave it” (like take it or leave it )
I agree about what @ujjwal.singh said, tickets gives the people some sort of accountability in task assignment as it can benefit both parties – the one doing the task and the one assigning the task – by many measures such as team transparency, scope, workload, and scheduling.
Since we follow scrum or agile (or whatever it actually is in our case), there’s always a gap of responsibilities from that side into the usual SDLC. Being a sole QA, I avoid taking up responsibility related to any of the scrum ceremonies.
I’m all the more happy to be part of the refinement process since that aligns with shift left.
For testing, in our team we write use case documentation extensively so for smaller features I do exploratory style testing while for a major feature I like to draw up a mind map as a starter then work my way in.
)