The Tester’s Toolkit

Transcript

If you were going to be at liberty to drop into any software testing job you wanted, anywhere, in any software related industry of your choosing, what would be part of your “jump kit”? The Testing Show sits down with Curtis Pettit (of Huge) and asks exactly that. We geek out on favorite tools, and quickly discover that we all have some perennial favorites, but we discuss some lesser known exotics as well, really just scratching the surface of possible tools.

Also, have we reached a point where, when systems go down for Airlines and Credit Card companies, that we are helpless to go back and do business as we used to do, at least if we are in so called “technically advanced” areas? Perhaps the rugged backcountry may have a thing or two still to teach us all.

Panelists:

References:

Transcript:

MICHAEL LARSEN: Welcome to The Testing Show. I’m Michael Larsen, the show producer, and today we have Perze Ababa.

PERZE ABABA: Good morning, everyone.

MICHAEL LARSEN: Our special guest, Curtis Pettit.

CURTIS PETTIT: Good morning.

MICHAEL LARSEN: And, of course, our MC, Mr. Matt Heusser. Take it away, Matt.

MATTHEW HEUSSER: Thanks, Michael. Welcome everyone to the show. As always, we like to start, “What’s going on in the world of software development?” I want to start with this Southwest Airlines computer outage, which actually is causing the fleet to be grounded because they couldn’t tell which should go where. I want to start with this question. When Amazon Web Services came out, there would be a day of outage. When Netflix or Twitter came out, it would be down just all the time. All of those services have kind of gotten better. So, has this always been a problem and we are just now starting to notice it? If I went back and Google Search, would I find that a major airline had an outage this long or longer, and the farther back we go, the longer they’d be, or is this a new thing? Are we reaching the point where we just can’t keep up with a pen and paper, and when the computers go down, we can’t do work at all?

MICHAEL LARSEN: I’ve actually had experience with this. I remember this very well because my family was flying down to LA. We were going to go and do like a Disneyland Vacation when the kids were little. We get to the airport early and we walked by and United was completely shuttered. It was completely down to the point to where none of the monitors were up. I actually watched a flight crew sit down at a table, take out a flight chart, and start plotting things with pen, if they were going to be able to make the flight work. Now, they could certainly do the work and the pilots knew how to do this, but it was so obvious to the rest of the flight crew that this was such an anomaly, they didn’t know how to deal with it. I think it’s just the fact that, over time, we have become so dependent upon the system that have been around for years and years, when there is fragility in the system, it ripples out to everybody. We were fortunate in this regard. We were only delayed about 24 hours. We were able to come back the next night, but yeah, I can imagine, for a number of people who had too much farther places to go or much more pressing time concerns, it was major issue.

MATTHEW HEUSSER: My main question is: Is it getting worse or is it getting better or do we not have enough data to tell.

MICHAEL LARSEN: I think, honestly, what is happening is, because things are so tied together and there’s such little slack in the system, I think the problems are getting worse or at least they’re becoming worse to our perception. We are more aware of them now and many of us have felt the effects of them. I’ve been lucky. I haven’t really had too many big issues. The worst issue that I can remember was last year. Because of a computer glitch and a delay and a flight crew that couldn’t get there on time, I basically had to rent a car in the middle of the night and drive from Chicago to Grand Rapids. That was fun.

CURTIS PETTIT: The article that I saw, it looked like Southwest had, had this sort of problem before, maybe not quite as bad, and they suggested that other airlines had similar problems. It certainly seems bad when it affects you, but based on the article I read, it didn’t seem like it was any worse than a hurricane or Nor’easter or something hitting one part of the country and just throwing their entire system off. I suspect that the airlines are being squeezed right now, in terms of their profit margins. So, any sort of delay has huge ripple effects all over their system.

