فرسودگی شغلی در QA؛ از Work Risk تا Support

وقتی یک تستر پس از چند هفته رگرسیون فشرده می‌گوید «دیگر تمرکز ندارم»، پاسخ حرفه‌ای نه یک شعار انگیزشی است و نه تشخیص از راه دور. پرسش درست این است: کدام بخش از طراحی کار—حجم و ریتم تقاضا، اختیار، حمایت، روابط، ابهام نقش یا تغییر—به فشار مزمن دامن می‌زند؛ اکنون چه خطری برای فرد و محصول وجود دارد؛ و چه کسی باید کدام شرایط را تا چه زمانی عوض کند؟ این راهنما برای همین تصمیم ساخته شده است.

فرسودگی شغلی در QA را اینجا با یک «پرونده ریسک و حمایت کاری» مدیریت می‌کنیم: زمینه و سیگنال را بدون برچسب‌زدن ثبت می‌کنیم، کار پرریسک را ایمن می‌سازیم، اقدام سازمانی را بر توصیه فردی مقدم می‌گذاریم، حمایت یا ارجاع را با رضایت و محرمانگی فراهم می‌کنیم و اثر تغییر را در یک بازه معین بازبینی می‌کنیم. خروجی این فرایند، تشخیص پزشکی یا تضمین پیشگیری نیست؛ یک تصمیم کاری قابل پیگیری است.

پاسخ کوتاه: برای جلوگیری از فرسودگی تستر چه کنیم؟

• گزارش فرد را جدی بگیرید و از او نخواهید بیماری، انگیزه یا «تاب‌آوری» خود را اثبات کند.
• اگر خطر فوری برای سلامت یا ایمنی وجود دارد، گفت‌وگوی عادی عملکرد را متوقف و مسیر کمک فوریِ متناسب با محل و سازمان را فعال کنید.
• تا روشن‌شدن وضعیت، کارهای برگشت‌ناپذیر یا پرخطر مانند تأیید انتشار، تغییر Production و رانندگی پس از شیفت طولانی را بازتخصیص یا با بازبینی دوم کنترل کنید.
• علت‌های قابل تغییر کار را در شش محور تقاضا، اختیار، حمایت، روابط، نقش و تغییر بررسی کنید؛ تکرار تست تنها یکی از ورودی‌هاست.
• یک اقدام دارای مالک، موعد، معیار پذیرش و زمان بازبینی انتخاب کنید: کاهش یا توقف تقاضا، افزایش ظرفیت، چرخش وظیفه، رفع مانع، روشن‌کردن نقش یا فراهم‌کردن حمایت.
• استراحت، یادگیری و مراقبت فردی را اختیاری و مکمل نگه دارید؛ آن‌ها جایگزین اصلاح اضافه‌کاری، کمبود نیرو، آزار، ابهام یا برنامه غیرواقعی نیستند.
• فقط داده لازم را نگه دارید، دسترسی را محدود کنید و داده سلامت را وارد Jira، داشبورد تیم یا ارزیابی عملکرد نکنید.
• در بازبینی، شرایط کار و توان انجام ایمن کار را بسنجید؛ اگر اقدام اثر نکرد، مسئله را باز کنید و سطح حمایت یا مسیر تخصصی را تغییر دهید.

مرز مهم: فرسودگی، خستگی و وضعیت پزشکی یکی نیستند

سازمان جهانی بهداشت Burn-out را در ICD-۱۱ یک پدیده شغلی ناشی از استرس مزمنِ کاریِ مدیریت‌نشده توصیف می‌کند، نه یک وضعیت پزشکی. سه بُعد آن تخلیه انرژی، فاصله ذهنی/بدبینی نسبت به شغل و کاهش کارآمدی حرفه‌ای است. این تعریف برای فهم دامنه مفید است، اما مجوز تشخیص همکار یا نتیجه‌گیری از یک نشانه نیست.

وضعیت	آنچه می‌توان دید یا شنید	پاسخ کاری مناسب	آنچه نباید نتیجه گرفت
یکنواختی یا کم‌درگیری	تکراری‌بودن کار، استفاده‌نشدن از مهارت، درخواست تنوع	بازطراحی کار، چرخش رضایتمندانه، مشارکت در تحلیل و اکتشاف	فرد تنبل یا حتماً فرسوده است
خستگی	کاهش توجه، کندی واکنش، نیاز به استراحت؛ ممکن است کوتاه‌مدت باشد	توقف کار حساس، استراحت و بازیابی، اصلاح شیفت/ساعات/تقاضا	با یک خواب یا قهوه همیشه رفع می‌شود
فرسودگی شغلی	تجربه گزارش‌شده در زمینه کار و در طول زمان؛ سه بُعد WHO	ارزیابی ریسک‌های کاری، مداخله سازمانی، حمایت و بازبینی	مدیر یا فرم می‌تواند آن را تشخیص دهد
مسئله سلامت یا بحران	فرد درخواست کمک می‌کند، ناتوانی جدی یا خطر فوری را گزارش می‌دهد	کمک حرفه‌ای/اورژانسی متناسب با محل، ایمن‌سازی و حفظ حریم	این مقاله جای درمان یا ارزیابی بالینی است

خستگی نیز فقط خواب‌آلودگی نیست. راهنمای NIOSH درباره خستگی و کار می‌گوید ساعات طولانی یا نامتعارف، استرس و کار ذهنی پرفشار می‌توانند با خستگی مرتبط باشند و توجه، حافظه کوتاه‌مدت و قضاوت را کاهش دهند. بنابراین وقتی یک تستر می‌گوید برای بررسی تراکنش حساس تمرکز کافی ندارد، این یک ورودی ایمنی است، نه موضوع رتبه‌بندی عملکرد.

اگر خطر فوری وجود دارد، این راهنما را متوقف کنید

اگر فرد از آسیب قریب‌الوقوع به خود یا دیگری، ناتوانی در حفظ ایمنی، بحران شدید، یا وضعیت جسمی/روانی فوری صحبت می‌کند، مدیر نباید مصاحبه تشخیصی انجام دهد. کار حساس را ایمن و متوقف کنید، فرد را تنها نگذارید اگر این کار ایمن و مورد پذیرش اوست، و از مسیر اورژانسی یا کمک حرفه‌ای معتبرِ همان محل و سیاست سازمان استفاده کنید. شماره‌ها و دسترسی‌ها با کشور و زمان تغییر می‌کنند؛ مسیر محلی را از قبل توسط فرد مسئول و واجد صلاحیت نگهداری و بازبینی کنید.

تهدید، خشونت، آزار، تبعیض، تلافی یا نگرانی حفاظت‌شده نیز با «جلسه انگیزشی» حل نمی‌شود. برای مکالمه‌ای با ریسک تنش از قرارداد گفت‌وگوی دشوار و De-escalation و برای افشای امن از مسیر گزارش نگرانی محفوظ استفاده کنید. حریم خصوصی به معنی منزوی‌کردن فرد با مدیر مسئله‌ساز نیست.

