About my time in Split, Croatia; about Schengen rules for travellers, and Uber outside of the US
Customer is always right! You might disagree with this statement, but when support cases come up, it is essential to put yourself in the customer's shoes. When you are just testing for a list of steps in your requirements rather than focusing on the actual behaviour of your app, you are sure to make mistakes.
In this talk, we discuss how to use Domain knowledge around your product to help improve your Software Quality. We use Domain Driven Testing tools to ensure we validate what your customers work with, rather than what you think they might use.
“I tested it how you told me to,” “Requirements say it's expected,” “I assumed it's fine” – these are the common phrases you hear when customer cases come up. Unfortunately, it is nothing unusual in our industry to be detached from customers' actual needs. As a result, teams regularly fail when they prioritize requirements over actual behaviour that the customers expect.
This problem of misaligned teams' focus is where Domain Driven Testing (DDT) comes into play. DDT helps developers to put themselves into the customers' shoes and see the product for what it is. This prioritization of the actual behaviour over the mere following of the requirements is what defines Domain Driven Testing.
In this talk, we discuss how knowledge of your company's domain (aka, the focus of your business) can improve your testing practices. We talk about Domain Driven Design techniques, Exploratory Testing, and other methods which emphasize software quality through customers' success. We touch bases on tools you can integrate into your system using Domain Driven Test Pyramid, and what common mistakes you should avoid when implementing Domain Driven Testing.
- Principles behind Domain Driven Design
- How-to's of Domain Driven Test Pyramid
- Tips and Trick on Behaviour Validation using DDT techniques