PERZE ABABA: I found this different article. There’s some hints about what actually happened, where no one can get into the “computer system,” seems to be very generic for me, but then when you look at what they were actually doing, apparently they were writing boarding tickets by hand, among other things. When the computer system went online, it took them a couple more hours before they were able to smooth things out. That seems to be. I want to echo what Michael was saying that, “Look, we are at a time where we have deeper relationships with software, whether we like it or not,” and most banks, most financial companies, they actually have this exercise down to the wire where they do a lot of premortems. They do a lot of disaster recoveries. You’d think that an airline company would actually also this. It’s a bit surprising that we hear this too often on systems that are kind of outside of their planes but still affect that relationship.

MATTHEW HEUSSER: A couple interesting things here. Delta has a slightly different model. If you’ve flown Delta, most of your commuter hop, they actually partner with somebody else. So, you’ll make your own company called “West Michigan Air” and you’ll own like five routes. You’ll own Grand Rapids to Detroit. You’ll own Grand Rapids to Chicago. You’ll own Grand Rapids to Atlanta. And then, you’ll operate yourself as your own carrier, and of course, their computers tell you where to go, what to do. Every day, every week, you can download your suggested travel plans. If the website goes down, all of the local carriers can operate independently. It’s like a hub-and-spoke kind of strategy. So, I wonder if there could be a way of structuring your business to continue when systems are down. How many gas stations have you been to that could operate credit cards, if the credit card readers went down? In the 1990s, you used to have these little things that you’d put the credit card in and you’d swipe it back and forth and you get triple kit. I don’t think those exist anymore.

MICHAEL LARSEN: They do exist. A few weeks ago, I actually did run into a place where their card reader was down, and they did actually still have the device for doing the swipe‑over.

MATTHEW HEUSSER: Was it in New Mexico though?

MICHAEL LARSEN: [LAUGHTER]. Well, yes.

MATTHEW HEUSSER: Was it somewhere off the beaten path that still sort has—like Colorado—this kind of mountain-man culture.

MICHAEL LARSEN: That is a good point. It’s a good thing that I have a card that still has raised bumps. I happen to have one that doesn’t. So, they’d have a hard time, [LAUGHTER], running that machine on that other card, if I had to run it.

PERZE ABABA: I can actually attest to that too. So Matt, when we were at Orcas for the Reinventing Testers Conference, on our last day, Marina’s Restaurant, the credit card system actually went down. So, there was sort of a line, and they only had one machine. There were multiple people there at that time, and we had to go through that swiping-crunching action so we can actually pay.

MATTHEW HEUSSER: Orcas Island, when it gets covered in snow or covered in rain, they lose connection with the outside world, and they’ve got have a backup. So, I guess the lesson there is: When the consequences are grave, we as a society are still capable of investigating that kind of thing, and I think that’s an important question to ask on any project, right, “What are we going to do if the system goes down? What if the FTD fails? PayPal is down, and we can’t take payments, what do we do?” The answer might be, “We’re dead in the water. That’s how it works. We’re on AWS. If AWS is down, we are. That’s how it works.” So, it’s Netflix. But, at least, you asked the question.

Let’s move on to talk about your, “Tester’s Toolkit.” I want to do the setup for that: Two‑or‑three different tests. We are all working on an e-commerce project together. This is hypothetical. A customer says, “You know what? We’re not getting a lot of traffic Apple Safari. I mean, we’re not really getting a lot of percentage of users, so we didn’t have you test it, but we’re getting a lot of dollars flowing through it. The people that use Apple Safari are buying our products. They’re buying them by the boatload. We really need a tester.” Tester number one says, “Well, we need to put in a request with purchasing. That’s going to be a ticket. You’re going to approve the ticket. You’ll get in four-to-six weeks.” Tester number two says, “Well, I’ve got my credit card and we’ll get it in a couple days.”

CURTIS PETTIT: “Ask forgiveness not permission?”

