Teaching Software Engineering

Panelists

Matthew Heusser

Connect with me

Michael Larsen

Connect with me

Robert Sabourin

Transcript

For many years, Computer Science was the only way, educationally speaking, to learn about methodologies related to programming software and building large scale applications.

Software Engineering grew out of the need to have a more streamlined methodology, and our guest Robert Sabourin of McGill University in Montreal, Quebec, Canada has been at the forefront of helping to develop those Software Engineering courses as well as teaching them to up and coming software engineers.

References:

Transcript:

Michael Larsen (INTRO):

Hello, and welcome to The Testing Show.

Episode 122.

Teaching Software Engineering.

This show was recorded Wednesday, August 17th, 2022.

For many years, Computer Science was the only way to learn about methodologies for programming software. Software Engineering grew out of the need to have a more streamlined methodology. To that end, Robert Sabourin joins us to talk about developing those Software Engineering courses as well as teaching them to up and coming software engineers.

And with that, on with the show.

Matthew Heusser (00:01):
Well, thank you, Michael. This week, we’ve got a neat little crossover episode, I think, between industry and academia. To do that, we’ve invited Robert Sabourin, who’s based in Montreal, Canada most of the time. Better known as Rob Sab, you may know him from the testing conference land. I met Rob Sab in 2005 when I was his track chair at the STAREast conference. So he’s both Adjunct Professor of Software Engineering at McGill University in Canada and an author. He wrote the book, “I am a Bug”, which is a children’s book about software testing. He is a practicing consultant and he came out of industry. So he was a manager/product director of software engineering for a full career before he went to teach back in 2005. Did I get that story right?

Robert Sabourin (01:02):
Some of the dates might be interesting. It’s hard to say when something starts and when something stops, but my professional career working for other people getting paid to do software engineering, I guess that extends from the late 1970s up until the year 2000. And then from 200 on, my career became more consulting and a lot of my work became teaching oriented. In fact, I always like to suggest 35% of my work was actually getting paid to teach. And I was invited in the nineties to do guest lectures at the university classes in software engineering about the projects I was working on and the things I was doing. That morphed into being invited to being an adjunct professor. And around the time you said around 2005 was when that became an actual real contracted paid gig. Before then it was like invited speaking. And I’ve been working at university and in practice ever since then. There’s very few people, I think, in the software testing universe that pit both sides of the equation, sort of the academic side and the commercial production side. So yeah, that’s me.

Matthew Heusser (02:10):
I found it really hard. I got my master’s degree and I was teaching for a couple years, but I couldn’t keep all the parts moving and support the family. So it’s really kind of a special little creature and it’s so great to have you here. And not only do you teach, not just computer science, but you teach software engineering.

Robert Sabourin (02:27):
Yeah. That’s it exactly. That’s my sort of passion is the sort of software engineering side of it. I always was wondering why… why we didn’t have a program in software engineering when I went to school. So I’ve sort of dreamt that that would come to fruition some days. Now we have programs in software engineering and I’m sort of a big fan of the professional side of it. That includes, by the way, software testing as part of software engineering. For me, it’s very important to look at it from a certain professional perspective.

Matthew Heusser (02:55):
So I had a professor Paul Jourgenson, who’s passed away, and he taught grad courses in software engineering and he describes software engineering as where business meets computer science. Computer science does lots of cool things. Software engineering is interested in, what exactly is it? When is it going to be done? Is it going to work? Is that going to satisfy the customers? And then businesses can come on and answer the questions like, how’s it gonna make me money? Now that’s a 3o second description. How would you describe software engineering? What is it?

Robert Sabourin (03:29):
You’re close. We’re gonna narrow it down and cut it down to shrink it to size here; getting things done. That’s what it is. Getting things done. Turning concepts into reality. It’s a little bit like the difference between theoretical physics and mechanical engineering or civil engineering, where you build bridges and roads. And yet someone has to figure out all the quantum mechanics theories and things. I like to suggest that software engineering is getting things done, the right thing, getting it done well, getting it done timely, getting it as to business focus, getting it done in a meaningful way, as opposed to computer science, which I think is an important discipline, but it’s basically, I think, figuring out how to solve problems with computers as opposed to actually implementing solutions. They really are tightly related fields.

