Skip to main content

The importance of quality engineering has resurfaced as whole industries shift to remote operations while attempting to maintain the quality of their processes and products. 

COVID was a game-changer for the entire world. As governments enforced social distancing and quarantine measures, companies had to reinvent themselves regarding working methods. 

As a Tester, SDET, QA Engineer, or any other role responsible for driving quality in your company, your day-to-day was likely disrupted.

Effective Quality Engineering in a Remote Setup

Before the pandemic, I already worked fully remote at Auth0 (a globally distributed remote company), and I have worked remotely before in other companies as well. 

In this article, I will share my tips, tricks, and processes to manage remote work and Quality Assurance practices. With quality engineering trends rapidly evolving, especially in remote environments, it's essential to stay updated on the tools and strategies that can support this shift.

The biggest generic advice I can give you is to be prepared for asynchronous communication—you'll often have to wait to interact, and you’ll need to learn to deal with that.

As you implement remote practices, it’s important to recognize the distinction between quality engineering and quality assurance. While Quality Assurance tends to focus on defect detection after the fact, Quality Engineering is a more holistic, preventive approach, ensuring quality is baked in at every stage of development.

Strategies and Tips for Remote QA Engineers

1. Disclaimer: This is Not Exactly Business as Usual 

During the pandemic, remote workers often had extra stress and pressure (children at home, improper office conditions at home, deaths or illnesses in the family, etc.). Whether you are in a manager, lead, senior, or junior role, it is crucial that you understand that what is currently going on is not what normal looks like. COVID was an edge case (hopefully!), and as such, it required extra adaptation from everyone.  

As a manager, show your direct reports that you are there to help. As a tech lead or principal, give your team direction but show that you are human too, and they should feel safe to show vulnerability as well. And for the rest, don’t feel pressure to perform like you usually do – it’s understandable that things will slow down.  

Companies should acknowledge that their teams’ velocities will decrease and that remote work is not at fault here. These are unique circumstances. Remote work allows your company to function, even if not at full speed.  

2. Code Reviews Are One of Your Best Quality Gateways  

Even if you’ve traditionally had a more manual quality role in your company, code reviews should already be on your radar. They are often an important part of the software development lifecycle and serve as a touchpoint where folks are forced to communicate with each other to improve code quality and prevent mistakes. 

In a remote situation, they are especially important because they are a natural ritual that’s usually already in place, so they will be easy to enforce. If used correctly, they will help you with those asynchronous communication problems I mentioned earlier. Leveraging the right quality engineering software can significantly enhance code review processes, streamlining communication and reducing errors before they occur.

Discover how to deliver better software and systems in rapidly scaling environments.

Discover how to deliver better software and systems in rapidly scaling environments.

  • By submitting this form you agree to receive our newsletter and occasional emails related to the CTO. You can unsubscribe at anytime. For more details, review our Privacy Policy. We're protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
  • This field is for validation purposes and should be left unchanged.

My Top Code Review Tips:

  • Encourage people to self-review first: self-reviewing is a practice where the person proposing the code change also reviews their own code and leaves helpful comments before asking for public review. It reduces time wasted by future reviewers and may even help the self-reviewer find small silly mistakes ahead of time; 
  • Code review in pairs or mob sessions: especially useful in cases where the PR touches sensitive code or is quite a large change (such as a refactor). The proposer of a change can get on a video conferencing call, share their screen, and explain their PR to the team or colleague. This really helps in getting everyone on the same page quickly, and can really help with improving code quality. 
  • Get developers involved in reviewing automation code: It’s important that developers participate in the automation/testing code review. This keeps their understanding of how the application is being tested up to date and helps enforce the same kind of code quality across all code; 
  • Make sure SDETs/Testers are reviewing application code: this is a really crucial one. Quality engineers should be participating in code reviews. You can even do this if you are not very technical (it is a great start to find out what you have to learn!). Not only can you provide valuable feedback, but you will also be gaining knowledge about what exactly is changing in the application (which you may be missing due to the new asynchronous setting). This knowledge will help you make better testing decisions for the team.

