In this interview, Mike Duskis, QA manager for 10-4 Systems, talks about his upcoming presentation at STARWEST 2014, his thoughts on the roles of testers as communicators, and his younger days of hacking video games and holding various roles in the tech industry.
In this interview, Mike Duskis, QA manager for 10-4 Systems, talks about his upcoming presentation at STARWEST 2014, his thoughts on the roles of testers as communicators, and his younger days of hacking video games and holding various roles in the tech industry.
Cameron Philipp-Edmonds: Today, we have Mike Duskis. He'll be speaking at STARWEST 2014. He is giving a presentation titled "The Role of Testing: Quality Police or Quality Communicator?" Thank you for joining us today, Mike.
Mike Duskis: Thanks for having me, Cameron.
Cameron Philipp-Edmonds: To start things off, can you tell us a little bit about 10-4 Systems and your role there?
Mike Duskis: 10-4 is rocking the transportation logistics industry. Most people who don't drive trucks don't think about it, but it's about 10% of the US economy, and we estimate it's running at about 50% efficiency. A lot of that inefficiency comes from lack of technology, lack of knowledge about what an organization is doing with another organization. People who have stuff to ship don't know where all the trucks are. People who have trucks don't know where the stuff is.
We are building a suite of products designed to A, help the guys who own trucks manage their business better so they can figure out where their stuff is, and then B, develop a marketplace so they can work together with people who have things to ship. It's like a cross between eHarmony and eBay. It's sort of a dating site between trucks and stuff that has to move around.
The big problem we're trying to solve, the holy grail, is called the back-haul problem, which you probably never heard of if you don't drive a truck. Say you've got a load of lettuce in Fresno and you're trying to drive it to Milwaukee. That's great, no problem. You've got it. You already have a load. You have a route, fine.
You get to Milwaukee and now what? You've got a refrigerated truck, and you have to get back home to Fresno somehow. You don't want to drive back empty. It turns out that half of these guys just wait around for days, or they drive back home empty, or they drive to some third location empty and pick something up. Then they're out of their way and they're driving around empty.
We think we can fix this problem by having a free market, basically, for stuff. It's complicated. It's like the traveling salesman problem, cubed.
Cameron Philipp-Edmonds: Wow, yeah. It sounds pretty inefficient. Now, the name of your presentation The Role of Testing: Quality Police or Quality Communicator? what led to the idea of the presentation and the subject matter?
Mike Duskis: That's a good question. My last job we had a problem with the development cycle where halfway through, we'd run into a scheduling crunch. We're supposed to be doing testing, but the product is late. People are waiting around for the software to be delivered. Three days before the delivery date, fully-formed, the development team would throw something over the wall. The test team would look at it, scratch their heads, say, "We don't understand it," and say, "No," and then send it back.
When that happens, you're not shipping anything. We were seven or eight months behind schedule simply because we weren't shipping anything because the testers were not involved early enough in the process, because they were playing this policing role. All they were doing is, "No! No! No!"
Instead, what I'm proposing is that the testers get involved early and they become a collaborative helper alongside the developer, so the developer isn't so frightened to show pre-release code to the tester and the tester then can provide input early. The tester can provide test scripts to the developer ahead of time, so the developer knows what the exam's going to be before she takes the exam. This way we can do more concurrent development testing and get the product out faster.
The second reason is political. I don't know about you, but I like to work in an environment where people work well together and we have a good time and we trust each other. If you have half the team doing nothing but criticizing and saying no to the other team, it's not conducive to a happy workplace. When you don't have a happy workplace, you're not getting anything done, really. You're hiding things from people. You're working around them, you're finding ways to stab them in the back and subvert them. Then the product suffers.
I'm trying to build a collegial environment that can get stuff done faster and get the product to market.
Cameron Philipp-Edmonds: To move right along here, software development acceptance criteria can be fairly complex, which often causes organizations to lack the confidence to make acceptance decisions. Therefore, the decision process often falls to testers. Why is there really a problem?
Mike Duskis: Because making decisions about when the software should go out and what condition it should be in and what features should be in there really is not a good decision for testers to be making.
Testers see a product, they see problems in the product, and that's all that they see. They don't have a good view of what the marketplace need is. They don't understand the schedules that are required, where the trade shows are, what's going to happen if we don't ship on time, who needs what feature when. The testers have a very important role in providing information to the organization. They have sometimes a very important decision-making role, when it comes to bringing things out and elevating them and having the conversations.
Ultimately, it's the business that's responsible for the product that it produces. Therefore, shipping this or shipping that or shipping neither, that's a business decision.
Cameron Philipp-Edmonds: You a proponent of moving away from binary pass/fail testing, towards a more exploratory method of testing which provides more information. Why is that?
Mike Duskis: First, it's not completely true that I'm opposed to binary testing. We do an awful lot of regression testing that's automated, and we do some regression testing that's done overseas by less-skilled testers who follow scripts. I do believe in the binary results for regression. I believe in the binary results for some of the the acceptance-test driven stuff we do at the beginning, as well.
But, also, you're not going to get a good view of the product just by answering a bunch of yes/no question. This is a human enterprise. We have a human experience in the product, and you want somebody who's going to be able to really tear the thing apart and say, "You know what? I tried to do this and this just looked ugly. It was hard. I didn't understand it. I think we could do better. Have you considered that maybe somebody might do this?" Which somebody who had originally written the test script had no clue, because he hadn't actually seen the product first.
I like what James Bach is doing with the session-based testing, and I believe in it. I've got one guy, sometimes one and a half guys, just full-time, doing session-based, but I also do the other kind of binary stuff.
Cameron Philipp-Edmonds: The title of your presentation infers that it's kind of black-or-white. You're either a quality police or you're a quality communicator. Is it really that black-and-white, or is there a lot of gray areas there?
Mike Duskis: There's a ton of gray areas there. A lot of it is contextual, based on the organization. I've worked in a medical device company where, if we screwed up, people could literally die. I've found a couple of bugs that could have killed people if they went out. That's good. It's a good thing for a tester. You say, "Hooray." I had one that literally could have caused a baby to explode.
Cameron Philipp-Edmonds: What was that?
Mike Duskis: I had one bug that literally could have caused a baby to explode if it had gone out in the field and the wrong stuff had been done with it. We miscalculated a fluid volume. It was just a math error, could have been really serious. It wasn't, because we had a good quality process and we caught the thing. Actually, you do want somebody, especially in a life-safety critical environment, you want somebody looking at the code and saying, "No, we can't ship this."
Cameron Philipp-Edmonds: Right. And find those defects.
Mike Duskis: "Somebody's going to die."
But there are other circumstances where it's not so black-and-white, where the decision is harder to make, where what you really want to do is say, "You know, I found this. I'm not so sure if we can live with it. Let's talk about the balance between the cost of fixing it and the risk of not fixing it and the risk of putting it aside and fixing it a week from now." That's where it becomes more of a communication role.
Cameron Philipp-Edmonds: To get some general questions here, you got your start as a programmer, not a tester, and you were hacking video games as a child in the 80s. What led you to hacking video games?
Mike Duskis: It's funny. I'm 42 years old now and just starting to understand what that means. It means that people coming into the industry are half my age and just don't have the experience of what it was like to live in the analog world.
There was a time when computers were not mainstream, and it was the realm of geeks and recluses and introverts. I was one of those. I got to know computers pretty well. Computer software, much the time, was software code. We didn't send binaries around. In fact, some of it was sent around on dead trees, if you can believe this. You'd actually bind and print BASIC code and put it out in book stores. People would type this stuff in.
I spent hours and hours typing stuff in and, "Gee, that's not quite right," because I have a different kind of BASIC Interpreter than the guy who designed the thing. I've got to figure out how to make it work with mine. I learned how to write code that way, because I wanted this dang game to run so I could play it. Eventually, I learned, "Well, you know what? It's actually more fun fooling with this code than it is playing the game."
Cameron Philipp-Edmonds: Is there a particular game that you did this with?
Mike Duskis: There were various adventure games. I don't even remember the names of most of them. In the early 80s, there were ... most of these things are gone now. There was a whole bunch of Z-Machine stuff that was done by Infocom, the Zork series. Those were fun to play with. There was King's Quest and the like by Sierra Interactive. If you know how to use a hexadecimal editor, you can break into their data files and interpret the data and play around with the system. I found that kind of fun.
Cameron Philipp-Edmonds: Sounds very fun. Immediately after high school, you launched a play-by gaming company. Can you tell us a little bit about that?
Mike Duskis: MAD Turkey Enterprises. Play-by-mail, of course, is long, long gone. The idea was that mostly role-playing games, some board games, and you would literally take your turn, put it in the mail, put a stamp on it, send it through snail mail, and six to eight weeks later, you'd get some response back from the company.
I was one of those companies that had a adventure game called Scavenger Adventures Across Eight Dimensions, which was a scavenger hunt across space and time and alternate realities. I had a system that I wrote in Turbo Pascal that ran the game and it ran the business. It was kind of fun. But I was also going to university, and I was also trying to feed myself. I made some money, but it wasn't like it was going to go anywhere.
Cameron Philipp-Edmonds: Can you elaborate a little bit on the name of the company?
Mike Duskis: That's my name, Michael Aaron Duskis, so MAD, that's my initials. My computer teacher in junior high called everybody turkeys: "Hey, turkey!" So that was MAD Turkey.
Cameron Philipp-Edmonds: You've held a myriad positions and played several roles on a variety of projects. Is there one particular role or experience that you can look at and say that this has been the most rewarding?
Mike Duskis: From a tester standpoint, the medical device testing absolutely was the most rewarding. Knowing that I'm standing between somebody dying, basically. I'm the one in front of, literally, that child. That one bug that I found that could have caused a baby to explode, that's incredibly grati- ... that one led to a recall, as a matter of fact. It's nice to be able to say, "Hey, you know what? I fixed this. I didn't fix the bug, but I'm the one who prevented potentially a severe injury or death to a two- or three-day-old infant." It's a pretty big deal.
From a management standpoint, my last job was very, very rewarding. It's where I rescued a project that wasn't going anywhere, which is really the impetus for this particular discussion. This is the company that could not ship because they couldn't get their development process working so stuff stuff could move out the door. We did. We shipped.
Cameron Philipp-Edmonds: A lot of people who start off as programmers become testers as they move through their career. Do you think that's been good for your career, or do you think that you would like to go back to more the programming aspect?
Mike Duskis: I have gone back and forth at least once. I'm learning that my business is software, it's about taking business needs and taking human needs and get them into coding, get them into people's hands. Right now, I've been doing much more managerial work than I've been doing either testing or coding. That's fine, too. It's all about mining ...
Cameron Philipp-Edmonds: Creating value.
Mike Duskis: Creating value, mining what's in people's heads and then making something real with it that they can use.
Cameron Philipp-Edmonds: Fantastic. Is there one thing you would like attendees of your presentation to take away from it?
Mike Duskis: That there's not just one way to do things. A lot of people on the quality police side are there because that's all they know. I'm trying to present that there is an alternative. As you said, it's not a black-or-white alternative. It's, "Maybe some of the time, I should stop and be a little more collegial and try to make my company work better."
Cameron Philipp-Edmonds: You talk about the black-and-white. Do you think maybe the title of the presentation could have been, like, The Role of Testing: 50 Shades of Gray?
Mike Duskis: Sure. It could have been a lot of things.
Cameron Philipp-Edmonds: All right. Is there anything you would like to say to the delegates of STARWEST before they attend the conference, and, of course, before they attend you presentation?
Mike Duskis: I'm very much looking forward to meeting different kinds of people from different places. This is my first big software testing conference. I'm really just going to hang out and meet people. I'm very excited.
Cameron Philipp-Edmonds: That actually wraps up our interview for today. Thank you so much for joining us today, Mike. Once again, this is Mike Duskis. He'll be speaking at STARWEST 2014, which is October 12 through October 17. Make sure to check out his presentation, The Role of Testing: Quality Police or Quality Communicator? Thank you so much, Mike.
Mike Duskis: Thanks, Cameron.
Mike Duskis got his start as a programmer, hacking video games as a child in the ‘80s. Immediately after high school, Mike sold his first custom-built business software product and launched a play-by-mail gaming company. He went on to gain a broad and deep appreciation of the software development process by playing nearly every conceivable role on projects ranging from children's entertainment to safety-critical medical devices. Based in Boulder, Colorado, Mike currently plays the QA manager role for 10–4 Systems, the world's first marketplace for capacity to move freight.