MATTHEW HEUSSER: Right. Tester number three says, “I got a MacBook Pro at home. I’ll just go get it. I’ll be testing it a half-an-hour from now.” Those are the three different architects, right? “The Testers Toolkit,” what is the combination of hardware, software, patterns, tools, soft skills, technical skills that you as a tester can bring to any project? Let’s be frank. The first person in my example, they’re probably doing what they’re told and being measured by hourly rate. Unless you live in India, Pakistan, Vietnam, or China, you probably can’t afford to compete on hourly rate. If we don’t want that to happen and we don’t want to be sort of pushed into these unsuccessful roles, if you want to be an AirDrop tester, I think there’s a unique set of skills and tools you should have. I’ve told you about one of them, which is having a physical hardware set, mostly for web and native stuff. So, I want to stop here and say, “What are the tools that you think testers should have and go get?” Curtis Pettit is our guest. He’s a software engineer—a huge specializing in test. So, I’m going to throw the question to you Curtis: What do you have in your toolkit, maybe, and then generalize, if we can?

CURTIS PETTIT: I have a bunch of different tools for different situations. I remember a couple of months ago our IT Department decided to lockdown the Wi-Fi, which was unfortunate because most of our developers and some of our testers were using the local Wi-Fi to test the code before it got checked in on their local servers. So, they were testing on basically their personal phones, and they locked down the network and we weren’t able to do that. So, we had to go out and spend a bunch of money, which meant we had to go through this months and months of approval process to get all the devices we needed to share out with the different developers and testers and stuff. So, I can really feel that pain. Luckily, we were able to get the IT people to approve a couple of personal devices in the interim. It was painful to have that ability ripped away from you like that. If you’re in that situation, it certainly helps to have at least one iOS device and one Android device, since those are the most popular. I happen to have an old Windows phone that I’ll pull out sometimes because I used to work for Microsoft, so that was my personal phone for a little while. I usually carry a USB stick with me wherever I go. Part of that USB stick has a bunch of testing tools or debugging tools or whatever you want to call them in different categories. So, I’ve done a lot of its accessibility work in the past, so I have accessibility tools like Color Doctor, Color Contrast Analyzer for looking at colors and their contrasts. I have some tools for looking at Windows accessibility trees, like UI Spy and AccChecker and AccExplorer32. I also carry a good install of NVDA, which is an open source screen reader. The sysinternals.

MICHAEL LARSEN: Ah, Curtis, you’re stealing my thunder, man. [LAUGHTER]. I was all prepared to talk about accessibility and the little toolkit you have, and you just took it. No. That’s totally cool. [LAUGHTER].

CURTIS PETTIT: Do you have any that I don’t have?

MICHAEL LARSEN: Well, I mean, actually, there’s a few that I use. I’m not sure if you’re familiar with WebAIM or WAVE. It’s a basic tool that gives you a quick, high overview of accessibility in a kind of graphic format to show you where you might have heat spots on your site that could or could not be accessibility issues. I also utilize some API tools. I use ARC and Postman. If I get dropped into an API and I want to actually play around with it and see how it works, those are good-quick ways without having to necessarily go in and dig into the guts of an API. You can do some quick testing with it and see what’s going on. As part of Matt’s conversation where he was saying the bit about Safari being a “high-dollar” driver. Well, for us actually, in a lot of environments, its various flavors of Internet Explorer, “Well, okay. I’ll have a number of virtual machines, and I’ll have a different flavor of IE on them,” and that’s fine. What we discovered, though, was that there were certain issues that didn’t register as problems on the virtual machines, but if we ran them on actual hardware machines running with IE, say 8, 9, 10, 11, or Microsoft Edge, we would end up getting different results, which isn’t entirely surprising, of course, because when you have a virtual machine and you’ve abstracted the hardware layer down to a common denominator that you can agree to, it takes away certain problems, where then if you’ve got some video card, something goes weird. [LAUGHTER].

CURTIS PETTIT: I have seen a lot of that on, like, browsers specifically. I’m curious what kind of virtualization technology you’re using.

MICHAEL LARSEN: We were using VMware.

CURTIS PETTIT: VMware. Okay. Yeah.

