Developers domain knowledge

Where you work what is the general level of understanding of the industry you are working in and how the tools/sites are used by the business by the development teams? Then with that how do you think this impacts the kind of issues that you find and how you report them to the devs?

For a bit of context I work in gambling and the levels of sports and gambling knowledge within the dev teams vary massively but are generally quite low. This means you can run into lots of simple, obvious issues because you know how the sport works and the dev didn’t. It also leads to us having to write very detailed bug reports with multiple examples and steps to replicate as without that whoever picks up the issue more than likely won’t be able to get to the point of replicating the problem.

1 Like

It varies a lot. Developers who have been with an organization/in a business domain for a long time will have built up a lot of domain knowledge. Those who haven’t won’t have built up domain knowledge.

I work in payroll software, with a lot of complex business rules that need to be handled. I know that when I’m testing work from less experienced developers I need to be more thorough in checks for regression issues than I do with developers who have strong business knowledge. Similarly, I often need to give explicit reproduction steps and explain why there is a problem for the developers with less domain knowledge compared to those with extensive domain knowledge.

The same factors apply to developers who are deeply familiar with their company’s software compared to those who are not. Intimate domain and application knowledge means many of the complex interrelationships in legacy software and/or complex business rules have been internalized.

(Incidentally, this also means that testers who aren’t familiar with the domain will likely miss things or mistakenly report non-issues until they’ve built up enough familiarity with the domain and application).

1 Like