مالکیت محتوایی: این مقاله چه چیزی را حل می‌کند؟

این راهنما مالک چرخه Work Context → Risk Signal → Safety → Work Redesign → Support → Review → Recovery/Change/Exit است. برنامه‌ریزی ظرفیت، WIP و وقفه‌ها در راهنمای Capacity و Flow تستر مدیریت می‌شود؛ احساس خودکم‌بینی و شواهد زمینه‌ای در راهنمای احساس ایمپاستر در QA؛ و طراحی نظام رهبری در سیستم عملیاتی رهبری تیم QA. این مرزبندی جلوی نسخه‌پیچی یکسان برای مسئله‌های متفاوت را می‌گیرد.

QA Work-Strain Support Record چیست؟

پرونده ریسک و حمایت کاری QA یک پرونده حداقلی، زمان‌دار و دسترسی‌محدود برای هماهنگ‌کردن اقدام‌های کاری است. نام انگلیسی آن در این مقاله QA Work-Strain Support Record است. این پرونده به جای امتیاز Burnout، «ادعا/مشاهده/مجهول»، شرایط کار، کنترل فوری، تصمیم، رضایت، مالک و نتیجه بازبینی را نگه می‌دارد.

SupportRecordID: QAWS-SYN-001
Version / Status: v1 / OPEN
OpenedAt / TimeZone: 2026-08-13T09:00:00Z / Asia-Tehran
PersonAlias: QA-A (در تمرین کاملاً ساختگی)
WorkContext: Release-R7 / Regression / On-call overlap
SignalSource: SELF_REPORTED
Statement: «در بررسی پرداخت تمرکز کافی ندارم»
Known / Unknown: سه شب استقرار دیرهنگام / وضعیت سلامت نامعلوم
ImmediateSafetyControl: توقف تأیید پرداخت + بازبین دوم
WorkRiskFactors: Demand, Control, Support, Role
ChosenActions: کاهش دامنه، حذف on-call، رفع ابهام اختیار
SupportOffer / Consent: جلسه داوطلبانه / ACCEPTED
Owner / Due: QA-Lead / 2026-08-14T08:00:00Z
ReviewAt: 2026-08-16T08:00:00Z
Access / Retention: Need-to-know / DeleteAt=2026-09-16
Outcome: NOT_YET_REVIEWED
ClinicalDiagnosis: NOT_COLLECTED

مرحله صفر: هویت، رضایت و حریم خصوصی را ببندید

پیش از جزئیات، شناسه پرونده، نسخه، وضعیت، زمان UTC، نمایش Asia/Tehran، فرد ثبت‌کننده، هدف استفاده و تاریخ بازبینی را مشخص کنید. به فرد بگویید چه چیزی ثبت می‌شود، چه کسانی دسترسی دارند، تا چه زمانی می‌ماند، کجا اصلاح می‌شود و چه بخش‌هایی اختیاری است. رضایت به حمایت، رضایت به ضبط صدا یا اشتراک جزئیات پزشکی نیست.

• حداقل داده: برای تصمیم کاری، نام بیماری، دارو، سابقه خانوادگی یا متن جلسه درمان لازم نیست.
• جداسازی: یادداشت حمایتی را از Jira، TestRail، Slack عمومی، داشبورد KPI و پرونده بازخورد عملکرد جدا کنید.
• دسترسی: نقش‌های مجاز، دلیل دسترسی و دریافت‌کننده هر انتقال را ثبت کنید؛ لینک عمومی یا export بی‌مالک ممنوع است.
• اصلاح: فرد باید بتواند گزاره منتسب به خود را ببیند و خطای factual را اصلاح کند.
• نگهداشت: آغاز و پایان نگهداشت، حذف مشتق‌ها/خروجی‌ها و استثنای الزام‌آورِ تعیین‌شده توسط نقش واجد صلاحیت را روشن کنید.

مرحله یک: سیگنال را بدون تشخیص ثبت کنید

سیگنال می‌تواند خوداظهاری فرد، درخواست مرخصی یا تغییر کار، مشاهده قابل توصیف، خطای نزدیک به وقوع، افزایش دوباره‌کاری، ساعات غیرعادی یا الگوی وقفه باشد. هر مورد را با منبع، بازه و محدودیت ثبت کنید. «سه بار در Review گفته شد انتظار Severity روشن نیست» مشاهده است؛ «او بی‌انگیزه و افسرده است» تفسیر و احتمالاً برچسب ناموجه است.

فیلد	نمونه خوب	نمونه نامعتبر
Self-report	نقل‌قول کوتاه با تأیید گوینده و تاریخ	بازنویسی مدیر به زبان تشخیصی
Observation	دو Review بدون استراحت، ۱۳ ساعت حضور ثبت‌شده	زبان بدن نشان می‌دهد فرسوده است
Work data	ورود ۴۲ مورد، ظرفیت پذیرفته‌شده ۲۴ مورد	Story point فرد پایین آمده پس مشکل سلامت دارد
Unknown	اثر تغییر شیفت هنوز سنجیده نشده	فضای خالی با حدس درباره زندگی شخصی پر شود
Impact	بازبینی Oracle حساس نیازمند نفر دوم است	او خطر برای تیم است

یک سیگنال منفرد برای نتیجه‌گیری کافی نیست. تعداد باگ، velocity، زمان آنلاین، keystroke، دوربین، لحن، sentiment، مرخصی یا حضور در جلسه نباید به «امتیاز سلامت/فرسودگی» تبدیل شود. تفاوت فرهنگی، زبان، معلولیت، مراقبت خانوادگی، نوع قرارداد و دسترسی دیجیتال نیز می‌تواند ظاهر داده را تغییر دهد.

مرحله دو: ریسک‌های طراحی کار را در شش محور بررسی کنید

چارچوب Management Standards مؤسسه HSE شش حوزه را برای ریسک استرس کاری برجسته می‌کند: Demands، Control، Support، Relationships، Role و Change. ما این طبقه‌بندی را برای پرسیدن سؤال‌های کاری اقتباس می‌کنیم؛ استفاده از آن به معنی انطباق با قانون بریتانیا یا ایران نیست.

۱) Demands؛ حجم، ریتم، ساعات و بار هیجانی

• چه مقدار تقاضا در بازه وارد و چه مقدار با ظرفیت/مهارت موجود پذیرفته شد؟
• آیا deadline منبع، دلیل و اختیار تصمیم دارد یا فقط «فوری» نامیده شده است؟
• شیفت، on-call، انتشار شبانه، اضافه‌کاری، تعطیلی و زمان بازیابی چگونه‌اند؟
• کار تکراری، triage تعارض‌آلود، محتوای آزاردهنده یا تعامل با کاربر چه بار ذهنی/هیجانی دارد؟
• چند environment outage، flaky test، انتظار وابستگی و context switch کار را تشدید کرده است؟

۲) Control؛ اختیار واقعی در انجام کار

