shutterstock_690204889.jpg

Quality Assurance and SCRUM

Note from Danny – As I was looking for a an image to go with this episode on Shuttershock, I ran into this image that had SCRUM misspelled. Well, that’s a perfect image for Quality Assurance and SCRUM…

Danny:Hello, this is Danny Ryan. Welcome to the ThreeWill podcast. Today I have Brandon Holloway.

 

Brandon :Thanks for having me, Danny.

 

Danny:You’re welcome. I don’t know why I want to start singing.

 

Brandon :I don’t know.

 

Danny:I’m going to start singing if that’s okay.

 

Brandon :[Crosstalk 00:00:14].

 

Danny:I’m going to sing. All my questions for you will be sung.

 

Brandon :Interesting.

 

Danny:Brandon helps out with our QA, otherwise known as quality assurance. He makes sure that everything’s staying tiptop quality-wise on our projects. I have asked him to sit down and just tell me what does it mean to do QA on a typical ThreeWill project? What does that mean to me?

 

Let’s get started off with this question. When do you typically get pulled in first for the project? Just we’re talking about generally for the typical project that you’d be a part of.

 

Brandon :I’ll usually get pulled in a lot of times at the very beginning even though it’s going to be a few weeks before there’s going to be any real testing even if it’s still in the requirements gathering, or architecture phases. Sometimes it’s good for me to be there because I’m still thinking in the beginning on how would a user approach this which is the mindset I try to put myself into. They try to involve me as early as possible that I could provide some value.

 

Danny:You usually start off with taking a look at the product backlog and what the user stories are. Is that where your first thing that you interact with on the project?

 

Brandon :Right, right, the user stories and the product backlog, that’s right. A lot of times a lot of what I focus on is the acceptance criteria which is definitely not the only thing I look at for it. Like I said, I got to put myself in the user perspective. What does this story mean to the typical user and just figure how to build test cases off of that.

 

A lot of times early in the sprints and early in the project I can go ahead and start working on test cases based off of mainly the product backlog, even well before testing is actually available to be done.

 

Danny:Then you would, as you find defects you would log those defects. Is there a typical place where we’re putting those defects?

 

Brandon :On most projects we use SharePoint to …

 

Danny:SharePoint, tell me more about this. What is this?

 

Brandon :Yes, it’s this thing we use around here called SharePoint. It’s a pretty cool little application.

 

Danny:Sounds fascinating, fascinating.

 

Brandon :Yeah, a lot of times we just have an issues list. It’s just a basic list in SharePoint that a lot of the developers will set up alerts for so they see. They know when they get a issue coming across they can go straight in there and work on it. It’s just [crosstalk 00:02:54] …

 

Danny:It probably has a status column as far as where the defect …

 

Brandon :The normal, the priority, what I think the priority should be. This is what I think the severity should be, what type of issue it is, that kind of thing. I’ll just assign it to whoever. Usually whoever is assigned to that particular product backlog, or that feature, that can vary though. Sometimes we’ll pass it to somebody else that it may be a better fit to work on.

 

Danny:You know when to retest because they’re updating that issue log.

 

Brandon :Correct, yeah. There’s a few different statuses that it’ll go though. When I first open an issue, I always see it’s an open status. When the developer fixes it, it’ll go decoded status. It’s not available for me to test yet. They have to just check their coding. Whenever they get ready for another QA deployment, then they deploy it and then it’s in the QA environment ready to be tested. Then they’ll move it to either deployed, to QA, or ready for QA. There’s a couple different statuses on the project.

 

Danny:A lot of our projects will have a separate QA environment that you work within. Is that correct?

 

Brandon :Yes.

 

Danny:Is that normal?

 

Brandon :Yeah, it’s pretty normal. We’ve used a couple different cloud service 1 time to ….

 

Danny:Geese. Host failure. Host failure. Just a second. It could be anybody. I’m sorry. Now I’m going to shut this off and here we go. You were saying, sir, yes.

 

Brandon :The best case is probably when the clients themselves have QA environments set up that I can go in there and use. That’s usually the best method just because that’s basically what they’re going to have their own UAT environment in that same environment to production. Everything should be similar. It should be more along the lines of how it’s going to be in the real world. I have a couple different virtual machines that I’ll host a QA site in. It depends on the project and if they have an actual QA environment for us to work on or not.

 

Danny:Got you.

 

Brandon :We just deal with what we got.

 

Danny:Yeah. It just depends on the project really.

 

Brandon :It does.

 

