The Testing Show: Ubiquitous Computing

Panelists:

References:

• Musical Instrument Digital Interface (MIDI)
• Akai MPK Mini II MIDI Keyboard Controller
• Line 6 Mobile In app turns your iPad or iPhone into a multi-effect amp
• Ubiquitous Computing
• Tesla’s Autopilot: The smart person’s guide
• Philips Hue: Personal Wireless Lighting
• The Testing Show: Unified Engineering
• TestBash Philadelphia 2017 Is Live
• PNSQC 2017: Senses Working Overtime: Improving Software Quality Through Accessibility and Inclusive Design

Transcript:

MICHAEL LARSEN: Hello, and welcome to The Testing Show.  I’m Michael Larsen, your show producer, and today we have a small, but intimate, panel with our host, Mr. Matt Heusser?

MATTHEW HEUSSER: Good morning from me and everyone else who happens to be here right now.  So, dear listener, good morning.

MICHAEL LARSEN: We’d also like to welcome our guest today, Mr. Paul Grizaffi.

PAUL GRIZAFFI: Hello, thanks for having me back.

MICHAEL LARSEN: Please tell me I pronounced that right?

PAUL GRIZAFFI: Grizaffi, absolutely.

MICHAEL LARSEN: Grizaffi, all right.  Thanks for joining us today.  I’m going to do my Ed McMahon thing and say, “Here’s Matt.”

MATTHEW HEUSSER: Thanks, Michael.  It’s a little bit smaller show today (just the three of us), and there’s a couple of issues that have come up recently that I wanted to talk through.  But let’s start with this idea that manual testing is dead, and we’ve heard it a million times.  What’s interesting and new is, I was talking to Jason Huggins, the original creator of the Selenium Project, a few years ago and he said, “Matt, if you want to do manual testing, what you want to do is you want to be working with some cutting edge technology that there’s no framework for.”  So, at the time he was talking about Google Glass, “Just test Google Glass.”  Before that, it was Android.  When Android first came out, there wasn’t any of this Appium stuff.  You just tested it.  When Silverlight came out.  Generally speaking, the test frameworks follow the development frameworks, and they lag.  So, in that intermediate space, there’s a lot of room for a lot of good human testing.  When I said, “What’s new and exciting in the world of testing,” Huggins’ reply was, “Hey, Tesla Motors is hiring a field test engineer.  You, for example, would help bring Tesla’s Autopilot to the next level of autonomy by testing features including Autosteer, Auto-Lane Coverage, Traffic Aware, Cruise Control, Summon, and more.”  A lot of that is going to, apparently, be sitting in an actual car doing testing and you need a driver’s license for it.

MICHAEL LARSEN: Also, to add to that too, you also need to be in LA.  This is not a work-from-home gig, [LAUGHTER], obviously.

MATTHEW HEUSSER: I would think not.

MICHAEL LARSEN: Yeah.  Sorry.  Don’t worry about working on this one just yet.  Now, that could be cool someday.  If, “Hey, can I work from home?  It’s okay.  I’ll just drive the car.”  [LAUGHTER].

MATTHEW HEUSSER: I’ll drive the virtual car in the virtual world.

MICHAEL LARSEN: With the actual car on the actual road.  Now, that’s when we’ll know that we’ve reached peak absurdity.  [LAUGHTER].

MATTHEW HEUSSER: I was think it would be in Second Life or something, and the whole thing would be simulator driven.

MICHAEL LARSEN: [LAUGHTER],

MATTHEW HEUSSER: But, I wouldn’t really trust that.

MICHAEL LARSEN: But, in any event, just, for those who are interest, of course you can go to https://www.tesla.com/ and look at their Career listings.  The job is for Field Test Engineer in Los Angeles, specifically it’s in their location in Hawthorne, California.  It is a mixture of working with both automated tools as well as manual tools and direct interaction with the ultimate hardware platform, as in both a self-driving and an actual manually-driven vehicle.  They definitely want to make sure that you are somebody who’s got some experience with either vehicle dynamics, robotic systems, or consumer electronics hardware or software, which means this is probably one of those areas where, if you are a super, geeked-out game tester, who has done a lot in the way of hardware hacking, you might actually be a really good fit for this.

MATTHEW HEUSSER: Yeah.  Well, they also say, “BS, MS, or PhD.  PhD in Computer Science, Information Systems, Electrical Engineering, or the equivalent.”

