Lee Copeland will be presenting a presentation titled "Creating a Better Testing Future: The World Is Changing and We Must Change With It" at STARCANADA 2014, which will take place April 5-9, 2014.

 

About "Creating a Better Testing Future: The World Is Changing and We Must Change With It":

The IEEE 829 Test Documentation standard is thirty years old this year. Boris Beizer’s first book on software testing also turned thirty. Testing Computer Software, the best selling book on software testing, is twenty-five. During the last three decades, hardware platforms have evolved from mainframes to minis to desktops to laptops to tablets to smartphones. Development paradigms have shifted from waterfall to agile. Consumers expect more functionality, demand higher quality, and are less loyal to brands. The world has changed dramatically and testing must change to match it. Testing processes that helped us succeed in the past may prevent our success in the future. Lee Copeland gives his insights into the future of testing, sharing his do’s and don’ts in the areas of technology, organization, test processes, test plans, and automation. Join Lee for a thought-provoking look at creating a better testing future.

 

Cameron: All right, today we have Lee Copeland. He will be speaking at STARCANADA April 5 through April 9 in a session called "Creating a Better Testing Future: The World Is Changing and We Must Change with It." All right, Lee, to give you a rundown of what we have for you, we have:

With more than thirty years' experience as an information systems professional at commercial and nonprofit organizations, Lee Copeland has held technical and managerial positions in applications development, software testing, and software process improvement. Lee has developed and taught numerous training courses on software development and testing issues and is a well-known speaker with our very own Software Quality Engineering. Lee presents at software conferences in the United States and abroad. He is also the author of the popular reference book A Practitioner’s Guide to Software Test Design. Did we cover everything, Lee?

Lee: You did, except the son of poor but honest parents, raised in a log cabin, who pulled himself up by the bootstraps. That whole thing.

Cameron: Your session, again, is titled "Creating a Better Testing Future: The World Is Changing and We Must Change with It," and that speaks to the future of software testing. My first question for you is: For a lot of companies and people, the testing methodologies that they’re using still works for them, so why should anyone be concerned with changing with the new testing trends?

Lee: That’s a good question. The first question I would respond back to you with is: What do you mean by “still work”? What does that mean? Does that mean that their techniques are efficient? Are they effective? Do they work as well as possible? Do they find a high percentage of defects? Do they find them quickly and early at the lowest cost? If that’s the case, then I don’t see any reason to change.

The question then I would ask is: Are they building the same applications over and over again, with the same functionality on the same platforms? They’re probably not. In that case, their world is changing, and their test techniques probably should change with it.

Cameron: Are there any test processes, methodologies, or practices that are likely to stay as testing continues to evolve?

Lee: I think the classic parts of testing—the planning, that analysis, the design, execution, monitoring, reporting—those things will all stay. I think their form is going to evolve. We do more just-in-time planning than we used to. We monitor better than we used to. I think those basic things are going to stay.

Cameron: Is there anything that’s gone away that you wish would make a comeback?

Lee: No, I don’t think so.

Cameron: Is there anything that’s been lingering around that you really wish would go away—it hasn’t gone away yet, and you’re like, "Come on, get out of here"?

Lee: Yeah. I think this planning. In astronomy, there’s this term called “the event horizon.” It’s essentially how far out you can see. Typically, in our test planning and development, too, we’ve been planning way past the event horizon. We’ve tried to plan from the beginning of the project all the way to the end, and that just never worked. People have Gantt charts and PERT charts that fill entire walls. Nobody believes what they say after the first couple of weeks.

In the agile world, we’re getting rid of that, and that’s long overdue. That should have gone years ago.

Cameron: In your session, you cover some do's and don’ts of technology. What are some of the do's and don’ts in the areas of technology, organization, test processes, test plans, and automation? You don’t have to speak about all of them, just a couple.

Lee: OK, let me talk about organization. Whatever you do, don’t continue to maintain these organizational walls—the "us versus them," the "throw work products over the wall without real communication." Rather, we need to integrate into multidisciplinary, multifunction teams and break down those walls. I think that’s important.

