Ep. #946 - SDLC: Testing

Matt DeCoursey 00:00
And we’re back! Back for another episode of Startup Hustle. Matt DeCoursey here with Matt Watson. Hi, Matt.

Matt Watson 00:06
Testing, testing, 123. Testing, testing.

Matt DeCoursey 00:09
Testing, testing, testing.

Matt Watson 00:14
Wait, is anybody there?

Matt DeCoursey 00:16
Are we doing different kinds of testing? Because you’re not a 1-2-3 in mind. Just said testing.

Matt Watson 00:21
Yeah, mine was an integration test.

Matt DeCoursey 00:25
Testing, testing, testing, testing, testing, that was a load test. Anyway, here we are for another exciting installment of our foray into the software development lifecycle. Today’s episode of Startup Hustle is powered by FullScale.io. Hiring software developers is difficult. Full Scale can help you build a software team quickly and affordably. And has the platform to help you manage the team and help you find the people, process, and platform. That’s what we’re all about at Full Scale. And, you know, we got a lot of testers. We know this, yeah, a lot of tests of strength. Like most of our testers have at least 10 years of experience, that’s a lot.

Matt Watson 01:12
There are a lot of different kinds of testing, and I am excited to talk about it. You know, and that’s what we’re gonna get into.

Matt DeCoursey 01:15
So you know, as mentioned, we’re back for another installment. This is the sixth episode in our series about the software development lifecycle. If you want a quick way to get to the whole series, there’s a link in the show notes that’ll give you a directory of all the different shows. You can go there and check them out. But we’ve been publishing these every Friday. So if you looked back a week ago, you’d have another episode. So, here we are. We just talked about software development. A key part of the software development cycle, or at least doing it correctly, launching quality stuff, and not driving yourself or your users crazy, is testing. So, Matt, what is testing when you think about it?

Matt Watson 02:03
Well, you know, developers like to write code. Just like, you know, I always give examples of remodeling my house, right? I got these guys remodeling my house. But you know what, somebody’s got to review their work and make sure they did it the right way. I mean, it’s like everything in life. You know, if you’re doing the work, you don’t necessarily like to step back and take a look at it and make sure it lines up the right way. Is it straight? Is it plumbed? Does it turn on? Does it turn off? Does it work? Is it designed for the right user that’s going to use this thing, like all the scenarios, right? When you’re testing, when you’re writing code yourself, you usually focus on the happy path, you know. You don’t focus on all the scenarios and needs. And it comes back behind you, and like, try to break it to make sure it really works.

Matt DeCoursey 02:48
Over there, you know, having such heavy involvement with so many different startup founders and software leaders and companies and entrepreneurs. Oftentimes, I get asked a question that quite honestly shows inexperience when I hear it. And sometimes, when people say, well, shouldn’t the software developer be testing their own stuff? Yes, but to a limited degree, like you get. So like Matt was saying, they get so close to it, and they do stuff, it helps have another set of eyes on it. And then the whole act of running tests and doing that, it takes a special personality to do it. Man, you have to have someone that wants to do the same thing. 100 times in a row looking to break at once?

Matt Watson 03:30
Well, what really matters is the type of application you’re trying to test. You’re trying to test. So think about Tesla and their self-driving cars. How do you test a self-driving car? Right, you would have to build software to like replay, you know, dynamically, all these driving all these miles driving all these scenarios, you’d have to automate all of it. Like it’s not a manual testing kind of thing, right? How do you manually test a self-driving car? So it really depends on the type of application that you’re building? What type of testing do you have to do? Why is it so early?

Matt DeCoursey 04:04
Why is it important to find and fix these things early in the process map?

