>> Seth: I would even argue a little that doing this work is a form of marketing where some businesses pour so much money into commercials and getting themselves out there, but once someone gets to your website, it's gotta be good.

>> Intro Speaker: You're ​listening ​to ​Discussing ​Stupid, ​a ​podcast ​sponsored ​by ​High Monkey. ​​Join ​your ​host, ​Virgil ​Carroll ​and ​others ​as ​our ​podcast ​helps ​you ​transform ​bad ​digital ​experiences ​into ​teachable ​moments ​you ​can ​use. 

>> Virgil: Today's episode is kind of a little exciting. We haven't brought anybody new to discuss anything with us for a long time. And so today we brought in Seth, who is both our project manager and also helps us with QA testing. And I thought that this was a great topic because obviously with any type of web project or digital project or really any kind of project you do, doing some quality assurance testing is critical. And, you know, from our perspective, quality assurance doesn't only include, you know, just making sure from a functional standpoint and from a design standpoint, but also accessibility and a lot of other things on there. Even early on in my career, we didn't tend to emphasize that level of testing before we deployed projects. And even today, I'm amazed how many times I run into different organizations that just make updates and put them out there and don't realize the consequences of it and everything doing it. So today we're going to talk about some of the things that we need to do around quality assurance to kind of make sure that we're delivering a very quality product, but also trying to make sure that you have it as part of a continuous process in your own organization to make sure that you're handling all these needs and some of the things that can have an effect from that. 

>> Virgil: Well, welcome Seth. Seth is joining for our first time. Uh, maybe you can introduce yourself.

>> Seth: I'm um, Seth Moline. I'm the Project Manager at High Monkey. Uh, but also have more of a hybrid role of doing QA for our customers, but also most recently our own website that we've relaunched. So, yeah, I guess I've been here what, four years now? Three?

>> Cole: Dang!

>> Virgil: Something like that. A while.

>> Cole: I didn't know it was that many years.

>> Virgil: Yeah. Well, technically, Cole, you'll be at 3.

>> Cole: Oh, yeah, yeah.

>> Virgil: There we go.

>> Cole: So I'm getting up there too. But, um, so yeah, today we'll be kind of focusing more on uh, the QA side of Seth's role. That's why brought him here today to talk, uh, kind of all things QA.

>> Virgil: No we're going to talk about project management. Everybody loves that topic right there. Yeah, I mean it's not like one of the most exciting ones. 

>> Cole: Maybe another day.

>> Virgil: We could talk about a Gantt Chart! 

>> Seth: Yeah.

>> Virgil: Okay, all right.

>> Cole: But um, yeah, so Seth, what kinds of things do you handle with regards to QA at High Monkey?

>> Seth: Well, uh, with QA, kind of the whole picture, uh, at least on the front end aspect of it and functionality, um, you know, from content to um, different screen sizes to accessibility, functionality, forms working the way they should, um, uncovering every stone that is to be uncovered with, uh, QA on a website that's, uh, getting ready to launch.

>> Virgil: You make it sound very simple.

>> Seth: Yes. Well, easier said than done is the phrase they like to say. Right?

>> Virgil: Yeah. So one of the things definitely when we kind of brought in uh, Seth and kind of switched him more to a more formalized role is we, we started doing QA as a more continuous process. Not that we didn't to a certain extent before, but it was always the developers kind of QAing their own stuff. And now we have somebody queuing all the work product kind uh, of as they're rolling things out continuously. So that makes a big difference, uh, which, you know, is really a big thing of quality assurance is that, you know, it's, it's amazing especially when you, when you're doing front end things, how much you change something to fix something over here and you end up breaking seven things over here. Because everything's so interconnected. If you're doing it right, everything's so interconnected. But the problem is, is that interconnection where that helps you, it also kind of hurts you at the same time.

>> Seth: Yeah. And it's also good to have a fresh perspective on it where developers are so engrossed in what they're doing that they forget to check back on things or they don't want to because they figured it's already done and have someone like me come in and be like, uh uh uh, yeah, that's always fun.

