I wouldn't bother with Narrator too much but by all means add it to your testing suite.
You will see from the webAim screenreader study that NVDA, JAWS and VoiceOver make up over 90% of screen readers. So those are the ones we use in testing. You will see narrator makes 1%.
The thing is if you can make a site that is accessible and fully usable in NVDA, JAWS and VoiceOver then it should work in other screen readers also.
In terms of experience using a screen reader it is actually beneficial that you are not experienced (explained later).
We tend to do all primary testing in NVDA, then just use VoiceOver and JAWS at the final stage to tidy up any idiosyncrasies with those screen readers.
Testing is done in two stages, component stage and page stage.
In component stage we design a component (i.e. an auto complete search box) and then test specific features, key combinations that fall under 'expected behaviour' and general usability.
Please note we do a battery of tests not just screen reader tests (focus indicator visible, colour contrast, screen magnifier at 800% zoom (to check labels, tooltips etc. are close enough to things and don't interfere) etc.)
Then we do full page tests which are 'functional' tests - i.e. we set specific goals (navigate to page x, fill in form y but make mistakes and check it is clear what mistakes were made etc.).
Between these two types of testing by the time you come to launch a website / web app there is nothing to do (and it adds maybe 2% extra time to development doing it this way, possibly as high as 10% if you have only just started on accessibility as a company as a lot of things will need redesigning that you use on a regular basis. However over time you will build up a base library and coding guidelines that are accessible by default).
I always make sure I stick to core commands when testing. This is because that is the minimum level of knowledge you need to use a screen reader with just the keyboard, so should be the minimum level of knowledge one of your site visitors will have.
As such your 'lack of experience' is actually a good thing.
So should we outsource?
Everything I have said makes it sound like you should do things in-house, and in an ideal world you should.
However there is a problem with this, the same as any other UX scenario. You end up developing bad habits and think 'I know how to use this component so everyone should be able to use it'.
What I would recommend is that you do preliminary testing in-house, get the site to a stage you think it is accessible and then employ a company to do user testing. They will approach the software 'blind' (no pun intended) and so they will not know the layout of pages etc. This is really beneficial as it shows holes in your logic and lets you see where a particular design aspect is not as clear as you think.
Testing Tips
Build a checklist
For the technical aspects of the design, complying with WCAG etc. a checklist is a great way to make accessibility testing easy.
We split our into component types, page theme, navigation and technical so that we can pull an applicable checklist without having to try and remember every single rule (which I still can't do!)
Build personas
gov.uk have a great writeup on accessibility personas along with a github repository with this in. Basically test against different people's needs. This is a great testing method and thought process for the team as well.
Different browser and screen reader combinations
Title says it all, JAWS works better with Internet Explorer, NVDA works best with FireFox etc. Try 'switching it up' to make sure it works on as wide a range of combinations of browser and screen reader as possible.
Give yourself minus marks for using WAI-ARIA
Yup you heard me right, points off for using WAI-ARIA.
This is a bit tongue-in-cheek but the actual point of this rule is to encourage you to think about native HTML5 components. I see lots of people adding a div with role="region" - just use a region, use buttons for buttons etc.
WAI-ARIA is not as widely supported as you think so use it for extra information, if your component is impossible to use without WAI-ARIA it is often 'code stink' that you are doing it a more difficult way.
Use WAI-ARIA but don't rely on it to make a site accessible, very few scenarios cannot be created with native components.
Conclusion
Accessibility testing is hard. Building accessibility into development practices is harder....at first.
When testing if you find a particular accessibility issue more than once then write some coding guidelines around it.
If you do that, coupled with checklists, personas etc. you will take about 6-12 months to transition to an 'accessibility first' way of thinking. As an added bonus you will probably design much better User Interfaces and a much better User Experience!
