اخلاق در تست نرم‌افزار؛ ۸ دوراهی و چارچوب تصمیم

فرض کنید چند ساعت مانده به کمپین، تست نشان می‌دهد Callback یکی از درگاه‌های پرداخت گاهی دوبار پردازش می‌شود. مدیر محصول می‌گوید «احتمالش کم است؛ فعلاً در گزارش نیاورید». آیا وظیفه QA متوقف‌کردن انتشار است؟ آیا باید موضوع را بیرون از شرکت گزارش کند؟ یا کافی است باگ را ثبت کند و کنار برود؟ پاسخ حرفه‌ای هیچ‌کدام از این نسخه‌های مطلق نیست.

اخلاق در تست نرم‌افزار یعنی مشاهده را تحریف نکنیم، اثر تصمیم بر افراد را ببینیم، محرمانگی و حدود اختیار را رعایت کنیم و ریسک مادی را به مالک درست برسانیم. این مقاله هشت دوراهی رایج، چارچوب تصمیم‌گیری، مسیر Escalation، کارت ثبت نگرانی و مثال‌های بومی برای تیم‌های QA ایرانی را ارائه می‌کند.

اصل راهنما: تستر نه «پلیس اخلاق» سازمان است و نه فقط مجری Acceptance Criteria. مسئولیت کیفیت و اثر محصول مشترک است؛ مسئولیت ویژه QA، تولید شواهد درست، بیان محدودیت‌ها، هشدار درباره آسیب معقول و خودداری از تأیید چیزی است که شواهد آن را پشتیبانی نمی‌کند.

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

اخلاق حرفه‌ای QA با قانون و سلیقه چه تفاوتی دارد؟

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

راهنمای رسمی آموزش مهندسی نرم‌افزار ACM با ارجاع به کد مشترک IEEE-CS/ACM یادآور می‌شود که متخصصان نرم‌افزار امکان ایجاد فایده یا آسیب دارند. آن کد، تعهدهای حرفه‌ای را در هشت حوزه عمومی، کارفرما و مشتری، محصول، قضاوت، مدیریت، حرفه، همکاران و خود فرد دسته‌بندی می‌کند. کدهای حرفه‌ای منبع قضاوت‌اند؛ جای قانون محلی، قرارداد یا تصمیم‌گیر مجاز را نمی‌گیرند.

سه پرسش برای تشخیص مسئله اخلاقی

1. چه کسی ممکن است آسیب ببیند؟ کاربر، فرد غیراستفاده‌کننده، همکار، فروشنده، جامعه یا محیط.
2. کدام حق، تعهد یا انتظار مشروع در خطر است؟ ایمنی، حریم خصوصی، انصاف، دسترس‌پذیری، صداقت یا محرمانگی.
3. آیا اطلاعات مادی پنهان، دست‌کاری یا بدون مجوز استفاده می‌شود؟ اگر بله، موضوع فراتر از اختلاف سلیقه است.

هر باگ یک تخلف اخلاقی نیست

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

تقسیم مسئولیت: چه کسی چه تصمیمی می‌گیرد؟

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

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

در تیم‌های کوچک ممکن است یک نفر چند کلاه داشته باشد؛ در این حالت، تعارض نقش را در Decision Record بنویسید و برای ریسک‌های مادی یک بازبین دوم بگیرید. مقاله نقش SDET و مالکیت مشترک کیفیت مرز تخصص تست با مسئولیت کل تیم را دقیق‌تر توضیح می‌دهد.

هشت دوراهی اخلاقی رایج در تست نرم‌افزار

۱. فشار برای انتشار با ریسک شناخته‌شده

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

گزینه‌ها فقط Fix یا Release نیستند: غیرفعال‌کردن Feature، حذف یک PSP از مسیر، Canary، محدودیت تراکنش، مانیتورینگ ویژه، Rollback آماده یا تأخیر بخشی از کمپین می‌توانند ریسک را تغییر دهند. برای ساخت شواهد اولویت، از تست مبتنی بر ریسک و برای ثبت توصیه و تصمیم از قالب گزارش اختتامیه تست استفاده کنید.

۲. دست‌کاری نتیجه، پوشش یا شدت باگ

