Crash course bug hunting: A primer for project managers and entrepreneurs | Evan Kimbrell | Skillshare

Crash course bug hunting: A primer for project managers and entrepreneurs

Evan Kimbrell, Director at Sprintkick

Play Speed
  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x
7 Lessons (23m)
    • 1. Welcome to the class!

      1:56
    • 2. First thing to do

      1:05
    • 3. Thoughts on bug hunting

      1:35
    • 4. Bug hunting on mobile

      4:40
    • 5. Becoming a bug hunting master

      10:59
    • 6. Accelerate your testing this way

      0:40
    • 7. Keep the learning going

      1:53

About This Class

The idea behind this class is to run through the basic skills you need to find and correct bugs. No, not the ones cowering in the corners of your bedroom (yikes), the ones cowering in the corners of your website or app code (yikes). 

A lot of people spend hours trying to find and fix every single bug when in all honesty, it's a frustrating, thankless, and never-ending endeavor. After this class you should be in the correct mindset to determine which bugs are worth fixing and which aren't. I will give you the best advice I have when it comes to figuring out which bugs matter and which bugs are often overlooked. 

Just to clarify, this class is not for developers - it's for those on the other side of the barrel - anyone who works with developers. Entrepreneurs, freelancers, project managers - especially when you're launching a project - you'll need to know what's going on in order to communicate effectively or even save time (and money) by hunting on your own. This crash course in bug hunting QA works better if you're following along with your app/website/project while listening so be sure to have it on hand.

What you'll learn:

  • How to determine which bugs are worth it and which arent
  • Bugs that people frequently miss
  • The correct mindset for happy hunting

What you'll do:

We'll toss you out in the wild (world of the Internet) so you'll get plenty of hunting practice in. Feel free to use your own project or app for this. 

Transcripts