MICHAEL LARSEN: I think that’s the first time I have ever seen “PhD” as a job requirement listing or even as a desired—

MATTHEW HEUSSER: Oh, Google used to do it.

MICHAEL LARSEN: —for a test position.  Wow.

MATTHEW HEUSSER: Oh, “For a test position,” yeah.  Google used to do it, but it was for development gigs and that was when they were small.  They lowered their standards at some point and said, “Oh, it’s okay if you only have a four-year degree from one of the world’s top engineering schools,” [LAUGHTER], in the particular discipline.  Yeah.  So I was thinking of that, I’m surprised.

MICHAEL LARSEN: I actually know somebody who is an engineer with Tesla specifically.  It might kind of fun as a follow on maybe to talk to him.

MATTHEW HEUSSER: Get him on the show.

MICHAEL LARSEN: He might be able to be on the show and tell us a bit about the engineering and testing side of things.  I’m not going to promise that, but let me reach out to him.  If he’s game to be on, then maybe I’ll say, “Hey.  Let me edit this into the show and say you might be coming on pretty soon.”

MATTHEW HEUSSER: Oh saying, “I might, maybe, someday, do something,” is absolutely game for the show.  Come on, man.  You’ve got all this extra language you need in there with that.

PARTICIPANTS: [LAUGHTER].

MICHAEL LARSEN: Woo, covered all my bases.  Excellent.

MATTHEW HEUSSER: One thing that surprises me, and this is just something personal, when they say, “Get a degree in electrical engineering,” that make sense.  A degree in CS, less sense.  IS, even less sense.  To me, just because.  Maybe, I’m an extreme example.  When my children were born, I kind of stepped back from any kind of significant home repair, and now that they’re older I’m just getting into it again.  Physical tools and me, I’m not so good with the physical tools.  A car, car engine parts, and how it runs, it seems like that’d be kind of important.

MICHAEL LARSEN: Realizing, of course, that we’re talking about a vehicle that does not have an internal combustion engine.  So, all the stuff that you and I have learned about how engines work, probably not very applicable.

MATTHEW HEUSSER: So, last weekend, I was over with David Hobbe.  I don’t know if David’s been on this show, but I’ve interviewed him before.  We spent part of Saturday just working on cars, and I was just amazed at how 20th Century a typical car is today.  Cruise Control is these physical-ly, little-ly things that push this thing up to this amount.  It’s like a string or a wire that physically pulls the throttle back to the right level and then keeps it there and all that.  There’s a computer that’s modulating that and is what you press when you press your Cruise Control buttons, but the actual implementation is all mechanical.  The Tesla ain’t got none of that.  It’s all, [LAUGHTER], on the computer, and then it’s just sending voltage to different systems.  That’s going to be very different.  So, maybe CS is appropriate.  I don’t know.

MICHAEL LARSEN: Yeah.  Tools that I think that I’m familiar with or I’d love to get back into working with certain things and you’d think that a certain level of understanding in the way that they’re designed, and nowadays even things I used to take for granted are totally different.  Recently, I started looking into redoing an electronic music production environment.  I have this equipment that I’ve had for years.  I built a studio back in the early 1990’s—a MIDI studio.  I bought a Roland JD-800 Keyboard, more MIDI cables that I could ever imagine using, an Alesis D4 Drum Brain, along with pads, MIDI guitar inputs, etc. and I put something in the neighborhood of $20,000.00 to get all of the equipment for this.  It was just hulking.  Just keeping it wired… and entropy set into the system.  You would think that if you just plug everything in, it’s going to work.  Right?  No.  I plug everything in and for whatever reason I’d have to go away for a week and I come back to it, and nothing worked the same.  I had to go back and check everything, every time now.  Now, I recently picked up a Boss VE-20, which is a vocal processor.  It’s a little stomp box for a singer.  Yeah, process that for second.  They make stomp boxes for singers now which I think is hysterical, but cool.  These things are just amazing.  The level of software control and the options that are built into these devices now.  I see that there are certain ports that you can plug into them.  I think, at this point, you still have to manually configure these, but I guess you probably could plug into a system board and you could run an API to actually test them.  Paul, did you ever think you’d see a day when an API would run your pedal boards?