تغییر نتیجه Fail به Pass، حذف شکست از مخرج، پایین‌آوردن شدت برای سبزشدن داشبورد یا بازاجرای انتخابی تا رسیدن به نتیجه مطلوب، مسئله اخلاقی و حاکمیتی است. اختلاف فنی درباره Severity طبیعی است؛ تحریف مشاهده یا پاک‌کردن تاریخچه طبیعی نیست.

• Observation، Expected Result، Business Impact و Priority را از هم جدا کنید.
• تغییر Severity را با نام تصمیم‌گیر، دلیل و زمان ثبت کنید.
• Flaky Test را با وضعیت Quarantined، مالک و تاریخ انقضا نگه دارید؛ آن را بی‌صدا حذف نکنید.
• Pass Rate را با مخرج روشن و وضعیت‌های Blocked، Skipped، Not Run و Inconclusive گزارش کنید.
• اگر KPI فردی انگیزه تحریف می‌سازد، خود KPI را بازطراحی کنید.

۳. استفاده از داده واقعی و افشای اطلاعات حساس

در دسترس بودن Backup تولید، مجوز استفاده از آن در لپ‌تاپ، محیط تست یا ابزار AI نیست. کد ملی، شماره موبایل، نشانی، توکن، متن تیکت، تصویر مدرک و شناسه پرداخت ممکن است در Log، Screenshot، Fixture، Artifact یا Prompt نشت کنند.

Privacy Framework مؤسسه NIST حریم خصوصی را به‌صورت مدیریت ریسک برای افراد و سازمان می‌بیند، نه فقط امنیت داده. پیش‌فرض عملی باید کمینه‌سازی و ساخت داده متناسب با هدف باشد. اگر داده تولید لازم است، مجوز، هدف، دامنه، روش Masking، دسترسی، نگهداشت و حذف قابل‌اثبات را ثبت کنید. Pseudonymization را با Anonymization یکی نگیرید؛ راهنمای داده تست واقعی یا مصنوعی این مرزها را با جزئیات پوشش می‌دهد.

۴. کشف آسیب‌پذیری و افشای مسئولانه

وجود یک Endpoint عمومی به معنی مجوز آزمون نامحدود نیست. Scope، Rules of Engagement و محیط مجاز را پیش از تست امنیتی مشخص کنید. پس از کشف، فقط تا حد لازم برای اثبات و اولویت ادامه دهید؛ Secret یا داده قربانی را در Ticket عمومی نگذارید و با اقدام نمایشی دامنه آسیب را بیشتر نکنید.

سازمان باید کانال امن دریافت، شناسه پیگیری، مالک پاسخ، زمان‌بندی و فرایند افشای هماهنگ داشته باشد. راهنمای Vulnerability Disclosure مرکز CERT/CC هماهنگی میان ذی‌نفعان، اصلاح آسیب‌پذیری و رساندن اطلاعات درست به عموم را هدف می‌گیرد؛ این راهنما قانون عمومی ایران نیست، اما ارزش یک مسیر رسمی را خوب نشان می‌دهد. چارچوب NIST SSDF 1.1 نیز مدیریت آسیب‌پذیری را در چرخه توسعه امن قرار می‌دهد.

۵. Dark Pattern، رضایت ظاهری و طراحی فریبنده

ممکن است Feature دقیقاً مطابق Acceptance Criteria کار کند اما انتخاب کاربر را منحرف کند: هزینه در مرحله آخر ظاهر شود، دکمه لغو پنهان باشد، Countdown جعلی نمایش داده شود، رضایت از پیش فعال باشد یا مسیر عضویت یک کلیک و خروج چندین تماس بخواهد. QA نباید صرفاً به دلیل «در Requirement بوده» اثر قابل‌پیش‌بینی را نادیده بگیرد.

مشاهده را بی‌طرف ثبت کنید: متن، ترتیب، Default، تعداد گام، امکان بازگشت، گروه آسیب‌پذیر و تفاوت مسیر قبول/رد. سپس از محصول، طراحی و حقوقی بخواهید هدف و مبنای تصمیم را روشن کنند. تشخیص قانونی Dark Pattern به حوزه قضایی بستگی دارد؛ تستر باید شواهد رفتاری بسازد، نه حکم حقوقی صادر کند.