آیا تستر می‌تواند کار ناایمن را Pause کند، ترتیب اجرا را تغییر دهد، زمان استراحت بگیرد، ابهام را برگرداند، روش دستی/خودکار را پیشنهاد دهد و بدون مجازات از ظرفیت ناکافی بگوید؟ «مالک کیفیت باش» بدون اختیار Scope/Time/Risk، مسئولیت صوری است. اختیار نیز نامحدود نیست؛ مرز تصمیم، escalation و fallback باید مکتوب باشد.

۳) Support؛ منابع، مهارت و حمایت انسانی

حمایت فقط گفتن «هر وقت خواستی صحبت کن» نیست. دسترسی به محیط سالم، داده ساختگی مناسب، Oracle، نیروی جایگزین، buddy review، آموزش در ظرفیت رسمی، مدیر پاسخ‌گو، مسیر تخصصی و زمان پیگیری باید قابل استفاده باشد. پیشنهاد حمایت باید روشن، داوطلبانه، قابل رد و بدون اثر تنبیهی باشد.

۴) Relationships؛ تعارض، احترام و امنیت روانی

سرزنش تستر بابت باگ Production، تمسخر سؤال، حمله در triage، آزار، تبعیض، micromanagement و تلافی را با «مثبت فکر کن» پاسخ ندهید. رخداد، شاهد، اثر و مسیر مجاز را از برداشت درباره نیت جدا کنید. حل اختلاف فنی معمولی با گفت‌وگو ممکن است؛ رویداد Safety یا رفتار ممنوع مسیر رسمی/حمایتی خود را می‌خواهد.

۵) Role؛ انتظار، تعارض نقش و Definition of Done

آیا از QA هم‌زمان انتظار می‌رود همه‌چیز را تست کند، کیفیت را تضمین کند، انتشار را امضا کند، مانع سرعت نشود و بدون اطلاعات تصمیم بگیرد؟ مسئولیت Feature، Risk Acceptance، Severity، Priority، Release و Incident را با صاحب اختیار تفکیک کنید. «QA مالک همه کیفیت است» معمولاً ابهام و تنهایی تصمیم را پنهان می‌کند.

۶) Change؛ تغییر محصول، ابزار، تیم یا قرارداد

مهاجرت ابزار، تعدیل تیم، تغییر مدیر، بازسازمان‌دهی، الزام حضور، تغییر شیفت یا ورود AI می‌تواند ظرفیت و امنیت شغلی ادراک‌شده را عوض کند. تاریخ، دلیل، اثر، افراد متاثر، اطلاعات موجود/ناموجود، فرصت مشارکت، آموزش، دسترسی و مرحله بازبینی را ثبت کنید. خبر دیرهنگام و «خودت تطبیق پیدا کن» کنترل تغییر نیست.

WorkRiskReview:
  demands: {evidence, window, owner, changeable, unknowns}
  control: {decision_rights, pause_right, escalation, gaps}
  support: {resources, backup, learning, offered, accessible}
  relationships: {facts, safety_route, conflict_route, privacy}
  role: {expected_outcome, authority, conflicts, handoffs}
  change: {what, when, impact, consultation, transition}
CrossFactors: recognition, fairness, security, accessibility
Decision: MITIGATE | SUPPORT | REFER | MONITOR | ESCALATE
Never: health_score | personality_score | diagnosis

مرحله سه: خطر عملیاتی امروز را ایمن کنید

پیشگیری بلندمدت مهم است، اما گاهی اولین تصمیم مربوط به امروز است. اگر کاهش توجه یا قضاوت گزارش شده، کارهای برگشت‌ناپذیر و حساس را شناسایی کنید: تأیید Release، تغییر Production، دسترسی امنیتی، بررسی پرداخت، تصمیم انطباقی یا رانندگی پس از شیفت. سپس با رضایت و بدون تحقیر، یکی از کنترل‌های موقت را انتخاب کنید.

• Pause یا جابه‌جایی کار حساس، بدون تبدیل آن به مجازات پنهان؛
• بازبین دوم مستقل با اختیار واقعی و ثبت اختلاف؛
• کاهش Scope، افزایش Time یا Capacity و پذیرش شفاف Risk توسط صاحب اختیار؛
• حذف on-call/اضافه‌کاری و ایجاد فاصله بازیابی؛
• Handoff حالت‌دار شامل build، محیط، داده، شواهد، یافته، مجهول و اقدام بعدی؛
• تعلیق deadline ساختگی یا Expedite بدون دلیل؛
• پشتیبانی فوری محلی در صورت Safety/Health trigger.

کنترل موقت باید Trigger، Scope، Owner، Start، Expiry، Review و معیار خروج داشته باشد. بازتخصیص نامحدود می‌تواند به حذف فرصت، انگ‌زنی یا تبعیض تبدیل شود. تصمیم درباره accommodation یا الزامات استخدامی را نقش واجد صلاحیت و چارچوب محلی می‌گیرد؛ این راهنما مشاوره حقوقی نیست.

مرحله چهار: گفت‌وگوی حمایتی را طراحی کنید

دعوت باید موضوع، هدف، مدت، شرکت‌کنندگان، محرمانگی و امکان همراه/کانال جایگزین را روشن کند. فرد می‌تواند زمان مناسب‌تر، گفت‌وگوی async، همراه مورد اعتماد یا نماینده واجد شرایط را درخواست کند. مدیر باید بگوید چه چیزی محرمانه می‌ماند و کجا به دلیل خطر فوری یا الزام معتبر ممکن است اشتراک حداقلی لازم شود.

دعوت پیشنهادی:
«می‌خواهم درباره شرایط کار در Release-R7 و حمایتی که ممکن است لازم باشد
صحبت کنیم؛ هدف ارزیابی عملکرد یا تشخیص سلامت نیست. ۳۰ دقیقه زمان گذاشته‌ام.
می‌توانی زمان/کانال دیگری یا همراه مجاز پیشنهاد کنی و لازم نیست جزئیات پزشکی
بگویی. فقط اقدام‌های کاری لازم با دسترسی محدود ثبت می‌شود. آیا موافقی؟»

• با مشاهده و اثر شروع کنید: «سه انتشار شبانه و دو لغو استراحت ثبت شده؛ می‌خواهم فشار کار را کم کنیم.»
• یک سؤال خنثی بپرسید: «کدام بخش کار اکنون بیشترین مانع انجام ایمن آن است؟»
• پاسخ را paraphrase کنید و از گوینده تأیید بگیرید؛ تأیید دریافت با موافقت یا تشخیص یکی نیست.
• درباره تغییرات کاری ترجیحی بپرسید؛ فرد مجبور نیست علت بالینی ارائه کند.
• از وعده محرمانگی مطلق، «بین خودمان می‌ماند»، مقایسه با همکار و نصیحت ناخواسته پرهیز کنید.
• پایان جلسه، Action/Owner/Due/Review و حق اصلاح یادداشت را با هم مرور کنید.