>> Virgil: The outside perspective is such a big thing. And your background's not development. I mean, you're not a developer by trade, you're a project manager by trade. Um, and, you know, it's, it's so interesting not, not to say that you're like our lowest common denominator user. Talk about this. But, you know, I mean, overall, you, you come from a more simplistic side of understanding how all this works together, um, uh, than developers. And sometimes, uh, people from a development side or an IT side can kind of get so focused on the functionality and how something works in the advanced mechanics behind it, they kind of forget that we're building these things so that people can actually use them that aren't developers. And I mean, the history of technology is just... there's so many examples out there in the world about that basically being a disaster. Because, uh, if you let developers create and build things, um, it tends to never go, well, if you let them build things that you create, it tends to go much better.

>> Seth: And the audiences of these websites, 99% of them are not developers, and they're coming to the website for information or to buy something, and that's what they want, where a developer just wants to build it.

>> Virgil: Amen. And even more importantly, they're not only not developers, they also don't work for the company building whatever they're doing. Which, uh, is obviously, Cole, a topic we talk about a lot on the, on the podcast is about how you're not building it for your people, you're building it for somebody else, and so, getting that outside perspective and looking at those things.

>> Cole: Right, what's that, uh, learning experience been like? You know, adjusting to the initial role of QA, from the, you know, the background of being a project manager. Has that helped your background of being a project manager in, QA?

>> Seth: Yeah, I think the thing that really opened my eyes, uh, my "aha" moment of QA, is just how thorough you have to be. You know, you don't just look at a page and go, okay, great. You know, looks good. You have to look at a page, go do something else, come back, relook at the page and kind of go through it multiple times for multiple things, you know, content. Is that all correct? Uh, then you look at accessibility. Then you come back and look at is it functioning the way it should? Um, so there's a lot to it. And having that "aha" moment of there's so much going on. Uh, where my project management background comes in is how do I organize myself and my processes to capture all of those stones and turn over every single one and make sure that each one was turned over, uh, and addressed.

>> Virgil: So now neither of you guys can eye roll when I say this, because this is probably the thing I say the most. Uh, and not only this, but, like, the way Cole, we do our stuff and everything else. Methodical. You have to be very methodical about this process and keep to your method and always do it the same to get the same repeatability results. Because, I mean, one of the things is, I mean, from a QA standpoint, there is nothing more irritating. Having been a dev and having done all that and somebody saying, this is broken. Okay, what's broken? Well, that doesn't look quite right on the page. Well, what is that? Or, you know, the form's not working correctly, or that for somebody to actually be able to troubleshoot and be able to do something about it, it has to be a repeatable activity, something that somebody else can repeat. I can't tell you how many times we get customers to come and say something's not working the way they wanted it to, and you just have no idea what they're even talking about, let alone, um, uh, you know, how to fix it. And so that's one of things you and I talked a lot about. It's not just about noticing something. It's about being able to give specific instructions on what exactly is happening. And so, you know, that's one of the reasons we use the tool we do now, uh, to kind of help, uh, manage that and be able to show screenshots and exactly where on the page something's wrong in that. Uh, but overall, once they fix it, you got to do it all again. It's repeating that method and being very methodical in the way you do things, because it's so easy with these to lose your place and lose your mind.

>> Seth: Yeah. And I think another aspect of it is having a good relationship with the developers you're working with, of having understanding how to work with them to say, you know, when you come back for the third time...

>> Virgil: They love your feedback, huh?

>> Seth: Yeah.

>> Virgil: Yeah.

>> Seth: Yeah, you're coming back for the third time.

>> Virgil: Ah, you're probably the friend on the project manager side and the enemy on the quality assurance side.

>> Seth: Exactly. But you're right, you know.

>> Virgil: You're a frenemy!

>> Seth: Me pushing it back to the developer in a way where it's teed up for them to just swoop in and fix it, knowing here's what I've tried, here's the browser, it's broken on um, or the screen size. So they can just get in there and do what they need to, um, instead of just saying, well it's not working great. Well what's not working?

>> Virgil: Um, you know, well and you have to do that too because you're also the other side which is when the customer's business folks come in and say something, you're the one that has to interpret that and figure that out into actionable things. And so sometimes you get better at doing that for our devs because you experience on the other side where somebody gives you very vague feedback and you're having to make that into an actionable something that could be fixed.

