When I was reading through “Domain Driven Design Quickly” (published on InfoQ) I had several aha moments as I linked the material I was reading to the “Heuristic Test Strategy Model” (HTSM) from James Bach which I work with daily.
The “Domain Driven Design Quickly” book is a digest of “Domain-Driven Design” by Eric Evans. I confess, I haven’t read “Domain Driven Design”, but the digest has given me enough taste for it to not only read the actual book but also write this post.
I struggled a bit with the structure of this post – should I list the key elements of the HTSM and then map the salient points of the book to those, or should I talk about relevant parts of the book & map those to the HSTM?
I decided to take quotes from the book & relate those to the HSTM. Unfortunately there were so many good quotes I almost reprinted the book in this post!
Consequently, I’ve taken some quotes as key examples – those concepts & ideas which really slapped me in the face.
There are loads more examples I could have chosen but I’ll leave those for you to go & find yourself J
Project Environment
Lets start with some quotes from the book which I felt related to the Project Environment.
“In order to create good software, you have to know what that software is all about. You cannot create a banking software system unless you have a good understanding of what banking is all about, one must understand the domain of banking.”
“Is it possible to create complex banking software without good domain knowledge? … Who then? The bankers, of course. The banking system is very well understood by the people inside, by their specialists. They know all the details, all the catches, all the possible issues, all the rules. This is where we should always start: the domain.”
“The air traffic controllers have vast knowledge about their domain, but in order to be able to build up a model you need to extract essential information and generalize it.”
These quotes got me thinking about my Mission on the project, identifying the customers & their domain in order to help solve the problem.
They also highlight an important source of Information to not only find out about the current need, but also historical situations/gotchas which have previously cropped up.
From conversations with the Customers you will soon realise if the Test Team &/or Development Team will require any special training.
“Here code design patterns come handy, and they should be applied when necessary. Good coding techniques help to create clean, maintainable code.”
“Getting the developers involved provides feedback. It makes sure that the model can be implemented in software. If something is wrong, it is identified at an early stage, and the problem can be easily corrected.”
I’ve found the underlying ideas behind both these quotes has really helped to build Developer Relations.
The book covers ideas & concepts in OOP, such as entities, value objects & services. Understanding these concepts has helped me have deep conversations with Programmers which has not only built rapport, but ultimately have helped me with testing the application. For example, we have discussions about the most efficient & effective way of testing different parts of the system which builds a more complete testing strategy (not forgetting helping to build trust between Testers & Programmers).
“We can and we should create a language to communicate specific issues about the domain… we need to communicate the model.”
“Use the model as the backbone of a language. Request that the team use the language consistently in all communications, and also in the code. While sharing knowledge and hammering out the model, the team uses speech, writing and diagrams. Make sure this language appears consistently in all the communication forms used by the team; for this reason, the language is called the Ubiquitous Language.”
“The Ubiquitous Language should be fully exercised throughout the modeling process in order to facilitate communication between the software specialists and the domain experts, and to discover key domain concepts which should be used in the model”
“Be wary of long documents. It takes a lot of time to write them, and they may become obsolete before they are finished. The documents must be in sync with the model. Old documents, using the wrong language, and not reflecting the model are not very helpful. Try to avoid them when possible.”
The customer will also be able to help you with any Equipment & Tools they use in their daily routine which might also help with testing.
One of these tools is the language that they, the customer, use. This will prove invaluable when reporting your testing – the customer will be able to understand the content of information you are trying to communicate, as opposed to either you or the customer attempting to translate from dev-speak to business-speak.
With regards to test reporting, understanding the domain will help you gauge what standard of test reporting is required. For example, the medical industry has stringent auditing process so you would expect reams & reams of spreadsheets right? I know of one Tester who spoke to the auditors to ascertain what test reporting they required & it turns out they were happy with video recordings of exploratory test sessions as evidence.
Product Elements
“The model is our internal representation of the target domain, and it is very necessary throughout the design and the development process.”
“The main idea is to choose a model which can be appropriately expressed in software, so that the design process is straightforward and based on the model. Tightly relating the code to an underlying model gives the code meaning and makes the model relevant.”
“Those who write the code should know the model very well, and should feel responsible for its integrity. They should realize that a change to the code implies a change to the model; otherwise they will refactor the code to the point where it no longer expresses the original model”
“…a change to the code may be a change to the model. Its effect must ripple through the rest of the project’s activities accordingly.”
If you understand the model then you are better placed to understand the potential implications of a code change & this can really help focus your regression testing.
Interactions & flows through the model should be reflected in the product. Knowing the interactions & flows will help you understand the Functions of the product & generate test Data, both valid & invalid, in order to exercise & challenge the system. As a result of understanding the inputs, you should have a better idea of the different types of output.
he following quote made me think about testability:
“However, when domain-related code is mixed with the other layers, it becomes extremely difficult to see and think about. Superficial changes to the UI can actually change business logic. To change a business rule may require meticulous tracing of UI code, database code, or other program elements. Implementing coherent, model-driven objects becomes impractical. Automated testing is awkward. With all the technologies and logic involved in each activity, a program must be kept very simple or it becomes impossible to understand.”
Opening the bonnet & identifying different parts of an engine doesn’t mean you can fix it, but it sure helps to understand that if a hose is unplugged somewhere then the engine isn’t going to working as it should.
Understanding the Structure of code will really help you prevent defects & complications further down the line. For example, the business logic should have no knowledge of the database being used – if knowledge leak does occur, what happens if the organisations wants to change the database?
Knowing the domain will also help identify different users of the product & the environment in which the product will be Operated. For example, field engineers may have a stripped down version of the product to use on their waterproof PDAs. Why does the PDA need to be waterproof? Is it in a case, thus making the touch screen more tricky to operate?
Quality Criteria Categories
No specific quotes of this section, but the ideas in the book really got me thinking how can we understand quality criteria without understanding the domain?
For example,
- How would we know what Reliability means? What are the different situations?
- How easy it for the customer to Use the product?
- Parts of the product that might really bug the customer that we didn’t pick up during testing? (because it didn’t bug us)
- Does the product meet the accessibility needs of all the intended users? Should it?
- What other applications does our product need to be Compatible with on the customers system? When running, does our product allow for those other applications to run as well?
What I took away from the book was that building domain knowledge is a great way of actually understanding the problem(s) which needs solving. You may discover that the problem doesn’t need solving with code…
One final quote which really sums up a fundamental part of what I do whilst testing :
“What is actually happening here? You and the domain experts are talking, you are exchanging knowledge. You start asking questions, and they respond. While they do that, they dig essential concepts out of the air traffic domain. Those concepts may come out unpolished and disorganized, but nonetheless they are essential for understanding the domain. You need to learn as much as possible about the domain from the experts. And by putting the right questions, and processing the information in the right way, you and the experts will start to sketch a view of the domain, a domain model. This view is neither complete nor correct, but it is the start you need. Try to figure out the essential concepts of the domain.”
How can domain driven design help you?