1. Welcome to the class!: Hey, guys. I'm Evan Kimbrell, and I'm the director at Sprint Kick, which is a Web and mobile development studio based out of San Francisco, California. Now the name of this course is crash course bug hunting. The idea behind this class is to empower you, the entrepreneur, the freelancer or the project manager with some basic skills on how to find bugs and correct them. The angle of this class is towards anyone who works with a developer, anyone who is launching their own project or anyone who has to oversee their own project. This class is not necessarily from a development standpoint. It's from the standpoint of an entrepreneur has just launched their application, and they need to know where to look, to find the most bugs and to figure out which bugs are the most important and the ones they can skip over. I think this class kind of like a primer. I'm gonna introduce you to bug hunting tools, but I'm not gonna get in depth with the tools themselves. I'm gonna walk you through the mindset you need to be in to properly find all the issues and correct them over my career at Sprint kick I've built and launched probably well over 100 Web and mobile applications. And I've kind of distilled down in this class. The best advice I could give you as to what bugs matter where they are. One of the most pernicious ones and one of the ones that everybody misses. You could call this a crash course Qiwei if you wanted to, because that's essentially what it is. Alright, guys, I hope you excited to take this course buckle in. This one is a little bit of a slower paced, more audio class, but a very insightful nonetheless. All right, I'll see you guys inside. 2. First thing to do: Hey, guys, welcome back to the class. So I have an assignment for you really quickly. I want this to be the first thing you dio eso at the bottom of the skill share page. It says discussions, the clip discussions, and then you can click new post. I want you right now to go and do that and introduce yourself. You don't have to tell me a lot of information. You can just say your name or your from. But what I'd like to actually hear from you is one. What do you struggling with? And to what are you looking to get out of the class? I think this is something that helped immensely with the class. I really like to make my classes as engaging as possible. I respond to everyone, and I want to make sure that as I'm teaching, I'm meeting your goals and I know exactly what I'm trying to fix. Okay, so this is the first thing. Just go down to the bottom of the page. Do that now. Don't skip it. You can skip it if you want, but I think you'll miss out. All right. Seeing the next lecture 3. Thoughts on bug hunting: talk a little bit about bugs. You probably thinking to yourself. Well, you mean bugs. If I'm paying the developer, shouldn't they deliver me something that's perfect? I want you to know that in every single application they're going to be bugs. Nothing comes off perfect in the first version. Please don't be discouraged when there are bugs. Please do not be discouraged when you come back and you have lots of bugs. Typically, the more you pay a developer, the less bucks you're going to see. That's something you associate with a good developer. However, the best developer in the world will still have bugs. You cannot where she cannot take into consideration every single possible thing that could go wrong with your application. So be realistic if you saved a lot of money on your application when you contract it out, the chances are you're gonna make up for it with putting in a little bit of extra effort, trying to find bugs and going through some back and forth until you get your application. Perfect. The first version. To be honest, it could be quite scary. It could have a lot of issues to it. I've had projects that came out that were completely mangled. And I've had them come out where they're quite good. Just it still had bugs. Just don't be afraid. Followed my advice. Put in a little bit of effort and make sure you follow up with your developer. Once your products Perfect, you honestly won't even recognize it anymore. Since the one that they first launched when they send it to you, expect bugs to be realistic about that. 4. Bug hunting on mobile: I thought I would be worth it to talk a little bit more about the tools that you need with regards to Mobile, I still think you need some kind of a timer app to stay focused. You're also still gonna need Google docks so that you can type out all of the bugs that you run into. The difference with Mobile is that you also need mobile devices. That could be tricky, depending on what environment you built your application for. If you're trying to test for an iPhone app, the number one thing you need to dio is you need Teoh have test flight. This is something that your developer, if they are an iPhone developer, they should be more than acquainted with test flight allows you to launch applications to private parties without sending it to the APP store. When you submit an application to the APP store, it can take anywhere from two days to three weeks for it to get approved. That's insane just to get the first version out to bug tested, so you don't want to do that test flight. It's a great system for uploading small packages. You can send it to your friends and family, and everyone can download it. They can all participate in the bug hunting, and it will also help you keep track of version so you can upload a version, save it, download it, and then every time they have a new version, they could upload it. And you can always revert backwards and then download an older version if something screwed up. That's a great system. Use got bought by Apple. Great, great great past that. What I suggest using is make sure for iPhone that you have the three main resolutions. You don't need to worry about iPhone three anymore if you want to do a good job, but this should have access to at least two of them. Hopefully you have a five and you have a six. At the point of which I'm speaking right now, five is the biggest, and six is up and coming. But obviously you need 45 and six. I know a lot of people who still use fours, so if you have access to those three, it's pretty easy. You just got to do the same testing and all three and do the same kind of Pomodoro just run a test on each one. See if there's something you notice that exists on law that doesn't exist on the other. Now, if you built an android app, you don't use test flight. Just ask your developer what they prefer to use to send you development packages. Hopefully, in either case of your android or iPhone, asked them for an O. T. A. Package meaning over the air, meaning you just go to a website and download it. You don't have to dalit on your computer, then plug in your phone. It's just unnecessary. Hopefully, Developer knows how to do that. If the studio they definitely know how to do that. If you built an android app. God help you. There are so many different resolutions you need to test. Used to be that there were, you know, for five Android resolutions back when there is only one iPhone resolution, but it's really exploded. I think it's unrealistic that you're gonna test this on every single resolution. There are one website that are often referred Teoh. They listen after their 4000 distinct devices, and I don't even know how many resolutions there are. Hundreds is my guess I think with Android, it's the case that you can capture 70% of the market in probably three resolutions. I want you to keep it simple to stay realistic. It's unrealistic thinking in a test. 15 different android screens stick with the basics, and I call this the galaxy test. The Galaxies are aligned by Samsung that are very popular amongst android users. They have the most popular resolutions. So the way you do this is you would follow the resolution of the galaxy s one galaxy s one is 800 by 4 80 pixels. Use kept the s two because it's the same size as the S. One. Go to the S three. That's 12 80 by 7 20 and then ask for is 1920 by 10 80. Those are the resolutions you want to test for. So your best shot is to try to get some kind of android phone that matches hopefully two of those three. Obviously, when you build your application will ask you specifically what relies solutions you want. If they don't ask you, please tell them. And if you want to keep your costs low, pick one or two or pick three. These are three that I think and in my experience, are the best to follow. They are the most common, but they're also the most easily adaptable to other screen resolutions because they're all kind of based off of a similar grid to these. 5. Becoming a bug hunting master: a bug Testing. This is a crucial phase of the application process. Don't be afraid of bugs. Expect the bugs and embrace the bugs. There is no reason why the bug hunting process can't be fun because the more bugs you find , the more bugs you can fix. The more bugs I find, the less bugs my users will find. I like to think of bugs kind of like panning for gold. You just strike over here, you strike over there and eventually you'll find something with software. It honestly, you can't find every single bug, but you want to find the big ones. So don't neglect this. And I'm gonna give you some tips and tricks, some warm up ideas for how you confined bugs. The general idea behind how you're gonna look for all of the bugs in your mobile application of your Web application or whatever your freelancers deliver to you is just time on task. Personally, if I have a medium sized application, I will go through hour and 40 minutes of solidly hitting the website are the mobile application or whatever it is that you built, you might not be a Zo CDs. I am but I prefer I would like to see you at least hit the major areas. So the first thing I do whenever I get my application back is I start with number one. Graphics. Graphics is an easy one, and it's a It's a kind of a sore spot I've noticed in there very often. Will you find problems in the graphics department Now, when you have a developer, they most likely are not. Also the graphic designer. They most likely took design from somewhere else. If you didn't get a graphic designer and you're using a template, I still suggest you do a quick view of the graphics itself. It's not really the same cause. Templates are typically designed to look good, no matter what, and the developers not following a set designed picture. He's just using the elements that are available. Let's assume that you used a graphic designer. Maybe use 99 designs. Even you have a page that you designed for your Web application. Now look at the application that your freelancer brought up or is delivered to you in a separate window. Open up a Photoshopped file of your design if there's immediate discrepancies while There you go. Write those down. Send them to you. Your freelancer, I want you to make sure that you're using Google docks throughout this entire thing. And when you use Google docks to find a bug right next to it the time that you find the bug at Don't ask me why it helps. Later. It helps the developer. It's just worth doing. You do like a quick glance. You look at your your graphic design. You might notice something immediately after that. Once you think you've noticed all the big things looked really small, zoom into your Photoshopped file and look at the application. Chances are you'll find things that are off. There's a term we use called pixel perfect pixel. Perfect means of the application matches every single pixel of the graphic design. It's up to you if you want to be that close to the actual design, I always go for pixel perfect. There's no reason it shouldn't be the case that the developer can make it the exact same way that your graphic designer designed it. But if you want to have that strict of a guideline, it's very possible that you could end up with a lot of mismatches. Do the buttons look the exact same to the pages load correctly? Are there breaks in the line pages? Look at the wit of the website. Is it wider than it was in The graphic design is the background color match. The graphic design. These are things that are very common, and a lot of developers will try to cut corners by skipping over. It might even be the case that you can't put your finger on what exactly is wrong, but it's worth highlighting it to the freelancer and showing them. Hey, this doesn't look right, because chances are if you drill down and zoom in, you'll notice that something is often It's some detail that they missed, so graphic design is fairly intuitive. Just use your eyeballs and scan it. See if you notice anything that's off and make sure that you report it. If you don't want to stick to pixel perfect guidelines, that's up to you. But you Do you want to make sure that sticks to your graphic design because you like geographic designed to begin with. There's no reason to change it at this point. The second thing I move on to after that are forms. Chances are your application has a form somewhere in it with a non. It's a form for logging in or form for entering an account. Information. You know, whatever your application does, chances are it's gonna take input from the user. Look at those forms. These are problem areas. Every single time we build an application, try filling them out as yourself. Try filling out some honest information. See how that reacts after you do that. Trying is bouncing around the page and try to fill out all of the functionality of your application. Then go back and imagine you're someone else. We call this in software design test cases. Just imagine you're someone else. A few you signed up, but someone who is 30 years old go back and sign up someone who is 45 years old, 60 years old. Change your name. Try inserting an accent mark on top of with your name. Just try different combinations out. It doesn't make sense to you thinking about it. Probably you're not familiar with how the software process works, but the more you do this, the more likely you'll find some kind of internal error. At first, you'll notice immediately there's some issues. One of my favorite things to do with forms is enter in the maximum character limit. A lot of developers forget to add the maximum character limit, so meaning when it says say, like first name last name. What if my first name has 100 digits in it? You'd say, Why does that matter? Well, chances are someone's gonna try that there's a good likelihood that they could crash your system. So try doing that. Try entering a name that has foreigner characters in and see if the system accepts it. If it doesn't accept it, what happens? Try to break and try to be the worst user you possibly can try to enter in special characters. Inter in a percent sign or an asterisk or things that you wouldn't expect to put into your form if it asked for a digit. Try putting in a word if it asked for a word, try putting in a special character. Try to put in everything wrong that you can think of, like if it asked for state your city. It asks for your zip code. Put your state do these kind of basic things. You'll find out very quickly where the developer cut corners and things he or she might have for gotten to accommodate. For after you're done screwing around with your forms and anything that could take in information, try creating multiple counts. Try making account for a fake user, another fake user, another fake user and another fake user. Now, if your application communicates between the to try to communicate, for example, with a Sprint kick application, we had one that had messaging, And so in order to test the messaging, it wasn't sufficient for us to create one account and send a bunch of messages. We had to create hundreds of accounts with different information and then communicate back and forth. We didn't just try to communicate in single regular text. We try to communicate messages. We tried to communicate in special characters. We tried to communicate in numbers who tried to communicate in anything that could possibly break the system. You don't have to use 100 users, but you should create three or four after you've tested out the graphics, the forms, you created, a bunch of accounts and you try to do any type of interaction where these accounts communicate with each other. Hi, then typically, just move on to a phase where I try to see every single screen. Now you might have for gotten all of the screens you designed with your graphic designer or there a lot of screens you might not have even thought about. Try to find a page that doesn't exist. If you have a search bar in your application, go to the search bar and just search for all sorts of things that don't exist. See how it reacts. If your application handles images, thats a big area for potential bugs. Try upload ING files that aren't correct If it asked for a J. Peg, Senate, A, P and G. If it takes all common image files, try sending in a movie file to see what happens. Try sending a image that is way too large and one that's way too small. Honestly, you don't even need to necessarily plan it out. Just see what's on your computer. Upload it and see what happens. Chances are you'll run into something and you can keep growing your Google doc list. Now I want to stress in this lecture that there is no set plan for bug hunting. People build their entire careers off of software testing, so don't expect that you're gonna get every single one. Don't even expect that you're gonna get 80% of them. There are a lot of bugs that on Lee come out under, for instance, performance stress. You're not gonna be able to find all the bugs that happen. That could potentially happen when you have thousands of users. So don't expect Teoh, But keep in mind that these things are going to happen in the future. The point to being a good bug hunter, I think, is just spending as much time as you can with your application. Try to flip over every single stone you can without getting too excessive. You don't want to spend tens of hours messing with your application unless you have the free time to do that. And that's worth doing for you. I typically think that it's not. Try to be economical with your time, but at the same time make sure you're spending at least an hour playing with it because I think that the end you'll have a much better outcome keep in mind also that Boggs typically operate in clusters. Once you find one bug, it's not that you just found a bug. You found an entire area that you're developer hasn't thought about, So you can really kind of go after that. The mobile example. Maybe he didn't plan for how the system reacts when it's under WiFi or how it reacts when it's on the edge. Network. One year on, say, like the Edge network. Meaning you're really out there. You've a very limited connection. How did the pages of load are there? Sections are very browser heavy. If you try that out, you might hit a cluster of bugs. So happy hunting Spend as much time as you can on it. Don't get frustrated by the ones you can't find. Keep in mind you're not gonna find all of them. This lecture didn't have a step by step structure. Bug testing, unfortunately, just does not have a structure. It's really kind of an art unless a science. So I think the best way of being a good bug hunter is to have fun with it. Try to beat your application. Try to break it down, try to screw it up as much as you can, because at the end of the day, the more you do that, the better the applications going to be in its final version. 6. Accelerate your testing this way: a quick tip for those of you who do not want to spend the rest of your natural lives. Bug testing You can outsource this freelancers a great website for finding people who could do software testing. Don't break the bank when you hire software tester. But don't get someone who doesn't understand what your application does. Make sure they understand primarily what you're is that you're doing. Otherwise, they're not going to really know where to check and what things they should test with. If that makes sense to use somebody else's time, I think it's a great investment. 7. Keep the learning going: Hey, guys, I just wanted to say thank you for taking this class, and I hope you learned something. I hope what I said made sense. And I was clear, if you have any questions, any concerns, just posting the group discussion, all respond to you. You could even send me a direct message if you want to. I want to give you a quick word of how you could take the skills that we learned in this class and how to bring it to the next level. Learn some other related skills. So this class, we learned a little bit about bug hunting. We talked about tools that are used in bug hunting. We talked about what a common areas that people often overlook. And where should you look first, and where should you look last for bugs. Now, if you're looking for bugs, I'm assuming you're working in a Web or mobile projects. So I have some other classes I think would help augment what you learned in this class. One thing I definitely think is worth checking out is my class called build documentation for your project. Now, if you're looking for bugs and you have something that has a lot of bugs. Chances are it's because you didn't build your documentation right. And as you're going through this class, you probably realize there's a lot of things you might have said or written down wrong. That ended up being a bug. That one's called Bill Documentation for your project and just search for it on skill share each other. What I would suggest is called master outsourcing, and in that one, I specifically go over. What are the issues and concerns with outsourcing? I talk about what are kind of best practices for getting the same high quality, where it you'd expect from someone locally. But with outsource labor, bugs are often associated with outsource labor. That's why I think it's important to go back and have a quick and easy course on what are some best practices for working with those people that do you often create bugs? Okay, if you want to go further with your skills, check those out. Otherwise, again, thank you for taking the course