Michael Larsen (04:18):
So if I could jump in here real quick, I’ve always been curious about this, cuz I know that historically some places have had differing approaches to this. As a software tester, as a long time software tester, I came to the field by an oblique route. I entered the side door as the way I like to say it. I fell into the role of being a tester. And it turns out that most of the software testers that I have met have generally done the same thing. They’ve started with programming and they decided they like testing better. Or they got introduced to a testing team, fell into the work and enjoyed it and kept on doing it. That’s my story. It’s also, when I did go back to school to complete my degree, I had a focus and I said, Hey, how can I emphasize the testing aspects of this? And I struggled to find meaningful software testing coursework or anything that even approached software testing. I had to somewhat cobble it out of whatever strands of programming or engineering courses that I was taking. So you’re in the academic space, how common or similar is my approach to many other people’s and how have we improved on that? Since I finished my degree program after a 20-year start in 2005, so almost 20 years.

Robert Sabourin (05:43):
So just to give you some context… In the nineties, there was no such thing at universities, with three exceptions, of a degree in software engineering, the exceptions being the biggest one was Carnegie-Mellon Software Engineering Institute. I believe that there was some stuff in California at the University of California, and I’m pretty sure North Carolina had degrees in software engineering. It was very rare. I did watch the creation of it. And it started with the creation of courses in software engineering that were mandatory for people who were studying computer engineering. So if you look at the evolution of software engineering as an undergraduate program, it would’ve started with mandatory courses in computer engineering. And then you sort of say, let’s fragment computer engineering into sort of stuff that is software engineering and stuff that is other stuff in computer engineering. And that does state back down though.
You’re getting back to the year 2003, 2004, when that started. I was involved in creating the degree program for what’s called a minor in software engineering, which I’m very proud of, very beautiful program. So if you’re studying civil engineering or architecture or something, you can become a minor in software engineering, which I think is just brilliant. You don’t have to become a computer scientist. You can just do your discipline and then learn the software engineering stuff. That’s something that kicked in that McGill probably around 2005. Right now, though, there’s a lot of software engineering programs. What’s rare is the software testing stuff. And I’m proud to say that I created, I think, one of the first three mandatory software testing courses, undergraduate courses. Software Engineering and Practice was the engineering one I did. And then Software Build Validation was the name of, I didn’t invent the name.
They just called it that, but it was a software testing course that was mandatory. So anyone who had a degree in software engineering from McGill University had to take and pass that course, which is pretty cool, ‘cuz they get to call you “sir” for a few months. It’s a long subject . It’s a fun thing to talk about. If you’re interested in the history and the evolution. There’s been a lot of false starts, a lot of people have tried things and backfired. I think we’re in a dismal state right now at the academic level in terms of programs that would inspire people to become, for example, software testers. So much focus is on the constructive part of programming and not, you know, software engineering finesse or the quality aspects of it. And I believe testing just in and of itself, I think is a beautiful practice.
I love it. It’s a passion of mine and I don’t see too many people wanting to become software testers in software engineering. I do see them. I mean I try to mentor them and create them and still will, but it’s like of maybe 200 students have a year, maybe there’s three or four of them that want to be into the software testing side of things. And that’s for me a fairly low ratio. At the same time, I see it pretty high that people who are educated in software engineering are now learning more and more about software testing. So they’re not naive about software testing when they come into the practice.

Matthew Heusser (08:40):
Well, let’s talk about those false starts for a minute. I think maybe we’ve covered some of the same ground. When I took Software Engineering, I got this book by Pressman, which probably 400 pages thick and even going further back. My first class, my first real programming class at Hood College was Assembler and I did all the work and then I read the assignment and it said, “You’ve gotta write a flow chart”. So I was like, “Oh no”. And I went and I made my flow chart, you know, an hour before class and turned it all in and got a good enough grade. I think I got an A-minus. And then I figured out later that’s what everybody did. So we had this formalism and flow charts were boxes and diamonds and program flow. A lot of the Pressman stuff are these logical formalisms, how you’re supposed to do things.
I would dare submit that most of them derived from theory, not practice, and they’re not terrible as thinking tools. They’re probably better than nothing. Parness tables was another, we got a logical formalism for how we’re going to describe the specification. So you can create a table for your input and output. Nobody did it. It was too hard. It was around the turn of the century that we got Extreme Programming and unit testing. And we actually got a way to do it that came from practice back to academia that these things actually work for us. So I’m curious your thoughts on that. And also, what do you teach in your testing course? Tell us about it.

