Programming Throwdown - Testing on Mobile with Kobiton

Episode Date: May 15, 2017

In this episode we interview Josh and Adam from Kobiton. They describe the challenges with releasing a mobile app for many platforms, and how Kobiton allows one to test their app on many devices in the cloud. Show notes: http://www.programmingthrowdown.com/2017/05/episode-65-testing-on-mobile-with.html ★ Support this podcast on Patreon ★

episode 65 testing on mobile with kobe ton take it away patrick time for our interview we're here with josh and adam uh j, why don't you go ahead and introduce yourself and tell us a little bit about what Kobiton is? Sure. Yeah. My name is Josh Lieberman. I'm the president and one of the founders of a company called KMS Technology. We're a 700-person consulting firm. And as part of our consulting firm, we use that as a platform to identify market needs with our clients and then spin out software product companies. Kobiton is one of those companies. And it's a complete mobile device cloud platform that enables developers, SMBs, and enterprises to really optimize their mobile testing and giving

them access to and management of both devices they own internally, as well as a mobile device cloud platform that we have as well. One of the keys for everybody in the audience here is we focused on making Kobiton affordable, that you know whether you're an indie developer building an app or a large fortune 500 company you can optimize the use of any devices that you own internally and at the same time where you need to flex and try out different devices outside of those that you own have access to our lab as well. Awesome, and then we also have Adam. Adam, why don't you tell us a little bit about yourself? Hey guys, my name is Adam Satterfield. I'm currently the VP of testing at KMS Technology. I'm also a testing evangelist and consultant for Kobotan.

I've been in the tech world since about the late 90s. I got a chance to cut my teeth on a lot of the Y2K testing that went around that time. Oh, nice. So definitely seen a lot come and go. Remember some of my earlier testing, testing on old HPUX systems. I'm sure a lot of the folks listening to this

probably wouldn't even know what that is. So can definitely say that I've seen a lot come and go. Really passionate about both development and testing. And really excited to, you know, talk about mobile testing, about Kobotan, and mobile development as well. So thank you, guys. Very cool.

I remember that. I remember there's something wild, right? Like even when the ball was going to fall at Times Square to usher in the year 2000, that all of a sudden all the lights would go out or something crazy. All of these conspiracy theories. And none of them came true because of you. That's right. We worked very hard day and night to make sure that all of your biases would be updated for Y2K. Nice. Cool. So, you know, there's a lot of people listening who have a background in kind of web. They've built websites.

Even entry level, one of the first things you do is kind of make an HTML site and do some PHP or something like that. And so you have kind of an idea of that development flow where you're kind of testing on web and you can test the JavaScript on your own browser and things like that. But with mobile, it's kind of different because you have this other device and you have sort of your host machine, you have this other device you're testing on. So how is it kind of different

than doing development on the web? Sure. Yeah. So one of the things I always like to talk about first is scope. You know, when you think about web development and web testing, there's really only about three. Don't tell the Linux folks that I'm looping all the Linux into one OS, but really only about three operating systems and about four major browsers, depending on who you ask. And even looking at that, you see Chrome holds a pretty heavy share in terms of what folks are using in the market. And you get a pretty big drop-off point to where usage drops off for users what they're using for browsers. So you understand when you're going into the web space, you know, what your scope really is. It's, you know, limited browsers, it's limited operating systems. And frankly, you know, we've been doing PC and

desktop development and browser development and testing for a really long time. So we've been doing PC and desktop development and browser development and testing for a really long time. So we've got really good tools. We have really good development environments. We've got good processes around rapid deployments for those. When you start looking at mobile, however, it really starts to change things because now let's take a look at we've got to do some of the same type of testing on the web, but we've got to talk about devices. So last time we checked, about 99% of all smartphones in the world either run Android or iOS. So that may sound great. I've only got two devices or two platforms that I really need to test on. But when you start looking into it, things get a lot bigger. Only about 70 to 76%

of users are actually using the latest iOS version. So if you build only for that version, you may be cutting out a large portion of your users. On Android, yeah. So when you think about it, it's like, okay, so that's about 30% of users that I may not be addressing by just testing or developing for the latest iPhone. Right, and you can't just cut them out because then, you know, if one of those users happens to be, you know, a writer for the New York Times or something, then you get completely hammered and your product gets just thrown in the gutter or something. Yeah, exactly. And you think about, you know, you've got even looking at different, you know, usage groups or age groups. If you're trying to develop an app, say you want to develop a game, well, then there's probably a pretty good likelihood if you're developing a game for the millennials, they've got the latest and greatest. So maybe that's all you really care about is that 76%. a financial app where perhaps you've got a wider age group, then you have to pay attention to that