Matt Watson 04:11
Well, so you can build on top of them. So I’m a huge fan of automated testing. You know, manual testing is good. And we need manual testing for things. But the more you can automate, the better because inevitably, in software, you get this project or feature request, or whatever you got to do. And you’re like, oh, just add this checkbox somewhere, make this thing changes database, column, whatever, and you just do it. And if you just throw it out there, how do you know that you know, the switch or lever you just pull didn’t break like a whole bunch of other things that you’re not aware of? And so if you have a big battery of automated tests, you’re like, hey, I made this little change. I push my code out there. Now all the automated tests are gonna run, and I will know in a few minutes if I broke anything or not, right. It’s like, it allows you to move quicker with more confidence because you have this automated testing battery, just like Tesla if they want to change the self Driving and they’re like, oh, we need to make it. Look at red lights or green lights now or do a better job with YIELD signs or stop signs. We added some new features with that. Now they could replay like millions of billions of driving hours and figure out, oh, when would we have gotten in a wreck now that we wouldn’t have before? Whatever, right? Like they can reply to all that shit? And quickly figure out, like, did this work or not work? Is it better? Is it worse what happened?

Matt DeCoursey 05:21
Let’s not get the testing cart too far before the horse, though, cuz until you want to automate something, you have to first do it manually and understand what it is you need to test. Now I have a simple rule for this, then it’s kind of some you know, something I learned as we are building Giga book is even if you don’t have a QA tester you and you’re like doing it yourself or something like that, you need to figure out like every software application has a very, very, very small handful of vital things that you should always test. And we’ll just use Giga buck as an example. It’s just an appointment booking platform. Like if you can’t make an appointment, it’s broken, like the whole fucking platform broke. Like if your appointment platform can’t get out of business. Yeah, so you have to have this list of, like, it’s almost like the commandments. You know, it’s like, if these things are broken or don’t work, we have no business working on anything else until they’re fixed. And so what those are for your software platform now or in the future, I don’t know. But regardless of having a tester at all, start to establish that stuff early and create a culture within your development team and operation that looks for the vital things and keeps it basic. Because, like I mentioned, like in an appointment booking platform, if you couldn’t schedule an appointment, there’s no point in working on invoicing and rescheduling and syncing to Google and a bunch of other crap. Because the main thing didn’t work. So you know, those are things, and you can very easily have an understanding of the true yeses and no’s of it. And then there’s a flip side of this. So when it comes to testing as well, it’s really, really easy, especially for early software products, for you to create a rat’s nest and like basically break things. And you gotta ask yourself, what anybody actually follows the path to breaking this in real life? Like it’s a very illogical set of steps or sequences that result in an issue, and is that urgent or just something weird?

Matt Watson 07:26
Like they went to schedule an appointment, but they put in Chinese characters instead of ASCII, you know, Latin base characters?

Matt DeCoursey 07:33
Well, yeah. And below when you talk about catching things early, though, those little things are hard to catch, like little special characters, or just weird shit that your database rejects or something like that. And, you know, now, is that commonplace? Like, will it affect your real users? If you aren’t servicing clients in China, then I wouldn’t put the entry of Chinese characters. Yeah, it’s an issue. Yeah. Yeah. So now, there are a whole lot of different types of testing. And they often refer to these as modules. And, you know, depending on the strategies that get developed by you, or your QA testers, or leaders, like there’s a whole lot, I mean, and I’m, you know, we’re going to talk about these real quick and kind of roll through them. It’s there, you know, but you have unit testing, integration, testing, system testing, load testing, security, testing, performance testing, automated testing, usability testing, and mobile testing.

Matt Watson 08:30
What do we get? It’s different stuff, man, a lot of different stuff.

Matt DeCoursey 08:34
And it lays through this?

Matt Watson 08:36
Well, I think, first of all, it sets the stage. It’s really important to understand the type of application that you have. And one of the examples I always give, right, if I was writing software that flew an airplane, it would be totally different than if I made this little database that two of my employees logged into, and if the thing was down, it wouldn’t even impact our business, it would be no big deal because it logged like people’s vacation time or some shit like that really was not business critical. But making an airplane fly out of the, you know, crash and kill people is a pretty big deal. Right? So depending on the type of software that you build, the type of testing that you have to do is totally different and not one size fits all.