مرحله پنج: مداخله سازمانی را اولویت دهید

راهنمای WHO درباره سلامت روان در کار ریسک‌هایی مانند بار و سرعت بیش از حد، کمبود نیرو، ساعات طولانی، اختیار کم، حمایت محدود، رفتار منفی، ابهام نقش و ناامنی شغلی را مطرح می‌کند و مداخله‌های سازمانیِ هدف‌گیرنده شرایط کار را توصیه می‌کند. پس ترتیب سالم از «شرایط را تغییر بده» آغاز می‌شود، نه از «فرد را مقاوم‌تر کن».

کاهش تقاضا و بازگرداندن ظرفیت

• Scope کم‌ارزش یا تکراری را با صاحب Risk حذف یا عقب بیندازید.
• کار واردشونده را از DM و جلسه به Intake واحد منتقل و WIP را محدود کنید.
• برای Release شبانه، incident و on-call ظرفیت و Recovery واقعی رزرو کنید.
• محیط، داده، دسترسی، flaky suite و dependency را به عنوان کار سیستم مالک‌دار رفع کنید.
• کمبود مزمن مهارت/نیرو را با استخدام، جابه‌جایی، pairing یا تغییر تعهد پاسخ دهید، نه overtime پنهان.

تنوع وظیفه بدون انتقال بار

Task Rotation زمانی مفید است که داوطلبانه، مهارت‌محور، دارای آموزش/Shadowing، زمان‌دار و همراه با انتقال مسئولیت قبلی باشد. اضافه‌کردن API Testing، Automation یا Security به همان رگرسیون کامل، تنوع نیست؛ دو شغل روی یک ظرفیت است. ترجیح فرد، دسترسی، مسیر رشد، ریسک مهارت و بازگشت‌پذیری را ثبت کنید.

خودکارسازی به عنوان بازطراحی کار، نه درمان

Automation می‌تواند تکرار کم‌ارزش را کاهش دهد، اما هزینه ساخت، نگهداری، زیرساخت، triage نتایج کاذب و یادگیری دارد. ابتدا هدف، فراوانی، ریسک، پایداری Oracle، داده/محیط، هزینه کل و گزینه جایگزین را بسنجید. به فرد نگویید برای نجات خود در وقت شخصی Selenium یا Playwright یاد بگیرد؛ یادگیریِ لازم برای نقش بخشی از ظرفیت رسمی است.

اختیار، معنا و دیده‌شدن بدون بازی‌سازی کیفیت

پیوند دادن تست به اثر کاربر می‌تواند معنا ایجاد کند، مشروط به آنکه ادعای «تضمین تجربه بی‌نقص» نسازد. تستر را در refinement، risk discovery، exploratory testing و بازبینی تصمیم مشارکت دهید. اثر را با کیفیت شواهد، پرسش‌های آشکارشده و ریسک مدیریت‌شده روایت کنید؛ تعداد باگ، Severity یا سرعت اجرا را به leaderboard و جایزه فردی تبدیل نکنید. این کار پنهان‌کاری، تورم Severity و رقابت ناسالم می‌آورد.

شفاف‌سازی نقش، انصاف و تغییر

• Outcome و مرز اختیار QA، Product، Engineering، Security و Release را مکتوب کنید.
• دسترسی به شیفت مطلوب، آموزش، پروژه جذاب، ارتقا، پاداش و مرخصی را با معیار قابل توضیح بازبینی کنید.
• تغییر ابزار/تیم/سیاست را زود اطلاع دهید و فرصت پرسش و مشارکت واقعی بسازید.
• از فردی که فشار را گزارش کرده فرصت، ownership یا ارتقا را خودکار نگیرید.
• اگر جبران خدمت یا ناامنی قرارداد عامل مهم است، آن را با مراقبت فردی جایگزین نکنید و به صاحب اختیار ارجاع دهید.

مرحله شش: حمایت فردی مکمل و داوطلبانه باشد

استراحت، مرخصی، حرکت، ارتباط اجتماعی، تمرکز دوره‌ای یا مشاوره می‌تواند برای بعضی افراد مفید باشد، اما نیاز و ترجیح یکسان نیست. Pomodoro با ۲۵/۵ قانون پزشکی نیست؛ اگر به عنوان آزمایش تمرکز استفاده می‌شود، دوره/استراحت را فرد انتخاب کند و شمارنده آن KPI نشود. مرخصی نیز بدون کاهش منبع فشار، فقط بازگشت به همان سیستم است.

• گزینه‌ها را پیشنهاد کنید، تجویز نکنید؛ پذیرش/رد را بدون قضاوت ثبت کنید.
• مسیر کمک حرفه‌ای یا برنامه حمایت کارکنان، اگر واقعاً در دسترس است، با دامنه و محرمانگی روشن معرفی شود.
• هزینه، زبان، زمان، مکان، معلولیت، اتصال و امکان استفاده در ساعات کار را در دسترس‌پذیری بسنجید.
• مدیر نقش درمانگر نگیرد و اطلاعات درمان را مطالبه یا راستی‌آزمایی نکند.
• اگر فرد کمک بیرونی را رد کرد، سازمان همچنان مسئول اقدام‌های کاریِ در اختیار خود است.

Accommodation، مرخصی و بازگشت به کار

تطبیق کار ممکن است شامل ساعت منعطف، کاهش موقت Scope، تغییر تکلیف، وقفه بیشتر، دورکاری، همراهی منظم یا ورود مرحله‌ای پس از مرخصی باشد. مناسب‌بودن، مدت، محرمانگی، حقوق و مدارک لازم به زمینه فرد و قواعد محلی وابسته است و باید توسط نقش واجد صلاحیت تعیین شود. همکاران نیاز ندارند علت پزشکی را بدانند؛ تنها تغییر هماهنگی لازم را می‌گیرند.

WorkAdjustment:
  AdjustmentID / Version / Status
  RequestedBy / Consent / QualifiedReviewRoute
  FunctionalNeed (نه تشخیص)
  WorkChange / Start / Review / Expiry
  TasksIncluded / Excluded / Handoff
  Schedule / Location / Access / Breaks
  ManagerOwner / WorkerPreference / Dependencies
  PrivacyNotice / TeamCoordinationMinimum
  SuccessSignals / StopOrAdaptTrigger
  Decision / Reason / AppealOrAlternativeRoute

بازگشت مرحله‌ای، تغییر نقش یا خروج

بازگشت پس از غیبت یک event نیست. ظرفیت آغازین، نوع کار، ساعات، نقاط تماس، محدودیت اطلاعات، مسئول پشتیبان و trigger افزایش/کاهش را توافق کنید. «بازگشته پس آماده ۱۰۰٪ است» فرض نکنید. اگر نقش فعلی قابل اصلاح نیست، انتقال داوطلبانه، تغییر مسئولیت یا گزینه‌های دیگر را بدون فشار بررسی کنید. تصمیم شغلی یا پایان همکاری نیازمند فرایند منصفانه و بررسی واجد صلاحیت است؛ Record حمایتی نباید پوشش یک تصمیم از پیش گرفته‌شده باشد.