larger, you know, that larger OS distribution, because if you don't, you're going to be cutting out that older age group who may not understand the upgrading or they may not be quite as tech savvy, but they're going to be a large user of your application. And one of the things that we've seen, especially for Android, Android, it makes everything much more complicated. I think last count, there was well over 500 different Android devices at any given time being sold by Verizon, you know, the AT&T. And what we found is that only about the largest Android platform right now only has about 30%

of the overall total users on that platform. And that's NuGet, I believe. Okay. And the next one itself is only 23%. So you're talking about needing to develop an app that supports maybe up to five different Android versions. And you start getting really complex there. Yeah, and I think with Android, too, you also have hardware diversity. Like, I think the hardware companies fork the OS, something like that, because basically I bought a tablet, and I thought that I could, as an Android tablet,

I thought that I could just replace the OS, but it turns out they, I guess they forked the OS to make it support their type of touchscreen or something. But basically their version of the OS wasn't the vanilla version. And if you just replace it with the Android that you could get for free, you know, the touchscreen wouldn't work. Exactly right. Yeah. And Samsung's pretty notorious for doing this. And even you add on, you start adding on carrier distributions and carrier differences as well, where they want you to upgrade at different times.

So you've got folks who have the same phone, but it works differently on AT&T than it does on Verizon. Oh, geez. Yeah, so when you start thinking about Android, it boggles the mind at the vast array of different types of devices that you can test on. And it's not like with web. You could have a sandbox with 10 different versions of Chrome running at the same time. But here you're talking about literally different OSs.

So you need kind of different devices or some way to represent that. Yeah, that's exactly right. And I know Josh has got some good information for us on some of the features and functionality of KobeTime for that. Yeah, that's exactly right. And I know Josh has got some good information for us on some of the features and functionality of Kobiton for that. So Josh, do you want to touch on that now? Yeah, sure. Fundamentally, what Kobiton allows you to do is sit at your computer and go through our platform and control any device plugged into the Cobyton network anywhere in the world. So a lot of people, as Adam talked to, need access to different types of devices to make sure that their app or their responsive website works on different types of apps.

So not only do we have a lab set up in Santa Clara, California that can be accessed anywhere in the world, it currently has approximately 200 devices there and it's growing every day. But you can also plug in, let's say you're part of a company like Lockheed Martin, for example, and you've got people working all over the world, you could plug in all those devices globally and have people sitting anywhere, and as long as they're connected to your Cobyton platform, access those devices and test upon them as if they were holding them and use all the features that are available within a phone but doing that virtually or not virtually because it's not a virtual machine it's an actual device

but doing it through your computer gotcha like doing it remotely so what how do you keep someone from just bricking the phone or if they do then then I guess I guess the phone physically exists somewhere and so the person will go out and and and flash it or what have you yeah let me let me actually answer that initially adam and you can you can jump in if you want that's been one of our biggest surprises and one of our biggest challenges quite honestly is the number of hackers out there who for whatever reason uh are interested in you know coming into our network and trying to destroy our phones. So we have lost a handful of them over the process.

Yeah, but fortunately, we've got really strong developers on our side, and as those vulnerabilities are identified within our platform, we've been able to clean those up. So we haven't had any issues in quite some time. But early on, while we were in the early stages of beta, that was a challenge. I feel as if that's just incredibly rewarding experience. I mean, this is a little bit off topic,

but the fact that you've hardened your system to protect against that just sounds immensely valuable, especially today when you're hearing about all of these crazy zero-day exploits and things like that. Yeah, it's not only rewarding, but it's also necessary. You know, early on, we were a bit concerned that how big of an issue was this going to be, but we're very confident we have it under control now and know that we know what we're doing and can secure the devices of both ours and our clients as well. Got you. So, how do they, like can two people share? So if I have a set of tests and I want to run it on a bunch of devices, like how do you sort of streamline that so that I'm not having to go and treat each talking on the manual side, you essentially, when you go into Kobotan, you have the ability to reserve a device and set a device.

