Developing and Testing Mobile Apps with Global Teams

Making the move to mobile-first application development is creating interesting challenges for co-located global teams. To this end, Matthew Heusser and Michael Larsen invited Mav Turner, the CTO of Tricentis, and Smita Mishra, CEO of Fandoro, to discuss the importance of user experience, security, and the need for optimized and secure code for mobile apps. They also highlight the challenges of working with distributed global teams and provide tips for effective collaboration, such as being aware of time zones and cultural differences.

Michael Larsen (INTRO):
Hello and welcome to The Testing Show

Episode 143

Developing and Testing Mobile Apps With Global Teams

This show was recored Friday, September 29, 2023.

As mobile-first application development is becoming more common for co-located global teams, Matthew Heusser and Michael Larsen welcome Smita Mishra of Fandoro and Mav Turner of Tricentis to talk about user experience, security, sustainability, optimized, and secure code for mobile apps. We also discuss the challenges of working with distributed global teams and provide tips for effective collaboration.

And with that, on with the show.

Matthew Heusser (00:00):
Okay, well this week we got something a little bit. different. I want to talk about a couple of intersecting things. We want to talk about the move toward mobile-first in application development, but also the teams that are building these mobile-first applications. Thanks to APIs, front ends, backend databases, outsourcing, and offshoring the team might be a lot more dispersed than what we’re traditionally used to and the challenges that brings. So to do that, we’ve got two guests for you. We have Mav Turner, the C T O of Tricentis, and Smita Mishra, who is the C E O of Fandoro, and we’ve known her forever. She started as a software tester in 2001 For a while, she was the CEO of QAZone in Delhi, India, and Fandoro is a software as a service platform for companies to identify and manage their sustainability goals, risks, and opportunities. Welcome to the show, Smita.

Smita Mishra (01:06):
Thank you, Matt.

Matthew Heusser (01:07):
We’re glad to have you here. A decade ago or so, we used to have a little consortium of testers that was called the Miyagi-Do School. Michael and I were instructors. You pointed out that when you took one of your early tests, we had this “test a lightsaber” toy exercise and you asked if the components were biodegradable. We think you’re the only person who ever asked that question.

Michael Larsen (01:33):
I can confirm that she is the only one who’s ever asked that. (Laugh)

Matthew Heusser (01:37):
Well, I mean I’ve given that test to a lot of people. She’s the only one that asked you, but I think that’s right. You were thinking about sustainability even then. So tell us a little bit about how you think about sustainability, quality, and how you got into Fandoro.

Smita Mishra (01:51):
Thanks Matt and thanks Michael for having me back on this show. Very happy to be here. Yes, much like my bio speaks, I’ve been doing testing since 2001 ever since my first job. That was straightaway into software testing after my engineering into computer sciences. I’ve done testing for a long, long time, of course, solving various other clients, doing various products and services, testing, and finally starting my own consulting at QA Zone and then moving on from there to build a SaaS platform for businesses to actually identify their sustainability goals and meet them at Fandoro. You brought in a very beautiful memory of mine, which was the Miyagi-Do classes that thoroughly enjoyed having you, Matt, and you Michael, as my teachers. One of the assignments, yes, was indeed about the lightsaber that Michael gave me. One of the tests that I had written there was the components biodegradable, we should check for it.

(02:47):
Michael did comment that it was interesting, it was unique, it was different and nobody really asked about that before. But this particular discussion that we are doing right now is about say seven, or eight years back, and fast forward here, I am actually taking up sustainability as a cause for my work, which still revolves around technology, cybersecurity, data privacy, and of course building secure apps. But now it is with a very different focus. However, as different as it may sound, very interestingly, the life that I lived through, the quality and testing ecosystem is so similar to what I’m living right now at sustainability. I find people making the exact same mistakes that I saw people doing at quality. I see people pretending the same ways being a good tester by having a good certification. It’s like way back, I heard that phrase that said, just having a driver’s license does not guarantee that you are a good driver.