MICHAEL LARSEN: These are local VMs. If you’ve got them on a USB stick or if you’ve got them on your Mac or on your laptop, you can just drop in, and you’re ready to go. I find the value to that. There’s a few things that I’ve gone through, especially when it comes to setting up environments, and now that AWS is a strong part of our business and it’s what our customers actually use to access our products, when we spin up a device for a customer, it’s done through AWS. So, a lot of what we do now there as well, when I’m testing and I have to throw away a machine and restart a machine, oftentimes there’s a number of steps that I have to go through for that, being able to tweak and modify those and do them quickly is a big help for me. So, I’ve spent a lot of time getting into the AWS console and figuring out ways to optimize and speed up device availability, and we’re looking at technologies like Docker and other methods so that we can speed that up even more. Right there, I’m touching on a whole bunch of tools that testers should probably get to know a bit about. They should get to know about AWS. They should get to know about Docker. They should be able to know how to configure them, how to spin up environments. It would not be a bad idea at all for a software tester to have a local version of Jenkins to play with and be able to have a simple project that they can work on, just so that they can get into the guts a bit of Jenkins and be able to work with it. I’m a broken record on this show because half of my work now extends to release management as well as to testing. So, it seems I’m always mentioning the challenges and issues you run into when you deal with Jenkins or Continuous Integration or being able to find tools that help you deploy, and those are part of my toolkit, which may or may not be relevant to other testers. But, they’ve become invaluable to me.

CURTIS PETTIT: I’ve not used Jenkins myself, but I have had to set up builds in TFS and whatnot. So, it’s a good skillset to have, I think. You might not be responsible for creating your own builds today, but in your next job or your next reorg, you could easily end up with that responsibility. Not being blocked when there isn’t an official build, is really powerful.

PERZE ABABA: For me, it boils down to two things. If look at the Heuristic Test Strategy Model or at least the heuristics of software testability, intrinsic testability comes to mind, with regards to observability and controllability. Most of the tools that we’ve been talking about boils down to these two. So, you’re looking at accessibility scanning tools. One of the things in my toolkit, which falls out on observability is a tool called “Pa11y.” It’s this NPM library that you can use to just look into a given URL. You can even plug that into a crawler and have that go through. Well, the other thing too, I know you guys have been talking about the other things that deal with controllability, Jenkins does give a lot of help, specifically from the repeatability standpoint. It forces you to think differently so that you could boil an action down into something that’s repeatable. Proxies, for example like Charles or Fiddler. It just gives you more control over doing certain things within your system. I mean, I’ve been living in a web‑specific context for the past couple of years. I did some video and audio streaming a job ago, so a lot of conversations around Wireshark as well as having the ability to be able to intercept live streams, live video streams, and look into buffering. So, it’s really the right type of tool for the given context that you’re in as well as, “What type of information are you actually deriving out of it?”

CURTIS PETTIT: I have Fiddler in my USB stick as well.

MATTHEW HEUSSER: I was waiting for the USB stick to come out. I carry that thing from job‑to‑job, but I’ve got every portable browser on it and I’ve got Fiddler on it. I’ve got Charles Proxy on it.

CURTIS PETTIT: Sometimes you just need to carry files around too. You know, you never know when you might need to move some software or files or data or whatever to a different computer.

MATTHEW HEUSSER: Oh, the stick itself is part of the toolkit. Yeah, absolutely.

CURTIS PETTIT: Yeah.

MATTHEW HEUSSER: For webby stuff, Firefox’s Responsive Design View. I think it’s fantastic. I want to have an iPhone, I want to have an iPad, and I want to have an Android Tablet. I want to have an Android Phone. At least it still fits in a backpack at that point. It’s not insane. Chrome Developer Tools. The Network Tab, and the ability to view source and inspect, I think, are really powerful. I want to have the knowledge of at least scripting language. Selenium IDE for XPath capturing, and that’s the only reason that I use it. And then, the ability to write a log file parser or a CSV file parser. I would argue that, if you have those things that I just listed and you’re a web tester—it’s not a big list—but you’re probably ahead of 85% of your competition.