Or you can even schedule that you want access to a device at XYZ time, and then you get access. So definitely on the manual side, it is more of a one time. I'm using a device at one given time. Unless you had on-prem type devices and then you could have multiple instances of Kobotan up and running and testing through multiple devices. Since it is just through the web, you would have the ability to pull up

multiple and test through multiple at the same time. On the automation side is we're very heavily integrated with Appium functionality. So you have the ability to go into Kobotan and get all of your device-specific information and pretty much your language of choice, your flavor, depending on what you're coding in, Java, Ruby, Python, C++, whatever it might be. And we give you the code that you need to put into your your appium scripts so that way it knows what devices to test on so then you can go and especially if it was devices

that you have all you need to do is put that into your appium scripts kick off your tests and it knows how to connect and talk to the device uh within kobiton to get your information and you know to get your screenshots and logs and all that kind of stuff. So we definitely built it with test automation in mind because we knew that that was going to be one of the really big rewarding features for this. Because one of the things that I've seen in my years of testing, and I've got a good example of this, is I used to work for a really large marketing company here in Atlanta. And we were in the process of testing an app that the CEO of the company wanted to roll out, essentially a Christmas app that was just going to thank all of our customers for,

you know, being good customers and all this kind of fun stuff. And I was doing the testing on the app. And what we found was, is when we loaded the app and we were using one of the more popular virtualization software, is none of the images would load in the app. And having to go and then face the CEO and say, hey, by the way, this app that you really wanted on Christmas, it's Christmas Eve right now and it's completely not working. Oh, geez. Sorry.

So I went and had that conversation. It was very painful. Then the developer and I, and then the developer was like, hey, I wonder, and pulled it up on his device. And it was working on his physical device. and what we found was there was actually a bug that was ongoing in the virtualized software that was causing images to not load oh so in the simulator itself exactly right because when you think about you know what are simulators it's essentially you know software that helps you test your software so So when you think about it,

is you're relying on someone to test your test suite, or, you know, test your test software. And when you've got that, you've got that larger potential for errors. And I've seen this several times throughout my career is where the virtualized software will cause artificial errors. So anytime you have the ability to test on that physical device, it greatly increases the, you know, the proper feedback you're going to get for what your users are going to see. Gotcha. That makes sense. So, so over the years of people kind of moved more towards testing on, on hardware devices and kind of abandoned, I know, uh, a while I built an app a long time ago. Um, and the, at time, the Android emulator was just so slow. It was just completely unusable.

It was almost just a joke. I guess it was mainly for people testing hardware or something. And so what is kind of the state of the whole emulator simulator scene now? Is it usable at all? Is it starting to eclipse testing on real hardware? Is it like kind of where is that? You know, I think from what I've seen and we're talking with a few mobile companies

is definitely in the market, virtualization is not going to ever surpass, in my opinion, testing on a true physical device. Until the virtualized software gets to a point that it actually truly runs everything that a physical device can do, everything from simulating signal strength and movement of the phone and all these various other functions that a physical device can truly do, you're always going to be relegated to having to need a physical device. And plus,

I think there's some sort of innate comfort level of I've tested this on a real device and not some sort of virtualization or, you know, headless browser or whatever it might be. You know, I have actually seen my app that I built running on a real device that is located somewhere. There's just a certain comfort level with that. Yeah, that makes sense. Also, I mean, you're never going to have a simulator that matches any one device perfectly because no one has time for that. You know what I mean? Like, there's probably one simulator for all of iOS or maybe, you know, a handful, but there's not one for every combination of hardware and OS. But in your case, you could actually do that. Yeah, we definitely could do it. And I would say that the one area where I think that when you look at virtualization is probably with testing responsive websites. So that's something that

automation does very well. You look at something like the Galen framework. I'm not sure if you're familiar with that test automation framework. So if we have any listeners out there that are struggling to test or validate responsive websites, definitely take a look at the GALEN framework, is G-A-L-E-N. It's a test automation framework specifically built to test responsive websites. Cool. Yeah. It's really cool.