(03:46):
And while it was true for the quality teams I saw back then, it’s so true for the sustainability teams I see today, everybody wants a rating ranking somewhere on this rating agency or that ranking agency or this reporting or disclosures. However, most of this is called greenwashing. If they don’t genuinely do it, trust me, the litigations on sustainability are increasing because people are not doing what they claim to be doing, unlike the quality world where people who just go do testing, even if it’s not exploratory, not risk-based testing where somebody writes a test case, somebody executes it almost like a zombie. Even in that world, but somehow go and get a test or certificate from somewhere and showcase it and make it appear like, okay, we are doing good work. Nobody did a litigation there. You are claiming to be a good tester. You are claiming to do good testing, but you’ve not done that. I haven’t heard of many litigations, thankfully. In sustainability world, consumers and customers are getting very serious about it because it’s a matter of life and death for them with respect to planet Earth. So we are seeing increasing litigations here. So that’s where I am today here from quality to sustainability, but in very similar roles.

Matthew Heusser (04:56):
And your company makes software and that software needs to be tested.

Smita Mishra (05:00):
Yes, absolutely.

Matthew Heusser (05:01):
So you’ve still got your finger on that piece of the ongoing work.

Smita Mishra (05:05):
Yes, yes, yes. In fact, we also work on due diligence for a lot of our customers. A lot of investors are now taking up environmental and social due diligence or the E S G due diligence as we call it before they invest. And as part of E S G, a lot of these startups for whom we do this due diligence are tech and tech-enabled businesses. So we do have to look into their technical certifications, their architectures, their security certifications, and their level of data privacy compliances, whether it is with the European standards, US standards, Indian standards, also the new D P D P that has come in India. So yes, we are very hands-on with testing even now.

Matthew Heusser (05:44):
And speaking of technical architecture and due diligence, we’ve also got Mav Turner, the C T O at Tricentis here, and he’s been there a couple of years. Before that, he was mostly in product development at a couple of other companies. If you haven’t heard of Tricentis, I should let him introduce it. I’ll do a poor job and let him correct me. But Tricentis started out as a tool vendor. They had a tool called Tosca, and Tosca was almost a pairwise test. You could record a test on almost any user interface and it could analyze the combinations and then it could multiply that out and run 500 test cases out of your one recording by snarfing user interface. And at one point they supported something like 120 different user interfaces. They’ve been a Qualitest partner for some time and they’ve been doing a bunch of acquisitions. So they acquired QA Symphony, the test case management company. They acquired SpecFlow, which made the behavior-driven development tool. They acquired Neotis, which was the enterprise load testing. So many things. Mav, did I get that even close to correct, if you can, tell us a little bit about your journey into the quality world from the product world.

Mav Turner (07:00):
Yeah, sure. I’ll start there and then I’ll come around. I think you got the highlights in the big picture, but I’ll add a little extra flavor to some of your descriptions there. I’ve been in technology for about 25 years, really started more on the infrastructure side back in the Windows NT days, going to Active Directory. Fortunately, I missed most of the Novell battles, so I never had to do much with token ring. It was a little before my time. Ultimately, it’s been about how to make technology work, moving from infrastructure to end-user support to moving into those more systems engineering and network engineering and things were always needed work. They didn’t just plug and play despite the great marketing label of plug-and-play, things rarely do where you just plug in and play. And so I spent most of my time trying to solve technology problems.

(07:46):
Sometimes that was building products, sometimes that was deploying and infrastructure hardware upgrades. The last 15 years have been more on the software side, building products, making sure that they’re working as expected, working with customers when they’re not, and trying to get them working properly. The most recent leg of my journey is here with Tricentis where I’m able to bring that larger infrastructure experience to bear here because a lot of our customers at Tricentis, you mentioned Tosca, definitely where Tricentis started from what most people know when they think of Tricentis. A lot of what our customers are using our products to do is to solve these massively complex IT problems. With their E R P systems, we’re up to 160 engines, so pretty much any sort of technology, green screen, mainframe, Excel, the most modern web apps, whatever you’ve got, we’ve got the technology to help you connect all of that together and ensure it’s working properly. And so that’s really where Tricentis shines. And as you mentioned, that was the test automation angle. We’ve expanded out from test automation to test management to performance engineering and making sure that we support the latest, greatest technology stacks. Whether you’re a cloud-native software development team building a product and you’re more worried about in-app workflow

(09:02):
Including web and mobile or you’re worried about a large enterprise challenge and you’re trying to connect that mobile app all the way back to your E r P system in some mainframe and some file server somewhere. All of those things come together in a really challenging way that frankly, if you make a mistake can have a big impact on your customers. Even a 1% or 0.1% impact when you’re operating at the scale that a lot of our customers operate at can have a massive impact on everybody. When we talk about the users really talking about customers, is it a regulated industry? Are we talking about power to your house or we’re talking about a prescription for your medical provider? It’s pretty much every industry has these complex challenges because of the legacy of technology that needs to be integrated and work together. And again, that’s where Tricentis really shines. But yeah, Matt, I think you did a great job of covering some of the highlights there about what Tricentis does and what we’re doing going forward.

