فریلنسری QA با «پیدا کردن چند باگ و گرفتن درآمد دلاری» شروع نمیشود. پیش از نخستین دقیقهٔ تست باید معلوم باشد آیا اصلاً اجازهٔ استفاده از کانال و دریافت وجه را دارید، چه سامانهای را با کدام اختیار میآزمایید، خروجی دقیقاً چیست، چه کسی آن را میپذیرد و اگر Scope تغییر کرد چه اتفاقی میافتد. اگر یکی از این پاسخها مبهم باشد، مهارت فنی عالی هم میتواند به کار رایگان، اختلاف یا افشای داده ختم شود.
این راهنما برای تستر ساکن ایران، یک مسیر فروشندهمحور میسازد: Opportunity Gate → Engagement Record → Permission → Scope → Estimate → Acceptance → Evidence → Invoice → Exit. هیچ رقم درآمد، پلتفرم یا روش پرداختی در آن تضمین نشده است و هیچ راهی برای هویت، نشانی، حساب یا موقعیت مکانی غیرواقعی پیشنهاد نمیشود.
پاسخ کوتاه: فریلنسری تست نرمافزار چیست؟
فریلنسری تست نرمافزار یعنی ارائهٔ یک خدمت QA با مرز، خروجی، مسئولیت و رابطهٔ قراردادی مشخص؛ نه صرفاً حضور موقت یک تستر بیرون از سازمان. خدمت میتواند اجرای یک Charter اکتشافی، بازبینی API، طراحی تست، اجرای Regression، ساخت Check اتوماتیک یا ممیزی Evidence باشد. ارزش قابلتحویل «تعداد باگ» نیست؛ پاسخ معتبر به یک سؤال کیفیتی در محدودهٔ مجاز است.
این نوشته مالک مسیر تستر/فروشنده از ارزیابی فرصت تا تسویه و خروج است. اگر از سمت خریدار میخواهید مدل تأمین، Work Package، کنترل دسترسی و پذیرش پیمانکار را طراحی کنید، راهنمای استخدام فریلنسر QA و Crowdtesting مرجع مکمل است. این تفکیک جلوی دو نسخهٔ تکراری از یک موضوع را میگیرد.
چهار واژهای که نباید یکی فرض شوند
| مدل | رابطه و خروجی | ریسک غالب برای تستر |
|---|---|---|
| Freelance project | تعهد مستقیم به Deliverable یا زمان توافقشده | Scope creep و پذیرش مبهم |
| Crowdtesting cycle | کار در چارچوب چرخه، قوانین و Payout ازپیشاعلامشده | Duplicate، رد گزارش و محدودیت کانال/پرداخت |
| Bug bounty / VDP | پژوهش امنیتی فقط در Scope و قواعد برنامه | خروج از مجوز یا افشای نامناسب |
| Employment | نقش سازمانی با شرایط استخدامی | اشتباهگرفتن نرخ/مزایا با قرارداد مستقل |
نام «تستر دورکار» نوع رابطه را تعیین نمیکند. یک همکاری ممکن است از نظر قانون حاکم، پلتفرم یا قرارداد ویژگیهایی متفاوت داشته باشد. این مقاله مشاورهٔ حقوقی یا مالیاتی نیست؛ وضعیت واقعی را باید با متن قرارداد، قواعد جاری ارائهدهنده و متخصص واجدصلاحیت در حوزهٔ مربوط بررسی کرد.
اول سه Gate مستقل را عبور دهید
- Eligibility Gate: آیا شخص با موقعیت واقعی، سن، هویت و وضعیت کاری واقعی اجازهٔ استفاده از کانال را دارد؟
- Payment Gate: آیا روش رسمی دریافت و برداشت برای همان کشور، شخص و ارز واقعاً در دسترس است؟
- Engagement Gate: آیا کارفرما اختیار واگذاری تست، محیط، داده، Scope، پذیرش و بودجه را روشن کرده است؟
عبور از یکی، دیگری را ثابت نمیکند. دیدن دکمهٔ ثبتنام، دعوت به Cycle یا لوگوی یک روش پرداخت شاهد امکان تسویه برای شما نیست. نتیجهٔ Gate باید با تاریخ، URL رسمی، نسخهٔ Terms، پاسخ پشتیبانی یا سند قراردادی ثبت شود؛ نه با تجربهٔ یک دوست یا اسکرینشات قدیمی.
واقعیت پلتفرم برای کاربر واقع در ایران؛ تاریخدار و بدون دورزدن
در بازبینی ۱۴ اوت ۲۰۲۶، صفحهٔ رسمی Eligibility در Upwork ایران را در فهرست موقعیتهایی قرار میدهد که اجازهٔ ثبتنام یا استفاده از پلتفرم ندارند. بنابراین Upwork برای شخصی که واقعاً در ایران قرار دارد در این تاریخ، Gate را رد میکند؛ حتی اگر مقالهای قدیمی آن را پیشنهاد کرده باشد. قواعد ممکن است تغییر کنند و باید نزدیک تصمیم دوباره بررسی شوند.
در uTest، راهنمای رسمی آمادهسازی پرداخت تستر میگوید PayPal، Payoneer و انتقال مستقیم بانکی در همهٔ کشورها موجود نیستند و گزینهٔ انتقال مستقیم فقط جایی نمایش داده میشود که پشتیبانی شود. این متن بهتنهایی Eligibility ایران یا امکان برداشت را تأیید نمیکند. ابتدا پشتیبانی رسمی، روش قابلنمایش در حساب واقعی و امکان برداشت قانونی به حساب متعلق به خود شخص را بررسی کنید.
حساب اجارهای، هویت یا نشانی ساختگی، استفاده از حساب شخص دیگر، پنهانکردن موقعیت یا انتقال خارج از مسیر مجاز راهحل این مقاله نیست. چنین اقدامهایی میتوانند Terms، KYC، حق دسترسی به وجه، محرمانگی و وضعیت حقوقی را مخدوش کنند. اگر Gate رد یا نامعلوم است، تصمیم امن HOLD است: کانال دیگری با شرایط روشن پیدا کنید، نه اینکه شاهد را جعل کنید.
Opportunity Record؛ قبل از ارسال Proposal
Opportunity-ID: As-of / source URL / Terms version: Channel / direct client / platform: True location and identity eligibility: Work authorization or restriction: Official payment method available: Withdrawal to own lawful account verified: Client identity and authority evidence: Target / environment / owner: Requested outcome and deadline: Known budget / currency / fees: Decision: GO | ASK | HOLD | DECLINE Owner / evidence / expiry:
«ASK» یعنی یک ابهام محدود با پاسخگو و مهلت دارید؛ «HOLD» یعنی پیششرط حیاتی هنوز اثبات نشده؛ «DECLINE» یعنی فرصت با قیدهای شما سازگار نیست. انباشتن Proposal روی فرصتهای نامعتبر، نرخ تبدیل را خراب میکند و زمان تشخیص کانال سالم را میگیرد.
Lead Qualification؛ هر آگهی یک فرصت نیست
- آیا شخص سفارشدهنده به سامانه و داده اختیار دارد؟
- آیا مسئلهٔ کیفیتی مشخص است یا فقط «همهچیز را تست کن» نوشته؟
- آیا محیط و Build در موعد مقرر آماده میشوند؟
- آیا خروجی، معیار پذیرش و تعداد Revision قابلتعریف است؟
- آیا پرداخت، ارز، کارمزد، مالیات و زمان تسویه روشناند؟
- آیا کار شامل پرداخت واقعی، دادهٔ حساس، مهندسی اجتماعی یا امنیت خارج از Scope است؟
- آیا تماس، فایل یا نصب ابزار ناشناس پیش از قرارداد درخواست شده است؟
برای فرصت با پاسخهای عمدتاً نامعلوم، تخفیف ندهید؛ سؤال بپرسید. قیمت پایین نبودِ اختیار، محیط یا Acceptance را درمان نمیکند.
خدمت QA را به Package قابلخرید تبدیل کنید
«تست دستی بلدم» خدمت نیست. Package باید سؤال، ورودی، فعالیت، خروجی و مرز ادعا داشته باشد. مثلاً «دو Session اکتشافی Checkout روی Build مشخص، با Charter، گزارش Finding بازتولیدپذیر، Coverage note و Debrief» قابلقیمتگذاریتر از «تست کامل سایت» است. برای طراحی Charter و تفاوت آن با روش Scripted از راهنمای تخصیص تست اکتشافی و Scripted استفاده کنید.
| Package نمونه | ورودی لازم | خروجی قابلپذیرش | ادعای ممنوع |
|---|---|---|---|
| Exploratory probe | Build، Scope، حساب ساختگی، Charter | Session note، Finding، Coverage/Unknown | «بدون باگ است» |
| Regression execution | نسخهٔ Suite، Data، Oracle | نتیجهٔ هر Check و Evidence معتبر | «کل محصول پوشش داده شد» |
| API review | Contract، Environment، Credential محدود | Mismatch و Reproduction | «API امن است» |
| Automation slice | Repo، Runner، CI، Definition of Done | کد، Check، Runbook و Handoff | «نگهداری صفر» |
Permission؛ اجازه را از داخل Scope استنباط نکنید
داشتن URL، حساب یا درخواست شفاهی بهمعنی مجوز هر نوع تست نیست. برای تست امنیتی، CISA توضیح میدهد که VDP باید سامانههای داخل Scope، آزمونهای مجاز/غیرمجاز و کانال گزارش را روشن کند؛ صفحهٔ رسمی سیاست افشای آسیبپذیری CISA این اصل را شفاف میکند. راهنمای داخلی افشای آسیبپذیری از Authorization تا Coordination نیز مرز امنیت را عمیقتر پوشش میدهد.
Permission-ID: Authorizing organization / named authority: Owned target and third-party dependencies: Allowed hosts, APIs, apps and builds: Allowed methods, rate, volume and window: Forbidden actions and out-of-scope systems: Environment / tenant / test identities: Sensitive-data handling and disclosure channel: Incident contact / stop authority: Evidence / signature / issued-at / expires-at:
اگر دامنه به CDN، PSP، سرویس پیامک، نقشه، Login اجتماعی یا SaaS ثالث متصل است، اجازهٔ صاحب محصول لزوماً اجازهٔ تست آن طرف ثالث نیست. آن Dependency را Stub، Sandbox یا Out of Scope کنید مگر اختیار صریح وجود داشته باشد.
Scope Contract؛ اسم Feature کافی نیست
Scope-ID: Product / service / artifact: Build / commit / config / feature flags: Environment / region / tenant: Included journeys, interfaces and risks: Excluded surfaces and dependencies: Platforms / devices / browsers: Test data / states / cleanup: Time window / capacity: Expected interruptions: Change authority / version / expiry:
«Checkout» میتواند UI، API، مالیات، انبار، Callback، Ledger و Reconciliation را دربر گیرد. اگر مرز Artifact و State ثبت نشود، هر Finding میتواند با جملهٔ «آن بخش در Scope نبود» رد شود و هر تغییر Build دوبارهکاری نامرئی بسازد.
Deliverable Contract؛ فایل تحویلی را نام ببرید
Deliverable-ID / Scope-ID: Artifact type and format: Required fields and evidence: Language / timezone / naming: Repository or submission channel: Redaction and retention: Review owner and review window: Acceptance criteria: Allowed revision rounds: Handoff / cleanup receipt:
Deliverable ممکن است Report، Test model، Check code، Dashboard query یا Evidence bundle باشد. «زمان صرفشده» و «خروجی پذیرفتنی» دو مفهوم جدا هستند؛ مدل تجاری باید بگوید کدامیک مبنای پرداخت است.
Acceptance را پیش از اجرا آزمونپذیر کنید
«کیفیت بالا»، «گزارش حرفهای» یا «بدون اشکال» معیار پذیرش نیستند. معیار خوب روی Artifact اعمال میشود و داور، مهلت، Evidence و راه اصلاح دارد.
Acceptance-ID: Deliverable and version: Required fields: Reproduction threshold: Evidence freshness and redaction: Oracle and allowed tolerance: Duplicate identity rule: Reviewer / decision authority: Review deadline: ACCEPT | REVISE | REJECT | DISPUTE Reason code / evidence / next action:
راهنمای رسمی حقوق تستر در uTest نمونهٔ مفیدی از شفافیت قبل از پذیرش Cycle است: Scope، دستورها و Payout باید پیش از قبول یا رد دیده شوند و مسیر سؤال و اعتراض وجود دارد. این قاعده را نباید به همهٔ قراردادها تعمیم حقوقی داد، اما میتوان آن را بهعنوان الگوی کنترل طراحی به کار برد.
Estimate؛ عدد را از واحد کار بسازید
برآورد باید از تعداد Surface، State، Data variant، Platform، Setup، Evidence، Review و Rework ساخته شود. «یک صفحه» ممکن است پنج حالت پرداخت، سه نقش، دو Locale و Callback دیررس داشته باشد. در برآورد، زمان هماهنگی، انتظار محیط، پاکسازی، Handoff و ظرفیت ازدسترفتهٔ رزروشده را هم آشکار کنید.
Estimate-ID: Scope version and assumptions: Units: session | case | endpoint | flow | check: Setup / execution / diagnosis / evidence: Communication / review / revision: Blocked-time rule: Range: optimistic / expected / adverse: Capacity and calendar window: Estimate confidence / unknowns: Re-estimate trigger:
قیمتگذاری؛ نرخ با درآمد یکی نیست
| مدل | مناسب برای | کنترل لازم |
|---|---|---|
| ساعتی | Scope اکتشافی یا عدمقطعیت بالا | Time log، سقف، گزارش پیشرفت و Stop |
| Fixed price | Deliverable و Acceptance پایدار | Change Order و Revision محدود |
| Milestone | کار چندمرحلهای با Gate | پذیرش و پرداخت مستقل هر مرحله |
| Per accepted item | Cycle با قواعد Duplicate روشن | انگیزه، کیفیت، داوری و اعتراض |
| Retainer | ظرفیت دورهای و نیاز تکرارشونده | ظرفیت رزروی، SLA، Carry-over و Exit |
برای مقایسه با استخدام، نرخ پروژه را با حقوق ماهانه یکی نگیرید. تعطیلی، زمان فروش، ابزار، کارمزد، مالیات، ریسک عدمپرداخت، ظرفیت خالی و مزایای شغلی باید جدا شوند. مقالهٔ حقوق تست نرمافزار در ایران روش خواندن داده و مقایسهٔ Offer را توضیح میدهد، نه نرخ قطعی فریلنسری.
Quoted price = delivery labor + setup and cleanup + review and included revision + communication and handoff + approved expenses and platform fees + disclosed risk/contingency Net receipt = collected amount - fees - lawful taxes/withholding - approved expenses - currency/settlement costs
ارز و واحد پول را دو بار نام ببرید
در Proposal و Invoice فقط علامت پول ننویسید. IRR و تومان یکی نیستند؛ تومان واحد رایجِ ارائه است و باید ضریب تبدیل آن صریح باشد. برای ارز خارجی، Currency code، منبع و زمان نرخ تبدیل، مسئول کارمزد، مبلغ ناخالص/خالص و وضعیت بازگشت وجه را ثبت کنید. نرخ لحظهای یا «معادل امروز» بدون منبع و Timestamp، قرارداد نیست.
Money-ID: Quoted amount / ISO currency: If toman is displayed: 1 toman = 10 IRR: Rate source / observed-at / timezone: Gross / fee / withholding / expense / net: Payer of each fee: Settlement date and method: Late / failed / reversed payment rule:
Proposal خوب، مینیقرارداد پنهان نیست
Proposal باید نشان دهد مسئله را فهمیدهاید، اما جای Scope و قرارداد را نگیرد. بدون اجازه، سامانهٔ عمومی مشتری را برای «اثبات مهارت» اسکن یا تست نکنید. یک Observation سطحی از آگهی را هم Fact محصول جا نزنید.
سلام، برداشت من از مسئله: [یک جمله، همراه Unknown]. برای تصمیم [X]، پیشنهاد میکنم [Package] روی [Scope اولیه] اجرا شود. تحویل: [Artifacts]؛ پذیرش: [سه معیار]. پیشنیاز: Permission، Build، Environment، Data و Reviewer. برآورد فعلی: [Range] بر اساس [Assumptions]. موارد خارج از Scope: [فهرست]. سؤال Gate: [یک تا سه سؤال تعیینکننده]. پس از پاسخ، Scope/Estimate نسخهدار میشود.
نمونهکار و رزومه؛ Claim باید Evidence داشته باشد
رزومه برای عبور از آگهی و پورتفولیو برای بررسی عمیق Artifact است. برای ساخت Claim–Evidence و حذف عددهای بیپشتوانه، راهنمای رزومه QA را ببینید؛ برای مجوز انتشار، پاکسازی داده و Verification از راهنمای پورتفولیوی QA استفاده کنید.
نام مشتری، دامنه، Screenshot، Token، Log، دادهٔ کاربر، Ticket داخلی و عدد کسبوکار را بدون مجوز منتشر نکنید. نسخهٔ Synthetic باید واضح برچسب بخورد؛ ناشناسسازی ظاهری لزوماً Re-identification را ناممکن نمیکند.
Contract Stack؛ NDA بهتنهایی کافی نیست
- هویت طرفین، اختیار امضا و قانون/مرجع حل اختلاف؛
- Scope، Deliverable، Acceptance و Change Order؛
- قیمت، ارز، مالیات/کسورات، کارمزد، Invoice و موعد پرداخت؛
- مالکیت فکری، مجوز استفاده از ابزار/کد و Portfolio permission؛
- محرمانگی، داده، امنیت، Incident و Retention؛
- دسترسی، تجهیزات، Subcontracting و شخص انجامدهنده؛
- توقف، تعلیق، خاتمه، پرداخت کار انجامشده و Handoff؛
- نسخه، پیوستها، اولویت اسناد و ثبت تغییرات.
قرارداد نمونهٔ اینترنتی را بدون تطبیق کپی نکنید. تعهدات مالیاتی، بیمهای، ارزی و قراردادی به اشخاص، نوع رابطه و حوزههای قضایی وابستهاند. پیش از پذیرش تعهد واقعی، متن را با متخصص محلی واجدصلاحیت بررسی کنید.
Change Order؛ پاسخ Scope creep
Change-ID / requested-at: Requester and authority: Current Scope/Build version: Requested delta: Reason and urgency: Impact on effort, calendar, price and evidence: New risks / exclusions: ACCEPT | DEFER | REJECT: Approvers / effective-at: Superseded records:
تغییر کوچک UI ممکن است Oracle، Data یا Automation را عوض کند. تا Change تأیید نشده، آن را «لطف کوچک» تلقی نکنید. در عین حال، اصلاح نقصی که Deliverable را از Acceptance اولیه دور کرده Change نیست؛ Revision تعهدشده است. مرز این دو را از قبل بنویسید.
Communication Contract؛ خوشقولی یعنی پیشبینیپذیری
Channel of record: Working hours / timezone: Expected response window: Daily or milestone update: Blocker severity and escalation: Decision owner: Meeting purpose / attendance / notes: Language and terminology: Emergency stop channel: Silence / abandonment rule:
«همیشه آنلاین» تعهد سالمی نیست. پنجرهٔ پاسخ، روزهای کاری و فوریت را تعریف کنید. برای درخواست، تصمیم، تعارض و Closure قابلردیابی، چارچوب تعامل ذینفعان در QA مفید است.
Access Contract؛ کمینه، زماندار و قابلابطال
حساب مشترک، Credential در پیامرسان و دسترسی Production بیپایان نپذیرید. هویت تستی جدا، کمترین Role، MFA مناسب، Secret channel، زمان انقضا و Log لازم است. تستر نیز نباید Secret را در Screen recording، Ticket، Repository یا ابزار AI عمومی وارد کند.
Access-ID / person: Resource / environment / tenant: Role and permitted actions: Issued-by / approved-by: Credential delivery channel: MFA / device requirements: Starts / expires: Logging / review: Revoke trigger: Revocation receipt:
Test Data؛ «ساختگی» را قابلاثبات کنید
دادهٔ تست باید منشأ، Schema، مالک، حساسیت، Locale، State، عمر و Cleanup داشته باشد. کپی دیتابیس Production با حذف نام، لزوماً Synthetic نیست. برای ایران، عدد فارسی/عربی/لاتین، ی/ی، ک/ک، ZWNJ، RTL/LTR، IRR/تومان و UTC/Asia–Tehran را بهعنوان Variant طراحی کنید؛ تبدیل جلالی را فقط وقتی Claim کنید که منبع و قواعد پیادهسازی معلوم باشد.
Execution Log؛ کار پنهان را قابلبازبینی کنید
Run-ID / Engagement-ID: Tester / started-at / ended-at: Build / config / environment: Scope and Charter/Suite version: Data set / accounts / state: Actions and observations: Oracle / result / uncertainty: Evidence references: Blockers / interruptions / changes: Cleanup status / next action:
Log برای کنترل دقیقهبهدقیقهٔ فرد نیست؛ زنجیرهٔ Artifact تا تصمیم را حفظ میکند. اگر مدل ساعتی است، Time entry باید به فعالیت و خروجی پیوند بخورد. اگر Fixed price است، Log همچنان برای Reproduction، Change و Handoff ارزش دارد.
Bug Report؛ تعداد بیشتر مساوی ارزش بیشتر نیست
یک Finding باید Target، Build، State، Data، مراحل، مشاهده، Oracle، Impact، Evidence، Reproducibility و Unknown داشته باشد. Severity را با Priority یکی نکنید و نتیجهٔ تجاری را بدون شاهد نسازید. برای Workflow و Field Contract میتوانید از راهنمای Jira برای QA کمک بگیرید.
Finding-ID: Scope / Build / Environment: Precondition / State / Data: Steps / Attempt count: Observed / expected / Oracle source: Impact hypothesis / confidence: Evidence / redaction: Duplicate relationship: Owner / disposition / decision: Retest / closure evidence:
Duplicate و Payout؛ Incentive را تست کنید
در مدل پرداخت به Finding پذیرفتهشده، تستر ممکن است هزینهٔ کشف و مستندسازی را بدهد اما گزارش بهعنوان Duplicate رد شود. پیش از پذیرش، بپرسید هویت Duplicate بر اساس Root cause، symptom، endpoint، build یا Ticket چگونه تعیین میشود؛ آیا Evidence تازه ارزش مستقل دارد؛ داور و مهلت اعتراض کیست؛ و تغییر Scope چگونه اعلام میشود.
راهنمای رسمی انواع پرداخت در uTest نشان میدهد پرداخت میتواند به Issue پذیرفتهشده، Test case، Review، Usability یا Task دیگر مربوط باشد؛ پس عبارت «پرداخت بهازای هر باگ» توصیف کامل حتی همان پلتفرم نیست و مبلغ ثابتی را تضمین نمیکند.
Evidence Policy؛ مدرک بیشتر همیشه بهتر نیست
| Evidence | حداقل کنترل | ریسک |
|---|---|---|
| Screenshot/video | Build، زمان، مراحل و Redaction | PII، اعلان و Secret |
| Log/trace | Source، بازه، timezone و correlation | Token و دادهٔ حساس |
| HAR/request | Scope، headers پاکشده و retention | Session hijack و دادهٔ ثالث |
| Automation result | commit، runner، config، data و raw result | False green و Flake |
| Meeting note | حاضرین، تصمیم، authority و action | برداشت مبهم یا انتشار ناخواسته |
Evidence باید برای داوری کافی و برای حریم خصوصی کمینه باشد. سیاست نگهداری بگوید چه چیزی کجا، توسط چه کسی، تا چه زمانی و با چه روش حذف میشود. «بعداً پاک میکنیم» Cleanup receipt نیست.
Dispute Record؛ اختلاف را از رابطهٔ شخصی جدا کنید
Dispute-ID: Engagement / Deliverable / Acceptance version: Claim by each party: Contested amount or decision: Evidence from both sides: Applicable contract/platform clause: Undisputed portion: Reviewer / appeal path / deadline: Resolution / payment / correction: Closure and retained records:
مبلغ بدون اختلاف را از بخش مورد اختلاف جدا کنید. گفتوگو را در Channel of record نگه دارید، از تهدید یا انتشار دادهٔ مشتری خودداری کنید و اگر موضوع حقوقی شد از متخصص واجدصلاحیت کمک بگیرید. هیچ متن عمومی نمیتواند نتیجهٔ اختلاف واقعی را پیشبینی کند.
Invoice و Settlement؛ «پرداخت شد» یک State است
Invoice-ID / contract / milestone: Seller and buyer legal identities: Deliverable acceptance reference: Issue date / due date / timezone: Gross amount / ISO currency: Fees / expenses / withholding / net: Official payment route: Payment reference / received-at: State: DRAFT | ISSUED | DUE | PAID | PARTIAL | FAILED | DISPUTED | REVERSED Receipt / reconciliation / correction:
نمایش Balance در یک داشبورد با امکان برداشت یا وصول نهایی یکی نیست. روش رسمی را پیش از شروع با مبلغ کم و بدون دورزدن Terms اعتبارسنجی کنید؛ هزینهٔ آزمایش و مسئول برگشت را از قبل مشخص کنید. از ارسال پول برای «آزادسازی درآمد»، خرید تجهیزات از فروشندهٔ تحمیلی یا انتقال وجه برای مشتری پرهیز کنید و مورد مشکوک را از کانال رسمی گزارش دهید.
مسیر مستقیم در ایران؛ محلی بودن هم Gate میخواهد
قرارداد مستقیم ریالی میتواند محدودیت یک پلتفرم خارجی را نداشته باشد، اما ریسک هویت طرف، اختیار، مالیات، مالکیت فکری و پرداخت همچنان باقی است. نام تجاری، شناسه/اطلاعات لازم برای قرارداد، نمایندهٔ مجاز، نشانی ابلاغ، حساب متعلق به طرف قرارداد و مسیر Invoice را بررسی کنید. معرفی شفاهی جای سند را نمیگیرد.
برای پروژهٔ خارجی نیز «کارفرما حاضر است» کافی نیست. قوانین و محدودیتهای قابلاعمال به طرفین، بانک/پرداختیار، پلتفرم، فناوری و کشورها ممکن است متفاوت باشند. این بررسی باید موردی، تاریخدار و توسط منبع رسمی یا متخصص مناسب انجام شود.
Capacity؛ چند پروژه همزمان یک مزیت خودکار نیست
ظرفیت را با ساعت تقویمی یکی نگیرید. Context switching، جلسه، انتظار Review، محیط خراب، Rework و فروش، ظرفیت تحویل را کم میکنند. رزرو بیشازحد باعث Evidence ضعیف، Deadline شکسته و فرسودگی میشود.
Capacity week: Available working window: - existing delivery commitments - review/revision reserve - sales/admin/invoice - recovery and learning - uncertainty buffer = offerable capacity Maximum concurrent engagements: Stop-accepting trigger:
Pipeline را با State و Denominator ببینید
تعداد Proposal بدون مخرج چیزی نمیگوید. Opportunityهای واجدشرایط، پاسخ، Discovery، Proposal پذیرفتهشده، قرارداد، Milestone پذیرفته، وصول و تکرار همکاری را جدا کنید. زمان فروش و تأخیر وصول را هم اندازه بگیرید؛ اما این سنجهها را برای سرزنش خود یا وعدهٔ درآمد به دیگران استفاده نکنید.
Opportunity → QUALIFIED | HOLD | DECLINED Qualified → DISCOVERY | NO_RESPONSE Discovery → PROPOSAL | NO_FIT Proposal → ACCEPTED | REJECTED | EXPIRED Engagement → ACTIVE | BLOCKED | CHANGED | CLOSED Invoice → ISSUED | DUE | PAID | DISPUTED | FAILED Relationship → REPEAT | REFERRED | ENDED
سنجههای مفید و Countermetricها
- Qualified-to-contract rate همراه با تعداد فرصت و تعریف Qualified؛ نه «محبوبیت».
- Estimate error همراه با Scope change و Blocked time؛ نه دقت فرد بهتنهایی.
- Acceptance latency همراه با ظرفیت Reviewer؛ نه سرعت تستر فقط.
- First-pass acceptance همراه با پیچیدگی و تغییر Build؛ نه مسابقهٔ بدون Revision.
- Collection latency همراه با Terms و مسیر بانکی؛ نه ارزش فنی.
- Repeat engagement همراه با Margin، سلامت و رضایت دوطرفه؛ نه موفقیت قطعی.
- Evidence correction rate همراه با Severity؛ نه پنهانکردن خطا.
سناریوی ایرانی کاملاً ساختگی؛ تسویهٔ Checkout بدون پول واقعی
SYN-FREELANCE-QA-IR-01 یک آزمایشگاه آفلاین و درونحافظهای است. Client، فریلنسر، فروشگاه، Order، PaymentAttempt، PSP Stub، Callback، Ledger و Reconciliation همگی ساختگیاند؛ هیچ Domain، حساب، Credential، پلتفرم، کاربر، بانک، پول یا نتیجهٔ واقعی وجود ندارد. مبلغ canonical با IRR نگهداری میشود و تومان فقط با برچسب نمایشی و نسبت ۱ تومان = ۱۰ IRR دیده میشود.
Fixture شامل رقم فارسی/عربی/لاتین، ی/ی، ک/ک، نیمفاصله، RTL/LTR/Bidi، UTC و Asia/Tehran است؛ تاریخ جلالی فقط Presentation و غیرمرجع است. Faultها شامل timeout پیش/پس از commit ساختگی، retry، callback تکراری/دیر/جابجا، تغییر Build، دادهٔ منقضی، Evidence دارای Dummy token، Duplicate مبهم، پذیرش هدفمتحرک، Fee پنهان و Settlement معکوس ساختگیاند.
اجرای ناامن آزمایشگاه چه ادعایی میسازد؟
نسخهٔ سطحی فقط پنج شعار «درآمد دلاری»، «پروفایل مساوی پروژه»، «کمترین قیمت برنده است»، «تعداد باگ ارزش را ثابت میکند» و «ثبتنام یعنی Eligibility» را میبیند و بهاشتباه خروجی زیر را میدهد:
FREELANCE_QA_DOLLAR_INCOME_PLATFORM_PROFILE_LOW_PRICE_BUG_COUNT_READY
این خروجی هیچ Terms، هویت، موقعیت، پرداخت، اختیار، Scope، Acceptance، Evidence، Fee یا وصولی را بررسی نکرده است؛ بنابراین یک False green بازاریابی است.
ممیزی مستقل؛ ۸۴۰ کنترل و HOLD
Validator مستقل ۶۰ گروه—از identity/as-of/opportunity/channel/eligibility/location تا permission/scope/deliverable/acceptance/pricing/payment/evidence/dispute/cleanup/exit/correction—را با ۱۴ کنترل group-qualified میسازد. Assertion یکتایی دقیقاً ۸۴۰ کلید مستقل را الزام میکند و پیش از پینشدن قراردادها نتیجه میدهد:
HOLD-840 NO_REAL_CLIENT_FREELANCER_IDENTITY_ACCOUNT_CREDENTIAL_PLATFORM_PAYMENT_MONEY_TARGET_OR_OUTCOME_PASS
قاعدهٔ دوم مستقل از شمارش کنترلها ثابت میکند Fixture به هیچ شخص، مشتری، هویت، حساب، Credential، پلتفرم، پرداخت، پول، Target یا Outcome واقعی متصل نیست. پس آزمایشگاه برای اقدام مالی یا پذیرش پروژه قابلاستفاده نیست.
پس از اصلاح، فقط Readiness برای Review
با پینشدن Eligibility evidence، Permission، Scope، Exclusion، Deliverable، Acceptance، Change، Price basis، مسیر Settlement ساختگی، Evidence policy و Cleanup receipt، خروجی اصلاحی چنین است:
READY_FOR_FREELANCE_QA_ENGAGEMENT_REVIEW-0
صفر یعنی هیچ فیلد الزامی Fixture جا نیفتاده؛ نه اینکه قرارداد قانونی، مشتری معتبر، تست کافی، درآمد تضمین، پرداخت ممکن، مالیات صحیح، پلتفرم مجاز یا همکاری موفق است. تصمیم واقعی همیشه به Evidence تازه و داوری انسان مسئول نیاز دارد.
Exit و Offboarding؛ پروژه با ارسال فایل تمام نمیشود
- آخرین Scope، Deliverable و Acceptance را reconcile کنید.
- Findingهای باز، Unknownها و ریسک باقیمانده را تحویل دهید.
- Repository، Runbook، Data dictionary و Decision log را منتقل کنید.
- Invoice، مبلغ بدون اختلاف و Receipt را ثبت کنید.
- دسترسیها را لغو و Secretهای موقت را Rotate کنید.
- Data/Evidence را طبق Retention حذف و Cleanup receipt صادر کنید.
- مجوز Portfolio/Testimonial را جداگانه و قابلابطال ثبت کنید.
- مسئول پاسخگویی پس از خروج و تاریخ پایان را مشخص کنید.
۲۸ ضدالگوی فریلنسری QA
- تضمین درآمد یا تعداد پروژه؛
- نرخ دلاری بیتاریخ و بینمونه؛
- ثبتنام را مساوی Eligibility دانستن؛
- حساب، نشانی یا هویت غیرواقعی؛
- حساب اجارهای یا متعلق به دیگری؛
- پنهانکردن موقعیت واقعی؛
- قبول کار پیش از Payment Gate؛
- تست عمومی بدون Permission؛
- فرض اجازهٔ سرویس ثالث؛
- Scope با عبارت «تست کامل»؛
- خروجی فقط «لیست باگ»؛
- Acceptance هدفمتحرک؛
- قیمت Fixed برای Scope ناشناخته؛
- شروع ارزان برای خرید Review؛
- کار نمونهٔ بزرگ و رایگان؛
- تعداد باگ بهعنوان KPI فرد؛
- Severity مساوی Priority؛
- Screenshot بدون Redaction؛
- Token در Ticket یا ویدئو؛
- استفاده از دادهٔ Production با NDA؛
- حساب مشترک و دسترسی بیانقضا؛
- تغییر شفاهی بدون Change Order؛
- جلسه و انتظار بدون قاعده؛
- تومان بدون IRR و ضریب؛
- Balance مساوی وصول؛
- انتشار Portfolio بدون مجوز؛
- تحویل بدون Handoff؛
- خروج بدون Revoke و Cleanup receipt.
برنامهٔ ۳۰روزه؛ بدون مشتری و پرداخت واقعی
- روز ۱ تا ۷: یک Package محدود، Scope، Deliverable، Acceptance، Permission و Estimate برای Fixture آفلاین بسازید.
- روز ۸ تا ۱۴: دو اجرای ساختگی با Build/Data متفاوت انجام دهید؛ Finding، Evidence و Cleanup را Peer review کنید.
- روز ۱۵ تا ۲۱: Proposal، Change Order، Invoice و Dispute ساختگی را روی سناریوی timeout/duplicate تمرین کنید.
- روز ۲۲ تا ۲۶: Eligibility و Payment Gate دو کانال را فقط از منابع رسمی تاریخدار بررسی کنید؛ اگر مبهماند HOLD بگذارید.
- روز ۲۷ تا ۳۰: Handoff پاک، Portfolio کاملاً Synthetic و Retrospective بنویسید؛ هیچ حساب، مشتری، پول یا Target واقعی وارد آزمایش نکنید.
چکلیست ۴۸نقطهای پیش از پذیرش پروژه
- Opportunity-ID و As-of؛
- منبع رسمی Terms؛
- هویت و موقعیت واقعی؛
- Eligibility روشن؛
- Work authorization بررسیشده؛
- روش پرداخت رسمی؛
- برداشت به حساب خود شخص؛
- کارمزد و Currency؛
- مالیات/کسورات برای بررسی تخصصی؛
- هویت طرف قرارداد؛
- اختیار نماینده؛
- مالک Target؛
- Permission امضاشده؛
- سرویس ثالث تعیین تکلیف؛
- Build/Config پینشده؛
- Environment/Tenant؛
- Scope included؛
- Scope excluded؛
- روشهای مجاز؛
- Stop contact؛
- Test data منشأدار؛
- PII/Secret policy؛
- Access کمینه؛
- دسترسی منقضیشونده؛
- Package تعریفشده؛
- Deliverable نسخهدار؛
- Acceptance آزمونپذیر؛
- Reviewer و مهلت؛
- Duplicate rule؛
- Revision محدود؛
- Change Order؛
- Estimate range؛
- Assumption و Unknown؛
- مدل قیمت؛
- مبلغ/ISO Currency؛
- IRR/تومان صریح؛
- هزینه و Expense؛
- Milestone؛
- Invoice state؛
- Dispute path؛
- Channel of record؛
- Timezone/response؛
- Execution log؛
- Evidence/redaction؛
- Handoff؛
- Revoke receipt؛
- Cleanup receipt؛
- Exit و Correction owner.
جمعبندی؛ پروژه را قبل از باگگیری طراحی کنید
فریلنسر QA حرفهای کسی نیست که بیشترین ابزار را در پروفایل مینویسد یا کمترین قیمت را پیشنهاد میدهد. او پیش از کار، Eligibility و پرداخت را اثبات میکند؛ اختیار، Scope، خروجی و پذیرش را نسخهدار میسازد؛ حین اجرا Evidence کمینه و معتبر نگه میدارد؛ Change و اختلاف را ثبت میکند؛ و در پایان وصول، Handoff، لغو دسترسی و Cleanup را میبندد.
نتیجه ممکن است GO، ASK، HOLD یا DECLINE باشد. ردکردن یک فرصت نامعتبر شکست نیست؛ کنترل ریسک حرفهای است. هیچ Package، گواهی، پلتفرم یا تعداد Finding هم درآمد، استمرار پروژه یا نتیجهٔ کسبوکار را تضمین نمیکند.
پرسشهای متداول فریلنسری QA
آیا تستر ساکن ایران میتواند در Upwork کار کند؟
طبق صفحهٔ رسمی Eligibility که در ۱۴ اوت ۲۰۲۶ بررسی شد، افراد واقع در ایران اجازهٔ ثبتنام یا استفاده از Upwork را ندارند. این وضعیت ممکن است تغییر کند؛ منبع رسمی را نزدیک تصمیم دوباره بخوانید و از هویت، نشانی، حساب یا موقعیت غیرواقعی استفاده نکنید.
آیا برای شروع فریلنسری QA باید اتوماسیون بلد باشم؟
نه برای همهٔ Packageها. یک خدمت اکتشافی، اجرای Regression یا بازبینی مستند میتواند بدون کدنویسی ارزشمند باشد، بهشرط Scope، Oracle و Evidence معتبر. Automation فقط برای مسئلهای که تکرار، نگهداری، Runner و Handoff آن توجیه شده مناسب است.
نرخ تستر فریلنسر چقدر است؟
یک نرخ عمومی و پایدار وجود ندارد. Scope، تخصص، ریسک، بازار، مدل قیمت، ارز، کارمزد، مالیات، زمان فروش، Revision و احتمال وصول متفاوتاند. نرخ مشاهدهشده را با تاریخ، نمونه و تعریف کار ثبت کنید و آن را درآمد خالص یا تضمین آینده ننامید.
آیا میتوانم پیش از قرارداد برای کارفرما باگ پیدا کنم؟
فقط روی Artifact و روشهایی که مجوز روشن دارند. عمومیبودن یک وبسایت مجوز اسکن، Load، دورزدن کنترل یا دسترسی به داده نیست. برای نمونهکار از Fixture آفلاین، Demo مجاز یا Task کوچک پولی با Permission استفاده کنید.
اگر مشتری Scope را وسط پروژه تغییر داد چه کنم؟
تغییر را با Change-ID ثبت و اثر آن بر زمان، قیمت، Evidence و ریسک را اعلام کنید؛ سپس فقط با Authority توافقشده اجرا کنید. اصلاح Deliverable ناقض Acceptance قبلی Revision است، اما افزودن Surface، Build یا خروجی جدید معمولاً Change محسوب میشود.