It's fun that someone actually went out there and built that and is now giving it out to the community. Where I think the testing for responsive websites, the virtualized servers can definitely help with that. But when you're looking at apps, especially all the various variety of different types of apps, you're going to want a physical device. Yeah, that makes sense. What about, you know, iOS is a totally closed platform versus on web, you know, every major browser is open source, like Chrome, Firefox. I guess Internet Explorer isn't open source now that I think about it.

But they're not sort of the lion's share of the market anymore. But is that a challenge that sort of the major player, at least in the U.S., is closed source? Yeah, definitely. And this is one thing that we like to tell our developers is, you know, if you want to build an iOS app, you better pony up the money to get a Mac because trying to do it on a Windows box or trying to do it through some other way is just going to, you're just going to

be beating your head against the wall. And luckily, Apple does try to make it very easy so that they provide some software called Xcode, which allows you to, you know, get your device's ID and you can set your device and put it in developer mode. That's one of the cool things when you plug an iPhone up to your laptop, you run Xcode, and it enables options on your phone that you normally don't have, which is a new feature. Yeah. You don't get that outside of a Mac or unless you're

using our software like Kobotan where we simulate that, or where we actually run that for you. And they also provide TestFlight. Are you familiar with the TestFlight app? I bet most of the users aren't familiar with it. So you'd be the best person to give a description. Sure. Yeah, so TestFlight on iOS,

it is a great way to get a test version of your app into multiple, multiple users' hands. So TestFlight essentially is when you sign up to be an Apple developer, you're given access to the TestFlight app. And essentially you send an email out to a group of users that say that you want to do your user testing for you. And they all install TestFlight on their iPhones. And then you can send them another email with the link to the app. And then TestFlight will read that and install the app for them. So essentially, it's a way to bypass a lot of the harshness and the rigors of the iTunes or the Apple marketplace, which has very, very rigorous standards. And when it comes to bug fixing, it can definitely slow things down for you.

So it's a way to bypass that to get your app in the hands of your users to get some real testing. Okay, cool. That makes sense. So let's say you use Copiton and you've done a whole bunch of system testing and things like that, and you ship the app. What's sort of the common ways that people use to measure if, you know, maybe there's some edge case or some device configuration of yours that they didn't test? How can people be sure that the app is really working once it's out there in the wild? So from the developer side or from the tester side? From the developer side. So there's a couple of things that you can take a look at from the developer side or from the tester side? From the developer side. So there's a couple of things that you can take a look at from the developer side.

And this is, I think, back to one of your earlier questions of what's the big marketplace and validated in the marketplace for both iOS and Android, you have to be rock solid that the app that you're putting out there is relatively bug and defect free. And the reason for this is you only get one chance to make a really good impression. I think the last study I saw said that only 60% of users would re-download an app after seeing a critical issue. Oh, wow. And that's a steep drop. And then if it came to the third time, I think it was only like 12%. So that is a huge drop-off. So the big change that even having to take a step back

before you release it to say, okay, I truly know how my users are going to use this app. I need to know what they are. I need to know what devices they're using. I need to know how they're going to use it. So you're going to have to have a very rigorous test plan and test strategy before you even go to the marketplace. Because once you get there and once you release your app, there's really only a couple ways to get feedback. First is you can sign up for crash reports

through both iOS and Android when you join their developer networks. And you can see if there's a hard crash in your app. Now, that's both good and bad if you're getting a lot of those and obviously you have a lot of unhappy customers. Right. Well, you won't have them for long, right?

You're only going to have 12% of them in a couple of days. Exactly right. One of the things we also like to say is reviews are forever, especially on the internet. That's true. Podcast reviews, too. That's true. Isn't the same for podcasts as well? Yep, definitely.

Yeah, so I'm sure you guys know. I mean, if you have a really terrible podcast and it tanks your reviews, even if you've got 20 great ones after that, if someone comes to look and they see that you've only got two stars or three stars, they're probably going to bypass you. And it's the same with an app as well. If you release a version that has bad feedback, probably the first place you're going to hear about it is through the reviews itself. You're not necessarily, unless you're running a hybrid app, and we can touch on that here in a little bit, you're not really going to get that feedback

because your app is locked within that native phone, that native OS. So it's hard to get a lot of feedback unless you've done a lot of communication with back to the server. And then that's, like I was saying before,