مرحله هفت: Action Plan قابل ممیزی بسازید

ActionID: ACT-SYN-07
RiskFactor: DEMAND / NIGHT_RELEASE
EvidenceWindow: 2026-08-01..2026-08-12
Action: دو انتشار شبانه بعدی حذف؛ Scope-R7 به Owner-Risk برگردد
Owner / Authority: Delivery-B / Product-C
Start / Due / Zone: 2026-08-13 / 2026-08-14T12:00:00+03:30
Acceptance: برنامه انتشار اصلاح و on-call جایگزین تأیید شده
WorkerConsentNeeded: YES for schedule-specific arrangement
Dependencies: Support roster, release decision
RiskIfDelayed: ادامه کار حساس بدون بازیابی کافی
Escalation: Delivery-Director
ReviewAt: 2026-08-20T09:00:00+03:30
Result: OPEN
Unknowns: اثر تغییر روی backlog هنوز نامعلوم

اقدام مبهمی مانند «بیشتر مراقب خودت باش» Owner یا acceptance ندارد. اقدام خوب چیزی در کار را تغییر می‌دهد و اثرش قابل مشاهده است. اگر چند اقدام دارید، توالی، وابستگی و اختیار را مشخص کنید. Risk Acceptance باید توسط صاحب ریسک انجام شود، نه تستری که فشار را گزارش کرده است.

سناریو ۱: رگرسیون تکراری و وعده Automation

تیم هر هفته ۱۸۰ سناریوی دستی اجرا می‌کند. پاسخ سطحی، مسابقه «بیشترین باگ» و درخواست یادگیری Cypress در آخر هفته است. پاسخ سیستمی ابتدا ارزش/ریسک سناریوها، تغییرپذیری، نرخ استفاده، Oracle، داده، flaky بودن و زمان نگهداری را بررسی می‌کند؛ موارد کم‌ارزش را حذف، تست اکتشافی را در Scope می‌آورد و یک Automation Pilot را در ظرفیت رسمی می‌گذارد. Rotation فقط با حذف بخشی از بار قبلی انجام می‌شود.

سناریو ۲: انتشارهای شبانه و افت تمرکز

تستر پس از سومین انتشار دیرهنگام می‌گوید در reconciliation تمرکز ندارد. تیم کار حساس را Pause و به دو بازبین منتقل می‌کند، رفت‌وآمد ایمن را در نظر می‌گیرد، شیفت بعدی و on-call را حذف و Recovery را در ظرفیت ثبت می‌کند. سپس الگوی Release، منبع deadline، پوشش نیروی جایگزین و اختیار توقف را اصلاح می‌کند. نتیجه «ضعف فرد» نیست؛ یک کنترل ریسک کاری است.

سناریو ۳: فرسودگی ادعاشده در تیم دورکار

مدیر از خاموش‌بودن دوربین و تأخیر پیام نتیجه می‌گیرد فرد فرسوده است. این استنتاج کنار گذاشته می‌شود. مدیر با دعوت غیرتنبیهی درباره حجم کار، ساعت/منطقه زمانی، accessibility، نقش مراقبتی، انتظار پاسخ و موانع کار سؤال می‌کند. فرد فقط نیاز به بلوک تمرکز و موعدهای روشن را گزارش می‌کند؛ تیم quiet hours، backup فوری و SLA پیام را آزمایش می‌کند. هیچ داده سلامت جمع نمی‌شود.

سناریو ۴: فشار، سرزنش و گزارش محفوظ

پس از یک باگ Production، مدیر در کانال عمومی تستر را تهدید می‌کند و فرد از تلافی می‌ترسد. mediation یا جلسه خصوصی با همان مدیر به عنوان پاسخ پیش‌فرض مناسب نیست. پیام‌ها با دسترسی محدود حفظ، تماس ناخواسته متوقف، مسیر رسمی/حمایتی مستقل و امکان همراه فراهم می‌شود. برنامه حمایت کاری می‌تواند هم‌زمان اجرا شود، اما جای رسیدگی به رفتار و حفاظت را نمی‌گیرد.

مرحله هشت: بازبینی، Recovery و Closure

Review درباره «آیا هنوز فرسوده‌ای؟» نیست. بپرسید آیا اقدام انجام شد، شرایط کاری هدف تغییر کرد، کار حساس اکنون با کنترل کافی انجام می‌شود، مانع جدیدی ایجاد شده و فرد چه ترجیحی برای ادامه دارد. Outcome را با یکی از حالت‌های ADAPTED، CONTINUE، RESTORED، REFERRED، REOPENED، TRANSFERRED یا CLOSED ثبت کنید؛ Closed یعنی تعهدهای این پرونده بسته‌اند، نه اینکه سلامت یا آینده فرد تضمین شده است.

• Delivery: آیا Action واقعاً تحویل شد یا فقط جلسه برگزار شد؟
• Work condition: Demand/Control/Support/Relationship/Role/Change هدف چه تغییری کرد؟
• Safety: کنترل موقت را می‌توان برداشت، باید ادامه داد یا باید تشدید کرد؟
• Recovery: زمان و ظرفیت بازیابی واقعاً بازگردانده شد یا backlog آن را بلعید؟
• Unintended harm: آیا انگ، محرومیت از فرصت، اضافه‌بار همکار یا نقض حریم ایجاد شد؟
• Next decision: Keep، Adapt، Stop، Escalate، Refer یا Reopen با دلیل چیست؟

ReviewRecord:
  ReviewID / SupportRecordID / ActionVersions
  PlannedAt / HeldAt / Participants / Consent
  EvidenceWindow / MissingEvidence
  ActionDelivered / AcceptanceResult
  WorkConditionBefore / WorkConditionAfter
  SafetyControlState / RecoveryCapacityRestored
  WorkerFeedbackConfirmed / PrivacyIssue
  SideEffect / NewRisk / Unknown
  Decision: KEEP|ADAPT|STOP|ESCALATE|REFER|REOPEN|CLOSE
  NextOwner / Due / NextReview
  Correction / Reissue / AffectedRecords

معیارها: سیستم را بسنجید، نه سلامت فرد را

برای یادگیری سازمانی می‌توان داده‌های تجمیعی و حداقلی درباره الگوی کار دید: ساعات اضافه‌کاری، لغو استراحت، فاصله بین شیفت‌ها، WIP/age، وقفه، محیط مسدود، تعارض نقش، دسترسی به حمایت، زمان پاسخ به درخواست و درصد Actionهای بسته‌شده. هر معیار تعریف، پنجره، مخرج، منبع، مالک، محدودیت و حداقل گروه برای گزارش دارد.