Matt DeCoursey 09:16
Yeah, so well. A good example is if you don’t have a mobile app, or you’re concerned about mobile, then mobile tests. Yeah.

Matt Watson 09:23
But if you were, if you were tick-tocking, mobile would be like everything, right? Like you will live and die by it.

Matt DeCoursey 09:29
Yeah. And now one thing, though, don’t take my comments like don’t take a mobile test, because, in the modern world, more people are probably going to use it on their phone than a desktop computer.

Matt Watson 09:39
But every app is different. Like it’s Dakka. Fi, like 90 Something percent of our users are on a desktop. You know, it’s all different.

Matt DeCoursey 09:46
Unit testing is the one at the top of the list that is often a developer kind of thing to you talk about for a second.

Matt Watson 09:55
Yeah, so unit testing can be very helpful for developers. They can also overdo it. So it makes no sense to build a unit test for like every line of code in your app. I always joke like, if you’re doing that, you should just use a programming language that compiles, like people use the scripting languages like

Matt DeCoursey 10:09
English, Math, and English to people that are, like me that are dumb.

Matt Watson 10:14
So unit tests are testing like, basically an individual method of code like, you know, I give it these parameters, and it runs something and either works or doesn’t, it gives us the output. And a good example of that would be like validating a credit card number. Is it 16 digits?

Matt DeCoursey 10:30
Setting the appointment? It could be, it could be even something simpler than that.

Matt Watson 10:33
But yeah, it could be. So usually, it’s something like a really simple thing like validating a credit card number, a good example. And you basically do a bunch of these different kinds of tests. And they’re really great for testing weird, funky business logic and things like that. And so it makes it easy. They’re nice, because they kind of helped validate business rules. So like, whatever kind of weird business rules that you have, if you could put in those unit tests, I’d be great. So for example, Gigabook, you might be like, Oh, the deposit must be more than $10, or something like that. So it also may pass in less than 10, it would throw an error or whatever.

Matt DeCoursey 11:12
And you would, you know, write tests to validate that we’re like, whatever kind of business rules
could also be checking things like making sure you don’t do double booking, you know, like, right logic, or just looking for zeros and ones and making sure that they’re reacting properly. And these are the things to them by the installation of this and the automation of it, you can really begin to you won’t have to go through that commandments less, like I mentioned, like some simple unit testing, you can make developers feel better. I mean, overall, my goal when managing a team is I want developers to keep developing testers to keep testing salespeople to keep selling, you get you get it, right. Yeah, and you know, these are the things that kind of help do that. Alright, so let’s move down the list integration testing, that’s exactly like it sounds, this is an important thing, because so many people’s apps that they’re building, whether they’re web or mobile, or whatever, integrated with other platforms, and if those connections are broken, or really hard, or unreliable, or they’re doing goofy stuff, like, you know, an example is with gega book and connecting to other calendars or Google like, that’s actually pretty complex, because there’s a lot you like, who wants what info and you know, like, some people want a lot, some people don’t. And then you know, here’s the thing is you’re gonna ruin someone’s day and your chance of keeping them as a client, if you do something like mess up their calendar.

Matt Watson 12:28
Yeah, a great example of that, right would be like, I need to create a calendar entry with, you know, a Google Calendar. So I’d write some code that calls the API and calls that. And then the test, I would call the API again, it makes sure that it is really created and it’s really there. And all the fields are what I thought they would be: the dates, the right date, the right time, and all that stuff. And now would validate that I can call their API and it works as expected. And yeah, depending on the type of software, integration tests are really critical. We did a lot of these at stack five because we had so many integrations with things, the integration tests were critical because if somebody like Google just changes something, and might break everything that you do, it’s really important. So those types of integration tests are really, really key. And like you talked earlier about the happy path, right, like the happy path, at Giga book, like being able to schedule a calendar entry with Google would be like, a really fundamental thing that has to work, you would want to test every time.

Matt DeCoursey 13:23
So I have a test for you. Can you explain system testing in less than 30 seconds?

