Managing a test team for one project is relatively simple. You spend some time getting to know the developers and their productivity and skill levels, then you hire tester specialists as needed. You have one main flow of work to production to keep track of.
Add another platform, web and mobile, and things get complicated. You now have several flows of work that most likely need to go together hand in hand, but you typically work as isolated teams. This is fertile ground for miscommunication, architectural problems and challenging testing strategy.
Regardless of how “mobile-first” a company is, I usually see web efforts being more cared for, and difficulties keeping the projects in sync.
Get TestRail FREE for 30 days!
API Tracking
Most projects I see today are based on some sort of API architecture. I have the most experience with REST APIs.
A few years ago I was working on a platform for marketing staff. We had some workflow tools, but the important part of our product helped marketers build and manage interactive advertising campaigns for social media. Most of the tools to build the advertisement were in a web front end, and the management tools were part of customer-specific mobile apps. The entire product was based on a large set of endpoints contained in a REST API.
Despite having one shared code base, mobile and web operated as two separate teams. Each team had its own tester, its own product manager and its own technical leadership. Our web team was usually the driver of change. They would have a feature request — for example, the ability to update the end date on an advertising campaign — and make that change, independent of what was happening in the rest of the organization.
When I was working on the mobile team, we had our own queue of change requests, some related to what was happening on the web product and some that were specific to our mobile product line. I would grab the latest version of our iOS product out of HockeyApp, install it on my device, and start testing, only to discover an error that didn’t make any sense.
Usually I would think these problems were related to implementation bugs and spend time investigating that. After awhile, a developer and I would open a developer tool and notice that a JSON response looked different than we had expected. The API had changed underneath us, and we didn’t know until we stumbled over the change while testing this feature. This resulted in a lot of wasted time and a lot of frustration and ill will between teams.
API versioning is one way to manage this difficulty. We opted to have a more static version of the API that was committed to at specific intervals and was backward-compatible for the mobile team, and another forward-driving API for the web team. We were able to test changes more efficiently without stumbling on unrelated problems with this method.
This, of course, creates new problems of managing two code bases, compatibility, release schedule and management, but it worked while I was on that project. A better solution might be to figure out a development cadence that works for both teams.
Unfortunately, technology management was only part of the issue on this project.
Information Sharing
The web and mobile teams were separate at that company. Each had its own queue in JIRA, and they held a standup at different times. Managing smaller projects like this is seductive: You only see the changes that are immediately relevant to you. You also regularly miss run-of-the-mill important project information.
One project I worked on had a web front team building a management tool and a separate mobile team that was supposed to consume the webpages created by the web team. The web team was moving slowly but surely through building the webpage management tool. Each new feature added had to be accounted for by the mobile team in terms of consuming and displaying data, as well as being able to edit those pages in a native mobile product.
The mobile team generally found out about new changes to the management tool because something would break when they were viewing a page. As you would expect, things quickly became hostile between the two teams.
There was an important date coming in the next couple of weeks for a sales demo on the mobile product, and testers on the web team learned about it by accident. The mobile test team had been operating under the assumption that everyone knew about this date and didn’t care. The web test team was blissfully ignorant, working as if breaking changes here and there was OK because there was plenty of time to get things fixed.
The teams simply were not talking with each other, despite working in the same building.
We solved this problem by blending the team standups. Each day, the mobile team would have a chance to hear about important changes on the web team and ask questions.
Join 34,000 subscribers and receive carefully researched and popular article on software testing and QA. Top resources on becoming a better tester, learning new tools and building a team.
Cross-Team Testing
Software projects are usually built on the idea that each project is a distinct thing, with its own workflows and reasonably self-contained. That is an illusion. Most products I work on will either consume data from an outside product, send data to an outside product, or somehow have a workflow that will start in one piece of software and end in another.
The medical products I have worked on required integration with several other products we made. A nurse might document patient vitals and drugs administered during a surgery on an iPad app. That data is automatically sent to a web front end via a tool like Redis. Once the patient information is displayed in the web dashboard, it might go through a few review workflows by a nurse manager, who reviews the case to make sure it was completely documented and either accepts it if everything is OK or rejects the case back to the original nurse if there is something wrong. After the case is eventually accepted, the data is packaged into a format that can be consumed by billing products.
A change in one product would always find a way to ripple through to the other products.
The company where I was working was very small, so although we had separate developers for our web and mobile products, the product people and test specialists worked on both. This facilitated a more complete understanding of the product. If a new vital was added to the mobile application, a tester could explore how that information was collected on the mobile application, see how the data was sent to and managed on the web front end, and then ultimately see if and how the new data was sent to insurance companies.
Companies I have worked at with distinct mobile and web testers have to coordinate work, figure out who has the domain knowledge, schedule time to work together and then fumble through test setup. My preference in this case is the test team being able to handle both web and mobile products.
Where to Start
Ultimately, my feeling is that having distinct mobile and web teams is a bad idea when the two teams are built on the same dependency tree. If you are having problems across mobile teams and the rest of your company, I would suggest building a plan for managing API changes, blending the standups to provide better information pollination and having teams that work together. Your developers probably don’t need to be able to work on both mobile and web technology stacks, but they need to at least understand what is happening on the other side.
This is a guest posting by Justin Rohrman. Justin has been a professional software tester in various capacities since 2005. In his current role, Justin is a consulting software tester and writer working with Excelon Development. Outside of work, he is currently serving on the Association For Software Testing Board of Directors as President helping to facilitate and develop various projects.
Test Automation – Anywhere, Anytime
