The company opens the job
When a company ships a new release, the job enters the queue by itself. No proposal to write, nothing to negotiate; the job is in the queue with its fee on it.
// NIJITECH PRODUCT · TESTING MARKETPLACE
BountyShift
BountyShift is a marketplace where software testing jobs are distributed. The company drops its new release into the queue; the tester takes the job from home, on their own computer or phone. What was done is recorded automatically and the value of the job is added to the balance.
Product site:bountyshift.com
BountyShift is a marketplace where software testing jobs are distributed by quota. There are five job types: website, mobile app, desktop software, embedded device and game testing. Each job’s fee is known and fixed before it is taken; it does not change with the number of bugs found, and a job with no bugs found is still paid. Payouts are weekly and no commission is taken from testers. The product grew out of the “was this really tried?” argument the SendTheCanary team kept having while delivering independent testing; that is why the run record sits at its centre.
Information as published by BountyShift; the queue and earnings tables on its site are examples.
// HOW IT WORKS
There are six things and they all address the same problem: the work should be visible and paid on time.
When a company ships a new release, the job enters the queue by itself. No proposal to write, nothing to negotiate; the job is in the queue with its fee on it.
A job that is not open to the tester’s level, does not fit a free slot or does not match the available setup never appears to them.
How many testers a job takes is written on the job; how many jobs a tester can hold at once is set by their level. Both are known up front, so nobody commits time without knowing how many they are competing with.
The environment fingerprint, scenario timestamps and file digests are written by the agent. Neither the tester nor the platform can edit them afterwards; the record is kept for 24 months.
The amount is written on the job and does not change after delivery. The value of an accepted job is added to the balance and paid out weekly; no commission is taken from the tester.
If a report is rejected, the customer must give a written reason. The argument runs on the record, not on who remembers what; a tester found right gets paid and their acceptance rate is unaffected.
Every one of these steps runs on the same backbone: the niji core pipeline →
// JOB TYPES
Which ones can be taken is set by level and by the devices at hand. Each type has different proof requirements.
Websites and panel applications. Browser matrix, form validation, payment flow and accessibility scenarios. The tester’s own computer is enough.
iOS and Android apps. A real device is required; the job states which model and version is wanted.
Windows, macOS and Linux software. Installation, update and permission scenarios. A virtual machine is accepted.
POS devices, meters, control boards. The physical device and serial console access are required; the desktop agent is mandatory. The highest-paid jobs in the queue are here.
PC, console and mobile games. Gameplay flow, save system, crashes and frame rate. Because sessions are long, quotas are kept wide.
// FREQUENTLY ASKED QUESTIONS
It has two sides. Companies drop a job into the queue to have a new release tested; testers pick up web, mobile, desktop, embedded-device and game jobs from home, on their own devices. The work is fully remote; there is no proposal to write and nothing to negotiate; the job is in the queue with its fee written on it.
There are two separate quotas. The first belongs to the job: the company commissioning the test writes how many testers it will take on the job, and when that fills the job leaves the list. The second is the tester’s slot limit, which sets how many jobs they can hold at once according to their level. Both are known up front.
No. Payment is a fixed amount per accepted job and is written on the job before it is taken. Finding zero bugs does not stop the report from being accepted; what is paid for is that the scenarios were run. No commission is taken from the tester.
The desktop agent records the environment fingerprint and the start and end stamp of every scenario by itself. The tester adds screenshots, a screen recording, logs and reproduction steps on top. Both go out in one package and cannot be edited afterwards; the record is kept for 24 months.
The customer must give a written reason. The tester can dispute it, and the dispute is judged on the run record rather than on who remembers what. If the tester is found right, payment goes out and their acceptance rate is unaffected.
For web jobs the tester’s own computer is enough. Mobile jobs need a real device; the job states which model and version is wanted. Desktop jobs accept a virtual machine. Embedded jobs require the physical device and serial console access; these are the highest-paid jobs in the queue.
Everyone starts at Level 1 and rises with their acceptance rate, the percentage of submitted reports that get approved. The level sets both how many jobs can be held at once and which job types are open. A job not open to your level never appears in your queue.
The value of an accepted job is added to the balance and payouts are made weekly. The amount does not change after delivery. Details are on BountyShift’s payment page.
The iOS and Android apps are announced on the site as “coming soon”. For now, new jobs are announced through Telegram and WhatsApp channels. The desktop agent that keeps the run record is mandatory for embedded jobs.
GET STARTED
Let us work out together how it fits your current infrastructure, how a migration would run and which plan suits your business.
Talk to the team →We would like to use Google Analytics to understand how the site is used. It sets cookies and transfers data to the United States. The site works exactly the same if you decline.