Matt Watson 13:30
Ah, you know, I honestly don’t know what the definition of this is, unless they describe.

Matt DeCoursey 13:38
I know, like Linux or Windows?

Matt Watson 13:41
Maybe? I don’t know. All right.

Matt DeCoursey 13:44
So all right. Well, you failed the test. But yeah, good part. So we get to move on. So load testing is one that comes up. Hey, look, I’ve talked about this a lot in the past when it comes to planning and just all of it so many people plan for rainy days. And they were like, Hey, we’re trying to do everything we can to not run out of money. We talked about happiness and sadness. What happens if everything goes right, you know, and low testing is a big thing that you hear about when you hear the term scalable. And load testing is just going to put a lot of pressure on what you’re doing. So it’ll show weird little things. Like in the past, when load testing Gigabook, we uncovered a lot of inefficiencies, like looking for one exact spot in the database, but it’s a query and the entire thing. So when you get a bunch of users in there doing the same thing, it puts undue and unnecessary pressure and slows everything down. You know, and that’s, and until you it’s kind of like filling something up with water to see if it has leaks in it, and it does or it doesn’t and till you do that, it’s kind of hard to see a pinhole leak.

Matt Watson 14:50
Yeah, it’s terrifying. We had things with processes and millions of transactions an hour, right? And so if you know you’re gonna have that kind of volume, you always gotta test for performance. Make sure that database As can handle it, we got Azure configured the right way AWS right way doesn’t scale like, can I handle the load?

Matt DeCoursey 15:06
And I’m gonna put that in the same ballpark as performance testing? No,

Matt Watson 15:11
I would, I would say it’s something totally different. So here, load testing is about load. But performance testing could be as simple as, you know, what, I’m trying to optimize the battery life of this phone. And so I need my code to use as few CPU cycles as possible. Now, it makes sense, like, in a high load, that would make sense, but think about it from like one cell phone, it’s not about the load on your cell phone doing billions of transactions, it’s about battery life, or how do I optimize my code to use like less nanoseconds, so that later under load testing, it’ll perform better? It will, you know, out there too, but it’s like micro, you know, performance optimizations, which can be used for things like battery life as an example.

Matt DeCoursey 15:52
Okay, security testing, this is a big one.

Matt Watson 15:56
Yeah, I mean, I mean, this is like, we, I talked about this at work with, with my team all the time, right? It’s like, Hey, you shouldn’t be able to login and edit the password of our CEO, and then like, log in as your CEO, and then like, tell everybody, they’re fired, like, that would be bad, right? Like, you’ve got to have the right kind of have security controls in the software for authentication, authorization, testing that like the permissions of what you can do what you can’t do, making sure that, you know, for example, at the top of the screen that says, I’m editing customer number seven, like I should be able to change it to eight, and then randomly, I’m editing something I should be able to edit. Like, it’s thinking through all the security things, and making sure that users can only do what they’re allowed to do.

Matt DeCoursey 16:36
And it’s a really unsexy part, but a highly important part of building stuff.

Matt Watson 16:42
And can you imagine if I logged into QuickBooks right now, and I could see somebody else’s account? Yeah, well, I logged into some medical software, and I could see the HIV test results of somebody else.

Matt DeCoursey 16:52
Yep. Right. Yeah. And in some things there, I mean, kind of be inconsequential, like, Yeah, I mean, I don’t know, there’s things to help with this. And, you know, we could almost do a whole nother show about this. I don’t want to get too caught up on it. Alright, you know, what I really liked Matt, is usability testing. Like, let’s actually try it. Let’s try it and see what sucks. And these are the guidelines for this. I, I’m gonna go back to Matt DeCoursey, his role on a software as this annoying? And if the answer is not no, you have work to do. And that’s part of your usability stuff. You know, like if things are annoying or clunky, or it’s just hard to figure out people won’t they won’t use it?

