QA on remote control

A few years ago I had the great pleasure and challenge to be remotely employed as a QA engineer in a startup company, and it has its fair share of challenges.

Try to imagine:

• The center of activity is miles away, you are short of information, mostly you don't get updated online when a change in requirements is made.
• You can't give your input in design reviews and at times you will be updated last on a change that in your opinion doesn't make any sense. In fact, you will probably have no say in most of the design issues. As a QA Engineer, I can tell you that pressing the "Off button" on your criticism is not as simple as changing a channel. 
• You are updated last about changes in deadline and priority. 
• At times you can spend an hour testing a module, while the developers are working on changing it.
• Sometimes you receive a short message to deliver X result in Y time, change your testing priorities or switch to testing another module ASAP, without even knowing what stood behind that decision. 
• You are not a physical part of the team, and as the "Outsider" you will have a harder time to make your opinion count. 

With that said, there are some key guidelines you should follow to be productive and live to tell about it: 

• Get to know the people you work with - Every person has his own character and temper. that includes QA Managers, Product owners, and developers and when you have to work with them - you should learn how to address each and every one to achieve cooperation. 
• Get to know the product and company - What is the product? Who are my end users? What is important to them? What are the products weak spots? All of which will help you build a wide and objective test plan. That connects directly to what I mentioned in the previous clause, insist on a brief about the company and product, call the product manager and hear his POV on whats important, make a testing plan that suits their needs and expectations.
• Set clear goals and deadlines - Before you dive in, establish for yourself: What are your short and long-term assignments? What are their priorities? What does your manager expect from you to deliver? (and is that a realistic expectation?). 
• Establish early on, how will you receive your assignments? - There is a big difference between a phone call and a written ticket in Jira. Try to understand how will you be updated on your tasks and what work procedures should you follow to be a part of the cycle. 
• What resources will be available to you? - In what platform will you receive your tasks? Will you have access to all the documentation you need? What tools will you be working with? Where and how will you report bugs? Do you have permission to access all of the necessary testing environments? (platforms, tunnels, CI deployment, branch environment, DB? API).
• Information - The same way a handyman needs his toolbox, our most important tool is information. You can't test without knowing what you are testing, how it's supposed to work, and what it suppose to look like. Try to get as much information as possible, read all of the documentation you can access. If you are testing a change request and you have an access to the loops and issues that relate to this module - read them! It can help you understand what evolution the feature made and what to notice in your tests.
• Be as clear as possible - I cannot emphasize enough the importance of a clear and detailed bug report. This becomes even more critical when you are not physically present in the office to explain yourself or help reproduce your bug. Give as many details as possible, use screenshots or recordings, supply the team with short and clear steps to reproduce.
• Communication and fluent update - Managing a remote employee is not easy. Fluently update your manager on your status, make sure you understand each other, what is your test plan? (keep in mind that your manager does not know what you are planning to test and what coverage is expected to be delivered within the time-frame), how are you doing compared to schedule? what is the status of the bugs you opened? are there any critical issues? what are you working on today? (you can also suggest taking part in daily meetings). Furthermore, try to be fluently available during work hours.
• Know your limitations and learn to live with them - It is logical to assume that the organization that hires you remotely for a short-term project, is aware of the limitations in a remote-controlled QA engineer. Understand your goals and focus on achieving them. Don't be hard on yourself, you are doing the best you can.