Matthew Heusser (09:56):
I think it’s interesting as a C T O when you think about it because you’ve got all these acquisitions, you’ve got all these legacy products, you’re going to have to integrate them and one of the things we wanted to talk about today was integrating distributed global teams. So I think it’s going to be a fun time, but I’ll let Michael lead off.

Michael Larsen (10:15):
Thanks Matt and Mav and Smita, both of you. Welcome to the show today. I’m really glad you’re both here. The question I’d like to lead off here if I can is whether we are definitely looking at a world, or at least it seems to me, from just interacting with my kids, and seeing how they involve technology. All of my kids have either through us or through their own mechanisms, purchased MacBooks or laptops, but I almost never see them use them. Most of the time everything they’re doing is either on an iPad or on a phone or something to that effect. Part of the challenge I’m seeing with this is I’m literally right now wrapping up teaching a course on software test automation and doing the things we need to, and interestingly enough, most of what they asked us to cover mobile wasn’t even a part of it. I had to fit it in as, oh, by the way, here are some things you can do, and if you want to test with some mobile examples, say you have the ability to be able to create user agents and those user agents can simulate the space you’re in, that makes sense of what you’re doing as you’re taking a web app that already exists and when you use a responsive design, you can make sure that it fits inside of that.

(11:31):
But again, that’s taking existing web code. As you pointed out earlier, Matt, we have all these interactions with systems that we don’t know what they’re going to be connecting to us. We just know that we have to and we have to be able to service it. How do you go about that? What are some of the challenges that you’ve seen moving into this mobile-first and do you see that that’s a, oh, this is great, we’ve got a whole new area to work with or this is a nightmare because all of our legacy systems just make this miserable?

Mav Turner (12:00):
Yeah, I think there’s a couple of things here that are really important. One is the standard. What problem are you trying to solve? Question. I think a lot of teams, unfortunately, start with the, we have an executive mandate, we need mobile, and so what do we do? We jam our existing app into a mobile app just like you were talking about Michael, and then you say, well, how do we make that better? Okay, well let’s make a responsive app and that’s all fine. That’s something that’s important as part of the journey, but if we come back and say, what problem are we trying to solve and what are we really trying to do and how do we leverage the specific capabilities that are inherent in these devices that are different than me sitting at my desk, working at my screen on my laptop or a pc?

(12:40):
So the question is, do you really need a mobile app? Because if all you’re trying to do is take that web experience and make it easier for your users and you don’t want to use anything local or native to the device, then the expense associated with creating that mobile experience is probably not worth it. So when you look at what you’re trying to solve at the highest level, you’re trying to check a box to say, yes, c e o, we’ve got this mobile experience, or you’re trying to create something new and unique that can only exist there and that’ll really change how you think about building your applications, testing them. It’ll also drive a really good architecture or hopefully it’ll be a good forcing function for architectural decisions because if there are similar data in the backend that you need to access, then you can really force that abstraction between the front end and backend and you can say, look, I need to feed this same data service to this web app, but I also need to make it available to my mobile app, but once it’s on the mobile app, I may need to cache it locally.

(13:41):
And then how do I deal with making sure that the cache times out and refreshes appropriately? So it brings in all of these challenges. I’m trying not to follow any of those rabbit holes down right now because they’re all very fun, but when you think about the architecture of your application and you think about, am I just trying to make data available into this mobile device or I trying to do something unique that only can happen on this tablet or this phone because of the capabilities on it, right, the gyroscope, the camera, the mobile experience.

Michael Larsen (14:11):
Yeah, that’s a good point and actually probably more to this angle if I can, I’ll backtrack just a little bit with this. I think it’s safe to say we pretty much all understand that either developing a mobile app, whether it’s a native app or it’s a web app with responsive design, they both serve similar purposes. You’ve got to deal with a mobile app. That’s fantastic. We know it’s got to be developed. How do we go about testing it? Is there a fundamental difference that we should be addressing when we think about testing mobile versus testing the legacy systems we’re all used to?

