This interview with Hans Buwalda is part of the Hexawise “Testing Smarter with…” software testing interview series. Our goal with these interviews is to highlight insights and experiences as told by many of the software testing field’s leading thinkers.
Hans has gained experience as a developer, manager, and principal consultant for companies and organizations worldwide. 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.
Hexawise: What drew you into a career in software testing?
Hans: It was "accidental". I worked as a management consultant in my home country, the Netherlands and was sent on an assignment to a major customer. They had serious problems with both test design and automation. In particular it was difficult to involve the (very busy) domain experts, and the automation was virtually impossible to keep current. Using keywords turned out to solve both these problems, and I have been pioneering that ever since with the Action Based Testing Method.
Hexawise: You were an early pioneer and key contributor to the keyword-driven test automation framework which has stood the test of time and is widely adopted in the industry. What drove you and other early keyword-driven framework pioneers to create it and advocate for its broader adoption?
Hans: I believe the two main drivers for using keywords are readability for non-technical people, and long-term maintainability of the tests. I think my core message is not as much the keywords themselves, but more the importance of test design in achieving those goals. Without a good modularized organization of tests keywords will fail, and so will for example Behavior-Driven Development (BDD). To say it even stronger: the worst automation projects I have seen were keyword projects.
Hexawise: What one or two software testing-related experiences have you found to be most personally satisfying in your career?
Hans: I like it when people are successful. In my world that means being able to leverage automation to achieve better quality at a faster pace. Two of my colleagues recently showed me how they were able to help a company in the oil industry reduce time needed for testing dramatically (more than twenty times).
A nice detail there was that those tests were for equipment workflows, and did not involve any User Interface (UI). It is a common misunderstanding that keyword automation is for testing via the UI, but it can work just as well for non-UI testing, like Internet of Things (IoT), services, games, telecommunication, embedded software, etc..
Hexawise: What testing practice(s) do you most wish the software testing community would embrace?
Hans: I believe that with Agile, DevOps and service oriented architectures, we're well on our way. Agile allows for good cooperation between the Quality Assurance (QA), developers, product owners, domain experts and stakeholders. DevOps allows testing to be incorporated into the build and deploy pipelines. And service oriented architectures gives more ways to test than just through the UI.
scalability in automation is not as much a technical challenge as it is a test design challenge. This gives a bit of a paradox: test designers influence the automation success, but are not developers, and do not necessarily have affinity with engineering concepts like structured programming and refactoring, which in turn are key elements of good maintainable automation.
Hexawise: Can you describe a view or opinion about software testing that you have that many or most smart experienced software testers probably disagree with? What led you to this belief?
Hans: "Disagree" is a big word. But I do like to focus on one particular area that many others tend not to address that much: It is my observation over the years that scalability in automation is not as much a technical challenge as it is a test design challenge. This gives a bit of a paradox: test designers influence the automation success, but are not developers, and do not necessarily have affinity with engineering concepts like structured programming and refactoring, which in turn are key elements of good maintainable automation. There are some more elements that can influence automation success, like "testability" of the application under test: to what extend is an application friendly to testing and automation.
Hexawise: You have extensive experience with automated testing. What interesting anecdotes would you be able to share about some of your earliest experiences automating tests?
Hans: An early experience was the very first project where action words (my term for keywords) were used. It was for a major screen trading system, and before I came in a substantial amount of tests had been created with record and playback. When I say that you can probably guess the upcoming/impending disaster... The development team made a slight change in a lay-out of the main screen and virtually all tests stopped working because of it. It was in the early days and people weren't expecting such problems.
Hexawise: One of my (Justin’s) favorite software testing articles of all time is “Soap Opera Testing.” What experiences led you to write it and why do you think it struck a chord with so many testers and managers?
Hans: Thanks for the kind note. It was based on a major project in a large financial institution. The project included re-architecting of all systems, and getting ready for the year 2000. Proper testing was essential, but the tests also needed to be developed and fully automated in a very short amount of time.
To get this done I introduced an approach based on real life stories from the every day practice of real users and good test design (test modules, keywords) to support successful automation. I guess the method appeals to teams and managers because it is an efficient way to translate domain knowledge into, aggressive, test cases, and to get them automated quickly as well.
I believe the two main drivers for using keywords are readability for non-technical people, and long-term maintainability of the tests. I think my core message is not as much the keywords themselves, but more the importance of test design in achieving those goals.
Hexawise: Large companies often discount the importance of software testing. What advice do you have for software testers to help their organizations understand the importance of expecting more from the software testing efforts in the organization?
Hans: You have to be serious about your craft. Know testing techniques, engineering principles and the domain of an application you're testing. Your attitude is important too. Be aggressive to the system under test, but cooperative as member of a team. Second, always keep an eye on the business side.
You should not be testing because you have read somewhere that testing is important. Testing costs time and money and there must be business reasons to invest in it. Not testing saves money, but also introduces risks that can cost money later on. Saving money and losing money are business considerations that well managed large companies tend to take very seriously.
You, or your QA management, must be ready to explain the value of their testing, and automation.
Hexawise: I see that you’ll be presenting at the StarEast conference in May. What could you share with us about those topics? What gave you the idea to talk about them?
Hans: I'm doing two tutorials, one on Better Test Design for Great Test Automation. The other focuses on what makes automated testing scalable. The classes are based on real-world experiences from various projects I’ve done, across many industries. With the many recent developments like cloud and DevOps, automation is constantly evolving, so it is fun to discuss about them.
Hexawise: How do you stay current on improvements in software testing practices; or how would you suggest testers stay current?
Hans: Reading, attending conferences and webinars and hands-on practice still work well. Don’t despair when current developments can be overwhelming. Concentrate on what you need, and be curious.
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 conferences and other events and is lead author of Integrated Test Design and Automation.
Web site: Happy Tester
Subscribe to the RSS feed for our blog.