MICHAEL LARSEN: I’m actually to actually put a little drop in here for something that might not be as obvious to help me develop and put together datasets, and that is fakenamegenerator.com.

CURTIS PETTIT: Cool.

MATTHEW HEUSSER: So, tell me about that.

MICHAEL LARSEN: You’ve never heard of it? This is something that dates back to when I was working at Immigration Tracker, and one of the things that we had to do was, very often, we needed to create large datasets, and those large datasets needed to have example names. Now, of course, you don’t want to use your customer’s real database. You don’t want to use real people, etcetera. So, if you go to fakenamegenerator.com, you can just generate randomly an identity with a name, with an address, phone number. You can even give them geographical coordinates, if you want to test with that. If you want to get Social Security Number examples or birthdates, ages. So, you can generate a lot of detail for an individual and you can create a fairly large set of names that you can just download. If you really want to get big ones, they have a charge model where they can create just tremendously large amounts of data for you, and then you can go and you can parse that and you can populate your database with anywhere from hundreds to millions of records, if you so choose. The data is structured, but of course, it’s randomly generated, and it’s not based on real people at all.

CURTIS PETTIT: I have not use that tool, outside of role-playing games, but I’m looking at it now and these people have credit card numbers. I know Perze just pasted into our chat, getcreditcardnumbers.com.

PERZE ABABA: Right. Yeah. So, that’s actually a very valuable tool. I’m starting to look into helping out one of the areas in my current work, where we’re dealing with e‑commerce. Should I stop calling that “e-commerce” and just call it “commerce?” But, one of the challenges is really the payment provider will give you sample credit cards, like 411-111, if you guys have used that particular number. It’s a valid card for Visa to use, but this site right here generates a bunch of possible valid, but hopefully fake, because they’re automatically generated and there’s a caveat in the side somewhere that tells you that, “Please don’t try to use these on real transactions, because there is a risk of these possibly working,” [LAUGHTER], and affecting someone.” It does happen. But, the other cool thing that we’ve used is, you can just issue an API that says, “Hey. Can you please give me 100 credit cards using a particular format for American Express or MasterCard or Discover,” and you can get that instantaneously. There is no need to reuse all the existing cards that you have.

CURTIS PETTIT: I’m a little reluctant to run randomly-generated stuff through an automated test suite, like a continuous delivery pipeline, just because you have to be very careful to record what data you’re using; otherwise, debugging it is going to be a huge pain.

MATTHEW HEUSSER: I want to make sure I and the audience understand how far down we’re taking this credit card validation. If I understand correctly, we’re going to generate a fake credit card number. We’re going to give it to our API that validates credit card numbers, and that should come back and say, “Yes. That’s a valid Visa,” through CI, but we’re not actually going to process the transaction all the way down. You wouldn’t, for instance, continuously monitor production once a day by ordering. Probably the right way to do it is some information product, an e-book, again and again and again and again, with these simulated credit card numbers, because that should fail. The actual validation with a third party, like PayPal or whoever your payment gateway is, that should fail. It’s just we’re validating that this is the right format of a credit card number. I think what Curtis is expressing some mild concern with is a couple things: One is, if you do a different credit card number every time, then traceability is hard, but debugging is hard.

CURTIS PETTIT: Yeah.

MATTHEW HEUSSER: But also, you never want to accidentally have that try to go through like it was real.

CURTIS PETTIT: Yeah. I had a colleague who, a couple of months ago, was working on a site that included like a registration for new mothers. So, she was generating user data, and for one of them or probably a couple of them, she put in her parents’ address, and it turned out that test data leaked. So, her parents getting baby catalogs and gave her a call. I don’t think she’s seeing anybody, [LAUGHTER], so her parents were kind of surprised to start getting new mother catalogs at their house with her name on it.

