“I tested it how you told me to”, “Acceptance Criteria said this is expected”, “I assumed it is fine” – these are frequent thoughts of teams which more likely to end up with customer cases in Production. Having an opinion about the product and ability to put themselves in its customers’ shoes is what makes a good tester, great. These great testers become the last line of defense before releasing functional but unusable product.

It is easy to tell what kind of company you are working for if when you started there, you were sat in front a laptop and were given some code to study. Teams like that simply want another coder.

If your team got you to explore the product first, then it is a team that wants you to know exactly what you are working on; they want you to know your domain.

In this talk, we will discuss on how to apply Domain Driven Development practices and principles in a testing field, creating Domain Driven Testing. We will learn why it is important to understand exactly what you are working on, and why “Programming by Coincidence” is the main danger to User Experience.

The speaker will share his experience in starting in a new domain of Website Building Software, and how learning about other products in the industry allowed him and his team to avoid reinventing the wheel, and as a result to prevent problems which were previously solved by other organizations.

At the end of talk, the audience should be empowered to make product decisions and direct all its efforts towards satisfying the most important stakeholder, Customer.

 
 

Outline/Structure of the Talk

In this talk, we will first explore Domain-Driven Design with its primary focus on enhancing communication in the team. Then, we will apply these techniques to Software Testing.

This presentation includes demos.

Learning Outcome

  • Undestand Domain-Driven Design
  • Know how and how not to apply DDD's techniques in testing field

Target Audience

Engineers, Testers

schedule Submitted 3 years ago
help