Transcripted Summary
What I mean by working solo is the following…
You might not be sitting alone. You might work closely together with your teammates. Still, you work on your task mainly on your own. Now, this is often considered the default working mode, especially in companies where it's still about utilizing their resources 100%, like keeping everyone busy, which is considered productive.
Solo means you work solo and your developers work solo as well. This is an asynchronous way of working. You only have joined forces in the sense that you work together on the same things consecutively. If you're working solo by default in your team, this probably applies to automation as well.
Working asynchronously can be productive or especially perceived as productive. However, it has its downsides, so at times we have to question its effectiveness.
We often long to feel productive and we associate this with being busy, right? We fill our full day with tasks, even in tiny gaps. And when something big comes, we find ourselves not ready to tackle it. We're pretty busy, right? I feel stressed then. No matter what kind of role you consider yourself in or which tasks are waiting, block some time to stay flexible. Give yourself the freedom to provide fast feedback.
So, if you're a tester and you're fully utilized, the following scenario might happen, even if you only have one developer.
Imagine implementation of Story A is ready for review, so you're testing A. While you're testing A, your developer finishes Story B, so you get it for testing as well. Now B has to wait as you already have another task, testing A, right? Or you might have to switch context.
But let's say you stick with A, as you're not finished yet. Meanwhile your developer will start working on Story C. After all, they try to fill waiting times.
Let's say you finish with Story A, and you have feedback on it. You've found something and you tell your developer. So, the developer stops working on Story C and switches context to work on fixing A. Now you have time to move on testing Story B. An hour later the developer provides a fix for Story A. And you have to interrupt your work on B because A has higher priority.
Now your developer can start thinking again where they were with Story C, while still waiting for feedback on A and B.
Phew! Can you imagine how the example would go on? So even in a simple case of just two people and three tasks, it's already lots of juggling.
How would it look like if you add more developers than just one? And not even mentioning who does automation here, not mentioning other things like meetings that only a few of the teams have, or emails or that travel reimbursement you wanted to take care of, or anything.
Another scenario is that you have a question for the developer or the product order and they're currently unavailable. This question will block you and is stuck in the queue. Yet again you try to fill your time. Or maybe someone might need support, you know… messing up my tight schedule. I guess you get the message.
If you work asynchronously, there's only a few things you can do according to my experience.
Allow yourself to stay flexible by not blocking your full time. You can roughly prioritize, but just like with exploratory testing or agile processes, everything you learn will inform the next step. Coach the rest of your team so they can jump in anytime.
Another problem is that you always have handovers between phases which encourage lost information in knowledge silos.
Even if you actively share knowledge, including the whole team, knowledge silos will evolve. We had this case in my team, even with full-stack developers. We still ended up with some developers knowing other things than the others, depending on what they worked on.
For example, build pipeline and infrastructure topics became a huge knowledge silo issue. It was so easy to involve always the same guy and have him working on those topics. So convenient. And the same with one of our external products we heavily rely on. You know, let's have X do it. He knows the product best.
Well in both of these examples, the respective person left the company.
If you're working solo as default mode and you still want to benefit from the whole team approach and testing continuously, you need to make lots of active effort to share knowledge in the team in a continuous manner.
Use demos or "show and tells" to teach about your work. Give lightning talks about concepts. Have someone else tackle the next automation challenge or do walk-throughs. Do code reviews from your side.
Make sure to not only have the knowledge spread in your team, but also in your company across teams.
Form a testing community. Reach out to others and learn how they solve their automation challenges.
The community we have in my company has the main focus of acquiring, applying, and sharing knowledge. We help new testers along. We help each other grow and the company learn. What we do is we have a community meetup, once a month, where we switch between different formats like giving a talk or a workshop, maybe showing what we did or just do lean coffee. We also tried mob testing or viewing conference talk recordings.
We also work on global testing topics together, like recruiting testers or creating personal development paths.
We have support to share learnings with the external testing community by hosting meetups, blogging about our experiences or speaking like at meetups and conferences.
This is a great learning opportunity. Share what your team is doing and trying, share your challenges and lessons, and maybe you can find advice, for example, on your current automation challenge.
