The Testing Show: Testing for the Greater Good
As we come to the end of 2016, we consider ways that software testing can go beyond just testing products, and looking at ways that we can use our super powers for good in the world.
Abby Bangser works with ThoughtWorks and ThoughtWorks makes this a core part of their mission with ThoughtWorks University, a combination of training and integration of all roles, including software testing, as they learn how to work with ThoughtWorks model. Additionally, they take on a variety of projects that focus on social and economic justice, bringing groups of people from all over the world to Pune, India to research and work on a specific problem to help those in the immediate area and beyond.
Also, are you getting a lot of Skype spam lately? You are definitely not alone. We talk about what’s causing it and how to fix it.
- ThoughtWorks: Creative Technology Consultants
- Beware of Links to Baidu in Skype Messages
- Spam messages & links sent from your account?
- ThoughtWorks for Graduates
- Testing Heuristics – Thinking like a tester
- The Oracle Problem and the Teaching of Software Testing
- ThoughtWorks Mission
- Emma Keaveny: Dark Patterns, A Tester’s Quandary
- Tester Diaries – Applying SFDPOT Heuristic
- Elisabeth Hendrickson’s Test Heuristics Cheat Sheet
- The road to enlightenment: How we learned to stop worrying and start treating infrastructure like any other feature – Abby Bangser and James Spargo
- European Testing Conference 2017
- Testing APIs from imagination to implementation
MICHAEL LARSEN: Welcome to The Testing Show. I’m Michael Larsen, your show producer, and today we are joined by Perze Ababa.
PERZE ABABA: Hello, everyone.
MICHAEL LARSEN: Matt Heusser
MATTHEW HEUSSER: Good morning.
MICHAEL LARSEN: And our special guest, Abby Bangser. Abby, could you please introduce yourself and tell us a little bit about you?
ABBY BANGSER: Yeah, Absolutely. Hi, everyone! Abby Bangser and I am a tester at ThoughtWorks, and have been with ThoughtWorks for about five years now. Based in the Chicago office for the majority of time, but also worked out of Pune, India, and I’m actually now in London, UK. Kind of a tester on the ground with our clients, helping them work better with testers co-located and looking at quality from a different perspective.
MICHAEL LARSEN: Awesome! Fantastic, thank you for joining us today. Matt, this is your show, wanna’ take over?
MATTHEW HEUSSER: Sure, thanks, Michael. So, we always start out with a news segment, and what’s been happening to me, that I am most interested in, is all these Skype spam bots. For the past month or so, I’ve been getting people, they test me a link to a baidu dot com website. Has this been happening to anybody else?
MICHAEL LARSEN: Yeah, definitely. It’s been happening to me quite frequently. Most frustrating was just this past weekend. My weekend Testing Americas account, we were setting up for a session, and I was really excited because at first I thought, “hey, I’ve got a bunch of people looking to respond for it” and it turns out that fifteen of them were not responses, they were these spam links and… aaaahhhhh!!! Just rather irritating, having to go through all of them and go “nope, nope, nope, nope nope, nope”… and in the middle of sessions, of course. Getting ring-ups and having to deal with them and ignore them while I’m trying to run a session, which was a bit irritating, too. You’re not the only one.
MATTHEW HEUSSER: So apparently in 2012, someone stole a bunch of Skype usernames and passwords –I don’t think mine included, I don’t know where the list came from- and then they are using them now. They log in, they go through all of your contacts, and they send every contact this link. It’s crazy. So we put a story to it. The Internet is held together with duct tape and bailing wire, right?
MICHAEL LARSEN: [Laughter] Yeah, unfortunately that’s the case. We’re not just looking at the fact the Skype has insecurities, it’s also the fact that we’re looking at the challenges of Skype interacting with and merging with Microsoft. You can have a Microsoft ID, or think that you have a Microsoft ID with the username and password that you think is secure, but you had a Skype ID that you didn’t either disable or turn off, and that’s still open, and so your account is still available, even though you thought you moved everything over to your Microsoft ID and password.
ABBY BANGSER: Yeah, I think that was the big kicker, is that Skype kept in one of those YAGNI, or “you ain’t gonna’ need it” features where they thought someone might still want to log in with just their Skype username and password, instead of using the two-auth Microsoft logins, so they kept those usernames and passwords around, even though they weren’t visible anywhere to the end user. Sometimes the most dangerous stuff in your software is the stuff that you just didn’t clean up, because maybe one day it might be helpful.
PERZE ABABA: Because of the integration that they made with Microsoft single sign on , which pretty much also means anyone can use your Skype account to log in across your Microsoft properties. That’s a little bit dubious.
MATTHEW HEUSSER: Wait, you could use your Skype account to log into your Microsoft Live email?
PERZE ABABA: Right, so you could pretty much use it as an alias and extend that across all of your Microsoft accounts.
MATTHEW HEUSSER: That sounds terrible. [laughter. That sounds really, really bad. Is there anything testing could have done about that?
PERZE ABABA: If you’re just testing for the functionality; we can confirm that it works a certain way, but then when you’re looking at the actual integration and the actual usage and ways where you can introduce risk, then this should at least have been brought up to a product owner or whoever it is that makes these decisions. That’s definitely risky, and it’s another integration point that you have to deal with. I think yes, if you tested for this particular case, then you can bring it up to someone but ultimately, if this particular case was ignored, then it’s not really going to be effective, whether you test as much as you can or not.
MATTHEW HEUSSER: Yeah, it’s almost backwards. The person that tested it would say “yes, you can log in with your old Skype account, and you can log in with your Microsoft Live account, they both work.” So they would confirm the presence of a feature, but there’s this “we should build the ability to turn off the old Skype login.” It’s not just on Skype, it’s across all Microsoft logins. That freaks me out. That’s a problem.
PERZE ABABA: I don’t think the ability to turn things off, but after you link your two accounts, that should be off by default. You can extend two factor authentication using the current Skype profile, so you want to switch into something that’s more strict.
MATTHEW HEUSSER: Somebody said that was a feature, though. Somebody said, “no, we want that.” Some project manager said “no no no no no, you need to be able to continue to use your”… I can even guess why it was. It was because people that use the Skype desktop client that automatically log in, want to just keep automatically logging in.
MICHAEL LARSEN: Yep, that’s me [laughter]. I’m one of those people. I have never integrated my Skype ID with Microsoft, so it is still, I just use the desktop client, I use my ID for it, it’s got nothing to do with any type of a Microsoft account. For those who do have the dual account option right now, Microsoft does have a fix, but you basically need to update your Skype account, make sure it’s merged over at Microsoft’s accounts page, and they’ve got steps for how to do it over at Microsoft, we’ll include that in the show notes, just in case you happen to be somebody who’s been hit by this. The idea is, you’ll be prompted to sign in and merge the accounts, which will create a Skype alias, and then, if needs be, you can turn off the old one and then you don’t have a problem anymore, according to Microsoft.
MATTHEW HEUSSER: Yeah, but I want my stuff to just work, and mine wasn’t stolen, so I’m going to risk it… so, if I suddenly Skype you [laughter] with a link that makes no sense, you tell me and I’ll take some action. I think that always speaks to the tradeoff between convenience and security. We get the little pop-up “Critical updates required on your computer. It’s the end of the world if you don’t update!” and then we click the “ehhh, do it overnight” button. “Ehhh, tell me later. I’m busy”. And I can’t even tell the difference any more on my Mac; it will say “critical updates” and I’ll shut everything down and update and it’s “Slack is updating”. That happened yesterday… really? You can’t tell the difference?
MICHAEL LARSEN: Good points. If you happened to be concerned out there, go check with Microsoft, see your settings and update your password at the very least.
MATTHEW HEUSSER: Yep. I’m really interested in how should testers be finding these things? How to we tell the product owner about them? Is that a way to demonstrate value? How do we get past the kind of classical “no, you’re a tester, that’s a feature… these testers are asking these weird questions that don’t really make any sense; they need to focus on the functional execution”, and then a year later we have this kind of black swan problem. “Man, why didn’t those testers tell us about that?” “We did.” “Man! You should have tried harder.” [Laughter].
To talk about that specifically, becoming effective in our role as testers, we brought Abby Bangser in… what’s your title at ThoughtWorks, Abby? You’re an analyst, right?
ABBY BANGSER: I am a Quality Analyst, is the way I define QA. I work with other ThoughtWorkers with different definitions at times [Laughter].
MATTHEW HEUSSER: So ThoughtWorks is an international consultancy that focuses on Agile transformation, They do a lot of doing and building, and they hire really smart people to get things done. Dare I say it, usually younger people who have more time to really devote to their careers.
ABBY BANGSER: Yeah, I think that ThoughtWorks has been going through a bit of a transformation over the last five or so years (basically since I’ve been there), where we’ve really been partnering more with our clients on, the term kind of “moving up the clock face”, instead of having people call us and say “we have an idea, come help us build it” we’re having people call us up and say “we have a problem that we need to solve”, and then allowing for that partnership between the client and ThoughtWorks to work together and iterate through ideas, fast prototype stuff and be able to solve those problems from the business perspective, leveraging technology rather than coming in and solving a tech problem.
MATTHEW HEUSSER: That makes a lot of sense. Going back to the reputation five years ago, you were known for coming in and doing software delivery in a newer and incremental and fast fashion, and then helping the company do it, and a big part of that was all sorts of innovation. Moving up to business innovations seems like a great next step for you. It’s a reasonably large company, what is it, five hundred people?
ABBY BANGSER: Globally, were up to near five thousand, but North America would be closer to the five hundred number.
MATTHEW HEUSSER: Yeah. A lot of off shore growth in the past couple of years.
ABBY BANGSER: We clearly do have a presence in many different countries, but we actually have at least one office on every continent. It gives us a chance to be involved in a lot of really interesting technology in all sorts of areas.
MATTHEW HEUSSER: Antarctica? You have an office in Antarctica [laughter]
ABBY BANGSER: All right, fine, you got me [laughter]. I think we can maybe argue that that one is a continent, though. [Laughter]
MATTHEW HEUSSER: All other populated continents… besides penguins.
ABBY BANGSER: I can always trust you to keep me honest, Matt.
MATTHEW HEUSSER: Or testers. I try not to let it inhibit social situations when I ask “oh, really?!” and they’re like “No, I didn’t mean that, of course not it’s social convention. Give me a break”. When we first met, I think, it was at CAST in 2014, and you were just about to head to India to help with the testing tester development program over there. ThoughtWorks has really not had much of a test discipline. They’ve had analysts and programmers, but there’s a view here and there, but they’ve never really made it a practice, and I think that’s changed. Tell us about that training program.
ABBY BANGSER: Yeah, it’s a pretty amazing training program. Actually, we’ve put a lot of energy into it and I was actually trained through it myself, when I first joined in 2112. It’s called TWU, or ThoughtWorks University All of our entry level hires across all the different regions and all of the different roles together to do a bit of hands on learning with project work as well as classroom and more targeted leaning around some of the skills you need to be successful. We take the time there to build networks of people that are going to be able to support us on our project teams. I’m still in touch with people from all over the world. When I need help, I know I can reach out. I think, for a lot of people, it’s learning how to interact across roles on a project team for the first time in maybe their experiences.
MATTHEW HEUSSER: So what do they do in this program? How long is it? What’s the curriculum look like?
ABBY BANGSER: The program is five weeks, and covers three major aspects of working at ThoughtWorks. Obviously, we are consultants, so the ability to work with clients, the ability to speak openly and honestly, and sometimes deliver hard messages, is a big part of being a trusted partner. We work through aspects of that. We also (as you were saying, Matt) are well known for delivering software in a high quality way and so go through some of what that takes; what are some of the practices and processes that we have found success with. Around Agile, yes, but also just around cross role collaboration between the Devs and QAs and Bas and all that. What are the skills associated in each of those roles? As a tester we’re going through some heuristics[vi] and oracle learning, as well as understanding automation and the pros and cons there, when to leverage it, and each role has their own specific learnings in those spaces. The third aspect is that ThoughtWorks has a strong focus on social and economic justice and so we take advantage of bringing our entire entry level group from around the world to India as a way to let people discuss topics that, maybe, they wouldn’t have learned about in their own home countries, and experience organizations in India that are doing fantastic work for… women’s and children’s rights was the organization that I was able to attend when I was most recently there. We partner with a bunch of different organizations, and give people some insight into how technology can help people from around the world as well.
MICHAEL LARSEN: Following up on that, that sounds really intriguing… so you had a choice of different programs and options you could attend. What are some of the other ones that they had?
ABBY BANGSER: Yeah, so it’s, timing wise, when we’re actually at that program. Sometimes, for one session, which is five weeks, we’ll go with a certain organization and maybe the next session, that organization wouldn’t be able to host us, and so we might go with a different organization. One of the things that we do is a research oriented project where there’s three or four different topics, and each of the groups of new hires work together to investigate that topic as well as chat with people internal to the company that has experience with it. That’s, I think, where it’s quite interesting, with the diversity of topics. We’ve done women in technology, which is one that, I’m actually a person that people can interview as a part of their research. We also have done healthcare in India, access to the open Internet, so it’s a mix of topics from very social oriented to sometimes more in our own backyard of technology, but all impact people in a social way.
PERZE ABABA: That is really cool, Abby. I just looked up ThoughtWorks mission, and the three areas I’ve seen is pretty interesting for me because, in the company that I work for we have what we call a credo, and essentially the things that we adhere to that really defines everything that we do within the company. Sure, we’re a health care company that’s trying to transition to a health care technology company but, at the end of it all, we care about our communities. We care about the people that work with our co-workers. We care about our customers. Because we care about all of these things, then we’re hoping for a sustainable model to drive our business, which kind of aligns with what you guys have, and I really appreciate that. You mentioned that there’s a driving factor as part of your training, as part of onboarding your new ThoughtWorkers. That’s really awesome to me.
ABBY BANGSER: Yeah, it’s about that sustainability, too. Our first pillar is the ability to have a sustainable business, because if we’re not in business, we can’t help anybody. Sometimes part of our learning is “balance all of those pieces”. There are so many people and organizations that could use help from technologists and from ThoughtWorkers. How do we balance that with making sure that we stay viable enough to be there to help therm. Those research projects that the new hires do are not just “hey, research into this topic”. They’re actually posing a problem that they have to solve. The one I know the best is the women in tech. For this one, we say “we’re trying to hire a more diverse staff. We’ve hired ten people so far, and they’re all men. We’ve got another five in the pipeline, all men, but we were only planning on hiring twenty people overall. How do you handle this situation? What do we do to make sure that we have the best possible staff from skills and diversity standpoint?” It’s a business problem that they’re trying to solve, while keeping in mind those social and economic justice aspects.
MATTHEW HEUSSER: What does “hosted by” mean? Do you actually do the training in the offices of some non-profit? Do you visit them once for an hour a week? What does “hosted by” mean?
ABBY BANGSER: The training itself is hosted inside of our Pune, India office, so it gives the new hires to get a sense of the ThoughtWorks office and meet people there. In the sense of being hosted by organizations, we do day trips out to meet and learn from the people that are doing fantastic work in the community and find out what it is they’re doing, what it is they struggle with, what their hope for the futures are, and where ThoughtWorks can continue to partner with them and support them through both volunteer work as well as technology support in different areas.
MICHAEL LARSEN: I’d be curious to see, as software testers and as technologists, there are other opportunities and other ways that we can get involved, being able to use the skills that we have, to help other organizations, NGO’s or other groups, that can help make the world a better place, quite frankly. This is really cool. It would be very interesting to get some ideas who these organizations are. For example, they may very well need software testers or programmers or somebody to help them with some infrastructure to be able to meet these needs in various places and not just in India but other parts of the world.
ABBY BANGSER: Absolutely. I think what I heard there is kind of two spots that are both very, very important. One of them you were talking about “is it our duty to a certain extent to produce things in a reasonable way and support people and society, and I think one of the the things I find interesting there is Emma Kevauny did a talk on Dark Patterns at European Test Conference last year. It’s about how, the way that certain websites operate, they actually trick you into spending more money or clicking that button. At what point do we cross the line of getting a click through rate to actually being not quite proper with the way that we’re handling our customers and people on our website? So I found that really interesting.
MATTHEW HEUSSER: Yeah, there’s an ethical line there. We could almost do a whole show about those ethical lines. That’s tough. I just read a thing about a website where a programmer wrote a program to email people after they had opted out, so they made their own email list and you opted out, and they were just going to wait ninety days and start emailing you again. That was a feature request! I think the programmer eventually left, which in fact means he did the feature request. That’s a tough one… but back to ThoughtWorks. You mentioned the session on heuristics and oracles. How long is that? Where did you get your material for that, and can you give me an example of one of those?
ABBY BANGSER: We have probably eight sessions, maybe, that are an hour and a half long, and are hands on but very targeted learning for testers. They range from how to analyze a requirement before it may go into development through to testing with manual and automated techniques. The oracle and heuristics one was a way to give new testers some frameworks, just like we all talk about to be able to get started in a space they may not have a lot of experience in. That five weeks is extremely jam packed. I don’t think it’s expected that the new hires are experts in that space by the end, but we introduce it week three, where they’ve just begun working on their own project with co-workers, and it’s for a real client. The trainers kind of play the product owners, but it is based around the idea of a real backlog and a real code base. They can start to leverage those tools, like SFDPOT, Elisabeth Hendrickson’s Cheat Sheet, how to identify an oracle within their testing on the day to day for their product. As a coach there, I would come up and chat with testers as they’re working and ask them what they’re up to and why they’re doing what they’re doing and encourage them to use vocabulary and concrete ideas when they’re describing the testing they’re doing. There’s actually something that you can send back to the client with some confidence, rather than “I tested some stuff, and I didn’t find anything all that bad, so I think we’re ready to go” [laughter]… and that’s going to give them confidence to be able to work with clients and with development teams.
MATTHEW HEUSSER: Let me see if I understand that correctly. You’ve actually got them doing testing. Is the development team which is in the other room down the hallway doing the development the day before and turning it over, or do you have sort of canned exercises that have already been created?
ABBY BANGSER: We absolutely have them doing testing. There’s actually a project team with all the new hires. There’ll be eight or ten developers, a business analyst and a tester or something similar to that number, depending on who joins us for that group. They get given a backlog that has some stories already completed, some stories that are ready for dev, others that are kind of more in the “epic” stage, and need to be broken down, and then they are given a codebase that has a mix of issues in it, as well as some good patterns to follow. What we find is software rarely is a green field. Teaching people how to make a brand new piece of software is great, but teaching them how to work with legacy code, do refactorings, and move a codebase forward is really where the power of being software developers comes from. They spend four weeks working on that project for anywhere from half a day to a whole day over those four weeks, depending on other classroom events and things.
MATTHEW HEUSSER: I guess you have testers. Is it an integrated classroom? Someone’s got to write the code the testers test.
ABBY BANGSER: Yep, it’s just like a project team. There’s a code base that exists before any of the new hires join that we hand over to them and say “now you need to extend it in these certain ways, here’s some stories that you might want to use to extend and produce more features for the company you’re working for”. As they’re producing those features, the testers are sitting right alongside, able to ask questions, test the features once they’ve been completed, just like the way we work with our normal clients. A tester will be engaged from analysis during development and beyond into testing.
MATTHEW HEUSSER: Right, there’s an integrated project room and some of the developers are writing the new feature and the testers are involved in all of it. When you have your specialty sessions, you break them into the three different groups? One group goes and talks about testing, or does everybody learn everything.
ABBY BANGSER: Yep, so there’s about a third of the specialty sessions are for everybody, and about two thirds are going to be more based on your specific role.
MATTHEW HEUSSER: Okay.
ABBY BANGSER: Then everyone comes back together whenever they’re working on the project.
MATTHEW HEUSSER: The general ThoughtWorks stuff, the general technology stuff, every tester at ThoughtWorks has to have a general knowledge of how Rails works, or whatever. How HTML works, and there’s the specialty tester stuff, and then there’s actually doing it with deliberate practice. Sounds like maybe the specialty tester stuff is maybe eight hours, ten hours, twelve hours and would make most sense if you were there for the whole thing. For those of us that are listening in on the Internet, people who are home rolling their own training programs in testing all the time, or else you don’t and you just get inconsistent results.
ABBY BANGSER: Yeah, I think it’s just that for everybody who is home rolling their own training programs it’s keeping in mind that it’s a growing process for us, and should be for everybody. We look at ways to improve it after every single group of new hires that comes through. We spend almost two months at the end of every year really looking for the larger changes that we can make to improve for ourselves, since between groups we may only have a couple of weeks and so the changes may be quite small.
MATTHEW HEUSSER: Sure.
PERZE ABABA: I wanted to dig deeper into the deliberate practice piece that you mentioned. I know that during Abby’s TestBash talk that there was this one piece that Abby and James did which they called a “desk check”. Maybe it’s just my ignorance out of this but, it really looked like a mini demo that Abby asked for James to do during once of their exercises, where you’re kind of challenging the developer to say “hey, can you demo what you are doing to me now, and maybe we could prove some of the area, and we could test it then and there as well?”
ABBY BANGSER: I’ve heard different words used for that. We tend to use Desk Check at ThoughtWorks, but it’s just our way of doing a sanity check and a handover from development process to verification and testing. It gives us a chance to make sure what the product owner and business analyst and people on that side were expecting to be built was actually built in the way they envisioned. It also gives me as a tester a chance to be able to see that the main functionality is working so that, if there’s anything small that we see as a defect during that desk check, the developers haven’t lost context yet, they can immediately start to make any changes or fixes there. Finally, one thing that we didn’t really showcase in the talk was, I often ask questions about testing that has been done by the developers. What levels of the application did they test? In what ways? The biggest risk they see? How did they mitigate it? So that I can look at testing as a holistic activity rather than as “well, unit tests were being done by the devs, so what do I want to do for UI tests?” That’s not the most successful route that we’ve found with our teams, so we try to discuss that with the desk check as well. The desk checks can occur at the end of a story as I said kind of as that hand over period, but I’ve often also had them throughout a story as well. As a developer is starting to get completed with an aspect of their story, maybe they’ve completed the API but they haven’t yet done the user interface interactions, they may call me over to have a chat about the API so that I can start testing that, before they start looking at the display aspect or the CSS. It’s really just a way of increasing that communication between the different roles.
PERZE ABABA: It’s very interesting to me in a way that when a lot of companies or teams start their journey into Agile or Devops, there’s a lot of conversations around backlog grooming and how the Three Amigos can help that, but the notion of a desk check that actually happens not before the actual work is done but happens during, and maybe close to after the work is done, mini feedback loops within feature development, that does help affirm or just making sure that we’re on the right path in building a given feature.
ABBY BANGSER: Absolutely, it’s definitely part of that feedback loop. If all you do I talk a lot before you start the feature, how are you going to be confident that the words that were spoken were interpreted the way you expect? This is our way of doubling back on that and making sure that we are all on the same page now that we have something physically in front of us to inspect.
MATTHEW HEUSSER: Yeah, I use the term desk check. I may mean something slightly different, but when the developer finishes the story, he hasn’t even checked it in yet, it’s running on his local machine, come on over, show me what you’re doing, explain to me what you’re thinking, let’s talk about it for five minutes, and maybe I can even do some light testing on it. The developer then understands what the tester is doing, how they do their work, and you can find bugs right there that don’t have to wait for “the developer checks it in, it goes to Jenkins, it gets built, it gets pushed, I get an email notification, I finish what I’m doing and I start it”. So there’s like a one day delay loop there that gets cut out, and I come back and find bugs. Not only that, but the developer understands how I think, so it’s possible the next build or the build after that, the check in after that, entire categories of defects are fixed because the developer knows that I’m going to test for International characters. And for some reason, filing a bug report or even a conversation two days later, doesn’t have the same reinforcing behavior as right at the desk. I think we’re close.
ABBY BANGSER: We just also bring in the product owners, but other than that, yes, that’s exactly what we are doing with our desk checks.
MICHAEL LARSEN: I do much the same. We have a similar environment with our development team. Socialtext prides itself on being a bit of a distributed group. We do a lot of our stuff separate. We don’t have the ability all the time of being able to just walk over and sit on the person’s desk and say “hey, what’s going on here?”, but we do the same thing in our chat channels or sharing screen sessions. It’s the same deal. It does come down to the fact that it’s one thing to say “hey, we’ve got a story and go work on it” versus just getting in with them and just talking with them about “Hey, this is how I go about testing, techniques that I use, some of the things that I’m considering”. As a point of example, last week we were trying to determine the proper order of operations to make sure that we were getting what we expected and that things were showing up the way they were, and it was really very helpful because that programmer say “Oh, OK, I see why you’re thinking that. That’s OK in these circumstances, but there’s other times that we need to be looking at it this way”, and just writing things up on the board, just talking out what we though was the proper flow for it, we found five issues that then we were able to resolve much faster than me sitting there in front of the app and having to load it up and say “well, OK, here’s what I’m seeing”. Beak away from it and talk about what it is you’re hoping to accomplish. Yu can really shorten that feedback loop considerably.
MATTHEW HEUSSER: OK, great. Thanks. We’re about out of time but before we go, where can people learn more about Abby and what she’s up to?
ABBY BANGSER: I will be speaking at European Testing Conference in February. I’m going to be doing a workshop so I’m not sure how that will come across in video, but they do a great job in putting up all the videos at that conference. I’m going to be there with Baghia going through the Distributed Team workshop again, and then really excited that, at CASTx, the one in Sydney, just announced, Mark Winteringham and I will be there doing API Testing in February as well, so that’s going to be an exciting one as well.
MATTHEW HEUSSER: Abby is also @a_bangser on Twitter and we’re going to have a link to that in the show notes. Thank you for being on today.
ABBY BANGSER: Thank you so much for having me.
MATTHEW HEUSSER: Anyone else have anything new and exciting?
MICHAEL LARSEN: We’re closing out the year, 2016 is coming to an end. I do want to say though, to everyone who has been listening, and commenting and giving us feedback, you’re definitely helping. If you really like the show, please give us reviews on iTunes because the more reviews we get, the more we bubble up in the search and people know that we exist. Keep listening. If you enjoy it, tell a friend. If you really enjoy it, give us a review.
PERZE ABABA: For me I just want to give a shout out, I just recently found out that there is a vibrant group in the Phillipines that primarily looks around the practice of software testing so this is software testing Philippines. They’re actually two thousand strong and they have monthly meetups, and one of their primary facilitators and leaders is actually a volunteer for the Association for Software Testing and Ian Pastelos I think has done a really good job in ushering the ideas of testing and helping that particular group, so I just want to give a shout out to Ian Pastelos, Michelle Lagare as well as Mel Alicando for doing such a great job in keeping that, and not every meetup group has two thousand members and to keep that in a way where they are consistent with their meetups is a really admirable thing so, guys, keep on doing what you guys are doing, you guys are doing well.
MATTHEW HEUSSER: That’s awesome, thanks Perze. Thanks everyone for being on the show. We’ll be back again in two weeks.
PERZE ABABA: Thank you.
ABBY BANGSER: Thanks, all.
MICHAEL LARSEN: All right, thanks a lot.