Mav Turner (14:46):
I think so, yes. When you think about the mobile app again, where are your users? What device hardware profiles are they going to be on? Right now, I think on the website we’re starting to be pretty consistent on the Chromium model, so you can kind of align around that. iOS, and Android platform differences. Do you want to support a large variety of legacy handsets? Is your population primarily in the U.S.? Is it primarily in Europe? Across Asia? Is it developing economies? Is it mature economies? What are you expecting that end user to have access to is super important and understanding that is different. I think a lot of times when we build web applications, that’s less important because we don’t really worry about the network connectivity as much we should, and there are some mechanisms in place to ensure that the application continues to work if the internet connection drops.

(15:41):
But in mobile, that’s so much more frequent. Low connections, slow speeds, timeouts become bigger issues. How much bandwidth to a desktop, particularly in the U.S. is fairly fast and so we don’t really have to spend too much time optimizing that, but you send that to a mobile device and all of a sudden it makes a huge difference. I’m sure we’ve all had the personal experience trying to interact with an application and because of my touch, my finger, am I clicking the right button, I’ve gone down the wrong path, how do I get back to where I want it to be easily? So I do think that testing mobile apps requires a very dedicated mindset. I would say it’s a superset, so you need to consider the same things when you’re testing web, but then there’s some unique areas that you just spend time dedicating your focus to ensure that your users have a good experience.

Smita Mishra (16:24):
I wanted to add to that, I think Mav has some fantastic parts there on mobile app testing. Just to add some of them through our own experiences. One of the things we’ve struggled with is definitely app permissions when you’re integrating with interacting with other apps, sometimes what you are asking for is that even a relevant permission you really require. You have to be very clear on what permissions you’re giving to other apps and what you are requiring from the user. Definitely the API authentications and accessing data from all those integrated apps. Of course, it’s similar to again, web apps for sure. Like Mav said, certain areas are very specific to mobile app particularly how’s the application doing its degradation at the low storage of the phone. There are specific situations where there is low battery or low storage or if there is a specific security tool running, some kind of update going on at that time.

(17:18):
Interruptions during let’s say a phone call is coming in or text messages are coming in. So there are very specific scenarios or edge cases as you may want or how does the app work when it’s in offline mode and when it’s online mode? These are some of the areas that we have had to look into and there are very specific things just to add on the compliance and security part with different ecosystems and different apps. So when I say security also about the data integration and data exchange, at that point in time of data encryption, how are we really taking the data? What form does it come from a particular app and what’s the encryption taking in that data and making sure we are able to convert it into the right format and respond back. That’s another thing we’ve struggled with quite a few times, particularly when integrating the payment gateways or different currencies.

Matthew Heusser (18:07):
Yeah, I mean the short summary of that I think is to figure out the common cause of failure that is unique to mobile devices and then test for those common causes of failure and if you can put it in their requirements, design it in, have the examples known so you don’t have to code it twice, and if you don’t have that so your team just doesn’t have the experience, then there are cheat sheets online. There are articles online. To me, they just listed a bunch of great ideas or hire someone who has done it before. Obviously, Qualitest has people that have done it before. We’d be remiss not to mention that. That’s more tactical, I think. Here’s the list of things you should think about. Here’s a list of specific test attacks. If we could spend just one more moment here, is there anything more high-level that we should… I really like the way MAV framed it. We have a website, and we need to have a mobile app, go make the mobile app and all of the problems and the structures of the systems operationally, we don’t know how to build it, we don’t know how to test it and then we don’t know how to put in it on the product line. Do you have any advice for people to sort of get over that hump to change the mindset to be successful at moving to mobile development?

Mav Turner (19:26):
I mean the simple thing is a lot of times people get a little overwhelmed with that complexity that you just mentioned, and I would say that core Agile principles, continuous improvement, get started, get your hands on the technology, and that will help you understand it a little bit more. I think a lot of folks worry about how do I do this? What do I need to do? And I would encourage you to experiment to play with this technology as you can and start to learn and that will really guide your next steps. Again, you can determine whether you need to bring in an outside consultant fairly quickly, but if you’ve never done anything with mobile and you’re saying, look, we need to do something, the best thing is to start today. If you have an experienced team and you’re looking at how do you expand, then you can mature.