>> Seth: Yeah, a lot of uh, balancing on either side um, of the process and make you know, translating business speak into dev speak and vice versa on these issues that are coming up.

>> Cole: So where do people kind of go wrong when it comes to QA or where have you personally encountered like where there's like uh, some easy places to make mistakes when it comes to the process.

>> Virgil: You know I'm m going to laugh because actually when we were talking about this, I don't know why it came up, but this is the origination of staging sites. I mean this is the origination of the staging process. Why you- it's amazing how many times I still have conversations with customers that are like well "why can't I just make the update on the website?". Because it's very easy to screw things up. And as especially a website becomes fully thing and it has thousands and thousands of lines of styles and thousands and thousands of lines of code, changing one thing can have such a big ripple effect across the entire site. And Seth is smiling because he's got to experience a lot of that.

>> Seth: My previous job, I was unaware if they even had staging. And a lot of the like they built their own CMS and they would push updates out to customers and it would be broken. And I'm sitting there like well did we test this at all? Like and now I have a customer coming back to me saying why is this broken? And I'm standing there, you know, with my pants down being like, "I don't know", I was just told that it's supposed to be fixed, but then these six other things are broken and it was just a frustrating experience for everybody.

>> Virgil: Yeah, and I think that's the key is you have to have that method, but you also have to have a place to test these things, um, uh, and go through that. Which is honestly one of the nice things about a lot of content management systems is they allow that process of kind of doing pre published things. Even our site where we're doing it without a content management system, where you still have a staging environment that we can release things first, um, before we actually go through and um, push it into production so that we can go through it and then test it in that. And so uh, but I think that's a good lesson to learn. You know, if people are going to do good quality assurance, they should hate it because they're going to do it all the time and you're going to look at the same things and it always works. And that's where complacency kind of comes into the process. It's like, well this header has always been here the same way in that. And then you make a change on a form over here which accidentally conflicts with a uh, style, uh, over here and all of a sudden your header's not. But I didn't look at it anymore because I was like, I didn't need to do that.

>> Seth: And that kind of comes back to Cole's question of, you know, the biggest issue is being methodical and staying on top of it because if you don't, you try to get through it quickly, uh, you start to miss little things and then um, it all kind of adds up. So just sticking to that plan that you have set up for yourself, whatever plan that might be, you know, it might vary by customer. Some customers are like pretty relaxed on what they want, others are a little more specific on how they want things to look and function. And um, just making sure you check all the boxes for those customers.

>> Cole: So for those types of customers, how do you like, remain methodical? How do you like, stay to the, you know, meticulous requirements of the QA?

>> Seth: For me I think it's um, doing a couple rounds of, well, let's take one page for example. You know, working on the homepage, um, kind of doing my first round of reading through the content. Okay, does the content match what we've been given? And then going through the next part of it of the visual layout of the page and making sure the pictures are right and things are formatted correctly, uh, and then the next part of looking at accessibility and you know, it's kind of chunked into different stages. And for me, sometimes it's good to do something else and come back to it with that fresh mind where I might have been trying to just get through it and I need to slow down and re see the page. Uh, and maybe notice something I missed in the first round of. Oh, you know, this word is capitalized but it shouldn't be and I missed that on the first round and just staying on top of that methodology but making sure that you're fresh on that methodology and not getting complacent as you're trying to get through it.

>> Virgil: Yeah. I've always joked for years that we've done some pretty cool sites, not only for ourselves, but for our customers and all that. But in the end, if we've done our job well, we internally should almost hate the site. We're so sick of looking at it because you've looked at it 5 million times. Cole now understands that much more that we just went through our site over the last six months. That uh, by the end of it you're like, man, I really want to change everything because I'm so tired of looking at this thing. And you think of it as a stale site when the reality is from our side. That's, that's really what it should be, is it should. If, if you have somewhat of a disdain for the product, you're putting it out because you've been doing quality assurance, that's probably a good thing because it means you looked at it the requisite number of times you needed to make sure it was a good product.

