TeleTesting - 10 Tips for DevOps and Software Testing while Teleworking

March 19th, 2020 by Adam Sandman

devops

During the last couple of weeks, the world has been turned upside down with the onslaught of the COVID-19 Coronavirus. As part of our response plan, we have moved Inflectra to 100% telework to reduce the chance of community transmission. A lot of newspapers and blogs have great tips about how to work remotely and stay sane and be effective. However, we have found there are some specific tips that make things easier for software development teams working remotely - TeleTesting if you wish!

What Did We Find?

We have always had teleworking at Inflectra, with most employees working most days in our office, but flexible telework available as needed to make it easier on employees' commutes and personal lives. In addition, we've always had remote employees that work for most part from home, and come to our office a couple of times a year to stay connected. However, even this didn't fully prepare us for the challenges of moving to 100% telework for all team members at the same time. So, we're going to share some of the tips that found useful in the transition to full on TeleTesting (and TeleDevelopment, but it sounds less catchy!)

  1. Virtual Standup Meetings
  2. Online Meetings
  3. Assigning Tasks and Work
  4. Using Automation
  5. Boosting Morale
  6. Avoiding Roadblocks
  7. Capturing What Happened
  8. Consensus on Requirements
  9. Real-Time Status
  10. Tools and Tech

1. Virtual Standup Meetings

Normally with agile teams it is ideal to have a daily standup meeting where everyone discusses what they are working on, identifies any roadblocks, and raise any team-wide issues that should be addressed. With the move to complete teleworking, we have used our normal team chat application (for us a combination of Google Chat and/or Spira instant messenger, but you can use Slack, Microsoft Teams, etc.) to write a new thread with a daily standup message each day:

This was so successful that our sales and marketing team have followed suit with their own version! Its a good, quick medium that works with the immediacy of a standup and avoids long drawn out meetings that are the reason you "stand up". We have also been experimenting with a virtual 15 minute Google hangout call. When we had the team partly colocated and partly teleworking this wasn't necessary, but with people feeling socially isolated due to the wider quarantine conditions, hearing/seeing each other has been helpful. One team member also showed us his cats playing which was a nice morale boost!

Regardless of how you do the meetings, make sure you are tracking any dependencies and people feel free to use the chat threads to reply to someone's standup message with suggestions or offers to resolve a roadblock or dependency...

2. Online Meetings

We have a weekly product meeting which is longer than our standup meetings. We discuss how the current sprints are going, are we on track to deliver the next release on schedule, and are there any impediments or issues that we need to discuss. During this meeting we review the planning board for the current release and current sprints.

Traditionally we'd do this in our conference room using our projector and take notes live in Google docs and/or use the whiteboards for any discussion topics.

With the switch to teleworking we've been using Google hangouts with web-cams. We first tried it without webcams but since we're used to being in the same physical space most days, it has been helpful to see people on the camera. It also forces people to fully engage in the meeting and not be multi-tasking doing other things. So we'd recommend using video and audio if practically possible.

The online tools for release and sprint planning we use (SpiraPlan in our case) work just as well in-person as remote, so as long as you're not relying on physical boards, should be minimal adjustment. If your team is using physical Scrum or Kanban boards, now is a good time to move to an online planning tool.

Another option if your developers are used to looking at each other's screens to get past roadblocks is to consider the much ignored practice of eXtreme Programming (XP) - namely pair programming. You can use screen sharing or code-sharing tools (VS Code has this built-in) to make this happen.

3. Assigning Tasks and Work

One of the challenges with tasks and work assignment is that there are too many ways to assign work to people. Should we type up tasks inside a Google document, send emails to someone to act like 'virtual tasks', or simply post them to people in Chat. What we have found is that in this case, be very disciplined around task tracking and assignment.

We recommend that you choose a very, very small number of apps that are your source of truth - so everyone knows where to go to see what they and others need to do. For example we are using SpiraPlan as our sole source of truth of product development and testing tasks. We use:

  • Tasks for development activities
  • Incidents for any bugs to be fixed
  • Test Sets for any assigned tests to be run

With requirements and releases/sprints being used to roll-up the information to see what needs to be done across multiple tasks and test cases.

We have a rule that anything that is in Google Chat or email is not by itself a task, to avoid confusion about priorities. If you want me to remember to do it after the next 5 minutes, don't put it in Chat or Spira instant messenger. Chat is only for immediate questions/responses, not task assignment.

For other, non-development teams, there should be an equivalent source of truth (CRM activities log for sales, KronoDesk support tickets for support, etc.)

4. Using Automation

With people working remotely, the overall environment will be less efficient, and/or collaborative. So it necessarily means that certain tasks may be less efficient and other task may be more efficient. When working from home, developers will have more time to code without being interrupted in meetings, but will have less time to clarify requirements, ask questions or hear what other team members are doing on the code that might help them (see tip 8 about requirements clarity).

So now is a good time to shift to tasks that previously you didn't have time for. Instead of doing some complex scenario tests that require you to talk to three other people, maybe it's time to get some robust non-flaky regression tests in place. Use automation tools to improve both your automated testing and/or tasks in your DevOps pipeline. That tricky deployment process that has 5 manual steps that you have had on your personal to-do list for months? Maybe now is the time to write the code to automate it.

Perhaps there are other things that you can automate (support chat bots, performance monitoring) that previously the team did manually but are not so ideal for distributed teams. Computers can work day and night and don't worry about spreading viruses (or at least not that kind!!) so automation is a good approach for any tasks that it's feasible for.

5. Boosting Morale