a little bit more of a hybrid app design. Yeah, and the other thing is the reviews follow you around as well. Like your account is tied to some type of credit card or personally identifiable information. So you can't just make a new account very easily. And you can make a new app, but your app is going to be tied to your other apps. And so yeah, I mean, there's really no going back. If you make a huge blunder, it's very hard to correct for that. That is a great point.

Cool. So I guess it sounds like we covered a lot of this, but it sounds like the way to make sure that apps work the same on everyone's device, or at least we can't do that, but on 99% of your market users' devices, is to get some idea of your market and do a bit of market research to try and intuit what sort of devices you should be expecting. And then to make sure that you've tested on at least one of all of those devices. And for many of us, we don't have, you know, a rack full of Android phones. So that's where sort of I think Kobotron kind of comes in, right? Josh, you want to take that one? Yeah, yeah, absolutely. That's dead on. If you do have devices and you want to share them, Cobyton can help you with that.

But moreover, for those who can't afford to own their own devices and need a laundry list of devices that they can get access to in a very affordable way. That's exactly what Kobiton's there for. One quick kind of interjection. What about like different geographies? So in other words, I know you said different carriers can make some phones act differently. What about, for example, you know, if someone's in a place where they only have 2G cell, for example, they're going to have very different experience. Like, do you have a way to sort of, you know, put devices in these sort of synthetic environments where you have really poor internet or you have, I don't know, whatever other kind of geological infrastructure issues? Yeah, Adam, why don't you answer that? Sure. Yeah. So there's some neat

things you can do with some of your test frameworks to simulate some of that. In fact, I was watching one of the latest Appium presentations a little while back, and they were saying that they had some abilities to where you could simulate, you could take a phone and downgrade it from, you know, 4G to 3G, 2G, and,G, and mess around with some of the settings there. One of the cool things I think a lot of folks don't realize is that both Android and iPhones can be set in a developer mode. The Android one is probably my favorite, is where you actually go to your settings

and you pull up the build name and you tap on the build name seven times, almost as if you're going to enter in a contra code or something. Yeah, I know. This looks like how you tap on the build name seven times almost as if you're going to enter enter the contra code or something yeah I know this looks like like how you get on the train at Harry Potter or something exactly right you have to stand on your head and but for real if you tap on it seven times you'll get a notification on your phone that says hey you're you're trying you're trying to enable developer options are you sure you want to do this and when

you do gives you some pretty awesome options. You know, some of those you can really tweak with the phone, you know, hint, hint, you know, jailbreak and root your phones. I don't recommend trying that. But, you know, there's cool things you can do where you can really, you know, mess with a lot of the phone settings that you don't normally have access to. You know, one of those as well is pretty cool.

You actually, once you do that, you can then enable USB debugging on your Android phone and then plug your Android phone into your laptop. And through just a basic terminal, you can really, really hack into your phone and do a lot of awesome things on that. Yeah, actually, I had to do this, But I was completely blind following directions. I bought a tablet. This is the same tablet. I bought it from AliExpress, which is this website where you can get things kind of drop shipped from China. And it came with a bunch of Chinese spyware. This true story. I mean, it came pre installed the add-ups and a couple other Chinese spyware

and so yeah I had to do all of these things to to sort of clean it and yeah it's true you feel like you're some kind of crazy wizard I mean Google is like sending you little little you know prompts at the bottom like almost there almost there, keep tapping the button. Yeah, it's a real weird thing. And one of the things we do from the Kobotan is when you're testing on the device, you get full access to use that device and the features. So if you've got a specific requirement where you need to install something, for instance, that will help spoof where your maps location is, which I've seen some folks do, you have the ability to install something, for instance, that will help spoof where your maps location is, which I've seen some folks do.

You know, you have the ability to install whatever APKs you need to install, or, you know, we support the multi-touch gestures and, you know, the rapid touch and some pretty cool things. So, you know, we definitely, you know, like I said before, is where we built that with a lot of the test automation in mind, you know, support a lot of those types of features.

So, you know, some of it is, you know, especially for a lot of the newer listeners who are just getting into this is, you know, definitely take the time and research a lot about the mobile device that you're testing and developing on. It's not like the PC, you know, where things are relatively locked down, especially if you're on Windows and Mac, where you really just have access to a browser and maybe you can install Firebug or something to see the request and response coming back. Mobile is a lot richer. And I think that may be even why some folks are drawn to develop and test on it, because