Robert Sabourin (10:12):
So start with, first of all, I love your allusion to, or reference to, flow charts. Go to 30,000 feet, where we’re talking about the digital models and I love to encourage and foster the notion of creating a sort of a model of what you’re gonna do to understand it and refine that model and iterate that down to eventually some sort of solution. Definitely, I’m a huge advocate of visual modeling. When I teach software testing, I do teach a lot of stuff related to visual models in it. And then I would include of course, flow charts, control, flow, diagrams, story, boarding, mind mapping. I would take the whole UML category of formal documentation and say, it’s a lot of stuff that’s really good in the modeling, the sequence diagrams, the stuff that you have in use case models. This is all really cool stuff. And I’d like to encourage people to deliberately create visual models and know multiple different techniques, treat it like blades of a Swiss army knife, where we have multiple techniques and dive in.
So you hit the nail on the head when you’re talking about the flow charts there and yeah, that’s something that’s also, it’s a sort of a lost skill by the way. I’m working a lot right now to try to go through things that we used to teach and focus on years ago, that seemed to have disappeared a little bit because of technology. It doesn’t mean we don’t have to model and think it just means that we have to look back and said, “Hey, we used to do really cool things with flow charts. So why don’t we do flow charts anymore?” And, of course, the answer is we actually, the people who are shrewd in this matter really do flow charts, but there’s a lot of people just don’t know what they are and how they might fit into the problem space. So it’s sort of like introducing people to this at the time that’s formative and that’s, if you wanna correlate this now with instructional design, try to try to find out what is the concept you wanna introduce people to before they get sort of corrupted by all of this template oriented, cut and paste development that Google has made so available in the world.
And by the way, that’s testing and programming, not just programming, that’s got the problem. I’m a huge fan of tabular requirements. By the way, I did so much work in that in the 1990s. And I’m glad that you mentioned that too. Cause when it came out, that was like, “What a solution! What a beautiful solution.” And then that was taken even further by all the work that was done with the Fitnesse, I don’t know, Fit for software engineering, the acceptance test during development models that came around, there was fascinating stuff. This is also something that people just don’t seem to know about. I think there’s really cool, useful modeling techniques around that that are useful. Now you said also Extreme Programming came around, of course, Kent Beck popularized Extreme Programming, but Test First Development predates actually Kent Beck’s work and was something that was advocated a lot at old conferences.
Like if you went to a STAR conference in the nineties, you probably get a t-shirt with a picture of a horse and a cart, but the horse is pushing the cart. And under the text says, “Test first, code later!” and this old notion of Test First Development was something that I used to jam with people about so much. And of course in that era, we didn’t have the tools. So the only people who could get away with test driven approaches to development were people who were toolsmiths, What popularized it was not really Kent Beck’s work, although his work did give us a foundation to talk about it. So we had a pedagogy to talk about it. What happened was the tools suddenly become widely available and part of the IDE. And of course today it’s so available that anybody can do TDD with the tooling.
But imagine if you knew to do Test Driven Development in 1997, but you had to make all your own tools, all that was hard, and you were so distracted from your problem, “I gotta make my tool to do the testing. Then I gotta do the testing. Then I gotta work code.” It’s a very distracting thing, unless you’re a tool. And of course I don’t even hear about toolsmiths any more. We used to talk about that in software engineer, as I’m sure you remember, if you’re old enough to talk about tables and the advent of XP. In terms of teaching, when I teach my software engineering and practice class, I definitely have a very important assignment, which is to implement an application with Test-Driven approaches. And we go through every single iteration and they go through the whole thing from beginning to end and make sure that people really show that the test fails.
Then write the minimum code, then show it passes, then show the other ones pass and keep doing this over and over again. And it’s painful, but you give them a small but hard problem to do. And you throw out the crap that gets in the way of distracting them. Like for example, user interfaces, I don’t need a user interface. I’ll just send API, keep it so that you can focus on the cognitive aspects of the approach. So Test-Driven stuff for me, I believe, it’s critical for introducing developers to the concept of not just testing first, but also deliberately designing the test. You’re deliberately designing the code, deliberately design the test, do it purposefully. That’s sort of where I see it fits into the curriculum, build into the course, teach the method, make it worthwhile. So for me, it’s like 20% of the grade is from this.
It’s not just like 2% or something. It’s a serious chunk and give them a problem. As it says, don’t distract them with all this crap like fancy JavaScript with user interfaces everywhere, give them something that’s hard business logic, not a trivial thing, a hard thing to solve where they can focus on, “Okay, let’s figure out how would you test this? How would I test it before I write the code in, get them to go through it step by step by step, by step, by step.” And of course, document steps, which is tedious and painful. In any commercial product, you would never do that. But in an academic thing, you force them to go through the steps, force them to look deeply at what they’re doing.

