I'd recommend looking into these options:

https://www.fiverr.com/
(do a search for QA)

https://www.reddit.com/r/slavelabour/
(e.g. pay $1 per bug committed to Trello)

https://www.scaleapi.com/

https://www.mturk.com/

If you'd like to discuss managing the software testing in more detail in relation to your specific product let me know,

best,

Lee

Yes, there's a lot we can discuss.

We internally use BDD tests (Gherkin for user stories), coupled with Selenium via CoyPu wrapped around any mock-up output (in our case, Indigo Studio).

You can take a look at an example from a while ago on our YouTube Channel (Axelisys Wonder), specifically at:

https://www.youtube.com/watch?v=ZWeC56bL3Oc&list=UUdTOmUegcjXIPtZt2sVutRQ&index=11

What we typically do is:

1. Sit together with the business, BA and a Dev to develop user stories representing customer journeys using "As a... I want... So that..." often in conjunction with mock-up web pages which are then changed into static HTML pages.

2. Run through the primary scenario and develop the "Given... When... Then" statements.

3. Commit that to your Version Control system ("What?")

4. At this point, the devs or a DiT (Developer in Test - if your organisation uses that) can pull it out and wrap the mock-up in CoyPu/Selenium with references to the appropriate elements. The behaviour of the mock-up should represent the user journey. Hence the BDD test should use the same data as the mock-up did. However...

The maximum number of tests should be 2 to the power of the number of "Given" "Ands". So if you have

"GIVEN I am 17 AND I have a driving license"

This counts as 2 test variates and as such, creates upto 4 test cases.

5. As the devs work through the process, they fill out the mock-ups and push data back through the layers (perhaps walking the skeleton for the primary scenario) and filling in any data persistence layers etc. as they go. The very same tests are used to regress existing functionality too.

So the test strategy is basically to make sure you have covered as much of the valuable journey as possible (all primary scenarios/happy paths and the most valuable secondary scenarios, as long as TDD level tests can adequately cover the rest).

How do you know what is adequate? I'll direct you to a couple of articles.
Feel free to arrange a call if you need more information.

http://goadingtheitgeek.blogspot.co.uk/2015/02/code-coverage-metrics-cyclocmatic.html

http://goadingtheitgeek.blogspot.co.uk/2014/09/going-from-acceptance-tests-to-code.html

Best of luck!

There are several options you can consider, some of them have been mentioned by other experts here. I have been helping startups for the past 10 years developing executable business and marketing plans as well software customization and applications development.

If you are paying for the premium access for example you are simply still only getting a tool that extends as far as your time and skill set allow. What you could do instead is also consider another development team whom you can partner with and allocate your budgets to them to do the testing while also providing you with their expertise in software development and customization for various interfaces they can run your tests as fix or provide direct solutions. Companies like www.BetaBulls.com for example can help you with services like that and maybe even fix any errors.

You're absolutely correct in the sense that there are certainly development costs (in terms of both development time and dollars) associated with the available testing strategies. In general, BDD with Selenium should produce outcomes of sufficient quality for you.

Depending on the purpose of the underlying system and how critical it is relative to operations, other additional techniques may be advisable (such as Test Driven Development/TDD or Unit testing) in order to assure adequate coverage of critical core components.

At FarShore, nearly 20% of our staff is tasked with QA testing exclusively, so we are tackling these exact type of questions every day. We usually advise a review the system's purpose, scale, anticipated rate of change for that system's code base, budget and based on that review, recommend a testing strategy that fits best for the parameters provided.

Happy to connect and offer additional insights or help with any guidance I can.