(20:11):
A continuous improvement mindset really comes into place, where are you at today? How do we make a plan for tomorrow? And I realize that is also another high-level recommendation, but my main thing is to start playing with the technology. That’s something that I’ve found very helpful throughout my career and when I have teams that are struggling and they’re not quite sure what to do, whether you call it a research spike or whether you call it an experiment, start working with the technology, try to narrow that problem down. Again, is your primary user going to be on both Android and iOS? Can you narrow that down? Can you start where you think you’re going to have the biggest impact and start using that technology? Learning from resources like this is great, but you need to start using your hands if you’re ever going to really understand those challenges. So that’s my one main advice.

Smita Mishra (21:00):
I think I totally second what Mav just said and definitely playing around with the technology, learning it, and implementing it works. If I could give some kind of North Star to this particular kind of testing, I would say that the whole purpose of why a lot of people are beginning to use mobile apps is just the user experience. It’s just easier. It’s quicker for them. I mean, the phone is at Access. They want to just use the app. I think there are reports that speak of higher conversion for various businesses on mobile apps because of this, which means as a tester, I would definitely want my North Star to be user experience, smooth, responsive, intuitive, whatever you want to call it. That would be my North Star, but not at the cost of security, which means a lot of your information, pictures, financial access and bank logins are there on your phone. So not at the cost of security, but yes, my North Star there I would suggest for the testers would be the user experience, like test for it across various stores like iOS or Android, and definitely across all the devices of various fragmentation, whatever. Again, if your user is in the U.S. or elsewhere or so what are the devices popular, the browsers and all of it. But yes, it’s definitely the user experience and security that I would like to suggest them to follow.

Michael Larsen (22:22):
This intrigues me because I’m really curious about this mainly because of the fact that recently, for those who don’t know, I worked for a decade for a company as primarily a software tester and doing a number of things in that capacity, but as of now, for the last few months, I’ve actually shifted into consulting, contracting, whatever you want to call it, but I’ve been training, I’m actively training a cohort right now with a multinational company, and interestingly enough, I’m located in California on the west coast of the United States. My students are located in the United Kingdom and in India. So we’ve had some very interesting general challenges, and I’m using this just as a microcosm of this. My class times when I meet with them start at 5:00 AM because that’s the one time that both of those teams can be effective for an extended period of time.

(23:20):
I’m oftentimes getting ready to teach a class at four o’clock in the morning just so I can make this work. And I realize also that trying to navigate out with this to say, well, if we could go a little bit longer, that would be great, and I’m having my team that you do realize it’s almost midnight here, right? Yeah, I do. This reminds me that… and my commitment to this is only four hours a day, two days a week. For the last few months. I’ve learned so much about the challenges that are faced not just with time zones, but with the literal things you have to work with to have teams be effective in this regard and responsive. Holiday schedules are completely different. So I try to schedule around those, and sometimes I don’t even know that there’s a holiday until the day before a class is scheduled and say, oh, we’re not going to be able to make it because of this celebration that’s happening.

(24:15):
And I don’t necessarily mind that, but sometimes I think it’s not just a matter of, Hey, where do the tools work, but it’s how do you communicate them? How do people use them? Are there cultural differences and barriers? Simple answer, yes, but what are those and could you potentially help me figure out how, if I’m going to be working with teams in this capacity, (hopefully I will), what are some things I should know? What are some stumbling blocks that I can get out of my way to help make that a better experience? Loaded question much (laugh)?

Mav Turner (24:51):
For sure. Very loaded question, and while there’s not a easy button here, my more recent history last say 15 years or so, most of the software teams I’ve been working with have been global, whether that’s in the Czech Republic, Poland right now most of my team is in Israel. I worked a lot with teams based out of India. I also have some folks in Australia as well as the U.S. You mentioned the cultural differences, and I want to start there. It’s not just a cultural difference in the sense of how we communicate with one another, how we do expectation management, how we receive and give feedback productively. It’s also just a cultural challenge with being in tune with what’s going on locally and all of those things that help form a team into a team outside and above the work. For example, about 10 years ago I did an expat assignment, and even though obviously I’m coming from the headquarters where I shared the exact same cultural experiences, we talk about American college football, I knew what was going on, no language difficulty, moving myself into this European time zone was a massive challenge.