Matthew Heusser (15:59):
Well, that makes a lot of sense. I appreciate it. And I really appreciate the way you, in a positive and constructive way… So if we look at things like Parnus Tables or data flow diagrams, those actually were the right thing. Maybe their time wasn’t a good time for it, or they weren’t detailed enough. Academia is really good at coming up with proof of concepts that don’t quite complete the problem. And then industry comes in and finishes it. So Test First Development was the very beginning of my time. And what I saw at the time was it was a lot of get requirements that include.. I think Fitnesse is a fantastic tool. I think the idea of when this function is called, we should give these inputs and expect this result.

Robert Sabourin (16:43):
Matt, if I can put a plug in for a book, the book for Fitnesse, “FIT for Software Development” or “FIT for Developing Software”, this is just fantastic. One of the best books on test automation that I’ve ever read, and that was describing how to use Fitnesse to solve problems, Ward Cunningham and Rick Mugridge, I think, are the authors.

Matthew Heusser (17:00):
Oh, Ward Cunningham. Anything Ward Cunningham touches is great.

Robert Sabourin (17:03):
That’s so influential for me, that book. I just, I want everybody to read it, just to look at how to write a book. This is well done, organized, instructive, practical. Sorry.

Matthew Heusser (17:16):
I don’t have that one on my list. I’ll add it to my list, but just the idea that when you think about that, that’s just a spreadsheet and then to execute it, it does not that many lines of code to say, find the function with the name of column a pass in column C D E, and F as parameters expect column B. That’s not that hard. And I…

Robert Sabourin (17:36):
Matt, Matt, do you wanna hear a Slime Bucket thing I did about that? Or would that be, this is fun. A number of years ago. Of course, I was really concerned with teaching people about TDD and Example Driven Development approaches and methods. And ATDD. So now of course, BDD fits in too, but all of these double-D things, I wanted to teach it. And so what I did was I gave a problem to my students and I said, “Okay, solve this problem with Fitnesse, which includes the tables and the fixtures, that’s the integration of the table and the application test, and then take the exact same problem and solve it with Gherkin Cucumber frameworks with the step definitions.”

Matthew Heusser (18:19):
Oh my

Robert Sabourin (18:20):
For the exact same problem side by side, and then do a comparative analysis. And it’s awesome. I got some beautiful results from that.
And one of them, I worked with a student because it was just so great that I got permission to share it. And when I’m teaching professionally, I will very often show this comparative example of the exact same problem, solved both ways. And of course the problem we chose, I believe we were looking at estimating the shipping cost. I mean, testing, shipping cost calculation in a shopping card on amazon.com. So most people would understand what we’re doing here, but it’s, <laugh>, it’s actually a pretty interesting thing to describe it with the Fitnesse table and with Gherkin and look at the two solutions side by side. And quite frankly, the fixtures had almost exactly the same amount of code as the step definitions. From a coding perspective, it’s about the same amount of work. It’s just the conceptual modeling approach is different. So I think if you can solve the problem with one, you can solve it with the other.

Matthew Heusser (19:13):
Yeah. I think there are different kinds of problems that lend themselves. So we may be getting… for the audience. Gerkin is the GIVEN, WHEN, THEN language, which you can express in things that look something like English. And then you have to write code behind that, to do the things that you’re talking about.

Robert Sabourin (19:35):
Exactly.