۶. دسترس‌پذیری و حذف ناخواسته کاربران

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

WCAG ۲.۲ کنسرسیوم W3C معیارهای قابل‌آزمون و مستقل از فناوری ارائه می‌کند، اما خودش می‌گوید همه نیازهای افراد دارای معلولیت را پوشش نمی‌دهد و ارزیابی ترکیبی خودکار و انسانی لازم است. پس «اسکنر صفر خطا» با «محصول عادلانه و دسترس‌پذیر» برابر نیست. برای اجرای ابزار و صفحه‌خوان، راهنمای ابزارهای تست دسترس‌پذیری مکمل این بحث است.

۷. سوگیری و آسیب در سیستم‌های داده‌محور و AI

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

NIST AI RMF 1.0 یک چارچوب داوطلبانه و زمینه‌محور با چهار تابع Govern، Map، Measure و Manage است و در کنار اعتبار و ایمنی، شفافیت، حریم خصوصی و مدیریت سوگیری زیان‌بار را مطرح می‌کند. برای QA این یعنی:

• هدف تصمیم، افراد متأثر و هزینه انواع خطا را پیش از Metric مشخص کند؛
• کامل‌بودن، منشأ و نمایندگی داده ارزیابی شود؛
• نتیجه کلی و زیرگروه‌های مرتبط، همراه با عدم‌قطعیت، گزارش شود؛
• Human Oversight، اعتراض، Override و بازیابی تعریف شود؛
• رفتار پس از استقرار، Drift و سوءاستفاده پایش شود.

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

۸. رخداد تولید: یادگیری بدون پنهان‌کردن مسئولیت

پس از رخداد، پرسش «چه کسی این باگ را جا انداخت؟» معمولاً تیم را به پنهان‌کاری هل می‌دهد. پرسش بهتر این است که چه شرایطی اجازه داد خطر ایجاد، عبور و دیر کشف شود: ابهام Requirement، فشار KPI، نبود مشاهده‌پذیری، Fixture غیرواقعی، اختیار نامشخص یا تصمیم ثبت‌نشده.

راهنمای Postmortem بدون سرزنش Google SRE بر علت‌های مشارکت‌کننده و اقدام سیستمی تأکید دارد. «بدون سرزنش» به معنی نبود پاسخ‌گویی نیست: تصمیم، کنترل و اقدام اصلاحی باید مالک و موعد داشته باشند. همچنین خطای انسانی با جعل عمدی مدرک، دسترسی غیرمجاز یا رفتار آگاهانه پرخطر یکسان نیست و ممکن است مسیر بررسی جداگانه بخواهد.

چارچوب تصمیم‌گیری: مشاهده تا پیگیری

این چارچوب هشت‌مرحله‌ای برای Incident فوری طراحی نشده است؛ در خطر جانی، افشای فعال یا حمله، Playbook اضطراری و اختیارات Containment مقدم‌اند.

مرحله ۱: مشاهده را از تفسیر جدا کنید

بنویسید دقیقاً چه دیدید، در کدام Build، محیط، داده و زمان؛ چه چیزی تکرار شد و چه چیزی هنوز فرض است. «تیم محصول کاربران را فریب می‌دهد» اتهام است؛ «هزینه ارسال فقط پس از ثبت شماره تماس ظاهر می‌شود و بازگشت، داده را نگه می‌دارد» مشاهده آزمون‌پذیر است.

مرحله ۲: افراد و اثر را نقشه‌برداری کنید

کاربر مستقیم تنها ذی‌نفع نیست. گیرنده پیامک، فروشنده، پیک، کارمند پشتیبانی، کودک، فرد دارای معلولیت یا کسی که داده او توسط دیگری وارد شده نیز ممکن است متأثر باشد. شدت، برگشت‌پذیری، مقیاس، مدت و توزیع نابرابر اثر را بنویسید.

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

قانون قابل‌اعمال، قرارداد، سیاست داده، SLO، استاندارد ایمنی، Code of Conduct و وعده عمومی محصول را از مالک معتبر بگیرید. ماتریس احتمال×اثر نمی‌تواند یک منع صریح یا حق غیرقابل‌واگذاری را «کم‌ریسک» اعلام کند.