PERZE ABABA: It seems to me that the law of unintended consequences is really a factor, especially when we’re not just building test data. This was an exercise on test data management as well as data cleanup. I was asked to perform a load test to see if our system can handle 100,000 transactions in an 8-hour period. This was specifically from a country in Asia going to a country in Europe. So, I created an account. We didn’t have these fancy name generators at that time. So, I put in “Jackie Chan” as the primary sole owner of the credit card that was used to perform a transaction, and I created 100,000 transactions for Jackie Chan and his posse to fly from one country to the next. What actually happened was, when we run the test through, only 10% of the transactions were where we actually got a PDF confirmation. That, “Hey. You bought this. This is your receipt.” What actually happened was things got stuck on the message queuing server, because there was an error in the logic when routing some of the data. So, they told me that, “Okay. Fine. We’ll clean that up before we push that to production.” I left that company, three months later I get a call from an airline. I got invited to a conference call for my old company and the airline in Europe and saying, “There is somebody named Jackie Chan who just ordered 90,000 of these, and it went through all of our systems.” So, there were like 90,000 printouts and then 90,000 e-mails were sent through the system and the thing that really happened, [LAUGHTER], was the guy that said that, “All the data is clear. It’s all sitting in an MQ server right now. We will clear that before we push the production,” that was never cleared before it was pushed to production. So, I call it my “100,000 Jackie Chan Story.” You have to be very respectful of the unintended consequences in any of our tests and Tee things through, because there’s going to be challenges that will come with it.

MATTHEW HEUSSER: Okay. I have a couple more things I want to mention. We tend to get a little abstract in the show in talking about real stories from real testing, and I think it’s awesome. I was doing test on an e-commerce site. We wanted to simulate slow transactions on phones, and I didn’t know how to do it. So, I got on Skype, and I started asking everybody I knew, “Hey. How can I? Is there a way that I can tell my laptop to throttle to certain speeds and then use my laptop as an access point? How am I going to make this happen?” And Sigge Birgisson got back to me. Now, he is Sweden. Now, he is in Australia. Really smart guy. He said, “Matt, what you want is called the Network Link Conditioner,” and I’m not sure that still exists as an Apple product. [LAUGHTER]. I was trying to re-download it this morning. It was a couple years ago, but it was, you had to download Xcode and then you get this plug-in and then it shows up on your phone under, I think, settings. It was super easy. It was, “What kind of network do you want to simulate, and what percentage of packet loss do you want? And then, we can do timing.” So, there’s two things there. There’s Network Link Conditioner. You should probably have some way of simulating a down network, a slow network, a wireless network, switching between cell towers, and that sort of thing. But also, the contact network of friends to get you to solve the problem. I was interviewing someone last week, and I threw them a testing problem they didn’t know how to solve. I said, “What are you going to do when you’re asked to do this?” It was something about, “Back-end APIs.” He said, “Well, it’s not my job to discover the API,” and what I was digging for is, “monitoring the network traffic, figure out the URL.” “This is not my job. I’m a tester.” So, I think the mental skillset there to go, “I don’t know. How can I figure that out? How can I Google, and who among my friends should I call?” It was performance, it’d be Mark Tomlinson and Scott Barber. If its security, it’s going to be Dan Billing. I know people I can call to get answers to these questions when my expertise is limited, and I think that should be part of your toolkit.

CURTIS PETTIT: Yeah, definitely. I’ve definitely used Twitter to ask about, like, accessibility tooling. I’m sure Michael has done the same. Having a network is super important.

PERZE ABABA: For me, it’s really the peers that surround me that help me to be better at what I do, and it’s not just that, it’s not just them challenging me or you guys challenging me, but it’s, you know, the knowledge that you guys also have and that you’re willing to share them as well. I mean, it’s good to have friends that are really awesome, but if they don’t know how to share things, then that’s a different question. [LAUGHTER].