PAUL GRIZAFFI: I never considered any of that, right?  I mean, some of that stuff was even kind of magic to me because I got a Computer Science Degree, but it was hard core computer science.  It was not engineering.  Hardware was what ran software, and that’s about the extent of that.  [LAUGHTER].  We did some architecture, internal architecture stuff, but that was about it.  So, when we’d get to my EE friends who were doing their own speaker design and doing their own effects board designs and stuff, they could explain to me what they were doing.  I could Grok it all from just sort of a processing standpoint.  But from a sitting down and doing it and working with the breadboards and all that, that was all magic to me.  So, no, I kind of can’t really.  Conceptually, I get it.  But how all the internals work, that’s all voodoo to me.

MICHAEL LARSEN: Yeah.  Definitely.  I’m feeling much the same.  The really weird thing, my guitar player in my group, he’s farther along on the curve that I am.  He does a lot of the tracking and recording and mixing and mastering of our demo tracks that we do.  He explained to me.  He says, “Oh, yeah.  You know, I’ve an Akai MPK Mini.”  He told me all this software that he had available to him, and I realized as I was talking to him, this little tiny keyboard that has maybe two octaves on it and a couple of pads and dials and controls plus this kit of software that he has, he was able to recreate all of this equipment that I spent some $20,000.00 on, 20-some-odd years ago.

PAUL GRIZAFFI: Uh-huh.  [LAUGHTER].

MICHAEL LARSEN: It all fits in his MacBook Pro, and he’s got this little keyboard with a USB cable that plugs in and, literally, he can control everything that I used to have a room full of equipment to do.  I just sat there and stared and I thought, “Wow.”  [LAUGHTER].

PAUL GRIZAFFI: There are even apps that you can get for your phone and then there’s some sort of Dongle or piece of equipment that attaches to the phone.  You plug your guitar into it and it’s basically an effects box on your phone.

MICHAEL LARSEN: Yeah.  I have one.  Line 6 makes it.

PAUL GRIZAFFI: There you go.

MICHAEL LARSEN: It is crazy.  I’m sitting here looking at this little box that plugs into my guitar, plugs into the phone, and it’s an entire amp modeler.  You can make any sound and route it out to—

PAUL GRIZAFFI: Yes.

MICHAEL LARSEN: —a mixing board, and it’s got the sound of a Line 6 Amp.  Simulated, but still pretty darn close to what a Line 6 Head running through a set of speakers would sound like.  Sorry.  Geeking, getting a little bit off topic, but the point being, to bring this back.

MATTHEW HEUSSER: No.  I think we’ve discovered the topic.  Right?

MICHAEL LARSEN: [LAUGHTER].

MATTHEW HEUSSER: Which is, there’s a term for it, “Ubiquitous Computing.”  When I was in grad school, we thought there was going to be a smart-house or something and there were wires everything, and we just didn’t get it.  It amazed me how the visionaries of the future were wrong.  We used to have a phone.  We used to have a camera, and we used to have a laptop.  A video camera, audio recorder.  They’ve all come together, and they fit in the palm of your hand and we have an incredible amount of computing power.  Now that computing power is integrating with the world around us.  So it’s integrating with your guitar, your amp, and your car.  The Tesla Smart Car will pull over to the side of the road and download its newest update, which just blows me away.  So you can do continuous delivery on your car, in theory, sort of.

MICHAEL LARSEN: It’s nuts.  Yeah.  Just the idea of having my car tell me, “You have an update.  Would you like to pull over and download it?”  There’s a part of me that, that just terrifies.  I’m still used to this whole world of like, when you do an update, there are little bits and pieces that just do weird things.  The idea of me pulling over and saying, “Okay.  Update my car’s software.”  “Okay.”  And, “Let’s go.”  There is a part of me that honestly I am just not there yet.  I just don’t trust that at this stage.

PAUL GRIZAFFI: I’m happy to be an early adopter on iOS with my iPad because that iPad is not critical to my existence right now.

MICHAEL LARSEN: Right.

PAUL GRIZAFFI: But my phone, no.  “Oh wait, there’s a new version of the Android OS” for my phone, yeah, I’m going to let that bake for a month before I take that down and see who else is having which problems, usually around battery life, and then certainly not on my car.  That’s just not going to happen.