Matt Watson 17:38
Well, I think there’s multiple types of usability testing. You could also say, say things like accessibility. So that worked for people who use screen readers or people who are colorblind, things like that. You’ve also got things like conversion optimization, right? From a usability perspective, do we get more leads, if we move the button over here? Or change the number of calls to actions or change the colors of the button? Is it hard to use, like, like you’re saying, like, people just hate using a thing, because it’s just not intuitive, like, there’s a lot of different types of, kind of usability, accessibility, optimization, and a great example, dude.

Matt DeCoursey 18:09
example, dude. So because I’m old, my eyes don’t work the way that they do. So I have literally increased the font size, yeah, on my phone, because I was having a hard time reading it. And it really presented some usability issues with other people’s shit. And it’s just simple stuff, like the overall field size is too small. So it’ll wrap things where it shouldn’t, or it just makes things weird and funky. And at first, I was like, man, they have a user interface issue. And I was like, oh, it’s because it made the font bigger, but it’s still a user interface issue, because people are going to look different, regardless of whether that font size is tiny or big. It’s their reality, it’s what they’re looking at. So perception is often in the mind of the person perceiving it. So if it looks broken, it’s going to be embarrassing for weird reasons. So have a broad grasp of who could use it. I think your stuff should be simple to use, I think you ask yourself, Could a five year old or a 75 year old use this in a similarly useful way as I do so. Okay, so let’s look at mobile testing. That, you know, we mentioned that this, you know, it looks, if you’re building software right now that isn’t responsive to the kind of device that that person has. You’re doing it wrong, it’s 2022. People like there’s lots of framework out there that makes this a lot easier. And now with that, it can kind of feel like it slows things down. Because you essentially have to have a small, medium and large version, like the medium is like a tablet large is obviously desktop. Mobile is what it is, but don’t skip this part of the process.

Matt Watson 19:55
Well, it’s also about the verb so it’s also the version right? Like if I’m, if I’m writing software For Apple, what happens if somebody has an iPhone five verses have an iPhone 13, right? It’s like, oh, I’m writing some software that does some smart home automation. And it requires this SDK that Apple added for this smart home. Well, that didn’t exist in the iPhone five. So what if somebody downloads, it’s hard to because you have to emulate the device that it’s on, and people don’t update their devices.

Matt DeCoursey 20:16
And there’s a gazillion different devices, iOS, and you have Android and you just like, there are platforms out there. And I’m not going to plug any of them because I honestly don’t have enough use of any of them myself to recommend one. But they emulate that what it is, it’s like a, you can simulate a current version of iOS or Android or different devices, do different sizes, and you can begin to automate that stuff too. And it’ll fix it. So. And with that, I kind of moved it back to the list. Now one thing with that, and I appreciate your appreciation for automated tests, I do want to put a caveat to that. If you create automated tests, or you want to, you need to be very committed to updating them, yes. Because when you change one thing, it’s gonna break the fucking test, and you got to do it. And the thing is, is automation tests in or they are engineers, they are software developers, essentially at this point. So you have to be committed to having someone high level, there are some basic little tools and stuff like that, like, what do we use the ghost one, what was that called? Ghost, I can’t remember. There was just like a basic bot that would go and like, you know, there are some basic things that are like test unit user interfaces and stuff like that. But if you change one thing, you’re gonna break the test.

Matt Watson 21:41
Yeah. So ideally, the great thing about automated testing is it helps you move faster, like the example I gave earlier, right? Like, hey, we’re gonna do a release today. Yeah, we’re gonna do some manual testing, we also have this battery of like 500, automated tests, they’re gonna run and test all these things, which is great, and helps us move faster. Because we can do those tests very quickly. Think about if you were like Mike doing Microsoft Windows or something like how many automated tests for like a billions of scenarios you would need a lot of I take them days even to run all those automated tests. But yeah, if they move a button, or change the name of a button or something like that, it could break all the tests. And so the more you go in, you’re moving things around in your UI, and all that you break all the tests, you spend a lot of time just fixing all the damage, just know you have to be committed to keeping up with it.