If you don’t have a strict code review process already, this is a great time to make the case for improving it. It’s a fundamental tool in a time where synchronous communication may be more difficult. 

Don't be afraid to leverage code review tools to help you organize and collaborate.

3. Leverage The Power of Pair Programming

I won’t get into the details of Pair Programming or Mob Programming, as that would be a whole other article, and there’s plenty of information about it online.

However, I wanted to point out that this is a very valuable tool in a time like this. Whether it is you working with another SDET on testing code, or you pairing with a developer to work on application code, I think it’s a great practice that will help with team bonding, knowledge sharing, and increasing code and application quality. 

Here are some commonly asked questions about Pair Programming, along with answers:

What is Pair Programming?

As the name indicates, Pair Programming is an activity whereby two people contribute together on the same code. It can also be done with more people, and it is typically called Mob Programming. 

How does Pair Programming work?

Usually, in Pair Programming, you have a driver (writes the code) and a navigator (or observer). This works well with remote conferencing tools in which one person can be sharing their screen and writing the code, and the other can be making suggestions, comments or reminders, or helping spot/prevent bugs.

What tools do you use for Pair Programming?

If you’re feeling collaborative, VS Code (for example) has developed excellent collaboration capabilities with (Visual Studio Live Share), which allows multiple people to be working on a shared project. It works a lot better than you’d think—it’s very powerful, and it works really well with people who are already familiar with each other or have similar styles.

Can you do Pair Programming with non-technical folks?

Yes, and it’s a great opportunity to develop mentorship skills as well as technical knowledge among your team. 

Do you have developers who are particularly interested in teaching, or perhaps have experience in giving workshops or tutorials? They may pair with you to guide you through the code base, allowing you to gain more experience if you don’t have a lot of technical knowledge yet.

What about testing?

To test, try something I'll call "Reverse Pair Programming". This encourages the reverse of pair programming, becoming instead about Pair/Mob Testing. Pair with developers to show them how you test the application, or for them to help you test it, or vice versa! This is a really useful way to tackle complex problems. Read some ideas about it in another excellent article by Maaret Pyhäjärvi.

4. Run Remote Testing Sessions to Collaborate as a Team: Bug Bashes, Game Days, etc. 

Testing Sessions (sometimes called Bug Bashes, Game Days, etc) are a collaborative activity, typically run by a team. 

It can be to test a specific new feature, or it can run on a regular cadence to test the application. The right QE tools can be game changers during these collaborative sessions, offering real-time insights and simplifying complex testing environments.

The idea is to bring people from the team and outside the team together, from many disciplines (development, testing, product, design, business stakeholders, etc) to test the application. Sometimes as developers or testers, we may have a biased technically-focused idea of what the application should look like, so having other stakeholders look at it can provide very valuable feedback.

Bug Bash Roles Screenshot
Testing sessions are a great chance for teams to come together and collaborate across departments, even in remote setups.

I thought this was important to call out because I feel this is a great activity to have during these times. It brings teams together and encourages communication and collaboration between different departments, potentially unearthing bugs or incorrect specifications that might otherwise be missed.  

Now, of course, running these remotely can be a challenge, so here are a few tips for that (and for running these in general).