Danny:Yeah, how does it work with …? Are you testing? Within the Sprint cycle, are you testing things that were implemented in the previous cycle and then they’re doing a defect resolution, or giving some capacity towards defect resolution in certain sprints? How does that all work?

 

Brandon :In a perfect world …

 

Danny:In a perfect world. Tell me this imaginary place …

 

Brandon :… which it is not.

 

Danny:… that you call in a perfect world.

 

Brandon :Excuse me. Say it’s a …. For instance we’ll say a 2 week sprint. In a perfect world, I would write my test cases maybe the first week or somewhere in that time frame. Maybe the beginning of the second week of that sprint all those product backlog items of stories will be available for me to test.

 

I should be able to get those at least a good round of testing in within a couple days. Maybe by Wednesday of the second week, or so, assuming the sprint ends on a Friday. Whatever issues come out of that, they can be working those issues and get them back to me and I can retest them so I can get everything closed out and everything marked as tested by the last day, or the day before the last day of the sprint. That’s a perfect world.

 

Danny:That’s a perfect world.

 

Brandon :It doesn’t always happen like that, of course. There’s just a lot of factors, a lot of movement going on everywhere. People change priorities of stories and the client’s involved pretty heavily in Scrum. We just adapt with it. I adapt just like everybody else does. Sometimes that means maybe a couple of product backlog items for a sprint may just be all the way pushed to the next sprint.

 

Sometimes I may get them on the actual last day of the sprint. I at least get what testing done I can, like maybe a good smoke test of the functionality, or just do some ad hoc testing to hit the points that I think may be most prone to have issues, at least get as much done of a first round of testing as I can before the beginning of the next week rolls around and we have a sprint review.

 

From there I’ll clean up all the test cases and run the rest of the tests and everything. It may be into the very beginning of the next sprint. That happens sometimes. It’s not a perfect world.

 

Danny:It sounds like a lot of the type of testing that you’re doing, is it more like end user testing, really trying to focus in on what the experience that …

 

Brandon :It is.

 

Danny:… the end user would have with …?

 

Brandon :Right. It’s pretty much all manual testing and it’s mainly use cases. A lot of the reason for that is balancing a couple different projects. Whatever my capacity is on a particular project, I have to base my testing scope around that capacity. There’s always more testing to be done. You could test forever on something and still not 100% cover everything. It’s just the nature of it.

 

Basically, I build off what my capacity is for this project, what we decided on with the client for this project, out of that amount of hours I’m going to get the most effective testing I can done out of that. That’s pretty much going to be manual use case testing; not a lot of tools involved. It’s more of a time sensitive thing. We want to make sure we hit everything that we can from a user’s perspective so that ….

 

Danny:Got you. It sounds like you’re across multiple projects. You probably have to …. You’re probably coming in since we’re building a lot of web-based stuff, probably have to get a list of which browsers are supported, that sort of stuff as well.

 

Brandon :Right, yeah, that’s another big part of it. Sometimes there’ll be a project where Internet Explorer 10 only. That’s the only browser I have to test in. Many times, they want to support it on Chrome. They want it IE10 and up which includes IE11 and in some cases maybe Microsoft Edge will start coming in since it’s a newer browser.

 

Sometimes Firefox needs to be supported. It just depends on the project. A lot of times there is definitely cross browser testing. IE, in particular, tends to behave differently in some situations than say Chrome and most [crosstalk 00:10:02] …

 

Danny:No.

 

Brandon :… Firefox.

 

Danny:No.

 

Brandon :Yeah. IE is fun. There’s always that to deal with.

 

Danny:Are you crying? There’s no need to cry. Did IE bring tears to your eye? Don’t look like tears of joy either.

 

Brandon :My eye’s just watering.

 

Danny:Tell me a couple more questions and I’ll let you go. I’ll let you leave. What do you find is the most challenging part of what you do?

 

Brandon :Definitely 1 thing is that just the nature of being Agile Scrum is that you don’t get as concrete requirements to test on, which for testing is very important. It’s important for everybody at my project. I base what I build in my test cases off of what is supposed to happen in these situations.

 

You don’t have detailed requirements, very detailed requirements sometimes in Scrum, at least in my experience. That’s 1 thing. There’s a lot more interaction between myself and developers. I ask questions. That’s how I like how everybody’s so open here. It’s just easy to get with somebody about something like that. Definitely I’ll need things clarified.

 

Sometimes it takes a while for me to get the full picture of everything without these hard requirements and everything. That’s mainly 1 of the challenges and of course just time in general, what things get pushed back. Testing is at the end of everything.

 

