Jennifer Bonine: All right. We are back with more interviews, and I am glad to have Hans here with me. Hans?

Hans Buwalda: I'm glad to be here. Thank you.

Jennifer Bonine: Thanks for joining me again.

Hans Buwalda: Yeah.

Jennifer Bonine: You know, we were just having a discussion on there's was a keynote this morning and it was broadcast for the virtual audience and one of the topics that, I guess, you could consider it a hot topic in general right now is around do testers have to be technical and do they need more technical skills in order to be successful? Maybe talking about the viewpoint on that, and we should all note that this is a hot topic, so it means people are passionate on both sides of the fence on this one. And you may have even heard some of the folks I interviewed this morning mentioned, she mentioned, if you don't have coding skills, you may be getting left behind.

Hans Buwalda: Yeah. That is an interesting topic. We had two really great keynotes this morning. If you haven't seen them yet, try to catch them when they become available online. And I would say just the best and the second best keynote I have seen in a long time. I'm not going to tell you what was the best and what was the second best.

Jennifer Bonine: You have to judge for yourself.

Hans Buwalda: You have to judge it for yourself. In the second keynote, there was a point made that testers need to get coding skills and move more and more to coding skills. Now, I do believe that is a practical thing to know and to do and you can do some of your own automation, but I don't see it as much as a must-have. I much rather have a tester who understands domain knowledge, who understands testing techniques, who has a tester attitude. And then, the coding, we can worry about that later. The tester can write the test in something like BDD or keywords and something that is away from the technology, and really to put more effectiveness in the test itself.

Jennifer Bonine: Yeah. Well, and just the mindset, right? So, we talk about passion's important, and you should be passionate about what you do and we tend to do better when we're passionate. If you ask someone who's passionate about developing coding, building code, their passion may be different from someone who says, "I'm passionate about testing," right?

Hans Buwalda: Could be. There are people who are, but it's not standard and it's not necessarily what I look for.

Jennifer Bonine: Right.

Hans Buwalda: I always think that it is also a matter of interest. Like, I like to say that developers are the people who like to create things and the testers are the ones who like to destroy them. So, that's more what I would call the dark side.

Jennifer Bonine: Right.

Hans Buwalda: I don't take that literally, of course, but it's a different way of thinking. And a developer will ask, "What do I need to build, what does it need to do?" The tester will ask, "What can go wrong? What can I do to it to break it, or to find the weaknesses," et cetera. And that's a great thing because if you find out weaknesses, the earlier you find them, the easier they are to attend to.

Jennifer Bonine: Yes. Well, and I think that's a really good point. I've seen when you have testers, people who naturally have a testing mindset, they're testing boundaries, they're testing limits, they're figuring out what happens if a component doesn't work or if it breaks. It's almost this natural curiosity about how does it work and what makes it work and what makes it break? And then, as you mentioned, the developers are about, "What do I need to build? I want to build something."

And we'll ask a question a lot of times, when I've seen people get hired, about if I gave you a washing machine, what would be your first instinct about what you would do with that. For a tester, it would probably be, "I'm going to take it apart and see how it works." And then, you would say, "Are you going to put it back together?" And they'd probably be like, "No, because if I took it apart, I know how it works and I've taken all the pieces out." Whereas the developer would say, "Now, I want to put it back together and I want to build it and I want to figure out how it works and then make it work."

Hans Buwalda: It reminds me not to let you anywhere near my washing machine.

Jennifer Bonine: So I don't take it apart into little pieces and never put it back together.

Hans Buwalda: But I do take it apart.

Jennifer Bonine: Exactly.

Hans Buwalda: And the tester would think, "What if I do the washing machine upside down? Does it still work?"

Jennifer Bonine: Yeah, and can it run?

Hans Buwalda: Not that you're going to do that every day, but research unexpected moves that you can think with the system on the test. And you want to know whether the system survives it.

Jennifer Bonine: Right. Well, and you did mention too, there's a lot of options out there for folks, like Cucumber and keyword-driven frameworks, so there are options to use, and I've seen it in organizations. And maybe give us your experience on this where you have folks that aren't necessarily coders who can use keyword driven or, as you mentioned, the BDD or the Cucumbers of the world to use common language as long you're syntax is correct and you're using it in the correct way where it's English language and you can understand it. It's understandable and readable.

Hans Buwalda: That is, you probably know, and this is a good time to plug it, we have our own product, Test Architect, which works with keywords. I actually went ahead and made a tool that translates BDD sentences into keywords and back, so you can take the keywords and translate it back into BDD, make it very accessible for a wide range of stakeholders. While, at the same time, because it can be translated to keywords, it's easier to maintain and to organize than BDD scenarios tend to be. And there's a lot less technical necessities, so you don't need Cucumber or anything to automate it.

Jennifer Bonine: Yeah, so this would maybe be good then in organizations out there where people are saying, "I know I need to get some automation. I know we can't manually test everything, but we're struggling because our organization maybe doesn't have all the skillsets we need to be able to do all pure test automation frameworks that are coded from the ground up that don't have keywords or other components." So, would this be a good case study maybe for someone out there who says, "We really want to do something. We're not sure where to start." How easy is it to get started with something like the tool you guys created?

Hans Buwalda: Technically easy. The technology is fairly straightforward. There can be kinks sometimes for the particles that did not support it, so you can run into trouble, but from a technical spec, it is easy. But I would like you to focus on the just the test design. Test design is always important and it really gives you good quality tests, but for automation it's doubly important. The better your tests are organized, the easier it is to do what they call impact analysis. If there's a change in the application on the test, which test cases are affected? And the better those tests are organized, the better that goes. So, you maintaining ability of the test is not so much a technical challenge, it is more of a test design challenge.

