Biography

Wim Decoutere started his testing career at CTG Belgium almost 15 years ago and has been testing at a number of companies ever since, mostly in the financial sector. He’s passionate about teaching and feels at home when standing in front of a classroom. A couple of years ago, he became a full-time trainer, coaching and teaching about the wonderful world of testing but also ISTQB, IREB, test design techniques, soft skills, etc… As a veteran youth instructor with a passion for learning theories and people management, Wim is constantly looking for new ideas to improve his own performance and that of the entire testing team.

Talk

Extreme Shift Left / Out with the Requirement Engineer?

To help decrease the time-to-market, testers have to reinvent themselves constantly. With the Agile transition that a lot of companies are undergoing, testers have to be part of multidisciplinary teams and become more T-shaped. To still be of use in a DevOps-oriented delivery cycle, testers should be able to automate and know how to code. But how many different caps can a tester handle?

To give an answer, you should know there are only 10 types of people. Those that understand binary and those that don’t. If you don’t get this joke, learning how to code or how to automate your tests is probably not your cup of tea. So how can you keep up with the ever-changing expectations of testers if becoming more technical is not an option?

Every testing course tells you that testing should start as early as possible. To comply with this shift-left principle, we participate in collaborative user-story-writing and review requirements. Becoming better at this will improve the overall quality, but it won’t have a huge effect on the lead time of the project. So what if we would apply this principle to the extreme? What if it was the tester that would draw up the requirements?

In his presentation, Wim is going to explore the idea of a tester doing the requirement engineering, or the inverse of a requirement engineer doing the testing. He will explain how requirements elicitation techniques, such as paradox brainstorming and 6 thinking hats can be beneficial for the tester, but also how to test techniques, such as Decision Tables, can ensure a higher quality of requirements. He will elaborate on Wieger’s prioritization matrix, Kano’s classification model, and other requirement engineering tools beneficial to testers, so join him, if you want to discover more from the requirements engineering toolbox and how to apply this in your project.

Session Keywords