(25:58):
Now, at the time, I had no kids and my wife hadn’t moved over yet, so the short answer was I just worked all the time, which is not a good scalable answer, but the reality is even then being remote was very challenging. If your team is not fully distributed, that’s another component that’s important, which is if you’re the only person in the team, a little bit like you were talking, Michael, you’re there in California, the rest of the folks are in the U.K. That’s one scenario. If you’ve got everybody distributed, that forces some of these cultural challenges to be addressed more drastically versus my teams that are co-located, I tend to find more success when the smallest atomic unit of the team is as co-located as possible so they can share those cultural similarities. And then in my role, obviously I need to adapt to all the different ones, but where we have different teams, I hate to use this analogy, but it works really well. We have clear APIs between the team expectation management, whether that’s a literal technical API that’s combining the team or whether that’s just understanding and making sure you find time for those teams to work together outside of the tactical operational meeting,

(27:09):
Whether that’s a daily standup or your sprint planning sessions, those are all great, but you need to find time to make sure that you’re exploring some of these other issues and you have these common understandings. Frankly, there’s some good resources out there to help understand the different cultures. Every time that I’ve spent even a little bit of time trying to understand the culture that I’m working with, I feel like it’s paid 10x dividends. Even if you think, oh, is this fine? Take a little bit of time, and understand the culture you’re working with and that will just massively impact your productivity and frankly, the team cohesion.

Matthew Heusser (27:44):
Thanks, Mav. If I could say recently I’ve worked with both kinds. I’ve worked with teams where everybody works from home or wherever there’s internet and power. Everybody works remotely, usually within one country, and I’ve worked where you’ve got a team in Poland and you’ve got a team in Portugal and you’ve got a couple of teams in the United States, maybe there are core hours 10 to 2 Pacific you need to be available, that kind of thing. But I think in my experience, for me it’s been more challenging when you have teams that have different architecture responsibilities. We do the API stuff, we do the database stuff, we do the cloud stuff, we do the front end and they’re in different places and then getting them to talk and communicate. We do their Ops stuff, we do their release stuff. That’s been really challenging for me. Have you seen that and what challenges does that propose? What are the biggest challenges we see here before we get into some of the solutions?

Mav Turner (28:46):
I hate to repeat some of the things Michael said earlier, awareness of vacation and time zones, who’s up when and where? Like you said, Matt, establishing those very specific working hours and acknowledging those working hours and not pushing those teams to work till midnight. It’s a little different in Michael’s scenario

(29:03):
He’s talking about from a working perspective, being hyper-aware, that’s super important and it really squishes down the availability. I can barely keep track of the U.S. holidays, much less globally, so I have to look at my calendar almost every day with the global calendar. So being aware of the working time zones is extremely important. I do find that if you can have, when I say co-located, the same country is fine. Again, that cultural difference is the thing that’s going to drive and the time zone difference is what’s going to drive. I think your organizational design ensures improvement. I’ve often had teams for various reasons where they’re spread out. Again, maybe right now I’ve got a team in Australia that works with a team in Israel and trying to set up time zone-friendly meetings and include me does not work.

(29:50):
And so making sure how can we design the organization to remove that friction on the team and on the employee. So my perspective coming in as C T O is how can I build the organization to be successful and then give ownership that minimizes the dependencies and the need for those teams to work together. It never reduces it. There’s always cross-functional dependencies, particularly as the organization gets larger and gets spread out across the globe, but being very proactive about changing the team structure, the ownership, even if the team worries that it’s going to be more work, it actually reduces their work if you can reduce those interdependencies.

Matthew Heusser (30:30):
Thanks. I’m going to push back on one thing you said and that was that org design should be influenced by time zones, and locations, and optimized for that. Just to let our hair down for a minute. I see the opposite. I see “make it work”. You don’t understand their political reason, or financial reason. They’re where they are. You’re where you are. Can’t you just make it work? Make it work. I don’t want to hear about it. Bring me solutions, don’t bring me problems. Frankly, that’s what I hear. I don’t see a lot of work design around that. Am I wrong and does that create challenges and constraints?

Smita Mishra (31:11):
Yeah, but I do agree with you that we could make it work and I’ll come to that part too, but I’ll probably take a step back and first acknowledge the original thought process there on having potential risks and challenges while working in such a situation. When you have a very distributed team, particularly when Michael said that not knowing about the holiday calendar, that made me think. Different cultures perceive communication hierarchy, problem-solving very differently. The very basic language barrier can actually bring in so many misunderstandings or if people have different communication styles or working ethics, that could make things very, very different. And to your point previously of having distributed teams where part of team is in one time zone and their part is in another zone. Yes. Again, coordinating across those time zones actually given that it’s going to cause you delays in communication and project timelines and certain of these things.

