There's two types of testing in the context of your question: black box testing and white box testing.
A black box tester doesn't know anything about the system. This allows the tester to uncover bugs that someone more familiar with the system might overlook. A white box tester has more familiarity with the system. Based on knowledge of the application's internals, that a white box tester may always perform task X before performing task Y, whereas someone without familiarity might go straight to performing task Y in a system where task X must be completed before task Y, or both must be completed before the next task.
Having both types of testers helps to uncover bugs where there are user interface issues, documentations issues, or missing validations.
Black box tester
Let's use an e-commerce website for an example. The order form indicates which fields are required but also allows the user to skip around and leave some of them empty to come back to later. A white box tester might just omit the required shipping information, and just enter billing information followed by submit. If they're then directed back to the missing fields for completion, then the design is likely fine. If not, and they land on a success page, they might not know that there's an issue.
White box tester
With a white box tester performing the same test, they'll notice something is wrong after landing on a confirmation page.
The black box tester used the system and everything they saw indicated a success. The white box tester, on the other hand, knows the internals of the backend and knows that, without the required shipping fields, the application should not be accepting the submission. They'll know something is wrong despite no explicit error.
This is why it makes sense to have a balance of both types. A black box tester may be less likely to test this scenario. Maybe they just assume people know they need to put their shipping information into the form before hitting submit, so the test case never occurs to them. A white box tester is more likely to test this case, but less likely to realize that there's an issue. When you have both doing quality assurance on your software, you're more likely to uncover the issue, either through coordination/communication with the two types of testers, or by an engineer seeing a backend failure triggered by the test that the white box tester may have never tested.
This happened frequently in the automated customer service speech recognition industry. People familiar with a system (a white box tester) may be mis-recognized, try again, succeed, and chalk it up to a misrecognition. Someone less familiar with the system (a black box tester) would be more likely to report an issue. Usually it was just a misrecognition, but other times, it helped to uncover issues. It sometimes turned out that the white box tester's misrecognition was actually caused by some bug in the system. If it weren't for the black box tester reporting the issue to be looked into, the bug might not be found.
Alternatively, a black box tester might complete the speech recognition transaction with no issues, whereas a white box tester might realize that the transaction should have failed because a particular piece of information critical to the transaction was never collected.
Again, this is why it can be beneficial to have both types of quality assurance on a team.
Edit: Apologies if this is confusing. I wrote this at around 3AM local time when I should have been working to meet a deadline.