Matthew Heusser (19:36):
And Fitnesse is more like a spreadsheet that I described earlier. Yep. I agree. You can do them either way. What I found is that if you actually have multiple steps to do first, you log in, then you search for this, then you do that. Then you do that. Then you do that. If it’s activity based, I tend to like Gherkin and if it’s more formulaic or function based, I tend to like Fitnesse, though you can make a series of calls in a row that become a test.

Robert Sabourin (20:11):
Yeah. I’m trying to address the issue of the instructional approach here. Let’s say I have 200 undergraduates and I want them to be aware of this stuff. When I say this is a Slime Bucket, I’m trying to make them aware of Example Driven Development and how it works. And so I’m going through the whole problem space, the whole stack, the whole thing from two different approaches, what they’re doing, of course fighting the slings and arrows of outrageous coding to build their future files and to build their step definitions and all this type of stuff. But in the end, they learn a lot about how to model problems this way. And hopefully they can come to the point where they have the wisdom to make statements like they’re making, which is to say, “Hey, I judge this one is more appropriate when we’re doing step by step for this and that one might be more appropriate for different types of business logic.” I want them to at least walk outta school with that in the toolkit. <laugh> They’ve thought it through and they’ve done some deep comparisons of the two. Of course, I’m trying to make them work very hard and do the testing and programming.

Matthew Heusser (21:07):
Maybe we can riff on that for a minute. Cuz I’ve got the same. It’s not really a problem. It’s just, I think one of the reasons BDD took off was that programmers wanted to write code. So when you said, “Oh yeah, it’s… we can call it testing, but it’s really programming”, Boom! higher acceptance rates. I’m not seeing long-term sustained success there over the decades, but certainly way higher than when you said you programmers test things by hand yourself and you debug and unit test. But I’m seeing the same thing with what’s called test automation, where there is a naive belief that… I had startups talk to me, “We need test automation”. And I’m like, “How about you do some actual testing first?” There’s a naive belief that programming is going to solve problems that usually can be educated out. But it sounds like you’re dealing with some very similar things where you’re saying, there’s this, “I wanna write code. So I find a way to teach them that involves writing code”?

Robert Sabourin (22:06):
Yeah. I’m working on motivation here for our undergraduates. For some reason. And I guess this is just, they love programming. We have over 4,000 applicants every year for the program and only like about a hundred of them get accepted and all of them are superstar programmers. So like before they even started the program at university, these kids are superstar programmers. They’re not going to university to learn how to become a programmer. They’re going there to hone their craft. Some of the stuff you see, it’s amazing how they program their way around all sorts of things. And they’re good. They’re really good at programming. I don’t wanna put them down for that. I’m shocked, always, at what they can do with their skills and programming, but I’ve got to teach them to do other things than just write a lot of code. And so that’s why I get this Slime Bucket.
How do you motivate them with programming? So let’s say you wanna teach test design to programmers. Turn it into some sort of programming activity. And I’ve done this in all sorts of cool ways, but one of the coolest ones was at UC Berkeley where I developed a unit testing course for people who are developing software for IoT systems, Internet of Things systems embedded in appliances. And we had to teach these guys how to do really great unit testing. What ended happening was it’s almost became like a competition. You turn it into a programming competition, you teach them a couple of test design techniques. Then you give them a couple of embedded problems with a whole IDE setup and then let them compete with each other to try to come up with the coolest solution. And you start finding that because it’s programming and they’re feeding to be the better programmer. They actually do apply what you teach them. So getting programmers to learn about testing. So that might just be one of the secrets that I’ve learned, to turn it into an interesting programming challenge.

