My diary as a QA Engineer working with a distributed team

The software development arm of Zola Electric is a distributed team with its members working from about six (6) different countries and three continents. This, of course, comes with its usual peculiarities which include but not limited to:

• Mismatch in time zones
• Cultural differences 
• Many online pairing sessions and meetings 
• Frequent use of collaboration tools such as Slack, Trello, Jira, Confluence, etc

Working with a distributed team brings a lot of benefits such as flexibility, saved commuting time and increased productivity. My typical day starts with me checking emails and Slack for notifications and replying them if need be. I then go ahead to check Project boards for tasks awaiting QA. With this information, I can then plan my day. I then attend my daily standup meeting.

Daily standups with my team involve two processes: using a Slack Bot called Geekbot and then doing a 10-15 minutes zoom call. Every weekday, at a particular time, Geekbot sends a message to every member of a team to provide a short summary of tasks done the previous day, tasks to be done that day and blockers/impediments if there is. Everyone’s responses are then posted to the team’s “#daily-standup” channel on Slack. Later that morning, during the zoom call, everyone gives a little bit more clarity about the standup report shared with the bot. The major aim of this zoom call is to grant team members the opportunity crave the attention of another member that may be able to assist with an impediment he or she is facing.

After daily standup, I then dive into the deliverables for the day.

My Expectations  vs. Reality

My initial expectation was a bit different from what currently happens. For starters, I assumed there was going to be a language barrier obviously because of the cultural diversity. So far, communicating with the other teammates hasn’t been difficult. Everyone has at least a good grasp of the English language sufficient to pass across information to one another.

Another expectation I had was that there was going to be a lot of emails and very long email threads with many back and forths. This also wasn’t the reality as Slack and Zoom are being used to ensure prompt responses and feedback from other teammates. 

I also expected that it would take a very long time to resolve technical issues due to time zones mismatch. To my surprise, the team members responsible for this have been relentless and creative in implementing measures that ensure minimal delay in production environment issues. An example of such measures is aggregating alerts from error tracking/monitoring software to a Slack channel so that stakeholders can respond promptly.

Finally, one of my biggest fears was that I was going to miss having a relationship or bond with other teammates working from other locations. The use of collaboration tools, frequent workgroup meetings and Slack channels for individual departments do help in a way. But from experience, organizing regular global all-hands meetings and departmental conferences/ meetups help foster team spirit, better vision alignment and help synergize the team.

Unique experiences peculiar to working as a QA with a distributed team

• Being more intentional and detailed with my documentations: Working remotely or with a distributed team is quite different and unique in this regard. If I was working with a colocated team, I would just walk over to demonstrate a problem in real-time. This, of course, is not always practical, especially when dealing with colleagues across different time zones. Personally, I invest a lot of energy in providing very detailed bug reports for example. I  especially like to share logs, videos, and screenshots when discussing or explaining a situation with colleagues. 

Take for example:

Vs

• Prepare for Meetings ahead of time: Before a meeting commences, I like to be prepared and not be caught off guard. So I ask myself these questions:
  – What was discussed in the previous meeting?
  – Was I assigned any task? If yes, confirm I have it done.
  – What are my contributions to this meeting if asked?
  Then I make a mental note of this and prepare accordingly.

• Being very accountable: Because trust and communication are two virtues that distributed teams thrive on, I take being accountable very seriously. This I do by attending standups regularly, shouting out when I am blocked on a task, giving the team a heads up when I will be unavailable or unable to complete a task in record time.

• Not being modest: Obviously, my other teammates cannot see me working at my desk. Therefore, it is only right to portray and accurately report the quantity of work done and the amount of time and effort exerted in completing my tasks. This I try to achieve by ensuring tickets are created for tasks I do and taking time to explain myself during standups and workgroup meetings. For example:

“ Yesterday I worked on tasks ABC-123 and ABC-456 yesterday, I also had a couple of meetings. Today, I will work on CED-123, ABC-433 and CED-221 ”

Vs

“ Yesterday, I had two meetings with the ‘xyz’ team to consider the different options for ‘abc’ integration required for the new feature ABC-111. After then, I picked up ABC-123 which I completed after having a long pairing session with the Back-end Developer. I then worked on ABC-456 , a fix for the production error that prevents users from getting ‘xya’ done .Today, I’ll be working on CED-123, ABC-433 and CED-221 against the Demo on Friday.”

Overall, it has been an insightful and enjoyable experience so far.