Remote QA Team working in an Agile environment - possible?

-

 I’ve been thinking about this for a while as I see more and more the interest in offshore development work. Be it to South America, India, anywhere, it appears to be a preferred option for some companies and even a long-term strategy.

It’s now a relatively mature idea and is proving cost-effective for many a software house, but is only ever deemed viable for development (as far as I know! Please correct me if I’m wrong).

My question is, why not for QA? I understand the very real problems inherent with people working in different geographical locations and timezones, but whenever I’ve asked about a testing team based remotely, people have had an initial mental block to the idea.

Now, I have to point out that I mean a QA Team based in a different location to that of the Development one - this may raise a few eyebrows! And yet although I don’t have all the answers, I don’t see the idea as completely unrealistic - again, it’s simply a matter of introducing and maintaining strong communication links throughout the whole project team.

Or am I missing something vital?

“It works fine on my machine”

I recently had a discussion with someone who queried how would this idea work with the age-old scenario of a tester finding a problem and a developer stating “It works fine on my machine”?

This asks a lot questions about the environments used and shared in such a project. VM sessions are one solution, a configuration is built early in the project lifecyle with the new application and all required support infrastructure included. Updates are made as often as required and shared via VPN connections. With this setup, all team members can work under exactly the same version-controlled environment.

Either this or setup an environment on a machine local to the QA team which has a VPN connection to the developers/others in the project and, most importantly, to the codebase. From the repository a version of the codebase can be pushed as often as required. Rollbacks are possible and developers can go directly onto the machine and work in parallel with testers to locate problems.

To summarise, there are many options open today regarding remote environment setup, sharing, updating and versioning. I’ve seen two different methods used so far and both were successful.

How to Maximise Communications

Obviously the most crucial factor in remotely located project teams is to create and maintain strong communication links between all members. There are plenty of tools that can be used to achieve this (skype/P2P software, audio & video conference equipment, baseCamp-style shared whiteboards, etc), but it is their correct use that is the key to success. As with all tools, if they are not used then they’re useless!

The answer is to install processes on day one, which include :-

  1. Have a predefined structure of daily meetings and their times and transmit this to all,
  2. Select chat and voice (and if necessary video) tools which everyone has to use, and create accounts for all.
  3. Create a wiki location for all documentation to be placed. This page must be maintained regularly to reflect any change in location of personnel.
  4. Within this wiki site create a page detailing all communications channels (tools used, VPN connections, server IP addresses, logins etc), usernames and local times for the project team.

If these are not there from the project initiation there will be confusion. This will lead to some members adopting communication methods for their co-located team whilst others adopt their own. Although the solution is simple i.e. announce to all the ‘project standard’ approach, these early problems can creep up later as people decide to use what they already have installed, whose accounts they are already in touch with etc.

Time Overlap

And finally, I’ve read in various places about the benefits of ‘24 hour’ teams, where three teams in different timezones keep the work going around the clock. Whilst this can give a project more time in a shorter calendar schedule, if there is little overlap between the ’shifts’ then problems are sure to arise.

From the project initiation meetings, to passing on environment set-up information, to discussing task priorities, to even solving simple connection problems, the whole team needs to have an overlap of at least 3 hours per day to do so. If any less time is allocated the a whole lot of extra planning is required to have questions ready, ensure any other project member involved is available, rush through all the bullet points and then summarise and assign responsibility to prepare for the next day’s window of opportunity.

It’s easy to view the ‘global team’ as giving the company that little extra that will pip the competition to the fastest release date. If they don’t have time to interact for a reasonable amount each day though, it quickly becomes separate teams performing what they think the other team wants and spending the rest of the time planning. And there goes not only the 24 hour working day but even the 8 hour one!

Comments

Post a Comment

Popular posts from this blog

Agile v Waterfall - Which Is The More Risky?

-
  I still find it strange that companies unfamiliar with Agile automatically view it as being a methodology that pays no heed to process or ensuring quality of output. From my experience the quality is actually a lot better, the timescales set are achieved more readily and everyone involved has a much greater understanding of the product and its development status at any one time. At present I´m working on a project where I´ve had to split the test team into two due to several companies working to build a complex product together. One team is performing agile QA in a sprint team, the other is working ´the old way´. It´s very interesting to note that all the worry and uncertainty is coming from the team working with the traditional model due to the fact that timeframes having been guesstimated months ago about environments, data and functionality that no-one knew about then. As time marches on we appear to be spending more time in meetings discussing what we once thought was gospel,...
Read more

What are the Educational Requirements and How to train for the job of Quality Assurance?

-
  The position of a quality assurance job requires a certain set of educational qualifications which would help the professional to carry out the technical and administrative operations given to him as part of his job role in the organization. Following are the educational requirements to obtain a post in the quality assurance job field: Educational Requirements: The minimum educational requirement to enter into the field of quality assurance is a bachelor’s degree in the field of computer science any other related field. This study must include subjects of Java, C++, and Python etc. A further master’s degree in the field of business administration majoring in any of the related subjects would prove beneficial in acquiring a post in the quality assurance job. However, the educational requirements differ with industry. Like for example, a candidate who wants to work in the quality assurance department in the aviation industry would require a high school diploma combined with an aero...
Read more

To Assume is To Doubt - Eliminating Doubt to Ensure Quality

-
To Assume is To Doubt - Eliminating Doubt to Ensure Quality  Recently I was reflecting on the many different occasions on projects where I’d witnessed assumptions being made regarding test and project strategies as an acceptable practice. Situations such as the following :- 1) Maintaining test environments with unmonitored and, as a result, unknown and unrepeatable data, under the assumption that it is the functionality of the application that is important and the data it is fed is immaterial. 2) Testing end user sessions on a different platform, under the assumption that there will be very little difference in functionality (”Firefox on Ubuntu is the same as on Windows”) 3) Pointing new-starters to a wiki-page, under the assumption that anything else they need to know shall be relayed by ‘asking around’ 4) Arranging development teams such that each person only has deep understanding of one part of the system, under the assumption that all issues that arise will be easily solved by...
Read more