Jennifer Bonine: Yup, and so when you've gone to organizations that say, "Hey, we want to do this," is that where you start with them, making sure that the test design is appropriate, correct.

Hans Buwalda: Yeah, essentially. Another big thing that I will look for is testability. Do the systems on the test expose enough properties of those clean elements, hooks to get to data that is being displayed, hooks for timing? If I fill up a table, when is the table complete? That kind of hooks, how easy it is to automate. And those two together, test design and testability, give you a good handle on UI based testing. And you're aware that tests can go for the UI or you can go for an API, and nowadays that's often addressed for APIs.

There is a trend right now, it's called the testing pyramid. You need to do as many tests possible at the unit test level and then follow the component based test and then, at the top, a very small area for UIs. I'm not so sure that's true. I think the UI is where it all comes together in your system and I would recommend to give ample attention to make sure stuff works using the UI.

The reason people avoid the UI is because it tends to be difficult. And you might remember President Kennedy about the moon, he said that we're going to the moon, not because it's easy, but because it's hard. In my interpretation, it means you should avoid UI if you don't have, but you should not avoid it because it will be difficult to automate or difficult to maintain. If you organize your test early, your testability is in order, and you cooperate well with your developers and others, UI automation should not be such a big problem, especially not web UIs.

Jennifer Bonine: Yeah. So, again, for those folks out there who haven't seen it yet, that pyramid is really ... people are talking about that a lot, of where do you focus, especially for automation. So, I think that's a good point of, "Are we truly focusing on certain areas because they're the low-hanging fruit in maybe easy areas, or are we focusing on them because it makes business sense, and where the impact is?"

Hans Buwalda: Absolutely. Just about unit tests, unit tests have the tendency to be fairly elementary. Once they work, they work. If they don't, they won't break again. They're very useful, but in my perspective, they're sometimes a little boring.

Jennifer Bonine: Yeah.

Hans Buwalda: They're not really the most spectacular testing, while business oriented tests, the more end to end tests, really simulate real business situations that you devise together with the domain expert, they can be very interesting and more exploratory, more rich. And that is the kind of richness that you want in your test.

Jennifer Bonine: Yeah. Now, here this week, you had a session on test automation.

Hans Buwalda: Yeah.

Jennifer Bonine: Yeah. What other sessions did you have this week, or do you have coming up? Do you have more coming up this week?

Hans Buwalda: Just small things like there is the meet together speaker's lunch. Tomorrow I will do a presentation in the test lab.

Jennifer Bonine: Oh, good.

Hans Buwalda: So, that's going to be cool.

Jennifer Bonine: Yeah, so the folks that don't know what that is, the test lab is here at the conference. We've talked about it before, so it's an opportunity, so there's a lot of sessions where you can get information and learn, but there's also a test lab where you can participate and actually hands-on work with things. So, you'll be giving a session in there.

Hans Buwalda: Yeah, it's a very popular thing, and not because I do it, but it's a very popular part of this conference and it's really hands-on. There are constantly very experienced people around that will help you do this. And that would be one of the main reasons for the next conference, not to just do the virtual one, but actually physically go to the place and do this.

Jennifer Bonine: Yeah, because you get an opportunity to hands-on use some of the things people are talking about, see some new things, get exposure to some experts that may help you see it in a different light, look a problem a different way, those types of things. So, that's a good recommendation for folks that haven't seen it. We will check in with them. They usually try and do something that our virtual audience can participate in.

Hans Buwalda: Okay.

Jennifer Bonine: So, I'll check and see if they've got anything for you guys out there in the virtual audience this year, but we try and engage you guys and we've had a virtual audience winner before on some of the testing.

Hans Buwalda: Okay, that's cool.

Jennifer Bonine: So, yeah. We'll see if we can get that. Now, your day job CTO, right?

Hans Buwalda: Yeah, for LogiGear.

Jennifer Bonine: From LogiGear. Any big problems, challenges, what you're seeing as trends in that space?

Hans Buwalda: Well, we live in interesting times. As you may know, that there's an old ancient Chinese curse: "May you live in interesting times." But I think we are, and I think it's very cool. I think that there's a lot of developments that are coming together, obviously hardware and cloud, and DevOps is very nice. Surface-oriented architectures are very cool with the microservices or the serverless computing, all that. So, it's moving very rapidly, and we're happily moving along to relieve that. It's very interesting, I think, it's a very interesting field to be in.

Jennifer Bonine: Yeah, fun to see the changes because they're coming a lot faster, right? The technology advancements are coming faster. Hans, thanks again for being with us. We're already out of time. If someone wants to find you, how do they do that?

Hans Buwalda: Well, they can write me, [email protected].

Jennifer Bonine: Perfect.

Hans Buwalda: Or hans@happytester.

Jennifer Bonine: Happy Tester?

Hans Buwalda: Happy Tester is my site, it's just a single-page site that I keep track of all my articles.

Jennifer Bonine: Yeah?

Hans Buwalda: All the things that I've written, the blogs, so that's a one-stop point where you can see my stuff.

Jennifer Bonine: At Happy Tester or LogiGear. So, Hans, thanks for being with us again.

Hans Buwalda: Yeah. Thanks for having me.

Jennifer Bonine: Enjoy the next session coming up, and we'll be back with more interviews later.

Hans Buwalda: Okay.

Hans Buwalda has been working with information technology since his high school years. In his career, Hans has gained experience as a developer, manager, and principal consultant for companies and organizations worldwide. He was a pioneer of the keyword approach to testing and automation, now widely used throughout the industry. His approaches to testing—action-based testing and soap opera testing—have helped a variety of customers achieve scalable and maintainable solutions for large and complex testing challenges. Hans is a frequent speaker at STAR conferences and is lead author of Integrated Test Design and Automation.