NOV. 3 – 8, 2019
POTSDAM, GERMANY

EUROPE'S GREATEST AGILE SOFTWARE TESTING FESTIVAL!

Testing on the beat

the importance of domain knowledge in software testing

As testing experts, when working in complex domains we need to learn to make use of techniques to gain domain knowledge, and understand what kind of domain knowledge is necessary to critical thinking

Last year I decided to take on a job as a Quality Engineer for music production software. For me, music was a complex new domain, in which I didn’t have prior expertise.

I was excited to learn more about making music, but at the same time I was not an aspiring musician. I didn’t mind my music to sound off the beat, but I definitely did not want my testing to be the equivalent of that. So it was important to not miss important workflows while focusing on irrelevant flows.

The big questions were how much depth of domain knowledge would I need to test effectively, and how could I transfer to this new context what I already know about gathering information and organizing my exploration?

This talk will cover what I learned from my experience after more than a year, as well as how ideas from Domain-Driven Design and other resources have inspired me to do new experiments. I will also describe how I re-evaluated my understanding about the importance of local and situated knowledge, and what that kind of knowledge encompasses.

I will tackle questions like:

- How desirable is it to become a domain expert for the project you are testing on?

- How much effort should you invest into that kind of knowledge, given that as testers we constantly need to make trade-offs in terms of the range of specialization areas in such a complex, fast-growing domain as software?

- How do we, as tester experts, effectively gain enough domain knowledge to be able to provide valuable information in a team?

We will also look into some of the strategies that were useful in my case:

- Use analogies to domains where I had more knowledge(like video editing software)

- Get close to the implementation level – it is software in the end, so the code and the product’s architecture reflects the functionalities it has.

- Discuss with UX designers with curiosity, and prepared to change my mind

- Include every team member’s ideas in the test planning process by providing a structure to come up with useful question. For example, I used Elisabeth Hendrickson’s testing heuristics cheatsheet, as well as an Outside-In risk analysis structure from James Bach

- Model a feature in multiple ways to understand it better

Join me in making some beats and learning about how to test that process!


More Related Sessions


Full-Day Tutorial (6-hour Workshop)

9:00-17:00

Leveraging Lean UX to Lead Successful Agile Teams

Bonus Session

10:25-12:25 Creative Space Room - Bonus Track

Get a Lot Out of This Conference

150-min Workshop

14:25-17:25 Room D5+D6 - Track 8: Workshops

Advanced Coding for Testing in Agile Teams

Equipment required

45-minute Keynote

13:25-14:10 Room F1+F2+F3 - Plenary

Testers, are you really engaged?

Other Events:

Your privacy matters

We use cookies to understand how you use our site and to give you the best experience on our website. If you continue to use this site we will assume that you are happy with it and accept our use of cookies, Privacy Policy and Terms of Use.