Full stack tester and context switching

Hi all,

I was pondering the amounts of context switching I have to do in my team which range from:

  1. 3 amigo sessions and test planning
  2. Exploratory and functional testing for FE
  3. Exploratory and functional testing for BE (APIs)
  4. Accessibility testing for FE
  5. Release planning and management
  6. General admin (managing 2 people other quality strategy stuff)
  7. Production monitoring (what do the users actually do and what errors exist in prod)

Is this normal in your places? How do you manage context switching?

The big ones I struggle with is FE vs BE testing and the tools I need for both and adequately applying critical thinking.

And as a side note, do you have full stack developers? We have specialists for FE and BE so I find it interesting to be “full stack” as a tester.
Some pondering from me. :smiley:

6 Likes

I can relate to this! Add to their, I’m also doing automation for the squad.

I get frustrated I can’t do more, but realistically the only way I survive is by dropping some parts depending on the sprint.

Thankfully not all our products have front ends, so I can focus on API automation. But, I find I’m really neglecting my forward planning and analysis…and reporting.

We do have multi-skilled full stack Engineers, although again we don’t do front end changes that often.

But we do switch between a huge product estate written in different languages!

4 Likes

I usually wine and complain until they cut me some slack :laughing:

But to be honest, most problems I had with context switching was in a company that had mostly american clients, now my current company has europeian clients and its much more easy going.

3 Likes

@punkmik - Do you often have to stop in the middle of a task to do a completely different task ? How often does this happen ? What are the challenges which you face due to context switching? If you could list some of those challenges, then it might be easier for people to suggest solutions.

PS -
I’d imagine its a bit hard to suggest solutions/cures without knowing all the challenges/symptoms.

3 Likes

I think this is par for the course for modern tech, not just testing.

Engineering problems and solutions are complicated with lots of things needed to be tied together for everything to work. It’s rare that any engineer can really be a specialist, and agile encourages t-shaped skills and team based approaches.

There’s going to be context shifting as the whole team is expected to be familiar with the surface of the application (and it’s required to make sure you don’t have single points of failure).

We spend a fair amount of time during our sprint planning trying to make sure we’re focusing on holistic problems, rather than too much depth on implementations/narrow focus areas. It slows us down a little as a team, but having everyone consider everything with a broad perspective lets us build full solutions, instead of a bunch of discrete bits that don’t actually work together.

3 Likes

This is a problem. I use a notebook to keep track of what I need to do each day and can also move tasks to the next day in the notebook. This helps me to keep track of what I have done and what I need to do.
I often take a break between tasks. The break can be a domestic task, pulling some weeds out of the garden or going for a short walk. I find that the break helsp clear my mine and enables me to focus on the next task

1 Like

Interesting, why do you think that is? Better expectation management?

1 Like

Good and valid question.
I often have stop and restart tasks such as:

  1. exploratory testing a feature
  2. Solve an issue for a direct report
  3. Help external pen testers
  4. Answer urgent questions from prod support

Then there is other context such as testing a feature for the Backend vs the Front end and what each entails, be it jenkins vs GitHub, postman vs cross browser.

Hence I struggle a bit. I guess the main thing on reflection is being interrupted in critical thinking work and being expected to do it while doing a lot of reactive work and my brain struggles with that.

2 Likes

Interesting approach about the hollistic part. We do that too but two specialists get together to design how the front end and back end will communicate and as tester I try to be involved as much as I can but that’s then another thing to add to my list to be available for.

So it is tricky to get the balance right.

1 Like

Thanks Mike! I do notice that I do better work if I take breaks to water some plants or do 10 mins of skipping or something.
But it is hard to sometimes make the time when you fell short of time.

My notebook is full after 3 months and I need to buy another. :joy: I am scared to look back at it to see what I have forgotten. lol

2 Likes

What I have found challenging is managing expectations. I can’t do everything for everyone. I can see what I write in my notebook but no one else can. I find that I am posting what I am doing in several Slack channels.

3 Likes

That sounds tricky. I find saying no difficult but it has helped me a lot.

My problem was many meetings too. And I decided to not go to quite a few of them anymore and just accept the outcome. This has been very difficult as I like to be in the know of why a decision was made but sometimes I have asked to get the info.

2 Likes

Hey there,

multiple context switches throughout a day has been part of every project I can think of. Usually they affect all roles in the team.
Part of the switches is due to the nature of our work that we just cover and are involved in different levels of the software developemnt process. that I usually experienced as something positive as it also changes things up.

For me and also most of the team members, it became a problem when there were frequent interruptions that actually made work and progress very difficult (or we had a lot of overhead keeping track of where we were or had to start over again). At that point this usually was adressed by someone in a retrospective.

Depending on the cause of the disruptions, the following things worked for us in the past:

  • keep morning/afternoon free of meetings on N day(s) a week
  • talk about how it is ok, to not immediately answer messages / calls / email and what’s an appropriate time frame to expect a reply in
    • we realised we expect different reply times depending on the medium we use
  • use DND status to signal you don’t want to be interrupted and in which situations it’s ok to contact someone anyway
  • when working on something and questions pop up - going through the whole topic and collecting questions / issues before finding someone to adress them
  • when interrupting someone - let them know
    • what its about,
    • how much you want to talk about / how long you think it will take
    • if it’s blocking you or how long you can wait for an answer

some things worked better, some less - but i guess this depends on the individual preferences. I would always talk with my team about it to find a solution that works for everyone / everyone can live with.

1 Like

Partly I try to make myself resilient to the chopping and changing. Partly, I push for better overall workflow. The volume of meetings, during lockdown, has been a problem. There’s no point complaining too much about that to management since their response is going to be a frustrated “Yeah, well try being us”. What we have been able to do is force the internal meetings down to the start of the day, and that is giving engineers a good run planning/organising and completing their tasks.

As for the resilience bit… Last year I tried organising my time using Trello; this year it’s just note keeping and a daily dashboard in OneNote. I’ll work something out. Eventually.