مرحله ۴: عدم‌قطعیت و تعارض منافع را آشکار کنید

چه داده‌ای ندارید؟ چه کسی از انتشار یا توقف سود و زیان می‌بیند؟ آیا ارزیاب همان سازنده کنترل است؟ آیا پاداش تیم به Deadline وابسته است؟ تعارض منافع الزاماً تخلف نیست، اما به بازبینی مستقل نیاز دارد.

مرحله ۵: چند گزینه متناسب و برگشت‌پذیر بسازید

Fix کامل تنها گزینه نیست. محدودکردن دامنه، Feature Flag، کاهش سقف، رضایت دوباره، حذف داده، بازبینی انسانی، Canary یا توقف موقت می‌تواند آسیب را کم کند. هزینه و آسیب هر گزینه—از جمله «هیچ کاری نکن»—را مقایسه کنید.

مرحله ۶: تصمیم‌گیر و حد اختیار را مشخص کنید

چه کسی می‌تواند ریسک محصول را قبول کند؟ کدام موارد باید به امنیت، حریم خصوصی، حقوقی یا مدیر ارشد برود؟ فردی که Deadline را تعیین کرده لزوماً اختیار پذیرش هر نوع ریسک را ندارد. اگر ماتریس اختیار وجود ندارد، خود این خلأ یک اقدام اصلاحی است.

مرحله ۷: تصمیم، مخالفت و شرط‌ها را ثبت کنید

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

مرحله ۸: نتیجه را پایش و فرض‌ها را اصلاح کنید

اگر انتشار مشروط بود، Guardrail و Stop Condition را مانیتور کنید. اگر فرض احتمال یا اثر غلط بود، Risk Register را اصلاح کنید. اقدام بدون مالک، موعد و شاهد تکمیل، فقط یک وعده است.

سطح‌بندی نگرانی اخلاقی و اقدام اولیه

سطح	نمونه	اقدام اولیه
فوری و فعال	افشای جاری داده، خطر ایمنی، تراکنش زیان‌بار در حال وقوع	Incident channel و Containment در حدود اختیار؛ حفظ حداقلی شواهد
مادی یا خط قرمز	نقض کنترل مصوب، دست‌کاری گزارش، حذف یک گروه از خدمت ضروری	توقف تصمیم عادی، ارجاع به مالک تخصصی و ثبت مستقل
مهم اما قابل‌کنترل	ریسک انتشار با Feature Flag و Rollback قابل‌مدیریت	گزینه‌های کاهش، مالک ریسک، شرط و انقضای پذیرش
نامطمئن	نشانه اولیه سوگیری با Sample کوچک	آزمون محدود، بازبین مستقل و تصمیم موقت برگشت‌پذیر
ترجیح طراحی	اختلاف کم‌اثر در متن یا چیدمان	Backlog و تریاژ معمول؛ برچسب اخلاقی نزنید

این جدول جای قضاوت تخصصی را نمی‌گیرد. شدت اقتصادی پایین ممکن است با اثر شدید بر یک گروه کم‌تعداد همراه باشد؛ شمار کاربران تنها معیار اهمیت نیست.

کارت ثبت نگرانی اخلاقی؛ قالب آماده

Ethics Concern ID:
تاریخ / گزارش‌دهنده / سطح محرمانگی:

مشاهده قابل‌بازتولید:
فرض‌ها و موارد نامعلوم:
Build / محیط / داده / دامنه آزمون:

افراد یا گروه‌های متأثر:
نوع اثر، شدت، مقیاس، برگشت‌پذیری و فوریت:
تعهد یا سیاست مرتبط و مالک تفسیر:

گزینه‌ها، هزینه و ریسک هر گزینه:
توصیه QA و درجه اطمینان:
تصمیم‌گیر مجاز و مهلت تصمیم:

تصمیم، شرط‌ها و مخالفت ثبت‌شده:
Guardrail / Stop Condition / تاریخ بازبینی:
مالک اقدام و شاهد تکمیل:

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

