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. 








Comments

Post a Comment

Popular posts from this blog

Sharing is caring - Intro to Jenkins shared libraries

-
Image
  Whether you're just dipping your toes into the world of automation infrastructure, or already crafting your first jobs to automate your test execution, Jenkins is your new best friend.  In this blog post, we will talk a bit more about the practice of infrastructure as code, its relevance to test automation, and how you can avoid code duplications, align with industry best practices, and enable velocity, maintainability, and collaboration. So, whether you're a seasoned pro or just starting out, let's dive into the world of Jenkins Shared Libraries and see how they can make your life easier. Jenkins Shared Libraries play a crucial role in the realm of Infrastructure as Code (IaC).  So, what are they exactly? Think of Jenkins Shared Libraries as your secret stash of code snippets, neatly organized and ready to be plugged into your pipelines whenever needed. Let's explore the aspect of reusability within Jenkins Shared Libraries: Reusability is the cornerstone of efficien
Read more

Intro to Terraform and how it is related to test automation infrastructure

-
Image
In this post, we will take a closer look at one of the most popular infrastructure-as-code software tools developed by HashiCorp, and if you follow my recent content, that name should start ringing a few bells. So, what is Terraform and why do we need it? Terraform allows you to define and describe your infrastructure in the form of code. To be more specific “HashiCorp declarative configuration language” (or HCL in short). With Terraform you can manage your resources and infrastructure modules like servers, VPCs, security groups, and much more, even if they are located on different providers such as AWS or Azure.  Generally speaking, cloud providers have their own infrastructure-as-code tools like CloudFormation or ARM. But, Terraform has very extensive support for different cloud providers and platforms allowing you to use a single tool for cross-cloud configurations. This makes it easier to manage your resources, easier to onboard and this is a scalable and in general, the “best prac
Read more

Chromedriver - Under The Hood

-
Image
Selenium Webdriver has been our companion in our test automation adventures for some time now. Over the years the Selenium open source project has obtained something I can fairly describe as global domination. With Selenium, we are able to interact with different browsers using the WebDrivers. But, how much do we really know about them and the way they work? In this article, we will take a closer look into "Chromedriver" and explore a little bit about how it works. So, what is the role of this Webdriver? Starting from the release of Selenium 2, we were introduced to the concept of Webdriver. The "Chromedriver" for example is a .exe file that is able to act as a server. His role is to allow us to "Interact" with the browsers. Eventually, the responsibility for developing and maintaining these drivers was transferred to the browser vendors. The idea is, that they know their browsers the best and the produces driver would be much more stable and
Read more