品質保證
回到LAB主頁
The Power of In-Time Zone Solutions for Quality Assurance
It’s no secret that time is one of the biggest factors in any working pipeline, but it’s especially true for quality assurance in game and software development. All projects have a deadline, so project managers develop meticulous plans that include multiple milestones that must be achieved. To ensure that all stakeholders adhere to this schedule, time must be managed accordingly to meet all deadlines for successful project submissions, whether these be DLCs or full game titles.
This becomes more difficult when the client—who must be kept appraised of progress at each stage of the project—is in a different time zone from the one in which the work is being done. Without oversimplifying the matter, this is one of the prime drivers for PTW to build locations across the globe. Let’s dig deeper into the challenges and benefits of in-time zone delivery of quality assurance.
As stated above, communication with the client is key when working to achieve project milestones. Obviously, when the client is in a time zone where their typical working hours are significantly outside of where the work is being done, timely communication can be challenging. But the problem can be deeper than merely updating a stakeholder.
For proper and robust QA to be achieved, the team requires up-to-date working builds and the necessary tools for testing. “Sometimes QA teams require specific documentation from the client to guide their testing,” says Deanne Curtis, Quality Assurance Manager for PTW Montreal. “When this is unavailable, the team might have questions that impede progress if the answers aren’t immediately apparent.”
When working on a project, client collaboration can solve problems and provide innovations when teams work together. However, this becomes much more difficult when teams are separated by the inconvenience of opposing time zones. Special meetings must then be scheduled to navigate the resultant roadblocks, which themselves add to the time and cost of the project. Team bonding can be a valuable tool in the execution of a project, but this requires in-person meetings and interactions, which can be extremely challenging or even impossible if the actual working hours don’t match up.
Having both parties involved in the same time zone simply makes communication easier, allowing for overlap in work hours to cover the change in shifts when necessary. Assistance from both sides when needed is readily available and quickly accomplished. Testing teams receive proper documentation and training quickly and responsively, with the ability to join meetings to avoid miscommunication. If a client needs change, testing alterations are made swiftly, reducing the number of related defects and boosting productivity. Because roadblocks inevitably occur, in-time zone teams always remain up-to-speed. Clients, vendors, dev teams, and QA teams harmonize their efforts and achieve optimal efficiency.
Let’s look at some examples of projects involving teams from different time zones to see how these factors played out.
In this first project, client expectations were clearly shared and training in the client’s tools was provided by an internal team. The dev team was embedded but used no leads—they followed an Agile methodology, requested by the client which was seen as the best solution. The client gave feedback once a week.
Despite being in a different time zone, the working team chose to communicate during the client’s core hours. Tasks were set up using Kanban boards, epics, etc. This project was successful, and now the client has a PTW PM/Lead who runs several projects for the internal teams client-side. PTW teams have taken over LiveOps, Player Support, automation, and day-to-day project metrics. The total size of the team is 25 from the original 5 team member size; 5 current projects are run by the team for the client and going strong.
The client wanted 24-hour service, with two teams: one in Montreal and one in India. The two teams did not work together as they were on completely different shifts. There were delays in communication on the client side as the India and Montreal teams had to wait for the internal team to come online for feedback and tasks. This caused miscommunications, delays in testing due to blockers, unclear tasks, and teams going underutilized.
PTW suggested splitting the India team to work in two shifts to overlap both the first shift and the Montreal shift. The teams would commit to daily scrums with the internal and PTW teams. The PTW teams provided handovers to each other and to the client. This allowed the client to answer any questions and update tasks.
The client gave feedback weekly and teams both internally and PTW-side felt empowered and united. The Montreal team split the teams’ shift starts and ends between the team. This was such a success that the teams have continued this process.
The India and Montreal teams splitting both of their shifts meant clear communications between the teams, ensuring a faster and more efficient testing process. This enabled the development teams to quickly fix and address any blockers or critical issues for submissions, which reduced the number of builds overall. Teams constantly communicated and tasks/tests were shared and confirmed, so duplicate testing was no longer an issue.
The QA Manager spoke with the client to discuss their needs before the project began. The QA Manager then discussed the needs with the assigned team leads to generate possible solutions. The client and team leads agreed on one team starting the shift at the same time as the client and another team starting two hours later, which matched one section of the development team.
The teams started the project with clear expectations and strong communication from both internal and external stakeholders. Communication and task assignation from the development team produced faster testing results and reduction of duplicate issues. Errors from builds were reduced and faster submission target dates were made.
Though it may seem that there are only drawbacks to working across different time zones, it can be beneficial for certain clients. “Some live games—where players are constantly accessing game servers—require a 24-hour service, especially those that have tight timelines/or build submissions,” relates Adrian Danalache, QA Manager at PTW Bucharest. “Having support teams in place across the involved regions is the best way to handle this situation. It requires that the teams perform regular handovers and communicate clearly between each other. Ideally, the teams overlap for at least 1-2 hours to ensure that they can communicate and flag any critical issues or ask for any verifications.”
This kind of 24-hour coverage can also be beneficial for faster test cycles, reduction of regression times, and production of new builds and hot fixes. In general, however, multiple time-zones present more obstacles than benefits, unless there are solutions set at the start of the project. PTW’s continuing rollout of global studios ameliorates time zone-related issues by providing extensive client support in all the regions players can be found.