Tips for Running Remote Testing Sessions:

  • You should be able to run these over a video conferencing tool. Make sure you have a chat available for it, too (if using Slack, maybe make a separate Slack channel for it); 
  • For situations in which devices are needed (e.g., mobile phones or living room devices, etc), make sure you know what people have ahead of time. If you are testing an iOS app, and you invite someone without an iPhone, that’s a waste of everyone’s time; 
  • Always have one or more people responsible for each of these sessions. This means they should help organize it before, prepare any documentation or setup necessary for the attendees, and facilitate the session; 
  • You should create clear install instructions for participants and have them available before the session. You want to spend the time of the session on testing, not installing; 
  • You should also have clear instructions on how to report problems, even if it’s just “post it in the channel” (instead of everyone trying to report problems on a conference call at the same time); 
  • Have a plan for the session. In situations like this, it’s useful for people to follow some sort of script or at least a plan of what to look at it;
  • That being said, still encourage exploratory testing, but bear in mind that some people might need a bit of a push to start exploring. 
  • You can still run these on more backend focused systems. An interesting exercise there might be to turn it into a Chaos Engineering experiment, with a more tech-oriented crowd. AWS has a version of these called Game Days, from which you can get some ideas.
  • Encourage fun! These can be very entertaining if done right – I used to gamify Testing Sessions with Game of Thrones characters when I was doing them at Miniclip many years ago. 

You can also find some more detailed information about it in this blog post, which covers several of the things I mentioned above.

5. Manage Your Free Time Wisely—Bolster Your Quality Engineering Skills

As I’ve mentioned, you’re going to have to get accustomed to asynchronous communication. In the world of testing (depending on your team dynamics), a tester’s tasks can often be dependent on development work being completed. With teams moving at slower velocities, and communication moving differently, you might find yourself with some free time in your hand. 

I remember I had a colleague in a previous company that would often say in the standup “I’m Blocked by x”, and then proceed to spend the day waiting to be unblocked. At one point, I was helping him improve his skills in various areas, and one of the things that needed to be worked on was precisely that mindset. This is especially true now when in addition to potential increases in dead periods, you’re also finding yourself in the comfort of your home, with a lot of distractions at hand. 

It’s important you manage your time and keep a backlog of things you are interested in learning. 

Here are a few examples of things you can do in your spare time: 

  • Have you been more of a Manual QA? Maybe you want to invest time in learning about Automation.  
  • Do you have a lot of Frontend knowledge? Maybe you should spend some time trying to gain some backend as well.
  • There’s a lot of free great resources like freeCodeCamp or Youtube, or cheap ones like Udemy (they often run deals). Additionally, there are a lot of conferences that have turned remote due to Coronavirus, and some are free to attend (e.g. OnlineTestConf)!
  • Or maybe you want to learn more about the application, diving through application code. 
  • Or perhaps you know some new project is coming, and you’ll have to pick up a new skill for it. 
  • Additionally, you can also use this time prototyping new ideas, cleaning up tech debt, documentation, etc.  

It doesn’t really matter. Pick and choose, but invest in your personal development. 

It doesn’t mean you can’t give yourself a break (it is a global pandemic, after all). People will understand. But increasing your QA skillset or improving yourself is valuable, especially in times like this, where the job economy has taken a huge dive. 

6. Use Team Activities to Help You Develop Relationships 

As a final note, even though this isn’t so much a testing-related suggestion, I wanted to say that I find it important to encourage activities in your team. Those relationships are important and serve as a welcome distraction from work. You usually get them more organically in an office environment, perhaps during lunch, or a coffee break, or even just a random comment in the same room. 

Some tips to build relationships in a remote setting: 

  • In my current team, we’ve just set up the Donut Slack app on our team channel. This will randomly pair us with a team member every week for a chat—we can talk about anything we want there.
  • We also have a Friday book club, where we take turns to share knowledge with each other (we focus on topics that have work relevance but could be anything!); 
  • Set up team lunches or coffee breaks in the channel, where you share some time together as you would in an office. This works best if you are all in similar time zones, of course; 
  • Run quizzes or play online games together, every once in a while. The Jackbox Party Pack is a great example of something that works really well in remote settings.

Join for More Insights

For more quality assurance tips, advice, and strategies, subscribe to The CTO Club's newsletter for the latest insights. We'll help you scale smarter and lead stronger with guides, resources, and strategies from top experts!