you can do some pretty awesome things on mobile and IoT devices that you just really don't have the capability to do on desktop. Yeah, it's true. And even on the design side, you can kind of cheat on web. Almost everyone has fixed column websites where the website is 800 pixels wide and they just get margins. And because of that, they can design a very specific experience or maybe more than 800 pixels, maybe let's say 1000 pixels. They can design a very specific experience or maybe more than 800 pixels maybe let's say a thousand pixels they can design a very specific experience but for mobile you don't really have that luxury because the form factor is very different and so you also need to make sure that you know the buttons don't run off the edge of the screen or something something wonky like that

or maybe just doesn't doesn't look good it looks too crowded yeah you're exactly right you know one of the things that i always like to hear folks say is, okay, you know, we've got this mobile device and let's just test on various screen sizes. And we always like to ask the questions, are we talking screen size or are we talking pixel density or are we talking, you know, orientation or resolution? Because all that now matters, whereas before it didn't

because you can have an app and it shows great on this level of pixel density but then you go to one of these super hot samsung phones that you know hot no pun intended um that uh you know have this awesome pixel density and suddenly your app is three-fourths the size on this nice samsung phone that it was on this other older phone. So there's a lot more, you're right, to take into consideration when you do your development. Yeah, that makes sense.

Cool. So who created Copiton? What's the inspiration for the company? I know you said it started as kind of an offshoot um so kind of talk about uh you know your experience that inspired you to want to sort of make another uh represent this as a whole another company as a whole separate effort yeah so um yeah as i mentioned i'm i'm one of the founders of kms technology and we work with i think it's around 30 different software product companies now where they ask us to help them build out and support their software, which often includes mobile.

And one consistent problem that we kept experiencing with these customers was how to have access to the right types and the right number of mobile devices. And as we talked with our customer base, what we consistently heard is that there are products out there, there are platforms out there that make many different types of mobile devices available, but they're prohibitively expensive. And they just couldn't afford to buy the software. On the flip side, they'd say, we've tried emulators, but emulators aren't really the real thing. So what they end up doing is, you know, some of our customers literally have 100 devices sitting in Ziploc baggies with their chargers in a drawer with a piece of paper, you know, and next to it, people checking in and checking out devices. And you never know what devices are charged, what operating system they're running, whether they've been swiped clean or not, who's really checked them out.

Sometimes they walk off mysteriously. And so that was just inspiration for us to go solve that problem for our customers. And it's been embraced by all of them. So we're very, we're very excited to see their enthusiasm level. And, and as we've done market research throughout the way and done a lot of product market fit, we've also realized that there's a great need in the indie development world as well with people building apps and, you know, building responsive websites and such so whether it be for you know for an indie developer or for you know fortune 500 company we

think there's need across all those markets cool yeah that makes sense i mean i think um people have tried to do kind of this kind of idea like there was um there was a company uh i think it was on stage i think there's a company where they would have an xbox sitting out you know in the desert somewhere and you would just be able to play xbox games from any kind of thin client and so this idea of sort of moving the hardware like locating the, co-locating a bunch of people's hardware in one place, you know, it's, that idea has shown kind of promise to different degrees and different verticals. But yeah, I don't think I've seen yet a company like yours, which, which, which is kind of focused on testing and focused on having just banks of real hardware that people can kind of, you know, withdraw for certain periods of time.

Yeah. No, no, there's proven models in other areas out there where you can leverage, whether it be crowdsourced hardware or, you know, hardware on demand. I mean, heck, look at Amazon with the business that they've built with their server farms. And this is just another flavor of what they're doing. Yeah, exactly. I think focusing on testing is really interesting because that's where you need just a little bit of time on many, many devices, as opposed to something else where you might need just a lot of time on one device where

it would make more sense to just buy one. But in this case, you're not going to buy 100 devices if you're only going to use each one for, let's say, five minutes a day. Right. Yeah, exactly. And one of the things, Jason, that we've seen, at least in my career, is I used to run a team. We had about 40 or so testers. And I would say about 30% of their time when it came to the mobile testing was spent either tracking the phone down or what you find is in that full QA process, when you go through and you're testing on the app with this phone is, okay, great. I found a bug. Now what? Okay. I'm going to grab my other personal phone that has my corporate email take a picture of the the defect on the phone email it to myself and then log it in the

