The Freelancers' Show 106 - Testing with Stephan Kämper
The panelists talk to Stephan Kämper about testing and why it is important in the freelancing world.
CURTIS: Sing the intro, Reuven. Sing it. [Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.] [Bandwidth for this segment is provided by CacheFly, the world’s fastest CDN. Deliver your content fast with CacheFly. Visit cachefly.com to learn more] ERIC: Hey, welcome to the Freelancers Show. This is episode 106. I'm Eric Davis. On our panel today we have Curtis. CURITS: Hello. ERIC: Reuven. REUVEN: Hello there! ERIC: And then we have a special guest, Stephan Kämper. STEPHAN: Hello. ERIC: So Stephan, why don’t you go ahead and introduce yourself. Tell us a little about what you do, that sort of thing, so we kinda get an idea. STEPHAN: Yeah, sure. As you’ve already said, my name is Stephan. I studied Physics, worked as an oceanographer for something like five years, and I'm a tester for 12 years now. And at the end of the next month, I’ll complete ten years of being self-employed. When I realized that, when Mandy invited me to the show, I was kind of shocked that I only waited one, two, maybe three years after the university, after I started being self-employed. Occasionally, I'm pretty surprised by that. Anyway, my business is testing mostly large-ish software, or large software systems, and my – well, my [inaudible] languages, not in particular order, are English, German, and Ruby. CURITS: So I assume when you say testing, you're talking about automated testing, correct? STEPHAN: Yes. I started testing for companies that have used object-oriented database systems for C++ and Java systems, and there was nothing but automated tests. I think, like 10,000 pretty different test cases, over and over. But I also did my little testing for smaller apps like iPhone apps. Mac desktop clients for various, mostly social network things, but the [inaudible] thing is, the one thing that I'm really into is testing large systems. [Inaudible] e-commerce system, which runs on a couple of several machines. So that’s my little testing [inaudible]. ERIC: Okay, so, is it just testing, or is it kind of like the whole QA process that you do? STEPHAN: For my current project, in fact, I am responsible for going live about two times a day – that’s what the target is. We don’t actually make it every day, but yeah, I essentially do the releases to the right system. Of course, there's a process behind that – from the automated test, running my little testing, checking the occasional, checking the layout, which you can’t really do very well with automated tests because that’s a web application, [inaudible] apart from working well you also want it to look nice, right? ERIC: Right. STEPHAN: That’s where my little testing comes in, [inaudible] the whole thing of user experience rather than only UI. I saw that one on Twitter the other day, the difference between UI and UX explained with a bicycle. The views are on it, the gears, the cogs, everything – and that’s just the UI. But the happy person riding the bicycle is user experience, and that's something you just can’t properly test in an automated way, I believe. ERIC: Yeah, or in my case, the UX is me not able to turn a bicycle and crash into a wall, but that’s a different story. REUVEN: [Chuckles] I like how –. CURITS: It requires a video. STEPHAN: But it’s also an experience, right? ERIC: Oh yeah, that’s one thing it is. I get this question because a lot of the stuff I did was development but I do test-driven development, so the bulk of that includes unit tests, and automated tests, and kind of working my way up to acceptance testing. One kind of concern I get from my clients a lot is why am I spending time testing, because they're, in a way, paying me to write code, or that’s what they are thinking. Why am I running tests, which aren’t actually code that runs? I mean, what do you say to a client that kinda thinks that or has that concern? STEPHAN: Personally, I think that’s a valid and good question. It really depends on how the client is involved in the whole development process, because if he doesn’t have some way of testing what you deliver, who will, right? ERIC: Right. STEPHAN: Probably no one if you don’t do it. Actually that’s one of the questions that I have, how do you test your own stuff? I mean, is it tested by your clients or customers as well, or do you hire a tester to do it for you, or do you just depend on, I mean, just on their [inaudible], depend on the testing that you do, which, as you said, is test-driven? ERIC: Yeah. I mean, with this client, basically when I release something, I tell them, like I tested stuff, they would go in and manually test it, and then I kinda explain to them that they did the manual testing because they're also looking at, like what you said, the layout and kind of how things fit together. And I told them, “Well, now that you’ve gone through a test of that and I have automated tests covering that case and other cases, you now don’t have to do that layout testing and all that stuff every time. You can only test kind of a new functionality or if there's bugs or [inaudible] you're willing to test – those differences, instead of the entire system as a whole, every week released. STEPHAN: Mm-hm, yeah. REUVEN: Yeah, I feel like [inaudible] now we’re winding down an upgrade of a large project form Rails 2 to Rails 3, and the CEO of the company said, “So, now that you're done, we’ll have our testers work on it.” I said, “Really? What are your testers going to be doing?” and it’s not a huge amount of test coverage on a software, but it’s a fair amount. They said, “Oh, I’ll send you our QA manual.” And it’s literally 40 pages of ‘go to this page, click here. Do you see this? Go to another page, click here. Do you see that?’ I was thinking to myself, “I don’t think he quite understands the advantage of automated testing here,” because we could take easily two-thirds of this book, if not more, and they could automate it and then it would always work, and then we wouldn’t need to waste everyone’s time waiting for these testers to do their thing. STEPHAN: Yeah, I personally am sad to hear that. A mixture between sad and mildly upset, because that’s – for anyone, find a human being, I think that’s too boring to do that the tenth time, or even the third time. Maybe it’s just me, but I consider that to be terribly boring, and totally automatable, and it should be automated, in my opinion. So that’s testers or developers or layouters or designers can actually test the thing that you can’t really alternate well, like explore how the whole thing works. For a client that should and wants to use it, if it’s a shop, the customer wants to buy stuff. And also, I think, what easily kinda falls off the testing is to discourage users to use your system [inaudible] guys who don’t want to be on your system. I guess, guys who want to steal your credit card info, or use your information, or what have you – you just don’t want them on your system. ERIC: And you mean like testing for security stuff? How would you not have them on your system? STEPHAN: Yes. I mean, the few things that you can do; few things probably can be – in some way – automated, or at least monitored like [inaudible] to your side. Ideally, you don’t want those guys on your system, I think that’s an interesting and hard question to ask and to answer on how to make them go away or [inaudible] look at your side. Or realizes just too much [inaudible] and try to break into someone else’s web application. ERIC: Right. REUVEN: Hold on I'm curious with whether your clients come to you just to do the testing on applications that already exist, or systems that already exist, or if you're interest in testing is part of a larger set of development projects that you do, or any development project that you do? STEPHAN: It’s a mixture. A few applications – I mean, most of the applications that I tested already existed when I joined the project. There's just so much, so many green field software development projects out there, most of it is just systems that have already run. So I would say, 70-75% already existing systems where testers left the company, or where they realized that they have so many bugs in production, or other issues, but they want to hire someone as soon as possible, and that’s usually where I come in. But there are exceptions where just a company realizes that they want to deepen their knowledge about software testing other than the testing that you do in the test room [inaudible], which is not testing really – it’s more of a design exercise, or software design, rather than testing. ERIC: Right. REUVEN: I guess, then, the companies with which you work see your added value not just as – I guess one of the ways that you’ve managed to succeed is not just being ‘Oh, another Ruby on Rails developer,’ because we’re all a dime a dozen. But rather, you are coming with specific expertise and specific abilities, specific experience, that can provably improve their ROI and improve their software maintainability and stability. STEPHAN: Yes. I mean, [inaudible] for my service as a programming tester, but the main purpose for me on any software project is testing the software, which is providing information to those who make the business decisions, to support them to decide whether or not to go live with a certain release, or whether to put live certain features to certain release, because that’s not really not my decision. I provide technical information so they have bases on which they then can decide whether or not to go live on a certain date. Or to delay going live. ERIC: And that’s something that one of my clients dealt – basically they had a whole third party testing team. I don’t know remember how many people were on it, but they verified the high-level details and the other big thing they were is they were the people who basically let a release go out the door. If the testing team said, “No, this isn’t ready” or “There's a critical bug,” they can hold back release. They were the gatekeepers of the release process. STEPHAN: Yeah, I see that. There certainly is a point to that, but I don’t feel that testers should be in that position. I've seen a few releases that I thought I didn’t find any problems, performance was great, scalability was great, and still there might have been one reason or another that I didn’t know or that I wasn’t aware of that was so important to not go live with something, and still that decision was made, and that could be the reasons – because there are applications from the – laws change, and then you cannot put certain features live, which has nothing to do with the technical usability or whatever, as a feature, but just the changed external situation. I would find [inaudible] I consider a blocking bug, which I consider so bad that I wouldn’t do the release, and so seeing it has been put through production because you want to hit a certain market window, the season’s shopping time frame, or there are some other reasons. And actually I think that’s really none of my business – my business actually is to give a very good foundation on technical terms to allow them to make these decisions. And of course it happened, I said, “Look, these four defects, which is just going to prevent customers from buying stuff, or from turning bad stuff that they bought and didn’t want, and they can’t send it back for whatever reason.” Of course [inaudible] based on that decision [inaudible] almost make decisions to not go live with the feature. And occasionally, I make the decision to not even stop testing apart from doing some [inaudible] test and just see the system break down and not even boot or whatever. And then any decision to go live would just be a bad mistake on business terms. ERIC: Okay, so it almost sounds like when you're doing testing, it’s not so much that you're, like you're saying, “Okay we’re releasing this” it’s more like you're consulting the client and saying, “Based on my testing, I give you the advice to go live with this or not based on technical reasons, or based on what you see,” and then let the business kind of figure out if there is a season release and they're going to be slammed, or there's other reasons, they can take your advice and think about it and decided for them if they actually want to do the release or not. Is that what you're saying? STEPHAN: That’s, correct, yeah – in most cases anyway. There have been cases – actually it was my first testing job after [inaudible] university where the ultimate testing was so advanced for that time, and that was 2001. And the process is that if all tests pass, we will release to the customers, and if one test fails, we won’t. And that [inaudible] just an easy technical decision; even that could have been automated. Well they still want someone to press the red or green button to stop a release or just to roll it out; it was just an [inaudible] something, and that happens. And currently, we release a live, as I said, once or twice a day. Occasionally there's a day where we don’t release a live, but essentially that’s my decision, because of the whole process of delivering and stuff and how we develop this particular software, that it doesn’t really matter who makes the decision to go live because there's always [inaudible] that can be deployed to the production system and that provides some value for the customers. ERIC: Okay, so I have another question. I've had this happen where I work for a company and there's multiple decision-makers – there might be a CTO and a CEO – and I've had it where the CTO brings me in, and in a way wants me to help convince the CEO of the value I bring. So it’s kind of I come in to a kinda political standoff-ish meeting, and I have to kinda demonstrate my value. For me, I do software development, so it’s a little bit easier because that’s kinda the core thing that they're looking at. Have you ever run into that kind of experience where you have to kinda convince the company that “I'm going to provide you value, there's documents and cases for me providing value for other companies,” and how do you actually convince the clients that what you're going to do has value? Especially if, like I said, one side of the company kind of sees you have value and another side doesn’t. STEPHAN: Wow, that’s a very good question. I actually experienced the opposite twice, where companies essentially fired our testers all at the same day, or nearly all of the testers, because they figured that tests do not only cost in terms of fixing bugs, but also preventing others from being productive and not providing any value at all. At that point, I figured that that level of mistake, I would rather make myself, and then became self-employed essentially. And of course, these kinds of decisions I make always and everywhere, but to answer the question – actually, no. I didn’t have to defend the value of testing, or the value of the know-how I would provide the companies because they want to hire me, which means they essentially made the decision to hire someone to help them test their systems, and they probably have seen issues of whatever kind they want to be addressed. That could be customer complaints, that can be support costs or what have you, thus the desire to create really great software, which I think I possible. REUVEN: So you’ve never had to go into a client basically convince them that testing is a good thing and an important thing, and it’s worth an investment? STEPHAN: No, not really. I have to say that one contract was first extended for another quarter at one point, and then the client decided that I was too expensive and canceled the contract five or ten days after extending it, which I did find funny. But hey, it’s their decision. I'm self-employed because I think I can handle that and it’s their decision. I think SATA was a great product, it was a great company, other than that’s the end of the contract. And that happens; and that's my business risk. And I'm fine with that decision. REUVEN: When you said that you work with companies that wanna make great software, and so they're just [inaudible] testing it and making it more robust – are these typically high-tech companies, large companies, small companies, or if you found that they're all over the map? STEPHAN: Yeah. I think that’s a great term – I find they're all, in fact, all over the map. And actually, I got the impression that kind of startup companies or very high-tech companies may tend to not find testing that valuable, because they want to create stuff for their customers, for their clients, that needs to be finished as fast as possible. Even today, people still think that testing just slows things down – and it may, in the beginning. But of course my opinion is that it’s well worth it. In fact, in one conference where I gave a presentation about system testing years ago, at the end of my talk someone asked, “How can we ever start to test our stuff when our CEO explicitly forbids that?” I'm afraid I had no good answer to that other than saying, “You do it at your own risk, the testing, but do it. I would do it anyway.” I think that’s part of being a professional software developer, whether you are more of a programmer or a tester, anyway, it doesn’t really matter; you need to test your stuff. ERIC: Right, and that’s what I've kinda told my clients over the years is – they’ll say, “Just not [inaudible] these automated tests or just not do as much testing and you'll save us some money” I’d tell them that the only way that I can be as productive as I am is because I test stuff. Because I don’t want to come back in a week and have to spend 30 hours manually testing to make sure stuff didn’t break. I’ll spend a little bit of time upfront, and when I saw my clients I told them that it’s not optional. If they want me not to test, then they're not my client anymore and I’ll walk away. STEPHAN: Yeah, correct. I think that’s – you expect that from everybody. You want your medical doctor, or surgeon, to wash their hands before they examine you or cut you open – that’s just good practice, and it’s necessary to keep things clean and alive and going. And you want your car mechanic to test that your – I don’t know, replace the winter tires. You want them to make sure that the summer tires are tight and fast. To me, that’s just the role of testing in software development, in general – just keeping things clean and knowing what the risks are. REUVEN: I'm curious to know how you find your clients or how your clients find you, because I generally had – maybe this took forever too [inaudible] I'm actually curious about [inaudible] but in general when I talk to my clients about testing, I would say at least half of them are almost violently opposed to it, Seeing it, as you guys described, a waste of time. STEPHAN: Mm-hm. Well, most of the times I get contacted through agencies, which I understand that none of you really like or appreciate. For me, it worked. Pretty well, so far, with the occasional exception to that rule where I just [inaudible] years ago, after the end of a project I tweeted, “Look guys, I'm available for any project. If you know anyone –” and seconds later got a response, “Would you mind working this and that [inaudible] for this and that company?” I said, “Huh. [Inaudible] Yes, sure I do.” But most of the time, it’s really bigger companies looking for a tester – not necessarily me in person because they probably don’t even know me – and then they go to the agencies and the agencies just know me well enough to know that they better not contact me for programming work, or programming work in general, but just testing. CURTIS: I'd say most of my clients are okay, like they’ll accept the testing, especially after I tell them it’s part of my process. What's more common is I’ll have a client that'll say, “Yes, we recognize testing’s good, we recognize that. It’s going to make the software better, but we haven't been doing it or we haven't had time to do it,” and so it’s kind of the thing of like I come in and I actually have to [inaudible] the test and kind of get the testing stuff kind of up to par. It’s like brushing your teeth – you know you should brush your teeth and floss but you don’t do it all the time, and the dentist gets on you about it. STEPHAN: Yeah. Sad, but true. But I can’t anymore [inaudible] to it, it’s just keeping things clean. I'm kinda surprised that I don’t find it hard to sell testing to my customers or my clients, but you do. I find that very funny, in a way. ERIC: I was thinking about it, because you said you worked with agencies – it could just be, if you get work through agencies, maybe the agencies have kinda sold the client on you and your testing skills and all that ahead of time, where I source most of my clients directly, so they're coming to me either at the idea stage or very early on in the development where they might have done a prototype just so something quick and rough, but they haven't actually flushed it out, so it might be they don’t have a process for testing. Most of them don’t even have a process to do software development, like I establish that for them. And so maybe that could be part of it, maybe you're working with more mature companies, or maybe they have more stuff flushed out around them, and they have already recognized testing and can actually, “Yes, we’re doing that; that’s something we do” where as mine, it’s not really established, it’s not part of who they are yet. STEPHAN: Yeah that’s absolutely possible. Even likely, I would say. Most of my past clients are companies with more than 2,000 to 5,000 employees, so not small businesses anymore, in any measure. ERIC: And mine, most of mine, I think are under a dozen or are just starting to scale up – they just went above a dozen, but they're still under a couple hundred, easily. STEPHAN: I had a few clients – in one client’s case, a one-person company was a client, it was another one-person company who did the programming, and then I was the one guy that was testing – that was me, and that was as small as it can get. But most of my projects, the project alone was probably 12 people. In many cases, that was just one small-ish project and the [inaudible] dozens of and one or two cases, even hundreds [inaudible] systems for anything that you could imagine. That setting was really a large company with – I don’t know – tens of millions of customers. REUVEN: Yeah, when you're at that point where you have tens of millions of customers, it seems to me that you have both the money and the incentive – hugely so – to invest even large amounts of money on testing [inaudible]. STEPHAN: Absolutely, yes. [Inaudible] I think it’s seen as more of a cost rather than an information service, or maybe a quality gate, which is a term that I don’t fancy, really. Because I think I'm not the quality gate; the teams that I work with, every single person is very aware of his effect on the overall quality of whatever system we are creating, or whatever service we are providing. So I can’t call quality a sure software, or a product, because I don’t even have the means to, I don’t know, persuade colleagues to write better programs. Come to think of it, I think that’s a silly idea to approach someone and say, “You need to provide more quality work.” Does that make sense? REUVEN: Meaning what? To say to people, “you just need to do a better job” is not going to do the job; you need to give them the tools to make that possible? STEPHAN: Yeah, I mean, you can provide training, [inaudible] coaching, and there's no way to force people to provide more beautiful code. Or that’s not the way they write code, maybe it’s just me, but I don’t have an idea how to push people into a certain direction of writing better code. REUVEN: One of my favorite books is probably from close to 20 years ago – it’s called The Machine That Changed the World, and it was about the development of what's called lean manufacturing in Japan, especially by Toyota – the car industry – and how one of the many innovations that they had was to put a string or like a rope next to every single person on the manufacturing floor’s workspace. And if you were working there and you saw that something was wrong, you not only could, but you were encouraged to pull the rope and bring the entire assembly line to a halt. And the idea was, that yes, this would cause utter chaos in the beginning, but over time, people would see quality as their jobs and as every one’s jobs, and better to fix things before they get out of the door than afterwards. And I have to assume that over time there were fewer and fewer cases of people actually pulling the rope, but I think the message that it sent was very true. STEPHAN: Absolutely, that’s really what I think as well, and I think it can work in software development just as well, only I have not yet the chance to work in a software development that does that. I mean, it stops the line, it’s simple enough. We find the bug wherever, we stop all work to fix that bug, write a test for it if possible, and then continue further development of the system. And I think that's a very clever idea because if you do that, not only is it that you create an awareness of how problematic bugs are, because it stops everything. I think it’s also a great way to avoid building more functionality based on a certain behavior of a system, which includes bugs, which are then probably very hard to fix because all the system or subsystem or component may depend on that particular behavior, which is in a certain situation was considered a bug, but then your new feature depends on that bug to work properly, and that’s a very bad situation to be in. Aand I think you can avoid that if you stop the line, fix the bug, and then continue work. ERIC: Yeah, the only problem I could see is if you'd stop the line but you have, say, four developers, you could have three people idle. And I know that's a big kickback I get from some companies where they want their people working, so it’s a hard thing to balance. You might stop the line, the developer who works in that section, or maybe the person who introduce the bug, if you can find that out, they stop working on the new feature, work on the bug, and let everyone else work in other areas. But I've ran into cases where that’s hard, especially when it’s a performance bug where it’s just – the code looks like it works, but when it runs in production it’s just dog-slow. That's a hard thing because one guy can work on it but the three others are just kinda sitting there and they can’t really do anything until that person’s done. STEPHAN: I totally get the point of what you're saying, and that’s what I sometimes think as well. But then the guys at Toyota, apparently – I mean, they stopped the line and didn’t produce any cars until the problem was fixed. But I don’t see a big difference in software development, and probably – I don’t know, I have no idea how many people worked on the modern car production line; probably not that many people anymore, but still there must be people going idle on the production line. People that maybe can’t help to resolve the immediate problem, but I think when you start with that, every stop where you can’t help other people, there's always something that you can do. You could add another test phase for the system integration test, or you could re-factor some code – I mean, there's always something that you can do not writing, or not continuing with the feature, but just making things better, making your CI system more stable, or anything that really improves the process of creating value for the customer. ERIC: Yeah, I see that’s [inaudible] the company culture has to do that, and I know with Toyota and their lean stuff, that’s a big part of it, because like the example I gave earlier with the CEO or the CTO where he didn’t want people testing because it would slow stuff down. If all production code development stopped when a bug was found, I know that kind of CEO would just go crazy. He’d be so mad because [inaudible] you guys can keep working on other things and [inaudible] not. And I've seen that, I've experienced that in the past, so also I'm kind of – to stop the line is interesting, but I just don’t know how it will actually work in real life, like I haven't seen it. STEPHAN: And neither have I. As I said, I think it could be worth the time box experiment to see whether it creates more trouble than it solves, and then if that’s the case, well you know what to do. ERIC: Yeah, I've seen something like that work. Say, the checkout part of the system, there's a bug there, and so all work stops in the checkout part bit. There's other parts of production code that people are working in to kind of work around that bug while someone’s fixing it. STEPHAN: Yes, true, and that's perfectly fine, and that’s absolutely the right thing to do, I think. REUVEN: If someone were interested in – I want to divide this question in two parts – but if someone were interested in being a better tester in their own software development, or if someone were interested in specializing in testing, what would you suggest that they do if they're interested in freelancing and pursuing this as a career? STEPHAN: There are a few good courses, and I happen to – I thought after five or six years in testing, I thought that I know it all, but there's always something that you can learn. In the last year, I went to the Association for Software Testing’s BBST courses, which is the abbreviation for black box software testing. There are three courses on testing itself, and I found that so valuable to work on the course that actually involves some testing activity, like figuring out when using the certain design, test design technique and learn how that works, and apply that to some product, and find defects in that product. And I found that very, very helpful and I think that could be – I mean, finding bugs and filing bug reports against open source software, for example, is a very good start for attuning your tester, or even a [inaudible] tester, to show your work, your main work product, which is for testers. I mean, for testers the main product is a bug report. You can show that to the public and say, “This is my work. Here’s how I write bug reports, and here’s the defect I found in that open source system; you can look at it. And I find that to be a very nice idea because most – actually all of my customers have that fear of bug reports becoming public. I think that's kind of understandable, but for me, that creates a problem that I can’t really provide any visibility for my work. So that was one of the nice insights. I can only recommend these courses – in fact, I find them so great that I started acting as a volunteer instructor for these courses [inaudible] I probably learned at least as much compared to actually taking the course as a student. ERIC: Okay, so let’s go ahead and get into the picks. Curtis, why don’t you start? CURITS: This week, I picked up a new battery, actually for my phone, my iPhone and my iPad. My old iPhone had a Mophie Juice Pack Air Case, which doesn’t work with my new 5s, so actually just got a Mophie Juice Pack Power Station Pro, which is one of the rugged, rubberized, drop it, drop it in water, batteries which willl work for all of my new 5s. A few weeks, I guess a few months ago, Eric got a new 5s, so yeah, the battery would allow me to get a full iPad charge out of there and some extra for my phone when I'm out traveling, which is nice, and it’s nice and small, and fully rugged, so I don’t have to worry about it say, on my back, if I'm biking. ERIC: Alright, Reuven? REUVEN: So I got two picks for today, one of which is – I'm going to remind people about that book that I mentioned earlier, The Machine That Changed the World. I don’t know or really care that much about cars, but I found this – I didn’t know much about auto manufacturing before I read this book. I found it to be completely fascinating, and it changed my view of many factoring physical goods in general, and just the business in general. And the second thing is I heard mentioned on Startups For the Rest of Us this new Chrome plugin called Momentumdash, the dashboard. Basically, you tell it each day, or whenever you want, what's the thing that you wanna be working on; what's the one thing you wanna be focusing on, and every time you open a new tab or a new window in Chrome, it gives that to you in your face. “So, have you been working on such and such?” Well it’s actually not that quite bad, it just reminds you of what you're supposed to be working on and some beautiful photography. So I've definitely changed it to be my default Chrome page and I don’t know if I've been a lot more productive, but I've enjoyed the photography and feeling like, “Oh yeah, I really should be focusing on that and ignoring other things.” So there we go, those are my picks for this week. ERIC: Okay. Stephan, what do you have? STEPHAN: I have two picks, one probably has been picked before, and that’s conferences. My tip and my pick is to attend conferences at least twice a year, or even better, speak at conferences. The first one is a conference strictly and strongly related to your own profession. I like the Agile testing days – for that, obviously, it’s a testing conference. And the other two’s something else. I most of the time choose a programmer-related conference – could be the EuroCo, the European Ruby Conference, or last year, I went to the other Barcelona Ruby Conference, and the idea behind that is if you do that, you also deepen your knowledge in your focus field, but you also widen your knowledge in not-so-related fields. And I find that very, very important to keep up-to-date on all kinds of stuff. I think that’s very, very important. And the other pick is a Scottish, I’ll say singer-songwriter, and that’s Amy Macdonald. ERIC: Okay. And then I have one pick today. Basically it’s winter in the US, and where I'm at, it’s really hard to get fruits and stuff like that, so we have to get a lot of frozen fruit. I've been making smoothies for a couple of years now, but I just happened to cross a recipe the other day. It’s really simple; it’s actually one orange, half a frozen banana, and then just a handful blueberries. I have frozen blueberries, but I think strawberries will work. And surprisingly, it’s really good, and I thought the orange would overpower it, but you can almost not taste the orange. But it’s nice because you throw it in the blender, you have a smoothie – it’s like three servings of fruit, and it’s really good especially in wintertime when it’s not around, I like having that. So that's my pick today, low-cost smoothie. Okay, and so with that, that’s the end of the show. Stephan, thanks for coming. Thanks for talking about testing. Hopefully I can use some of this to take to my clients to kinda show them the value and actually see how important testing is. STEPHAN: Yeah, thanks for having me. ERIC: Alright, take care everyone. REUVEN: Bye! CURITS: Ciao! STEPHAN: Thank you, bye, ciao!