MATTHEW HEUSSER: It’s amazing.  I think that the concept—couple of things—about the Internet of Things.  A few years ago when IoT “came hot,” and really I’m not a buzzword guy, and almost nobody was testing Internet of Things.  We saw conference tutorials by people who had never done Internet of Things testing and the conference tutorial was, “How to Test” this—I don’t know—toy car that you drove from your phone, but a lot of that really is Linux Devices—like your NEST (thermostat).  They need to be tested.  Now, we’ve expanded testing from like, “Here’s a little app” to “Here’s an entire device with the Wi-Fi connection.”  So, we should be thinking about security, performance, and the long-term problems.  A lot of testing is, “Test all the features.  It works.”  But, for something like a thermostat, you probably want to seriously stress test that under strange conditions for a really long time and not just one of them.  So, you want to fluctuate the temperature, you want to see if there are memory leaks.  There’s a whole bunch there.

PAUL GRIZAFFI: Do you think you might want to see what happens when it loses connection to the main server?

MATTHEW HEUSSER: Yeah.  Absolutely.

PAUL GRIZAFFI: [LAUGHTER].

MATTHEW HEUSSER: When the wireless goes down, for how long?

PAUL GRIZAFFI: Exactly.

MATTHEW HEUSSER: My water heater has the potential to work off your phone.  We just never hooked it up to the Wi-Fi and we use it like a water heater, because I don’t really need my water heater to Tweet at me that, “I’m using a lot of water.”  Like, [LAUGHTER], you know?

MICHAEL LARSEN: I love the fact that I live in a town—it’s called San Bruno, by the way, for those who are interested, we’re about 10 miles south of San Francisco—and we are one of those towns that still has a Municipal Cable Company.  Comcast, AT&T, whatever services are.  I mean, I guess, if you really want to go with them, you can, but we have a City Cable Company.  The nice thing is that the City Cable Company is a nice alternative.  For most people who just say, “You know, yeah, you just want to have basic Internet or you just want to have a few devices in your house,” it works great.  It’s pretty fast.  It’s relatively inexpensive.  Their service is actually pretty good, but there is a limit (generally speaking).