Matt DeCoursey 22:20
Now, one thing that, you know, we talked about doing things quickly, finding experts, and software developers does not have to be difficult, especially when you visit FullScale.io. Or you can build a software team quickly and affordably. Use the Full Scale platform to define your technical needs, and then see what available developers, testers, and leaders are ready to join your team. FullScale.io I’m testing that right now. I’m gonna maybe do a couple different iterations of that. So you know, when we talk about, like, the roles of the tester, like, you know, a tester’s main role is to, you know, contrast the output with the requirements and identify issues and make sure that software products are behaving as defined. You know, and like, you know, some people ask, like, how long should the testing process take? That’s not easy to answer on? Yeah, but we’re still nature. Yeah, let’s talk about that.

Matt Watson 23:21
Because if when you think about the development process, right, so you run a development team, and you want to do sprints, so you want to do like, you know, work for a week or two weeks, and then you want to release that work you’ve done over a week or two weeks, or maybe even a month, or whatever it is, you have figured out like a development lifecycle, right? And the hard part is like, hey, we write code for a week. And then how long do we test it, we give the testers like a week, a day or two another week, or whatever. Because you want to try to get into this rhythm. And it all sounds great. Like, hey, we write code for a week, they test it for a week, and then we ship it to production, like That sounds great. And reality, the whole thing falls apart the first time you try and do it because nothing ever works exactly to that plan. It just, it just doesn’t, it’s very difficult to work in these exact cycles like that. Now at stack phi, we did a pretty good job. It’s like we push code to production, like every Tuesday, and we did it pretty religiously, and we were pretty good at it. But the more you also try to do QA and get all these other things in that cycle, the harder it is to adhere to that cycle. But that’s one of the big challenges of development is trying to figure out that cycle of okay, we write code for this many days. And then we know we need this many days for QA and then we’re gonna release it in this timeframe, and try to build and get really good at that assembly line. If you kind of get really good at it. It’s good, but it’s just hard. It sounds simple, but it’s hard to get in that rhythm and really stick to it.

Matt DeCoursey 24:45
I think that some of the things that help us, like I mentioned earlier is defining like those like those biblical proportion things that have to work. Yeah. And with that, you should begin to define the other F then means that they could affect so like if you let’s we’ll go back to the appointment setting thing and Giga book so Okay, so you can set an appointment, can you reschedule it? Can you attach an invoice? Does it have a reminder? Does it have a notification because if you go if especially if your your SOT your development team is growing, you can’t just assume that a software developer is going to inherently understand every single thing that could be affected by a change. So just define it. It’s like, if you work on this, if there’s a change made to this, let’s test these other things, too. Yeah. Because it’s easy, especially in the beginning to try to fix one thing and break five more now. You know, a common question is going to be what’s the most common errors, they’re probably there. They’re simple ones. I mean, that’s the easiest way to say it. Like a lot of times, it’s just dumb little stuff that probably shouldn’t need repair as you stabilize things. You know, there are a couple of different types of bugs you have functional, logical workflow and unit level bugs. What’s your favorite bug man? Because I believe I want saw, you know what, we’re going to use the picture of you and the bug costume. Yes, yes. Matt Watson has a full size suit. Did you keep that or does that belong to the company that acquired sacrificed? Now?

Matt Watson 26:18
I threw it away.

Matt DeCoursey 26:19
I’d probably shut off. I mean.

Matt Watson 26:23
I did.

Matt DeCoursey 26:24
But I have many, many, many pictures of Matt dressed like a bug. So I feel like you’re the best person here on the show. Which type of bug do you like, Matt? Because you did once build a platform that finds bugs.

Matt Watson 26:38
I like dead ones. Ah, that’s not on the list.

Matt DeCoursey 26:43
It’s the best answer.