• داده فردی سلامت یا self-report را به KPI، رتبه‌بندی، bonus، promotion یا اخراج وصل نکنید.
• نبود گزارش را نشانه نبود ریسک ندانید؛ ترس، دسترسی و اعتماد روی گزارش‌دادن اثر دارد.
• افزایش گزارش پس از ایجاد مسیر امن می‌تواند بهبود دسترسی باشد، نه بدترشدن سلامت.
• میانگین تیم، گروه کوچک یا اقلیت را پنهان می‌کند؛ در عین حال شکستن داده نباید فرد را بازشناسایی کند.
• هم‌بستگی اضافه‌کاری و خطا، علت پزشکی یا نتیجه فردی را اثبات نمی‌کند.
• هدف Measure، اصلاح طراحی کار است؛ نه پیش‌بینی «چه کسی خواهد سوخت».

نقش‌ها و مرز اختیار

نقش	مسئولیت	مرز
Worker/Tester	گزارش اختیاری، ترجیح، بازخورد اقدام، توقف کار ناایمن طبق مسیر	اثبات بیماری یا حل کمبود سازمانی بر عهده او نیست
Line/QA Manager	گوش‌دادن، ایمن‌سازی، اصلاح کار در اختیار، پیگیری	تشخیص، درمان یا وعده محرمانگی مطلق نمی‌دهد
Delivery/Product/Risk Owner	تصمیم Scope/Time/Capacity/Risk و رفع deadline/تعارض	ریسک را به QA تحمیل یا ناشناس نمی‌کند
People/Occupational/Qualified Role	سیاست، accommodation، مسیر تخصصی و قواعد محلی	فقط داده لازم را با مجوز مناسب می‌گیرد
Safety/Formal Route	بحران، تهدید، آزار، تلافی یا نگرانی حفاظت‌شده	با کوچینگ عملکردی ادغام نمی‌شود
Team	پشتیبانی، handoff، بازطراحی workflow و احترام	جزئیات خصوصی فرد را طلب نمی‌کند

آزمایشگاه آفلاین فارسی: دام «Wellness + Pomodoro + Leaderboard»

این آزمایشگاه کاملاً ساختگی و بدون شبکه است. نام شخص، سازمان، پروژه، سلامت، پرداخت یا پول واقعی ندارد. Checkout، PSP Stub و IRR صرفاً داده داستانی‌اند؛ نمایش تومان برچسب نمایشی دارد. ارقام فارسی/عربی/لاتین، ی/ی، ک/ک، نیم‌فاصله، RTL/LTR، UTC، Asia/Tehran و تاریخ جلالیِ صرفاً نمایشی برای تست محلی حضور دارند.

// Node.js 24+ — no network, no package, no real person/work/health data
const fixture = {
  id: "SYN-QA-STRAIN-01", locale: "fa-IR", zone: "Asia/Tehran",
  system: "Fake Checkout / Order / PaymentAttempt / PSP Stub / Callback / Ledger",
  events: ["timeout-before-fake-commit", "timeout-after-fake-commit",
    "retry", "duplicate", "late", "reordered"],
  superficial: ["Wellness webinar", "Pomodoro 25/5", "Bug leaderboard",
    "Learn automation after work", "Motivational one-to-one"],
  money: {canonical: "IRR-FAKE", viewOnly: "تومانِ صرفاً نمایشی"},
  glyphs: ["۱۲۳", "١٢٣", "123", "کیفیت", "كيفيت", "نیم‌فاصله"],
  time: {instant: "2026-08-13T09:00:00Z", local: "Asia/Tehran",
    jalali: "نمایشی/غیرمحاسباتی"},
  realPersonTeamOrgWorkHealthOutcome: false
};

const groups = {
  identity: ["recordId","version","status","openedAt","zone","asOf","owner","purpose","reviewAt","expiry","sourceOfRecord","correctionRoute"],
  scope: ["workContext","release","role","task","window","location","schedule","contractContext","accessNeeds","language","inScope","outOfScope","unknowns"],
  consent: ["notice","purposeNotice","dataNotice","participantChoice","channelChoice","supportPerson","decline","withdraw","pause","recordingConsent","sharingConsent","correctionRight","retentionNotice"],
  privacy: ["dataMinimum","healthDataExcluded","diagnosisExcluded","jiraExcluded","dashboardExcluded","accessRoles","accessReason","recipientLog","secureStore","retentionStart","deleteAt","derivativeDeletion","breachRoute"],
  signal: ["selfReport","speakerConfirmed","observation","workData","source","timestamp","window","fact","inference","unknown","alternativeExplanation","impact","confidenceLimit","noBodyLanguageOracle","noSentimentOracle"],
  distinction: ["boredom","fatigue","workStress","burnoutScope","medicalBoundary","crisisBoundary","noSingleSignalDiagnosis","occupationalContext","durationUnknown","individualVariation","cultureContext","disabilityContext"],
  safety: ["urgentTrigger","localRoute","qualifiedOwner","stopSensitiveWork","doNotLeaveIfSafeAccepted","secondReview","handoff","transportRisk","threatRoute","harassmentRoute","retaliationRoute","protectedConcernRoute","privacyLimit","safetyReview","controlExpiry"],
  demands: ["arrivalRate","acceptedDemand","capacityRange","scope","pace","deadlineSource","deadlineReason","decisionAuthority","hours","shift","onCall","overtime","breaks","recovery","emotionalLoad","repetition","interruptions","blockedTime","environment","dependency"],
  control: ["decisionRights","sequenceChoice","methodChoice","pauseRight","breakRight","clarifyRight","declineUnsafe","riskEscalation","workerInput","flexibility","boundary","fallback"],
  support: ["manager","peer","backup","staffing","skills","learningTime","environmentResource","dataResource","oracleResource","toolResource","professionalRoute","accessibility","offer","acceptOrDecline"],
  relationships: ["respect","conflict","publicBlame","bullying","harassment","discrimination","violence","retaliation","psychologicalSafety","formalRoute","mediationBoundary","factsNotIntent","repair"],
  role: ["expectedOutcome","qaAuthority","productAuthority","releaseAuthority","riskAuthority","severityAuthority","priorityAuthority","conflictingExpectations","handoffBoundary","definitionOfDone","escalation","roleReview"],
  change: ["changeType","reason","noticeTime","affectedPeople","knownImpact","unknownImpact","consultation","participation","training","transitionCapacity","accessChange","jobSecuritySignal","review"],
  immediate: ["trigger","taskRisk","reversibility","productionImpact","securityImpact","financialImpact","complianceImpact","decision","owner","start","expiry","acceptance","workerConsent","noPenalty","reallocationFairness"],
  conversation: ["topic","purpose","duration","participants","facilitator","invitation","privacyBoundary","openingObservation","neutralQuestion","oneQuestion","listen","paraphrase","speakerConfirm","silence","noIntentClaim","noAdviceWithoutAsk","noComparison","actionSummary","followUp"],
  redesign: ["organizationalFirst","removeDemand","reduceScope","increaseTime","increaseCapacity","limitWip","fixEnvironment","fixDependency","restoreRecovery","rotationConsent","rotationTraining","removeOldLoad","automationTco","automationPilot","learningInCapacity","roleClarity","changeParticipation","fairAccess","recognitionNotScoring","noBugLeaderboard"],
  supportPlan: ["voluntary","optionSet","preference","access","cost","language","timeAccess","locationAccess","disabilityAccess","professionalSupport","managerNotClinician","noTreatmentData","declineNoPenalty","workActionContinues"],
  adjustment: ["adjustmentId","functionalNeed","qualifiedReview","workChange","start","review","expiry","includedTasks","excludedTasks","schedule","location","breaks","handoff","teamMinimumInfo","appeal","alternative"],
  action: ["actionId","riskFactor","evidenceWindow","actionText","owner","authority","start","due","ianaZone","dependency","acceptance","riskIfDelayed","escalation","result","unknown","dissent"],
  review: ["reviewId","plannedAt","heldAt","evidenceWindow","actionDelivered","acceptanceResult","conditionBefore","conditionAfter","safetyState","recoveryRestored","workerFeedback","feedbackConfirmed","sideEffect","newRisk","privacyIssue","decision","nextOwner","nextDue","reopen","correction","reissue","affectedRecords"],
  measures: ["systemMeasureOnly","definition","window","denominator","source","owner","limitation","minimumGroup","aggregation","reidentificationCheck","reportingAccess","overtime","cancelledBreak","shiftGap","wipAge","interruptions","blockedWork","roleConflict","supportLatency","actionClosure","noHealthScore","noIndividualRanking","noPrediction"],
  recovery: ["capacityRestored","leaveProtected","handoffComplete","phasedReturn","startingCapacity","taskMix","contactPoint","increaseTrigger","decreaseTrigger","noHundredPercentAssumption","transferChoice","exitFairProcess","closureMeaning","futureNotGuaranteed"],
  limits: ["notDiagnosis","notTreatment","notLegalAdvice","notComplianceProof","notPreventionProof","notSafetyProof","notQualityProof","notProductivityProof","notTrustProof","notWorkerFitnessProof","notCausalityProof","notUniversalLaw","localReviewRequired","noRealTarget"]
};