bug tracking software so you've got this massive overhead right when it comes to mobile testing that you don't have with web testing but if you can take those mobile devices and show them in a browser that helps you take the screenshots, that gives you all the logs that you need, that shows you the steps that you perform to get that actual bug, it cuts a lot of that overhead down. So not only is it easier to find the device, but your testing overall is a lot more simplified,

and you can actually have your testers focus on testing, which I think is the ultimate goal of any organization is to cut down the paperwork and the overhead and to truly focus on the testing, which I think is the ultimate goal of any organization is to cut down the paperwork and the overhead and to truly focus on the testing and getting that rapid feedback back to the developers. Yeah, that totally makes sense. Very cool. So we asked this of everybody, what's the best part about working at Kobiton and are you guys hiring? So I'll go first. I think the best part about working at Kobiton is we are tackling a very big problem in a massive space. And while there are some companies out there who have attempted to solve this problem. It's such a big space, they haven't hardly touched it. And, you know, what's also nice is that we have the backing of a very stable and large company

in KMS. So you kind of get the best of both worlds in that you're with this very entrepreneurial startup, you know, doing some very innovative and fun things. But we also have the backdrop of having a very financially stable business in KMS that's funding it and supporting it. It has a lab of 30 customers that we're able to work with on a day-to-day basis and get their feedback and insights as well. In terms of hiring, interestingly enough, we're looking for a CEO. Our business model in spinning these startups out is KMS is very good at building software. We know

how to build commercial grade, bulletproof, world-class software. What we've realized we're not quite as good at is building out the sales and marketing machine behind a software product company. So what we've done in the past with other companies like Kobiton that we've been fortunate to be successful with is we'll build out the platform and the technology. We'll ensure we have early adopters on board. We'll get a core customer base on board and then go out and look for a CEO to help us run the company,

ultimately raise money from some strategic investors, whether they be angels, VCs, strategics, whatever the case may be, and then grow the company from there. Once we have that CEO in place, then we'll build out more on the sales and marketing side initially, and then supplement the engineering in addition to what we have today. Gotcha. How do you, I'm just curious, how do you find a CEO? I mean, usually when we ask this question, the answer we get is, yeah, if you're straight out of college, you know, come check it out. But in this case, I mean, that, that's like a really cool and very different answer. And I just,

it just totally piques my fascination. Like, like, is there, is there like a CEO registry? Like you find people who said, yes, I'm ready to VC. Like, how does that even work? Yeah, I mean, it's a great question. And what I will tell you is we actually do have some of those kids out of college already working with us. So we've gone after and gotten just some great raw talent to help us grow the business. But ultimately, you know, you think about the best technology companies or best companies in the world. And it requires somebody who knows what the heck they're doing. So with our first company, the company was called QA Symphony, we attempted to find somebody on our own and ultimately were unsuccessful and ended up hiring

a recruiting firm to help us find somebody. This time around, because of the success of QA Symphony and the personal brand that I've been fortunate enough to build and the brand that KMS has built, because we're behind QA Symphony, and because of just the incessant networking that I've been doing over the past eight years, I've built out a broad network of people that I can tap into who are, uh, you know, whether they be other business leaders or, uh, friends or, um, investors in Atlanta or throughout the U S that I'm, uh, you know, what we do is we begin messaging to people well before we're looking for the CEO and start getting on their radar. And then on a monthly basis,

we'll share information about our progress and where we're headed and, you know, begin letting people know that we're looking for somebody to come in and help run the business. And through that process, they see the traction we're getting, the success we're having, and they become more educated, more aware of the business such that if they have a friend or a colleague, they're like, wow, these guys are doing it again, like they did with QA Symphony. This is a hot company. Let me, you know, let me get somebody connected with them to help them out because they've been good to me and they're good guys. And it'll be good for that potential CEO as well. Yeah, that makes sense. Actually, it's an excellent point. I think one thing that

maybe we don't talk about enough on the show is the idea of really trying to get out and network. Even for example, if you're really into, let's say you've really dove into the Linux kernel and you're a college student and you found some issue or you want to support your dot matrix printer from your childhood, because you think that'd be super fun. And you have that plugged in, and you're trying to make that work. Along the way, just talk to a lot of people, you know, post on the Debian mailing list or the kernel mailing list. And just always, no matter what you're doing, try to find sort of, you know, ideally an audience of people who are interested, but also just a set of peers.

