Let’s Test prequel with Huib Schoots

As a prequel to the Let’s Test conference in May, I interviewed some of the European context-driven testers. Today we have Huib Schoots who is a board member of the Dutch testing network association TestNet.

Markus Gärtner: Hi Huib, could you please introduce yourself? Who are you? What do you do for work?
Huib Schoots: Hi Markus, my name is Huib Schoots. I live in Den Bosch in the Netherlands. I am a software tester. Why? Because testing is fun! I have 15 years of experience in IT and software testing. After my study in Business Informatics I started in IT as a developer. Soon I found out that developing wasn’t my cup of tea. After a year of being a test engineer automating tests, I found out that software testing was fun. I have experience in various roles within testing. At several companies I provided (international) testing consultancy in various roles: tester, test coordinator, test manager, trainer, coach but also in project management.

Currently I am team manager test, release and implementation management at Rabobank International. I like combining people (management), test management and agile testing trying to improve testing and making it more fun. I try to share my passion for testing in coaching, training and giving presentations on several testing topics.

In my free time I am board member of TestNet, the Dutch testing network association. TestNet offers its 1500+ members the opportunity meet with other testers and share knowledge and experience. Within TestNet I am responsible for the special interest groups and I participate in the event & program committee. I also co-founded and participate in DEWT, the Dutch Exploratory Workshop on Testing. I am a member of AST and a student in the Miagi-Do school of software testing.

Besides testing I love to play trombone in my brass band, read, travel, take photos, scuba dive and play golf. To stay fit I recently started running. I also love to play strategic board games, but unfortunately I do not have the time to do that on a regular basis.

Markus Gärtner: How have you crossed the path of context-driven testing?
Huib Schoots: Without knowing I have practiced the Basic Principles of the context-driven school in the past and Lessons learned in software testing has been my favorite testing book for years now. Quite some time ago I was not very happy how the majority in the Netherlands approached their testing. I saw too much process, favoring certificates over skills. In some projects I tried exploratory testing and I liked it.

In 2010 I saw some tweets from people I knew from TestNet speaking about exploratory testing. We met at my kitchen table and we founded DEWT. I felt good to have a group of like-minded people to discuss testing. The Rapid Software Testing course I did in 2011 made it perfectly clear to me that I am quite context-driven.

Markus Gärtner: Connecting with like-minded people is one aspect of context-driven testing. Workshops like DEWT help, but also conferences. But what do you do to hone your testing skills?
Huib Schoots: I hone my testing skills in different ways: conferencing, writing and practicing. As you mentioned, I am in DEWT and here we discuss testing and learn from each other. I like visiting conferences and even better: do talks at conferences. I have a blog and write articles for a test news website and agile record. I am also writing a book for TestNet on the future of software testing. Preparing talks and writing helps me structure my thoughts but also forces me to investigate subjects in more depth. The feedback I receive helps me to gain insights form different angles. This is also why I am very active within TestNet. As a board member I am responsible for special interest groups and I participate in the event committee. This gives me the opportunity to facilitate groups and organize events where testers meet and learn.

Last year I became a student in the Miagi-Do school of software testing. I consider this school a community where enthusiastic testers learn and help each other become better testers. The instructors give the students challenges to practice their testing skills and when you show your skills you can earn belts. I like the challenge I received from you last week where I have to study an advice given in a 90 minute video of a presentation. My assignment is to develop my own approach to testing. This is great stuff and I can’t wait to start working on this.

Recently I have organized a testing dojo at work. It was fun and we learned a lot. Some others became enthusiastic about this as well and they will organize the next dojo. I wish I had more time because Weekend Testers sounds like fun and a great opportunity to learn, but unfortunately I can’t find the time to participate.

In April I will do the BBST foundation course. What I like in this course is that you learn more about testing but also improve online study skills, such as learning more from video lectures and associated readings and improve online discussion and working together online in groups. I am looking forward in meeting new testers online and work with them in this course.

Markus Gärtner: How do you apply context-driven testing at your workplace?
Huib Schoots: In the past I applied some context-driven elements in several projects without knowing it was context-driven. For example: try exploratory testing, consider the context in my project more important as the process and organize intervision sessions to learn from others are some.

In 2010 I joined Rabobank International as a team manager. I also became a member of the lateral meeting. This is a formal body consisting of testers and team managers who decide about test policy, test approaches and training for our testers. Here I told the others about Rapid Software Testing. In June 2011 Michael Bolton came to Rabobank to teach 50 testers Rapid Software Testing. This kicked off an interesting change, since then we try new things like mind maps, low tech dashboards, heuristics and we focus more on skills and less on process.

Markus Gärtner: Considering my experiences with the banking sector, do you face struggles with the context-driven way at your workplace? What do you do to change your organization to a perceived less structured way of testing?
Huib Schoots: Not really (yet). We don’t do exploratory testing full swing. Change within our organisation is difficult: it takes quite some time to change the way we work. The most resistance to a different way of working comes form an unexpected side. Some time ago I had a meeting with our audit department to discuss exploratory testing. I expected a lot of resistance, but to my great surprise, they didn’t see any problem in testing exploratory as long as we were in control. Session-based test management (SBTM) will gives us enough control, they expect.

The resistance to change in our organisation lays within the testers themselves. They are used to structuring their testing with processes and test cases upfront. Exploratory testing is perceived less structured and is different to what they are used to.