const required = Object.entries(groups).flatMap(([g, xs]) => xs.map(x => `${g}.${x}`));
const supplied = new Set(fixture.controls || []);
const missing = required.filter(x => !supplied.has(x));
const superficial = fixture.superficial.length === 5
  ? "BURNOUT_PREVENTED_TEAM_MOTIVATED" : "INCOMPLETE";
console.log(superficial);                 // ادعای غلطِ کنترل سطحی
console.log(`HOLD-${missing.length}`);    // باید HOLD بماند
console.log(new Set(required).size === required.length ? "UNIQUE" : "DUPLICATE");
console.log(fixture.realPersonTeamOrgWorkHealthOutcome === false
  ? "NO_REAL_TARGET_PASS" : "STOP_REAL_TARGET");

// فقط پس از تکمیل همه فیلدهای ساختگی:
fixture.controls = [...required];
const remaining = required.filter(x => !new Set(fixture.controls).has(x));
console.log(remaining.length === 0
  ? "READY_FOR_QA_WORK_STRAIN_SUPPORT_REVIEW-0" : `HOLD-${remaining.length}`);

کنترل سطحی از پنج آیتم جذاب نتیجه غلط BURNOUT_PREVENTED_TEAM_MOTIVATED می‌سازد. ممیزی مستقل باید صدها کنترل یکتای گروه‌بندی‌شده را غایب ببیند و HOLD بدهد؛ قانون مستقل نیز نبود هر فرد، تیم، سازمان، کار، سلامت یا نتیجه واقعی را بررسی می‌کند. حتی خروجی نهایی READY_FOR_QA_WORK_STRAIN_SUPPORT_REVIEW-0 فقط آمادگی داده ساختگی برای Review است، نه اثبات سلامت، ایمنی، کیفیت، بهره‌وری یا پیشگیری از فرسودگی.

ضدالگوهایی که باید حذف شوند

• «همه خسته‌اند؛ تحمل کن» یا عادی‌سازی اضافه‌کاری مزمن؛
• تشخیص فرسودگی از دوربین، لحن، مرخصی، سرعت پاسخ یا تعداد باگ؛
• Wellness webinar، یوگا، هدیه یا پیتزا بدون تغییر شرایط کار؛
• اجباری‌کردن افشای تشخیص، دارو یا پرونده درمان برای شنیده‌شدن؛
• گیمیفیکیشن باگ، leaderboard و پاداش Severity؛
• یادگیری Automation در وقت شخصی به عنوان راه نجات؛
• Rotation همراه با حفظ کامل وظایف قبلی؛
• مرخصی بدون plan بازگشت و بدون رفع منبع فشار؛
• انتقال خودکار فردِ گزارش‌دهنده از کار مهم یا مسیر ارتقا؛
• ثبت داده سلامت در Jira، Slack، TestRail یا dashboard عمومی؛
• قول محرمانگی مطلق یا اشتراک بی‌خبر؛
• مقایسه «فلانی با همین بار مشکلی ندارد»؛
• یکی‌گرفتن fatigue، boredom، burnout و depression؛
• استفاده از فرم برای تشخیص یا fitness-for-work؛
• جلسه خصوصی اجباری با فرد متهم به آزار؛
• mediation برای تهدید، تبعیض یا گزارش حفاظت‌شده بدون Safety screen؛
• پرسش‌های پیاپی، advice ناخواسته و praise sandwich؛
• تبدیل سکوت یا رد کمک بیرونی به عدم همکاری؛
• پذیرش Risk توسط تستر بدون اختیار Scope/Time/Capacity؛
• بستن پرونده چون جلسه برگزار یا لینک مشاوره ارسال شد؛
• سنجش موفقیت با کاهش تعداد گزارش‌ها؛
• پیش‌بینی فرسودگی فرد با AI، sentiment یا surveillance؛
• حذف جزئیات از میانگین تا مسئله اقلیت ناپدید شود؛
• گروه‌بندی ریز که فرد را دوباره قابل شناسایی کند؛
• ادعای انطباق قانون ایران یا کشور دیگر از روی این راهنما؛
• ادعای تضمین انگیزه، ماندگاری، کیفیت یا سلامت.

چک‌لیست مالک پرونده حمایت کاری QA