It's easy to forget the people and focus on the product, but the move to 100% telework, especially when there is a wider national disaster (like the current Coronavirus) can actually make things worse - people have more time to read the news, check social media (twitter) and generally get stressed out. The good thing is that having work to do keeps people's mind off the wider picture, but balancing family/home/work time can be stressful.

For those who are not used to remote working, it sounds idyllic until your dog/kid/partner starts driving you up the wall. And remember we are not at home because we want to be. We should do what we can to make this easier for each other, and look out for each other. Sending care packages can be a good idea, as long as they don't get in the way of essential supplies being delivered (at the time of writing this article, Amazon is rumoured to have started delaying non essential shipments). Leaders in the company need to let people know that the company is OK with productivity taking a dip overall.

Also there will be a tendency for people to use the company's channels (instant messengers, virtual meetings) to discuss things in the news and compensate for their relative isolation. Leaders should tolerate and encourage this. Expect that most company meetings will start with 10 minutes of banter unrelated to work, that's OK.

6. Avoiding Roadblocks

One of the biggest challenges when developing or testing software is what to do when you hit a roadblock and cannot seem to get past it. When we are all located together, one of my strategies of "hands-on management" (a term pioneered by Bill Marriott Jr.) is to walk around and ask how people are doing. Often I will find that a person has been stuck on something for a while. Often a fresh pair of eyes will assist and one of us can see the solution. Alternatively I will tell that person to work on something else and come back to it. Usually the next day when they come back, they see the answer right away. That kind of intervention is harder when everyone is remote.

Another related issue can be when that same person is dependent on something from another person and they are not both working the same hours remotely. This can happen if one person has to deal with family situations and is working earlier/later hours than they would have worked in the office.

There is no magic solution to this, but at least tracking task dependencies or all the tasks related to a requirement / user story more formally can be helpful. That way if a user story has Tasks A,B,C and B is dependent on A, you can track those dependencies and adjust for it. Another idea is to give team members multiple tasks A,B,C so that if they hit a roadblock with A, they can always work on B and C, then tackle A in the morning when fresh. However you have to be careful, some people have a tendency to panic when they have three tasks and not be able to focus on any of them because they are not sure which one is more important. This is similar to Fear of Missing Out (FOMO) but in this case is Fear of More Important Tasks (FOMIT).

7. Capturing What Happened

As you are developing and testing, team members need to make sure they are capturing everything more religiously than they might do if working in the office. For a tester, they could normally just show someone else (e.g. a developer) what happened on their screen, but when you are Teletesting, that is harder to. Use screen capture tools (like a free google extension - SpiraCapture) to capture what you are doing and then save the results into a tool like SpiraTest so that you have a record of what you just did.

Similarly, make sure you document any changes or questions about requirements as a comment in the requirement. If you are not sure what the requirement means, add a question as the comment. If you are worried you will forget to clarify, just add a task to the requirement so that it is not forgotten. Teams should err on the side of adding tasks as well as comments to make sure things are not lost. Also as mentioned in item 3. if you need to get clarity on something, it's fine to use IM tools, but make sure the results from that discussion make it into the tool being used for the source of truth.

Another key agile tenet is to have retrospectives. We used to do these in our conference room. We simply switched over to a Google hangout meeting with live capture in the Releases section of Spira:

We added some custom fields to capture three types of retrospective item:

  • Start Doing
  • Keep Doing
  • Stop Doing

8. Consensus on Requirements

Even in normal circumstances, it is widely agreed in the software industry that one of the keys to delivering high quality products is to get the requirements "right". However there is far less consensus on what "right" actually means, and even less consensus on what is the best way to get there. However with the rapid and sudden shift to complete teleworking that has happened over the past couple of weeks, having teams suddenly remote for the first time makes this harder than ever.

The key here is to make sure that you have more discipline about requirements. Since there won't be ad-hoc conversations around them happening around the "water cooler" you may need to have some "forced activities" to make the conversations happen. For example, you may want to use a view like the SpiraPlan 'document' view so that you can have a screen share session and read through everything as a team.

Also you might want to have a policy of every requirement is written by one person and is reviewed, edited and clarified by at least one other person before it's ready to be put into the release or sprint backlog. That way some of the steps that would previously have been ad-hoc and information are a bit more standardized. That way a project manager can see everything in the system and know that it's been reviewed.

9. Real-Time Status

Encourage people to be clear when they are online and available, but also that it is OK to go offline. Development and testing require deep concentration and focus - chat apps and Skype calls can break concentration, so make sure people know they can and should turn off work and communications. Each person should have a daily schedule for themselves that consists of:

  • Time for communication with team - chat apps enabled
  • Time for heads-down work - chat apps disabled
  • Time for family/self - chat apps disabled

Also for managers, encourage your team to keep the source of truth updated. For us that means that developers commit code and push regularly, keep their SpiraPlan tasks and incidents up to date, and testers are logging results into SpiraPlan in real-time. If that is happening, then you as a manager will have real-time status:

You won't need to bug everyone all the time on Chat, which will make everyone happier. So make sure you have good, real-time tools in place and ensure that the team understands that the better they are in keeping them up to date, the less bugging / nagging they will receive during the day. Win/Win for everyone!

10. Tools and Tech

Without being an exhaustive list, here are some of the tools we have been using to manage the move to telework, some of these are our own tools, some are companies. I have listed them by category so that you can use other tools in the same category as well:

Further Reading

Spira Helps You Deliver Quality Software, Faster and with Lower Risk.

Get Started with Spira for Free

And if you have any questions, please email or call us at +1 (202) 558-6885

Free Trial