Testing from home

One of the things we allow on the OneNote test team is working from home now and then.  We have tried hard to keep the process lightweight and leave the decision up to you for whether or not you can meet all your goals and work at home on any given day.  If you know you have no mandatory meetings and otherwise are not physically required in your office, you can make the decision about where you will work for the day.  As I write this, it is snowing pretty hard in Redmond, and many schools, roads and other places are trying to figure out if they will be open today.  Three people have already sent mail saying they will be unable to make it in, and I expect more as the morning progresses.

FWIW, we have no fixed hours to be at work.  We have the concept of "meetings are typically scheduled between 10 AM and 4 PM" but that's about it.  I typically get in by 7 AM.  Most people get in between 9 and 10, with a few coming in about 11 or so.  It helps stagger people through traffic if nothing else, and results in testers being here pretty much all day.  Some stages of product development may require set hours, but that is not the norm.  As an example of fixed hours, I had to work nights one week to perform Outlook on Terminal Server testing since that was the only time of day I could get lab time to run the scalability tests.  It was actually a fun time and nice break - there aren't many distractions at 3 AM, but there are a surprising number of people around...

We also consider ourselves fortunate that testers are able to work remotely and still accomplish their goals.  An obvious task which can be completed at home is creating test documentation: testing design specs are based on PM and developer documentation.  Since this documentation is shared via internal Sharepoint servers and shared OneNote notebooks, once you get logged into the domain remotely, it's pretty easy to complete this type of work.

Since we are also fortunate in that we all get issued tablets to use for testing, we can carry these home and use for remote work as well.  Since we get issued tablets, we can carry them with us, test at home, public wi-fi spots, can update the software with the high bandwidth connection when at work and so on.

From the management point of view, we are fortunate again.  Testers get work done and no one has fallen behind from working at home.  Everyone has treated it as "being at work with my door shut to minimize distractions."  So far, we've gotten good, quantifiable results. 

Other tasks we have to do are not good fits for working remotely.  Without a broadband connection automation scripts are very difficult to create at home.  Plus, writing code on a tablet PC screen is difficult.  There simply is not enough screen real estate.  Setup testing, due to those bandwidth concerns, takes far too much time to test remotely (except, of course, when the purpose of the test is remote setup testing).  Even trying to verify bugs have actually been fixed in new builds requires setup to run, so that is difficult.  And any testing which needs to be completed across multiple hardware platforms is usually not possible from home.

Like everything else, working remotely now and then has an upside and downside.  I think we do a good job of balancing the two, letting testers choose when it is appropriate or not, and holding ourselves accountable for the results.

No updates next week.  I'm OOF, and attentive readers know what that usually means...

Questions, comments, concerns and criticisms always welcome,

John