(32:12):
In fact, there are bigger challenges, intellectual property theft, data breaches, and cybersecurity threats because you don’t know where the person is living, where are they working from, what kind of security they have on their machines. A lot of things need to be controlled, and of course, these things bring in their own legal and compliance issues. A lot of hidden cost issues. You may be paying some X, Y, Z amount to a certain person or a certain team or a certain organization, but the kind of tax structure the country could make a lot of difference. So a lot of things here are part of these; like holiday calendars, tax structures and things like that are public knowledge and are some things which I would highly recommend teams to synchronize much in advance or at least know much in advance as a best practice or good practice, as you would say. These are things you need to know in advance or at least the kind of data security that people can afford, the kind of infrastructure and technology differences that they may have to deal with.

(33:08):
If they can bring those upfront, those can be some of the very specific more quantitative information that can be known and fixed. The softer issues of cultural and ethical issues are those which are a little bit more challenging also because much to when Michael said about the holiday calendar, how often do you really talk about your celebrations or holidays or how often do you celebrate your diversity across various teams? As a cultural thing, I’m not necessarily talking about in HR to step in and do something that wouldn’t even be good, but just doing regular team building and talking about various things or lives around them beyond just work, that could be very helpful because then people feel more comfortable and particularly people who believe in certain kind of hierarchical communication. Breaking down those blocks and those walls makes it easier for people who are facing challenges for them to open up and mention the challenges much in advance, which will be very helpful for the project. So from that perspective, organizational culture doesn’t necessarily have to be driven through these items, but I think there’ll be a fine balance there. What are the issues we are facing? If we really can’t manage them, then we will have to make some challenges in the organizational culture, but most of it in my belief can be managed.

Matthew Heusser (34:33):
So before we get going, let’s spend a minute and talk about the impact of global mobile apps and flip it around. Instead of thinking like a big team all over the world, it’s going to be used by people all over the world. People that maybe can’t even afford a laptop now could get a mobile device. We can skip telephone lines and go directly to a cell phone, but there are people that have computing for the first time. Smita, I know this is one of the things that’s on your list of things you care about. Do you have any recommendations for makers for a suddenly big, 10 times larger customer base?

Smita Mishra (35:10):
Yeah. In this new economy, the new world that we are bringing in, there are a lot of people who are going to move from a lower economic strata to a higher economic strata. There is one set of people at that end and then at the other end we have people and technology users who are probably working on high-end satellite technologies going to Moon and Mars and all over the place. So there’s a huge spectrum of users that we are going to be building these solutions for. With respect to my current work, there are a couple of things I would just want the users to think about after they listen to this podcast. One of them certainly being built more optimized and better solutions. We are particularly talking about how we can actually make smaller or optimized code for the algorithms and smaller models which can actually be more resource efficient and more energy efficient, and also have quicker response time and be more useful to the users to build those kind of code, which is very, very optimized for processing and therefore uses lesser energy and definitely be building these more secure app. Because while there’s a certain section of society which is pretty used to the clickbaits and phishing and is very careful about it, there’s a huge new population stepping into using mobile apps for the first time using FinTech apps on it for the first time, putting in all their life’s earnings there and new users coming from Asia and Africa.

(36:41):
Keeping them in mind. I mean, please build secure apps. When I say secure apps, I mean definitely look at how we can not pass on the risks to the customer. Test for risk-based issues and of course use green technology, green cloud, how can you power your technology, your cloud servers using renewable sources?

Matthew Heusser (37:01):
Well, thanks Smita. It feels like we just got started, but we should get going and we want to leave our audience with the best at the end. We got to give ’em that cherry on top of the ice cream. At the end, we’d like to do a tip, a technique, a takeaway, or where to go for more to learn more about the things that we’ve covered today. Mav, do you have anything you’d like to add before you go on?

