Between a solution developer and a solution tester who must understand the IT architecture of a project in order to work.
Both of them, but on a different level. The developer should understand the basic characteristics of the architecture in order to deliver software which works, performs and scale. The tester needs to know more about how the system is configured in order to be able to solve possible deployment and configuration issues.
It is very important that both entities understand the programming architecture as it will be useful when reporting the errors or when looking for the the errors or bugs int he software. If the tester does not understand the programming architecture he/she will not know all the dimensions to test.
Let's start from the beginning.
The ultimate goals of the developer and tester are opposite:
- The developer works to prove that the application works as expected;
- The tester works to prove that the application does not work as expected;
"As expected" literally means that the application performs exactly as specified in requirements.
However, the requirements can't be coded or tested directly. For this purpose, two artifacts are created:
- Design Specifications (DS), containing the Architecture of the solution;
- Test Cases (TC), containing details of individual usage sequences;
The developer implements the DS by writing the code.
The tester tests the code according to TC.
As you see, only the developer has direct need to be deeply familiar with the Architecture.
However, if the tester is also familiar with it, they get a good opportunity to find design-specific problems that are otherwise hard to detect.
Further reading: V-Model