The domain knowledge
To write a piece of code, domain knowledge is not that important as it is to test the same piece of code. Let’s take an example.
Imagine writing code for two software: one to store and display engineering information where as the other for accounting. Now from a programmers’ perspective, all she needs to care about is a dialog (say a grid) behavior, knowing how to connect to the data (say a SQL database), and how to display that data on the screen. Whether or not that data stored in the database and the information displayed on the screen makes sense to the user, requires some knowledge of the domain for which software is being developed. Now imagine if we ask a guy from accounting background to test the software being developed to be used by engineers and vice versa. Definitely we need the testing eyes to possess the knowledge that the users of the software usually would have.
Take this example to solutions for other domains like the Medical community, or Network analysis software, or Talent Management or any thing. Testers being proxies of the actual users of the software, ought to be having in-depth knowledge of that domain.
This does not mean that you can have a domain expert doing testing without having any knowledge of how software are written, tested and deployed. That knowledge is equally important and the best case is:
Such that the domain knowledge is used to derive business use cases and software knowledge is used to derive test cases to test the limits of the technology.
On some of the projects that I worked, were engineering heavy applications and each time we made a hiring decision, we put more emphasis on the domain knowledge. And even all engineers are not the same e.g. to test an Industrial Instrumentation software, you can have a Structural Design engineer do that job. And believe it or not, that formula always worked.