Sometimes I find myself working late on a Friday, a little bit on the weekend, which it’s not a big deal. That definitely can come into play, especially later in projects depending on what needs to be put into the backlog at the last minute or taken out.

 

Danny:I think when we look at what makes a great QA person is they have to come in and take some initiative to come into it. You’re coming in to a project and really trying to understand what are we trying to do for the client as well. I think you do a great job at that from what I’m hearing from other people. You’ve tested my Web site.

 

Brandon :I’m about half way done with it. I got 2 lists of things.

 

Danny:For people who come to threewill.com, it’s half tested. How’s that make you feel? It’s half tested. Don’t worry. I change things daily. I mean I don’t change the name of the company daily, but I do change a lot of stuff on my Web site daily just to keep things moving.

 

Brandon :I didn’t realize how much there was on that Web site.

 

Danny:It’s a dynamic site. It’s a dynamic.

 

Brandon :It’s pretty large.

 

Danny:Maybe it’s a softball, maybe it’s not a softball question, but what do you love about what you do?

 

Brandon :Man, I just don’t know. It’s like I’m a perfectionist in a way. I hate to say I like it’s like a treasure hunt almost. It’s fun. There’s something in here that I’m going to find that’s not doing what it’s supposed to be doing.

 

It’s like finding things like that, not mistakes. That’s a bad word for it. I like finding bugs. It’s just like a hunt for me. Since I first started testing, I didn’t even know coming out of college with my degree, I didn’t even know there was a profession, software tester, or whatever.

 

I have a cousin that did that at a company back in Columbus. I was like, “Man, this sounds like something right up my alley.” I started doing it. I love it. It’s just you never know what you’re going to come across. Working with great developers obviously helps a lot.

 

Sometimes in the past, other jobs sometimes you don’t have developers that are very willing to …. Some look at QA as, “Oh, that guy, my nemesis.” It’s not like that here. Everybody’s on the same team. It’s great.

 

Danny:I heard, within the past week, Eric was talking about how much he appreciates what you do and how he feels better after you’ve tested something. It’s wonderful having you around to do that. You’re an important part of each 1 of our projects. I love it that you love to do. It is treasure hunting. You’re trying to go figure out.

 

Brandon :Can’t think of another way to put it. [Crosstalk 00:14:41].

 

Danny:It’s fun. No, it’s a great analogy. It’s a wonderful analogy. You’re trying to go in and figure out what are the important, when talking about treasure, what are the big things that we might’ve overseen as a developer.

 

Brandon :A lot of times I have to put myself into the end user’s shoes is what I’m doing. I’m thinking, “What would a user do here? Does this look right to the user’s perspective?” Just giving that whole side of things, I like it.

 

Danny:We love having you here too. We can really think through the what from somebody from Alabama would do.

 

Brandon :Here we go with this again.

 

Danny:For those that’s not an inside joke. He’s from Phoenix City, Alabama. Yes, he’s representing Alabama in the ThreeWill family. We now have a southeast …

 

Brandon :Not the school. Not the school Alabama.

 

Danny:Not the school. Yeah, let’s get that straight.

 

Brandon :Even the state.

 

Danny:I’m sorry. You’re representing the state of Alabama.

 

Brandon :We’ll say that, yeah.

 

Danny:The school of Auburn.

 

Brandon :Auburn.

 

Danny:Geese, there’s too many of you guys around here. Why don’t you go hang out with our other Auburn friends and get the heck out of here? That’s the end of this episode. Let’s get out of here.

 

Brandon :[Crosstalk 00:16:00].

 

Danny:Yeah, I’m going to kick the …. Here’s where I’d kick the microphone over and like, “Get out of here.” Slam the door.

 

Brandon :Y’all are the guys hiring the Auburn folks. Do you know what I mean? That should tell you something.

 

Danny:With that, I think we’ll wrap up this episode. Thanks so much for listening everybody. Brandon, thank you for your time.

 

Brandon :Thank you.

 

Danny:Go get back to testing and go back. You’ve got a long ride home from here. You’re heading …

 

Brandon :Yeah, a couple hours.

 

Danny:… going to head home. A couple hours.

 

Brandon :Back to Alabama.

 

Danny:All right. Just test this like you were someone from Alabama. Thank you for spending your time here, Brandon.

 

Brandon :Thanks.

 

Danny:Take care. Bye-bye.

 

Danny RyanQuality Assurance and SCRUM

Join the conversation

This site uses Akismet to reduce spam. Learn how your comment data is processed.