Hello and welcome to The Testing Show, Episode 143, Developing and Testing Mobile Apps with Global Teams. This show was recorded Friday, September 29th, 2023. As mobile-first application development is becoming more common for co-located global teams, Matthew Heuser and Michael Larson welcome Smita Mishra of Fandoro.
and Mav Turner of Tricentis to talk user experience, security, sustainability, optimized and secure code for mobile apps. We also discuss challenges of working with distributed global teams.
and providing tips for effective collaboration and with that on with the show 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, back ends, databases, outsourcing, 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 CTO of Tricentis. And Smita Mishra, who is the CEO of Fandaro. And we've known her forever. She started out as a software tester in 2001. For a while, she was the CEO of QA Zone in Delhi, India. And Fandaro is a software as a service platform.
for companies to identify and manage their sustainability goals, risks, and opportunities. Welcome to the show, Smita. Thank you, Matt. I'm 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. He pointed out when you took one of your early tests, we had this.
test a lightsaber toy exercise, and you ask if the components are biodegradable, we think you're the only person who ever asked that question. I can confirm that. She is the only one who's ever asked that. 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, how you got into Fandaro. 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 straight away into software testing after my engineering into computer sciences.
I've done testing for a long, long time, of course, serving various other clients, doing various products and services testing, and finally starting my own consulting at QA Zone. We've gone from there to build a SaaS platform for businesses to actually identify their sustainability goals and meet them at Fandoru. You brought in a very beautiful memory of mine, which was the Miyagi-Do classes.
I thoroughly enjoyed having you Matt and you Michael as my teachers. One of the assignments, yes, was indeed about lightsaber that Michael gave me. One of the tests that I had written there was, are the components biodegradable? We should check for it. 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're doing right now is about, say, seven, 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 doing 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 which said, just having a driver's license does not guarantee that you are a good driver. 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 or 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 could 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 tester's 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're seeing increasing litigations here. So that's where I am today here, from quality to sustainability, but very similar words.
And your company makes software. That software needs to be tested. Yes, absolutely. So you've still got your finger on that piece of the ongoing work. Yes, yes, yes. In fact, we also work on due diligences for a lot of our customers. A lot of investors are now taking up environment and social due diligence or the ESG due diligence, as we call it, before they invest. And as part of ESG... A lot of these startups for whom we do these due diligence are tech and tech-enabled businesses.
So we do have to look into their technical certifications, their architectures, their security certifications, their level of data privacy compliances, whether it is with the European standards, US standards, Indian standards, also the new DPDP that has come. and India also. So yes, we're very hands-on with testing even now. Yeah, and speaking of technical architecture and due diligence, we've also got Mav Turner, the CTO 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. Trisentis 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 interface. They've been quality test 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 SpectFlow, who 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? And if you can tell us a little bit about your journey in the quality world from the product world.
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 here. 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 just plug in and play. And so I spent most of my time trying to solve technology problems. 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, trying to get them working properly. The most recent leg of my journey is here with Tricentis, where I'm able to bring in... that larger infrastructure experience to bear here because a lot of our customers at Tricentus, you mentioned Tosca, definitely where Tricentus started from, what most people know when they think of Tricentus.
A lot of what our customers are using our products to do is to solve these massively complex IT problems with their ERP systems. We're up to 160 engines, so pretty much any sort of technology, green screen, mainframe, Excel. the most modern web apps, wherever you've got, we've got technology to help you connect all of that together and ensure it's working properly. And so that's really where Trisentis 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 and greatest technology stacks, whether you're a cloud native software development team building a product and you're more worried about in-app workflow.
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 ERP system and 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, it 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, we're really talking about customers. Is it a regulated industry? Are we talking about power to your house? Are we 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 Tricentus really shines. But yeah, Matt, I think you did a great job of covering some of the highlights there about what Tricentus does and what we're doing going forward. I think it's interesting as a CTO, 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. Thanks, Matt. And Mav, 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 we are definitely looking at a world, or at least it seems to me, from just interacting with my kids, 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 that 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. If you want to test with some mobile examples, say you have the ability of being able to create user agents and those user agents can simulate the space you're in. That makes sense if what you're doing is 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. But again, that's taking existing web code, as you pointed to earlier, Matt, we have all these. interactions with systems that we don't know what they're going to be connecting to us to. 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. 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 response of that. 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. 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, are you trying to check a box to say, yes, CEO, we've got this mobile experience? Or are you trying to create something new and unique that can only exist? 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 frontend 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. And then how do I deal with making sure that 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 am 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.
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 know 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? 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, 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? 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. But in mobile, that's so much more frequent. Low connections, slow speeds, timeouts become bigger issues. Bandwidth to a desktop, particularly in the US, 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, I'm clicking the right button. I've gone down the wrong path. How do I get back to where I wanted 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 thing in your testing web, but then there's some unique areas that you can spend time dedicating your focus to, to ensure that your users have a good experience.
Just wanted to add, I think Mav has some fantastic thoughts there on mobile app testing. Just to add some of them to 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're 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 Matt said, there are certain areas which 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 specific security tool running.
Some kind of update going on at that time. 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 they're 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 quite a few times, particularly when integrating with payment gateways of different currencies.
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 the requirements, design it in, have the examples known so you don't have to code it twice. And if you... Don't have that. Your team just doesn't have the experience. And there are cheat sheets online.
There are articles online to me that 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. 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? 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. Continuous improvement mindset really comes into place. Where are you at today? How do I make a plan for tomorrow? And I realize that is also another high level.
recommendation, but my main thing is start playing with the technology. That's something that I found very helpful through 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 a 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 I think I totally second what Matt 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 a 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 a 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 not start 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.
various fragmentation, whatever. Again, if your user is in US or elsewhere, or 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. 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 a.m. because that's the one time that...
both of those teams can be effective for an extended period of time. I'm oftentimes getting ready to teach 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 which reminds me that
And my commitment with 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 trying 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 saying, oh, we're not going to be able to make it because of the celebration that's happening. 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? For sure. Very loaded question. And while there's not a...
Easy button here. My more recent history, last like 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've worked a lot with teams based out of India. I also have some folks in Australia, as well as the US. You mentioned the cultural differences, and I want to start there. It's not just a cultural difference in a 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 talked about American college football. I knew what was going on. No language difficulty.
Moving myself into this European time zone was a massive challenge. 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 on the team, a little bit like you were talking, Michael, you're there in California.
The rest of the folks are in the UK. 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 that's the smallest atomic unit of the team is as co-located as possible so they can share those cultural similarities. And then me, 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. Whether that's a daily stand-up 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, this is fine.
Take a little bit of time, understand the culture you're working with, and that will just massively impact your productivity and, frankly, the team cohesion. 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 remote, 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? What challenges does that propose? What are the biggest challenges we see here before we get into some of the solutions? 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 acknowledges working hours and not pushing those teams to work till midnight. It's a little different in Michael's scenario. He's talking about that 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 the ones 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, 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 to ensure improvement.
I often have 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 basically. 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 at as CTO 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, gets spread out across the globe.
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. Thanks. I'm going to push back on one thing you said, and that was that... Org design should be influenced by time zones, 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, financial reason, 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? 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, you know, not knowing about the holiday calendar, that made me think, you know, different cultures perceive communication, hierarchy, problem solving very differently.
The very basic language barrier can actually bring in so many misunderstandings. And if people have different communication style 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, another part is under 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, in fact, there are bigger challenges. Intellectual property theft, data breaches, 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 XYZ amount to a certain person or a certain team or a certain organization, but the kind of tax structure the country has 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, if they can bring those up front. 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 what 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 an HR to step in and do something.
That wouldn't even be good. But just doing a 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 challenge in the organizational culture. But most often, in my belief, can be managed.
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. You know, we can skip telephone lines and go directly to a cell phone, but there are people that have computing for the first time.
Samita, I know this is one of the things that's on your list of things you care about. Do you have any recommendations for app makers where they're suddenly big, 10 times larger customer base? 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 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 please more secure app because While there is a certain section of society which is pretty used to the clickbaits and phishing and is very careful about it, there is a huge new population stepping into using mobile apps for the first time.
fintech apps on it for the first time, putting in all their life's earnings there and new users coming from Asia and Africa. 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? 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 them that cherry on top of the ice cream. At the end, we 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 get going? 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 Tricentus, 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 their physical devices that you need a little bit of time on as part of your testing process. 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 grid. 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 Tricendus.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.
If I could just jump in, add to what Mav 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're talking about. I would suggest heavily that people should use tools like Qualytest or any virtual.
I mean, test environment that they would like to use, but definitely Qualtest is one of the better ones, where they could actually start testing from the very start of designing and building the app for various kinds 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.
Thanks, Smita. I think I talked plenty. So, Michael, do you have anything you want to add? 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, 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. And not only is there room, I think we need to make it a priority. And 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. 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 kind of 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. Fantastic. Well, with that, we all got to get going.
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, no code in a very long time. So I think we have more things to talk about. I think that would be a good one. Thanks, everybody. Thanks so much for joining us. Thanks, y'all. Thanks, all. 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 visibility of the show 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, and also to help us shape future shows.
Please email us at thetestingshow at qualitestgroup.com and we will send you an invite to join the group. The Testing Show is produced and edited by Michael Larson, moderated by Matt Heuser.
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 thetestingshow at qualatestgroup.com.