And it's good for sort of building your, you know, momentum and keeping it fun and exciting. And also, as we just talked about it, it could end up becoming those professional relationships years down the road that are really important. Yeah, yeah. And I can't, I'll let Adam talk to it from a more technical perspective. But I can't stress enough how important that is. You know, in life, as you build out your career, building goodwill with people, doing the right thing, building out a network, you know, reconnecting people with other people, always looking out for as you build out your network and you're in dialogue with friends, colleagues, people you may never have met and understanding

what their needs are and how you can help in making that extra effort to help them. When you need help someday, they're going to help you out. And you don't do it because you know that you're going to be asking for something in the future. You purely do it because it's the right thing to do. And I firmly believe in karma and what goes around comes around. So as we go out and we try to build out not just a CEO, but an entire management team, which will include, you know, people that we're good guys versus going out and just randomly getting resumes off the street. You just eliminate a lot of risk, a lot of headache, and a lot of cost. It allows you to scale your business more quickly. By the way, when you go to bed at night, you feel better about yourself too.

So true. Yeah, that makes sense i mean yeah oh go ahead oh i was saying yeah so you know josh brings up a great point and in fact this is for for those of those listening this is how appium actually came to be is there was just a guy who was doing some test automation and found there was a weakness in mobile app testing and went and forked out the Selenium and started working on some of his own work and started talking about it to a few folks. And slowly but surely, it started gaining a lot of traction. And now it is the most widely used mobile app test automation framework in the world.

And so it started as a small idea that a guy decided to share out so you know one of the things that he likes to talk about and it's so true is if you have ideas especially in the development because most likely there's someone who's having that same problem that needs you know your support and your thoughts and you can put your heads together and probably come up with a really really good good solution. Yeah, totally. I mean, I feel like I bring this up way too often, but I always am really interested in these like economic thought experiments. And the one I like the most is the prisoner's dilemma. And, you know, if you study this, you find that the prisoner's dilemma is basically there are two people. And if they work together, they each get a decent, you know, reward. They each get a decent,

let's say, paycheck. If one person takes advantage of the other, they each get a decent, you know, reward. They each get a decent, let's say, paycheck. If one person takes advantage of the other, that person gets a huge reward. But if they both try and take advantage of each other at the same time, no one gets anything. And if you just do one round of this, you know, mathematicians and economists have kind of proven that you should be selfish. Like if you only have one shot at this, then you should just try and take advantage of the other person. And mathematically, that's going to work out the best. But if you, if you have this repeated, they call it the iterated prisoner's dilemma, where you're just always finding yourself in this position where, you know, helping someone else will, will cause you to not do as well but still pretty pretty good

but you're kind of depending on each other if you kind of keep doing this then what your strategy should be is to look at what the other person is doing and if that person is helping then you should help that person and if that person has a reputation for not helping, then you shouldn't help that person. something greater because, uh, that gets kind of your kind of reputation going and it can kind of, um, cause other people around you to sacrifice themselves for you when, when you really need something. Couldn't agree more. Cool. Thank you so much for, for coming on the show. It was super interesting. Um, one of these days I really want to, uh, take to take another crack at making apps. And these kind of resources are extremely useful. I know the app that I made a long time ago, there's no way it works today.

And so, you know, it wasn't built in a very robust way. And so I'm going to have some redemption next time thanks to kobaton and these other technologies nice we'll leave you some good reviews on it though all right cool yeah i appreciate i need i need salvation from the last app so cool all right uh um for uh coming on the show and thank you guys actually do you have so you have kobaton and uh I guess it's kobotan.com is the website. Yes. And if people want to reach out to you, there's like a mail-to in the website or something like that? Absolutely, yes.

Okay, cool. So we'll put a link in the show notes. And if you have any questions about how to test your app, you can go to that link, and there'll be tons of information. There'll be a way to contact Adam and Josh and all of that. All right. Thanks, guys. Cool. Thanks, guys.

All right. Thanks, everyone. The intro music is Axo by Binar Pilot. Programming Throwdown is distributed under a Creative Commons Attribution Share Alike 2.0 license. You're free to share copy distribute transmit the work to remix adapt the work but you must provide attribution to Patrick and I and share alike in kind