>> Cole: Yeah, yeah, definitely got old looking at that site, but can't stop looking at it.

>> Virgil: Yeah. Uh, so, I mean, but that's important. I did want to mention one thing that I think is very key to what Seth said is he talked about accessibility and how I don't think a lot of people always think of accessibility as part of quality assurance, they think of it as testing. But it's even, you know, like, even when we respond to RFPs, everybody puts it as a separate thing. Instead be in like an overall quality thing. Uh, if you're not doing accessibility as part of your quality assurance, well, first, shame on you. Two, you're not only costing yourself a segment of users, but you're also costing yourself a segment of search engine optimization. And people should always remember that. And that's why we think that quality assurance is very important. And accessibility should always be in there.

>> Seth: I've actually recently come across a website where they touted themselves as accessible. Um, and all they did was add some third party accessibility feature where you can click on it and it'll change the contrast of the page so it's easier for people who might have trouble with colors or something. But when I looked further onto it, there's missing alt text, um, little things like that where it's great, you can say it's accessible with this little feature, but Google's going to read it and say this isn't accessible at all. You know, you've got bad links, you know, missing alt text, uh, or repeating alt text, stuff like that.

>> Cole: Ah, performative.

>> Seth: People try to take a shortcut.

>> Virgil: I've seen people do those kind of things. Not only that, just general quality. You know, it's, it's the same with like artificial intelligence. And what a lot of organizations are saying, well, like this can fix the things that we have broken in that. And it's like, is that really a good policy? That just basically means you're trying to do things a lazy way. And I understand that not everybody has time to work on these things. But the reality is, websites are no longer this other thing and haven't been for a very long time. They are a core part of almost every business's business. Uh, therefore, um, you know, you always want to be thinking about that and, and putting the same amount of effort. As a matter of fact, right now with kind of the direction that, you know, our world is going in right now, you know, a lot of organizations are going to be starting to beef up their marketing as, you know, kind of the markets start to slow down and that kind of stuff. That's a great opportunity to really look at what you can do to improve that user experience. And part of that is doing some QA testing up front. We really recommend that with customers is doing QA testing up front to kind of see what's working well right now and what isn't.

>> Seth: And um, I would even argue a little that doing this work is a form of marketing where some businesses pour so much money into commercials and getting themselves out there, but once someone gets to your website, it's gotta be good, and that's part of your brand and your business. And if you have a terrible website with, you know, little to no accessibility or it's inconsistent because no one QA'd it, you know, that kind of tarnishes your name a little bit in the eyes of that customer. And um, so I would argue it's, uh, in a way, is. It's part of the marketing.

>> Virgil: Yeah. And marketing's always a good thing. As a matter of fact, if, uh, you're listening right now, we could always use your help marketing us, by liking what you're listening, whether you're listening or watching the video and sharing it with your friends and colleagues so that we can grow our listener base, so that we can continue to do this kind of stuff.

>> Cole: What Virgil said.

>> Virgil: Yeah, what Virgil said. I'm sure Cole was getting ready to say that, but I just saw that as a perfect segue, so. But, Seth, boy, we really do thank you for joining us today. Kind of fun to have a new face. Not just Cole and I, or Cole I and Chad, to have somebody new. And we'll have to see how adequate a job you did once we, uh, release the episode.

>> Seth: Well, and I'm in the final push of QA for a site that should be launching in a couple of weeks, so I should probably get back to that.

>> Virgil: Uh, we'll probably, after that to talk about it.

>> Seth: All right. Look forward to it. Thanks, guys. Uh, appreciate you having me.

>> Virgil: Just a reminder, we'll be dropping new episodes every two weeks. If you enjoyed the discussion today, we would appreciate it if you hit the like button and leave us a review or comment below. And to listen to past episodes or be notified when future episodes are released, visit our website at www.discussingstupid.com and sign up for our email updates. Not only will we share when each new episode drops, but also we'll be including a ton of good content to help you in discussing stupid in your own organization. Of course, you can also follow us on YouTube, Apple Podcasts, Spotify or SoundCloud, or really any of the other favorite podcast platforms you might use. Thanks again for joining, and we'll see you next time.