Mav Turner (37:24):
Yeah, thanks Matt. My main tip is mobile testing is important. There’s easier ways to do it. If you’re scared, don’t know where to start. If you’re looking at trying to buy a bunch of devices, make your own lab, that’s not the right place to start. There’s a lot of solutions out there. Obviously I’m biased towards the ones that we’ve created at Tricentis, but I would encourage you to leverage some of those technologies to make mobile testing easier. To, as Smita said, test across all these device profiles that are important for your users to ensure they have a good experience, whether that’s low bandwidth, low resources, whether that’s just different device types that you wouldn’t have otherwise. At Tricentis, we have solutions that can help you test those complex end-to-end scenarios or just make it really easy for you to get the right devices to test the permutations, whether those are emulator grids that we have with virtual mobile grids or they’re physical devices that you need a little bit of time on as part of your testing process.

(38:21):
Leverage those solutions to make your job easier, to improve the quality of the product. There’s no reason that you need to try to say, Hey, we got a big mobile initiative, so we need to buy 20 different physical devices and set up a new environment in our lab. There may be some use case that takes you down that path, but definitely don’t start there. Start where it’s easy. Start with the virtual mobile grids. Start with physical grids that you can execute your test on and try to incorporate that as early in the process as possible so you can understand how the latest versions of iOS or Android impact your application, how these different environmental characteristics get impacted by your application, how the different form factors impact your application. Pull all that early into the design to the build stage. Don’t wait until you are getting into that delivery stage. Make that easy for your QA teams, for your development teams to test across this entire environment. Make it easier on yourself. Go to tricentis.com in our product section. You’ll see different mobile solutions depending on what you’re trying to do there, and we’re here to help.

Smita Mishra (39:26):
If I could just jump in, add to what Matt said. I so much agree with what you just said, that don’t wait for building the complete apps and then testing them in some real environment. The cost of building these environments are very high. These days, mobile phones, particularly the ones that get trendy, these are expensive phones we are talking about. I would suggest heavily that people should use tools like Qualitest or any virtual test environment that they would like to use, but definitely Qualitest is one of the better ones where they could actually start testing from the very start of designing and building the app for various kind of even network access. That is something even if you bring in multiple phones, trust me, it’s going to be a very difficult challenge to bring in 2G, 3G, 4G, 5G, all kinds of networks across having such an environment would be a boon for testers.

Matthew Heusser (40:19):
Thanks, Smita. I think I talked plenty. So Michael, do you have anything you want to add?

Michael Larsen (40:23):
Well, just considering my recent exposure to this, and again, this is just based on the fact that I was brought in last minute to do a training opportunity and I’m grateful for doing it and I learned a lot in the process too, and what I realized was that a lot of what we are focusing on, especially when we’re doing upskilling, is that I think we still focus on a lot of the tools as though the desktop is where a lot of this is going to be run from and a lot of this is going to be effectively handled. There is room for mobile. Not only is there room, I think we need to make it a priority. A lot of the tools now make that easier to do. You don’t necessarily have to have a full device farm and load up a bunch of apps to do it.

(41:08):
You could just play around with the user agents and the sizing and options and just use the responsive elements. Or there are things like test flight that will allow you to actually run things in simulation. But yes, I agree with MAV and Smita that it’s important not just to get in and play with the applications and the tools, but to also understand what might drive somebody to use the tools differently than you will. To wrap this whole thing up, I would definitely say it’s not just enough to say what devices are you using, but what is the situations that your users are moving to those platforms or making those their first line of anything they’re doing? Understand that and I think that the situation will be easier to deal with going forward. That’s my take.

Matthew Heusser (41:55):
Fantastic. Well, with that, we all got to get going, so thanks for being here and let’s do this again real soon. Maybe we can talk… I don’t think we’ve talked about low-code, or no-code in a very long time, so I think we have more things to talk about.

Michael Larsen (42:08):
I think that would be a good one. Thanks, everybody. Thanks so much for joining us.

Mav Turner (42:11):
Thanks.

Smita Mishra (42:12):
Thanks all.

Michael Larsen (OUTRO):
That concludes this episode of the Testing Show. We also want to encourage you, our listeners to give us a rating and a review on Apple Podcasts. Those ratings and reviews help raise the show’s visibility and let more people find us. Also, we want to invite you to come join us on The Testing Show Slack channel as a way to communicate about the show. Talk to us about what you like and what you’d like to hear. Also to help us shape future shows, please email us at [email protected] and we will send you an invite to join the group.

The Testing Show is produced and edited by Michael Larsen, moderated by Matt Heusser with frequent contributions from our many featured guests who bring the topics and expertise to make the show happen. Additionally, if you have questions you’d like to see addressed on the testing show or if you would like to be a guest on the podcast, please email us at [email protected]