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.
The COVID-19 outbreak has been a game-changer for the entire world—for the first time in a very long time (perhaps ever), the whole world is focused on the same problem.
As governments enforced more and more social distancing and quarantine measures over the last few weeks, a lot of companies have had to reinvent themselves when it comes to ways of working.
As a result, as a Tester, SDET, QA Engineer, or any other role responsible for driving quality in your company, you may find that your day to day has been somewhat disrupted. You might be asking:
How Do You Undertake Effective Quality Engineering In A Remote Setup?
Before all this started, I happened to be already working fully remote at Auth0 (a fully globally distributed remote company), and I have worked remotely before in other companies as well.
This blog post is about trying to help you learn about some tips, tricks, and processes you can use in your company to try and manage remote work when it comes to Quality Assurance practices, coming from my experiences.
This will be specifically focused on remote work and its relationship with the quality. If you want general tips for remote work, I suggest you check this post by Auth0.
The biggest generic advice I can give you, however, is to be prepared for the concept of asynchronous communication—you’re often going to have to wait to interact, and you’ll need to learn to deal with that.
Quality Engineering Strategies and Tips For Remote Quality Assurance Engineers
1. Disclaimer: This Is Not Exactly Business As Usual
Right now, people will have 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 what is currently going on is not what normal looks like. We are currently going through the edge case (hopefully!), and as such, we need to be prepared to understand that it will require extra adaptation from us.
As a manager, show your direct reports that you understand that, and 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 their teams’ velocities will go down, and remote work is not at fault here. These are unique circumstances. Remote work is actually the thing that’s keeping your company still being able 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 (if not, go learn about them now in this great blog post). 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 it will be easy to enforce. If used correctly, they will help you with those asynchronous communication problems I mentioned earlier.
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 code review of automation/testing code. 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 SDET’s/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.
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 (aka 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 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.
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’s are a few examples of things you can do in your spare time:
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 theDonut 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.
What’s Your Best Remote Quality Engineering Tip?
This list of quality engineering tips for remote teams is by no means exhaustive. What has worked well for you and your team of remote quality engineering folks, software developers, or product teams?
Share your ideas in the comments, or connect with me on Twitter or Medium at @bernardobridge to share your thoughts.