Michael Larsen (23:50):
This reminds me a lot of what I just recently… I shouldn’t say recently, this is a few years ago, but it’s recent for me in the sense of my career. So we had this situation where we had all of these disparate quality assurance groups that we’re all doing different things. And the vice president of QA was looking for a “one ring to rule them all” kind of a solution. And I thought it was interesting, was that cuz she said at the time, “Hey, here’s some of the things that we’re considering, here’s some of the things we’d like to do, but we don’t necessarily just want to say, here’s the solution. Now go learn this and implement it. We’d like to have your feedback about this. So are there situations that you think might be beneficial that we should consider?” And I remembered thinking at this time, serendipitously, because I was looking for a workshop topic for PNS QC, I think in 2017, 2018, about that time period.
And I thought, I know how about I pitch, what does it take to build an entire ground up framework? And I said, I’m gonna use Java because a lot of people use Java. I’m gonna use cucumber because everybody’s talking about it. And then I’m gonna say, look, here is your roadmap. I’m gonna give you a speed walkthrough to play this game of putting together a software testing framework, even if it’s very basic, but here’s all the steps you need to go through. And I presented that and by the time I presented that and a bunch of other people had presented other ideas, since so many people had demonstrated other possibilities and other frameworks and other methodologies that were already built in, in certain cases it gave, instead of us trying to figure out a “one ring to rule them all”, we came up with “a few rings to rule most”, rather than forcing everybody into one approach.
But what was cool about it was that testing and the test automation side got a real shot in the arm because instead of just, “It’s mandated here, go learn Java and figure this out”, it’s, “Wait, what do our services in our products really benefit from?” And it turned out that a lot of our software was developed in the Microsoft universe. And so using .NET as a basis made a lot more sense than it would to try to just plug in a whole bunch of different things and hope for the best. So yeah, we still had a fairly unifying framework, but how we went about using it was open to the individual teams and the individual needs and no two teams used it exactly the same way. And that was okay. And I thought that was a really neat thing to actually go through and be able to experience that and actually take some of what I’ve learned in the trenches and teach it to other testers who said, “You know, I probably wouldn’t have approached it that way.” So I thought that was pretty cool.

Robert Sabourin (26:47):
Well, it’s an interesting instructional approach. I’ve taught subjects in dramatically different ways. So the approach you just mentioned, I think fits very nicely in when I’m doing instructional design and training onsite for companies with specific needs. And I say that because I like what you described and I call that a problem solving approach. So what you did is you took a problem or a problem solving approach and you came up with a way to solve the problem. And when I’m teaching academically, that’s where I get to the Slime Bucket stuff, tricking people to learn things. I don’t know what their end goal is. There is sort of, you’ve gotta create a formative instruction to people and give them tools that they will use in all sorts of problem solving. Whereas when you’re looking at the framework example you gave that sounds to me like you’re trying to solve a specific business problem or technical problem.
And I like that. I like automation to be looked at that way. In fact, I advocate that so much these days as test automation is part of problem solving. Not all automation is regression, not all regression is automation, but what is true is that computers give us powerful tools. Programming is the way we can use those computers to solve almost any imaginable technical problem you’ve got. There’s solutions with, “You have to write code, you have to write programs and therefore you can sort of look at programming as part of the problem solving things.” I think you’re gonna be ahead of the game. And that’s where test automation fits in. For me, it’s part of the solution. It’s part of how do you test it. Automation is one of the tools I’m gonna use to help me solve the problem, but the problem is not. How do you automate the testing?
The problem is how do you test the software? And automation is part of the solution and that’s a little bit of philosophy, but it does fit into instructional design too. You know, it’s gotta be looking at what are you trying to teach people? Are you trying to teach people to think on their feet, to use all their tools at the disposal to get job done? I like to think that that’s important, but then when you’re looking at a specific company that is specific problem space, maybe let’s build a framework, maybe let’s, you know, do something to show them very tactile, very hands on how we can work this and get the thing done. Reminds me of a big oil company that I worked at, where they basically were big advocates of the educational approach, where they would basically have the whole team create training objectives and then try to learn as a team and then review it and keep going and going and going a little bit like someone would do in martial arts when you’re trying to master some of these skills, I don’t know proper words from their models, but it’s come up with the goals, try to achieve it, learn from that, adapt and keep going.

Michael Larsen (29:25):
Well, I can’t speak for every martial art, but for the ones that I studied, the term that we oftentimes used was kata.

Robert Sabourin (29:32):
Kata. That’s the term. That’s exactly it. Yeah. That’s the right term. Thank you.

Michael Larsen (29:35):
And the idea behind kata is that that is the ideal form. Of course, every kata that you learn is going to fall apart the instant you are up against an opponent who isn’t playing by the same rules. <laugh> you know, so the…

Robert Sabourin (29:52):
Fair. Fair enough. Again, we’re going back to the point. It’s a metaphor, right? So right. We’re not doing the same thing in software engineering. When we’re trying to teach a team how to solve problems for me, I love the feedback part of it and the fact that you keep practicing and then you observe what you’re doing when you’re learning.