• شناسه، نسخه، وضعیت، زمان، هدف و بازبینی ثبت شده است.
• فرد اعلان حریم، حدود محرمانگی و حق اصلاح را فهمیده است.
• داده پزشکی غیرضروری جمع نشده و Record از ابزار کار جداست.
• Self-report، Observation، Work data، Inference و Unknown جدا هستند.
• هیچ تشخیص، امتیاز سلامت، personality یا sentiment وجود ندارد.
• Safety/Health/Formal trigger و مسیر محلی بررسی شده است.
• کار حساس موقتاً کنترل و Control دارای expiry است.
• Demands با عدد/بازه/منبع و ساعات/بازیابی بررسی شده است.
• Control واقعی و حق Pause/Escalate روشن است.
• Support قابل استفاده، داوطلبانه و دسترس‌پذیر است.
• Relationship risk از اختلاف فنی جدا شده است.
• Role و صاحبان Severity/Priority/Release/Risk مبهم نیستند.
• Change، اطلاع، مشارکت و ظرفیت انتقال بررسی شده است.
• مداخله سازمانی پیش از توصیه فردی انتخاب شده است.
• Rotation بار قبلی را حذف و رضایت/آموزش دارد.
• Automation با TCO و Pilot سنجیده و یادگیری در ظرفیت است.
• هیچ bug leaderboard یا رقابت سلامت وجود ندارد.
• Action، Owner، Authority، Due/Zone و Acceptance دارد.
• Risk تأخیر، Dependency، Escalation، Dissent و Unknown محفوظ است.
• Accommodation/مرخصی/بازگشت توسط مسیر واجد صلاحیت بررسی می‌شود.
• تیم فقط حداقل اطلاعات هماهنگی را دریافت می‌کند.
• معیارها سیستم‌محور، دارای مخرج/پنجره و ضد بازشناسایی‌اند.
• Review، Delivery را از جلسه و Work condition را از سلامت جدا می‌کند.
• Recovery واقعاً به ظرفیت برگردانده شده است.
• اثر جانبی، محرومیت از فرصت، انگ و اضافه‌بار همکار بررسی شده است.
• Keep/Adapt/Stop/Escalate/Refer/Reopen/Close با دلیل ثبت شده است.
• Correction/Reissue/Affected records و حذف زمان‌دار فعال‌اند.
• خروجی به عنوان اثبات پیشگیری، fitness، کیفیت یا انطباق معرفی نشده است.

Pilot سی‌روزه بدون داده سلامت واقعی

برای شروع، از داده‌های ساختگی و یک جریان غیرحساس استفاده کنید. هفته اول واژگان، نقش‌ها، Privacy/Safety route و فرم‌ها را tabletop کنید. هفته دوم سناریوهای رگرسیون تکراری، انتشار شبانه، تعارض نقش و تغییر ابزار را اجرا کنید. هفته سوم Action/Adjustment/Review و خطاهای دسترسی/حذف را بیازمایید. هفته چهارم یافته‌ها را در Retrospective به آزمایش بهبود تبدیل کنید.

• روز ۱–۵: Stop rule، مسیر محلی کمک، نقش واجد صلاحیت و حداقل داده را تأیید کنید.
• روز ۶–۱۰: Record را با alias و رویدادهای خیالی پر و دسترسی/اصلاح/حذف را تست کنید.
• روز ۱۱–۱۵: شش محور طراحی کار و کنترل فوری را با اختلاف نظر اجرا کنید.
• روز ۱۶–۲۰: دعوت، همراه، کانال، decline، privacy boundary و action closure را تمرین کنید.
• روز ۲۱–۲۵: phased return و workload redesign را بدون تشخیص یا فرد واقعی شبیه‌سازی کنید.
• روز ۲۶–۳۰: validator، anti-pattern، accessibility، re-identification و not-proof را ممیزی کنید.

جمع‌بندی

پیشگیری از فرسودگی شغلی تستر با انگیزه‌دادن به فرد یا سریع‌ترکردن اجرای تست آغاز نمی‌شود. از شنیدن بدون تشخیص، ایمن‌کردن کار، دیدن طراحی واقعی کار و تغییر شرایط قابل کنترل آغاز می‌شود. Record پیشنهادی کمک می‌کند ادعا از مشاهده، حمایت از ارزیابی عملکرد، اقدام سازمانی از خودمراقبتی، و Closure اداری از سلامت واقعی جدا بماند.

قاعده عملی ساده است: اگر سیستم تقاضا، اختیار، حمایت، رابطه، نقش یا تغییر مسئله دارد، سیستم باید تغییر کند. فرد می‌تواند در تصمیم مشارکت کند و حمایت بگیرد، اما نباید هزینه پنهان یک برنامه غیرواقعی را با سلامت، وقت شخصی یا سکوت خود بپردازد.

سؤالات متداول درباره فرسودگی شغلی در QA

آیا مدیر می‌تواند تشخیص دهد تستر دچار فرسودگی شغلی شده است؟

خیر. مدیر می‌تواند گزارش فرد و شرایط قابل مشاهده کار را جدی بگیرد، خطر فوری را ایمن کند و ریسک‌های طراحی کار را اصلاح کند؛ اما این فرم و گفت‌وگو ابزار تشخیص پزشکی نیست. در صورت نیاز یا درخواست فرد، مسیر کمک حرفه‌ای معتبر و محلی باید فراهم شود.

آیا تست رگرسیون تکراری به‌تنهایی باعث Burnout می‌شود؟

نمی‌توان از یک عامل برای یک فرد نتیجه قطعی گرفت. تکرار و استفاده‌نشدن از مهارت ممکن است به فشار یا کم‌درگیری کمک کند، اما حجم و ساعات، اختیار، حمایت، روابط، نقش و تغییر نیز مهم‌اند. با مشاهده، self-report و زمینه کار تصمیم بگیرید و مجهول‌ها را مجهول نگه دارید.

بهترین اقدام فوری وقتی تستر می‌گوید تمرکز ندارد چیست؟

ابتدا خطر کار جاری را بسنجید. کار حساس یا برگشت‌ناپذیر را Pause، بازتخصیص یا دو-نفره کنید؛ استراحت/بازیابی و handoff امن بدهید؛ سپس علت‌های کاری و مسیر حمایت را بررسی کنید. گزارش خستگی نباید به تنبیه، رتبه منفی یا درخواست جزئیات پزشکی تبدیل شود.

آیا Pomodoro، مرخصی یا Automation از فرسودگی جلوگیری می‌کند؟

هیچ‌کدام تضمین نیست. Pomodoro یک ترجیح احتمالی تمرکز است؛ مرخصی بدون اصلاح منبع فشار پایدار نیست؛ و Automation هزینه و ریسک نگهداری دارد. این گزینه‌ها ممکن است بخشی از برنامه باشند، اما باید در کنار کاهش تقاضا، ظرفیت واقعی، اختیار، حمایت و Recovery قرار گیرند.

در تیم ایرانی چه اطلاعاتی درباره سلامت تستر ثبت کنیم؟

فقط حداقل اطلاعات لازم برای تصمیم کاری: محدودیت عملکردیِ بیان‌شده، تغییر کار، رضایت، مالک، موعد و بازبینی. تشخیص، دارو یا یادداشت درمان را در ابزارهای QA و مدیریت کار ثبت نکنید. الزامات دقیق استخدامی، حریم خصوصی، اورژانس و نگهداشت را نقش حقوقی/سلامت شغلی واجد صلاحیت بر اساس محل و وضعیت جاری تعیین کند.