Matt Watson 26:44
Now. The problem with writing software is, you know, you can spend hours, days, weeks trying to find the littlest needle in the haystack like a bug. And it is so frustrating. And it’s the nature of what we do, though, as developers, right? It feels like we take like three or four steps back or forward. And then we end up taking two or three steps back, like fixing bugs. And like they tested it, they found these problems.

Matt DeCoursey 27:09
That’s not necessarily doing it wrong.

Matt Watson 27:12
Yeah, it’s just part of the process. Yeah. Yeah, you know, it may. But it’s the process.

Matt DeCoursey 27:18
Well, now, I don’t want to get too far into what the different types of bugs are. You know, once again, if you need to hire software engineers, testers, or leaders, Full Scale can help Matt and Matt, and I own together. We were in the Inc 5000. This year in our first year, eligible for seven over 700% growth, I feel like we’re really helping a lot of people grow too. So definitely validated and tested there. We have the people and the platform to help you build and manage a team of experts just go to FullScale.io. And all you need to do is answer a few questions. Our platform will match you up with our fully vetted, highly experienced teams of engineers, testers, and leaders. We have a lot of testers. I have this really a strength of what we do at Full Scale. We specialize in building long-term teams that work only for you to learn more when you visit FullScale.io. Mr. Watson, what would you like to say on the way out, buddy?

Matt Watson 28:10
Um, you know, one suggestion I always give people is when you’re planning a project, you’re planning the work items in JIRA, whatever is part of that plan, just include a few simple notes about, well, how are we going to test this thing? Yeah. So when we finish this project, how are we going to test it? We need to build some automated tests. Do we test it manually? What are the conditions we’re trying to test, like new tests on mobile or usability? You know, all those things, right? Just thinking a little bit ahead, like so you’re telling the developers to like, hey, don’t forget, we’re gonna need to test this. And then the QA team knows, Hey, okay, I need to test it this way. So I think taking a little bit of time to just think about that and put those notes in the tickets, I think it helps a lot.

Matt DeCoursey 28:48
Yeah, and I think that even just like you, if you’re in an early stage, or you’re, you’re uncomfortable with like, the quality of what has been getting produced, I mean, do you have that simple list, as you can literally like here’s, it changed the results. And my sanity when building the Gigabook, when I came up with a list, I think I had 20 things on. It might not even have been that long. Like, these are the things that always have to work. If any of these things are broken, stop doing everything else we’re trying to mess around with and go fix these things. Because they’re just the basics, it’s like a vital organ. Like if your liver doesn’t work, you need to go to the doctor and get that fixed before you do anything else. Right? Because like, you know, these are and you should be able to define what those core things are like, it’s like logging in.

Matt Watson 29:40
Like, you know, just like I mean, we make money.

Matt DeCoursey 29:43
Well, that’s the thing. Yeah. Dude, it’s it. You know what, I’ll fall on the sword and mention that because, like, in the first year of Giga buck, we tried to create our own billing system, which was actually way too complex. And it sucked, and like it wasn’t right. That was like, we can’t even collect money from people. Let’s get that right. We just ended up using Zoho, which was amazing. Because for, like, 400 bucks a year, we didn’t have to mess with that part of it anymore. So you don’t always have to build everything. Sometimes you buy it before you build it or whatever. There are a lot of tools out there for testing. If you need help finding the tester, go to Full Scale, we got people that like everything from, like, that can do it at a management level and have a lot of training and can help you establish all that. And maybe you just need someone to beat up some keys and buttons, you know, got that too. So the thing is, I think that overall if you can add a tester to your software team, your developers will appreciate the backup. And I think it will, I don’t think it will, but if you get a good tester, it’ll accelerate the process. And it’s really just going to make you out if you’re a founder. I mean, dude, there’s nothing more excruciating than seeing your shit go live, and it has a bunch of bugs in it. So from a sanity perspective, to get investment.

Matt Watson 31:11
Absolutely.

Matt DeCoursey 31:13
I think we passed the test. I think we passed the test here. I’m gonna go ahead and push this show to production. I’ll see. I’ll see you next week.

Matt Watson 31:21
Ship it.