مثال ایرانی: انتشار Callback پرداخت پیش از کمپین

این سناریو فرضی است. در Build شماره ۴۲۱، پس از Timeout و Callback تکراری PSP-B، دو مورد از ۵۰ اجرای کنترل‌شده باعث ثبت دوباره اعتبار کیف پول شده است. فقط محیط تست و یک الگوی Timeout بررسی شده؛ نرخ واقعی تولید نامعلوم است. PSP-B حدود ۱۲٪ ترافیک عادی را می‌گیرد و کمپین فردا آغاز می‌شود.

گزارش ضعیف

«سیستم پرداخت ناامن است؛ QA انتشار را رد کرد.» این جمله مشاهده، دامنه، عدم‌قطعیت، گزینه و اختیار را مخلوط می‌کند.

گزارش تصمیم‌پذیر

• مشاهده: دوباره‌اعتبار در ۲/۵۰ اجرای سناریوی Timeout+Callback تکراری؛ Log و Run ID پیوست محدود.
• اثر: زیان مالی، مغایرت حسابداری و احتمال سوءاستفاده؛ نرخ تولید نامعلوم.
• شکاف: Retry شبکه واقعی، PSPهای دیگر و بازپرداخت جزئی هنوز ارزیابی نشده‌اند.
• گزینه A: تأخیر سه‌روزه و اصلاح Idempotency.
• گزینه B: خارج‌کردن PSP-B با Feature Flag، مانیتور مغایرت و بازبینی پس از اصلاح.
• گزینه C: انتشار کامل؛ بیشترین ریسک و بدون کنترل جبرانی کافی.
• توصیه QA: No-Go برای گزینه C؛ انتشار مشروط فقط با B، Rollback آزموده و مالک عملیات.
• تصمیم: مالک محصول و عملیات در محدوده اختیار مالی؛ امنیت/مالی برای کنترل و سقف ریسک.

اگر مدیریت گزینه C را انتخاب کرد، QA نباید نتیجه را «بدون ریسک» یا «تأیید کامل» بنویسد. تصمیم، مخالفت حرفه‌ای، شرط‌ها و مالک پذیرش باید باقی بماند.

Escalation حرفه‌ای؛ از گفت‌وگو تا مسیر مستقل

سطح ۱: حل مستقیم و مستند

با مالک Requirement یا تصمیم، بر پایه مشاهده و اثر صحبت کنید. اتهام اخلاقی معمولاً مقاومت می‌سازد؛ زبان Evidence و گزینه‌ها امکان اصلاح می‌دهد.

سطح ۲: مالک تخصصی یا مسیر مستقل داخلی

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

سطح ۳: مشاوره مستقل و گزارش بیرونی

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

اگر از شما خواستند گزارش را حذف کنید چه بگویید؟

«در Build و محیط ثبت‌شده، این رفتار را با شواهد پیوست مشاهده کرده‌ام. دامنه و عدم‌قطعیت مشخص است. می‌توانیم Severity یا اولویت را در تریاژ تغییر دهیم، اما حذف مشاهده یا تبدیل آن به Pass با شواهد فعلی درست نیست. لطفاً تصمیم، دلیل و مالک پذیرش ریسک را ثبت کنیم.»

آیا باید همه باگ‌ها را ثبت کرد؟

پاسخ مطلق «بله، هر مشاهده برای همیشه یک Ticket» عملی و حرفه‌ای نیست. Duplicate، مسئله خارج از دامنه، پیشنهاد طراحی و شکست محیطی می‌توانند وضعیت متفاوت داشته باشند. اصل اخلاقی، ردیابی‌پذیری اطلاعات مادی و نبود تحریف است.

• مشاهده مادی را پیش از تریاژ ناپدید نکنید.
• Duplicate را به مرجع وصل کنید و Evidence تازه را حفظ کنید.
• Won’t Fix را با مالک، دلیل، ریسک باقی‌مانده و تاریخ بازبینی ببندید.
• مسائل کم‌اثر را می‌توان گروه‌بندی کرد، اگر الگوی سیستمی پنهان نشود.
• Retention باید با سیاست امنیت و حریم خصوصی سازگار باشد.