You have a Home Tier and then you have a Business Tier, and right now, I am so butting up against the edge of that Home Tier because I have so many devices in the house between myself and our kids.  We’re not even really looking at much Internet of Things stuff yet; and, part of the reason why we haven’t is because we have that limitation on the number of Mac addresses that you can actually assign to our connection.  When we get to the point where we overload it, it’s a common complaint in our house, “Okay.  Who’s on the Wi-Fi?  I can’t get my device on.  I can’t download this.”  You know, “I can’t load this,” and it’s just the common request.  I’ve shown every kid in the house, “Here’s the home router.  Here’s the page.  Go to the “Setup: Configure” page. Just press ‘Reload Router,’ and what that does is it wipes away the Mac addresses, and then first come first serve.”  You know, so I’m sitting here thinking about, again, with this “Ubiquitous Computing” idea and having the Internet of Things monitoring all of this stuff, and I’m think about somebody like myself or my neighbors and such, “Are every one of us, if we want to take advantage of these things, going to have to literally jump up to Business Internet to be able to have that leeway, or how much is it going to cost us to have the service necessary to have the breadth of addresses needed so that we can actually run these device efficiently?”  Things like security cameras, you can actually use your Wi-Fi or Bluetooth or whatever to do mood lighting around the house.  I’m spacing on the company.  I think Siemens or whatever has this whole lighting system that you can use that just basically you can even talk to your Amazon Echo or Siri and say Siri, “Dim the lights in the kitchen,” and it will dim the lights in the kitchen. [Editor’s Note: Philips Hue Lights  “How many of those addresses have to be mapped?  How much maintenance do you have to do?  How much of your network has to be optimized to be able to do this?”  Nobody ever talks about that.

MATTHEW HEUSSER: Yeah.  What I think is really happening now, it’s kind of like programming, because there’s lots of different waves of programming.  There was the COBOL people, which are still around, although from what I’m seeing, except for the biggest of the banks, it’s getting phased out.  Then, we had the client server stuff and the Webby stuff and now the Responsive Design stuff, and each generation is still around.  IOT is big enough now that there are jobs for it, that people are starting to do the testing for it.  I think there is a chance—I don’t think it’s a 100 percent chance—that it will get so big that it’s going to be a significant driver of the industry.  It’s like the Tesla stuff, if you prepare yourself now, when those gigs come out, you’ll be better positioned for them.  Most of the advice on IOT testing that I’ve seen is relatively vapid and weak and that’s great, because it’s the Wild-Wild West and we all get to explore and figure it out for ourselves.  It would be hard to come up with a comprehensive list of ways to test a thermostat.  The performance and the security stuff, if you’re talking about a device that monitors something and then sends message out into the world based on that, maybe we can come up with some standards for that.

MICHAEL LARSEN: Yeah.  Paul, I know that we’re talking about this from the perspective of these opportunities just for testing in general, there is, of course, going to be a convergence here.  If any device runs software, at some point there has to be an interface for it; and, if there’s an interface for it, there is, of course, some way for an external keyboard monitor console of some type to be able to interact with it, automate it, sequence stuff with it.  Do you have any thoughts or have you had any experiences in how these are being addressed or how somebody might be able to get a leg up on, “Hey, I’d like to kind of be a New-Jack Tester with the Internet of Things, what is some of the stuff that I might need to know to be able to even be competitive in this?”

PAUL GRIZAFFI: I think you’re hitting the nail on the head there, right?  If there’s a way to interact with it, there’s possibly a way to interact with it from an automated standpoint.  The whole thing sort of smells like Telecom testing, where the far end (the device, the thing that you’re testing) doesn’t really care how it got the information, where it came from.  It just knows that it got a request for something and it’s sending something back or it’s sending a request out and it’s expecting some information back.  I think some of the techniques—the basic messaging techniques—that are used in the Telecom world can be repurposed here, not necessarily the technologies, but the concepts and the approaches of, “Hey, we can ‘simulate’ on your end (the home-server end) and then ping the IOT device, get the information back,” and we can do a lot of that message-based testing from an automation standpoint, simply because it’s turning a crank, sending something out, and expecting something back.  You don’t need to waste a human’s time doing that sort of compliance-type testing.  What you need the human being able to do is, “Okay.  Let’s take this and it’s going to be in my car, and I’m going to drive around with it and see how it works.”  Back when I was working at Nortel, we were testing some of the mobile stuff, and actually there was a device and they slammed it into a bunch of laptops and they had laptops in vans and they drove vans all over the city to make sure the hand-off and hand-over worked in between the different mobile sites.  That’s the actual testing that was done to make sure that this stuff worked, and we could simulate a lot in the lab by changing the attenuation.  We did a lot of the testing that way because dealing with the hardware part of it and the driving around part was expensive in terms of both equipment and of human time.  So, we tried to get as much of the bread-and-butter stuff out of the way as possible and then the things that just weren’t practical from an automation standpoint humans did that, but then there was also actual real testing with real phones to say, “Can I hear you?  Does it sound good?”  Sure, the little gauge, the little, you know, readings that we took, says it should sound good, but does it really sound good?  I think we’ll live sort of in that type of a world where it’s this automation but more at the lower level, less around the equivalent of a UI automation, because there really won’t be one.  It’ll be messaging-based automation, and I think that’s going to probably a more economical way to go anyway.  Because UI automation tends to be brittle, in flux a lot, because we change the UI’s a lot more than we change the messaging base on average.

MATTHEW HEUSSER: Yeah, totally.  He’s not here today, but one of the recurring themes of Justin Rohrman’s work lately is testing at the API.  That it’s faster.  It’s more stable.  It’s more meaningful.  That’s how we’re going to have to test these IOT devices.  Yeah.  We can test the screen, but I don’t think there’s a lot of value in doing that.

PAUL GRIZAFFI: Certainly not from an automation standpoint.

MATTHEW HEUSSER: Yeah.  Yeah.  It’s like a little-tiny job.  So, a lot of testers are worried about their job security, and I think I may get in trouble for this.  One of the reactions to that is to say, “No.  Testing is so important.  I just do testing.  I only do testing.  I don’t have time for anything else, and I’m going to do it extremely well.  Because it’s a discipline that I study, and I’m just the best at it.”  I think too many companies are getting away.  [CAR DRIVING BY].

MICHAEL LARSEN: Just like that car that just drove away.  There it goes.  Bye‑bye.  [LAUGHTER].

MATTHEW HEUSSER: Too many companies are getting away with not having testers.  I mean, maybe, they have long-term consequences.  Maybe they’re down sometimes or the quality sucks or whatever.  But, they’re getting away with not having testers.

MICHAEL LARSEN: Also I think, to borrow a little bit here, I’m going to take a little bit from Alan Page on this and kind of laugh here because, you know, Alan was on the show.  We talked about this a while back with the whole “Unified Engineering” idea.  It is the fact that testing is going to happen, regardless of whether or not we have dedicated testers or not.  Either testing is going to happen by the developer that is actively programming the system and if they are proactive they will do unit testing and they will do integration testing and they will do end-to-end testing and other “ilities” testing as part of their programming work, if the company has bought into that, or if you are a Software-as-a-Service and you’re doing a whole lot of rollouts, your customers are going to be doing your testing.  That’s what Facebook does with its free products, let’s face it.  They have a much more rigorous testing when it comes to their ad revenue.  [LAUGHTER].  Totally different thing.  Just like Google.  They say, “Oh, we don’t have testers.”  “Oh, really?  Tell us about your ad generation.”  “Well, different story.”  Now, they may not have a tester job description or they may not have the person that is actively working that, but believe me, where the money is coming in and where the money matters, there’s testing and they are not just leaving it to their customers to do on-site in-production testing.  Maybe some A/B testing they might be doing at that level, but I think it is definitely.  I don’t want to buzzword this too much, but yes.  I believe that testing is not going to go away.  It’s going to be done, but dedicated testers who are absolutely super crackerjack at what they do and that’s the only thing they do, certain companies may still niche for that.  It even sounds like, when you look at the Tesla job description, “Yes, you’re going to be doing genuine manual testing.”  You’ll be in the car driving it.  You’ll actually be working with it, but at the same time, you will be working with instrumentation and you will be manipulating that instrumentation.  If you don’t know how to do that, you’re not going to get that gig period.  I think that’s going to be the same in many other places.  If you are a manual-only tester and you don’t have skills or if you don’t have that level of at least a little bit of a programmer’s sense or knowledge so that you can leverage it, you’re going to struggle.  That’s just going to be the case.

You are going to struggle with many companies.  You may still find some places, but more times than not, if you don’t have additional skills that you can bring, additional technical skills, and you don’t necessarily have to be a day-in/day-out programmer who spends their entire day in front of an IDE.  But you may very well be putting together little tooling scripts that help you combine certain aspects, or you’ll need to know the API (at least a bit) so that you can interact with it and see what works and just changing a couple of bits here and there, “Oh, I’m going this way now.”  “Okay.  That makes sense.”  If you are somebody who is looking to add value to the organization and are willing to say, “I can do more than just test” and if you are a programmer saying, “Yes, I can test.”  I’m not going to just say, “We’re going to play ping pong, and I’m going to throw this over to a dedicated tester.  They’re going to find a problem, and they’re going to bounce it back to me.”  We’re doing this rapid‑current whatever, Scrum, Waterfall-y, rip-roaring rapid thing.  It’s going to change.  It’s going to be different.  We’re all going to be dealing with a different approach to this at some different, because again, with the whole idea of “Ubiquitous Computing,” those manual bits are going to be squished together.  It’s going to blur the lines.

PAUL GRIZAFFI: One of the things you hit on a little earlier is something that I’ve started making a theme through all my recent talks and that is, “It’s a choice.  It’s a business choice, a business decision, on where you’re going to focus your effort.  Right?  So, projects have budgets, organizations have budgets that are divided up.  We can’t get everything we want.  We can’t get every dollar we need for everything we’d like to have.  So, in some cases, we will decide to do more testing and in other cases we will decide to do less testing; and, if that is a “conscious business decision,” you can’t say, “That was a wrong decision.”  Like you said, if Facebook is not “testing” their UI to the Joe User, like you and me, well, that’s a decision they made because they can get away with that.  When it comes to the ad generation, the revenue generation with the ad stuff, they realize that’s the core of their business model or a core business model to them.  They’re going to put more diligence around it and some of that diligence is going to be testing.  Like you said, whether it’s a testing role or a testing job or that the testing just gets done prior to it getting to the consumers, the users, the people that are paying for this stuff, it matters and it doesn’t.  This goes with automation as well.  It goes with testing.  It goes with everything.  The more key it is to your core business, the more diligence, and the more effort you’re going to need to put toward it.

MATTHEW HEUSSER: Yeah.  [LAUGHTER].  Thanks, Paul.  Yeah.  It’s been kind of dance around the topics, around IOT, but I think we should do Parting Thoughts and then What’s Going On, and call it a day.  Now, I’ll start the Parting Thoughts so I don’t get the last word.  I know we said a million times this conversation about Skillset and Job Market and it is very frustrating to me the job market today seems to want (everyone wants) a unicorn.  They want someone with five years of experience, willing to work for a very small amount of money, in a very-very specific niche, and I think that relationships and a portfolio are going to get you in when you don’t have a very specific niche.  They know you’re a good person.

They know you do good work.  They know you’re adaptable.  They’re not going to worry as much that you don’t have five years in JMeter.  We just saw that with the company I work with right now, and so I would have an eye toward IOT and start looking around and keep an eye on it.  Because five years from now, I think it’s going to be a significant driver of jobs.  Michael?

MICHAEL LARSEN: My parting thought on this one, again, is, “What you think is ubiquitous today can be very old hat in a short amount of time.”  If you spend too much time focusing on a framework or learning a language, if that’s what you’re company does and you plan on being there for an extended period of time and, you know, there’s a lot of robust activity going around it, it makes sense to do that.  But, generally speaking, if you’re going to be working with a number of different companies, you may find what you spent a lot of time working on with one company may be totally different someplace else.  I worked for a company that was a Ruby shop and then I moved over to a company that was a Python shop that decided to upgrade most of their internal services to Node.  So a lot of the skills that I learned just a few years ago, I really don’t use very much today, but I do use the problem solving and troubleshooting and looking at the issues and ability to.  If I can’t necessarily be in the driver’s seat all the time and design everything exactly the way I want it, I can still be a pretty good navigator with the development team that I’m working with.  You know, every skill that you learn, anything that you pick up, anything that can help broaden your skillset—whether it’s programming, whether it’s performance, whether it’s tooling, whether it’s getting familiar with a framework in three different languages—so that you can effectively, as I have said one hundred times, “Forget about the tool, start with the problem.”

PAUL GRIZAFFI: You know, my basic thoughts are when we talked a little about automation is that I think we should really—especially when we start getting into these new weird places like the IOT stuff—stop thinking about automation being always based off test cases.  That is an important (sometimes) implementation of automation; but, if we starting thinking of applying technologies to help humans do their jobs—

MATTHEW HEUSSER: Sure.

PAUL GRIZAFFI: —and here the humans are testers, I think we can open up new avenues to what we call “automation,” and give ourselves the opportunity to say, “Where can we point technology here so that I’m not sitting here turning this crank.  Where I, as the tester, am doing the more cognitive stuff, the reasoning, the questioning, the investigation part, and I’m letting the machines do what their good at, which is turn the crank.”

MICHAEL LARSEN: Fantastic.  I guess, at this stage, this is our shameless self‑promotion part.  So, Paul, let’s go ahead and give you the first shot on this.  What are you up to?  Where can we see you, and what are the fun things you’re up to in the coming months?

PAUL GRIZAFFI: Oh, let’s see.  On September 25th through the 29th, I will be at STPCon.  I’m actually giving the Keynote there.

MATTHEW HEUSSER: That’s awesome.

PAUL GRIZAFFI: Thank you.  Thank you.  Yeah.  I’m very much looking forward to that.  Then, at the beginning of November, the 9th and 10th (I believe), I will be at TestBash Philadelphia.

MICHAEL LARSEN: Very cool.

MATTHEW HEUSSER: That’s awesome, man.

MICHAEL LARSEN: I am excited about the fact that, as of right now, I am knee‑deep into putting my presentation together for the Pacific Northwest Software Quality Conference (PNSQC), which is held in Portland, the second week of October.  I am looking forward to talking about, “Accessibility and How to Scale it.”

MATTHEW HEUSSER: As for me, I am going to be Keynoting the Siemens Healthcare Conference in Erlangen, Germany in October, and there is a public tutorial on Lean Software Testing the day before that anybody can do to.  You don’t have to be a Siemens employee.  That’s why I get to talk about it on the show.  We’re all out of time.  If you questions, you want us to talk about something, you have a topic idea, you want to be a guest or whatever, and you want to get in touch with the show it’s [email protected].  If you have fun and you’re enjoying the show, please give us a review on iTunes.  That would be fantabulous.  I think we’re out.  So thanks for coming on the show today, Paul.

PAUL GRIZAFFI: [SIRENS].  Absolutely.  Thanks so much for having me.  Sorry for the siren there, but I’d love to participate in that DevTest Topic one day if you’ll have me back.

MICHAEL LARSEN: Definitely.

MATTHEW HEUSSER: Yeah.  IOT just kind of emerged, and I’m glad it did.  So, we’ll catch you later.  Thanks, guys.

MICHAEL LARSEN: All right.  Thank you.

PAUL GRIZAFFI: All right.  Thanks, guys.  Have a good day.

[END OF TRANSCRIPT]