MATTHEW HEUSSER: Yeah. This line of reasoning has me thinking about the ability, when you don’t know, to say you don’t know in a way the customer can hear it. The ability to communicate accurately what you know about the status of the software. The ability to slice and dice work. So, you say, “Look, if you give me an hour, I’ll do this. If you give me a day, I’ll do this. If you can give me a week, I’ll do this. I suggest you give me two days, so we can do this.” Those sorts of communication skills, again, if you have them, I think that puts you in the top 85% of testers. I’ve known testers that just go into the client and say, “You don’t understand. That’s a check, not a test. I couldn’t possibly know. I’ve performed some testing. It appears to not have any problems that I saw, at this time, but that makes no guarantee about the future.” Let’s be honest, when the customer hears that in a confrontational tone, they do not think you’re smart. They think, “What am I paying for?” Am I right?

CURTIS PETTIT: Yeah. Sometimes we get bogged down in the technical aspects, but software is built by people for people. So, a lot of times, I’ll study social psychology when I want to get better at my job, controlling biases, influencing people, and that sort of thing.

MICHAEL LARSEN: Yeah. This opens up a whole other aspect, when we talk about, “The Testers Toolkit.” We’ve been focusing primarily on the technical tools that a tester uses. We haven’t even touched on the psychological tools or the cognitive tools that we can utilize to get it. I think that’s a whole series of shows that we could, [LAUGHTER], address.

MATTHEW HEUSSER: Totally. Totally. Yeah. I think trying to keep that to the kind of hard, “Here’s ways to prevent data. Here’s ways to prevent evidence. Here’s a way to prevent bugs,” things to do, instead of getting too abstract, may an audience. Okay. It’s last word time. We don’t have anything in the mailbag. So folks, if you have questions for The Testing Show, if you want to recommend people to be on The Testing Show, if you want to be on The Testing Show, e-mail us at: [email protected]. Final words, thoughts. I’m going to go to Michael.

MICHAEL LARSEN: Okay. Well, since there’s still some time for this, I’m going to make a plug. Again, I’m helping out with this, in regards to reviews and the program that’s shaping up for it. I want to recommend to anybody who can be in the Pacific Northwest in the month of October, come visit the Pacific Northwest Software Quality Conference. It’s looking to be a good program this year, just from the number of submission that we’ve gone through and reviewed. So, I’ll plug there. I want to definitely encourage anybody who can make it up to Portland, do so.

PERZE ABABA: Right. So, on September 25th, 26th, 27th, and the 29th, there is the Test Masters Academy by our good friend, Anna Royzman. If you’re local in New York City and it’s easier for you to get to New York City, you should check out this conference. Go to www.testmastersacademy.org. Also, the other thing is, we’ve been very consistent with our monthly meetups for NYC Testers. We just had a panel of Test Automation Strategy a couple of days ago, and that was very insightful and very interesting. We actually had a packed house. We had over 90 people attend. So, we’re going to announce another one for August, and that’s something you should always look out for if you live in the area.

MATTHEW HEUSSER: Great. Curtis?

CURTIS PETTIT: I don’t have something specific I want to plug, but I will mention that www.meetup.com is a great way to build your network. There are local test meetups, technical meetups in just about every market. If there isn’t one already, then you can start one. It’s fairly cheap.

MATTHEW HEUSSER: Thanks, Curtis. I’m going to thank our sponsors, QualiTest Group. You know I’ve got a lot going on. You can go to xndev.com and look at what we’re up to at Excelon, but really, the reason we have a show is the folks at QualiTest. So, if you’re looking to do some staff aug, if you’re looking to bring in some testers, you want people who care deeply enough to recognize good talent, look into the QualiTest Group. Also, their website has a bunch of articles, blogs, and white papers. They make this show possible. I think that’s it. Thanks everybody for coming. One more testing show down. I think we really covered some good ground here today. Thanks, everybody.

MICHAEL LARSEN: Thanks for having us.

CURTIS PETTIT: Thanks for having me.

PERZE ABABA: Thank you.

[END OF TRANSCRIPT]

The Tester’s Toolkit

share

Panelists:

References:

Transcript:

Recent posts