هدف انباشتن Backlog نیست؛ ساختن یک تاریخچه صادقانه و متناسب برای تصمیم است.

کنترل‌های سازمانی که شجاعت فردی را جایگزین می‌کنند

سازمان اخلاقی نباید هر بار منتظر قهرمان فردی بماند. حداقل کنترل‌ها عبارت‌اند از:

• منشور محصول و Code of Conduct با مثال‌های واقعی؛
• ماتریس اختیار برای پذیرش ریسک محصول، امنیت، حریم خصوصی و ایمنی؛
• تعریف خطوط قرمز و معیارهای توقف پیش از Deadline؛
• کانال گزارش محرمانه، دسترسی محدود و سیاست روشن درباره تلافی؛
• بازبینی دوم برای تصمیم‌های پراثر و تعارض منافع؛
• سیاست Test Data، Secret، Screenshot، Artifact و ابزار AI؛
• Vulnerability Disclosure Policy و Incident Playbook؛
• Decision Record با شرط، انقضا و مالک اقدام؛
• Postmortem مبتنی بر علت‌های مشارکت‌کننده و پیگیری اقدام؛
• تمرین دوره‌ای سناریوهای اخلاقی، نه فقط امضای سالانه سیاست.

استقلال به معنی جدایی QA از تیم نیست

QA باید با مهندسی و محصول همکاری نزدیک داشته باشد، اما امکان بیان نتیجه نامطلوب بدون تغییر اجباری Evidence را حفظ کند. Peer Review، چرخش بازبین و مسیر مستقل برای ریسک مادی می‌تواند استقلال قضاوت را بدون ساختن دیوار سازمانی تقویت کند.

فشار و فرسودگی یک کنترل کیفیت است

فرد خسته، تنها و وابسته به KPI احتمالاً ریسک را دیرتر می‌بیند یا کمتر مطرح می‌کند. ظرفیت واقع‌بینانه، On-call سالم، امکان توقف، بازبینی همکار و حمایت مدیر، کنترل‌های اخلاقی و فنی‌اند. ماتریس مهارت مقاله مهارت‌های ضروری QA می‌تواند برای آموزش ارتباط ریسک و قضاوت حرفه‌ای استفاده شود.

شاخص‌های سالم برای حاکمیت اخلاقی QA

اخلاق را به امتیاز افراد تبدیل نکنید. شاخص‌ها باید سلامت سیستم گزارش و تصمیم را نشان دهند:

• زمان تأیید دریافت نگرانی مادی، به تفکیک سطح؛
• سن تصمیم‌های پذیرش ریسکِ منقضی‌شده؛
• درصد تصمیم‌های پرریسک با Evidence، مالک و تاریخ بازبینی کامل؛
• زمان حذف Test Data و Artifact حساس نسبت به سیاست؛
• تعداد اقدام‌های Postmortem بسته‌شده با شاهد اثر، نه صرفاً Status؛
• نرخ بازگشایی ریسک به دلیل شرط اجرا‌نشده؛
• کیفیت و دسترس‌پذیری کانال گزارش از طریق بازبینی دوره‌ای ناشناس.

«تعداد گزارش اخلاقی کمتر» لزوماً بهتر نیست؛ ممکن است کانال ناامن یا فرهنگ ساکت باشد. معیار را همراه با مصاحبه، Audit نمونه‌ای و زمینه تیم تفسیر کنید.

چک‌لیست ایران: داده، زبان، پول و ابزار خارجی

• داده هویتی: کد ملی، موبایل، نشانی، تصویر مدرک و شناسه پرداخت را در Log و Screenshot جست‌وجو کنید.
• ریال و تومان: نمایش و ذخیره واحد، گردکردن، تخفیف، قسط و بازپرداخت جزئی را شفاف کنید.
• پرداخت: Timeout، Callback تکراری، تطبیق، بازگشت وجه و مسیر اعتراض مشتری را بسنجید.
• زبان و هویت: نام‌های فارسی/عربی، نیم‌فاصله، ارقام، راست‌به‌چپ و فرض‌های جنسیتی یا جغرافیایی را بررسی کنید.
• دسترس‌پذیری: صفحه‌خوان، کیبورد، کنتراست، زمان، CAPTCHA و احراز هویت را فقط با اسکن خودکار نسنجید.
• شبکه و دستگاه: کاربر کم‌سرعت یا دستگاه قدیمی نباید بدون دلیل از Journey حیاتی حذف شود.
• سرویس خارجی: پیش از ارسال کد، Log، Dataset یا Screenshot به SaaS و مدل AI، مجوز، محل داده، Secret و امکان حذف را بررسی کنید.
• الزام حقوقی: از تعمیم خودکار GDPR یا قانون کشور دیگر خودداری کنید؛ دامنه قانون و قرارداد قابل‌اعمال را متخصص مربوط تعیین کند.

