How to be a technical tester and preserve end-user perspective at the same time?
I believe that there is no 'fix' to this other than to become proficient in both areas and to combine those skills through actual work. The two different aspects are not a binary choice of one or the other. I would focus on the specific things to get good at in each area and allow the combination of the skills to come together through your work.
So the skills I would try to advance in each of the aspects is
Technical Tester - unit tests, mock and stub, integrated tests, programming skills, writing DRY code, separation of concerns, isolating application unit under test, DRY code, etc.
End User Perspective Tester - learn the business domain, learn current business objectives, learn how/where revenue is earned, understand reasons for new and changed features from business perspective, understand business goals for upcoming quarters, learn about customer needs, understand customer viewpoints, pain points, study feedback surveys, obtain customer service feedback, etc.
In terms of your main title Can knowing too much about the tested code be a disadvantage? I would say yes if you focus too much only on the technical aspects above and not enough attention to end-user perspectives
To do this well means learning how to use different personas and perspectives and how 'wearing a different hat' works. This skill takes some practice and takes time to learn.
At the end of the day you cannot 'avoid' technical knowledge affecting the end user perspective to some extent. The goal should be to be aware of that fact and to make sure that you take extra effort to make sure the end user perspective is still listened to. This can be done through a number of activities including involving others and paying more attention to customer feedback.
In addition to the above, one approach that I use that it somewhat in between the 'black box' (often user perspective is black box) and 'white box' (often meaning having knowledge about the code itself) approaches is 'grey box'. In this case one doesn't know or have access to the code internals but you do have access to control state. A couple of examples of this:
- The ability to set or seed a database appropriately for a test to run
- The ability to control a web session and visit a specific page of a multi-form flow
Many experienced automation developers have found the above capabilities can be critical to actually having reliable test suites that run quickly and add huge value.
You also need to both acknowledge and take advantage of what the automation does not do in terms of addressing usability and still do real user manual testing for that perspective, but make sure the testers have a good understanding of what the automation does and the value it already provides and how their input should address different aspects and which aspects they should be.