In terms of technology, my bit of advice there would be don’t stick with Stone Age tools. The IEEE standard that most of us use came about in about 1983, which was the same year that Windows Version One came out. Now, hardware has changed and software has changed, yet we still use the same Stone Age procedures, tools, techniques. I’d get rid of them. Look for new technologies. Embrace new technologies. Grab on to those and incorporate those. One more?

Cameron: Sure, go ahead.

Lee: Test process: Don’t try and test everything. That’s just a big hole that you’ll throw your time, your money, and your life into. Rather, we’ve got to focus on where testing adds value. We’ve got to focus on what we call risk-base testing, looking at the things that are the highest risk and highest payback and testing those first. If you can’t test everything, it’s OK.

Cameron: Those are great answers. Now, we have a broader question here. Where do you think the future of technology is going?

Lee: I have no clue. Let me tell you a story to illustrate that.

Cameron: OK, great.

Lee: In 1970, I was a grad student at the University of Utah, working on a little project called the ARPANET.

Cameron: I’ve heard of it, yeah.

Lee: It was an attempt to get some computers to talk to each other. Whatever happened to that thing? Oh, yeah, it turned into the Internet, right?

Cameron: Right.

Lee: You’re talking to an Internet pioneer right here.

Cameron: Oh, fantastic!

Lee: The thing is I had absolutely no clue where that was going to go, where that could’ve gone. I was just a young punk kid programmer trying to get bits to go down a wire and come back. I had no vision. I worked with a guy, his name is Alan Kay, who was truly a visionary, but I can’t predict the future. I have no idea.

Cameron: With the way technology has been going, how do you feel about that direction?

Lee: Well, it’s exciting. There’s always something new, something exciting. In terms of future, let me also add something about the future of testing. I am generally pessimistic. I’ll tell you why. One of the things we do at SQE is provide test process assessments. Organizations can hire us to come in. We take a look at the test process that people are using and give suggestions on how to make it better.

One of the standard questions that I use in interviews when we talk to people and organizations is: What’s your favorite book on software testing? Almost without fail, the answer that I hear every time is, “I’ve never read a book on software testing.” That just frightens me. Testers want to be considered professionals. They want their ideas respected and valued, and yet they’ve never even read a book on their own craft.

The future of testing is an exciting time. There’s so much new with mobile and smart devices, so many exciting things going on, new tools, new processes, new techniques, but I’m generally pessimistic about many of the testers that I meet.

Cameron: Now, to balance this out and look back in time here, back to ARPANET days, you’ve been in the industry for more than thirty years. What is something you wish you realized or knew at the beginning of your career that you now know?

Lee: That’s a really good question. In terms of testing, I wish I had known early on how challenging testing is from an intellectual standpoint, how rewarding it is, and how just plain fun it can be. I spent the first half of my IT career in development—in project management, development management and so on. I wish I had known earlier how fun testing is. I would have started it earlier. I would have made it part of my life earlier.

Cameron: OK, very cool. Once again, you have a session called "Creating a Better Testing Future: The World Is Changing and We Must Change with It." Is there anything you would like to say to the attendees of STARCANADA 2014 before the conference?

Lee: Yeah. First of all, come to Toronto. It’s a fantastic city. Especially if you’ve never been there before. I know you’ll enjoy it. Come to the conference. Seek to learn. Seek to enjoy yourself. And importantly, seek to network. Find people who have challenges similar to yours. Share your ideas with them. A lot of people say that one of the best parts of our conferences is that networking opportunity, so make use of that.

Cameron: Thank you so much. Once again, this is Lee Copeland, and he’ll be at STARCANADA 2014, which will be between April 5 and April 9. Thank you so much, Lee.

Lee: Thank you, Cameron.

 

With more than thirty years of experience as an information systems professional at commercial and nonprofit organizations, Lee Copeland has held technical and managerial positions in applications development, software testing, and software process improvement. Lee has developed and taught numerous training courses on software development and testing issues, and is a well-known speaker with Software Quality Engineering. Lee presents at software conferences in the United States and abroad. He is the author of the popular reference book A Practitioner’s Guide to Software Test Design.