برنامه ۳۰ روزه برای تیم QA

1. هفته اول: سه Incident یا اختلاف انتشار گذشته را بدون نام افراد مرور و خلأ تصمیم را پیدا کنید.
2. هفته دوم: کارت نگرانی، ماتریس اختیار و چهار سطح اقدام را با محصول، مهندسی، امنیت و حقوقی تطبیق دهید.
3. هفته سوم: یک تمرین Tabletop برای پرداخت، داده تولید یا Feature مبتنی بر AI اجرا کنید.
4. هفته چهارم: کانال، زمان پاسخ، Retention، گزارش تصمیم و دو شاخص سیستمی را فعال کنید.

پس از ۳۰ روز، کیفیت یک تصمیم واقعی را Audit کنید: آیا Evidence کافی بود؟ فرد درست تصمیم گرفت؟ شرط‌ها اجرا شد؟ داده حساس حفاظت شد؟ این بازبینی از شمارش تعداد آموزش‌ها ارزشمندتر است.

جمع‌بندی

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

در دوراهی بعدی، از یک جمله اتهامی یا یک Pass مبهم شروع نکنید. کارت نگرانی را پر کنید: مشاهده، افراد متأثر، تعهد، عدم‌قطعیت، گزینه‌ها، تصمیم‌گیر و تاریخ بازبینی. اخلاق خوب در QA بیش از هر چیز، قابلیت دیدن، گفتن و پیگیری حقیقت مادی بدون ایجاد آسیب تازه است.

سؤالات متداول اخلاق در تست نرم‌افزار

۱. آیا متخصص QA مسئول اخلاقی بودن کل محصول است؟

خیر؛ مسئولیت میان محصول، مهندسی، طراحی، داده، امنیت، حقوقی و مدیریت مشترک است. QA مسئول ویژه دقت Evidence، بیان محدودیت تست، طرح نگرانی معقول و خودداری از تأیید ادعای بدون پشتوانه است. پذیرش ریسک باید نزد مالک مجاز بماند.

۲. اگر مدیر بخواهد باگ مهم را پنهان یا کم‌اهمیت کنم چه کنم؟

مشاهده، دامنه، عدم‌قطعیت و اثر را حفظ کنید. Severity و Priority می‌توانند در تریاژ تغییر کنند، اما تغییر باید با مالک و دلیل ثبت شود. اگر فشار برای تحریف ادامه یافت، از مسیر مستقل داخلی استفاده کنید و برای اقدام بیرونیِ پرریسک، مشاوره تخصصی بگیرید.

۳. آیا همه باگ‌های جزئی باید Ticket جدا داشته باشند؟

نه لزوماً. Duplicate، پیشنهاد و مسائل کم‌اثر را می‌توان پیوند یا گروه‌بندی کرد. اصل مهم این است که اطلاعات مادی حذف نشود، تغییر وضعیت ردپا داشته باشد و Won’t Fix با دلیل، مالک و ریسک باقی‌مانده ثبت شود.

۴. آیا استفاده از داده تولید برای تست غیراخلاقی است؟

همیشه نه، اما نباید پیش‌فرض باشد. ضرورت و تناسب باید اثبات شود و مجوز، کمینه‌سازی، Masking، کنترل دسترسی، Retention و حذف وجود داشته باشد. داده مصنوعی یا زیرمجموعه کنترل‌شده در بسیاری از هدف‌ها گزینه کم‌ریسک‌تری است.

۵. چه زمانی نگرانی را بیرون از سازمان گزارش کنیم؟

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