Leverage Domain-Driven Design throughout testing @ DDD Europe

Every time I start working on a new software product I want to learn the domain. The faster I learn the domain I am working in, the faster I will add value to that product. I always start by looking at the tests; they should reflect what the software is built for and how it needs to behave.

However, the tests seldom reflect the same language as the code, the documentation and the communication. Inconsistent language usually is one of the reasons testing slows down the software delivery process. A lot of ‘ping-pong’ going on between several disciplines and even though the product is rigorously tested, there are still a lot of bugs found in production. It is hard, or even impossible to build the right product if there is inconsistency in the language used to communicate.

Join me in this talk where I will show you how to leverage Domain-Driven Design throughout testing. You will learn how to make the language of your tests consistent with the communication used, and create tests that can serve as living documentation.

Transcript

1. Leverage Domain-Driven Design throughout testing
2. When I was young…….
7. 7 To communicate effectively, the code must be based on the same language used to write the requirements - the same language that the developers speak with each other and with domain experts - Eric Evans
11. Jira Driven Communication
12. 12 Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure. — Mel Conway
13. 13 https://martinfowler.com/articles/microservices.html
14. 14 A separate QA/Test team lead to silod test suites, with their own language. Use isolated test per Bounded Context, save all tests under source control where the code resides.
15. 15 “The indirectness of communication conceals the formation of schisms—different team members use terms differently but don’t realize it.” - Eric Evans
17. shifting the burden to the intervenor
24. 24 A group of people is not a team, focus on collaboration as a team. Do more Pairing/Mobbing, create collective ownership.
25. 25 Focus on Diversity, everyone is individual and different. Focus on Equality, equal access to opportunities Focus on Inclusion, create a sense of belonging.
26. 26 “In the old waterfall method, the business experts talk to the analysts, and analysts digest and abstract and pass the result along to the programmers, who code the software. This approach fails because it completely lacks feedback.” - Eric Evans
27. Still a waterfall…..
31. 31 “Apophany” that moment when a sufferer says, “Oh! I get it!” when they really don’t. - Liz Keogh https://lizkeogh.com/2015/09/09/on-epiphany-and-apophany/
33. 33 https://lizkeogh.com/2015/09/09/on-epiphany-and-apophany/ Build beliefs Draw conclusions Generate assumptions Filter data Observe data
35. 35 The greatest obstacle to discovery is not ignorance - it is the illusion of knowledge. - Daniel J. Boorstin
36. 36 Don’t telephone game requirements, get ‘first-hand knowledge’, battle your bias.
37. 37 “Knowledge crunching is an exploration, and you can’t know where you will end up.” - Eric Evans
48. 48 Don’t only talk about requirements, visualise, actively participate while exploring requirements. Even better, experience it yourself!
49. 49 “A document shouldn’t try to do what the code already does well.” - Eric Evans
54. We all know or should know that language is fluid, liquid, subject to the whims of the people. Language evolves, as it should. Because language changes to accommodate new users, the older users resist and complain. http://tednellen.blogspot.com/2013/04/language-is-fluid.html
55. #MoreCatTax @kenny_baas Baasie.com xebia.com/blog/author/kbaas/ https://speakerdeck.com/baasie