Yes, there are resources you can provide to help testers get up to speed. Start with a book like Cem Kaner's Testing Computer Software, which covers test techniques as well as how to deliver good bug reports. Testers may also find the lectures and reference materials on the BBST site valuable.
The value a motivated, effective test team can provide is simple: They'll think differently than developers, and they'll have more opportunity to explore different combinations of actions than developers will budget time for. They'll also spot things that developers will miss because we tend to focus on "happy path" outcomes and only the obvious-to-us side effects and interactions. They'll be able to advocate product quality with a more customer-focused perspective than most developers have focus or bandwidth for.
You should be providing testers with information and guidance about your concerns in the system based on what you know about the implementation and design. You will likely have some areas of concern because of technical debt, areas with poor unit or integration test coverage, or service boundaries and external dependencies.
Programming skills are far from essential for a good tester. In fact, when I was a tester, the more aware of implementation and design details I was, and the more focused on automation I was, the fewer bugs I discovered, as I was increasingly thinking more about the technical boundaries and less about the user's interaction with the software. Automation gave us confidence that we were not regressing functionality that was previously built, but it didn't necessarily catch new problems as effectively as an exploratory black box test team, and developers were often better equipped to provide the necessary hooks for test automation than even people with an SDET type background who were less involved in the implementation of the current project.