I suppose it matters where you're looking, and what your requirements are. Some temporary agencies like Volt (in the US) place a lot of testers, and even if you run a small shop you can work with them as long as you are able to pay on an hourly basis.
Different companies use different job titles, including "QA Analyst", "Software Tester", "Software Test Engineer", and so on. I prefer "Software Test Engineer" if you can get away with it where you are, only because people who have done it professionally will be more likely to understand what you are looking for.
However, in many countries, the use of "engineer" may imply specific educational requirements, so you may need another title. The ironic thing is that "Quality Assurance Analyst" or similar titles are also misleading for people with an industrial quality assurance background, as Software QA corresponds most directly to what industrial QA refers to as quality control. Quality Assurance, as a job description is, in manufacturing, usually more about creating and managing processes that lead to quality, and Quality Control is traditionally about defect identification. Software QA is somewhere between those two worlds.
I've personally had good experiences (and some unpleasant ones) with outsourced QA work.
In practice, if what you are looking for is someone to do manual, ad hoc UI testing or integration testing, you are probably looking for a "black box tester".
As for the interview process, don't get too hung up on paper qualifications unless you really need an experienced tester (and unless you're testing something fairly esoteric, chances are you don't). I started doing internationalization QA work right out of college with a degree in East Asian Studies. They wanted someone who knew something about the internet, and preferred people who knew German or Japanese (I knew both, at least a little), and were interested in people who had taken the time to learn a programming language or two but didn't really need evidence that you had done anything particularly impressive with it. For example, I was only asked to write the header file for a linked list class, not an actual implementation. What they were more interested in was answers to questions like: "Here's a dialog box (on the whiteboard). How would you test it?" Then they'd press for answers on things like "how do you know X is the correct behavior?" and the ideal answer was that you would consult a specification, a project plan, a project manager, your lead, and finally, base it on an understanding of the motivations of the users, roughly in that order.
Problem solving and an intuitive ability to break down problems are more valuable in testers than coding experience, and a creative ability to identify vulnerabilities and exercise the program to exploit them is the single most valuable skill. As I got more experienced in my early career, I actually found fewer bugs, because my approach became more rigid and defined by the project specifications. People with a less technical approach would find more errors in the overall interaction; I tended to find interesting but sophisticated bugs after a while, because I would start from a deeper technical understanding of the system; however, if you want the most bang for the buck, I promise a creative ad hoc tester will get you further, faster, than a sophisticated tester, until your project reaches the point where it can afford multiple QA team members.