Markus Gärtner: I face similar struggles with testers in Germany as well. How do you help testers overcome their resistance then?
Huib Schoots: Most important is to focus on “what is in it for them”. I always try to find added value for an individual. A reason why they should change and that is mostly different with every tester I work with. Let me give you an example. We are implementing an agile way of working and we use OpenUp. I see a lot of resistance against implementing this method. I hear things like: “We tried this 3 years ago and it didn’t work” or “It’s OpenUp now, but it will be different again in 5 years, so why change?”. If we focus more on solving current problems, improving and adding value by implementing some practices, resistance decreases. That is why I think we need more coaching in our organisation. Coaches have the time and the skills to work with people on an individual basis and help them improve. If you want to change a whole organization, you can only do it one by one.

Markus Gärtner: Your talk will be on tester and programmer collaboration, and how each other can learn from it. Without spoiling possible participants, what is your experience with programmer and tester collaboration?
Huib Schoots: My experience is that they do not collaborate really. Of course they work together and discuss things like planning, bugs and requirements. But what I would like to see is testers helping developers with unit testing. Testers are able to improve unit testing by only showing interest and asking simple questions like: what are you trying to test here and why? Spending time pairing with the developer to go through the unit tests gains insight and better understanding. My experience is that developers are every capable and willing to expend their unit tests when you ask them.

Developers can help testers to speed up their testing. Developers are able to build “tools” or scripts in just a couple of hours which can save hours of work sorting out reports and log files. Testers should focus more on testability and developers are there to make our life easy. They are more than willing to do that, but we need to help them by telling them what we need.

I have had a nice talk with some developers explaining what I could do for them and how I need their help in my work. At first they were very skeptical and showed a lot of resistance. At the end they were more than willing to collaborate. You just need to take away the perception that testers do not care about what developers do and are only there to show that they are doing a lousy job by focussing on bugs.

Markus Gärtner: Programmers and testers working together, this sounds dangerous to some folks. What do you say to them to overcome their fears?
Huib Schoots: Programmers are great to work with. They can do amazing things for testers like writing scripts, add logging or create special tooling that can speed up testing and make my job easier and faster. The trick is to ask the right questions, show interest in their work and collaborate. Let me generalize a little here. Programmers think they can do a decent job testing. They also think testers can’t code. So a lot of programmers I have met need to be shown what a tester can do for them. But also the other way around!

I was in a programmers meeting a couple of months ago to discuss testing within OpenUp. The first thing that happened was that one of the programmers told me he could test and testers couldn’t code. So I challenged his remark by asking some questions to find out what he was trying to say. It turned out that in his project the tester couldn’t keep up with the 3 programmers so the programmers had to do a lot of testing. I smiled at him and asked him what he did to help the tester do a better (or in this case a faster) job. I don’t know in detail what happened after that, but they started to collaborate more and the programmers started to help the testers. When I spoke to the programmer a couple of weeks later he was very happy because collaborating with the tester speeded up his programming. Examples like this help to overcome these fears. What also helps is to show your skills as a tester and teach your team mates to do better testing.

Markus Gärtner: What do you hope to learn at Let’s Test?
Huib Schoots: My main reason to go there is to meet other context-driven testers. I also hope to learn new insights in testing, find argumentation or ideas to introduce new stuff and see the latest developments and opinions. I like to submerge myself in a place where all people do is talk about testing. Confer with my peers will refresh and sharpen my ideas and mind set.

By enlarging my network I know I will be able to learn from them long after the conference is over. It helps me to read their blogs and articles. If you know somebody and have had discussions with them, you hear them talk when you read their stuff (in a way of speaking of course). It also makes it easier to contact people directly if you have questions or need help.

Markus Gärtner: Speaking about the future of testing, imagine time skipped forward over night, and we’re now in 2030. What has changed? What’s still the same?
Huib Schoots: Good question! We are writing a book on the future of software testing with a group of TestNet colleagues in the Netherlands. But we only look into the future 5 years. It is very hard to predict the future and I think there is not one future for all. Technology like tablets and smart phones are upcoming and apps are getting all over the place. The cloud will have a great influence in the areas like security, performance and privacy. Also the social changes in organisations and people working from home might have impact on our craft, one thing I think of is crowd-sourced testing to cope with all the different devices.

We will do more and more projects in an agile way of working. In agile projects everyone is responsible for the quality of the delivered products. A tester is not alone in this, after all it’s the whole team that tests. Testers will get a coaching role and will coach their teammates. They will teach and distribute their expertise over the team.

To cope with the ever-growing complexity and ever-changing world around us, the requirements of a tester are getting higher. It requires a higher level for the skills that make a good tester: critical thinking, questioning, but also mastering testing skills, for example, applying testing techniques or doing (risk) analysis. In the past testers could get away with not having good testing skills. Because of the mainly confirmative way of testing, coverage of requirements was important. If the report was fine and all requirements were covered, testing was okay. However, finding the major bugs in a short time is a different story. In preparation for test execution, writing the test cases, the tester formerly had plenty of time and the opportunity to hide. In future, expectations will go up: with limited preparation he must show his testing skills applying testing techniques while he tests (exploratory). In projects testers collaborate increasingly closely with their team mates. The tester will quickly fail and not be taken seriously if he can’t show his skills.

Markus Gärtner: Thanks for your answers and your time. Looking forward to meet you in May in Sweden.

  • Print
  • Twitter
  • LinkedIn
  • Google Bookmarks

Leave a Reply

Your email address will not be published. Required fields are marked *