Matthew Heusser (30:08):
Fantastic. I think that’s a good place to go next, feedback and learning. So if our audience listened to this and thought, “Wow, there’s a bunch of stuff here.” And frankly, we threw out a whole bunch of words, whole bunch of ideas that maybe weren’t described so well, where could they go next? Is there a book they should buy? Is there a class they should take? Is there a website they should search for to sort of branch out into this world of software engineering that we just don’t talk about enough?

Robert Sabourin (30:41):
So if you’re looking for references, I’m working very hard to put together papers and articles in the area, which is exactly what you mentioned, call it active feedback loops and software testing. This will be that one that’s gonna be coming out soon is gonna be part of PNSQC, which also is mentioned in this conversation. So the PNSQC is the Pacific Northwest Software Quality Assurance group. They have an annual conference, they publish proceedings and I’ve got a paper that I’m coauthoring with Chris Blain on active feedback in software testing. That touches a lot of the stuff we talked about actually is in that article. So that’s gonna be out pretty soon. I can’t give you a copy until the publication date, but that comes up with the proceedings. I wrote a book on the subject, which hasn’t been published and I don’t know if it’ll ever be published, but it’s called “Charting the Course: Coming up With Great Test Ideas Just in Time”.
I’m perfectly happy to give anybody who wants electronic access to that. And that has a huge bibliographical reference on some of the subjects we’re talking about. In terms of books to read, there’s a lot of great books. We talked about the Fitnesse book, read about Behavior Driven Development and The Cucumber Book is a good starting point. It’s just read about the stuff we talked about. The framework of “FIT for Development”. Those are great book references. In terms of software testing, there are some that I would dissuade you from reading. For example, if you see a book that’s called unit testing for JavaScript or unit testing for this or unit testing for that, that whole series of stuff is propagating the myth that learning the tool is learning unit testing. They don’t do test design. They do how to use the tool. They teach you very well how to use the tool. I don’t wanna dis the books. They teach you how to use the tool, but they don’t teach the test design stuff. So I would urge people to focus on test design related thinking and those things. Still the best book on that I think is Lee Copeland’s “A Practitioner’s Guide to Test Design”. It’s important to look at multiple sources. There’s a lot of different opinions and I think it’s worth taking a look at them. There’s some really interesting insights into this.

Matthew Heusser (32:49):
And speaking of books, our next episode is going to be on the “How to Reduce the Cost of Software Testing” book, 11 years after publication. Did we learn anything? Was it any good? Was it of any lasting impact? If you want to get that, you can… I’m sure you can get it on Kindle for a few dollars. I think it’s on Safari free with your subscription if you have access to that service. It’s not a cheap book. And I think what we did there was throw out a bunch of ideas that at the time were new and today have had inconsistent adoption. Like, they’re old news to some people and they’re totally new for others, which I think is kind of the lesson of this podcast, too. So thanks so much for being on the show, Rob and hope to have you back soon.

Robert Sabourin (33:38):
Really fun talking to you guys. Thanks for everything.

Michael Larsen (33:40):
Thanks for having us and thanks for joining.

Matthew Heusser (33:42):
Bye bye.

Robert Sabourin (33:43):
Take care.

Michael Larsen (33:44):
Catch y’all later.

Michael Larsen (OUTRO):
That concludes this episode of The Testing Show. We also want to encourage you, our listeners, to give us a rating and a review on Apple podcasts, Google Podcasts, and we are also available on Spotify. Those ratings and reviews, as well as word of mouth and sharing, help raise the visibility of the show and let more people find us. Also, we want to invite you to come join us on The Testing Show Slack channel, as a way to communicate about the show. Talk to us about what you like and what you’d like to hear, and also to help us shape future shows. Please email us at thetestingshow (at) qualitestgroup (dot) com and we will send you an invite to join group. The Testing Show is produced and edited by Michael Larsen, moderated by Matt Heusser, with frequent contributions from our many featured guests who bring the topics and expertise to make the show happen. Additionally, if you have questions you’d like to see addressed on The Testing Show, or if you would like to be a guest on the podcast, please email us at thetestingshow (at) qualitestgroup (dot) com.

Teaching Software Engineering

share

Panelists

References:

Transcript:

Recent posts