کیفیت نرم افزار (Software Quality) چیست؟ بررسی جامع ابعاد، معیارها و نقش آن در توسعه نرم افزار

وقتی درباره کیفیت نرم افزار صحبت می‌کنیم، اولین چیزی که معمولاً به ذهن می‌رسد Bug است.

ممکن است تصور کنیم اگر یک نرم افزار Bugهای کمی داشته باشد، پس حتماً Software باکیفیتی است.

اما آیا واقعاً همین‌طور است؟

فرض کنید یک فروشگاه اینترنتی داریم که هیچ Bug مهم شناخته‌شده‌ای ندارد؛ اما صفحات آن بسیار کند هستند، فرآیند خرید پیچیده است، کاربران نمی‌توانند به‌راحتی از آن استفاده کنند و در زمان افزایش تعداد کاربران، سیستم از کار می‌افتد.

آیا می‌توانیم بگوییم این نرم افزار باکیفیت است؟

احتمالاً نه.

اینجاست که متوجه می‌شویم Software Quality مفهومی بسیار بزرگ‌تر از «تعداد Bugها» است.

کیفیت نرم افزار مجموعه‌ای از ویژگی‌ها و رفتارهایی است که مشخص می‌کنند یک Software تا چه اندازه می‌تواند نیازها و انتظارات مرتبط کاربران، کسب‌وکار و سایر ذی‌نفعان را در شرایط موردنظر برآورده کند.

کیفیت نرم افزار چیست؟

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

اما برای درک بهتر این مفهوم، باید چند سؤال اساسی را از خودمان بپرسیم:

• آیا Software رفتار مورد انتظار را دارد؟
• آیا در شرایط مختلف قابل اعتماد است؟
• آیا Performance مناسبی دارد؟
• آیا از نظر Security قابل قبول است؟
• آیا کاربران می‌توانند به‌راحتی از آن استفاده کنند؟
• آیا تغییر و نگهداری آن برای تیم توسعه امکان‌پذیر است؟
• آیا در شرایط واقعی Production همچنان عملکرد مناسبی دارد؟

بنابراین Quality را نمی‌توان به یک ویژگی واحد محدود کرد.

یک Software ممکن است از نظر Functional بسیار خوب باشد، اما از نظر Performance یا Security مشکل داشته باشد.

یا ممکن است از نظر فنی کاملاً درست کار کند، اما استفاده از آن برای کاربران دشوار باشد.

یک مثال ساده برای درک Software Quality

فرض کنید یک Application بانکی ساخته‌ایم.

کاربر می‌تواند وارد حساب خود شود، موجودی را ببیند و انتقال وجه انجام دهد.

از نظر Functional Testing همه چیز درست است.

اما در زمان انتقال وجه، Response Time به ۱۵ ثانیه می‌رسد.

یا تصور کنید سیستم در شرایط عادی خوب کار می‌کند، اما با افزایش تعداد کاربران، Crash می‌کند.

یا اینکه فرآیند انتقال وجه از نظر Functional کاملاً درست است، اما یک مشکل Security باعث افشای اطلاعات حساس کاربران می‌شود.

در تمام این حالت‌ها ممکن است تست‌های عملکردی (Functional Test) موفق باشند، اما نمی‌توانیم نتیجه بگیریم که Software از نظر کلی باکیفیت است.

Software Quality فقط به این سؤال پاسخ نمی‌دهد که «آیا نرم افزار کار می‌کند؟» بلکه می‌پرسد «آیا نرم افزار در شرایط موردنظر، به شکل قابل اعتماد، امن، قابل استفاده و متناسب با نیاز واقعی عمل می‌کند؟»

چرا تعریف Quality سخت‌تر از چیزی است که به نظر می‌رسد؟

یکی از دلایل دشوار بودن تعریف Quality این است که Quality یک مفهوم مطلق نیست.

ممکن است چیزی برای یک Product بسیار مهم باشد، اما برای Product دیگری اهمیت کمتری داشته باشد.

برای مثال، در یک سیستم بانکی:

• Security اهمیت بسیار بالایی دارد.
• Reliability اهمیت بسیار بالایی دارد.
• Availability اهمیت زیادی دارد.
• Performance نیز مهم است.

اما در یک Application سرگرمی ممکن است Usability و Performance وزن بیشتری داشته باشند.

بنابراین وقتی می‌گوییم:

«این Software باکیفیت است.»

بهتر است بپرسیم:

برای چه کسی؟ در چه Contextی؟ و با چه سطحی از Risk؟

کیفیت فقط در پایان پروژه ساخته نمی‌شود

یکی از اشتباهات رایج این است که تصور کنیم Quality در مرحله Testing بررسی می‌شود.

در این نگاه، فرآیند به شکل زیر است:

Development → Testing → Quality

اما در واقع Quality از مراحل بسیار زودتری شروع می‌شود.

Requirement → Design → Development → Testing → Deployment → Production → Feedback

در هر یک از این مراحل ممکن است تصمیمی گرفته شود که روی Quality نهایی اثر بگذارد.

داستانی که نگاه ما به Quality را تغییر می‌دهد

فرض کنید یک تیم Software قرار است یک Feature جدید برای سیستم فروش آنلاین خود توسعه دهد.

Developer Feature را پیاده‌سازی می‌کند.

QA Test Caseها را اجرا می‌کند.

تمام Testها Pass می‌شوند.

Feature Release می‌شود.

اما چند هفته بعد مشخص می‌شود که کاربران تقریباً از این Feature استفاده نمی‌کنند.

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

آیا Software بی‌کیفیت بود؟

نه لزوماً.

ممکن است Software از نظر فنی کاملاً درست ساخته شده باشد، اما Feature از ابتدا دغدغه واقعی کاربر نبوده باشد.

این موضوع بیشتر به حوزه‌هایی مانند Product Value و Product Success مربوط می‌شود؛ مفاهیمی که با Software Quality ارتباط دارند اما با آن یکی نیستند.

این تمایز بسیار مهم است، زیرا اگر هر شکست Product را به Quality نسبت دهیم، مفهوم Software Quality را بیش از حد گسترده و مبهم خواهیم کرد.

رابطه Quality با تیم‌های مختلف

Quality نتیجه کار یک تیم واحد نیست.

Requirementهای ضعیف می‌توانند باعث ایجاد مشکل شوند.

Design ضعیف می‌تواند Reliability یا Performance را تحت تأثیر قرار دهد.

Implementation ضعیف می‌تواند Defect ایجاد کند.

Testing ضعیف می‌تواند باعث شود مشکلات کشف‌نشده وارد Production شوند.

Deployment یا Infrastructure نامناسب نیز می‌تواند باعث Failure شود.

حتی عوامل خارج از Software مانند Product Strategy یا Marketing می‌توانند روی موفقیت نهایی Product تأثیر بگذارند؛ بدون اینکه الزاماً نشان‌دهنده Software Quality پایین باشند.

Quality یک مسئولیت مشترک است، نه وظیفه یک نقش خاص.

Software Quality چه چیزهایی را شامل می‌شود؟

برای اینکه مفهوم Quality را بهتر درک کنیم، باید ابعاد مختلف آن را بشناسیم.

• Functional Quality: آیا Software قابلیت‌های موردنظر را درست انجام می‌دهد؟
• Reliability: آیا Software در طول زمان و شرایط مختلف قابل اعتماد است؟
• Performance: آیا Software در شرایط بار مورد انتظار عملکرد مناسبی دارد؟
• Security: آیا اطلاعات و قابلیت‌های سیستم در برابر تهدیدها محافظت می‌شوند؟
• Usability: آیا استفاده از Software برای کاربران قابل فهم و مناسب است؟
• Accessibility: آیا افراد با نیازهای مختلف می‌توانند از Software استفاده کنند؟
• Maintainability: آیا Software به‌راحتی قابل تغییر و نگهداری است؟
• Compatibility: آیا Software در محیط‌ها و شرایط موردنظر به‌درستی کار می‌کند؟

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

Quality را نباید فقط با یک عدد سنجید

گاهی سازمان‌ها تلاش می‌کنند Quality را به یک عدد تبدیل کنند:

Quality Score = 92%

اما این عدد به‌تنهایی اطلاعات زیادی به ما نمی‌دهد.

اگر Security عالی باشد اما Performance ضعیف، یا Reliability عالی باشد اما Usability ضعیف، یک عدد واحد ممکن است تفاوت‌های مهم را پنهان کند.

به همین دلیل در ارزیابی Quality باید مجموعه‌ای از Quality Signals و Metrics را در کنار Context و Risk بررسی کنیم.

Quality یک وضعیت ثابت نیست

حتی اگر امروز Software کیفیت مناسبی داشته باشد، نمی‌توانیم فرض کنیم همیشه همین‌طور باقی خواهد ماند.

با تغییر:

• Code
• Architecture
• Dependencies
• User Behavior
• Traffic
• Infrastructure
• Security Threats

ممکن است Quality نیز تغییر کند.

بنابراین Quality باید به‌صورت مداوم:

Measure → Observe → Learn → Improve

شود.

در این مقاله چه چیزهایی بررسی خواهیم کرد؟

در ادامه این مقاله جامع، از تعریف Software Quality عبور می‌کنیم و به سراغ ابعاد، مدل‌ها، معیارها و کاربردهای عملی آن می‌رویم.

• Software Quality دقیقاً چیست؟
• تفاوت Quality با QA و QC چیست؟
• Quality Attributes کدام‌اند؟
• رابطه Testing با Quality چیست؟
• چگونه Quality را اندازه‌گیری کنیم؟
• Quality Metrics چه کاربردی دارند؟
• نقش Performance، Security و Accessibility در Quality چیست؟
• Quality در Agile و DevOps چگونه مدیریت می‌شود؟
• Quality Engineering چه تفاوتی با نگاه سنتی دارد؟
• رایج‌ترین اشتباهات درباره Software Quality چیست؟
• چگونه برای یک پروژه Quality Strategy طراحی کنیم؟
• QA در یک پروژه واقعی چگونه به بهبود Quality کمک می‌کند؟

در نهایت به این سؤال پاسخ خواهیم داد:

چگونه بفهمیم Software ما واقعاً باکیفیت است؟

---

💡 نکته: در این مقاله تلاش می‌کنیم Software Quality را فقط از زاویه Testing بررسی نکنیم؛ بلکه آن را به‌عنوان مفهومی در کل چرخه عمر Software و در ارتباط با Risk، User Experience، Reliability، Security، Performance و سایر ابعاد مهم بررسی خواهیم کرد.

Software Quality دقیقاً به چه معناست؟

در بخش قبل دیدیم که Software Quality مفهومی بسیار گسترده‌تر از «نداشتن Bug» است. اما اگر بخواهیم این مفهوم را دقیق‌تر بررسی کنیم، باید ببینیم وقتی درباره Quality صحبت می‌کنیم، دقیقاً چه چیزی را ارزیابی می‌کنیم.

در ساده‌ترین شکل می‌توان گفت:

Software Quality یعنی میزان توانایی یک نرم افزار برای برآورده کردن نیازها و انتظارات مرتبط، با سطحی قابل قبول از عملکرد، قابلیت اعتماد، امنیت، استفاده‌پذیری و سایر ویژگی‌های موردنیاز.

اما همین تعریف یک نکته مهم دارد:

Quality همیشه باید در Context خودش بررسی شود.

نمی‌توان بدون درنظر گرفتن نوع Software، کاربران، شرایط استفاده و Riskها گفت که یک سیستم «با کیفیت» یا «بی‌کیفیت» است.

Quality از نگاه‌های مختلف

یکی از دلایل پیچیدگی Software Quality این است که افراد مختلف ممکن است از یک Software انتظارهای متفاوتی داشته باشند.

برای مثال، یک کاربر ممکن است بگوید:

«این نرم افزار خیلی سخت استفاده می‌شود.»

یک Developer ممکن است بگوید:

«Codebase بسیار پیچیده شده و تغییر دادن آن سخت است.»

یک تیم DevOps ممکن است بگوید:

«سیستم در زمان افزایش Traffic به‌خوبی Scale نمی‌شود.»

تیم Security ممکن است بگوید:

«یک Vulnerability مهم وجود دارد.»

و Product Manager ممکن است بگوید:

«Feature اصلی نیاز کاربر را به‌خوبی پوشش نمی‌دهد.»

هیچ‌کدام لزوماً اشتباه نمی‌کنند.

هرکدام از زاویه متفاوتی به Quality نگاه می‌کنند.

یک Software می‌تواند از یک نظر عالی و از نظر دیگر ضعیف باشد

تصور کنید یک API داریم که:

• از نظر Functional کاملاً درست کار می‌کند.
• Response Time بسیار خوبی دارد.
• در Load بالا پایدار است.
• اما Logging ضعیفی دارد.
• یا تغییر دادن آن بسیار دشوار است.

آیا باید بگوییم Software باکیفیت است یا بی‌کیفیت؟

پاسخ دقیق‌تر این است:

Software دارای نقاط قوت و ضعف متفاوتی در Quality Attributes مختلف است.

به همین دلیل ارزیابی Quality معمولاً به یک نگاه چندبعدی نیاز دارد.

Quality Attribute چیست؟

برای صحبت دقیق‌تر درباره Quality، معمولاً از مفهوم Quality Attribute استفاده می‌شود.

Quality Attribute ویژگی‌ای از Software است که نشان می‌دهد سیستم از یک جنبه خاص تا چه اندازه رفتار مطلوبی دارد.

برای مثال:

• Performance: سیستم با چه سرعت و ظرفیتی پاسخ می‌دهد؟
• Reliability: سیستم تا چه اندازه در طول زمان قابل اعتماد است؟
• Security: سیستم تا چه اندازه در برابر تهدیدها محافظت می‌شود؟
• Usability: استفاده از سیستم برای کاربر تا چه اندازه آسان و قابل فهم است؟
• Maintainability: تغییر، اصلاح و نگهداری Software تا چه اندازه آسان است؟
• Accessibility: افراد با توانایی‌ها و شرایط مختلف تا چه اندازه می‌توانند از Software استفاده کنند؟

این Attributes کمک می‌کنند Quality را از یک مفهوم کلی و مبهم به مجموعه‌ای از ویژگی‌های قابل بررسی تبدیل کنیم.

Functional Quality در برابر Quality کلی

یکی از اشتباهات رایج این است که Functional Correctness را با Software Quality یکی بدانیم.

Functional Testing معمولاً بررسی می‌کند که آیا Software قابلیت موردنظر را مطابق Requirement انجام می‌دهد یا خیر.

اما Software Quality سؤال‌های بیشتری مطرح می‌کند.

• آیا Feature قابل استفاده است؟
• آیا در شرایط مختلف پایدار می‌ماند؟
• آیا Performance مناسبی دارد؟
• آیا رفتار آن امن است؟
• آیا در محیط‌های موردنظر سازگار است؟
• آیا تغییر آن در آینده دشوار خواهد بود؟

بنابراین:

Functional Correctness یکی از اجزای Software Quality است، نه تمام آن.

داستان؛ نرم افزاری که همه چیز را درست انجام می‌داد

فرض کنید یک تیم یک سیستم رزرو آنلاین ساخته است.

کاربر می‌تواند مقصد را انتخاب کند، تاریخ را وارد کند، اتاق را انتخاب کند و پرداخت را انجام دهد.

QA تمام Test Caseهای Functional را اجرا می‌کند و همه آن‌ها Pass می‌شوند.

تیم با خیال راحت Release می‌کند.

اما چند ساعت بعد کاربران شروع به شکایت می‌کنند.

چرا؟

• صفحه Search بسیار کند است.
• در موبایل استفاده از فرم دشوار است.
• در زمان Traffic بالا Response Time افزایش شدیدی پیدا می‌کند.
• برخی کاربران با Keyboard نمی‌توانند به‌درستی از سیستم استفاده کنند.

هیچ‌کدام الزاماً به این معنی نیستند که Functional Testها اشتباه بوده‌اند.

مشکل این است که تیم Quality را بیش از حد به Functional Correctness محدود کرده است.

آیا Quality یعنی برآورده کردن Requirement؟

این سؤال بسیار مهمی است.

در نگاه سنتی ممکن است بگوییم:

«اگر Software مطابق Specification ساخته شده باشد، پس باکیفیت است.»

اما یک مشکل وجود دارد:

ممکن است خود Specification مشکل داشته باشد.

فرض کنید Requirement می‌گوید:

«کاربر برای تکمیل خرید باید از پنج مرحله عبور کند.»

Developer دقیقاً همین Requirement را پیاده‌سازی می‌کند.

QA نیز آن را مطابق Specification تست می‌کند.

تمام Testها Pass می‌شوند.

اما بعد مشخص می‌شود کاربران در فرآیند Checkout پنج‌مرحله‌ای، نرخ ریزش بسیار بالایی دارند.

در اینجا Software ممکن است از نظر Compliance با Requirement درست باشد، اما سؤال Quality همچنان باقی است:

آیا چیزی که ساختیم، واقعاً در Context موردنظر کیفیت قابل قبولی دارد؟

تفاوت Quality با Product Value

در این نقطه باید یک مرز مهم را مشخص کنیم.

ممکن است Software از نظر فنی بسیار خوب باشد، اما Feature یا Product ارزش زیادی برای کاربر ایجاد نکند.

مثلاً تیم محصول یک Feature جدید توسعه داده است که:

• بدون Bug است.
• Performance مناسبی دارد.
• Security آن بررسی شده است.
• Automation Test دارد.
• در Production نیز پایدار است.

اما کاربران علاقه‌ای به استفاده از آن ندارند، چون این Feature مسئله مهمی را برای آن‌ها حل نمی‌کند.

این وضعیت لزوماً نشانه Software Quality پایین نیست.

در این مقاله وارد بحث عمیق Product Value یا Product Success نمی‌شویم؛ زیرا این موضوعات خودشان حوزه‌های مستقلی هستند. نکته مهم فقط این است که مرز این مفاهیم را با Software Quality بشناسیم.

یک Product می‌تواند از نظر Software Quality عالی باشد اما از نظر Product Value موفق نباشد.

تفاوت Quality با عملکرد Marketing

سناریوی دیگری را در نظر بگیرید.

یک Software از نظر فنی وضعیت بسیار خوبی دارد:

• Performance مناسب است.
• Bugهای Critical وجود ندارد.
• Security بررسی شده است.
• Usability مناسب است.
• سیستم در Production پایدار است.

اما تیم Marketing یک کمپین ضعیف اجرا می‌کند و کاربران کافی وارد Product نمی‌شوند.

آیا باید نتیجه بگیریم Software Quality پایین بوده است؟

خیر.

کمپین ضعیف می‌تواند باعث شکست در جذب کاربر شود، اما این موضوع به‌تنهایی نشان‌دهنده ضعف Software Quality نیست.

البته Marketing، Product و Software Quality می‌توانند در موفقیت نهایی یک محصول با یکدیگر تعامل داشته باشند؛ اما نباید آن‌ها را یک مفهوم واحد در نظر گرفت.

پس Quality دقیقاً کجای این تصویر قرار می‌گیرد؟

می‌توانیم رابطه مفاهیم را به شکل ساده زیر تصور کنیم:

Product Success
↑
Product Value + Business Model + Marketing + User Adoption + Software Quality + عوامل دیگر

در این میان Software Quality یکی از عوامل مهمی است که به Product کمک می‌کند ارزش موردنظر را به شکل پایدار و قابل اعتماد ارائه کند.

اما Software Quality به‌تنهایی تضمین‌کننده Product Success نیست.

Quality Assurance، Quality Control و Testing کجا قرار می‌گیرند؟

از آنجا که QA و QC موضوع مقاله‌های جداگانه هستند، در اینجا فقط مرز کلی آن‌ها را مشخص می‌کنیم.

Quality Assurance (QA) بیشتر به رویکردها و فعالیت‌هایی مربوط می‌شود که با هدف جلوگیری از ایجاد مشکلات و بهبود فرآیندها انجام می‌شوند.

Quality Control (QC) بیشتر بر بررسی خروجی و شناسایی مشکلات موجود در Software تمرکز دارد.

Testing نیز مجموعه‌ای از فعالیت‌ها برای ارزیابی Software و کشف اطلاعات درباره رفتار آن است.

اما هیچ‌کدام به‌تنهایی معادل Software Quality نیستند.

QA، QC و Testing ابزارها و رویکردهایی برای رسیدن به Quality بهتر هستند؛ خود Quality نیستند.

یک مدل ذهنی ساده برای درک Quality

اگر بخواهیم یک مدل ذهنی ساده بسازیم، می‌توانیم Quality را حاصل تعامل چند عامل در نظر بگیریم:

Requirements
↓
Design
↓
Implementation
↓
Testing
↓
Deployment
↓
Real-World Usage
↓
Feedback & Improvement

در هر مرحله تصمیم‌هایی گرفته می‌شود که می‌توانند Quality نهایی را بهتر یا بدتر کنند.

چرا این نگاه برای یک Tester مهم است؟

اگر Tester Quality را فقط به معنی «پیدا کردن Bug» بداند، احتمالاً بیشتر وقت خود را صرف اجرای Test Caseها خواهد کرد.

اما اگر Quality را یک مفهوم چندبعدی ببیند، سؤال‌های متفاوتی مطرح می‌کند:

• چه چیزی ممکن است خراب شود؟
• کدام Failure بیشترین Impact را دارد؟
• چه Quality Attributeهایی برای این Product مهم‌تر هستند؟
• چه چیزی را هنوز تست نکرده‌ایم؟
• چه چیزی را نمی‌توانیم به‌خوبی تست کنیم؟
• اگر Software در Production شکست بخورد، چگونه متوجه آن خواهیم شد؟

این تغییر نگاه، Tester را از یک Test Executor به فردی نزدیک‌تر می‌کند که به تیم کمک می‌کند Riskهای Software را بهتر بشناسد.

جمع‌بندی بخش دوم 🎯

Software Quality را نمی‌توان با یک معیار واحد تعریف کرد.

Quality باید در Context مربوط به Product، کاربران، Riskها و نیازهای آن بررسی شود.

• Functional Correctness فقط یکی از ابعاد Quality است.
• Quality Attributeها به ما کمک می‌کنند Quality را به ویژگی‌های قابل بررسی تقسیم کنیم.
• برآورده کردن Specification لزوماً به معنی Software Quality بالا نیست.
• Product Value و Product Success با Software Quality یکی نیستند.
• Marketing ضعیف به‌تنهایی نشان‌دهنده Software Quality پایین نیست.
• QA، QC و Testing با Quality ارتباط مستقیم دارند اما با آن یکسان نیستند.
• Quality نتیجه تعامل بخش‌های مختلف چرخه عمر Software است.

در بخش بعدی، وارد مهم‌ترین موضوع مقاله می‌شویم: ابعاد و ویژگی‌های اصلی Software Quality و بررسی می‌کنیم که Quality از چه جنبه‌هایی باید ارزیابی شود.

ابعاد اصلی Software Quality؛ یک نرم افزار باکیفیت چه ویژگی‌هایی دارد؟

حالا که فهمیدیم Software Quality مفهومی چندبعدی است، وقت آن است که دقیق‌تر بررسی کنیم این ابعاد چه چیزهایی هستند.

اگر یک تیم فقط بپرسد:

«آیا Feature درست کار می‌کند؟»

بخش مهمی از تصویر Quality را از دست داده است.

سؤال‌های دیگری هم وجود دارند:

• آیا Software در شرایط واقعی پایدار است؟
• آیا در زمان افزایش بار همچنان عملکرد مناسبی دارد؟
• آیا اطلاعات کاربران محافظت می‌شوند؟
• آیا کاربران می‌توانند به‌راحتی از آن استفاده کنند؟
• آیا افراد دارای نیازهای مختلف می‌توانند از آن استفاده کنند؟
• آیا Software در محیط‌های مختلف به‌درستی کار می‌کند؟
• آیا تغییر و نگهداری آن در آینده امکان‌پذیر است؟

مجموع این سؤال‌ها ما را به مفهوم Quality Attributes می‌رساند.

Quality Attribute چیست؟

Quality Attribute ویژگی یا جنبه‌ای از Software است که کیفیت سیستم را از یک زاویه مشخص توصیف می‌کند.

به جای اینکه Quality را یک مفهوم بزرگ و مبهم در نظر بگیریم، آن را به چندین ویژگی قابل بررسی تقسیم می‌کنیم.

برای مثال:

• Functional Suitability: آیا Software قابلیت‌های موردنیاز را ارائه می‌کند؟
• Performance Efficiency: آیا منابع و زمان پاسخ سیستم مناسب هستند؟
• Compatibility: آیا Software می‌تواند در محیط موردنظر با سایر سیستم‌ها به‌درستی کار کند؟
• Usability: آیا استفاده از Software برای کاربران مناسب و قابل فهم است؟
• Reliability: آیا Software در شرایط مشخص می‌تواند عملکرد پایدار و قابل اعتمادی داشته باشد؟
• Security: آیا Software از اطلاعات و قابلیت‌های خود در برابر تهدیدها محافظت می‌کند؟
• Maintainability: آیا Software به‌راحتی قابل تحلیل، تغییر، تست و نگهداری است؟
• Portability: آیا انتقال Software به محیط‌های دیگر با دشواری غیرمنطقی همراه نیست؟

این تقسیم‌بندی به ما کمک می‌کند هنگام صحبت درباره Quality دقیق‌تر باشیم.

آیا همه Quality Attributes به یک اندازه مهم هستند؟

خیر.

یکی از مهم‌ترین نکات در Software Quality این است که اهمیت Quality Attributes به Context وابسته است.

فرض کنید دو Software داریم:

Software A: یک سیستم بانکی.

Software B: یک Application ساده برای مدیریت لیست خرید شخصی.

در سیستم بانکی احتمالاً Security، Reliability و Availability اهمیت بسیار بالایی دارند.

اما در یک Application ساده ممکن است Usability و Simplicity اهمیت بیشتری پیدا کنند و برخی Riskهای Security در سطح پایین‌تری قرار بگیرند.

این به معنی بی‌اهمیت بودن Security در Application دوم نیست؛ بلکه یعنی سطح مورد انتظار و اولویت Quality Attributes متفاوت است.

Quality Profile چیست؟

می‌توانیم مجموعه Quality Attributes مهم برای یک Product را Quality Profile آن در نظر بگیریم.

مثلاً Quality Profile یک سیستم پرداخت آنلاین ممکن است تقریباً چنین اولویت‌هایی داشته باشد:

Quality Attribute	اهمیت احتمالی	دلیل
Security	بسیار بالا	حفاظت از اطلاعات و تراکنش‌ها
Reliability	بسیار بالا	جلوگیری از خطا در تراکنش‌ها
Availability	بالا	دسترسی مداوم به سرویس
Performance	بالا	تجربه مناسب و پاسخ سریع
Usability	بالا	کاهش خطای کاربر در پرداخت
Maintainability	متوسط تا بالا	تغییرات و توسعه مداوم

این جدول یک مثال مفهومی است و مقدار اهمیت هر Attribute باید بر اساس Context واقعی Product تعیین شود.

داستان؛ وقتی یک عدد همه چیز را پنهان می‌کند

فرض کنید مدیر یک تیم توسعه در جلسه‌ای می‌گوید:

«Quality سیستم ما ۹۵ درصد است.»

همه خوشحال می‌شوند.

اما یک Tester سؤال ساده‌ای می‌پرسد:

«این ۹۵ درصد دقیقاً چه چیزی را اندازه می‌گیرد؟»

مشخص می‌شود این عدد از درصد Test Caseهای موفق به دست آمده است.

اما هیچ اطلاعاتی درباره این موارد نمی‌دهد:

• Performance
• Security
• Usability
• Reliability
• Accessibility
• Maintainability

بنابراین:

۹۵٪ Test Pass Rate به معنی ۹۵٪ Software Quality نیست.

Functional Quality؛ آیا Software کار درست را درست انجام می‌دهد؟

اولین و شاید شناخته‌شده‌ترین جنبه Quality، عملکرد صحیح قابلیت‌های Software است.

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

• محصول را به سبد خرید اضافه کند.
• قیمت صحیح را محاسبه کند.
• Discount را درست اعمال کند.
• هزینه ارسال را صحیح محاسبه کند.
• پرداخت را به شکل صحیح پردازش کند.
• وضعیت سفارش را درست ثبت کند.

این‌ها نمونه‌هایی از Functional Correctness هستند.

اما حتی در همین مثال هم Quality فقط به Happy Path محدود نمی‌شود.

باید بدانیم Software در شرایط غیرعادی چه رفتاری دارد:

• اگر پرداخت ناموفق شود چه اتفاقی می‌افتد؟
• اگر کاربر صفحه را Refresh کند چه می‌شود؟
• اگر موجودی محصول هم‌زمان تمام شود چه اتفاقی می‌افتد؟
• اگر درخواست دوبار ارسال شود چه می‌شود؟
• اگر سرویس Payment در دسترس نباشد چه اتفاقی می‌افتد؟

اینجاست که Functional Quality با مفاهیمی مانند Reliability و Error Handling نیز ارتباط پیدا می‌کند.

Reliability؛ آیا می‌توانیم به Software اعتماد کنیم؟

فرض کنید یک Feature همیشه درست کار می‌کند؛ اما هر چند ساعت یک‌بار کل سیستم Crash می‌کند.

از نظر Functional شاید Feature درست باشد، اما از نظر Reliability وضعیت مطلوبی نداریم.

Reliability به این موضوع می‌پردازد که Software در شرایط مشخص و برای مدت مشخص، تا چه اندازه می‌تواند رفتار مورد انتظار را حفظ کند.

موضوعاتی مانند:

• Failure Frequency
• Recovery
• Stability
• Fault Tolerance
• Data Integrity

می‌توانند با Reliability ارتباط داشته باشند.

Performance؛ Software چقدر خوب و سریع کار می‌کند؟

ممکن است یک Software از نظر Functional کاملاً درست باشد، اما در عمل بسیار کند باشد.

مثلاً کاربر روی دکمه Search کلیک می‌کند و نتیجه پس از ۱۲ ثانیه نمایش داده می‌شود.

از دید Functional:

Search درست کار کرده است.

اما از دید Performance:

ممکن است رفتار سیستم قابل قبول نباشد.

Performance فقط به سرعت محدود نمی‌شود و موضوعاتی مانند Response Time، Latency، Throughput، Resource Utilization و رفتار سیستم در Loadهای مختلف را نیز دربرمی‌گیرد.

در مقاله مستقل Performance Testing می‌توان این موضوع را بسیار عمیق‌تر بررسی کرد.

Security؛ آیا می‌توان به Software از نظر امنیتی اعتماد کرد؟

یک Software ممکن است همه قابلیت‌های خود را به‌درستی انجام دهد، اما یک Vulnerability جدی داشته باشد.

برای مثال، تصور کنید کاربر بتواند با تغییر یک مقدار در Request، اطلاعات کاربر دیگری را مشاهده کند.

در این شرایط ممکن است Functional Testهای معمولی Pass شوند، اما Quality سیستم از منظر Security با یک مشکل جدی مواجه است.

Security می‌تواند موضوعاتی مانند:

• Confidentiality
• Integrity
• Authentication
• Authorization
• Data Protection

را شامل شود.

Usability؛ آیا کاربر می‌تواند به‌راحتی از Software استفاده کند؟

فرض کنید یک قابلیت کاملاً درست کار می‌کند، اما کاربر برای پیدا کردن آن باید چند دقیقه جست‌وجو کند.

از نظر Functional مشکلی وجود ندارد.

اما از نظر Usability، Software می‌تواند تجربه نامناسبی ایجاد کند.

Usability می‌تواند با مواردی مانند:

• Learnability
• Efficiency
• Error Prevention
• Consistency
• Clarity

ارتباط داشته باشد.

Accessibility؛ آیا Software برای همه قابل استفاده است؟ ♿

یکی از جنبه‌هایی که گاهی در بحث Quality نادیده گرفته می‌شود، Accessibility است.

فرض کنید یک Web Application برای کاربران عادی به‌خوبی کار می‌کند، اما کاربری که از Screen Reader استفاده می‌کند نمی‌تواند دکمه‌های اصلی صفحه را تشخیص دهد.

از نظر Functional ممکن است قابلیت کاملاً سالم باشد.

اما از دید Accessibility، Software برای بخشی از کاربران قابل استفاده نیست.

Accessibility بنابراین می‌تواند بخشی از Software Quality باشد و باید متناسب با مخاطبان و Context محصول مورد توجه قرار گیرد.

Maintainability؛ کیفیتی که کاربر مستقیماً نمی‌بیند

برخی Quality Attributes مستقیماً توسط کاربر دیده نمی‌شوند، اما برای عمر Software بسیار مهم هستند.

برای مثال، Software ممکن است امروز کاملاً درست کار کند، اما Codebase آن به‌قدری پیچیده باشد که اضافه کردن یک Feature ساده چند هفته زمان ببرد و هر تغییر کوچک چند Bug جدید ایجاد کند.

در چنین شرایطی Maintainability پایین است.

Maintainability می‌تواند با موضوعاتی مانند:

• Modularity
• Testability
• Readability
• Analyzability
• Changeability

ارتباط داشته باشد.

Compatibility و Portability

Software ممکن است در یک محیط کاملاً درست کار کند اما در محیط دیگری با مشکل مواجه شود.

برای مثال:

• در یک Browser درست کار کند اما در Browser دیگر مشکل داشته باشد.
• در یک سیستم‌عامل عملکرد مناسبی داشته باشد اما در سیستم‌عامل دیگر دچار مشکل شود.
• در یک نسخه از Dependencyها درست کار کند اما پس از Update رفتار آن تغییر کند.

در اینجا Compatibility و Portability اهمیت پیدا می‌کنند.

Quality Attributes چگونه به یکدیگر وابسته‌اند؟

یکی از نکات جالب درباره Quality این است که Quality Attributes همیشه مستقل از یکدیگر نیستند.

گاهی بهبود یک Attribute می‌تواند Attribute دیگری را تحت تأثیر قرار دهد.

برای مثال، افزایش شدید Security ممکن است فرآیند Login را پیچیده‌تر کند و روی Usability اثر بگذارد.

یا یک Optimization برای Performance ممکن است Code را پیچیده‌تر کند و Maintainability را کاهش دهد.

به همین دلیل Software Quality اغلب شامل Trade-off است.

هدف همیشه بیشینه کردن همه Quality Attributes نیست؛ هدف پیدا کردن تعادل مناسب برای Context واقعی Product است.

جمع‌بندی بخش سوم 🎯

Software Quality یک مفهوم چندبعدی است و برای ارزیابی آن باید مجموعه‌ای از Quality Attributes را در نظر گرفت.

• Functional Quality بررسی می‌کند قابلیت‌ها درست عمل می‌کنند یا خیر.
• Reliability به قابل اعتماد بودن و پایداری Software مربوط است.
• Performance رفتار سیستم از نظر زمان پاسخ، ظرفیت و مصرف منابع را بررسی می‌کند.
• Security به حفاظت از اطلاعات و قابلیت‌های سیستم مربوط می‌شود.
• Usability تجربه و سهولت استفاده از Software را پوشش می‌دهد.
• Accessibility امکان استفاده افراد با نیازهای مختلف را مورد توجه قرار می‌دهد.
• Maintainability روی قابلیت تغییر و نگهداری Software تمرکز دارد.
• Compatibility و Portability رفتار Software در محیط‌های مختلف را بررسی می‌کنند.

مهم‌تر از همه، هیچ Quality Attributeای را نمی‌توان بدون Context ارزیابی کرد. اهمیت هر Attribute باید بر اساس نوع Product، کاربران، Business Risk و شرایط استفاده مشخص شود.

در بخش بعدی، سراغ یکی از مهم‌ترین بحث‌های Software Quality می‌رویم: Quality Modelها و اینکه چگونه می‌توان Quality را به شکلی ساختاریافته ارزیابی کرد.

مدل‌های کیفیت نرم افزار (Software Quality Models) چیستند؟

تا اینجا درباره Quality Attributes صحبت کردیم؛ اما یک سؤال مهم باقی می‌ماند:

چطور این ویژگی‌ها را به شکلی منظم و ساختاریافته کنار هم قرار دهیم؟

اینجاست که مفهوم Software Quality Model مطرح می‌شود.

Quality Model یک چارچوب مفهومی است که کمک می‌کند ویژگی‌های مختلف Quality را دسته‌بندی کنیم و بدانیم برای ارزیابی یک Software باید به چه جنبه‌هایی توجه کنیم.

به زبان ساده، Quality Model به ما کمک می‌کند به جای اینکه فقط بگوییم:

«این Software خوب است.»

سؤال‌های دقیق‌تری مطرح کنیم:

• از نظر Functional چطور است؟
• از نظر Reliability چطور است؟
• از نظر Performance چطور است؟
• از نظر Security چطور است؟
• از نظر Usability چطور است؟
• از نظر Maintainability چطور است؟

چرا به Quality Model نیاز داریم؟

بدون یک مدل یا چارچوب مشخص، ارزیابی Quality می‌تواند بسیار سلیقه‌ای شود.

فرض کنید در یک جلسه، مدیر Product می‌گوید:

«به نظر من Software کیفیت خوبی دارد.»

Tester می‌گوید:

«من چندین مشکل مهم پیدا کرده‌ام، پس Quality پایین است.»

Developer می‌گوید:

«Codebase ما تمیز است و مشکل خاصی نداریم.»

هر سه نفر ممکن است از دیدگاه خودشان درست بگویند.

اما بدون یک چارچوب مشترک، تعریف Quality بین افراد مختلف متفاوت خواهد بود.

Quality Model کمک می‌کند تیم یک زبان مشترک برای صحبت درباره Quality داشته باشد.

ISO/IEC 25010؛ یکی از شناخته‌شده‌ترین مدل‌های کیفیت نرم افزار

یکی از شناخته‌شده‌ترین چارچوب‌ها برای توصیف Software Quality، استاندارد ISO/IEC 25010 است.

این استاندارد Quality را از چندین زاویه مختلف بررسی می‌کند و به تیم‌ها کمک می‌کند هنگام تعریف، ارزیابی و اندازه‌گیری Quality دید ساختاریافته‌تری داشته باشند.

در نسخه رایج مدل Quality Characteristics، ویژگی‌های اصلی شامل موارد زیر هستند:

• Functional Suitability
• Performance Efficiency
• Compatibility
• Usability
• Reliability
• Security
• Maintainability
• Portability

هرکدام از این Characteristics نیز می‌توانند به Subcharacteristicهای دقیق‌تری تقسیم شوند.

هدف ما در این مقاله بررسی تمام جزئیات استاندارد نیست؛ بلکه می‌خواهیم بفهمیم چنین مدل‌هایی چگونه نگاه ما به Quality را منظم می‌کنند.

Quality Model به ما چه چیزی می‌دهد؟

فرض کنید یک تیم در حال توسعه یک سیستم پرداخت آنلاین است.

اگر فقط Functional Requirements را بررسی کنیم، ممکن است تمرکز تیم روی این باشد که:

• کاربر بتواند پرداخت کند.
• مبلغ درست محاسبه شود.
• رسید صادر شود.

اما Quality Model باعث می‌شود سؤال‌های بیشتری مطرح شوند:

• اگر سرویس Payment موقتاً در دسترس نباشد چه می‌شود؟
• اگر هزاران کاربر هم‌زمان پرداخت کنند چه اتفاقی می‌افتد؟
• آیا اطلاعات حساس محافظت شده‌اند؟
• آیا کاربر می‌تواند خطاهای پرداخت را به‌راحتی درک کند؟
• آیا سیستم در Browserها و محیط‌های موردنظر درست کار می‌کند؟
• آیا تغییر قوانین پرداخت در آینده به‌راحتی امکان‌پذیر است؟

در نتیجه Quality Model کمک می‌کند Blind Spotهای احتمالی را بهتر ببینیم.

Quality Model با Test Plan یکی نیست

این دو مفهوم ممکن است با یکدیگر اشتباه گرفته شوند.

Quality Model مشخص می‌کند چه جنبه‌هایی از Quality مهم هستند.

Test Plan مشخص می‌کند برای ارزیابی Software چه رویکرد و فعالیت‌های Testی انجام خواهیم داد.

مثلاً Quality Model می‌گوید:

Performance برای این Product مهم است.

اما Test Plan ممکن است مشخص کند:

• Load Testing انجام شود.
• Response Time اندازه‌گیری شود.
• رفتار سیستم در Peak Load بررسی شود.

بنابراین Model و Plan نقش متفاوتی دارند.

یک اشتباه رایج: تبدیل Quality Model به Checklist

گاهی تیم‌ها یک Quality Model را دریافت می‌کنند و آن را به یک Checklist ثابت تبدیل می‌کنند:

• ☐ Performance تست شد.
• ☐ Security تست شد.
• ☐ Usability تست شد.
• ☐ Compatibility تست شد.

این کار می‌تواند مفید باشد، اما اگر بدون توجه به Context انجام شود، مشکل‌ساز خواهد شد.

فرض کنید یک سیستم داخلی سازمانی داریم که فقط ۲۰ کاربر دارد.

آیا باید همان سطح Performance Testing را برای آن انجام دهیم که برای یک سیستم پرداخت عمومی با میلیون‌ها کاربر انجام می‌دهیم؟

احتمالاً نه.

Quality Model نقشه راه است؛ نه یک Checklist ثابت که برای همه Softwareها دقیقاً یکسان اجرا شود.

Quality Model و Risk-Based Thinking

یکی از کاربردهای مهم Quality Model این است که به تیم کمک می‌کند Quality را با Risk ترکیب کند.

فرض کنید یک سیستم پزشکی داریم.

در این سیستم Reliability و Safety ممکن است اهمیت بسیار بالایی داشته باشند.

در یک Application سرگرمی ممکن است همان سطح از Risk وجود نداشته باشد.

بنابراین تیم باید ابتدا Quality Attributes مهم را شناسایی کند و سپس بر اساس Risk مشخص کند:

• کدام Attributeها اولویت بالاتری دارند؟
• چه سطحی از Quality قابل قبول است؟
• کدام قسمت‌ها باید بیشتر تست شوند؟
• چه نوع Evidenceای لازم است؟

Quality Requirement چیست؟

یکی از مشکلات رایج در پروژه‌ها این است که Quality Attributes فقط به‌صورت کلی مطرح می‌شوند.

مثلاً گفته می‌شود:

«سیستم باید سریع باشد.»

اما «سریع» دقیقاً یعنی چه؟

اگر این Requirement به شکل قابل اندازه‌گیری تعریف نشود، ممکن است Developer، Tester و Product Manager برداشت‌های متفاوتی از آن داشته باشند.

مثلاً می‌توان Requirement را دقیق‌تر کرد:

«در شرایط بار مورد انتظار، ۹۵٪ درخواست‌های Search باید در کمتر از ۲ ثانیه پاسخ داده شوند.»

حالا Requirement قابل ارزیابی‌تر شده است.

این موضوع نشان می‌دهد Quality باید تا حد امکان از یک مفهوم مبهم به Quality Requirement قابل بررسی تبدیل شود.

داستان؛ «سیستم باید سریع باشد»

در یک پروژه، Product Manager در جلسه Requirement می‌گوید:

«این صفحه باید خیلی سریع باز شود.»

Developer آن را به شکل خودش تفسیر می‌کند.

Tester نیز معیار دیگری در ذهن دارد.

پس از Release، Product Manager ناراضی است و می‌گوید:

«این صفحه هنوز کند است!»

Developer پاسخ می‌دهد:

«اما سرعت صفحه نسبت به نسخه قبلی دو برابر بهتر شده است.»

هر دو نفر ممکن است از دیدگاه خودشان درست بگویند.

مشکل اصلی این است که Requirement از ابتدا دقیق نبوده است.

💡 Quality قابل اندازه‌گیری، معمولاً از Requirement قابل اندازه‌گیری شروع می‌شود.

Quality Model در عمل چگونه استفاده می‌شود؟

یک تیم می‌تواند برای هر Product یک Quality Profile ایجاد کند.

برای مثال:

Attribute	Priority	سؤال کلیدی
Reliability	بسیار بالا	آیا سیستم در شرایط مورد انتظار پایدار می‌ماند؟
Security	بسیار بالا	آیا اطلاعات و عملیات حساس محافظت شده‌اند؟
Performance	بالا	آیا Response Time قابل قبول است؟
Usability	بالا	آیا کاربر می‌تواند بدون سردرگمی کار خود را انجام دهد؟
Maintainability	متوسط	آیا تغییرات آینده با هزینه قابل قبول انجام می‌شوند؟

سپس برای Attributes مهم‌تر، Requirement و Strategy مناسب تعریف می‌شود.

Quality Model قرار نیست همه مشکلات را حل کند

داشتن یک Quality Model به این معنی نیست که Software حتماً باکیفیت خواهد بود.

Model فقط کمک می‌کند:

• موضوعات مهم را فراموش نکنیم.
• زبان مشترکی برای صحبت درباره Quality داشته باشیم.
• Quality Requirements را بهتر تعریف کنیم.
• Riskها را بهتر اولویت‌بندی کنیم.
• برای ارزیابی Software دید ساختاریافته‌تری داشته باشیم.

در نهایت این تصمیم‌ها و فعالیت‌های تیم هستند که Quality واقعی را شکل می‌دهند.

Quality Model و نگاه حرفه‌ای به Testing

برای Tester، Quality Model یک مزیت مهم دارد: کمک می‌کند Test Strategy فقط حول Functional Requirements شکل نگیرد.

مثلاً وقتی می‌دانیم Reliability یک Attribute مهم است، سؤال‌های Testing نیز تغییر می‌کنند.

• سیستم در Failure چه رفتاری دارد؟
• آیا Recovery درست انجام می‌شود؟
• آیا داده‌ها پس از Failure سالم می‌مانند؟
• آیا سیستم در شرایط غیرعادی پایدار است؟

یا اگر Accessibility اهمیت بالایی داشته باشد، Testing باید سناریوهای مرتبط با کاربران دارای نیازهای مختلف را نیز پوشش دهد.

در نتیجه Quality Model می‌تواند مستقیماً روی Test Strategy اثر بگذارد.

جمع‌بندی بخش چهارم 🎯

Quality Modelها کمک می‌کنند Software Quality را از یک مفهوم کلی و مبهم به مجموعه‌ای از Characteristics و Subcharacteristics قابل بررسی تبدیل کنیم.

• Quality Model یک چارچوب برای نگاه کردن به Quality است.
• ISO/IEC 25010 یکی از مدل‌های شناخته‌شده در این حوزه است.
• Quality Model با Test Plan یا Checklist یکسان نیست.
• همه Quality Attributes برای همه Productها اهمیت یکسان ندارند.
• Quality باید با Context و Risk ترکیب شود.
• Quality Requirements باید تا حد امکان مشخص و قابل اندازه‌گیری باشند.
• Quality Model می‌تواند روی Test Strategy تأثیر مستقیم داشته باشد.

در بخش بعدی به سراغ یکی از مهم‌ترین پایه‌های Quality می‌رویم: Requirement Quality و اینکه چگونه Requirementهای ضعیف می‌توانند حتی قبل از شروع Development، مسیر Software را به سمت Quality پایین هدایت کنند.

نقش Requirement در Software Quality؛ کیفیت از کجا شروع می‌شود؟

تا اینجا درباره Quality Attributes و Quality Modelها صحبت کردیم. اما یک سؤال مهم‌تر وجود دارد:

اگر از ابتدا ندانیم دقیقاً چه چیزی باید ساخته شود، چطور می‌توانیم کیفیت آن را ارزیابی کنیم؟

اینجاست که Requirement اهمیت پیدا می‌کند.

Software قبل از اینکه Code شود، معمولاً ابتدا در قالب نیازها، اهداف، قوانین، User Storyها، Acceptance Criteria و سایر Artefactها تعریف می‌شود.

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

یک Requirement خوب چه ارتباطی با Quality دارد؟

فرض کنید Requirement سیستم این باشد:

«کاربر باید بتواند سریع خرید خود را انجام دهد.»

در نگاه اول Requirement ساده‌ای به نظر می‌رسد.

اما چند سؤال مهم ایجاد می‌شود:

• «سریع» یعنی چند ثانیه؟
• در چه شرایطی؟
• با چه تعداد کاربر هم‌زمان؟
• در چه دستگاهی؟
• کدام بخش فرآیند باید سریع باشد؟
• حد قابل قبول برای کاربر چیست؟

اگر این موارد مشخص نباشند، تیم نمی‌تواند یک Quality Expectation روشن ایجاد کند.

Requirement ناقص چگونه به Bug تبدیل می‌شود؟

فرض کنید Product Owner می‌گوید:

«اگر موجودی محصول تمام شد، کاربر نباید بتواند خرید کند.»

Developer این Requirement را پیاده‌سازی می‌کند.

Tester نیز بررسی می‌کند که وقتی موجودی صفر است، دکمه خرید غیرفعال شود.

Test Pass می‌شود.

اما در Production، دو کاربر تقریباً هم‌زمان آخرین موجودی محصول را خریداری می‌کنند.

مشکل چیست؟

Requirement درباره Concurrent Purchase چیزی نگفته بود.

در نتیجه ممکن است چیزی که در ابتدا به‌عنوان «Bug نرم‌افزاری» دیده می‌شود، ریشه در Requirement ناقص داشته باشد.

همه مشکلات Quality، Bugهای Code نیستند

این یکی از مهم‌ترین نکاتی است که باید در Software Quality درک کنیم.

وقتی کاربر با یک مشکل مواجه می‌شود، اولین واکنش ممکن است این باشد:

«پس Software Bug دارد.»

اما همیشه این‌طور نیست.

مشکل ممکن است از یکی از این مراحل آمده باشد:

• Requirement
• Product Decision
• UX Design
• Architecture
• Implementation
• Configuration
• Deployment
• Infrastructure
• Integration

بنابراین وقتی درباره Quality صحبت می‌کنیم، بهتر است فقط به محل مشاهده Failure نگاه نکنیم؛ بلکه به Root Cause آن نیز توجه داشته باشیم.

داستان؛ فیچری که کاملاً درست ساخته شد اما اشتباه بود

تصور کنید یک تیم محصول تصمیم می‌گیرد یک Feature جدید برای یک فروشگاه آنلاین ایجاد کند: مقایسه چند محصول کنار هم.

تیم Development ماه‌ها روی آن کار می‌کند.

• UI زیباست.
• Backend درست کار می‌کند.
• APIها تست شده‌اند.
• Performance مناسب است.
• Bugهای مهم برطرف شده‌اند.
• Automation Testها Pass می‌شوند.

Feature منتشر می‌شود.

اما کاربران تقریباً از آن استفاده نمی‌کنند.

آیا Feature از نظر Software Quality ضعیف است؟

نه لزوماً.

ممکن است Software Quality این Feature بسیار خوب باشد، اما تصمیم Product از ابتدا بر اساس یک نیاز واقعی کاربر شکل نگرفته باشد.

این همان مرزی است که باید بین Software Quality و مفاهیمی مانند Product Value و Product Success حفظ کنیم.

در این مقاله فقط همین مرز را مشخص می‌کنیم و وارد تحلیل عمیق Product Value نمی‌شویم.

Requirement Quality فقط درباره کامل بودن نیست

وقتی از Requirement Quality صحبت می‌کنیم، منظور فقط این نیست که Requirement «زیاد» یا «کم» باشد.

یک Requirement خوب معمولاً ویژگی‌هایی مانند موارد زیر دارد:

• Clear: ابهام غیرضروری نداشته باشد.
• Consistent: با سایر Requirementها تناقض نداشته باشد.
• Complete: اطلاعات ضروری برای درک رفتار موردنظر را داشته باشد.
• Testable: امکان بررسی و ارزیابی آن وجود داشته باشد.
• Feasible: از نظر فنی و کسب‌وکاری قابل اجرا باشد.
• Traceable: ارتباط آن با هدف یا نیاز مربوطه قابل پیگیری باشد.

این ویژگی‌ها کمک می‌کنند Requirement به ورودی بهتری برای Design، Development و Testing تبدیل شود.

Requirement قابل تست چرا مهم است؟

فرض کنید Requirement می‌گوید:

«سیستم باید امنیت بالایی داشته باشد.»

این جمله نیت خوبی دارد، اما برای Testing کافی نیست.

Tester نمی‌تواند به‌سادگی بگوید:

«Security را تست کردم و ۸۷٪ خوب بود.»

باید بدانیم دقیقاً چه Security Expectationsای وجود دارند.

برای مثال ممکن است Requirementهای مشخص‌تری تعریف شوند:

• کاربر بدون Authentication نباید به اطلاعات حساب دسترسی داشته باشد.
• کاربر نباید بتواند اطلاعات کاربر دیگر را مشاهده کند.
• Passwordها نباید به شکل Plain Text ذخیره شوند.
• Session باید پس از شرایط مشخص منقضی شود.

حالا Testability بسیار بهتر شده است.

Non-Functional Requirements و Quality

بخش مهمی از Quality Attributes در قالب Non-Functional Requirements یا Requirementهای کیفی بیان می‌شوند.

برای مثال:

• Response Time
• Availability
• Security
• Usability
• Scalability
• Accessibility

اما یک نکته مهم وجود دارد:

Non-Functional به معنی «غیرمهم» یا «فرعی» نیست.

در بسیاری از سیستم‌ها، شکست در یک Non-Functional Requirement می‌تواند بسیار جدی‌تر از یک Functional Bug باشد.

یک مثال؛ همه چیز درست است، اما سیستم قابل استفاده نیست

فرض کنید یک فرم ثبت درخواست ساخته شده است.

از نظر Functional:

• تمام فیلدها کار می‌کنند.
• Validationها درست هستند.
• اطلاعات در Database ذخیره می‌شود.
• پیام موفقیت نمایش داده می‌شود.

اما فرم برای یک Screen Reader قابل استفاده نیست.

یا متن خطا آن‌قدر نامشخص است که کاربر نمی‌فهمد چه چیزی را باید اصلاح کند.

در اینجا Functional Requirements برآورده شده‌اند، اما Quality از جنبه‌های دیگر می‌تواند مشکل داشته باشد.

Shift Left؛ هرچه زودتر، بهتر

از اینجا به مفهوم مهمی در Software Quality می‌رسیم: Shift Left.

ایده ساده است:

هرچه زودتر بتوانیم یک مشکل را شناسایی کنیم، معمولاً اصلاح آن ساده‌تر و کم‌هزینه‌تر خواهد بود.

اگر Requirement در مرحله تحلیل مشخص کند که یک Feature ابهام دارد، اصلاح آن معمولاً بسیار ساده‌تر از زمانی است که همان مشکل بعد از Development، Testing و Release کشف شود.

به همین دلیل حضور افراد با دید Quality در مراحل اولیه پروژه می‌تواند ارزش زیادی ایجاد کند.

Tester چه نقشی در Requirement Quality دارد؟

Tester الزاماً نویسنده Requirement نیست.

اما می‌تواند با پرسیدن سؤال‌های درست، ابهام‌ها و Riskهای احتمالی را زودتر آشکار کند.

• اگر این اتفاق بیفتد چه می‌شود؟
• اگر سرویس خارجی در دسترس نباشد چه می‌شود؟
• حد قابل قبول Performance چیست؟
• چه کسانی از این Feature استفاده می‌کنند؟
• رفتار سیستم در حالت Error چیست؟
• آیا این Requirement قابل Test است؟
• آیا Edge Caseهای مهم مشخص شده‌اند؟

این سؤال‌ها می‌توانند قبل از نوشته شدن حتی یک خط Code، مشکلات مهمی را آشکار کنند.

Requirement خوب، تضمین‌کننده Quality نیست

نباید از بحث‌های این بخش به یک نتیجه افراطی برسیم.

Requirement خوب بسیار مهم است، اما به‌تنهایی Software باکیفیت تولید نمی‌کند.

حتی اگر Requirementها کاملاً شفاف باشند، هنوز ممکن است مشکلاتی در:

• Design
• Architecture
• Implementation
• Integration
• Testing
• Deployment
• Infrastructure

ایجاد شوند.

بنابراین Quality حاصل یک زنجیره است، نه نتیجه یک مرحله واحد.

یک زنجیره ساده از Requirement تا Quality

Requirement
↓
Design
↓
Architecture
↓
Implementation
↓
Testing
↓
Deployment
↓
Real-World Usage

هر مرحله می‌تواند Quality را تقویت یا تضعیف کند.

به همین دلیل وقتی یک مشکل در Production مشاهده می‌شود، سؤال حرفه‌ای فقط این نیست که:

«کدام خط Code اشتباه است؟»

بلکه باید پرسید:

«این مشکل چرا در مراحل قبلی شناسایی یا پیشگیری نشد؟»

جمع‌بندی بخش پنجم 🎯

Quality از مرحله Testing شروع نمی‌شود؛ بلکه بخش مهمی از آن از همان زمان شکل‌گیری Requirementها تعیین می‌شود.

• Requirement مبهم می‌تواند باعث برداشت‌های متفاوت شود.
• Requirement ناقص می‌تواند Edge Caseهای مهم را پنهان کند.
• همه مشکلات Quality الزاماً Bug در Code نیستند.
• Non-Functional Requirements بخش مهمی از Software Quality را شکل می‌دهند.
• Requirementهای قابل تست، ارزیابی Quality را ساده‌تر می‌کنند.
• Shift Left کمک می‌کند مشکلات زودتر شناسایی شوند.
• Tester می‌تواند با پرسیدن سؤال‌های درست به بهبود Requirement Quality کمک کند.
• Requirement خوب لازم است، اما به‌تنهایی تضمین‌کننده Software Quality نیست.

در بخش بعدی، یک قدم جلوتر می‌رویم و بررسی می‌کنیم Software Quality در مراحل مختلف Software Development Lifecycle چگونه شکل می‌گیرد و چرا Quality نباید مسئولیت یک مرحله یا یک تیم خاص تلقی شود.

Software Quality در چرخه توسعه نرم افزار؛ کیفیت در کدام مرحله ساخته می‌شود؟

اگر از یک تیم نرم‌افزاری بپرسیم «چه کسی مسئول Quality است؟»، ممکن است پاسخ‌های متفاوتی بشنویم.

• «QA مسئول Quality است.»
• «Tester باید کیفیت را بررسی کند.»
• «Developer باید Code بدون Bug بنویسد.»
• «Product باید Requirement درست تعریف کند.»

هرکدام بخشی از واقعیت را بیان می‌کنند؛ اما هیچ‌کدام به‌تنهایی پاسخ کاملی نیستند.

Software Quality نتیجه عملکرد یک مرحله یا یک نقش واحد نیست؛ نتیجه تعامل تمام مراحل و افراد در چرخه عمر Software است.

Quality از Requirement شروع می‌شود، اما همان‌جا تمام نمی‌شود

در بخش قبل دیدیم که Requirement ضعیف می‌تواند از همان ابتدا مسیر Software را به سمت مشکلات مختلف هدایت کند.

اما حتی Requirement عالی نیز تضمین نمی‌کند که Software نهایی باکیفیت باشد.

تصور کنید Requirement کاملاً واضح است، اما Architecture مناسبی انتخاب نشده است.

یا Architecture خوب است، اما Implementation اشتباه انجام شده است.

یا Code درست است، اما Deployment اشتباه انجام شده است.

یا همه این موارد درست هستند، اما رفتار سیستم در Production با چیزی که در محیط Test دیده شده متفاوت است.

بنابراین Quality باید در طول چرخه عمر Software مدیریت و محافظت شود.

Quality در مرحله Discovery و Product Definition

قبل از اینکه Development شروع شود، معمولاً تصمیم‌های مهمی درباره Product گرفته می‌شود.

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

• کاربر چه نیازی دارد؟
• Product قرار است چه مسئله‌ای را حل کند؟
• چه محدودیت‌هایی وجود دارد؟
• چه Riskهایی مهم هستند؟
• چه Quality Attributesهایی برای Product اهمیت بیشتری دارند؟

تصمیم‌های این مرحله می‌توانند تأثیر زیادی روی Quality آینده داشته باشند.

برای مثال اگر از ابتدا مشخص باشد که سیستم باید در شرایط Peak Traffic پایدار بماند، Architecture و Test Strategy نیز باید این نیاز را در نظر بگیرند.

Quality در مرحله Design

در مرحله Design، تصمیم‌هایی گرفته می‌شوند که مستقیماً روی تجربه کاربر و رفتار Software تأثیر دارند.

مثلاً:

• ساختار صفحات چگونه باشد؟
• خطاها چگونه به کاربر نمایش داده شوند؟
• Flowهای اصلی چگونه طراحی شوند؟
• برای کاربران مختلف چه محدودیت‌هایی در نظر گرفته شود؟
• چه حالاتی باید در UI پوشش داده شوند؟

یک Design ضعیف می‌تواند حتی با Implementation کاملاً صحیح، تجربه نامناسبی ایجاد کند.

Quality در Architecture

تصمیم‌های Architecture معمولاً اثر بلندمدتی روی Quality دارند.

برای مثال انتخاب یک Architecture نامناسب ممکن است در آینده باعث شود:

• Scale کردن سیستم دشوار شود.
• Failure یک Service روی بخش‌های دیگر اثر زنجیره‌ای بگذارد.
• تغییرات کوچک نیازمند تغییرات گسترده باشند.
• Testing برخی بخش‌ها بسیار دشوار شود.
• Performance در Load بالا افت کند.

در اینجا Quality دیگر فقط مسئله‌ای مربوط به UI یا Bugهای قابل مشاهده نیست؛ بلکه با ساختار فنی سیستم نیز ارتباط دارد.

Quality در مرحله Development

در مرحله Implementation، تصمیم‌ها و اشتباهات Developer می‌توانند Quality را مستقیماً تحت تأثیر قرار دهند.

• Bugهای Functional
• مشکلات Error Handling
• Security Vulnerability
• Memory Leak
• Race Condition
• Code Complexity
• مشکلات Maintainability

اما اینجا نیز یک نکته مهم وجود دارد:

Developer مسئول ایجاد Quality است، اما مالک انحصاری Quality نیست.

Quality در مرحله Code Review

Code Review یکی از نقاطی است که می‌تواند مشکلات را قبل از رسیدن به محیط Test یا Production آشکار کند.

در Code Review ممکن است مواردی مانند این‌ها بررسی شوند:

• Correctness
• Readability
• Maintainability
• Security
• Error Handling
• Consistency

البته Code Review نیز جای Testing را نمی‌گیرد؛ هرکدام هدف متفاوتی دارند.

Quality در مرحله Testing

در این مرحله Software از زوایای مختلف ارزیابی می‌شود تا اطلاعات بیشتری درباره رفتار واقعی آن به دست آید.

Testing می‌تواند شامل مواردی مانند:

• Functional Testing
• Integration Testing
• System Testing
• End-to-End Testing
• Performance Testing
• Security Testing
• Accessibility Testing
• Compatibility Testing

باشد.

هدف Testing فقط پیدا کردن Bug نیست؛ Testing اطلاعاتی درباره Risk و رفتار Software در اختیار تیم قرار می‌دهد.

داستان؛ «QA آخر خط است»

در یک تیم، Developerها Feature را توسعه می‌دهند و در پایان Sprint آن را به Tester تحویل می‌دهند.

یک روز Product Manager می‌گوید:

«چرا QA این‌قدر Bug پیدا می‌کند؟ Sprint را عقب انداختید!»

Tester پاسخ می‌دهد:

«من تازه Feature را دریافت کرده‌ام. خیلی از مشکلات قبل از اینکه به من برسد قابل پیشگیری بودند.»

مشکل این تیم این نیست که Tester زیاد Bug پیدا می‌کند.

مشکل این است که Quality را به انتهای چرخه منتقل کرده‌اند.

Shift Left؛ Quality را به ابتدای چرخه نزدیک کنیم

ایده Shift Left می‌گوید فعالیت‌های مربوط به Quality را تا حد امکان زودتر وارد چرخه توسعه کنیم.

یعنی به جای اینکه صبر کنیم Feature ساخته شود و سپس بپرسیم:

«آیا این Feature مشکل دارد؟»

از ابتدا سؤال کنیم:

«چه چیزی ممکن است باعث شود این Feature با مشکل مواجه شود؟»

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

Quality در مرحله CI/CD

در تیم‌های مدرن، Quality نباید فقط به یک مرحله Manual Testing محدود شود.

Pipelineهای CI/CD می‌توانند بخشی از کنترل‌های Quality را به‌صورت خودکار اجرا کنند.

• Unit Test
• Integration Test
• Static Analysis
• Linting
• Security Checks
• Build Validation
• Automated Regression Tests

این Automation باعث می‌شود برخی مشکلات قبل از Deployment شناسایی شوند.

Quality در مرحله Deployment

حتی اگر Software در محیط Test کاملاً سالم باشد، Deployment اشتباه می‌تواند باعث Failure شود.

برای مثال:

• Configuration اشتباه باشد.
• Environment Variable مقدار نادرست داشته باشد.
• نسخه اشتباه Database Migration اجرا شود.
• Service Dependency در Production در دسترس نباشد.
• Infrastructure ظرفیت کافی نداشته باشد.

بنابراین Deployment نیز بخشی از زنجیره Quality است.

Quality در Production تمام نمی‌شود

یکی از تفاوت‌های مهم Software واقعی با یک پروژه آزمایشگاهی این است که رفتار واقعی Software را نمی‌توان فقط در محیط Test شناخت.

پس از Release، تیم باید بتواند متوجه شود:

• آیا سیستم پایدار است؟
• آیا Errorها افزایش یافته‌اند؟
• آیا Performance افت کرده است؟
• آیا کاربران با مشکل خاصی مواجه هستند؟
• آیا Failure جدیدی در محیط واقعی رخ داده است؟

اینجاست که Monitoring، Logging، Alerting و User Feedback اهمیت پیدا می‌کنند.

Production یک منبع مهم اطلاعات Quality است

فرض کنید تمام Testهای ما Pass شده‌اند، اما پس از Release می‌بینیم نرخ خطای پرداخت افزایش یافته است.

این اطلاعات نشان می‌دهد تصویر ما از Quality کامل نبوده است.

Production می‌تواند اطلاعاتی درباره شرایطی ارائه دهد که همیشه در محیط Test قابل بازسازی نیستند.

Quality Loop؛ یک چرخه مداوم

به همین دلیل Software Quality را بهتر است یک چرخه بدانیم:

Plan → Design → Develop → Test → Deploy → Observe → Learn → Improve

پس از Production، اطلاعات جدیدی به تیم می‌رسد و این اطلاعات می‌تواند روی Requirement، Design و تصمیم‌های Releaseهای بعدی اثر بگذارد.

Quality بنابراین یک فعالیت یک‌باره نیست؛ یک Continuous Process است.

آیا همه اعضای تیم به یک اندازه مسئول Quality هستند؟

این سؤال نیاز به دقت دارد.

بهتر است به جای اینکه بگوییم:

«همه مسئول همه چیز هستند.»

بگوییم:

هر نقش، بخشی از Quality را تحت تأثیر قرار می‌دهد و مسئولیت‌های مشخصی در قبال آن دارد.

Product می‌تواند روی کیفیت تصمیم و Requirement اثر بگذارد.

Designer روی تجربه و Usability اثر می‌گذارد.

Developer روی Implementation و Technical Quality اثر می‌گذارد.

Tester با ارزیابی Software و آشکار کردن Riskها به تصمیم‌گیری بهتر کمک می‌کند.

DevOps و تیم‌های Infrastructure روی Reliability، Deployment و Observability اثر دارند.

این نقش‌ها جای یکدیگر را نمی‌گیرند، بلکه در کنار هم Quality را شکل می‌دهند.

یک نگاه مهم برای Tester

Tester حرفه‌ای فقط نمی‌پرسد:

«چه Test Caseهایی باید اجرا کنم؟»

بلکه از خود می‌پرسد:

«در کدام مرحله از چرخه توسعه می‌توانستیم این Risk را زودتر ببینیم؟»

این نوع نگاه باعث می‌شود Testing از یک فعالیت انتهای چرخه به بخشی از تفکر Quality در کل چرخه تبدیل شود.

جمع‌بندی بخش ششم 🎯

Software Quality در یک نقطه خاص از SDLC ساخته نمی‌شود. از Requirement و Design گرفته تا Development، Testing، Deployment و Production، هر مرحله می‌تواند روی Quality تأثیر بگذارد.

• Quality فقط مسئولیت Tester نیست.
• Requirement و Design می‌توانند Quality آینده را شکل دهند.
• Architecture روی بسیاری از Quality Attributes اثر بلندمدت دارد.
• Testing اطلاعات مهمی درباره Risk و رفتار Software فراهم می‌کند.
• CI/CD می‌تواند برخی کنترل‌های Quality را خودکار کند.
• Deployment و Infrastructure نیز می‌توانند منبع Failure باشند.
• Production و User Feedback اطلاعات ارزشمندی درباره Quality واقعی ارائه می‌کنند.
• Quality بهتر است به‌عنوان یک Continuous Process دیده شود.

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

آیا Software Quality قابل اندازه‌گیری است؟

تا اینجا Quality را از جنبه‌های مختلف بررسی کردیم؛ اما یک سؤال اساسی باقی می‌ماند:

آیا می‌توان Quality یک Software را با عدد و Metric اندازه‌گیری کرد؟

پاسخ کوتاه این است: تا حدی بله.

اما یک نکته مهم وجود دارد: Software Quality یک مفهوم چندبعدی است و نمی‌توان آن را با یک عدد واحد خلاصه کرد.

برای مثال نمی‌توان گفت:

«Quality این Software برابر با ۸۷٪ است.»

مگر اینکه دقیقاً مشخص کرده باشیم این عدد چگونه محاسبه شده و چه چیزی را نشان می‌دهد.

چرا اندازه‌گیری Quality دشوار است؟

Quality یک ویژگی واحد نیست.

یک Software ممکن است:

• Functional بسیار خوبی داشته باشد.
• Performance ضعیفی داشته باشد.
• Security مناسبی داشته باشد.
• Usability ضعیفی داشته باشد.
• Maintainability بسیار خوبی داشته باشد.

بنابراین وقتی می‌گوییم «این Software باکیفیت است»، باید مشخص کنیم درباره کدام جنبه Quality صحبت می‌کنیم.

Measurement، Metric و KPI چه تفاوتی دارند؟

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

Measurement

Measurement به فرآیند یا نتیجه به‌دست‌آوردن یک مقدار اشاره دارد.

مثلاً:

Response Time یک درخواست برابر با ۱.۸ ثانیه اندازه‌گیری شد.

Metric

Metric یک معیار کمی است که برای توصیف یا ارزیابی یک ویژگی استفاده می‌شود.

مثلاً:

• Error Rate
• Response Time
• Defect Density
• Test Pass Rate
• Availability

KPI

KPI یا Key Performance Indicator معمولاً شاخصی است که برای ارزیابی عملکرد در ارتباط با یک هدف مشخص استفاده می‌شود.

بنابراین هر Metric الزاماً KPI نیست.

مهم‌ترین Metricهای مرتبط با Software Quality

هیچ لیست واحدی برای تمام پروژه‌ها وجود ندارد؛ اما بسته به نوع Product و Risk، Metricهای مختلفی می‌توانند مفید باشند.

Defect Metrics

• تعداد Defectها
• Defect Density
• Defect Severity
• Defect Leakage
• Defect Reopen Rate

این Metricها می‌توانند تصویری از وضعیت Defectها ارائه دهند؛ اما به‌تنهایی نمی‌توانند کیفیت کلی Software را مشخص کنند.

Test Metrics

• Test Execution Rate
• Test Pass Rate
• Test Coverage
• Automation Coverage
• Regression Test Results

این شاخص‌ها درباره فعالیت‌های Testing اطلاعات می‌دهند، اما باید مراقب باشیم آنها را با خود Quality اشتباه نگیریم.

Production Metrics

• Error Rate
• Availability
• Crash Rate
• Incident Rate
• Mean Time to Recovery

این Metricها می‌توانند اطلاعات ارزشمندی درباره رفتار Software در محیط واقعی ارائه کنند.

Performance Metrics

• Response Time
• Latency
• Throughput
• Resource Utilization
• Error Rate under Load

برای Productهایی که Performance اهمیت زیادی دارد، این شاخص‌ها می‌توانند بخش مهمی از Quality Assessment باشند.

یک اشتباه خطرناک: «Bug کمتر یعنی Quality بیشتر»

فرض کنید دو محصول داریم.

Product A در یک ماه ۲۰ Bug گزارش کرده است.

Product B فقط ۵ Bug دارد.

آیا می‌توان نتیجه گرفت Product B کیفیت بالاتری دارد؟

خیر.

ممکن است کاربران Product B مشکلات زیادی داشته باشند اما Bugها را گزارش نکنند.

یا تیم Product A بسیار فعال‌تر و دقیق‌تر در شناسایی و ثبت Bugها باشد.

حتی ممکن است Product B بسیار کوچک‌تر باشد و طبیعتاً Defect کمتری داشته باشد.

💡 یک Metric بدون Context می‌تواند به‌جای کمک، تصمیم‌گیری را گمراه کند.

یک اشتباه دیگر: «Test Pass Rate بالا یعنی Quality بالا»

فرض کنید ۹۹٪ Test Caseهای یک Release Pass شده‌اند.

این عدد در نگاه اول عالی به نظر می‌رسد.

اما چند سؤال مهم وجود دارد:

• آیا Testها سناریوهای مهم را پوشش می‌دادند؟
• آیا Test Caseها به‌روز بودند؟
• آیا Riskهای اصلی پوشش داده شده بودند؟
• آیا Non-Functional Testing انجام شده بود؟
• آیا Test Environment مشابه Production بود؟

اگر پاسخ این سؤال‌ها منفی باشد، Pass Rate بالا ممکن است تصویر اشتباهی از Quality ایجاد کند.

Test Coverage نیز Quality را تضمین نمی‌کند

Coverage Metric مفیدی است، اما باید درست تفسیر شود.

مثلاً Code Coverage برابر ۹۰٪ به این معنی نیست که:

«۹۰٪ Software تست شده و ۱۰٪ آن تست نشده است.»

Code Coverage فقط نشان می‌دهد چه میزان از Code در جریان اجرای Testها پوشش داده شده است؛ کیفیت Assertions و سناریوهای تست‌شده را به‌تنهایی مشخص نمی‌کند.

ممکن است Testها Code را اجرا کنند، اما رفتار اشتباه را تشخیص ندهند.

Metric خوب چه ویژگی‌ای دارد؟

یک Metric زمانی ارزشمندتر است که:

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

مورد آخر بسیار مهم است.

وقتی Metric تبدیل به هدف می‌شود

فرض کنید مدیر تیم اعلام کند:

«هدف تیم QA این است که Test Pass Rate به ۹۹٪ برسد.»

ممکن است تیم به‌جای بهتر کردن Quality، ناخودآگاه به سمت بالا بردن عدد حرکت کند.

برای مثال:

• Test Caseهای سخت حذف شوند.
• سناریوهای مهم از Scope خارج شوند.
• Testها بیش از حد ساده شوند.
• Failureها به‌جای تحلیل، فقط به Pass تبدیل شوند.

در این حالت Metric به هدف تبدیل شده و رفتار تیم را به سمت بهینه‌سازی عدد، نه Quality واقعی، هدایت می‌کند.

وقتی Metric تبدیل به Target شود، ممکن است دیگر Metric خوبی نباشد.

Quality Dashboard باید چه چیزی را نشان دهد؟

یک Quality Dashboard خوب قرار نیست ده‌ها عدد را کنار هم نمایش دهد.

هدف آن باید کمک به تصمیم‌گیری باشد.

برای مثال یک Dashboard می‌تواند ترکیبی از این اطلاعات را نشان دهد:

• Defectهای Critical و High باز
• Production Incidentها
• Error Rate
• Availability
• Test Coverage مرتبط با Riskهای مهم
• Regression وضعیت
• Trend کیفیت در Releaseهای اخیر

مهم‌تر از تعداد Metricها، ارتباط آنها با Risk و تصمیم‌های واقعی تیم است.

Trend معمولاً از یک عدد مهم‌تر است

فرض کنید در یک Release تعداد Bugهای Critical برابر ۳ باشد.

این عدد به‌تنهایی اطلاعات زیادی نمی‌دهد.

اما اگر بدانیم:

• Release قبلی: ۸ مورد
• Release فعلی: ۳ مورد
• Release بعدی: ۱ مورد

ممکن است نشانه‌ای از بهبود وضعیت باشد.

برعکس، اگر روند از ۱ به ۳ و سپس ۷ رسیده باشد، باید بررسی بیشتری انجام شود.

بنابراین Trend در بسیاری از موارد از یک Snapshot ارزشمندتر است.

آیا User Feedback یک Quality Metric است؟

User Feedback می‌تواند اطلاعات مهمی درباره Quality ارائه کند، اما نباید هر Feedback را مستقیماً به یک Metric تبدیل کنیم.

برای مثال اگر کاربران مرتباً بگویند:

«فرآیند Checkout گیج‌کننده است.»

این یک Signal مهم درباره Usability است.

تیم می‌تواند این Signal را بررسی و در صورت امکان با داده‌های دیگر مانند Drop-off Rate یا Support Tickets ترکیب کند.

یک تصویر کامل‌تر از Quality

برای ارزیابی Quality بهتر است به جای یک Metric، مجموعه‌ای از Evidenceها را در کنار یکدیگر ببینیم:

Testing Evidence + Production Data + Defect Data + Performance Data + User Feedback + Risk Analysis

هیچ‌کدام به‌تنهایی تصویر کاملی ارائه نمی‌کنند، اما کنار هم می‌توانند درک بسیار بهتری از وضعیت Quality ایجاد کنند.

جمع‌بندی بخش هفتم 🎯

Software Quality تا حدی قابل اندازه‌گیری است، اما نمی‌توان آن را با یک عدد واحد خلاصه کرد.

• Quality چندبعدی است.
• Metricها باید در Context مناسب تفسیر شوند.
• Bug Count به‌تنهایی معیار Quality نیست.
• Test Pass Rate به‌تنهایی کیفیت را تضمین نمی‌کند.
• Code Coverage نشان‌دهنده کیفیت Testها نیست.
• Metric نباید بدون توجه به Risk و هدف استفاده شود.
• Trendها معمولاً اطلاعات بیشتری از یک عدد منفرد ارائه می‌کنند.
• Production Data و User Feedback می‌توانند Evidence مهمی درباره Quality باشند.
• ترکیب چند Evidence معمولاً تصویر قابل‌اعتماد‌تری از Quality ایجاد می‌کند.

در بخش بعدی، وارد یکی از مهم‌ترین مرزهای این بحث می‌شویم: Software Quality در برابر Product Success؛ یعنی چرا ممکن است یک Software از نظر فنی و کیفی بسیار خوب باشد، اما Product در بازار موفق نشود.

Software Quality در برابر Product Success؛ آیا Software خوب حتماً موفق است؟

یکی از مهم‌ترین سوءتفاهم‌ها درباره Software Quality این است که گاهی موفقیت Product مستقیماً به Quality نرم‌افزار نسبت داده می‌شود.

مثلاً ممکن است یک Product در بازار موفق نباشد و بلافاصله این سؤال مطرح شود:

«پس Software کیفیت خوبی نداشته است؟»

اما این نتیجه‌گیری همیشه درست نیست.

ممکن است Software از نظر Technical Quality بسیار خوب باشد، اما Product به دلایل دیگری موفق نشود.

یک Software می‌تواند باکیفیت باشد اما Product موفق نباشد

فرض کنید یک تیم، یک Application جدید توسعه داده است.

• Architecture مناسب است.
• Code کیفیت خوبی دارد.
• Bugهای مهم بسیار کم هستند.
• Performance مناسب است.
• Security به‌خوبی پیاده‌سازی شده است.
• UI از نظر فنی درست کار می‌کند.
• Testing به‌صورت گسترده انجام شده است.

اما بعد از Launch، کاربران استقبال چندانی نمی‌کنند.

آیا می‌توان گفت Software بی‌کیفیت بوده است؟

نه.

ممکن است مسئله این باشد که Product مسئله مهمی را برای بازار هدف حل نمی‌کند یا کاربران به آن Featureها نیازی ندارند.

مثال اول؛ کمپین Marketing ضعیف

فرض کنید یک تیم Software بسیار خوبی برای یک Product ساخته است.

Product آماده Launch است و کمپین Marketing اجرا می‌شود.

اما کمپین عملکرد ضعیفی دارد:

• مخاطب هدف به‌درستی انتخاب نشده است.
• پیام Campaign واضح نیست.
• Reach کافی ایجاد نشده است.
• کانال Marketing مناسب نبوده است.
• ارزش Product به‌درستی منتقل نشده است.

در نتیجه کاربران کمی وارد Product می‌شوند.

در این شرایط ممکن است Business Outcome ضعیف باشد، اما این موضوع به‌تنهایی نشان نمی‌دهد که Software Quality پایین بوده است.

Marketing Failure و Software Quality Failure دو مسئله متفاوت هستند؛ هرچند ممکن است در نتیجه نهایی کسب‌وکار کنار هم دیده شوند.

مثال دوم؛ Feature عالی برای یک نیاز اشتباه

فرض کنید تیم Product بر اساس فرضی که درباره کاربران دارد، Feature جدیدی طراحی می‌کند.

Development انجام می‌شود و نتیجه فنی بسیار خوب است.

• Feature درست کار می‌کند.
• Edge Caseها پوشش داده شده‌اند.
• Performance مناسب است.
• Security رعایت شده است.
• Automation Testها Pass شده‌اند.

اما پس از Release، کاربران تقریباً از Feature استفاده نمی‌کنند.

دلیل ممکن است ساده باشد:

کاربران اصلاً چنین مسئله‌ای نداشته‌اند.

در اینجا یک نکته بسیار مهم وجود دارد:

«Feature درست ساخته شده» با «Feature درست انتخاب شده» یکسان نیست.

Software Quality بیشتر به کیفیت Software و انطباق آن با Requirements و Quality Expectations مربوط است؛ اما اینکه آیا این Feature اصلاً باید ساخته می‌شد، مسئله‌ای گسترده‌تر در سطح Product و Business است.

مثال سوم؛ Product بسیار خوب، بازار نامناسب

ممکن است تیمی Software بسیار باکیفیتی بسازد، اما:

• بازار هدف کوچک باشد.
• رقیب قدرتمندی وجود داشته باشد.
• Timing نامناسب باشد.
• مدل Pricing مناسب نباشد.
• کانال Distribution مناسب نباشد.

در نتیجه Product موفق نشود.

هیچ‌کدام از این موارد به‌تنهایی اثبات نمی‌کنند که Software Quality پایین بوده است.

پس Software Quality هیچ ارتباطی با Product Success ندارد؟

این هم نتیجه‌گیری اشتباهی است.

Software Quality می‌تواند روی موفقیت Product تأثیر بسیار زیادی داشته باشد.

مثلاً تصور کنید یک Application بانکی:

• مرتب Crash کند.
• Transactionها با خطا مواجه شوند.
• اطلاعات کاربران افشا شود.
• Performance بسیار ضعیفی داشته باشد.
• در شرایط Peak Load از دسترس خارج شود.

در این شرایط Quality پایین می‌تواند مستقیماً روی اعتماد کاربران و موفقیت Product تأثیر بگذارد.

بنابراین رابطه این دو بهتر است به این شکل دیده شود:

Software Quality → می‌تواند روی Product Success اثر بگذارد
اما Product Success ← فقط تابع Software Quality نیست

یک مدل ذهنی ساده

می‌توانیم موفقیت یک Product را حاصل تعامل چند حوزه مختلف در نظر بگیریم:

Product Decisions
＋
Software Quality
＋
UX
＋
Marketing
＋
Business Model
＋
Market Conditions

این مدل یک فرمول ریاضی نیست؛ فقط کمک می‌کند موفقیت Product را به یک علت واحد نسبت ندهیم.

مرز مهم: Quality vs. Value

یکی از مهم‌ترین تفاوت‌ها این است که Quality و Value الزاماً یک چیز نیستند.

ممکن است یک Feature:

• از نظر Engineering بسیار باکیفیت باشد.
• از نظر Usability مناسب باشد.
• Bug بسیار کمی داشته باشد.
• Performance خوبی داشته باشد.

اما Value کمی برای کاربران ایجاد کند.

در مقابل، ممکن است یک Feature ساده از نظر فنی باشد اما مسئله بسیار مهمی را برای کاربران حل کند.

در این مقاله لازم نیست وارد بحث عمیق Product Value شویم؛ نکته اصلی فقط این است که Quality و Value را نباید مترادف یکدیگر بدانیم.

آیا Tester باید Product Success را تضمین کند؟

خیر.

Tester می‌تواند اطلاعات ارزشمندی درباره Quality، Risk و رفتار واقعی Software ارائه کند، اما مسئولیت تضمین موفقیت تجاری Product را بر عهده ندارد.

برای مثال Tester می‌تواند بگوید:

«این Feature مطابق Requirement کار می‌کند، اما در تست Usability مشاهده کردیم کاربران در این مرحله دچار سردرگمی می‌شوند.»

این اطلاعات می‌تواند برای Product Team بسیار ارزشمند باشد.

اما تصمیم درباره اینکه Feature ادامه پیدا کند، تغییر کند یا حذف شود، یک تصمیم Product است.

یک اشتباه رایج در تحلیل نتایج

گاهی بعد از یک Release ضعیف، تیم تلاش می‌کند یک علت واحد پیدا کند.

«فروش پایین بود؛ پس Software مشکل داشت.»

یا:

«Bug زیادی نداشتیم؛ پس Product موفق می‌شود.»

هر دو نوع تحلیل می‌توانند اشتباه باشند.

برای تحلیل درست باید عوامل مختلف را از هم تفکیک کنیم و سپس ارتباط احتمالی آنها را بررسی کنیم.

چه زمانی شکست Product واقعاً می‌تواند به Quality مرتبط باشد؟

اگر کاربران Product را امتحان کنند اما به دلیل مشکلات Software نتوانند از آن استفاده کنند، رابطه بسیار مستقیم‌تر می‌شود.

• Application مرتب Crash می‌کند.
• Checkout در مرحله پرداخت شکست می‌خورد.
• صفحات اصلی بسیار کند هستند.
• کاربران نمی‌توانند Login کنند.
• اطلاعات اشتباه نمایش داده می‌شود.
• Security Incident اعتماد کاربران را از بین می‌برد.
• Accessibility ضعیف باعث می‌شود بخشی از کاربران نتوانند از Product استفاده کنند.

در چنین شرایطی می‌توان گفت Quality Failure احتمالاً مستقیماً در Product Outcome نقش داشته است.

یک چارچوب ساده برای تحلیل

وقتی یک Product نتیجه مطلوبی نمی‌گیرد، می‌توان ابتدا سؤال را به چند بخش تقسیم کرد:

• Acquisition: آیا کاربران مناسب اصلاً وارد Product شدند؟
• Activation: آیا توانستند از Product استفاده کنند؟
• Experience: آیا تجربه استفاده مناسب بود؟
• Quality: آیا Software به شکل قابل اعتماد کار کرد؟
• Value: آیا Product مسئله ارزشمندی را حل می‌کرد؟

این تفکیک کمک می‌کند مشکل Marketing را با مشکل Software یا Product اشتباه نگیریم.

چرا این تفکیک برای QA مهم است؟

اگر QA هر Failure کسب‌وکاری را به Software Quality نسبت دهد، ممکن است تیم به سمت حل مسئله اشتباه برود.

مثلاً اگر کمپین Marketing ضعیف باشد و کاربران کمی وارد Product شوند، افزایش تعداد Test Caseها احتمالاً مشکل را حل نمی‌کند.

یا اگر Feature از نظر فنی عالی باشد اما کسی به آن نیاز نداشته باشد، اجرای Regression Test بیشتر، مسئله اصلی را حل نخواهد کرد.

نقش حرفه‌ای QA این است که Evidence مربوط به Software Quality را ارائه کند و مرز آن را با سایر عوامل روشن نگه دارد.

یک مثال نهایی؛ سه سناریوی کاملاً متفاوت

وضعیت	Software Quality	نتیجه Product	مشکل اصلی
کمپین ضعیف	خوب	ضعیف	Marketing / Acquisition
Feature بدون نیاز واقعی	خوب	ضعیف	Product Decision / Value
Application ناپایدار	ضعیف	ضعیف	Software Quality

این جدول یک نکته کلیدی را نشان می‌دهد:

نتیجه ضعیف Product به‌تنهایی Evidence کافی برای نتیجه‌گیری درباره Software Quality نیست.

جمع‌بندی بخش هشتم 🎯

Software Quality و Product Success با یکدیگر ارتباط دارند، اما یک مفهوم نیستند.

• Software باکیفیت می‌تواند در بازاریابی ضعیف، شکست Product را تجربه کند.
• یک Feature می‌تواند از نظر فنی عالی باشد اما نیاز واقعی کاربر نباشد.
• Product Success تحت تأثیر عوامل متعددی قرار دارد.
• Software Quality می‌تواند یکی از عوامل مهم Product Success باشد، اما تنها عامل نیست.
• Quality و Product Value را نباید مترادف دانست.
• Tester مسئول تضمین موفقیت تجاری Product نیست.
• QA باید با Evidence و داده صحبت کند، نه اینکه هر Failure کسب‌وکاری را Bug تلقی کند.

در بخش بعدی، به یک سؤال مهم‌تر می‌رسیم: Quality از دید چه کسی تعریف می‌شود؟ نگاه Developer، Tester، Product، Business و User ممکن است متفاوت باشد و همین تفاوت، یکی از چالش‌های اصلی در تعریف Software Quality است.

Quality از دید چه کسی؟ تفاوت نگاه User، Product، Developer و Tester

تا اینجا درباره ابعاد مختلف Software Quality صحبت کردیم؛ اما هنوز یک سؤال مهم باقی مانده است:

چه کسی تعیین می‌کند یک Software باکیفیت است؟

ممکن است پاسخ ساده به نظر برسد: «کاربر».

اما در یک Software واقعی، افراد مختلف با اهداف و مسئولیت‌های متفاوت درباره Quality قضاوت می‌کنند.

برای یک Developer، Quality ممکن است بیشتر با Code و Architecture مرتبط باشد. برای Tester، Risk و رفتار Software اهمیت زیادی دارد. برای Product Manager، تحقق نیازهای Product مهم است و برای User، چیزی که در نهایت تجربه می‌کند اهمیت بیشتری دارد.

یک Software، چند نگاه متفاوت به Quality

فرض کنید یک فروشگاه اینترنتی داریم که در صفحه Checkout، پرداخت کار می‌کند اما انجام آن حدود ۱۰ ثانیه طول می‌کشد.

Developer ممکن است بگوید:

«از نظر Code مشکلی وجود ندارد و همه Testها Pass شده‌اند.»

Tester ممکن است بگوید:

«Functional Requirement درست پیاده شده، اما Performance قابل قبول نیست.»

Product Manager ممکن است بگوید:

«تعداد زیادی از کاربران قبل از تکمیل خرید خارج می‌شوند.»

و User احتمالاً فقط می‌گوید:

«این سایت خیلی کند است.»

همه این افراد درباره یک سیستم صحبت می‌کنند، اما از زاویه متفاوتی به Quality نگاه می‌کنند.

Quality از دید User

User معمولاً Software را با Architecture، Code Quality یا Test Coverage ارزیابی نمی‌کند.

او بیشتر با سؤال‌هایی مانند این مواجه است:

• آیا می‌توانم کاری را که می‌خواهم انجام دهم؟
• آیا Software قابل اعتماد است؟
• آیا سریع پاسخ می‌دهد؟
• آیا استفاده از آن ساده است؟
• آیا اطلاعات من امن هستند؟
• وقتی مشکلی رخ می‌دهد، آیا سیستم رفتار قابل فهمی دارد؟

بنابراین ممکن است یک Software از دید Engineering بسیار خوب باشد، اما از دید User تجربه ضعیفی ایجاد کند.

Quality از دید Product

Product Team معمولاً به این موضوع توجه دارد که Software تا چه اندازه نیازهای تعریف‌شده برای Product را برآورده می‌کند.

• آیا Feature مطابق Requirement ساخته شده است؟
• آیا User Flow موردنظر درست کار می‌کند؟
• آیا Release آماده ارائه است؟
• آیا Riskهای مهم شناخته شده‌اند؟

برای Product، Quality می‌تواند ارتباط نزدیکی با تجربه واقعی کاربر و اهداف Product داشته باشد.

Quality از دید Developer

Developer معمولاً بخش مهمی از Quality را در سطح فنی می‌بیند.

• Code خوانا باشد.
• Architecture قابل نگهداری باشد.
• Dependencyها به شکل مناسبی مدیریت شوند.
• Error Handling درست باشد.
• Security رعایت شود.
• Performance مناسب باشد.
• Technical Debt کنترل شود.

این موارد بسیار مهم هستند، زیرا Technical Quality ضعیف می‌تواند در آینده هزینه تغییر و نگهداری Software را افزایش دهد.

Quality از دید Tester

Tester معمولاً Software را از منظر Risk و رفتار سیستم بررسی می‌کند.

سؤال‌هایی مانند این برای Tester اهمیت دارند:

• چه چیزی ممکن است اشتباه پیش برود؟
• آیا Requirement به‌درستی پیاده شده است؟
• آیا Edge Caseها پوشش داده شده‌اند؟
• رفتار سیستم در شرایط غیرعادی چگونه است؟
• آیا Regression ایجاد شده است؟
• آیا Quality Attributes مهم بررسی شده‌اند؟

بنابراین Tester فقط به این موضوع نگاه نمی‌کند که «Feature کار می‌کند یا نه»؛ بلکه می‌خواهد بفهمد Software در شرایط مختلف چگونه رفتار خواهد کرد.

Quality از دید Business

Business ممکن است Quality را از زاویه‌ای متفاوت بررسی کند.

برای مثال:

• آیا سیستم قابل اتکا است؟
• آیا Incidentهای مهم کاهش یافته‌اند؟
• آیا Downtime قابل قبول است؟
• آیا تغییرات بدون ایجاد مشکلات جدی Release می‌شوند؟
• آیا هزینه نگهداری Software قابل کنترل است؟

در اینجا Quality با Reliability، Operational Risk و هزینه‌های ناشی از Failure ارتباط پیدا می‌کند.

آیا یکی از این دیدگاه‌ها درست‌تر است؟

معمولاً نه.

هر دیدگاه بخش متفاوتی از Quality را نشان می‌دهد.

مشکل زمانی ایجاد می‌شود که یک دیدگاه، تمام مفهوم Quality را به خودش محدود کند.

مثال؛ «Code عالی است، پس Software عالی است»

فرض کنید تیم توسعه یک سیستم بسیار تمیز و Maintainable ساخته است.

Code Reviewها عالی هستند و Automated Testها نیز Coverage مناسبی دارند.

اما User برای انجام ساده‌ترین عملیات باید از هفت صفحه عبور کند.

از دید Developer ممکن است Quality فنی عالی باشد.

اما از دید User، Software تجربه مناسبی ایجاد نمی‌کند.

پس Technical Quality بالا لزوماً به معنی User Experience عالی نیست.

مثال؛ «کاربر راضی است، پس Code عالی است»

حالت برعکس نیز ممکن است اتفاق بیفتد.

ممکن است Software فعلاً برای User به‌خوبی کار کند، اما Code آن بسیار پیچیده و شکننده باشد.

در کوتاه‌مدت User مشکلی نمی‌بیند.

اما چند ماه بعد، اضافه کردن یک Feature ساده باعث ایجاد چندین Regression می‌شود.

این نمونه‌ای از تفاوت بین Quality قابل مشاهده برای User و Technical Quality است.

Requirement به‌عنوان نقطه اتصال دیدگاه‌ها

یکی از راه‌های کاهش این اختلاف، شفاف کردن Quality Expectations از ابتدای پروژه است.

برای مثال به جای اینکه فقط بگوییم:

«صفحه Checkout باید سریع باشد.»

می‌توان Requirement را دقیق‌تر کرد:

«در شرایط مشخص، زمان پاسخ Checkout باید کمتر از مقدار تعیین‌شده باشد.»

در این حالت Product، Developer و Tester برداشت نزدیک‌تری از انتظار Quality خواهند داشت.

Quality Expectations باید قابل گفتگو باشند

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

برای مثال:

• Product می‌گوید: «Feature آماده است.»
• Developer می‌گوید: «Code تمام شده است.»
• Tester می‌گوید: «هنوز Riskهای مهم بررسی نشده‌اند.»
• Business می‌گوید: «Release باید پایدار باشد.»

همه این جملات ممکن است هم‌زمان درست باشند.

مشکل، نبودن یک تعریف مشترک از معیارهای Release است.

Definition of Done و Quality

در تیم‌های Agile، Definition of Done می‌تواند بخشی از این انتظار مشترک را مشخص کند.

برای مثال ممکن است تیم توافق کند یک Feature زمانی Done محسوب شود که:

• Implementation کامل شده باشد.
• Code Review انجام شده باشد.
• Testهای لازم اجرا شده باشند.
• Defectهای Critical باز وجود نداشته باشند.
• Acceptance Criteria تأیید شده باشند.
• Documentation موردنیاز تکمیل شده باشد.

Definition of Done به‌تنهایی Quality را تضمین نمی‌کند، اما می‌تواند انتظارات تیم را شفاف‌تر کند.

Quality یک مفهوم Negotiated هم هست

در دنیای واقعی همیشه امکان دستیابی به حداکثر Quality در همه ابعاد وجود ندارد.

گاهی تیم باید بین سرعت Release، هزینه، Scope، Performance، Maintainability و Risk تصمیم بگیرد.

این به معنی بی‌اهمیت بودن Quality نیست؛ بلکه یعنی Quality باید در Context واقعی Product و Riskهای آن مدیریت شود.

نقش QA در ایجاد زبان مشترک Quality

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

مثلاً اگر Product Manager می‌گوید «این Feature آماده است»، QA می‌تواند سؤال کند:

«برای اینکه آن را Ready بدانیم، چه Quality Criteriaهایی باید برقرار باشند؟»

این سؤال می‌تواند باعث شود معیارهایی که قبلاً ضمنی بودند، به معیارهای قابل مشاهده و قابل بررسی تبدیل شوند.

از «کیفیت خوب است» به «کیفیت طبق چه معیاری؟»

یکی از عادت‌های مهم در تفکر QA این است که جملات مبهم را به معیارهای مشخص تبدیل کنیم.

عبارت مبهم	سؤال بهتر
سیستم سریع است.	Response Time قابل قبول چقدر است؟
سیستم امن است.	چه Riskهای Security بررسی شده‌اند؟
Feature آماده است.	چه Acceptance و Quality Criteriaهایی تأیید شده‌اند؟
UI خوب است.	Usability و Accessibility چگونه ارزیابی شده‌اند؟
سیستم پایدار است.	چه شواهدی از Reliability در اختیار داریم؟

هدف این نیست که همه‌چیز را به یک عدد تبدیل کنیم؛ هدف این است که درباره Quality با زبان دقیق‌تری صحبت کنیم.

جمع‌بندی بخش نهم 🎯

Quality از دید افراد مختلف می‌تواند متفاوت باشد، زیرا هر نقش با هدف و مسئولیت متفاوتی به Software نگاه می‌کند.

• User بیشتر تجربه، قابلیت استفاده و اعتمادپذیری را می‌بیند.
• Product به تحقق نیازها و کیفیت Release توجه دارد.
• Developer روی Technical Quality تمرکز می‌کند.
• Tester رفتار Software و Riskها را بررسی می‌کند.
• Business به Reliability، Risk و هزینه‌های Failure توجه دارد.
• هیچ‌یک از این دیدگاه‌ها به‌تنهایی کل Quality را توضیح نمی‌دهد.
• Quality Expectations باید تا حد امکان از ابتدا شفاف شوند.
• Definition of Done می‌تواند بخشی از انتظارات Quality را مشخص کند.
• QA می‌تواند به ایجاد زبان مشترک درباره Quality کمک کند.

در بخش بعدی، به یکی از مهم‌ترین مفاهیم این مقاله می‌رسیم: Quality Attributes؛ یعنی ویژگی‌هایی مانند Reliability، Performance، Security، Usability و Maintainability که مشخص می‌کنند Software فقط «کار می‌کند» یا واقعاً از جنبه‌های مختلف کیفیت قابل قبولی دارد.

Quality Attributes؛ Software خوب فقط Softwareی نیست که کار می‌کند

وقتی می‌گوییم یک Software «کار می‌کند»، معمولاً منظورمان این است که Functionهای مورد انتظار را انجام می‌دهد.

اما آیا همین موضوع برای اینکه Software را باکیفیت بدانیم کافی است؟

خیر. Software ممکن است از نظر Functional درست باشد، اما از جنبه‌های دیگری کیفیت قابل قبولی نداشته باشد.

برای مثال یک Application بانکی ممکن است امکان انتقال وجه را به‌درستی انجام دهد، اما اگر برای هر درخواست ۳۰ ثانیه زمان نیاز داشته باشد، مرتب Crash کند یا در برابر حملات امنیتی آسیب‌پذیر باشد، نمی‌توان صرفاً به دلیل درست انجام دادن عملیات انتقال وجه آن را Software باکیفیت دانست.

Quality Attribute چیست؟

Quality Attribute ویژگی‌ای از Software است که یک جنبه از کیفیت آن را توصیف می‌کند.

به زبان ساده، به جای اینکه فقط بپرسیم:

«آیا سیستم این کار را انجام می‌دهد؟»

می‌پرسیم:

«این کار را با چه کیفیتی انجام می‌دهد؟»

همین تفاوت، یکی از مهم‌ترین مرزهای بین Functional Quality و سایر ابعاد Software Quality است.

Functional بودن با Quality داشتن یکسان نیست

فرض کنید یک فروشگاه اینترنتی داریم.

کاربر محصولی را انتخاب می‌کند، آن را به Cart اضافه می‌کند و در نهایت سفارش ثبت می‌شود.

از نظر Functional، سیستم درست کار کرده است.

اما حالا چند سؤال دیگر مطرح می‌کنیم:

• آیا صفحه Cart سریع باز می‌شود؟
• آیا در زمان Load بالا سیستم پایدار می‌ماند؟
• آیا اطلاعات پرداخت امن هستند؟
• آیا کاربران دارای محدودیت‌های دسترسی می‌توانند از سیستم استفاده کنند؟
• آیا تغییر دادن این بخش در آینده آسان است؟
• اگر یک Service از کار بیفتد، چه اتفاقی برای سفارش می‌افتد؟

این سؤال‌ها ما را وارد دنیای Quality Attributes می‌کنند.

مهم‌ترین Quality Attributes

بسته به نوع Software، استاندارد مورد استفاده و Context پروژه، دسته‌بندی‌ها می‌توانند متفاوت باشند. اما برخی Quality Attributeها تقریباً در بسیاری از پروژه‌ها اهمیت دارند.

• Reliability
• Performance Efficiency
• Security
• Usability
• Accessibility
• Maintainability
• Compatibility
• Scalability
• Availability
• Portability

البته همه این Attributes در همه پروژه‌ها اهمیت یکسانی ندارند.

Reliability؛ آیا می‌توان به Software اعتماد کرد؟

Reliability به توانایی Software برای انجام عملکرد مورد انتظار به‌صورت پایدار و بدون Failure در شرایط مشخص اشاره دارد.

مثلاً در یک سیستم بانکی، فقط درست بودن عملیات انتقال وجه کافی نیست.

سیستم باید بتواند این عملیات را به‌صورت قابل اعتماد و در شرایط مختلف انجام دهد.

Failureهای مکرر، Crash، از دست رفتن Transaction یا رفتارهای غیرقابل پیش‌بینی می‌توانند نشانه‌هایی از مشکل در Reliability باشند.

Performance؛ سیستم چقدر خوب و سریع عمل می‌کند؟

Performance فقط به «سرعت» محدود نمی‌شود.

معیارهایی مانند Response Time، Latency، Throughput و Resource Utilization می‌توانند برای ارزیابی Performance مورد استفاده قرار گیرند.

مثلاً ممکن است یک API در شرایط عادی Response Time مناسبی داشته باشد، اما در زمان افزایش تعداد کاربران Performance آن به‌شدت افت کند.

در این حالت Software از نظر Functional ممکن است درست باشد، اما Performance آن در شرایط واقعی قابل قبول نیست.

Security؛ آیا Software در برابر تهدیدها مقاوم است؟

Security یکی از مهم‌ترین ابعاد Quality در بسیاری از Softwareها است.

موضوعاتی مانند Authentication، Authorization، Data Protection، Session Management و Input Validation می‌توانند بخشی از این حوزه باشند.

یک سیستم ممکن است تمام Functionهای خود را به‌درستی انجام دهد اما به دلیل یک Security Vulnerability، Software قابل قبولی محسوب نشود.

Usability؛ آیا استفاده از Software آسان است؟

Usability به تجربه و سهولت استفاده کاربران از Software مربوط می‌شود.

فرض کنید کاربر باید برای انجام یک عملیات ساده، چندین مرحله غیرضروری را طی کند یا دائماً با پیام‌های نامفهوم مواجه شود.

ممکن است Function کاملاً درست باشد، اما Usability ضعیف باشد.

Accessibility؛ آیا Software برای طیف گسترده‌ای از کاربران قابل استفاده است؟

Accessibility به این موضوع می‌پردازد که افراد با توانایی‌ها و شرایط مختلف تا چه حد می‌توانند از Software استفاده کنند.

برای مثال:

• آیا کاربر می‌تواند با Keyboard در سیستم حرکت کند؟
• آیا تصاویر دارای متن جایگزین مناسب هستند؟
• آیا Contrast عناصر کافی است؟
• آیا پیام‌های خطا برای کاربران قابل درک هستند؟
• آیا Screen Reader می‌تواند محتوای مهم را به‌درستی تشخیص دهد؟

Accessibility بخشی از Quality است که گاهی در پروژه‌ها نادیده گرفته می‌شود، در حالی که برای بخشی از کاربران کاملاً حیاتی است.

Maintainability؛ تغییر دادن Software چقدر دشوار است؟

Software فقط برای امروز ساخته نمی‌شود.

در طول زمان باید Bugها اصلاح شوند، Featureهای جدید اضافه شوند و نیازهای Product تغییر کنند.

Maintainability نشان می‌دهد Software تا چه اندازه برای تحلیل، تغییر و نگهداری مناسب است.

Code بسیار پیچیده، Dependencyهای نامناسب و Architecture ضعیف می‌توانند Maintainability را کاهش دهند.

Compatibility؛ آیا Software در محیط‌های مختلف درست کار می‌کند؟

Software ممکن است در یک محیط کاملاً درست کار کند اما در محیط دیگری مشکل داشته باشد.

برای مثال:

• Browserهای مختلف
• سیستم‌عامل‌های مختلف
• Deviceهای مختلف
• نسخه‌های مختلف API
• Configurationهای مختلف

Compatibility کمک می‌کند Software را فقط در یک محیط محدود ارزیابی نکنیم.

Scalability؛ وقتی تعداد کاربران چند برابر شود چه اتفاقی می‌افتد؟

فرض کنید Application امروز با ۱۰۰ کاربر بدون مشکل کار می‌کند.

اما اگر تعداد کاربران به ۱۰۰ هزار نفر برسد چه اتفاقی خواهد افتاد؟

Scalability به توانایی Software و زیرساخت برای مدیریت رشد بار و منابع مورد نیاز مربوط می‌شود.

این موضوع مخصوصاً برای سیستم‌های آنلاین، SaaS و سرویس‌هایی که رشد سریع دارند اهمیت زیادی پیدا می‌کند.

Availability؛ Software چه مقدار در دسترس است؟

Availability به میزان در دسترس بودن سیستم برای استفاده در یک بازه زمانی مشخص اشاره دارد.

برای مثال یک سرویس آنلاین که مرتباً از دسترس خارج می‌شود، حتی اگر هنگام Available بودن کاملاً Functional باشد، از نظر Quality مشکل جدی دارد.

آیا همه Quality Attributes باید حداکثر باشند؟

خیر.

این یکی از نکات مهم در Software Quality است.

هدف این نیست که هر Software را در تمام Attributes به بالاترین سطح ممکن برسانیم.

هدف این است که برای هر Product مشخص کنیم کدام Attributes مهم‌تر هستند و چه سطحی از Quality برای آنها مورد نیاز است.

Quality Attributes بر اساس نوع Software متفاوت‌اند

تصور کنید سه سیستم مختلف داریم:

نوع Software	Attributes مهم‌تر
سیستم بانکی	Security، Reliability، Availability
فروشگاه اینترنتی	Performance، Availability، Usability
نرم‌افزار داخلی سازمان	Maintainability، Usability، Reliability

این جدول فقط یک مثال ساده است و اولویت واقعی باید بر اساس Risk و نیازهای همان Product تعیین شود.

Quality Attributeها معمولاً به هم وابسته‌اند

یکی از دلایلی که Quality پیچیده است، ارتباط بین Attributes مختلف است.

مثلاً افزایش Security ممکن است روی Performance اثر بگذارد.

یا یک Architecture بسیار Flexible ممکن است پیچیدگی بیشتری ایجاد کند و Maintainability را دشوارتر کند.

بنابراین نمی‌توان هر Attribute را کاملاً مستقل از سایر Attributes بررسی کرد.

مثال؛ امنیت بیشتر همیشه بدون هزینه نیست

فرض کنید برای افزایش Security، سیستم از فرآیند Authentication پیچیده‌تری استفاده کند.

Security ممکن است افزایش پیدا کند، اما اگر فرآیند Login بیش از حد پیچیده شود، Usability تحت تأثیر قرار می‌گیرد.

راه‌حل این نیست که یکی از این دو را حذف کنیم؛ بلکه باید بین نیازهای مختلف تعادل مناسبی ایجاد شود.

Quality Attribute یا Functional Requirement؟

یکی از تفاوت‌های مهم این است که Functional Requirement معمولاً بیان می‌کند Software چه کاری باید انجام دهد.

Quality-related Requirement بیشتر درباره این است که Software آن کار را با چه شرایط و سطحی انجام دهد.

نوع	مثال
Functional	کاربر بتواند سفارش خود را ثبت کند.
Performance	ثبت سفارش در شرایط مشخص حداکثر در زمان تعیین‌شده پاسخ دهد.
Security	کاربر بدون مجوز نتواند سفارش سایر کاربران را مشاهده کند.
Availability	سرویس سفارش در بازه مشخص در دسترس باشد.
Accessibility	فرآیند ثبت سفارش با Keyboard نیز قابل انجام باشد.

چرا Quality Attributes برای Tester مهم‌اند؟

اگر Tester فقط Functional Requirementها را بررسی کند، ممکن است بخش مهمی از Riskهای Software را از دست بدهد.

مثلاً ممکن است تمام Test Caseهای Functional Pass شوند، اما:

• سیستم در Load بالا Crash کند.
• اطلاعات حساس در Log ذخیره شوند.
• کاربران Keyboard نتوانند از UI استفاده کنند.
• یک تغییر کوچک باعث Regression گسترده شود.
• سرویس در Production Availability مناسبی نداشته باشد.

شناخت Quality Attributes باعث می‌شود Tester نگاه گسترده‌تری نسبت به کیفیت Software داشته باشد.

یک اشتباه رایج: Quality Attribute یعنی Non-Functional Requirement

این دو اصطلاح بسیار نزدیک هستند و در بسیاری از منابع به شکل متفاوتی استفاده می‌شوند، اما بهتر است آنها را کاملاً مترادف فرض نکنیم.

Quality Attribute یک ویژگی یا جنبه کیفیت است؛ در حالی که Requirement می‌تواند این ویژگی را به یک انتظار مشخص و قابل بررسی تبدیل کند.

مثلاً:

Quality Attribute: Performance

Quality Requirement: 95 درصد درخواست‌ها در شرایط مشخص باید کمتر از X میلی‌ثانیه پاسخ دریافت کنند.

این تفکیک به تیم کمک می‌کند Quality را از یک مفهوم کلی به یک انتظار قابل ارزیابی تبدیل کند.

جمع‌بندی بخش دهم 🎯

Software Quality فقط به این معنی نیست که Software Functionهای مورد انتظار را انجام دهد. Software باید در ابعاد مختلفی مانند Reliability، Performance، Security، Usability، Accessibility و Maintainability نیز انتظارات مناسبی را برآورده کند.

• Quality Attribute یک جنبه از کیفیت Software است.
• Functional بودن به‌تنهایی کیفیت کلی را تضمین نمی‌کند.
• هر Product بر اساس Context و Risk، Quality Attributeهای مهم‌تری دارد.
• Quality Attributes می‌توانند روی یکدیگر اثر بگذارند.
• Functional Requirement مشخص می‌کند Software چه کاری انجام دهد.
• Quality Requirement مشخص می‌کند آن کار با چه سطح یا شرایطی انجام شود.
• Tester باید علاوه بر Functional Behavior، Quality Attributes مهم Product را نیز در نظر بگیرد.

در بخش بعدی، یکی از پایه‌ای‌ترین مفاهیم Quality را بررسی می‌کنیم: Functional Quality و Non-Functional Quality چه تفاوتی دارند و چرا این دو نباید در فرآیند Testing از یکدیگر جدا و بی‌ارتباط دیده شوند؟

Functional Quality و Non-Functional Quality؛ دو بُعد مکمل Software Quality

در بخش قبل دیدیم که Software Quality فقط به درست کار کردن Functionها محدود نمی‌شود. حالا می‌توانیم این موضوع را دقیق‌تر بررسی کنیم.

در بسیاری از پروژه‌ها، Quality را از دو زاویه اصلی بررسی می‌کنیم:

• Functional Quality
• Non-Functional Quality

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

Functional Quality چیست؟

Functional Quality به این موضوع می‌پردازد که Software تا چه اندازه Functionها و رفتارهای مورد انتظار را به‌درستی ارائه می‌کند.

به زبان ساده:

آیا Software کاری را که باید انجام دهد، درست انجام می‌دهد؟

برای مثال در یک فروشگاه اینترنتی:

• آیا کاربر می‌تواند Product را به Cart اضافه کند؟
• آیا قیمت درست محاسبه می‌شود؟
• آیا Coupon به‌درستی اعمال می‌شود؟
• آیا سفارش با اطلاعات صحیح ثبت می‌شود؟
• آیا پرداخت موفق یا ناموفق به‌درستی مدیریت می‌شود؟

این‌ها نمونه‌هایی از رفتارهای Functional سیستم هستند.

Non-Functional Quality چیست؟

Non-Functional Quality به ویژگی‌ها و شرایطی مربوط می‌شود که مشخص می‌کنند Software چگونه Functionهای خود را ارائه می‌کند.

برای مثال:

• چقدر سریع پاسخ می‌دهد؟
• چقدر پایدار است؟
• چقدر امن است؟
• چقدر استفاده از آن آسان است؟
• چقدر در برابر افزایش Load مقیاس‌پذیر است؟
• چقدر قابل نگهداری و تغییر است؟

بنابراین اگر Functional Quality بیشتر به «چه کاری؟» مربوط باشد، Non-Functional Quality بیشتر به «با چه کیفیتی و تحت چه شرایطی؟» مربوط می‌شود.

یک مثال ساده؛ Login

فرض کنید در یک Application، کاربر باید بتواند با Username و Password وارد سیستم شود.

از نظر Functional:

• اطلاعات صحیح باید باعث ورود موفق شوند.
• اطلاعات اشتباه باید رد شوند.
• پیام خطای مناسب نمایش داده شود.

اما از نظر Non-Functional سؤال‌های دیگری مطرح می‌شوند:

• آیا Login در زمان قابل قبول انجام می‌شود؟
• آیا Password به شکل امن منتقل و ذخیره می‌شود؟
• آیا سیستم در برابر تلاش‌های متعدد برای Login مقاوم است؟
• آیا کاربران دارای محدودیت‌های دسترسی می‌توانند از صفحه Login استفاده کنند؟
• آیا Login در Browserها و Deviceهای پشتیبانی‌شده درست کار می‌کند؟

در نتیجه یک Login می‌تواند Functional درست باشد اما از نظر Security یا Performance مشکل داشته باشد.

Functional درست، Non-Functional ضعیف

این سناریو بسیار رایج است.

فرض کنید یک سیستم رزرو آنلاین داریم.

کاربر می‌تواند:

• مقصد را انتخاب کند.
• تاریخ را انتخاب کند.
• رزرو را انجام دهد.
• پرداخت کند.

همه این Functionها درست کار می‌کنند.

اما در زمان افزایش کاربران، هر صفحه ۱۵ ثانیه طول می‌کشد تا باز شود.

از نظر Functional سیستم شاید سالم باشد؛ اما از نظر Performance Quality مشکل جدی دارد.

Non-Functional عالی، Functional ضعیف

حالت برعکس هم ممکن است.

ممکن است Application بسیار سریع، امن و پایدار باشد، اما هنگام ثبت سفارش مبلغ اشتباهی از حساب کاربر کم کند.

در این حالت Non-Functional Quality ممکن است مناسب باشد، اما Functional Quality مشکل جدی دارد.

Software با Performance عالی اما رفتار Functional اشتباه، Software باکیفیتی نیست.

چرا باید هر دو را با هم ببینیم؟

کاربر Software را به‌صورت مجموعه‌ای از ویژگی‌های جداگانه تجربه نمی‌کند.

او یک تجربه کامل دارد.

برای مثال:

«می‌خواهم محصول را بخرم، بدون اینکه سیستم خطا بدهد، اطلاعاتم در خطر باشد یا مجبور شوم چند دقیقه منتظر بمانم.»

از دید User، Functional و Non-Functional Quality در نهایت بخشی از یک تجربه واحد هستند.

Functional و Non-Functional Testing

این تفاوت در Testing نیز اهمیت زیادی دارد.

Functional Testing معمولاً رفتارهای مورد انتظار سیستم را بررسی می‌کند.

• آیا Login انجام می‌شود؟
• آیا سفارش ثبت می‌شود؟
• آیا مبلغ درست محاسبه می‌شود؟
• آیا Permissionها درست اعمال می‌شوند؟

در مقابل، Non-Functional Testing می‌تواند مواردی مانند این‌ها را بررسی کند:

• Performance Testing
• Load Testing
• Stress Testing
• Security Testing
• Usability Testing
• Accessibility Testing
• Compatibility Testing

هرکدام از این Testingها سؤال متفاوتی درباره Quality مطرح می‌کنند.

یک اشتباه رایج: Non-Functional یعنی «چیزهایی که مهم نیستند»

کلمه Non-Functional گاهی باعث سوءبرداشت می‌شود.

ممکن است تصور شود چون چیزی «Non-Functional» نامیده می‌شود، اهمیت کمتری دارد.

در حالی که در بسیاری از Softwareها، یک Non-Functional Failure می‌تواند بسیار جدی‌تر از یک Functional Bug باشد.

برای مثال:

مشکل	پیامد احتمالی
Functional Bug در یک گزارش کم‌اهمیت	اختلال محدود
Performance Failure	از دست رفتن کاربران
Security Vulnerability	افشای اطلاعات
Availability Failure	از دسترس خارج شدن سرویس

بنابراین Non-Functional به معنی «کم‌اهمیت» نیست.

آیا همه Non-Functional Attributes باید برای همه Softwareها تست شوند؟

خیر.

همان‌طور که در بخش Quality Attributes دیدیم، اولویت‌ها به نوع Product و Risk بستگی دارند.

برای یک Application بانکی، Security و Reliability ممکن است بسیار مهم باشند.

برای یک فروشگاه اینترنتی، Performance و Availability اهمیت زیادی پیدا می‌کنند.

برای یک Application مورد استفاده در یک سازمان خاص، Maintainability و Compatibility ممکن است اولویت بیشتری داشته باشند.

اولویت‌بندی بر اساس Risk

بهترین رویکرد این نیست که همه Quality Attributes را بدون توجه به Context با شدت یکسان تست کنیم.

بهتر است ابتدا بپرسیم:

• کدام Failure بیشترین آسیب را ایجاد می‌کند؟
• کدام Quality Attribute برای User مهم‌تر است؟
• کدام بخش Business Critical است؟
• چه الزام قانونی یا امنیتی وجود دارد؟
• چه شرایطی احتمال Failure بیشتری دارند؟

این نگاه باعث می‌شود Testing بر اساس Risk هدایت شود، نه صرفاً بر اساس یک Checklist ثابت.

Quality Attributes باید از ابتدا وارد پروژه شوند

یکی از اشتباهات رایج این است که تیم در پایان Development ناگهان متوجه شود Performance یا Security برای Product بسیار مهم بوده است.

در چنین شرایطی ممکن است اصلاح Architecture یا Design بسیار پرهزینه باشد.

اگر از ابتدا مشخص باشد که مثلاً سیستم باید تعداد زیادی Request هم‌زمان را مدیریت کند، این موضوع می‌تواند روی Architecture، Database، Caching و حتی طراحی API اثر بگذارد.

Quality Attributeها به Acceptance Criteria هم مرتبط‌اند

اگر یک Quality Attribute برای Feature مهم باشد، بهتر است انتظار مربوط به آن تا حد امکان به معیار قابل بررسی تبدیل شود.

مثلاً به جای:

«صفحه باید سریع باشد.»

می‌توان گفت:

«در شرایط تعریف‌شده، پاسخ درخواست باید در محدوده زمانی مورد توافق قرار داشته باشد.»

این کار هم برای Development و هم برای Testing مفید است.

یک مثال ترکیبی؛ صفحه Checkout

فرض کنید می‌خواهیم Checkout یک فروشگاه اینترنتی را ارزیابی کنیم.

بعد Quality	سؤال
Functional	آیا سفارش درست ثبت می‌شود؟
Performance	آیا Checkout در زمان قابل قبول پاسخ می‌دهد؟
Security	آیا اطلاعات پرداخت به شکل امن مدیریت می‌شوند؟
Usability	آیا کاربر به‌راحتی می‌تواند خرید را کامل کند؟
Accessibility	آیا کاربران مختلف می‌توانند فرآیند را کامل کنند؟
Reliability	آیا فرآیند در شرایط مختلف بدون Failure انجام می‌شود؟
Compatibility	آیا Checkout در محیط‌های پشتیبانی‌شده درست کار می‌کند؟

این نگاه نشان می‌دهد یک Feature واحد می‌تواند از چندین زاویه Quality بررسی شود.

آیا Functional و Non-Functional کاملاً از هم جدا هستند؟

در تئوری می‌توان این دو را برای توضیح بهتر از هم تفکیک کرد، اما در Software واقعی مرز آنها همیشه کاملاً جدا نیست.

برای مثال Permission یک رفتار Functional سیستم است، اما Security نیز به آن وابسته است.

یا Error Handling هم می‌تواند بخشی از رفتار Functional باشد و هم روی Reliability و Usability تأثیر بگذارد.

بنابراین بهتر است این دو دسته را به‌عنوان دو زاویه مکمل برای بررسی Quality ببینیم، نه دو دنیای کاملاً جدا.

جمع‌بندی بخش یازدهم 🎯

Functional Quality و Non-Functional Quality هر دو برای ارزیابی Software مهم هستند.

• Functional Quality بررسی می‌کند Software چه کارهایی را درست انجام می‌دهد.
• Non-Functional Quality بررسی می‌کند Software این کارها را با چه سطحی از کیفیت انجام می‌دهد.
• Functional بودن به‌تنهایی Quality کلی را تضمین نمی‌کند.
• Non-Functional به معنی کم‌اهمیت بودن نیست.
• Security، Performance، Reliability، Usability و Accessibility می‌توانند برای Product بسیار حیاتی باشند.
• همه Quality Attributes در همه پروژه‌ها اولویت یکسانی ندارند.
• اولویت Testing باید با توجه به Risk و Context تعیین شود.
• Functional و Non-Functional Testing بهتر است در کنار یکدیگر دیده شوند.

در بخش بعدی، از این تفکیک یک قدم جلوتر می‌رویم و بررسی می‌کنیم که Quality Assurance، Quality Control و Testing دقیقاً چه رابطه‌ای با Software Quality دارند؛ البته بدون ورود عمیق به این سه مفهوم، چون برای آن‌ها مقاله جداگانه خواهیم داشت.

Quality، QA، QC و Testing؛ این مفاهیم دقیقاً چه رابطه‌ای با هم دارند؟

تا اینجا درباره مفهوم Software Quality، ابعاد مختلف آن و تفاوت Functional و Non-Functional Quality صحبت کردیم.

حالا به یکی از نقاطی می‌رسیم که معمولاً باعث سردرگمی می‌شود:

آیا Software Testing همان Quality Assurance است؟ آیا Testing خودش Quality را ایجاد می‌کند؟ و Quality Control چه جایگاهی دارد؟

پاسخ کوتاه این است که این مفاهیم به یکدیگر مرتبط‌اند، اما یکسان نیستند.

Quality یک هدف است، نه فقط یک فعالیت

Software Quality را می‌توان به‌عنوان یکی از اهداف اصلی تیم Product و Engineering در نظر گرفت.

فعالیت‌هایی مانند Requirements Analysis، Design، Development، Code Review، Testing، Monitoring و Feedback همگی می‌توانند روی Quality نهایی Software تأثیر بگذارند.

بنابراین Quality چیزی نیست که فقط در مرحله Testing به Software «اضافه» شود.

Quality نتیجه مجموعه‌ای از تصمیم‌ها و فعالیت‌ها در طول چرخه عمر Software است.

Testing چه نقشی دارد؟

Software Testing یکی از مهم‌ترین فعالیت‌های مرتبط با Quality است، اما تمام Quality نیست.

Testing می‌تواند با اجرای سیستم، بررسی رفتار آن، پیدا کردن Defectها، ارزیابی Riskها و ارائه اطلاعات به تیم کمک کند درباره وضعیت Quality تصمیم‌های بهتری بگیرد.

برای مثال Tester ممکن است متوجه شود:

• یک Business Rule اشتباه پیاده‌سازی شده است.
• یک Feature در شرایط خاص Crash می‌کند.
• Performance در Load بالا افت شدیدی دارد.
• یک Permission به‌درستی اعمال نمی‌شود.
• یک Regression در Release جدید ایجاد شده است.

این اطلاعات برای تصمیم‌گیری درباره Product بسیار ارزشمند هستند.

آیا Tester مسئول Quality است؟

این جمله که «Quality مسئولیت Tester است» یکی از برداشت‌های اشتباه رایج در تیم‌های Software است.

Tester نقش مهمی در Quality دارد، اما نمی‌تواند به‌تنهایی کیفیت یک Product را تضمین کند.

اگر Requirement مبهم باشد، Architecture مشکل داشته باشد، Design مناسب نباشد یا تصمیم‌های Business اشتباه باشند، Testing به‌تنهایی نمی‌تواند همه این مشکلات را برطرف کند.

Quality یک مسئولیت تیمی است

در تیم‌های مدرن Software، Quality معمولاً به‌عنوان یک مسئولیت مشترک دیده می‌شود.

• Product برای نیازهای درست تصمیم می‌گیرد.
• Developer Software را طراحی و پیاده‌سازی می‌کند.
• Tester رفتار و Riskهای سیستم را ارزیابی می‌کند.
• DevOps و تیم‌های Platform به Reliability و Operability کمک می‌کنند.
• Security متخصصان و سایر نقش‌ها نیز در ابعاد خاص Quality مشارکت می‌کنند.

البته این به معنی حذف مسئولیت‌های تخصصی نیست؛ بلکه یعنی Quality نباید در یک نقش واحد محصور شود.

Quality Assurance چیست؟

Quality Assurance یا QA معمولاً به رویکردها و فعالیت‌هایی مربوط می‌شود که هدف آنها کمک به جلوگیری از Defect و بهبود فرآیندهایی است که Software از طریق آنها تولید می‌شود.

در QA تمرکز فقط روی محصول نهایی نیست؛ بلکه Process نیز اهمیت زیادی دارد.

برای مثال موضوعاتی مانند استانداردها، فرآیندهای توسعه، Definition of Done، Code Review، Root Cause Analysis و بهبود فرآیند می‌توانند در این حوزه قرار بگیرند.

از آنجا که شما برای Quality Assurance و Quality Control مقاله‌ای جداگانه دارید، در این مقاله وارد جزئیات این دو مفهوم نمی‌شویم و فقط رابطه آنها با Software Quality را مشخص می‌کنیم.

Quality Control چیست؟

Quality Control یا QC بیشتر بر بررسی و ارزیابی خروجی برای شناسایی Defect یا عدم انطباق با معیارهای مورد انتظار تمرکز دارد.

Testing یکی از فعالیت‌هایی است که می‌تواند در Quality Control نقش داشته باشد، اما QC نیز مفهوم گسترده‌تری از Testing صرف دارد.

رابطه ساده بین این مفاهیم

اگر بخواهیم رابطه را به شکل ساده نمایش دهیم:

Software Quality

↓

نتیجه مجموعه‌ای از فعالیت‌ها در طول چرخه عمر Software

↓

• Requirements
• Design
• Development
• QA Activities
• Testing
• QC Activities
• Monitoring & Feedback

این نمودار نشان می‌دهد Testing یک جزء مهم در اکوسیستم Quality است، نه مترادف Quality.

Testing نمی‌تواند Quality را «بسازد»

یک تصور قدیمی این است که Software ساخته می‌شود و در پایان Tester آن را Test می‌کند تا Quality ایجاد شود.

این نگاه مشکل دارد.

اگر سیستم از ابتدا با Requirementهای اشتباه طراحی شده باشد، Testing ممکن است Defectها را پیدا کند، اما نمی‌تواند Business Strategy اشتباه را اصلاح کند.

اگر Architecture برای Scale مورد نیاز مناسب نباشد، Testing می‌تواند این Risk را آشکار کند، اما الزاماً نمی‌تواند Architecture را اصلاح کند.

پس نقش Testing بیشتر ارائه اطلاعات درباره وضعیت Software و Riskها است تا ایجاد Quality به‌تنهایی.

Testing به‌عنوان Feedback Loop

یکی از ارزشمندترین نقش‌های Testing ایجاد Feedback است.

Tester اطلاعاتی درباره رفتار واقعی Software در اختیار تیم قرار می‌دهد.

این Feedback می‌تواند باعث شود:

• Requirement اصلاح شود.
• Design تغییر کند.
• Code اصلاح شود.
• Risk جدید شناسایی شود.
• Acceptance Criteria دقیق‌تر شوند.
• Process تیم بهبود پیدا کند.

بنابراین Testing فقط یک مرحله انتهایی نیست؛ می‌تواند در طول چرخه توسعه Feedback تولید کند.

Shift Left و Quality

یکی از نتایج همین نگاه، مفهوم Shift Left است.

ایده اصلی این است که فعالیت‌های مرتبط با Quality و Testing تا حد امکان زودتر وارد چرخه توسعه شوند.

برای مثال به جای اینکه Tester بعد از تکمیل Feature متوجه ابهام Requirement شود، می‌توان این ابهام را هنگام تحلیل Requirement شناسایی کرد.

این کار معمولاً هزینه اصلاح مشکل را کاهش می‌دهد و Feedback را سریع‌تر می‌کند.

آیا Shift Left یعنی Testing فقط باید زودتر انجام شود؟

نه.

Shift Left را نباید صرفاً به معنی «زودتر Test کردن» در نظر گرفت.

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

Shift Right؛ Quality بعد از Release تمام نمی‌شود

در مقابل Shift Left، مفهوم Shift Right نیز اهمیت دارد.

حتی پس از Release، رفتار واقعی Software در Production می‌تواند اطلاعات مهمی درباره Quality ارائه دهد.

• Monitoring
• Logging
• Observability
• Real User Feedback
• Incident Analysis

می‌توانند نشان دهند Software در دنیای واقعی چگونه عمل می‌کند.

یک چرخه کامل‌تر برای Quality

اگر این مفاهیم را کنار هم قرار دهیم، تصویر کامل‌تری به دست می‌آید:

• نیازها و Requirementها تعریف می‌شوند.
• Design و Architecture شکل می‌گیرند.
• Software توسعه داده می‌شود.
• Testing و سایر Quality Activities انجام می‌شوند.
• Software Release می‌شود.
• رفتار واقعی سیستم Monitoring می‌شود.
• Feedback جمع‌آوری می‌شود.
• تیم بر اساس شواهد، Software و Process را بهبود می‌دهد.

در چنین چرخه‌ای Quality یک نقطه مشخص در انتهای پروژه نیست؛ بلکه یک فعالیت مستمر است.

یک مثال واقعی‌تر؛ Feature پرداخت

فرض کنید تیم در حال توسعه یک Feature پرداخت آنلاین است.

اگر فقط در پایان Development Testing انجام شود، ممکن است Tester متوجه شود که فرآیند پرداخت در صورت Timeout شدن Payment Gateway رفتار مشخصی ندارد.

اما اگر Quality از ابتدا وارد فرآیند شود، تیم می‌تواند از همان زمان طراحی درباره سناریوهایی مانند Timeout، Duplicate Payment، Retry، Failure و Rollback تصمیم‌گیری کند.

در این حالت Testing فقط Defect را پیدا نمی‌کند؛ بلکه به شناسایی Risk پیش از ایجاد Defect نیز کمک می‌کند.

Quality Gate چیست؟

در برخی تیم‌ها برای عبور Software از مراحل مختلف، معیارهایی تحت عنوان Quality Gate تعریف می‌شود.

مثلاً قبل از Release ممکن است معیارهایی مانند این‌ها بررسی شوند:

• Defectهای Critical باز وجود نداشته باشند.
• Testهای ضروری Pass شده باشند.
• Quality Criteriaهای مهم تأیید شده باشند.
• Riskهای شناخته‌شده مستند شده باشند.

Quality Gate می‌تواند به تصمیم‌گیری کمک کند، اما نباید به یک Checklist صوری تبدیل شود که صرفاً برای عبور از مرحله Release تکمیل شود.

مهم‌ترین نکته برای یک Tester

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

Tester باید بتواند اطلاعاتی تولید کند که به تیم کمک کند بهتر تصمیم بگیرد:

• چه چیزی را می‌دانیم؟
• چه چیزی را هنوز نمی‌دانیم؟
• کدام Riskها جدی‌تر هستند؟
• چه چیزی Test شده است؟
• چه چیزی Test نشده است؟
• چه Defectهایی وجود دارند؟
• چه شواهدی برای Release داریم؟

این نگاه، Testing را از یک فعالیت صرفاً اجرایی به یک فعالیت اطلاعات‌محور و Risk-Based تبدیل می‌کند.

جمع‌بندی بخش دوازدهم 🎯

• Software Quality یک هدف کلی است و فقط به Testing محدود نمی‌شود.
• Testing یکی از فعالیت‌های مهم برای ارزیابی Quality و ارائه Feedback است.
• Tester به‌تنهایی مسئول Quality کل Product نیست.
• Quality یک مسئولیت مشترک در تیم است.
• QA، QC و Testing مفاهیم مرتبط اما متفاوت هستند.
• به دلیل داشتن مقاله جداگانه درباره QA و QC، در این مقاله فقط رابطه آنها با Software Quality را بررسی کردیم.
• Shift Left یعنی Quality را زودتر وارد چرخه توسعه کنیم.
• Shift Right نشان می‌دهد Quality پس از Release نیز باید دنبال شود.
• Testing می‌تواند نقش یک Feedback Loop مهم برای تیم داشته باشد.
• هدف نهایی Testing فقط پیدا کردن Bug نیست؛ بلکه کاهش ابهام و Risk و فراهم کردن اطلاعات برای تصمیم‌گیری بهتر است.

در بخش بعدی، سراغ یکی از مهم‌ترین موضوعات در درک واقعی Software Quality می‌رویم: Defect، Error، Failure و Bug چه تفاوتی با یکدیگر دارند و این تفاوت چه ارتباطی با Quality دارد؟

Error، Defect، Bug و Failure؛ وقتی Software آن‌طور که باید رفتار نمی‌کند

وقتی درباره Software Quality صحبت می‌کنیم، یکی از مفاهیم پایه‌ای که باید به‌درستی درک شود، تفاوت بین Error، Defect، Bug و Failure است.

این اصطلاحات در گفتگوهای روزمره Software Testing گاهی به جای یکدیگر استفاده می‌شوند، اما از نظر مفهومی تفاوت دارند.

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

Error چیست؟

Error معمولاً به یک اقدام انسانی یا تصمیم اشتباه اشاره دارد که می‌تواند باعث ایجاد مشکل در Software شود.

این اشتباه ممکن است توسط Developer، Tester، Product Manager، Business Analyst یا هر فرد دیگری در فرآیند تولید Software رخ دهد.

برای مثال، فرض کنید Requirement به اشتباه تفسیر شود:

Developer تصور می‌کند Discount باید روی قیمت Product اعمال شود، در حالی که Business منظورش اعمال Discount روی کل Order بوده است.

این برداشت اشتباه یک Error انسانی است.

Defect چیست؟

اگر آن Error وارد Work Product شود، می‌تواند به یک Defect تبدیل شود.

Defect به وجود یک مشکل یا نقص در یک Artifact یا Software اشاره دارد که باعث می‌شود آنچه ساخته شده با چیزی که مورد انتظار بوده مطابقت نداشته باشد.

برای مثال Developer بر اساس برداشت اشتباه خود، Code را طوری پیاده‌سازی می‌کند که Discount فقط روی Product اعمال شود.

در این مرحله، Code دارای یک Defect است.

Bug چیست؟

Bug اصطلاح رایجی است که در تیم‌های Software برای اشاره به یک رفتار یا مشکل نادرست در Software استفاده می‌شود.

در عمل، Bug و Defect در بسیاری از گفتگوهای روزمره تقریباً به جای یکدیگر استفاده می‌شوند.

بنابراین وقتی Tester می‌گوید:

«یک Bug پیدا کردم.»

معمولاً منظور او این است که رفتار Software با رفتار مورد انتظار مطابقت ندارد.

Failure چیست؟

Failure زمانی رخ می‌دهد که Software هنگام اجرا نتواند رفتار مورد انتظار را ارائه دهد.

این نکته مهم است:

Defect در Software وجود دارد؛ Failure زمانی مشاهده می‌شود که آن Defect در اجرای Software باعث رفتار نادرست شود.

ممکن است یک Defect در Code وجود داشته باشد اما هنوز در شرایطی که Test می‌کنیم، Failure قابل مشاهده‌ای ایجاد نکند.

یک زنجیره ساده

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

Human Error → Defect → Failure

و در گفتگوهای روزمره:

Bug معمولاً برای اشاره به Defect یا مشکل موجود در Software استفاده می‌شود.

مثال؛ محاسبه مبلغ سفارش

فرض کنید Requirement می‌گوید:

«برای سفارش‌های بالاتر از ۱ میلیون تومان، ۱۰٪ Discount روی مبلغ نهایی Order اعمال شود.»

Developer Requirement را اشتباه متوجه می‌شود و Discount را فقط روی اولین Product اعمال می‌کند.

• Error: برداشت اشتباه Developer از Requirement
• Defect: Logic اشتباه در Code
• Bug: اصطلاح رایج برای همین مشکل در Software
• Failure: وقتی کاربر Order را ثبت می‌کند و مبلغ نهایی اشتباه محاسبه می‌شود

آیا هر Defect حتماً Failure ایجاد می‌کند؟

خیر.

ممکن است Defectی در بخشی از Code وجود داشته باشد که فقط تحت شرایط خاصی فعال شود.

مثلاً یک Error Handling اشتباه ممکن است فقط زمانی اجرا شود که یک Dependency خاص در دسترس نباشد.

تا زمانی که آن شرایط رخ نداده باشد، Failure قابل مشاهده‌ای ایجاد نمی‌شود.

Failure بدون شناخت فوری Defect

از طرف دیگر، Tester ممکن است یک Failure را مشاهده کند بدون اینکه بلافاصله علت اصلی آن را بداند.

مثلاً:

«در زمان پرداخت، سیستم خطای 500 نمایش می‌دهد.»

این یک Failure مشاهده‌شده است.

اما علت می‌تواند یکی از موارد مختلف باشد:

• Bug در Application
• مشکل Database
• Failure در یک External Service
• Configuration اشتباه
• Network Problem
• Resource Exhaustion

بنابراین مشاهده Failure لزوماً به معنی شناخت فوری Root Cause نیست.

Root Cause چه نقشی دارد؟

در بررسی Defectها، پیدا کردن Root Cause اهمیت زیادی دارد.

فرض کنید یک Bug باعث می‌شود قیمت Order اشتباه محاسبه شود.

ممکن است فقط Code مربوط به محاسبه قیمت را اصلاح کنیم.

اما اگر Root Cause این بوده باشد که Requirement از ابتدا Ambiguous بوده، ممکن است همان نوع مشکل در Featureهای دیگر نیز تکرار شود.

در اینجا اصلاح صرفاً Code کافی نیست و Process یا Requirement نیز ممکن است نیاز به بهبود داشته باشد.

Defectهای پنهان

همه Defectها به یک اندازه قابل مشاهده نیستند.

ممکن است یک Defect ماه‌ها در Software وجود داشته باشد اما به دلیل شرایط خاص استفاده هرگز فعال نشود.

این موضوع یکی از دلایلی است که چرا «تعداد Bugهای پیدا شده» به‌تنهایی معیار مناسبی برای قضاوت درباره Quality نیست.

آیا پیدا کردن Bug زیاد یعنی Tester ضعیف است؟

لزوماً نه.

اگر Tester در یک Release تعداد زیادی Defect مهم پیدا کند، ممکن است این موضوع نشان‌دهنده ضعف Software باشد، نه ضعف Tester.

حتی می‌توان گفت پیدا شدن Defect قبل از رسیدن آن به Production می‌تواند نتیجه ارزشمند Testing باشد.

Defectهای Production

وقتی Defect در محیط Production فعال می‌شود و User با رفتار نادرست مواجه می‌شود، ممکن است پیامد آن بسیار جدی‌تر شود.

مثلاً:

Defect	Failure	Impact
محاسبه اشتباه قیمت	مبلغ اشتباه نمایش داده می‌شود	ضرر مالی
Permission اشتباه	کاربر اطلاعات دیگران را می‌بیند	Security Incident
Memory Leak	Service پس از مدتی Crash می‌کند	Downtime
Timeout Handling ضعیف	Payment دوبار ثبت می‌شود	مشکل مالی و اعتماد کاربر

Severity و Impact

همه Bugها اهمیت یکسانی ندارند.

یک Typo در متن ممکن است Defect باشد، اما Impact بسیار کمی داشته باشد.

در مقابل، یک Bug در Payment یا Authentication می‌تواند Impact بسیار بالایی ایجاد کند.

به همین دلیل در Software Testing معمولاً Defectها بر اساس عواملی مانند Severity و Priority ارزیابی می‌شوند.

Defect، Failure و Quality چه ارتباطی دارند؟

هر Defect می‌تواند یک Risk برای Quality ایجاد کند.

اگر Defect فعال شود، ممکن است Failure ایجاد کند و اگر Failure در شرایط واقعی رخ دهد، می‌تواند روی User، Business، Security، Revenue یا Reputation تأثیر بگذارد.

بنابراین Testing تلاش می‌کند تا Defectهای مهم را قبل از تبدیل شدن به Failureهای پرهزینه شناسایی کند.

اما هدف Testing فقط جلوگیری از Failure نیست

Testing همچنین می‌تواند محدودیت‌ها و شرایطی را آشکار کند که در آنها Software ممکن است رفتار نامناسب داشته باشد.

برای مثال Performance Testing ممکن است نشان دهد سیستم در شرایط مشخصی به نقطه‌ای می‌رسد که Response Time به‌شدت افزایش پیدا می‌کند.

حتی اگر در Test معمولی Failure قابل مشاهده‌ای رخ نداده باشد، این اطلاعات می‌تواند یک Risk مهم برای Production باشد.

آیا Bug همیشه ناشی از Code است؟

خیر.

مشکل Software می‌تواند در مراحل مختلف چرخه تولید ایجاد شود:

• Requirement اشتباه
• Requirement ناقص
• Design نامناسب
• Architecture نامناسب
• Implementation اشتباه
• Configuration اشتباه
• Deployment مشکل‌دار
• Integration با یک سرویس خارجی

به همین دلیل نگاه حرفه‌ای به Testing نباید Bug را فقط با «اشتباه Programmer» یکی بداند.

یک نکته مهم درباره اصطلاحات

در منابع مختلف Software Testing ممکن است تعاریف یا کاربردهای متفاوتی برای Error، Defect، Bug و Failure ببینید.

مهم‌تر از حفظ کردن اصطلاحات، درک زنجیره علت و معلولی است:

یک تصمیم یا اقدام انسانی اشتباه می‌تواند وارد Artifact شود، یک Defect ایجاد کند و در شرایط مشخص به Failure منجر شود.

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

جمع‌بندی بخش سیزدهم 🎯

• Error معمولاً به یک اشتباه انسانی اشاره دارد.
• Defect یک نقص یا مشکل موجود در Work Product یا Software است.
• Bug اصطلاح رایجی برای اشاره به مشکل یا Defect در Software است.
• Failure زمانی رخ می‌دهد که Software هنگام اجرا نتواند رفتار مورد انتظار را ارائه کند.
• هر Defect لزوماً همیشه Failure قابل مشاهده ایجاد نمی‌کند.
• مشاهده Failure به معنی شناخت فوری Root Cause نیست.
• Defectها می‌توانند از Requirement، Design، Code، Configuration یا سایر مراحل ایجاد شوند.
• تعداد Bugهای پیدا شده به‌تنهایی معیار مناسبی برای سنجش Quality نیست.
• هدف Testing فقط پیدا کردن Bug نیست؛ بلکه کاهش Risk و ارائه اطلاعات درباره رفتار Software نیز اهمیت دارد.

در بخش بعدی، از خود Defectها یک قدم جلوتر می‌رویم و بررسی می‌کنیم چرا Defectها به وجود می‌آیند، چرا بعضی از آنها زود پیدا می‌شوند و بعضی تا Production باقی می‌مانند و چه عواملی روی هزینه رفع آنها تأثیر می‌گذارند.

چرا Defectها ایجاد می‌شوند و چرا بعضی از آنها تا Production باقی می‌مانند؟

در بخش قبل دیدیم که یک Defect می‌تواند از Requirement، Design، Code، Configuration یا بخش‌های دیگر چرخه تولید Software ایجاد شود.

اما یک سؤال مهم‌تر وجود دارد:

اگر Defect وجود دارد، چرا همیشه قبل از Release پیدا نمی‌شود؟

پاسخ ساده این است که Software یک سیستم پیچیده است و هیچ فرآیند Testingای نمی‌تواند همه حالت‌های ممکن را بررسی کند.

منشأ Defect همیشه Code نیست

یکی از مهم‌ترین نکات در Software Quality این است که محل مشاهده Defect لزوماً محل ایجاد آن نیست.

ممکن است Bug در مرحله Testing مشاهده شود، اما علت اصلی آن ماه‌ها قبل و هنگام تعریف Requirement ایجاد شده باشد.

برای مثال:

• Business Requirement مبهم بوده است.
• تیم آن را به شکل متفاوتی تفسیر کرده است.
• Design بر اساس همان تفسیر ایجاد شده است.
• Developer Code را مطابق Design نوشته است.
• Tester نیز ابتدا همان رفتار را درست فرض کرده است.

در نهایت بعد از Release مشخص می‌شود رفتار Software با انتظار واقعی Business مطابقت نداشته است.

مهم‌ترین منابع ایجاد Defect

Defectها می‌توانند از منابع مختلفی ایجاد شوند:

• Requirementهای ناقص یا مبهم
• Communication ضعیف
• Design یا Architecture نامناسب
• Implementation اشتباه
• Integrationهای پیچیده
• Configuration نادرست
• تغییرات مکرر در Product
• فشار زمانی شدید
• فرآیند ضعیف Development
• نبود Test مناسب برای Riskهای مهم

Requirement مبهم؛ یکی از منابع مهم Defect

فرض کنید در Requirement نوشته شده:

«سیستم باید سریع باشد.»

این Requirement از نظر Testing مشکل دارد، چون «سریع» برای افراد مختلف می‌تواند معنی متفاوتی داشته باشد.

Developer ممکن است Response Time پنج ثانیه را قابل قبول بداند و Product Manager یک ثانیه را انتظار داشته باشد.

اگر این اختلاف قبل از Development مشخص نشود، احتمال ایجاد Defect و اختلاف در زمان Acceptance افزایش پیدا می‌کند.

Communication Gap

گاهی Requirement روی کاغذ واضح است، اما افراد مختلف برداشت یکسانی از آن ندارند.

برای مثال Business می‌گوید:

«کاربر باید بتواند سفارش را لغو کند.»

اما مشخص نشده:

• تا چه زمانی امکان لغو وجود دارد؟
• آیا بعد از پرداخت هم امکان لغو هست؟
• در صورت ارسال سفارش چه اتفاقی می‌افتد؟
• Refund چگونه انجام می‌شود؟
• آیا برای برخی Productها محدودیت وجود دارد؟

اگر این موارد مشخص نشوند، احتمالاً افراد مختلف تصمیم‌های متفاوتی خواهند گرفت.

Complexity؛ هرچه سیستم پیچیده‌تر، فضای Defect بیشتر

Softwareهای مدرن معمولاً فقط یک Application ساده نیستند.

• Frontend
• Backend
• Database
• Cache
• Message Broker
• Payment Gateway
• Authentication Service
• Third-Party APIs
• Cloud Infrastructure

هرچه تعداد Componentها و Interactionها بیشتر شود، تعداد حالت‌های ممکن نیز افزایش پیدا می‌کند.

در نتیجه احتمال اینکه یک Defect فقط در یک ترکیب خاص از شرایط ظاهر شود بیشتر می‌شود.

چرا Testing همه Defectها را پیدا نمی‌کند؟

یکی از دلایل اصلی، محدود بودن زمان و منابع است.

فرض کنید یک Form فقط ۱۰ Input داشته باشد و هر Input چندین مقدار ممکن داشته باشد. بررسی تمام ترکیب‌های احتمالی می‌تواند عملاً غیرممکن باشد.

بنابراین Tester باید با استفاده از تکنیک‌های مناسب، مهم‌ترین و Riskyترین حالت‌ها را انتخاب کند.

Exhaustive Testing تقریباً غیرممکن است

Exhaustive Testing یعنی تلاش برای بررسی تمام حالت‌ها و ورودی‌های ممکن.

در Software واقعی، به‌خصوص سیستم‌های پیچیده، چنین رویکردی معمولاً عملی نیست.

به همین دلیل Testing حرفه‌ای به جای تلاش برای پوشش همه چیز، روی Risk، Business Impact و احتمال Failure تمرکز می‌کند.

Risk-Based Testing

در Risk-Based Testing منابع Testing ابتدا روی بخش‌هایی متمرکز می‌شوند که احتمال و Impact بالاتری دارند.

مثلاً در یک فروشگاه اینترنتی:

بخش	Risk احتمالی	اولویت
Payment	ضرر مالی	بسیار بالا
Authentication	دسترسی غیرمجاز	بسیار بالا
Order Creation	ثبت سفارش اشتباه	بالا
Search	نمایش نتایج نامرتبط	متوسط
UI Text	اشتباه نگارشی	پایین‌تر

این به معنی بی‌اهمیت بودن موارد کم‌ریسک نیست؛ بلکه منابع محدود باید متناسب با Risk توزیع شوند.

Defect Escape چیست؟

وقتی یک Defect از مراحل داخلی Testing عبور کند و به محیط بالاتری مانند Production برسد، معمولاً از اصطلاح Defect Escape استفاده می‌شود.

Defect Escape می‌تواند نشانه‌ای باشد که یک Defect مهم در یکی از مراحل قبلی شناسایی نشده است.

اما وجود Defect Escape به‌تنهایی به معنی ضعیف بودن Tester نیست.

باید بررسی شود:

• آیا Requirement درست تعریف شده بود؟
• آیا Test Case مناسب وجود داشت؟
• آیا Environment مشابه Production بود؟
• آیا Data مناسب برای Test وجود داشت؟
• آیا زمان کافی برای Testing وجود داشت؟
• آیا Risk به‌درستی شناسایی شده بود؟

هزینه رفع Defect در مراحل مختلف

به‌طور کلی هرچه یک مشکل دیرتر کشف شود، هزینه و Impact اصلاح آن می‌تواند بیشتر شود.

برای مثال اگر یک Requirement اشتباه قبل از Development شناسایی شود، اصلاح آن معمولاً ساده‌تر از زمانی است که Software بر اساس آن ساخته، Test و Release شده باشد.

در Production علاوه بر هزینه فنی، ممکن است هزینه‌های دیگری نیز ایجاد شود:

• پشتیبانی از کاربران
• Incident Management
• از دست رفتن درآمد
• کاهش اعتماد کاربران
• آسیب به Reputation
• نیاز به Rollback یا Hotfix

Shift Left و کاهش هزینه Defect

یکی از دلایل اهمیت Shift Left همین موضوع است.

اگر یک ابهام یا Risk در همان مرحله Requirement یا Design شناسایی شود، معمولاً اصلاح آن بسیار ساده‌تر از زمانی است که تبدیل به Code و سپس Production Failure شده باشد.

آیا همه Defectها باید قبل از Release رفع شوند؟

لزوماً نه.

در پروژه‌های واقعی ممکن است Release با وجود Defectهای شناخته‌شده انجام شود.

تصمیم Release باید بر اساس عواملی مانند:

• Severity
• Business Impact
• Risk
• تعداد کاربران تحت تأثیر
• وجود Workaround
• هزینه تأخیر Release
• تعهدات قانونی یا قراردادی

گرفته شود.

بنابراین Quality یک تصمیم صفر و یک نیست؛ بلکه در بسیاری از مواقع یک تصمیم آگاهانه بر اساس Risk است.

Root Cause Analysis

وقتی یک Defect مهم پیدا می‌شود، فقط Fix کردن آن همیشه کافی نیست.

تیم می‌تواند بررسی کند چرا Defect ایجاد شد و چرا زودتر شناسایی نشد.

برای این کار روش‌هایی مانند 5 Whys یا سایر تکنیک‌های Root Cause Analysis می‌توانند مورد استفاده قرار گیرند.

هدف این تحلیل سرزنش یک فرد نیست؛ بلکه پیدا کردن عاملی است که احتمال تکرار مشکل را افزایش می‌دهد.

Bug Fix به‌تنهایی Quality را افزایش نمی‌دهد

فرض کنید یک Bug مربوط به محاسبه قیمت پیدا شده و Developer آن را Fix می‌کند.

اگر Root Cause همچنان وجود داشته باشد، ممکن است در Feature دیگری همان الگو دوباره تکرار شود.

به همین دلیل تیم‌های بالغ فقط به Fix کردن Defect نگاه نمی‌کنند؛ بلکه به جلوگیری از تکرار آن نیز توجه دارند.

Defect Prevention

Defect Prevention به فعالیت‌هایی اشاره دارد که با هدف کاهش احتمال ایجاد Defect انجام می‌شوند.

• شفاف‌تر کردن Requirementها
• Review کردن Design
• Code Review
• Automated Testing
• Static Analysis
• بهبود فرآیند Development
• Root Cause Analysis
• اشتراک‌گذاری Lessons Learned

هدف این است که تیم فقط در پیدا کردن مشکلات بهتر نشود، بلکه در جلوگیری از ایجاد آنها نیز پیشرفت کند.

یک نگاه حرفه‌ای به Defect

Tester حرفه‌ای فقط نمی‌پرسد:

«Bug کجاست؟»

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

• چرا این Defect ایجاد شد؟
• چرا این Defect زودتر پیدا نشد؟
• چه Riskهایی مشابه این Defect وجود دارند؟
• آیا Test دیگری می‌تواند این نوع مشکل را پیدا کند؟
• آیا Requirement یا Design نیاز به اصلاح دارد؟
• چگونه می‌توان از تکرار این مشکل جلوگیری کرد؟

این نوع نگاه باعث می‌شود Testing از یک فعالیت صرفاً Bug-Finding به یک فعالیت مؤثر در بهبود Quality تبدیل شود.

جمع‌بندی بخش چهاردهم 🎯

• Defect می‌تواند از مراحل مختلف چرخه Software ایجاد شود.
• Requirementهای مبهم و Communication ضعیف از منابع مهم Defect هستند.
• Complexity باعث افزایش تعداد حالت‌هایی می‌شود که باید در Testing در نظر گرفته شوند.
• Exhaustive Testing در Softwareهای واقعی معمولاً عملی نیست.
• Risk-Based Testing کمک می‌کند منابع محدود روی مهم‌ترین Riskها متمرکز شوند.
• Defect Escape به معنی عبور Defect از مراحل Testing و رسیدن آن به محیط‌های بالاتر مانند Production است.
• هزینه و Impact Defectهای دیر کشف‌شده می‌تواند بیشتر باشد.
• همه Defectها الزاماً قبل از Release رفع نمی‌شوند؛ تصمیم باید بر اساس Risk و Business Impact باشد.
• Root Cause Analysis می‌تواند از تکرار Defectهای مشابه جلوگیری کند.
• Quality فقط با Fix کردن Bugها بهتر نمی‌شود؛ Defect Prevention نیز اهمیت دارد.

در بخش بعدی، وارد یکی از مهم‌ترین مباحث Software Quality می‌شویم: Quality Metrics؛ یعنی چگونه می‌توان درباره Quality با استفاده از داده و شاخص‌ها صحبت کرد، بدون اینکه در دام Metricهای گمراه‌کننده بیفتیم.

Quality Metrics؛ چگونه کیفیت Software را با داده ارزیابی کنیم؟

تا اینجا درباره مفهوم Quality، Defectها، Risk و نقش Testing صحبت کردیم. اما یک سؤال مهم باقی می‌ماند:

از کجا بفهمیم Quality یک Software واقعاً خوب است؟

در پروژه‌های واقعی نمی‌توان فقط بر اساس احساس یا تعداد Bugها درباره Quality تصمیم گرفت. برای تصمیم‌گیری بهتر، به داده و شاخص‌های مناسب نیاز داریم.

به این شاخص‌ها معمولاً Quality Metrics گفته می‌شود.

Quality Metric چیست؟

Quality Metric یک معیار قابل اندازه‌گیری است که می‌تواند اطلاعاتی درباره یک جنبه از Quality، فرآیند توسعه یا وضعیت Defectها ارائه کند.

برای مثال:

• تعداد Defectهای باز
• تعداد Defectهای Critical
• Defect Escape Rate
• Defect Reopen Rate
• Test Pass Rate
• Test Coverage
• Mean Time to Repair
• Production Incident Rate

اما نکته مهم این است که هر عددی الزاماً یک Metric مفید نیست.

چرا Metrics می‌توانند گمراه‌کننده باشند؟

فرض کنید مدیر یک تیم بگوید:

«تعداد Bugهای تیم ما نسبت به ماه قبل ۳۰٪ کاهش پیدا کرده است؛ پس Quality بهتر شده.»

این نتیجه‌گیری لزوماً درست نیست.

ممکن است دلیل کاهش Bug این باشد که Testerها زمان کمتری برای Testing داشته‌اند، Testهای کمتری اجرا شده‌اند یا Release کوچک‌تر بوده است.

بنابراین یک Metric باید در Context خودش تفسیر شود.

Bug Count؛ یکی از ساده‌ترین اما خطرناک‌ترین Metrics

تعداد Bugها یکی از رایج‌ترین شاخص‌هایی است که تیم‌ها اندازه‌گیری می‌کنند.

اما تعداد Bug به‌تنهایی اطلاعات کافی درباره Quality نمی‌دهد.

فرض کنید:

Release	تعداد Bug
Release A	50
Release B	20

ممکن است در نگاه اول Release B بهتر به نظر برسد.

اما اگر در Release A، تست‌ها دو برابر Release B بوده باشند، این مقایسه دیگر به همین سادگی نیست.

Severity مهم‌تر از تعداد خام Bugها

دو تیم ممکن است هرکدام ۲۰ Bug داشته باشند، اما کیفیت محصول آنها کاملاً متفاوت باشد.

تیم	Bugها	وضعیت
Team A	20 Bug کم‌اهمیت	Risk پایین‌تر
Team B	20 Bug شامل چند Critical	Risk بسیار بالاتر

بنابراین تحلیل Defect باید حداقل Severity و Business Impact را نیز در نظر بگیرد.

Defect Density

Defect Density تلاش می‌کند تعداد Defectها را نسبت به اندازه یک Work Product اندازه‌گیری کند.

در برخی محیط‌ها ممکن است Defectها نسبت به اندازه Code یا واحد دیگری سنجیده شوند.

این Metric می‌تواند برای مقایسه روندها مفید باشد، اما باز هم باید با Context تفسیر شود؛ زیرا همه بخش‌های Code از نظر Complexity و Risk یکسان نیستند.

Defect Escape Rate

یکی از Metrics مهم برای تیم‌های Testing، بررسی Defectهایی است که قبل از Release پیدا نشده‌اند و بعداً در محیط‌های بالاتر یا Production کشف شده‌اند.

این شاخص می‌تواند به تیم کمک کند بفهمد چه مقدار از Defectها از فرآیندهای داخلی عبور کرده‌اند.

اما هدف از این Metric نباید سرزنش Testerها باشد.

اگر Defect Escape افزایش پیدا کند، سؤال حرفه‌ای این است:

«چه چیزی در سیستم ما باعث شد این نوع Defect قبل از Production شناسایی نشود؟»

Test Pass Rate

Test Pass Rate درصد Testهایی را نشان می‌دهد که با موفقیت اجرا شده‌اند.

این Metric برای درک وضعیت یک Test Suite می‌تواند مفید باشد، اما نباید به‌تنهایی به‌عنوان معیار Quality استفاده شود.

ممکن است ۹۹٪ Testها Pass شوند، اما Testهای مهمی که اصلاً نوشته نشده‌اند یک Risk جدی ایجاد کنند.

Test Coverage

Test Coverage یکی از شناخته‌شده‌ترین Metrics در Testing است.

Coverage می‌تواند به شکل‌های مختلفی تعریف شود؛ برای مثال Coverage مربوط به Code، Requirements یا Test Scenarios.

اما یک نکته بسیار مهم وجود دارد:

Coverage بالا لزوماً به معنی Quality بالا نیست.

ممکن است Testها مقدار زیادی از Code را پوشش دهند اما Assertionهای ضعیفی داشته باشند یا Scenarioهای مهم Business را بررسی نکنند.

Automation Coverage

برخی تیم‌ها درصد Testهای Automated را نیز اندازه‌گیری می‌کنند.

این شاخص می‌تواند برای بررسی وضعیت Automation مفید باشد، اما «درصد Automation» به‌تنهایی نشان نمی‌دهد Automation واقعاً چقدر ارزش ایجاد کرده است.

یک تیم می‌تواند ۸۰٪ Testهای خود را Automated کرده باشد، اما اگر بیشتر آنها Testهای کم‌ارزش باشند، این عدد لزوماً نشانه موفقیت نیست.

Mean Time to Repair

Mean Time to Repair یا MTTR می‌تواند نشان دهد یک مشکل پس از شناسایی، به‌طور متوسط چه مدت زمان برای رفع شدن نیاز دارد.

MTTR پایین‌تر می‌تواند نشانه توانایی بهتر تیم در واکنش به مشکلات باشد، اما باید شرایط و Severity مشکلات نیز در نظر گرفته شود.

Production Incident Rate

تعداد و شدت Incidentهای Production نیز می‌تواند اطلاعات مهمی درباره کیفیت واقعی Software در اختیار تیم قرار دهد.

برای مثال ممکن است Testهای داخلی وضعیت خوبی داشته باشند، اما بعد از Release تعداد زیادی Incident مهم رخ دهد.

این موضوع می‌تواند نشان دهد بین شرایط Test Environment و دنیای واقعی فاصله وجود دارد.

Customer-Reported Defects

Defectهایی که توسط کاربران یا مشتریان گزارش می‌شوند نیز می‌توانند یک Signal مهم باشند.

اگر کاربران مرتباً مشکلاتی را گزارش کنند که تیم داخلی آنها را قبل از Release شناسایی نکرده است، باید فرآیند Testing و همچنین شناخت تیم از User Behavior بررسی شود.

Quality Metrics نباید به ابزار فشار تبدیل شوند

یکی از بزرگ‌ترین خطرها این است که Metricها به Targetهای سخت و شخصی تبدیل شوند.

مثلاً اگر به Tester گفته شود:

«باید هر Sprint حداقل ۳۰ Bug پیدا کنی.»

ممکن است رفتار تیم به سمت تولید Bugهای کم‌اهمیت یا گزارش‌های غیرضروری تغییر کند.

این همان مشکلی است که وقتی یک Metric به هدف تبدیل می‌شود ممکن است رخ دهد: افراد بهینه‌سازی را برای خود عدد انجام می‌دهند، نه برای Quality واقعی.

Goodhart’s Law و Quality Metrics

یک ایده معروف در اندازه‌گیری می‌گوید وقتی یک Metric تبدیل به Target شود، ممکن است دیگر Metric خوبی برای اندازه‌گیری نباشد.

در Quality نیز همین خطر وجود دارد.

اگر هدف فقط کاهش Bug Count باشد، تیم ممکن است به جای حل مشکلات واقعی، روی کاهش عدد تمرکز کند.

بهتر است چند Metric را کنار هم ببینیم

به‌جای اتکا به یک عدد، بهتر است چند Signal را در کنار هم بررسی کنیم.

Metric	چه چیزی را نشان می‌دهد؟
Defect Count	حجم Defectهای شناسایی‌شده
Severity Distribution	شدت Defectها
Defect Escape	Defectهای عبورکرده از مراحل داخلی
Test Pass Rate	وضعیت اجرای Testها
Coverage	میزان پوشش تعریف‌شده
MTTR	سرعت واکنش و رفع مشکل
Production Incidents	رفتار Software در دنیای واقعی

هیچ‌کدام به‌تنهایی تصویر کاملی از Quality ارائه نمی‌کنند.

Metrics باید به سؤال مشخصی پاسخ دهند

قبل از انتخاب Metric بهتر است بدانیم دقیقاً چه چیزی را می‌خواهیم بفهمیم.

• آیا Defectهای مهم در حال افزایش‌اند؟
• آیا Defectهای بیشتری به Production می‌رسند؟
• آیا تیم سریع‌تر مشکلات را رفع می‌کند؟
• آیا Testهای ما بخش‌های مهم Product را پوشش می‌دهند؟
• آیا Releaseهای جدید باعث افزایش Incident شده‌اند؟

وقتی سؤال مشخص باشد، انتخاب Metric نیز منطقی‌تر می‌شود.

Metrics خوب چه ویژگی‌هایی دارند؟

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

Metric برای یادگیری، نه فقط گزارش‌دهی

ارزش واقعی Quality Metrics زمانی مشخص می‌شود که از آنها برای یادگیری و بهبود استفاده کنیم.

مثلاً اگر Defect Escape در Featureهای Payment افزایش پیدا کرده است، سؤال اصلی این نیست که «چه کسی اشتباه کرده؟» بلکه باید پرسید:

• چه نوع Defectهایی Escape کرده‌اند؟
• چرا Testهای موجود آنها را پیدا نکرده‌اند؟
• آیا Requirementها مشکل داشته‌اند؟
• آیا Test Data کافی نبوده است؟
• آیا Environment تفاوت زیادی با Production داشته است؟

در این حالت Metric تبدیل به ابزاری برای Continuous Improvement می‌شود.

Quality Metrics و تصمیم Release

Metrics می‌توانند بخشی از اطلاعات مورد استفاده برای تصمیم‌گیری درباره Release باشند.

اما تصمیم Release نباید صرفاً بر اساس یک Threshold عددی گرفته شود.

برای مثال ممکن است Test Pass Rate بالا باشد، اما یک Security Risk مهم هنوز باز باشد.

در چنین شرایطی یک عدد خوب نمی‌تواند Risk مهم را پنهان کند.

نگاه حرفه‌ای به Quality Metrics

یک Tester یا QA حرفه‌ای نباید فقط عدد تولید کند.

ارزش اصلی در تفسیر داده و تبدیل آن به Insight است.

برای مثال:

«تعداد Bugهای Production در دو Release اخیر افزایش یافته و بیشتر آنها مربوط به Integration با سرویس پرداخت بوده‌اند؛ بنابراین احتمالاً باید Coverage سناریوهای Failure و Timeout در این Integration افزایش پیدا کند.»

این جمله بسیار ارزشمندتر از گفتن «تعداد Bugها ۲۰٪ افزایش یافته است» است، چون Metric را به یک Insight و اقدام مشخص متصل می‌کند.

جمع‌بندی بخش پانزدهم 🎯

• Quality Metrics ابزارهایی برای اندازه‌گیری و درک بهتر وضعیت Quality هستند.
• هیچ Metric واحدی نمی‌تواند Quality کل Software را نشان دهد.
• Bug Count به‌تنهایی معیار مناسبی برای Quality نیست.
• Severity، Risk و Business Impact باید در تحلیل Defectها در نظر گرفته شوند.
• Test Pass Rate و Coverage نیز به‌تنهایی تضمین‌کننده Quality نیستند.
• Defect Escape و Production Incidents می‌توانند Signalهای مهمی باشند.
• Metrics نباید به ابزار فشار یا ارزیابی ساده افراد تبدیل شوند.
• هر Metric باید به یک سؤال یا تصمیم مشخص کمک کند.
• ارزش واقعی Metrics در استفاده از آنها برای Learning و Continuous Improvement است.
• داده بدون Context می‌تواند حتی باعث تصمیم‌گیری اشتباه شود.

در بخش بعدی، سراغ موضوعی می‌رویم که مستقیماً به این بحث متصل است: Quality Risk و Risk-Based Thinking و اینکه چگونه می‌توان منابع محدود Testing را روی مهم‌ترین تهدیدهای Quality متمرکز کرد.

Quality Risk و Risk-Based Thinking؛ همه چیز ارزش یکسانی برای تست ندارد

در بخش‌های قبلی دیدیم که نمی‌توان همه حالت‌های ممکن یک Software را به‌طور کامل تست کرد و همچنین هیچ Metric واحدی نمی‌تواند Quality را به‌تنهایی توضیح دهد.

در پروژه‌های واقعی، زمان، نیروی انسانی و منابع Testing محدود هستند. بنابراین یک سؤال مهم مطرح می‌شود:

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

پاسخ این سؤال ما را به مفهوم Risk-Based Thinking می‌رساند.

Risk چیست؟

Risk به امکان وقوع یک رویداد یا شرایط نامطلوب و پیامد احتمالی آن اشاره دارد.

در Software، Risk می‌تواند مربوط به موارد مختلفی باشد:

• از دست رفتن اطلاعات
• ضرر مالی
• اختلال در سرویس
• مشکل امنیتی
• نارضایتی کاربران
• عدم رعایت قوانین یا الزامات
• آسیب به Reputation سازمان

Risk با Defect یکی نیست

این دو مفهوم را نباید با یکدیگر اشتباه گرفت.

Defect یک مشکل موجود در Software یا Work Product است، اما Risk به احتمال وقوع یک نتیجه نامطلوب و Impact آن مربوط می‌شود.

ممکن است یک Defect وجود داشته باشد اما Risk بسیار کمی ایجاد کند.

برعکس، ممکن است حتی بدون وجود یک Defect شناخته‌شده، یک Risk جدی وجود داشته باشد؛ مثلاً به دلیل وابستگی به یک سرویس خارجی که احتمال Downtime آن بالاست.

Risk-Based Testing چیست؟

Risk-Based Testing رویکردی است که در آن فعالیت‌های Testing بر اساس Riskهای شناسایی‌شده اولویت‌بندی می‌شوند.

یعنی به جای اینکه همه بخش‌های Software را با شدت یکسان تست کنیم، ابتدا سراغ قسمت‌هایی می‌رویم که Failure آنها می‌تواند پیامد مهم‌تری داشته باشد.

یک مثال ساده از فروشگاه اینترنتی

فرض کنید یک فروشگاه اینترنتی داریم که بخش‌های زیر را دارد:

• Login
• Search
• Product Details
• Shopping Cart
• Payment
• Order History
• User Profile

همه این بخش‌ها باید تست شوند، اما Risk آنها یکسان نیست.

Feature	Potential Impact	Risk
Payment	ضرر مالی یا تراکنش اشتباه	بسیار بالا
Login	دسترسی غیرمجاز	بالا
Order History	نمایش اطلاعات اشتباه	بالا
Search	نتیجه نامرتبط	متوسط
UI Icon	مشکل ظاهری	پایین‌تر

بنابراین طبیعی است که Payment و Authentication نسبت به یک Icon ساده، Testing عمیق‌تری دریافت کنند.

Probability و Impact

برای تحلیل Risk معمولاً دو عامل مهم در نظر گرفته می‌شوند:

• Probability: احتمال رخ دادن مشکل
• Impact: شدت پیامد در صورت رخ دادن

ترکیب این دو عامل می‌تواند به تیم کمک کند Riskها را اولویت‌بندی کند.

Risk Matrix

یکی از روش‌های ساده برای نمایش Risk، استفاده از Risk Matrix است.

Probability / Impact	Low Impact	Medium Impact	High Impact
Low Probability	Low	Low/Medium	Medium
Medium Probability	Low/Medium	Medium	High
High Probability	Medium	High	Critical

این مدل ساده است، اما می‌تواند در تصمیم‌گیری اولیه مفید باشد.

همه Riskها از جنس یکسان نیستند

Riskها می‌توانند از منابع مختلفی ناشی شوند.

• Technical Risk: مشکل در Architecture، Code یا Technology
• Security Risk: احتمال دسترسی غیرمجاز یا افشای اطلاعات
• Performance Risk: افت Performance تحت بار
• Business Risk: تأثیر منفی روی درآمد یا فرآیند Business
• Operational Risk: مشکل در Deployment یا Operation
• Compliance Risk: عدم رعایت الزامات قانونی یا قراردادی

ریسک‌های محصول و ریسک‌های پروژه

در Testing معمولاً بین Product Risk و Project Risk نیز تمایز وجود دارد.

Product Risk مربوط به احتمال رفتار نامطلوب خود Software است؛ مثلاً محاسبه اشتباه قیمت.

Project Risk مربوط به عواملی است که می‌توانند اجرای پروژه را تحت تأثیر قرار دهند؛ مثلاً کمبود نیروی انسانی، تأخیر در Release یا نبود Test Environment.

این دو می‌توانند به یکدیگر مرتبط باشند، اما یک مفهوم نیستند.

Risk-Based Thinking فقط برای Tester نیست

یکی از برداشت‌های اشتباه این است که Risk Analysis فقط وظیفه QA یا Tester است.

در یک تیم بالغ، Risk باید موضوعی مشترک میان افراد مختلف باشد:

• Product Manager
• Business Analyst
• Developer
• Tester
• DevOps
• Security
• Stakeholders

هرکدام می‌توانند Riskهایی را ببینند که دیگران ممکن است متوجه آنها نشده باشند.

چه زمانی Risk را شناسایی کنیم؟

بهتر است Risk Assessment فقط در پایان Development انجام نشود.

Risk می‌تواند از همان زمان Requirement و Design بررسی شود و در طول چرخه توسعه نیز تغییر کند.

مثلاً یک Feature که در ابتدا Risk متوسطی داشته، ممکن است بعد از اضافه شدن Payment Integration به یک Feature با Risk بالا تبدیل شود.

Risk و Test Strategy

Risk می‌تواند مستقیماً روی Test Strategy تأثیر بگذارد.

اگر یک بخش Risk بالایی داشته باشد، ممکن است به موارد زیر نیاز داشته باشد:

• Test Caseهای بیشتر
• Exploratory Testing عمیق‌تر
• Automation بیشتر
• Integration Testing
• Security Testing
• Performance Testing
• Regression Testing گسترده‌تر

در مقابل، برای یک بخش Low Risk ممکن است مجموعه کوچک‌تری از Testها کافی باشد.

Risk Appetite و Risk Tolerance

همه سازمان‌ها میزان یکسانی از Risk را نمی‌پذیرند.

برای مثال یک Application سرگرمی ممکن است یک Bug کوچک را قابل قبول بداند، اما یک سیستم مالی یا Healthcare معمولاً نسبت به خطاهای خاص حساسیت بسیار بیشتری دارد.

بنابراین تصمیم درباره اینکه «چه مقدار Risk قابل قبول است» به Context و Business نیز وابسته است.

Risk در Production تمام نمی‌شود

حتی پس از Release نیز Risk باید پایش شود.

Monitoring، Logging، Alerting و Incident Management می‌توانند کمک کنند Riskهای واقعی سریع‌تر شناسایی شوند.

برای مثال ممکن است یک Feature در Test Environment کاملاً سالم به نظر برسد، اما بعد از Release مشخص شود در یک Region خاص Error Rate آن افزایش پیدا کرده است.

این اطلاعات می‌تواند یک Risk جدید یا تغییریافته را نشان دهد.

یک مثال واقعی‌تر؛ Payment

فرض کنید یک فروشگاه اینترنتی از یک Payment Gateway خارجی استفاده می‌کند.

Riskهای مهم می‌توانند شامل این موارد باشند:

• Timeout هنگام پرداخت
• Callback تکراری
• ثبت Payment اما ایجاد نشدن Order
• ثبت دوباره تراکنش
• اختلاف وضعیت Payment بین دو سیستم
• قطع شدن سرویس خارجی

در چنین شرایطی Testing نباید فقط مسیر موفق Payment را بررسی کند.

سناریوهای Failure، Timeout، Retry، Duplicate Request و Recovery نیز اهمیت زیادی پیدا می‌کنند.

Risk-Based Testing به معنی تست نکردن نیست

یک سوءبرداشت رایج این است که Risk-Based Testing یعنی بخش‌های کم‌ریسک را اصلاً تست نکنیم.

در واقع هدف، تخصیص هوشمندانه‌تر منابع Testing است، نه حذف کامل Testing.

Riskها باید به‌روزرسانی شوند

Risk یک مقدار ثابت نیست.

با تغییرات Product، Architecture، کاربران، Business Model و External Dependencies، سطح Risk نیز می‌تواند تغییر کند.

به همین دلیل Risk Assessment باید یک فعالیت مستمر باشد، نه یک سند یک‌باره.

از Risk به Test Scenario

یکی از ارزشمندترین کاربردهای Risk-Based Thinking این است که Risk را به Test Scenario تبدیل کنیم.

مثلاً:

Risk	Scenario
Payment Timeout	بررسی رفتار سیستم هنگام Timeout
Duplicate Payment	ارسال Callback تکراری
Unauthorized Access	دسترسی به Resource با Token نامعتبر
Data Loss	قطع ارتباط هنگام ذخیره اطلاعات

به این ترتیب Risk مستقیماً روی نوع Testing و Scenarioهایی که انتخاب می‌کنیم تأثیر می‌گذارد.

Risk-Based Thinking و نقش Tester

Tester حرفه‌ای فقط منتظر دریافت Test Case نمی‌ماند.

او باید بتواند بپرسد:

• اگر این Feature خراب شود، چه اتفاقی می‌افتد؟
• کدام Userها تحت تأثیر قرار می‌گیرند؟
• آیا راه جایگزینی وجود دارد؟
• آیا Failure می‌تواند اثر مالی یا امنیتی داشته باشد؟
• کدام Scenario احتمال بیشتری دارد؟
• اگر زمان Testing محدود باشد، کدام Testها را باید اول اجرا کنیم؟

این نوع تفکر یکی از تفاوت‌های مهم میان اجرای مکانیکی Test Caseها و Testing حرفه‌ای است.

جمع‌بندی بخش شانزدهم 🎯

• Risk و Defect یک مفهوم نیستند.
• Risk-Based Testing منابع Testing را بر اساس Risk اولویت‌بندی می‌کند.
• Probability و Impact دو عامل مهم در ارزیابی Risk هستند.
• همه Featureها از نظر Risk اهمیت یکسانی ندارند.
• Product Risk و Project Risk باید از یکدیگر متمایز شوند.
• Risk Analysis فقط وظیفه Tester نیست و باید یک فعالیت تیمی باشد.
• Risk می‌تواند مستقیماً روی Test Strategy و نوع Testها تأثیر بگذارد.
• Riskها در طول چرخه Software تغییر می‌کنند و باید دوباره ارزیابی شوند.
• Risk-Based Testing به معنی حذف Testing نیست؛ بلکه یعنی استفاده هوشمندانه‌تر از منابع محدود.
• یک Tester حرفه‌ای می‌تواند Risk را به Test Scenario و تصمیم Testing تبدیل کند.

در بخش بعدی، به سراغ Quality Assurance در فرآیند توسعه می‌رویم و بررسی می‌کنیم چگونه می‌توان Quality را فقط با پیدا کردن Defect کنترل نکرد، بلکه از ابتدا در فرآیند ساخت Software وارد کرد.

Quality در چرخه توسعه Software؛ کیفیت فقط در مرحله Testing ساخته نمی‌شود

تا اینجا دیدیم که Quality فقط به تعداد Bugها یا نتیجه Testها محدود نمی‌شود. یک Software زمانی می‌تواند کیفیت مناسبی داشته باشد که کیفیت از مراحل مختلف چرخه توسعه آن حمایت شود.

به همین دلیل یکی از مهم‌ترین تغییرات در نگاه مدرن به Software Quality این است که Quality را نباید فقط به پایان Development و مرحله Testing موکول کرد.

Testing معمولاً مشکلات را آشکار می‌کند؛ اما بسیاری از عوامل ایجاد Quality یا کاهش آن، خیلی زودتر از مرحله Testing شکل می‌گیرند.

Quality از Requirement شروع می‌شود

اگر Requirement ناقص، مبهم یا متناقض باشد، احتمال اینکه Software نهایی نیز رفتاری متفاوت از انتظار داشته باشد افزایش پیدا می‌کند.

برای مثال، فرض کنید Requirement فقط می‌گوید:

«کاربر باید بتواند سفارش خود را لغو کند.»

برای یک Feature واقعی، این جمله سؤالات زیادی ایجاد می‌کند:

• لغو سفارش تا چه زمانی امکان‌پذیر است؟
• آیا بعد از پرداخت امکان لغو وجود دارد؟
• اگر سفارش ارسال شده باشد چه اتفاقی می‌افتد؟
• مبلغ پرداخت‌شده چگونه بازگردانده می‌شود؟
• آیا همه Productها شرایط یکسانی دارند؟

اگر این ابهام‌ها قبل از Development برطرف نشوند، احتمال ایجاد Defect در مراحل بعدی بیشتر خواهد شد.

Requirement خوب چه کمکی به Quality می‌کند؟

Requirement مناسب باید تا حد امکان واضح، قابل بررسی و قابل درک برای افراد مختلف تیم باشد.

از دید Testing نیز Requirement باید آن‌قدر مشخص باشد که بتوان بر اساس آن رفتار مورد انتظار را تعریف و بررسی کرد.

برای مثال به جای:

«سیستم باید سریع باشد.»

می‌توان انتظار Performance را با معیار مشخص‌تری تعریف کرد.

«در شرایط مشخص‌شده، Response Time درخواست باید در محدوده توافق‌شده باقی بماند.»

هرچه انتظار دقیق‌تر باشد، امکان بررسی و اعتبارسنجی آن نیز بیشتر می‌شود.

Design نیز روی Quality تأثیر مستقیم دارد

حتی اگر Requirement کاملاً درست باشد، یک Design یا Architecture نامناسب می‌تواند مشکلات زیادی ایجاد کند.

برای مثال، اگر یک سیستم به شکلی طراحی شده باشد که همه درخواست‌ها از یک Component مرکزی عبور کنند، ممکن است آن Component به یک Bottleneck تبدیل شود.

در چنین شرایطی ممکن است Developerها Code کاملاً درستی بنویسند، اما Architecture همچنان باعث Performance Problem شود.

بنابراین Quality فقط ویژگی Code نیست؛ Architecture نیز بخشی از آن است.

Code Quality

Code یکی از مهم‌ترین بخش‌های Software است، اما Code Quality فقط به تمیز بودن ظاهری Code محدود نمی‌شود.

موضوعاتی مانند موارد زیر نیز اهمیت دارند:

• Maintainability
• Readability
• Testability
• Reliability
• Security
• Performance
• Complexity

Codeی که امروز کار می‌کند اما تغییر دادن آن بسیار دشوار است، می‌تواند در آینده به منبعی برای Defect تبدیل شود.

Code Review و اثر آن بر Quality

Code Review یکی از فعالیت‌هایی است که می‌تواند قبل از اجرای Software به شناسایی برخی مشکلات کمک کند.

در Code Review ممکن است مواردی مانند این‌ها شناسایی شوند:

• Logic اشتباه
• Edge Caseهای نادیده‌گرفته‌شده
• Security Problem
• Complexity غیرضروری
• مشکل در Error Handling
• عدم رعایت استانداردهای تیم

این کار به معنی حذف نیاز به Testing نیست؛ بلکه یک لایه دیگر برای کاهش احتمال Defect ایجاد می‌کند.

Testing باید زودتر وارد چرخه شود

در رویکردهای مدرن، Tester یا QA نباید همیشه تا پایان Development منتظر بماند تا Software آماده شود.

مشارکت زودهنگام می‌تواند به شناسایی ابهام‌های Requirement، Riskهای مهم و Scenarioهای فراموش‌شده کمک کند.

این همان ایده‌ای است که در رویکردهایی مانند Shift Left اهمیت پیدا می‌کند.

Shift Left یعنی چه؟

Shift Left به طور کلی به معنای انتقال برخی فعالیت‌های مربوط به Quality و Testing به مراحل زودتر چرخه توسعه است.

هدف این نیست که Testing را صرفاً زودتر شروع کنیم؛ بلکه هدف این است که مشکلات و Riskها را تا حد امکان قبل از تبدیل شدن به مشکلات پرهزینه شناسایی کنیم.

مثال ساده از Shift Left

فرض کنید Business تصمیم گرفته است امکان Refund را به یک فروشگاه اینترنتی اضافه کند.

اگر Tester فقط بعد از تکمیل Feature وارد شود، ممکن است در زمان Testing متوجه شود که Requirement درباره مواردی مانند Partial Refund، Refund بعد از ارسال کالا و Failure در Payment Gateway چیزی مشخص نکرده است.

اما اگر Tester از زمان بررسی Requirement در بحث حضور داشته باشد، بخشی از این ابهام‌ها قبل از Development مشخص می‌شوند.

در نتیجه هزینه اصلاح نیز می‌تواند کمتر شود.

Continuous Testing

در تیم‌های مدرن، Testing نیز می‌تواند بخشی از جریان مداوم Development و Delivery باشد.

برای مثال، بخشی از Testها می‌توانند به صورت Automated در Pipeline اجرا شوند تا تغییرات جدید قبل از رسیدن به مراحل بعدی بررسی شوند.

• Unit Tests
• API Tests
• Integration Tests
• Security Checks
• Static Analysis
• Smoke Tests

این رویکرد کمک می‌کند Feedback درباره تغییرات Software سریع‌تر به تیم برگردد.

Quality در CI/CD

در محیط‌های CI/CD، Quality می‌تواند به بخشی از Pipeline تبدیل شود.

برای مثال یک تغییر ممکن است قبل از Merge یا Deployment از چند مرحله عبور کند:

Code → Build → Automated Tests → Quality Checks → Deployment

این مدل باعث می‌شود برخی مشکلات خیلی زودتر از Production شناسایی شوند.

اما Automation به معنی Quality خودکار نیست

وجود Automated Tests به‌تنهایی تضمین نمی‌کند Software کیفیت بالایی دارد.

ممکن است Automation بسیار گسترده باشد، اما Testها سناریوهای اشتباه را بررسی کنند یا Riskهای مهم را پوشش ندهند.

بنابراین Automation باید در خدمت Strategy و Riskهای واقعی Product باشد.

Quality Feedback Loop

یکی از ویژگی‌های تیم‌های بالغ این است که اطلاعات مربوط به Quality فقط برای یک Release استفاده نمی‌شود.

اطلاعاتی که از Testها، Production، Incidentها، کاربران و Metrics به دست می‌آید، می‌تواند برای بهبود Releaseهای بعدی مورد استفاده قرار گیرد.

این چرخه را می‌توان به شکل ساده چنین دید:

Build → Test → Release → Monitor → Learn → Improve → Build

در چنین رویکردی Quality یک فعالیت یک‌باره نیست؛ بلکه یک فرآیند Continuous است.

Production نیز بخشی از چرخه یادگیری Quality است

قبل از Release ممکن است تیم تصور کند Software رفتار مورد انتظار را دارد، اما رفتار واقعی کاربران می‌تواند اطلاعات جدیدی ایجاد کند.

Monitoring و Observability می‌توانند به تیم کمک کنند مواردی مانند Error Rate، Latency، Availability و رفتار واقعی سیستم را مشاهده کند.

این داده‌ها می‌توانند ورودی مهمی برای تصمیم‌های Testing و Development بعدی باشند.

Quality یک مسئولیت مشترک است

در یک تیم حرفه‌ای، Quality نباید فقط به یک فرد یا یک نقش وابسته باشد.

Developer، Tester، Product، DevOps، Security و سایر اعضای تیم هرکدام می‌توانند روی کیفیت نهایی Software تأثیر بگذارند.

Tester نقش بسیار مهمی در ارزیابی و ارائه اطلاعات درباره Quality دارد، اما نمی‌تواند به‌تنهایی کیفیت یک محصول را ایجاد یا تضمین کند.

Quality Gate چیست؟

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

برای مثال یک تیم ممکن است تصمیم بگیرد تا زمانی که یک Critical Security Issue باز است، Deployment به Production انجام نشود.

Quality Gate می‌تواند به ایجاد حداقل استاندارد برای Release کمک کند، اما نباید جایگزین قضاوت حرفه‌ای و Risk Assessment شود.

Quality در تیم‌های Agile

در Agile، Quality نباید به فعالیتی تبدیل شود که فقط در پایان Sprint انجام می‌شود.

بهتر است Quality در طول چرخه انجام Work Itemها حضور داشته باشد؛ از Refinement و بررسی Requirement گرفته تا Development، Testing، Review و Release.

این نگاه کمک می‌کند Quality بخشی از فرآیند Delivery باشد، نه یک مرحله جدا از آن.

Quality ≠ Testing

یکی از مهم‌ترین نکات این بخش همین است:

Testing بخش مهمی از Quality است، اما Quality معادل Testing نیست.

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

چرا این تفاوت مهم است؟

اگر Quality را فقط با Testing یکی بدانیم، ممکن است این تصور ایجاد شود که کافی است Software ساخته شود و در پایان چند Test اجرا کنیم.

اما اگر Requirement اشتباه باشد، Architecture مناسب نباشد، Riskها شناسایی نشده باشند یا Feedback از Production به تیم برنگردد، حتی یک فرآیند Testing قوی نیز نمی‌تواند تمام مشکلات را جبران کند.

جمع‌بندی بخش هفدهم 🎯

• Quality از مرحله Testing شروع نمی‌شود؛ از مراحل ابتدایی چرخه Software شکل می‌گیرد.
• Requirementهای مبهم می‌توانند منشأ Defectهای بعدی باشند.
• Design و Architecture نیز تأثیر مستقیمی بر Quality دارند.
• Code Review می‌تواند برخی مشکلات را قبل از اجرای Software شناسایی کند.
• Shift Left تلاش می‌کند Riskها و مشکلات را زودتر شناسایی کند.
• Continuous Testing و CI/CD می‌توانند Feedback سریع‌تری درباره تغییرات ایجاد کنند.
• Automation به‌تنهایی تضمین‌کننده Quality نیست.
• Production و رفتار واقعی کاربران نیز بخشی از چرخه یادگیری Quality هستند.
• Quality یک مسئولیت مشترک در تیم است.
• Quality با Testing یکسان نیست؛ Testing یکی از ابزارهای مهم برای ارزیابی و بهبود آن است.

در بخش بعدی، به سراغ Continuous Improvement و نقش Feedback در ارتقای کیفیت Software می‌رویم و بررسی می‌کنیم یک تیم چگونه می‌تواند از مشکلات گذشته برای جلوگیری از تکرار آنها استفاده کند.

Continuous Improvement؛ چگونه Quality را در طول زمان بهتر کنیم؟

تا اینجا دیدیم که Quality فقط با پیدا کردن Bugها ایجاد نمی‌شود و Testing نیز تنها یکی از اجزای بزرگ‌تر سیستم Quality است.

اما حتی یک تیم حرفه‌ای نیز ممکن است اشتباه کند، Defect تولید کند یا Incident داشته باشد. تفاوت تیم‌های بالغ این نیست که هیچ‌وقت مشکل ندارند؛ بلکه این است که از مشکلات خود یاد می‌گیرند و احتمال تکرار آنها را کاهش می‌دهند.

Quality فقط پیدا کردن مشکل نیست؛ توانایی یادگیری از مشکل نیز بخشی از Quality است.

Continuous Improvement چیست؟

Continuous Improvement یعنی تلاش مداوم برای بهتر کردن Product، Process و روش‌های کار تیم بر اساس داده، تجربه و Feedback.

هدف آن لزوماً ایجاد تغییرات بزرگ نیست. گاهی یک تغییر کوچک در فرآیند می‌تواند از تکرار تعداد زیادی Defect جلوگیری کند.

چرا پیدا کردن یک Bug کافی نیست؟

فرض کنید Tester یک Bug مهم پیدا می‌کند، Developer آن را Fix می‌کند و Test مربوطه نیز Pass می‌شود.

اگر همین نوع Bug چند Sprint بعد دوباره اتفاق بیفتد، مشخص می‌شود که تیم فقط Problem را حل کرده، اما لزوماً Cause را برطرف نکرده است.

سؤال مهم‌تر این است:

«چه چیزی باعث شد این مشکل ایجاد شود و چگونه می‌توانیم احتمال تکرار آن را کاهش دهیم؟»

Corrective Action و Preventive Thinking

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

دو سؤال متفاوت می‌توانیم داشته باشیم:

• Corrective: چگونه این مشکل فعلی را برطرف کنیم؟
• Preventive: چگونه احتمال رخ دادن مشکل مشابه را کاهش دهیم؟

این تفکیک کمک می‌کند تیم از Fix کردن موردی به سمت بهبود سیستم حرکت کند.

Root Cause Analysis

یکی از روش‌های رایج برای یادگیری از مشکلات، Root Cause Analysis یا تحلیل علت ریشه‌ای است.

هدف این نیست که فقط اولین علت قابل مشاهده را پیدا کنیم؛ بلکه باید بررسی کنیم چه عواملی در نهایت باعث ایجاد مشکل شده‌اند.

مثال: قیمت اشتباه در Checkout

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

بررسی اولیه نشان می‌دهد مشکل در محاسبه Discount بوده است.

اما بررسی عمیق‌تر ممکن است زنجیره‌ای مانند این را نشان دهد:

• Discount Rule جدید اضافه شده است.
• Requirement مربوط به ترکیب چند Discount مبهم بوده است.
• Edge Caseها در زمان طراحی مشخص نشده‌اند.
• Test Scenario مربوط به ترکیب Discountها وجود نداشته است.
• Code Review نیز این حالت را بررسی نکرده است.

در این حالت، Fix کردن محاسبه Discount تنها بخشی از راه‌حل است.

روش Five Whys

یکی از تکنیک‌های ساده برای بررسی علت ریشه‌ای، Five Whys است.

ایده اصلی این است که با پرسیدن مکرر «چرا؟» از علت ظاهری عبور کنیم و به عوامل عمیق‌تر برسیم.

برای مثال:

• چرا قیمت سفارش اشتباه شد؟ → Discount اشتباه محاسبه شد.
• چرا Discount اشتباه محاسبه شد؟ → ترکیب دو Rule درست مدیریت نشد.
• چرا این حالت مدیریت نشد؟ → Scenario مربوطه در Requirement مشخص نبود.
• چرا Requirement این حالت را نداشت؟ → Edge Caseها در Refinement بررسی نشده بودند.
• چرا Edge Caseها بررسی نشده بودند؟ → فرآیند Refinement برای Featureهای مشابه Checklist مشخصی نداشت.

در این مثال، Root Cause ممکن است صرفاً یک Bug در Code نباشد؛ بلکه یک ضعف در فرآیند تحلیل Requirement باشد.

اما Five Whys همیشه دقیق نیست

Five Whys یک ابزار ساده است، نه یک فرمول قطعی برای پیدا کردن Root Cause.

مشکلات پیچیده معمولاً چند علت هم‌زمان دارند و ممکن است یک زنجیره خطی از «چرا»ها تصویر کاملی ارائه نکند.

در چنین شرایطی می‌توان از روش‌های تحلیلی دیگر مانند Fishbone Diagram، Fault Tree Analysis یا بررسی داده‌های Incident استفاده کرد.

Blameless Culture

یکی از عوامل مهم در Continuous Improvement، فرهنگ تیمی مناسب است.

اگر بعد از هر Incident اولین سؤال این باشد که «چه کسی مقصر بود؟»، احتمالاً افراد در آینده تمایل کمتری به گزارش مشکلات و صحبت کردن درباره اشتباهات خواهند داشت.

در مقابل، فرهنگ Blameless تلاش می‌کند تمرکز را از سرزنش افراد به سمت درک شرایط و بهبود سیستم ببرد.

Blameless به معنی بدون مسئولیت نیست

Blameless Culture به این معنی نیست که هیچ‌کس مسئول تصمیم‌های خود نیست.

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

Postmortem چیست؟

بعد از یک Incident مهم، تیم‌ها ممکن است یک Postmortem برگزار کنند تا اتفاق رخ‌داده را بررسی کنند.

در یک Postmortem مناسب معمولاً مواردی مانند این‌ها بررسی می‌شوند:

• چه اتفاقی افتاد؟
• چه زمانی مشکل شروع شد؟
• چگونه شناسایی شد؟
• چه اثری روی کاربران داشت؟
• چه اقداماتی برای Recovery انجام شد؟
• چه چیزی باعث ایجاد مشکل شد؟
• چه اقداماتی برای جلوگیری از تکرار لازم است؟

Incident بدون Action Item ارزش محدودی دارد

اگر تیم بعد از Incident فقط درباره اتفاق صحبت کند اما اقدام مشخصی تعریف نکند، احتمالاً یادگیری به تغییر واقعی تبدیل نمی‌شود.

Action Item باید تا حد امکان مشخص باشد.

ضعیف	بهتر
Testing را بهتر کنیم.	برای Payment Retry سه Scenario جدید به Regression Suite اضافه شود.
دقت بیشتری داشته باشیم.	در Refinement مربوط به Payment، Failure Scenarioها بررسی شوند.
Monitoring بهتر شود.	برای افزایش Error Rate در Payment Alert تعریف شود.

Quality Improvement باید قابل اندازه‌گیری باشد

اگر تیم تصمیم بگیرد فرآیندی را تغییر دهد، بهتر است بعداً بررسی کند که آیا تغییر واقعاً نتیجه‌ای ایجاد کرده است یا نه.

برای مثال اگر هدف کاهش Defect Escape باشد، می‌توان روند آن را در Releaseهای بعدی بررسی کرد.

در این حالت Continuous Improvement به یک چرخه تبدیل می‌شود:

Measure → Analyze → Improve → Measure Again

Quality Improvement همیشه به معنی Process Change نیست

گاهی مشکل با تغییر فرآیند حل نمی‌شود.

ممکن است نیاز باشد:

• Architecture تغییر کند.
• Automation افزایش پیدا کند.
• Test Environment بهبود پیدا کند.
• Monitoring اضافه شود.
• Documentation اصلاح شود.
• Training انجام شود.
• Tool جدیدی وارد فرآیند شود.

بنابراین Improvement باید متناسب با Root Cause انتخاب شود.

Defect Trend؛ آیا مشکلات در حال تکرار هستند؟

یکی از اطلاعات ارزشمند برای Continuous Improvement، بررسی روند Defectهاست.

اگر تیم مشاهده کند که در چند Release متوالی مشکلات مشابهی در یک بخش ایجاد می‌شوند، احتمالاً یک Problem Systemic وجود دارد.

در این شرایط فقط Fix کردن هر Bug به‌صورت جداگانه کافی نیست.

Problemهای تکرارشونده یک Signal هستند

فرض کنید در چند Release متوالی Bugهای مرتبط با Date و Time ایجاد می‌شوند.

این موضوع ممکن است نشان دهد که مشکل فقط در چند خط Code نیست؛ بلکه تیم باید موضوعاتی مانند Time Zone، Locale، Date Format و Test Data را جدی‌تر بررسی کند.

Learning باید وارد فرآیند شود

اگر تیم از یک Incident یاد گرفته است که یک Scenario خاص مهم است، این یادگیری نباید فقط در ذهن افراد باقی بماند.

بسته به شرایط می‌توان آن را به شکل‌های مختلف وارد سیستم کرد:

• Test Case جدید
• Automated Test
• Checklist
• Requirement Guideline
• Code Review Rule
• Monitoring Rule
• Documentation

به این ترتیب تجربه یک فرد یا یک Incident به دانش قابل استفاده برای کل تیم تبدیل می‌شود.

Continuous Improvement و Automation

Automation می‌تواند یکی از نتایج Continuous Improvement باشد.

اگر تیم مرتباً یک Regression Scenario مهم را به‌صورت دستی اجرا می‌کند و این Scenario بارها باعث ایجاد مشکل شده است، Automated کردن آن می‌تواند یک Improvement منطقی باشد.

اما Automation نباید هدف نهایی باشد؛ هدف، کاهش Risk و افزایش Feedback مؤثر است.

Quality Improvement و Feedback کاربران

Feedback کاربران یکی از منابع ارزشمند برای شناخت مشکلات واقعی Product است.

ممکن است تیم داخلی یک Feature را کاملاً موفق ارزیابی کند، اما کاربران به دلیل پیچیدگی UI یا رفتار غیرمنتظره سیستم تجربه خوبی نداشته باشند.

بنابراین User Feedback نیز می‌تواند بخشی از Quality Feedback Loop باشد.

بهبود کوچک اما مداوم

Continuous Improvement الزاماً به معنی اجرای پروژه‌های بزرگ و پرهزینه نیست.

گاهی تغییرات کوچک، اما مستمر، در طول زمان تأثیر بسیار زیادی ایجاد می‌کنند.

• یک Checklist بهتر
• یک Test Automation جدید
• یک Alert مناسب
• یک Requirement Guideline
• یک Code Review Rule
• یک Test Data Strategy بهتر

مجموع همین تغییرات کوچک می‌تواند کیفیت فرآیند و Product را به‌مرور افزایش دهد.

Continuous Improvement نباید به جلسه‌های بی‌نتیجه تبدیل شود

یکی از مشکلات رایج این است که تیم مرتباً درباره مشکلات صحبت می‌کند، اما هیچ تغییر واقعی اتفاق نمی‌افتد.

برای جلوگیری از این وضعیت، هر Improvement مهم باید تا حد امکان:

• هدف مشخص داشته باشد.
• اقدام مشخص داشته باشد.
• مالک مشخص داشته باشد.
• زمان‌بندی مشخص داشته باشد.
• نتیجه آن قابل بررسی باشد.

نگاه حرفه‌ای Tester به Continuous Improvement

Tester حرفه‌ای فقط نمی‌پرسد:

«این Bug چرا ایجاد شد؟»

بلکه سؤال‌های عمیق‌تری مطرح می‌کند:

• چرا قبل از Production پیدا نشد؟
• آیا Test مناسب وجود داشت؟
• آیا Requirement واضح بود؟
• آیا Risk قبلاً شناخته شده بود؟
• آیا می‌توان این نوع Bug را Automated کرد؟
• آیا مشابه این مشکل قبلاً رخ داده است؟
• چگونه می‌توان از تکرار آن جلوگیری کرد؟

این نوع نگاه باعث می‌شود Testing از یک فعالیت صرفاً تشخیصی به یکی از منابع مهم Learning در تیم تبدیل شود.

جمع‌بندی بخش هجدهم 🎯

• Continuous Improvement یعنی یادگیری و بهتر کردن مداوم Product و Process.
• Fix کردن یک Bug لزوماً به معنی حل علت اصلی مشکل نیست.
• Root Cause Analysis می‌تواند به کشف عوامل عمیق‌تر کمک کند.
• Five Whys یک تکنیک ساده برای بررسی علت ریشه‌ای است، اما همیشه کافی نیست.
• فرهنگ Blameless می‌تواند گزارش و تحلیل مشکلات را آسان‌تر کند.
• Postmortem باید به Action Itemهای مشخص منجر شود.
• Improvement باید متناسب با Root Cause انتخاب شود.
• Defectهای تکرارشونده می‌توانند نشانه یک مشکل Systemic باشند.
• Learning باید به Test، Automation، Checklist، Monitoring یا سایر بخش‌های فرآیند منتقل شود.
• هدف Continuous Improvement ایجاد تغییر واقعی و قابل اندازه‌گیری است، نه صرفاً برگزاری جلسه و تولید گزارش.

در بخش بعدی، به سراغ Quality در دنیای واقعی و تفاوت بین Quality در تئوری و Quality در Production می‌رویم و بررسی می‌کنیم چرا یک Software ممکن است تمام Testهای داخلی را با موفقیت پشت سر بگذارد اما همچنان در دنیای واقعی با مشکل مواجه شود.

Quality در دنیای واقعی؛ چرا Software بعد از Release هنوز ممکن است مشکل داشته باشد؟

تا اینجا بیشتر درباره فعالیت‌هایی صحبت کردیم که قبل از Release برای افزایش Quality انجام می‌شوند. اما یک واقعیت مهم وجود دارد:

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

دلیل این موضوع این است که محیط واقعی بسیار پیچیده‌تر از Test Environment است.

Test Environment با Production یکسان نیست

یکی از مهم‌ترین دلایل بروز مشکل بعد از Release، تفاوت بین محیط Testing و Production است.

در محیط Test ممکن است همه چیز کنترل‌شده باشد:

• تعداد کاربران محدود است.
• Test Data کنترل‌شده است.
• سرویس‌های خارجی پایدار هستند.
• Network شرایط نسبتاً مشخصی دارد.
• تنوع Deviceها محدود است.
• Load واقعی وجود ندارد.

اما Production شرایط کاملاً متفاوتی دارد.

Production رفتارهای پیش‌بینی‌نشده دارد

کاربران واقعی همیشه همان مسیری را طی نمی‌کنند که تیم در زمان طراحی Test Case تصور کرده است.

ممکن است کاربر:

• دکمه‌ای را چند بار پشت سر هم کلیک کند.
• در میانه یک فرآیند اینترنت خود را از دست بدهد.
• با یک Device قدیمی وارد شود.
• از Browser متفاوتی استفاده کند.
• داده‌ای وارد کند که تیم انتظارش را نداشته است.
• یک فرآیند را نیمه‌کاره رها کند و بعداً ادامه دهد.

هرکدام از این رفتارها می‌تواند یک Edge Case جدید ایجاد کند.

تعداد کاربران نیز یک عامل مهم است

ممکن است یک Application با ۱۰۰ کاربر کاملاً پایدار باشد، اما وقتی تعداد کاربران به چند هزار یا چند میلیون نفر برسد، رفتار سیستم تغییر کند.

در این شرایط موضوعاتی مانند:

• Response Time
• Throughput
• Resource Consumption
• Database Load
• Queue Size
• Error Rate

اهمیت بیشتری پیدا می‌کنند.

این موضوع نشان می‌دهد که Functional Testing به‌تنهایی برای ارزیابی تمام جنبه‌های Quality کافی نیست.

External Dependencies

بسیاری از Softwareهای امروزی به سرویس‌های خارجی وابسته‌اند.

• Payment Gateway
• Email Provider
• SMS Provider
• Cloud Services
• Authentication Provider
• Maps API
• Third-Party Libraries

در Test Environment ممکن است این سرویس‌ها همیشه در دسترس باشند، اما در Production ممکن است Timeout، Rate Limit، Downtime یا تغییر رفتار API رخ دهد.

یک مثال: Payment Gateway

فرض کنید Test مربوط به Payment در محیط Test با موفقیت انجام شده است.

اما در Production، Payment Gateway برای چند ثانیه پاسخ نمی‌دهد.

حالا چند سؤال مهم ایجاد می‌شود:

• آیا Order ساخته می‌شود؟
• آیا Payment دوباره ارسال می‌شود؟
• اگر مبلغ کسر شده باشد اما پاسخ دریافت نشود چه اتفاقی می‌افتد؟
• آیا کاربر می‌تواند دوباره پرداخت کند؟
• آیا سیستم می‌تواند وضعیت تراکنش را بعداً بازیابی کند؟

این‌ها مثال‌هایی از Failure Scenario هستند که اهمیت آنها در Production بسیار بیشتر می‌شود.

Data واقعی می‌تواند رفتار متفاوتی ایجاد کند

Test Data معمولاً ساده‌تر و کنترل‌شده‌تر از داده‌های واقعی است.

در Production ممکن است داده‌هایی وجود داشته باشند که تیم هنگام طراحی Test Scenario به آنها فکر نکرده است.

برای مثال:

• نام‌های بسیار طولانی
• کاراکترهای خاص
• داده‌های قدیمی
• Accountهای ناقص
• اطلاعات مهاجرت‌یافته از سیستم قبلی
• ترکیب‌های غیرمعمول داده

این داده‌ها می‌توانند Bugهایی را آشکار کنند که در Test Environment دیده نشده‌اند.

Browser و Device Diversity

کاربران واقعی از مجموعه بسیار متنوعی از Deviceها، Operating Systemها و Browserها استفاده می‌کنند.

ممکن است یک Web Application در محیط اصلی تیم کاملاً درست کار کند اما در یک Browser یا Device خاص دچار مشکل شود.

به همین دلیل Compatibility و Cross-Browser Testing برای برخی محصولات اهمیت زیادی دارد.

Accessibility در دنیای واقعی

یک Application ممکن است از نظر Functional Testing کاملاً موفق باشد، اما برای بخشی از کاربران قابل استفاده نباشد.

برای مثال ممکن است:

• Keyboard Navigation مناسب نباشد.
• Contrast کافی نباشد.
• Screen Reader نتواند عناصر را درست تشخیص دهد.
• Focus به شکل مناسبی مدیریت نشود.

در چنین شرایطی Software ممکن است «کار کند»، اما Quality آن برای همه کاربران مناسب نیست.

Security Risk ممکن است در Test عادی دیده نشود

یک Application ممکن است تمام Functional Testهای خود را Pass کند، اما همچنان یک Security Vulnerability جدی داشته باشد.

مثلاً یک کاربر می‌تواند با تغییر یک شناسه در URL به اطلاعات کاربر دیگری دسترسی پیدا کند.

در این حالت Feature از نظر Functional ممکن است کار کند، اما از نظر Security یک مشکل جدی وجود دارد.

Observability و نقش آن در Quality

در سیستم‌های مدرن، فقط Test کردن Software کافی نیست؛ باید بتوانیم بعد از Release نیز بفهمیم سیستم چه وضعیتی دارد.

اینجاست که Observability اهمیت پیدا می‌کند.

ابزارها و روش‌های Observability معمولاً به تیم کمک می‌کنند اطلاعاتی درباره مواردی مانند:

• Logs
• Metrics
• Traces
• Errors
• Latency

به دست بیاورد.

Monitoring فقط برای DevOps نیست

Monitoring می‌تواند اطلاعات ارزشمندی برای تیم Testing و Quality نیز ایجاد کند.

برای مثال اگر بعد از Release مشخص شود Error Rate مربوط به یک API خاص دو برابر شده است، این اطلاعات می‌تواند نشان‌دهنده یک Quality Problem باشد؛ حتی اگر Testهای قبل از Release همه Pass شده باشند.

Feature Flag و کنترل Risk

در برخی سیستم‌ها Feature جدید بلافاصله برای همه کاربران فعال نمی‌شود.

با استفاده از Feature Flag می‌توان یک Feature را ابتدا برای گروه محدودی از کاربران فعال کرد و رفتار آن را بررسی کرد.

این روش می‌تواند به کاهش Risk مربوط به Releaseهای بزرگ کمک کند.

Canary Release

در Canary Release نیز نسخه جدید ابتدا برای بخشی از Traffic یا کاربران ارائه می‌شود.

اگر سیستم رفتار مناسبی داشته باشد، Release به‌تدریج گسترش پیدا می‌کند.

این رویکرد می‌تواند به تیم کمک کند مشکلات Production را قبل از تأثیر گسترده شناسایی کند.

Rollback نیز بخشی از Quality است

گاهی اوقات با وجود تمام Testها، Release مشکل‌دار می‌شود.

در چنین شرایطی توانایی بازگشت سریع به نسخه سالم قبلی می‌تواند Impact مشکل را کاهش دهد.

بنابراین Quality فقط به جلوگیری از Failure مربوط نیست؛ توانایی Recovery نیز اهمیت دارد.

Resilience و Quality

یک سیستم با Quality مناسب فقط در شرایط ایده‌آل نباید کار کند.

باید تا حد امکان بتواند در برابر Failureهای قابل انتظار نیز رفتار مناسبی داشته باشد.

• قطع شدن سرویس خارجی
• Network Failure
• Timeout
• Database Failure
• افزایش ناگهانی Traffic

این موضوع ما را به مفاهیمی مانند Resilience و Reliability نزدیک می‌کند.

Quality در Production یک وضعیت ثابت نیست

حتی اگر یک Release در روز اول بدون مشکل باشد، Quality آن ممکن است در طول زمان تغییر کند.

ممکن است:

• تعداد کاربران افزایش پیدا کند.
• Dependency خارجی تغییر کند.
• داده‌ها رشد کنند.
• Featureهای جدید اضافه شوند.
• Infrastructure تغییر کند.

بنابراین Quality باید به‌صورت مداوم پایش شود.

تفاوت «Software کار می‌کند» با «Software کیفیت دارد»

این دو جمله یکی نیستند.

یک Software ممکن است وظیفه اصلی خود را انجام دهد، اما:

• کند باشد.
• ناامن باشد.
• برای برخی کاربران قابل دسترس نباشد.
• در شرایط خاص Crash کند.
• نگهداری آن بسیار دشوار باشد.
• در برابر Failureها Recovery مناسبی نداشته باشد.

بنابراین Quality یک مفهوم چندبعدی است.

یک نگاه واقعی به Quality

فرض کنید یک فروشگاه اینترنتی در Test Environment هیچ Bug مهمی ندارد.

اما بعد از Release:

• در ساعات پرترافیک Response Time افزایش پیدا می‌کند.
• برخی Paymentها Timeout می‌شوند.
• کاربران موبایل قدیمی مشکل UI دارند.
• یک Browser خاص Checkout را درست نمایش نمی‌دهد.
• تعداد زیادی کاربر در فرآیند Refund با مشکل مواجه می‌شوند.

در این حالت نمی‌توان گفت Software چون Testها را Pass کرده، پس Quality بالایی دارد.

Testها اطلاعاتی درباره وضعیت Software ارائه کرده‌اند، اما واقعیت Production اطلاعات بیشتری آشکار کرده است.

Tester باید از Production هم یاد بگیرد

برای Tester حرفه‌ای، Production فقط محل وقوع Bug نیست؛ یک منبع مهم برای یادگیری است.

اگر یک Incident در Production رخ دهد، باید بررسی شود که آیا می‌توانستیم آن Scenario را زودتر شناسایی کنیم یا خیر.

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

هدف نهایی Quality چیست؟

هدف Quality این نیست که Software را به یک محصول کاملاً بدون خطا تبدیل کنیم؛ چنین چیزی در Softwareهای پیچیده واقع‌بینانه نیست.

هدف این است که:

• Riskهای مهم شناخته شوند.
• Defectهای مهم تا حد امکان زود شناسایی شوند.
• Software در شرایط واقعی رفتار قابل قبولی داشته باشد.
• Failureها Impact کنترل‌شده‌ای داشته باشند.
• مشکلات Production سریع شناسایی و رفع شوند.
• تیم از تجربه‌های گذشته یاد بگیرد.

جمع‌بندی بخش نوزدهم 🎯

• موفقیت در Test Environment تضمین‌کننده موفقیت در Production نیست.
• تفاوت Environment، Data، کاربران و Traffic می‌تواند رفتار Software را تغییر دهد.
• External Dependencies می‌توانند منبع مهم Risk باشند.
• Functional Testing به‌تنهایی تمام ابعاد Quality را پوشش نمی‌دهد.
• Security، Performance، Accessibility، Compatibility و Resilience نیز می‌توانند روی Quality تأثیر بگذارند.
• Monitoring و Observability به تیم کمک می‌کنند وضعیت واقعی Software را بعد از Release مشاهده کند.
• Feature Flag و Canary Release می‌توانند Risk مربوط به Release را کاهش دهند.
• Rollback و Recovery نیز بخشی از کیفیت عملیاتی Software هستند.
• Quality در Production یک وضعیت ثابت نیست و باید به‌صورت مستمر پایش شود.
• Production می‌تواند یکی از مهم‌ترین منابع Learning برای تیم Testing و Development باشد.

در بخش بعدی، سراغ نقش انسان در Quality؛ همکاری Tester، Developer، Product و سایر اعضای تیم می‌رویم و بررسی می‌کنیم چرا Quality زمانی بهتر می‌شود که مسئولیت آن به یک نقش خاص محدود نشود.

نقش افراد و همکاری تیمی در Quality؛ کیفیت یک کار تیمی است

در بخش‌های قبل دیدیم که Quality به Requirement، Design، Code، Testing، Deployment و حتی Production وابسته است. بنابراین منطقی است که کیفیت یک Software را نتوان فقط به یک نفر یا یک نقش نسبت داد.

Quality یک خروجی تیمی است، نه مسئولیت یک نفر.

Tester نقش بسیار مهمی در ارزیابی Quality دارد، اما اگر Requirement مشکل داشته باشد، Architecture نامناسب باشد یا تصمیم Product اشتباه باشد، Tester به‌تنهایی نمی‌تواند تمام این مشکلات را جبران کند.

آیا Tester مسئول Quality است؟

این سؤال در بسیاری از تیم‌ها مطرح می‌شود.

پاسخ دقیق این است که Tester مسئولیت مهمی در Quality دارد، اما مالک انحصاری Quality نیست.

وظیفه Tester این است که با استفاده از Testing، تحلیل Risk، بررسی رفتار Software و ارائه Feedback، اطلاعات ارزشمندی درباره وضعیت Product در اختیار تیم قرار دهد.

اما تصمیم‌های مربوط به Product، Architecture، Code، Infrastructure و Business نیز مستقیماً روی Quality تأثیر می‌گذارند.

نقش Developer در Quality

Developer فقط مسئول نوشتن Code نیست.

تصمیم‌های Developer می‌توانند روی مواردی مانند Reliability، Maintainability، Security، Performance و Testability تأثیر مستقیم داشته باشند.

• نوشتن Code قابل نگهداری
• مدیریت مناسب Errorها
• نوشتن Unit Test در صورت نیاز
• در نظر گرفتن Edge Caseها
• انجام Code Review
• توجه به Security و Performance

بنابراین کیفیت از همان لحظه‌ای که Code نوشته می‌شود تحت تأثیر قرار می‌گیرد.

نقش Product Manager یا Product Owner

تصمیم‌های Product نیز می‌توانند Quality را تحت تأثیر قرار دهند.

اگر Requirementها مبهم باشند یا برای یک Feature، رفتار مورد انتظار به‌خوبی مشخص نشده باشد، احتمال ایجاد اختلاف بین چیزی که Business می‌خواهد و چیزی که تیم توسعه می‌دهد افزایش پیدا می‌کند.

Product نیز باید درباره مواردی مانند:

• Acceptance Criteria
• Business Rules
• اولویت‌ها
• Riskهای Business
• رفتار مورد انتظار کاربران

شفافیت ایجاد کند.

نقش Business در Quality

گاهی یک مشکل فنی نیست؛ بلکه نتیجه یک تصمیم Business است.

فرض کنید تیم برای کاهش هزینه، یک Third-Party Service ارزان‌تر انتخاب می‌کند که Reliability پایین‌تری دارد.

حتی اگر Developer و Tester تمام وظایف خود را به‌درستی انجام دهند، این تصمیم می‌تواند روی کیفیت نهایی Product تأثیر بگذارد.

به همین دلیل Quality باید در سطح تصمیم‌گیری Product نیز دیده شود.

نقش DevOps و Infrastructure

یک Software ممکن است در Test Environment کاملاً درست کار کند، اما Infrastructure نامناسب باعث شود در Production با مشکل مواجه شود.

• Deployment
• Scaling
• Monitoring
• Logging
• Backup
• Recovery

همگی می‌توانند بخشی از Quality عملیاتی سیستم باشند.

همکاری Tester و Developer

یکی از مهم‌ترین همکاری‌ها در تیم Software، ارتباط بین Tester و Developer است.

یک رابطه سالم نباید بر اساس «Tester Bug پیدا می‌کند و Developer دفاع می‌کند» شکل بگیرد.

هدف مشترک هر دو نقش باید این باشد که Software رفتار مورد انتظار را داشته باشد و Riskهای مهم کنترل شوند.

Bug نباید تبدیل به بحث شخصی شود

وقتی Tester یک Bug گزارش می‌کند، هدف نباید نشان دادن اشتباه یک Developer باشد.

Bug یک ویژگی شخصی یا شکست یک فرد نیست؛ بلکه یک اطلاعات درباره وضعیت Software است.

این نگاه می‌تواند فضای همکاری را بسیار بهتر کند.

Bug Report خوب، ارتباط را ساده‌تر می‌کند

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

• Steps to Reproduce واضح
• Expected Result
• Actual Result
• Environment
• Evidence
• Severity مناسب

هرچه اطلاعات گزارش دقیق‌تر باشد، Developer زمان کمتری برای بازسازی شرایط و فهمیدن مشکل صرف می‌کند.

Tester و Developer باید زودتر با هم صحبت کنند

یکی از روش‌های مؤثر برای کاهش مشکلات، صحبت کردن قبل از کامل شدن Feature است.

برای مثال Tester می‌تواند قبل از شروع Development درباره Scenarioهای زیر سؤال مطرح کند:

• حالت موفق چیست؟
• حالت Failure چیست؟
• Edge Caseها کدام‌اند؟
• اگر سرویس خارجی در دسترس نباشد چه اتفاقی می‌افتد؟
• چه محدودیت‌هایی برای Input وجود دارد؟

این نوع همکاری می‌تواند بسیاری از مشکلات را قبل از ورود به مرحله Testing کاهش دهد.

Three Amigos

در برخی تیم‌های Agile، مفهومی به نام Three Amigos برای ایجاد گفت‌وگو میان افراد مختلف درباره یک Feature استفاده می‌شود.

سه دیدگاه اصلی معمولاً شامل:

• Business / Product
• Development
• Testing

است.

هدف این جلسات این است که قبل از Development، برداشت مشترکی از رفتار مورد انتظار و Scenarioهای مهم ایجاد شود.

Quality در تیم Cross-Functional

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

این ساختار باعث می‌شود تصمیم‌های مربوط به Quality از ابتدا در کنار Development و Product مطرح شوند.

در چنین تیمی، Tester نباید آخرین فردی باشد که Feature را می‌بیند.

Definition of Done و Quality

در تیم‌های Agile، Definition of Done می‌تواند مشخص کند چه شرایطی باید برقرار باشد تا یک Work Item واقعاً Done محسوب شود.

برای مثال ممکن است شامل موارد زیر باشد:

• Code تکمیل شده باشد.
• Code Review انجام شده باشد.
• Testهای لازم اجرا شده باشند.
• Acceptance Criteria برآورده شده باشد.
• Bugهای مهم تعیین تکلیف شده باشند.

Definition of Done می‌تواند Quality Expectation را به بخشی از فرآیند Delivery تبدیل کند.

Definition of Ready و جلوگیری از ابهام

در برخی تیم‌ها، قبل از شروع Development نیز معیارهایی برای آماده بودن یک Work Item تعریف می‌شود.

هدف این است که تیم روی Requirementی کار نکند که هنوز ابهام‌های مهم دارد.

ارتباط ضعیف، یکی از دشمنان Quality

بسیاری از مشکلات Software لزوماً نتیجه یک اشتباه پیچیده فنی نیستند.

گاهی یک سوءتفاهم ساده بین Product، Developer و Tester باعث می‌شود Software رفتاری متفاوت از انتظار داشته باشد.

برای همین Communication یک مهارت جانبی بی‌اهمیت نیست؛ بخشی از فرآیند Quality است.

Knowledge Sharing

اگر دانش مربوط به یک بخش حساس Software فقط در ذهن یک نفر باشد، تیم در برابر تغییرات آسیب‌پذیر می‌شود.

Documentation، Pairing، Code Review و Knowledge Sharing می‌توانند وابستگی به یک فرد را کاهش دهند.

وقتی تیم Quality را فقط به Tester واگذار می‌کند

یک Anti-Pattern رایج این است که سایر اعضای تیم تصور کنند:

«Software را می‌سازیم؛ Tester بعداً کیفیتش را بررسی می‌کند.»

این نگاه باعث می‌شود بسیاری از مشکلات دیر کشف شوند و فشار زیادی روی مرحله Testing ایجاد شود.

در یک تیم بالغ، Quality از ابتدا در تصمیم‌ها و فعالیت‌های مختلف حضور دارد.

وقتی Tester همه چیز را باید خودش تست کند

Anti-Pattern دیگری این است که Tester تبدیل به آخرین خط دفاعی شود و انتظار برود همه مشکلات را قبل از Release پیدا کند.

این مدل هم از نظر عملیاتی پرریسک است و هم باعث ایجاد Bottleneck می‌شود.

بهتر است هر نقش بخشی از مسئولیت Quality مربوط به فعالیت خودش را بر عهده داشته باشد.

Quality Ownership

Quality Ownership یعنی اعضای تیم نسبت به کیفیت خروجی خود احساس مسئولیت داشته باشند.

Developer فقط نمی‌گوید «Code نوشته شد»؛ بلکه به Testability و رفتار درست آن نیز توجه می‌کند.

Product فقط نمی‌گوید «Feature ساخته شد»؛ بلکه بررسی می‌کند آیا واقعاً نیاز کاربر را حل می‌کند یا خیر.

Tester نیز فقط به دنبال Bug نیست؛ بلکه Riskهای Product را تحلیل و درباره آنها Feedback ارائه می‌کند.

یک تیم بالغ چگونه به Quality نگاه می‌کند؟

• Quality از ابتدا مورد توجه قرار می‌گیرد.
• Tester زود وارد بحث می‌شود.
• Developer نسبت به کیفیت Code مسئولیت دارد.
• Product Requirementهای شفاف‌تری ایجاد می‌کند.
• Bugها به شکل شخصی دیده نمی‌شوند.
• Production Feedback وارد چرخه توسعه می‌شود.
• مشکلات تکرارشونده تحلیل می‌شوند.
• Quality به یک نقش خاص محدود نمی‌شود.

جمع‌بندی بخش بیستم 🎯

• Quality مسئولیت یک فرد یا یک نقش خاص نیست.
• Tester نقش مهمی در ارزیابی و ارائه Feedback درباره Quality دارد، اما مالک انحصاری آن نیست.
• Developer، Product، DevOps و سایر اعضای تیم نیز مستقیماً روی Quality تأثیر می‌گذارند.
• همکاری زودهنگام Tester و Developer می‌تواند از بسیاری از مشکلات جلوگیری کند.
• Bug Report دقیق باعث ارتباط بهتر و سریع‌تر می‌شود.
• Three Amigos می‌تواند به ایجاد درک مشترک درباره Requirement و Scenarioها کمک کند.
• Definition of Done می‌تواند معیارهای Quality را وارد فرآیند Delivery کند.
• Communication و Knowledge Sharing نیز روی Quality تأثیر دارند.
• واگذار کردن کامل Quality به Tester یک Anti-Pattern است.
• در یک تیم بالغ، Quality به یک مسئولیت مشترک و بخشی از فرهنگ تیم تبدیل می‌شود.

در بخش بعدی، به سراغ Quality Metrics و شاخص‌هایی که می‌توانند به تیم در اندازه‌گیری و تصمیم‌گیری درباره کیفیت کمک کنند می‌رویم؛ البته با این نکته مهم که هر Metric لزوماً نشان‌دهنده Quality واقعی نیست.

Quality Metrics؛ چگونه کیفیت Software را اندازه‌گیری کنیم؟

تا اینجا درباره ابعاد مختلف Quality، نقش Testing، Production، همکاری تیمی و Continuous Improvement صحبت کردیم. اما یک سؤال مهم باقی می‌ماند:

از کجا بفهمیم کیفیت Software در حال بهتر شدن است یا بدتر شدن؟

برای پاسخ به این سؤال، تیم‌ها از Quality Metrics استفاده می‌کنند. Metricها می‌توانند اطلاعات مفیدی درباره وضعیت Product و فرآیند توسعه ارائه دهند؛ اما باید با دقت انتخاب و تفسیر شوند.

آیا هر عددی یک Quality Metric است؟

خیر.

اینکه بتوانیم چیزی را اندازه‌گیری کنیم، به این معنی نیست که آن عدد واقعاً Quality را نشان می‌دهد.

برای مثال اگر بگوییم:

«تیم ما این Sprint، ۵۰۰ Test اجرا کرده است.»

این عدد به‌تنهایی اطلاعات زیادی درباره کیفیت Product نمی‌دهد.

ممکن است ۵۰۰ Test داشته باشیم، اما مهم‌ترین Riskهای Product اصلاً پوشش داده نشده باشند.

Metric خوب چه ویژگی‌هایی دارد؟

یک Metric مفید باید به تیم کمک کند بهتر تصمیم بگیرد، نه اینکه فقط یک عدد زیبا برای گزارش مدیریتی تولید کند.

• قابل اندازه‌گیری باشد.
• هدف مشخصی داشته باشد.
• قابل تفسیر باشد.
• در طول زمان قابل مقایسه باشد.
• با Business و Product Risk ارتباط داشته باشد.
• باعث رفتار اشتباه در تیم نشود.

Defect Density

Defect Density تلاش می‌کند تعداد Defectها را نسبت به اندازه مشخصی از Software بیان کند.

اندازه Software می‌تواند با معیارهایی مانند Lines of Code یا معیارهای دیگر تعریف شود، هرچند در Software مدرن استفاده از Lines of Code به‌عنوان معیار اصلی همیشه انتخاب مناسبی نیست.

این Metric می‌تواند در برخی شرایط برای مقایسه روندها مفید باشد، اما به‌تنهایی نمی‌تواند Quality واقعی Product را مشخص کند.

Defect Escape Rate

یکی از Metricهای مهم‌تر، بررسی Defectهایی است که قبل از Release شناسایی نشده‌اند و بعد از Release در محیط واقعی پیدا شده‌اند.

اگر تعداد یا نسبت این Defectها در طول زمان کاهش پیدا کند، می‌تواند نشانه‌ای از بهبود فرآیند باشد.

Defect Reopen Rate

این Metric نشان می‌دهد چه تعداد از Bugهایی که به‌عنوان Fixed علامت‌گذاری شده‌اند، دوباره به دلیل برطرف نشدن کامل مشکل یا ایجاد مشکل جدید باز شده‌اند.

افزایش این مقدار می‌تواند نشانه‌ای از مشکل در Root Cause Analysis، Development، Requirement یا حتی فرآیند Verification باشد.

Test Pass Rate

Test Pass Rate یکی از Metricهای رایج در تیم‌های Testing است.

اما باید با احتیاط تفسیر شود.

اگر ۹۹٪ Testها Pass شوند، لزوماً به این معنی نیست که Software کیفیت بسیار بالایی دارد.

ممکن است Test Suite مهم‌ترین Scenarioها را پوشش نداده باشد.

Test Coverage

Coverage می‌تواند اطلاعاتی درباره میزان پوشش Code یا Scenarioهای مختلف ارائه کند.

برای مثال:

• Code Coverage
• Requirement Coverage
• Risk Coverage
• Feature Coverage

اما Coverage بالا نیز به‌تنهایی Quality را تضمین نمی‌کند.

Coverage بالا با Testهای ضعیف، فقط پوشش بالای Testهای ضعیف است.

Code Coverage؛ یک سوءبرداشت رایج

فرض کنید یک تیم به Code Coverage برابر با ۹۵٪ رسیده است.

این عدد نشان می‌دهد بخش بزرگی از Code در زمان اجرای Testها پوشش داده شده است، اما نمی‌گوید آیا Assertions درست هستند یا Scenarioهای مهم Business پوشش داده شده‌اند.

بنابراین Code Coverage باید به‌عنوان یک Signal دیده شود، نه یک نمره نهایی برای Quality.

Requirements Coverage

یکی دیگر از ابعاد Coverage، بررسی این است که آیا Requirementهای مهم دارای Test مناسب هستند یا خیر.

این نوع Coverage از دید Business می‌تواند اطلاعات مفیدتری نسبت به یک عدد خام Code Coverage ارائه دهد.

Risk Coverage

در Risk-Based Testing، مهم است بدانیم آیا Riskهای مهم Product توسط Testها پوشش داده شده‌اند یا خیر.

ممکن است یک Feature کم‌اهمیت Coverage بسیار بالایی داشته باشد، در حالی که یک Payment Flow حیاتی Test کافی نداشته باشد.

از این منظر، Risk Coverage می‌تواند برای تصمیم‌گیری بسیار ارزشمند باشد.

Mean Time to Detect

MTTD یا Mean Time to Detect به‌طور کلی به میانگین زمانی اشاره دارد که طول می‌کشد یک مشکل شناسایی شود.

کاهش زمان Detection می‌تواند باعث شود Impact یک Incident کمتر شود.

Mean Time to Recovery

MTTR معمولاً برای بیان میانگین زمان مورد نیاز برای Recovery یا بازگرداندن سرویس به وضعیت مناسب استفاده می‌شود.

یک تیم ممکن است نتواند جلوی تمام Failureها را بگیرد، اما اگر بتواند آنها را سریع Detect و Recover کند، Impact را کاهش می‌دهد.

Production Error Rate

بررسی Error Rate در Production می‌تواند اطلاعات مستقیمی درباره رفتار واقعی Software ارائه دهد.

اگر بعد از یک Release، Error Rate یک API مهم افزایش پیدا کند، این موضوع می‌تواند یک Signal مهم برای بررسی Quality باشد.

Availability و Reliability

برای برخی Softwareها، کیفیت فقط به درست بودن Featureها محدود نیست؛ در دسترس بودن و قابل اعتماد بودن سیستم نیز اهمیت زیادی دارد.

Metricهایی مانند Availability و Reliability می‌توانند برای این دسته از سیستم‌ها اهمیت ویژه‌ای داشته باشند.

Performance Metrics

برای ارزیابی Performance نیز Metricهای مختلفی وجود دارند:

• Response Time
• Latency
• Throughput
• Error Rate
• Resource Utilization

این Metricها به‌خصوص در سیستم‌هایی که Performance برای Business اهمیت زیادی دارد، اطلاعات ارزشمندی ایجاد می‌کنند.

Customer-Reported Issues

تعداد مشکلاتی که کاربران گزارش می‌کنند نیز می‌تواند یک Signal مهم باشد.

البته افزایش تعداد گزارش‌ها همیشه به معنی بدتر شدن Software نیست؛ ممکن است تعداد کاربران افزایش یافته باشد یا فرآیند گزارش‌دهی بهتر شده باشد.

بنابراین Context همیشه مهم است.

Customer Satisfaction

Quality فقط از دید فنی تعریف نمی‌شود.

اگر کاربران نتوانند به‌راحتی با Product کار کنند یا تجربه مناسبی نداشته باشند، حتی یک Software فنی و پایدار نیز ممکن است از دید Business موفق نباشد.

بنابراین در برخی محصولات، معیارهایی مانند User Satisfaction، Customer Feedback و Support Tickets نیز ارزشمند هستند.

Lead Time و اثر آن بر Quality

سرعت Delivery نیز می‌تواند به شکل غیرمستقیم با Quality ارتباط داشته باشد.

اگر تیم بتواند تغییرات کوچک‌تر را با سرعت و Feedback مناسب Delivery کند، ممکن است مدیریت Risk آسان‌تر شود.

اما افزایش سرعت بدون کنترل Quality می‌تواند نتیجه معکوس داشته باشد.

چرا تعداد Bug معیار مناسبی برای رتبه‌بندی Tester نیست؟

این یکی از اشتباهات رایج در استفاده از Metrics است.

اگر عملکرد Tester را با «تعداد Bugهای پیدا شده» بسنجیم، ممکن است رفتارهای ناسالم ایجاد شود.

• گزارش Bugهای کم‌اهمیت افزایش پیدا کند.
• Bugهای مشابه چند بار گزارش شوند.
• تمرکز روی تعداد به جای اهمیت Bug قرار گیرد.
• Tester به دنبال افزایش مصنوعی آمار باشد.

در حالی که ممکن است یک Tester با پیدا کردن تنها یک Critical Bug، ارزش بسیار بیشتری نسبت به پیدا کردن ده‌ها Bug جزئی ایجاد کند.

Goodhart’s Law و Quality Metrics

یک اصل مهم در استفاده از Metrics این است که وقتی یک Metric به هدف تبدیل شود، ممکن است افراد رفتار خود را برای بهبود همان Metric تغییر دهند، بدون اینکه الزاماً نتیجه واقعی بهتر شود.

برای مثال اگر هدف تیم «کاهش تعداد Bugهای باز» باشد، ممکن است تعداد Bugها کاهش پیدا کند فقط به این دلیل که برخی Bugها بسته یا Reclassify شده‌اند؛ نه به این دلیل که Software واقعاً بهتر شده است.

Metric را برای یادگیری استفاده کنیم، نه تنبیه

اگر Metrics به ابزاری برای سرزنش افراد تبدیل شوند، کیفیت داده‌ها نیز ممکن است کاهش پیدا کند.

افراد ممکن است مشکلات را گزارش نکنند یا اطلاعات را به شکلی ثبت کنند که عملکرد آنها بهتر به نظر برسد.

Metric باید به تیم کمک کند بهتر بفهمد چه چیزی نیاز به بهبود دارد، نه اینکه صرفاً مشخص کند چه کسی مقصر است.

Dashboard کیفیت

برخی تیم‌ها برای مشاهده وضعیت Quality از Dashboard استفاده می‌کنند.

یک Dashboard مفید می‌تواند اطلاعاتی مانند موارد زیر را در یک نمای کلی نشان دهد:

• Open Critical Defects
• Defect Escape
• Test Execution
• Automation Stability
• Production Errors
• Performance Trends
• Incident Trends

هدف Dashboard نباید نمایش بیشترین تعداد عدد ممکن باشد؛ بلکه باید به تصمیم‌گیری کمک کند.

هیچ Metric واحدی نمی‌تواند Quality را توضیح دهد

Quality یک مفهوم چندبعدی است و به همین دلیل معمولاً به مجموعه‌ای از Signals نیاز دارد.

برای مثال یک Product ممکن است:

• Test Pass Rate بسیار بالا داشته باشد.
• Code Coverage بالایی داشته باشد.
• اما Customer Satisfaction پایینی داشته باشد.

یا برعکس، ممکن است تعداد Bugها نسبتاً زیاد باشد اما هیچ Bug مهمی وجود نداشته باشد و کاربران تجربه خوبی داشته باشند.

Quality Metrics باید با Context تفسیر شوند

هیچ عددی بدون Context معنای کاملی ندارد.

مثلاً افزایش Defectها ممکن است به دلیل افزایش تعداد Featureها، بزرگ‌تر شدن Product یا افزایش تعداد کاربران باشد.

بنابراین بهتر است به جای نگاه کردن به یک عدد منفرد، Trend، Context و ارتباط بین چند Metric را بررسی کنیم.

یک مجموعه متعادل از Metrics

یک رویکرد منطقی این است که Metrics از چند حوزه مختلف انتخاب شوند.

حوزه	نمونه Metric
Testing	Test Pass Rate، Test Execution
Defect	Defect Escape، Reopen Rate
Code	Code Coverage، Static Analysis
Production	Error Rate، Availability
Operations	MTTD، MTTR
Performance	Latency، Response Time، Throughput
User	Customer Feedback، Satisfaction

بهترین Metric، Metric قابل اقدام است

یک سؤال مهم هنگام انتخاب Metric این است:

«اگر این عدد تغییر کند، آیا می‌توانیم بر اساس آن تصمیم یا اقدام مشخصی انجام دهیم؟»

اگر پاسخ منفی باشد، احتمالاً آن Metric ارزش محدودی برای تیم دارد.

جمع‌بندی بخش بیست‌ویکم 🎯

• Quality Metrics برای شناخت وضعیت Product و Process استفاده می‌شوند.
• هر عددی لزوماً Metric مناسبی برای Quality نیست.
• Test Pass Rate و Code Coverage به‌تنهایی Quality را تضمین نمی‌کنند.
• Defect Escape می‌تواند اطلاعات مهمی درباره مشکلاتی که به Production رسیده‌اند ارائه کند.
• Risk Coverage در سیستم‌های Risk-Based می‌تواند بسیار ارزشمند باشد.
• MTTD و MTTR به تیم کمک می‌کنند سرعت Detection و Recovery را بررسی کند.
• Production Metrics مانند Error Rate و Availability نیز بخشی از تصویر Quality هستند.
• Customer Feedback می‌تواند جنبه‌ای از Quality را نشان دهد که Metrics فنی قادر به نمایش آن نیستند.
• استفاده نادرست از Metrics می‌تواند رفتارهای ناسالم ایجاد کند.
• Metrics بهتر است برای Learning و Decision Making استفاده شوند، نه تنبیه افراد.
• Quality یک مفهوم چندبعدی است و بهتر است با مجموعه‌ای از Signals و با درنظر گرفتن Context ارزیابی شود.

در بخش بعدی، وارد موضوع مهم Quality در پروژه‌های مدرن و معماری‌های پیچیده می‌شویم و بررسی می‌کنیم Microservices، Cloud، Distributed Systems و Third-Party Services چه تأثیری بر Quality و Testing دارند.

Quality در سیستم‌های مدرن؛ وقتی Software دیگر یک برنامه ساده نیست

در Softwareهای امروزی، معماری سیستم‌ها نسبت به گذشته پیچیده‌تر شده است. یک Application ممکن است دیگر یک برنامه واحد با یک Database ساده نباشد؛ بلکه مجموعه‌ای از سرویس‌ها، APIها، Cloud Infrastructure، Message Queueها، Third-Party Serviceها و Clientهای مختلف باشد.

هرچه Architecture پیچیده‌تر شود، تعریف و ارزیابی Quality نیز پیچیده‌تر می‌شود.

در چنین سیستم‌هایی، ممکن است هر Component به‌تنهایی درست کار کند، اما تعامل بین آنها باعث ایجاد مشکل شود.

از Monolith تا Distributed System

در یک Monolithic Application، بسیاری از اجزای سیستم در یک Application واحد قرار دارند.

اما در معماری‌های مدرن ممکن است یک درخواست کاربر از چندین Component عبور کند:

• Frontend
• API Gateway
• Authentication Service
• Order Service
• Payment Service
• Inventory Service
• Database
• Message Broker
• Notification Service

در این شرایط Quality دیگر فقط به عملکرد یک Application وابسته نیست.

Microservices و چالش Quality

Microservices می‌تواند مزایای زیادی داشته باشد، اما Testing و Quality را نیز پیچیده‌تر می‌کند.

برای مثال اگر Order Service برای تکمیل یک سفارش به Payment Service و Inventory Service وابسته باشد، Failure در یکی از آنها می‌تواند روی کل فرآیند تأثیر بگذارد.

در اینجا باید علاوه بر رفتار هر Service، رفتار تعامل بین Serviceها نیز بررسی شود.

Integration دیگر فقط یک مرحله ساده نیست

در سیستم‌های Distributed، Integration ممکن است شامل API، Event، Queue، Database و سرویس‌های خارجی باشد.

برای مثال:

• Order Service یک Event ایجاد می‌کند.
• Message Broker آن را منتقل می‌کند.
• Inventory Service Event را دریافت می‌کند.
• Payment Service وضعیت پرداخت را بررسی می‌کند.
• Notification Service پیام مناسب را ارسال می‌کند.

اگر یکی از این ارتباط‌ها درست کار نکند، ممکن است سیستم در وضعیت ناسازگار قرار بگیرد.

Distributed Systems و Failureهای جدید

در Distributed Systems، Failure فقط به معنای Crash کردن یک Application نیست.

• Network Partition
• Timeout
• Partial Failure
• Message Loss
• Duplicate Message
• Service Unavailability
• Latency Spike

همگی می‌توانند روی Quality سیستم تأثیر بگذارند.

Partial Failure

یکی از مفاهیم مهم در Distributed Systems، Partial Failure است.

ممکن است یک بخش سیستم سالم باشد اما بخش دیگری از دسترس خارج شود.

مثلاً Frontend و Order Service فعال باشند، اما Payment Service موقتاً در دسترس نباشد.

در این شرایط، رفتار سیستم اهمیت زیادی دارد:

• آیا سفارش ایجاد می‌شود؟
• آیا کاربر پیام مناسبی دریافت می‌کند؟
• آیا Retry انجام می‌شود؟
• آیا درخواست Duplicate می‌شود؟
• آیا وضعیت سیستم بعداً قابل بازیابی است؟

Retry همیشه راه‌حل نیست

ممکن است تصور کنیم اگر یک Request شکست خورد، کافی است آن را دوباره ارسال کنیم.

اما Retry نامناسب می‌تواند مشکل را شدیدتر کند.

برای مثال اگر Payment Request در سمت Server انجام شده باشد اما پاسخ آن به Client نرسد، ارسال مجدد همان Request ممکن است باعث ایجاد تراکنش Duplicate شود.

Idempotency و Quality

در چنین Scenarioهایی، Idempotency اهمیت زیادی پیدا می‌کند.

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

این موضوع به‌خصوص در Payment، Order Creation و عملیات حساس اهمیت دارد.

Event-Driven Architecture

در معماری‌های Event-Driven، سرویس‌ها ممکن است مستقیماً با یکدیگر ارتباط نداشته باشند و از طریق Event و Message Broker با هم تعامل کنند.

این معماری می‌تواند مقیاس‌پذیری و استقلال سرویس‌ها را افزایش دهد، اما Scenarioهای جدیدی برای Testing ایجاد می‌کند.

• Event به مقصد نمی‌رسد.
• Event دوبار مصرف می‌شود.
• Event با تأخیر دریافت می‌شود.
• Consumer از دسترس خارج است.
• ترتیب Eventها تغییر می‌کند.

Eventual Consistency

در برخی معماری‌های Distributed، اطلاعات همه Componentها لزوماً در یک لحظه یکسان نیستند.

ممکن است یک Event ایجاد شود و چند لحظه بعد Service دیگری اطلاعات مربوط به آن را دریافت کند.

بنابراین Tester باید بداند که «Consistency فوری» همیشه Requirement سیستم نیست.

Cloud و Quality

Cloud Infrastructure امکانات زیادی برای Scaling، Availability و Deployment فراهم می‌کند، اما Complexity جدیدی نیز ایجاد می‌کند.

• Auto Scaling
• Load Balancing
• Containerization
• Service Discovery
• Cloud Storage
• Managed Databases

هرکدام از این اجزا می‌توانند در رفتار نهایی سیستم نقش داشته باشند.

Container و Quality

Containerها به ایجاد Environmentهای قابل تکرار کمک می‌کنند، اما اختلاف بین Local، Test و Production همچنان ممکن است وجود داشته باشد.

بنابراین استفاده از Container به‌تنهایی تضمین‌کننده یکسان بودن تمام شرایط نیست.

Third-Party Services

بسیاری از Softwareهای مدرن به سرویس‌هایی خارج از کنترل مستقیم تیم وابسته‌اند.

• Payment Provider
• Email Service
• SMS Provider
• Identity Provider
• Maps API
• Analytics Platform

این Dependencyها می‌توانند Availability، Performance و حتی Business Flow را تحت تأثیر قرار دهند.

Contract Testing

وقتی Serviceها از طریق API با یکدیگر ارتباط دارند، تغییر در Contract می‌تواند باعث شکست سرویس‌های دیگر شود.

Contract Testing کمک می‌کند مشخص شود Provider و Consumer همچنان بر سر ساختار و رفتار مورد انتظار API توافق دارند.

این روش می‌تواند بخشی از Risk مربوط به تغییرات API را کاهش دهد.

Observability در سیستم‌های Distributed

وقتی یک Request از چندین Service عبور می‌کند، پیدا کردن Root Cause یک مشکل می‌تواند دشوار باشد.

در چنین شرایطی Logs، Metrics و Distributed Tracing اهمیت زیادی پیدا می‌کنند.

برای مثال اگر Response Time یک Checkout افزایش پیدا کند، Trace می‌تواند نشان دهد مشکل در کدام Service یا Dependency رخ داده است.

Quality فقط Functional Correctness نیست

در یک Distributed System ممکن است تمام Serviceها Functional Testهای خود را Pass کنند، اما سیستم از دید کاربر همچنان مشکل داشته باشد.

ممکن است مشکل در:

• Latency
• Availability
• Consistency
• Failure Handling
• Scalability
• Observability

باشد.

تست End-to-End در معماری‌های مدرن

End-to-End Testing می‌تواند برای بررسی جریان‌های حیاتی سیستم مفید باشد، اما در معماری‌های Distributed باید با دقت طراحی شود.

یک E2E Test ممکن است چندین Service را همزمان درگیر کند و به همین دلیل Failure آن همیشه به معنی Bug در همان Feature ظاهری نیست.

ممکن است مشکل از یک Dependency یا Infrastructure باشد.

آیا باید همه چیز را End-to-End تست کنیم؟

خیر.

تعداد زیاد E2E Test می‌تواند Suite را کند، شکننده و دشوار برای نگهداری کند.

بهتر است برای هر لایه از سیستم، سطح مناسب Testing انتخاب شود:

• Unit Testing برای Logicهای کوچک
• Integration Testing برای تعامل Componentها
• Contract Testing برای API Contract
• API Testing برای رفتار سرویس‌ها
• E2E Testing برای جریان‌های حیاتی Business

Quality در معماری پیچیده نیازمند نگاه سیستمی است

یکی از مهم‌ترین تغییرات در Testing مدرن این است که Tester فقط یک Feature یا یک Service را به‌صورت جداگانه نمی‌بیند.

باید بتواند درک کند که آن Component چگونه در کل سیستم قرار گرفته و Failure آن چه اثری روی Business Flow خواهد داشت.

مثال واقعی: خرید در فروشگاه اینترنتی

فرض کنید کاربر یک محصول را خریداری می‌کند.

جریان ممکن است به شکل زیر باشد:

• Frontend درخواست را ارسال می‌کند.
• Order Service سفارش را ایجاد می‌کند.
• Inventory Service موجودی را بررسی می‌کند.
• Payment Service پرداخت را انجام می‌دهد.
• Notification Service پیام تأیید را ارسال می‌کند.

حالا فرض کنید Payment موفق باشد اما Notification Service از دسترس خارج شود.

آیا سفارش باید شکست بخورد؟

پاسخ به این سؤال یک تصمیم Business و Architecture است، اما Tester باید بتواند این Scenario را شناسایی و رفتار سیستم را در برابر آن بررسی کند.

Complexity بیشتر، به معنای Test بیشتر نیست

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

گاهی باید به جای افزایش تعداد Testها، Strategy بهتری برای پوشش Riskها، Contractها، Failureها و تعامل Componentها ایجاد کنیم.

Quality Engineering در سیستم‌های مدرن

در رویکردهای مدرن، Quality به یک مرحله انتهایی محدود نمی‌شود. Quality Engineering تلاش می‌کند Quality را در کل Software Delivery Lifecycle وارد کند.

در این رویکرد، Testing، Automation، Observability، Performance، Security و Reliability می‌توانند در کنار Development و Delivery دیده شوند.

جمع‌بندی بخش بیست‌ودوم 🎯

• Architectureهای مدرن، مفهوم Quality را پیچیده‌تر کرده‌اند.
• در Microservices، کیفیت هر Service به‌تنهایی کافی نیست و تعامل بین Serviceها نیز اهمیت دارد.
• Distributed Systems با Failureهایی مانند Timeout، Partial Failure و Message Duplication روبه‌رو هستند.
• Retry نامناسب می‌تواند حتی مشکل جدید ایجاد کند.
• Idempotency برای عملیات حساس اهمیت زیادی دارد.
• Event-Driven Architecture Scenarioهای جدیدی برای Testing ایجاد می‌کند.
• Eventual Consistency باید به‌عنوان بخشی از رفتار مورد انتظار سیستم در نظر گرفته شود.
• Cloud و Third-Party Services نیز روی Quality تأثیر مستقیم دارند.
• Contract Testing می‌تواند Risk مربوط به تغییر APIها را کاهش دهد.
• Observability در پیدا کردن Root Cause مشکلات سیستم‌های Distributed اهمیت زیادی دارد.
• E2E Testing برای جریان‌های حیاتی مفید است، اما نباید جایگزین تمام سطوح دیگر Testing شود.
• در سیستم‌های مدرن، Tester باید علاوه بر Feature، رفتار کل سیستم و Business Flow را نیز درک کند.

در بخش بعدی، به یکی از مهم‌ترین موضوعات مقاله می‌رسیم: Quality در عصر AI و Automation و اینکه هوش مصنوعی چگونه می‌تواند فرآیندهای Testing و Quality را تغییر دهد.

Quality در عصر هوش مصنوعی؛ وقتی AI وارد چرخه Software Development می‌شود

هوش مصنوعی در سال‌های اخیر وارد بخش‌های مختلف Software Development شده است؛ از تولید و بررسی Code گرفته تا تحلیل Log، تولید Test Case، تشخیص Anomaly و کمک به تحلیل Bugها.

این تغییر یک سؤال مهم ایجاد می‌کند:

وقتی بخشی از Software با کمک AI ساخته می‌شود، Quality آن چگونه باید ارزیابی شود؟

پاسخ ساده‌ای وجود ندارد. AI می‌تواند سرعت بعضی فعالیت‌های Quality را افزایش دهد، اما خودش نیز Riskهای جدیدی ایجاد می‌کند.

AI جایگزین Quality Engineering نیست

یکی از برداشت‌های اشتباه این است که با استفاده از AI می‌توان بخش بزرگی از Testing را کاملاً حذف کرد.

در واقع AI بیشتر یک Capability جدید برای تیم است، نه جایگزینی کامل برای تحلیل، قضاوت و تصمیم‌گیری انسانی.

AI می‌تواند Test Case پیشنهاد دهد، اما هنوز باید بررسی کنیم آیا Testهای پیشنهادی واقعاً مهم‌ترین Riskهای Product را پوشش می‌دهند یا خیر.

AI در Test Case Generation

یکی از کاربردهای رایج AI در Testing، تولید Test Scenario و Test Case است.

برای مثال می‌توان Requirement یا User Story را در اختیار یک ابزار AI قرار داد و از آن خواست Scenarioهای مختلف را پیشنهاد کند.

• Happy Path
• Negative Scenario
• Boundary Condition
• Edge Case
• Validation Scenario
• Error Handling

این کار می‌تواند به Tester کمک کند سریع‌تر به مجموعه اولیه‌ای از Scenarioها برسد.

اما Test Case تولیدشده توسط AI الزاماً Test Case خوبی نیست

AI ممکن است Testهای زیادی تولید کند که از نظر ظاهری منطقی هستند اما ارزش واقعی کمی دارند.

برای مثال ممکن است ده‌ها Test برای Validationهای ساده تولید شود، در حالی که یک Business Rule حیاتی اصلاً پوشش داده نشده باشد.

بنابراین Test Design همچنان به درک Business و Risk نیاز دارد.

AI برای تحلیل Requirement

AI می‌تواند به پیدا کردن ابهام‌ها و تناقض‌های احتمالی در Requirement کمک کند.

برای مثال می‌توان از AI خواست موارد زیر را بررسی کند:

• Requirementهای مبهم
• Business Ruleهای ناقص
• حالت‌های تعریف‌نشده
• Conflict بین Requirementها
• Edge Caseهای احتمالی

این قابلیت می‌تواند باعث شود بخشی از مشکلات قبل از Development شناسایی شوند.

AI در Bug Analysis

یکی دیگر از کاربردهای مفید AI، کمک به تحلیل Bug Reportهاست.

AI می‌تواند بر اساس اطلاعات موجود:

• Bugهای مشابه را شناسایی کند.
• احتمالاً Componentهای مرتبط را پیشنهاد دهد.
• اطلاعات ناقص Bug Report را مشخص کند.
• Logs مرتبط را خلاصه کند.
• الگوهای تکرارشونده را پیدا کند.

اما این خروجی‌ها باید به‌عنوان پیشنهاد دیده شوند، نه حقیقت قطعی.

AI در Test Automation

AI می‌تواند در تولید یا اصلاح Automation Scriptها نیز استفاده شود.

برای مثال می‌تواند به تولید Code اولیه برای UI، API یا Unit Test کمک کند.

این موضوع سرعت ایجاد Test Automation را افزایش می‌دهد، اما کیفیت Automation همچنان به طراحی درست Test وابسته است.

AI-generated Code هم باید Test شود

اگر Developer یا Tester از AI برای تولید Code استفاده کند، این Code نباید صرفاً به دلیل تولید شدن توسط یک مدل هوش مصنوعی قابل اعتماد فرض شود.

AI می‌تواند Codeی تولید کند که:

• از نظر Syntax درست باشد.
• اما Business Logic اشتباه داشته باشد.
• Security Risk ایجاد کند.
• Edge Caseها را مدیریت نکند.
• Performance مناسبی نداشته باشد.
• با Architecture موجود سازگار نباشد.

در نتیجه AI-generated Code نیز باید مانند هر Code دیگری Review و Test شود.

Hallucination و Quality

یکی از محدودیت‌های مهم مدل‌های AI، تولید پاسخ‌هایی است که از نظر ظاهری منطقی هستند اما ممکن است نادرست باشند.

این مسئله در Testing اهمیت ویژه‌ای دارد؛ زیرا اگر Tester یک پیشنهاد نادرست را بدون Verification بپذیرد، ممکن است Test Strategy نیز تحت تأثیر قرار گیرد.

AI باید Verification شود

یک اصل ساده و مهم:

AI می‌تواند پیشنهاد بدهد؛ انسان باید تصمیم بگیرد.

هرچه تصمیم حساس‌تر باشد، نیاز به Verification نیز بیشتر است.

AI و Risk-Based Testing

AI می‌تواند در تحلیل حجم زیادی از اطلاعات به تیم کمک کند و الگوهایی را پیدا کند که بررسی دستی آنها دشوار است.

برای مثال می‌توان از داده‌های گذشته استفاده کرد تا مشخص شود کدام Componentها بیشتر دچار Defect شده‌اند یا کدام قسمت‌های Product بعد از Release Risk بیشتری داشته‌اند.

این اطلاعات می‌تواند در اولویت‌بندی Testing مورد استفاده قرار گیرد.

Predictive Quality

یکی از ایده‌های جذاب در AI، استفاده از داده‌های تاریخی برای پیش‌بینی Riskهای آینده است.

برای مثال مدل می‌تواند با بررسی History مربوط به Code Changes، Defects و Incidentها، بخش‌هایی را که احتمال بیشتری برای ایجاد مشکل دارند مشخص کند.

این رویکرد می‌تواند به تیم کمک کند منابع Testing را روی قسمت‌های پرریسک‌تر متمرکز کند.

Self-Healing Test Automation

در برخی ابزارهای مدرن، AI برای کاهش Maintenance مربوط به Automation Testها استفاده می‌شود.

برای مثال اگر یک UI Selector تغییر کند، سیستم می‌تواند تلاش کند Element جدید را بر اساس ویژگی‌های دیگر شناسایی کند.

این قابلیت می‌تواند Flaky Test یا Test Maintenance را کاهش دهد، اما نباید باعث شود Failureهای واقعی به‌صورت خودکار نادیده گرفته شوند.

Flaky Test و خطر AI

اگر AI تلاش کند هر Failure را به‌عنوان یک مشکل Automation تشخیص دهد و Test را به‌صورت خودکار اصلاح کند، ممکن است یک Bug واقعی را پنهان کند.

بنابراین Self-Healing باید با Guardrail و Verification مناسب استفاده شود.

AI Testing؛ تست کردن خود سیستم‌های هوش مصنوعی

موضوع فقط استفاده از AI برای Testing نیست.

اگر خود Software از AI یا Machine Learning استفاده کند، باید کیفیت رفتار AI نیز ارزیابی شود.

در اینجا معیارهای سنتی Software Testing ممکن است کافی نباشند.

چالش‌های Testing سیستم‌های AI

• خروجی همیشه کاملاً Deterministic نیست.
• ممکن است یک Input مشابه خروجی متفاوت ایجاد کند.
• Accuracy اهمیت پیدا می‌کند.
• Bias می‌تواند روی نتیجه اثر بگذارد.
• داده‌های آموزشی روی رفتار مدل تأثیر دارند.
• ممکن است Model در شرایط خاص Performance متفاوتی داشته باشد.

Quality در AI فقط Accuracy نیست

یک سیستم AI ممکن است Accuracy مناسبی داشته باشد اما همچنان از جنبه‌های دیگر Quality مشکل داشته باشد.

• Security
• Privacy
• Fairness
• Reliability
• Explainability
• Robustness

بنابراین ارزیابی Quality در AI نیز باید چندبعدی باشد.

Prompt Injection و Security Testing

سیستم‌های مبتنی بر LLM ممکن است در برابر ورودی‌هایی قرار بگیرند که تلاش می‌کنند رفتار مورد انتظار سیستم را تغییر دهند.

در چنین سیستم‌هایی، Security Testing باید علاوه بر Application Layer، رفتار Model و تعامل آن با User Input و ابزارهای متصل را نیز در نظر بگیرد.

Privacy و داده‌های حساس

استفاده از AI در Testing می‌تواند نیازمند ارسال Requirement، Log، Code یا Test Data به یک سرویس خارجی باشد.

بنابراین تیم باید قبل از استفاده از ابزار AI، سیاست‌های مربوط به Data Privacy، اطلاعات محرمانه و نحوه پردازش داده‌ها را بررسی کند.

AI باعث حذف Tester نمی‌شود؛ نقش Tester را تغییر می‌دهد

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

در نتیجه ارزش مهارت‌هایی مانند:

• Risk Analysis
• Critical Thinking
• Domain Knowledge
• Test Strategy
• Exploratory Testing
• Understanding Architecture
• تحلیل خروجی AI

بیشتر می‌شود.

Tester آینده باید AI را بشناسد

Tester مدرن لازم نیست الزاماً Machine Learning Engineer باشد، اما باید بداند AI چگونه می‌تواند در چرخه Testing استفاده شود و چه محدودیت‌هایی دارد.

توانایی استفاده درست از AI می‌تواند به یک مزیت حرفه‌ای مهم تبدیل شود.

AI را به‌عنوان یک Assistant ببینیم

یکی از منطقی‌ترین رویکردها این است که AI را به‌عنوان یک Assistant قدرتمند در نظر بگیریم.

AI می‌تواند:

• ایده بدهد.
• سناریو پیشنهاد کند.
• اطلاعات را خلاصه کند.
• الگو پیدا کند.
• Code اولیه تولید کند.
• تحلیل اولیه انجام دهد.

اما تصمیم نهایی درباره Risk و Quality همچنان نیازمند قضاوت انسانی است.

آینده Quality Engineering

احتمالاً آینده Quality Engineering ترکیبی از Human Expertise، Automation، AI، Observability و Continuous Feedback خواهد بود.

تیم‌های موفق الزاماً تیم‌هایی نیستند که بیشترین ابزار AI را دارند؛ بلکه تیم‌هایی هستند که می‌دانند کجا، چرا و چگونه از AI استفاده کنند.

جمع‌بندی بخش بیست‌وسوم 🤖

• AI می‌تواند بسیاری از فعالیت‌های Testing و Quality را سریع‌تر کند.
• AI جایگزین کامل Tester یا Quality Engineering نیست.
• Test Case Generation، Bug Analysis، Test Automation و Requirement Analysis از کاربردهای مهم AI هستند.
• AI-generated Code و Testها همچنان به Review و Verification نیاز دارند.
• Hallucination یکی از Riskهای مهم استفاده از AI است.
• AI می‌تواند در Risk-Based Testing و Predictive Quality کمک‌کننده باشد.
• Self-Healing Automation می‌تواند Maintenance را کاهش دهد، اما نباید Failureهای واقعی را پنهان کند.
• سیستم‌های AI خودشان نیز باید Test شوند.
• Quality در AI شامل Accuracy، Reliability، Security، Privacy، Fairness و Robustness نیز می‌شود.
• استفاده از AI در Testing باید با توجه به Data Privacy و اطلاعات محرمانه انجام شود.
• با افزایش AI، مهارت‌هایی مانند Critical Thinking، Risk Analysis و Domain Knowledge اهمیت بیشتری پیدا می‌کنند.
• Tester آینده احتمالاً بیشتر از گذشته نقش تحلیلگر، تصمیم‌گیرنده و Quality Engineer خواهد داشت.

در بخش بعدی، سراغ اشتباهات رایج درباره Quality و Testing می‌رویم؛ باورهایی که در تیم‌های Software زیاد دیده می‌شوند اما می‌توانند باعث تصمیم‌های اشتباه درباره کیفیت شوند.

اشتباهات و باورهای غلط درباره Software Quality

در طول سال‌ها، برداشت‌های مختلفی درباره Quality، Testing و نقش Tester شکل گرفته است. بعضی از این باورها در نگاه اول منطقی به نظر می‌رسند، اما در پروژه‌های واقعی می‌توانند باعث تصمیم‌های اشتباه شوند.

شناخت این اشتباهات اهمیت زیادی دارد، زیرا بسیاری از مشکلات Quality نه به دلیل کمبود ابزار، بلکه به دلیل نگرش نادرست نسبت به کیفیت ایجاد می‌شوند.

اشتباه اول: Quality یعنی نبود Bug

این یکی از رایج‌ترین برداشت‌های اشتباه است.

یک Software ممکن است Bugهای کمی داشته باشد اما همچنان برای کاربران نامناسب باشد؛ مثلاً استفاده از آن دشوار باشد، Performance ضعیفی داشته باشد یا Requirement اصلی Business را برآورده نکند.

بنابراین نبود Bug به‌تنهایی مساوی با Quality نیست.

اشتباه دوم: Testing مسئول Quality است

Tester نقش مهمی در Quality دارد، اما Quality مسئولیت یک فرد یا یک تیم نیست.

Developer، Product Manager، Designer، DevOps، Business و سایر اعضای تیم نیز در کیفیت نهایی Product نقش دارند.

Testing می‌تواند اطلاعاتی درباره Quality ارائه کند، اما نمی‌تواند به‌تنهایی Quality را بسازد.

اشتباه سوم: اگر همه Testها Pass شوند، Product باکیفیت است

Pass شدن Testها فقط نشان می‌دهد Testهای طراحی‌شده در شرایط مورد بررسی موفق بوده‌اند.

اما اگر Test Suite ناقص باشد، ممکن است بخش‌های مهمی از Product اصلاً بررسی نشده باشند.

اشتباه چهارم: هرچه Test بیشتر، Quality بالاتر

تعداد Testها معیار مستقیمی برای Quality نیست.

صد Test ضعیف ممکن است ارزش بسیار کمتری نسبت به ده Test خوب و Risk-Based داشته باشند.

هدف Testing باید پوشش مناسب Riskها باشد، نه تولید بیشترین تعداد Test ممکن.

اشتباه پنجم: Code Coverage بالا یعنی Quality بالا

Code Coverage نشان می‌دهد چه مقدار از Code هنگام اجرای Testها پوشش داده شده است، اما درباره کیفیت Assertions یا درست بودن Business Scenarioها اطلاعات کاملی نمی‌دهد.

بنابراین Coverage باید یک Signal باشد، نه هدف نهایی.

اشتباه ششم: Tester باید همه Bugها را پیدا کند

در Software پیچیده، پیدا کردن تمام Defectها عملاً غیرممکن است.

هدف حرفه‌ای Testing این نیست که ادعا کند هیچ Bugای وجود ندارد؛ بلکه هدف این است که با توجه به زمان و منابع موجود، مهم‌ترین Riskها شناسایی و مدیریت شوند.

اشتباه هفتم: Bugهای بیشتر یعنی Tester بهتر

تعداد Bugهای گزارش‌شده معیار مناسبی برای سنجش عملکرد Tester نیست.

یک Tester حرفه‌ای ممکن است تعداد کمتری Bug پیدا کند اما یک Defect بسیار مهم را قبل از Release شناسایی کند.

اشتباه هشتم: Quality فقط در پایان پروژه بررسی می‌شود

اگر Quality فقط در انتهای Development بررسی شود، بسیاری از مشکلات زمانی کشف می‌شوند که اصلاح آنها پرهزینه‌تر شده است.

رویکردهای مدرن تلاش می‌کنند Quality را از مراحل اولیه وارد چرخه Development کنند.

اشتباه نهم: Automation یعنی Quality بالاتر

Automation یک ابزار است، نه تضمین کیفیت.

اگر Test اشتباه باشد، Automation فقط همان Test اشتباه را سریع‌تر اجرا می‌کند.

اشتباه دهم: همه چیز باید Automation شود

همه Testها Candidate مناسبی برای Automation نیستند.

• Testهای تکراری و پایدار معمولاً Candidateهای خوبی هستند.
• Testهای بسیار Exploratory ممکن است نیاز بیشتری به قضاوت انسانی داشته باشند.
• Scenarioهای یک‌بار مصرف ممکن است ارزش Automation نداشته باشند.

هدف Automation باید ایجاد ارزش باشد، نه افزایش تعداد Scriptها.

اشتباه یازدهم: E2E بیشتر یعنی Coverage بیشتر

E2E Test می‌تواند جریان واقعی Business را بررسی کند، اما تعداد زیاد آن می‌تواند باعث افزایش زمان اجرا، Maintenance و Flakiness شود.

بهتر است E2E برای Flowهای مهم و حیاتی استفاده شود و سایر رفتارها در سطح مناسب‌تر تست شوند.

اشتباه دوازدهم: اگر Production مشکل ندارد، Quality عالی است

نبود Incident در یک بازه زمانی کوتاه الزاماً به معنی Quality بالا نیست.

ممکن است کاربران هنوز به بخش‌های مشکل‌دار دسترسی پیدا نکرده باشند یا Failure موردنظر هنوز رخ نداده باشد.

اشتباه سیزدهم: هر Bug باید قبل از Release رفع شود

در دنیای واقعی ممکن است Release با وجود برخی Bugهای شناخته‌شده انجام شود.

تصمیم Release باید بر اساس Severity، Business Impact، Risk و وجود Workaround گرفته شود.

یک Bug با Severity پایین ممکن است قابل پذیرش باشد، در حالی که یک Bug Critical می‌تواند Release را متوقف کند.

اشتباه چهاردهم: Quality را می‌توان با یک عدد سنجید

Quality چندبعدی است.

Test Pass Rate، Defect Count، Code Coverage یا Customer Satisfaction هرکدام تنها بخشی از تصویر را نشان می‌دهند.

ترکیب چند Signal و بررسی Trend آنها معمولاً تصویر قابل‌اعتمادتری ایجاد می‌کند.

اشتباه پانزدهم: Quality فقط وظیفه تیم فنی است

Business Requirement ضعیف می‌تواند باعث تولید Software ضعیف شود، حتی اگر Code و Testing از نظر فنی بسیار خوب باشند.

به همین دلیل Quality باید در همکاری بین Business، Product و Technical Team شکل بگیرد.

اشتباه شانزدهم: سریع‌تر Release کردن همیشه بهتر است

سرعت Delivery ارزشمند است، اما اگر سرعت باعث افزایش شدید Defect، Incident یا Technical Debt شود، ممکن است در بلندمدت هزینه بیشتری ایجاد کند.

هدف تیم باید پیدا کردن تعادل مناسب بین Speed، Quality و Risk باشد.

اشتباه هفدهم: اگر Requirement نوشته شده باشد، پس واضح است

وجود Requirement به معنی واضح بودن آن نیست.

Requirement ممکن است ناقص، مبهم یا دارای چند تفسیر باشد.

یکی از ارزش‌های Testing، مطرح کردن همین ابهام‌ها قبل از تبدیل آنها به Defect در Product است.

اشتباه هجدهم: Tester فقط باید طبق Requirement تست کند

اگر Tester فقط مواردی را بررسی کند که صراحتاً در Requirement نوشته شده‌اند، ممکن است بسیاری از Riskهای واقعی را نبیند.

Tester باید بتواند از Requirement فراتر برود و با استفاده از Domain Knowledge، تجربه و Exploratory Testing، رفتارهای غیرمنتظره را نیز بررسی کند.

اشتباه نوزدهم: Bug پیدا کردن یعنی شکست Developer

Bug بخشی طبیعی از فرآیند توسعه Software است.

هدف تیم Quality پیدا کردن مقصر نیست؛ هدف پیدا کردن و کاهش Riskهای Product است.

اگر رابطه Developer و Tester به رقابت تبدیل شود، احتمالاً اطلاعات مهم دیرتر به اشتراک گذاشته خواهند شد.

اشتباه بیستم: Quality با ابزار حل می‌شود

ابزارهای Testing، Automation، Monitoring و AI می‌توانند بسیار قدرتمند باشند، اما ابزار به‌تنهایی Strategy ایجاد نمی‌کند.

یک تیم با ابزارهای زیاد اما Process ضعیف ممکن است Quality پایین‌تری نسبت به تیمی با ابزار کمتر اما Strategy مناسب داشته باشد.

اشتباه بیست‌ویکم: AI همه چیز را حل می‌کند

AI می‌تواند Productivity را افزایش دهد، اما نمی‌تواند جایگزین کامل Domain Knowledge، Critical Thinking و Human Judgment شود.

خروجی AI نیز باید Verification شود.

اشتباه بیست‌ودوم: Quality یعنی رضایت تیم توسعه

ممکن است یک Team از نظر داخلی احساس کند Product آماده است، اما کاربران تجربه نامناسبی داشته باشند.

Quality باید از دید Stakeholderها و به‌خصوص User نیز بررسی شود.

اشتباه بیست‌وسوم: هر Failure یک Bug است

هر Failure الزاماً ناشی از Bug در Product نیست.

ممکن است مشکل از Network، Infrastructure، Configuration، Third-Party Service یا Test Environment باشد.

بنابراین Tester باید بتواند Failure را تحلیل کند و تا حد امکان Root Cause را از Symptom جدا کند.

اشتباه بیست‌وچهارم: Quality فقط مربوط به Functional Testing است

یک Software می‌تواند Functional باشد اما از نظر Performance، Security، Accessibility، Reliability یا Usability مشکل داشته باشد.

به همین دلیل Quality باید از چندین بُعد مختلف بررسی شود.

اشتباه بیست‌وپنجم: کیفیت بالا یعنی هیچ‌وقت Incident رخ نمی‌دهد

حتی سیستم‌های بسیار Mature نیز ممکن است با Incident مواجه شوند.

تفاوت اصلی در نحوه پیشگیری، Detection، Response، Recovery و Learning از Incident است.

از اشتباهات Quality چه چیزی یاد می‌گیریم؟

تمام این موارد به یک نکته مشترک برمی‌گردند:

Quality یک خروجی ساده از تعداد Testها، تعداد Bugها یا مقدار Automation نیست.

Quality نتیجه تعامل Requirement، Design، Development، Testing، Infrastructure، Process، Team، User و Business است.

به جای دنبال کردن عدد، به دنبال Signal باشیم

یکی از مهم‌ترین درس‌های Quality این است که نباید به یک Metric خاص وابسته شویم.

بهتر است چند Signal را در کنار هم بررسی کنیم و از خودمان بپرسیم:

• کدام Riskها هنوز باقی مانده‌اند؟
• چه نوع Defectهایی بیشتر تکرار می‌شوند؟
• کاربران با چه مشکلاتی مواجه هستند؟
• Production چه اطلاعاتی به ما می‌دهد؟
• کدام بخش‌های سیستم تغییرپذیرتر و پرریسک‌تر هستند؟
• کجا باید Process را بهبود دهیم؟

Quality Mindset

در نهایت Quality بیش از آنکه فقط مجموعه‌ای از ابزارها و تکنیک‌ها باشد، یک Mindset است.

این Mindset یعنی تیم همیشه درباره پیامد تغییرات، Riskها، تجربه کاربر و رفتار واقعی سیستم سؤال بپرسد.

تیمی که چنین نگرشی داشته باشد، حتی با تغییر ابزارها و تکنولوژی‌ها نیز می‌تواند اصول Quality را حفظ کند.

جمع‌بندی بخش بیست‌وچهارم 🎯

• Quality مساوی با نبود Bug نیست.
• Testing تنها مسئول Quality نیست.
• تعداد Testها یا Bugها معیار مناسبی برای سنجش کیفیت نیست.
• Code Coverage بالا به‌تنهایی Quality را تضمین نمی‌کند.
• Automation و AI ابزارهایی برای افزایش توانایی تیم هستند، نه تضمین Quality.
• همه Bugها الزاماً نباید قبل از Release رفع شوند؛ تصمیم باید بر اساس Risk و Business Impact باشد.
• Requirement نوشته‌شده الزاماً Requirement واضح و کامل نیست.
• Tester نباید فقط به Requirementهای موجود محدود شود.
• Bug نباید به ابزاری برای مقصر پیدا کردن تبدیل شود.
• Quality فقط Functional Correctness نیست.
• Production Incident می‌تواند حتی در سیستم‌های Mature نیز رخ دهد.
• Quality در نهایت یک مسئولیت تیمی و یک Mindset سازمانی است.

در بخش پایانی مقاله، تمام مفاهیم را کنار هم قرار می‌دهیم و یک Framework عملی برای نگاه کردن به Software Quality ارائه می‌کنیم؛ سپس مقاله را با چک‌لیست نهایی و جمع‌بندی کامل به پایان می‌رسانیم.

چگونه یک رویکرد جامع برای Software Quality داشته باشیم؟

در بخش‌های مختلف این مقاله دیدیم که Software Quality یک مفهوم چندبعدی است و نمی‌توان آن را با یک Test، یک ابزار، یک Metric یا حتی یک تیم مشخص تعریف کرد.

Quality از زمانی شکل می‌گیرد که یک نیاز یا ایده مطرح می‌شود و تا زمانی که Software در اختیار کاربر قرار می‌گیرد و حتی بعد از آن ادامه پیدا می‌کند.

Quality چیزی نیست که در انتهای Development به Software اضافه شود؛ Quality باید در تمام چرخه عمر Software ساخته و حفظ شود.

یک Framework ساده برای نگاه کردن به Quality

برای اینکه تمام مفاهیم مقاله را کنار هم قرار دهیم، می‌توان Software Quality را در چند سؤال اصلی بررسی کرد:

• آیا چیزی را درست ساخته‌ایم؟ — Functional Correctness
• آیا چیز درست را ساخته‌ایم؟ — Business و User Value
• آیا Software در شرایط واقعی قابل استفاده است؟ — Usability، Accessibility و Performance
• آیا Software قابل اعتماد و امن است؟ — Reliability و Security
• آیا می‌توانیم کیفیت را در طول زمان حفظ کنیم؟ — Maintainability و Engineering Practices
• آیا می‌توانیم مشکلات را سریع شناسایی و اصلاح کنیم؟ — Observability و Feedback

Quality از Requirement شروع می‌شود

یکی از مهم‌ترین نقاطی که می‌توان Quality را تحت تأثیر قرار داد، قبل از شروع Development است.

Requirementهای مبهم، ناقص یا متناقض می‌توانند باعث شوند تیم Softwareی بسازد که از نظر فنی درست است اما نیاز واقعی Business یا User را برآورده نمی‌کند.

• آیا Requirement واضح است؟
• آیا قابل Test است؟
• آیا Acceptance Criteria مشخص هستند؟
• آیا Edge Caseهای مهم مشخص شده‌اند؟
• آیا Riskهای مهم شناسایی شده‌اند؟

Quality در Design و Architecture

تصمیم‌های Architecture نیز تأثیر مستقیمی بر Quality دارند.

اگر Architecture نتواند نیازهای مربوط به Scalability، Security، Reliability یا Performance را پشتیبانی کند، Testing در مراحل بعدی نمی‌تواند تمام مشکلات بنیادی آن را برطرف کند.

به همین دلیل Quality باید از مرحله Design نیز مورد توجه قرار گیرد.

Quality در Development

Code Review، Static Analysis، Unit Testing، استانداردهای Coding و مدیریت مناسب Technical Debt همگی می‌توانند به جلوگیری از Defect کمک کنند.

هدف این نیست که تمام مسئولیت Quality بر عهده Developer قرار گیرد؛ بلکه باید Quality به بخشی از فرآیند Development تبدیل شود.

Quality در Testing

Testing یکی از مهم‌ترین منابع Feedback درباره رفتار Software است.

یک Strategy مناسب Testing باید بر اساس Risk، Business Impact، Architecture و نوع Product طراحی شود.

• Unit Testing
• Integration Testing
• API Testing
• UI Testing
• End-to-End Testing
• Performance Testing
• Security Testing
• Accessibility Testing
• Exploratory Testing

هیچ‌کدام به‌تنهایی کافی نیستند و سطح مناسب Testing باید با توجه به نیاز سیستم انتخاب شود.

Quality در CI/CD

در Software Delivery مدرن، Quality باید تا حد امکان در Pipeline نیز حضور داشته باشد.

برای مثال می‌توان Quality Gateهایی برای مواردی مانند Test Failure، Static Analysis، Security Check یا سایر معیارهای مهم تعریف کرد.

هدف Quality Gate جلوگیری از ورود تغییرات پرریسک به مراحل بعدی Delivery است.

Quality در Production

Release پایان Quality نیست.

در Production می‌توان اطلاعاتی به دست آورد که هیچ Test Environmentای نمی‌تواند به‌طور کامل شبیه‌سازی کند.

• Real User Behavior
• Production Errors
• Performance Trends
• Availability
• Incidentها
• Customer Feedback

این اطلاعات باید دوباره وارد چرخه Development و Testing شوند.

Quality یک Feedback Loop است

یکی از بهترین روش‌ها برای درک Quality این است که آن را یک چرخه Feedback در نظر بگیریم:

• Requirement
• Design
• Development
• Testing
• Release
• Production
• Monitoring
• Feedback
• Improvement

سپس این چرخه دوباره تکرار می‌شود.

Quality و Risk

یکی از مهم‌ترین اصولی که باید از این مقاله به خاطر داشته باشیم این است که Quality را باید در ارتباط با Risk بررسی کرد.

همه قسمت‌های Software ارزش یکسانی ندارند.

یک خطا در صفحه تنظیمات ظاهری ممکن است تأثیر کمی داشته باشد، اما یک خطا در Payment، Authentication یا Data Processing می‌تواند خسارت بسیار بزرگی ایجاد کند.

بنابراین منابع Quality باید متناسب با Riskها تخصیص داده شوند.

Quality و User

در نهایت Software برای User ساخته می‌شود.

اگر Software از نظر فنی سالم باشد اما User نتواند به‌راحتی از آن استفاده کند، Experience مناسبی نداشته باشد یا نیاز اصلی خود را برطرف نکند، نمی‌توان صرفاً بر اساس Technical Metrics گفت Product باکیفیت است.

Quality و Accessibility

Accessibility نیز بخشی از Quality است.

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

بنابراین Accessibility Testing نباید صرفاً یک موضوع جانبی در نظر گرفته شود.

Quality و Security

Softwareی که Functionهای مورد انتظار را انجام می‌دهد اما داده‌های کاربران را به‌درستی محافظت نمی‌کند، نمی‌تواند از دید کلی Software Quality محصولی باکیفیت محسوب شود.

Security باید متناسب با Risk و نوع سیستم از مراحل اولیه طراحی تا Production مورد توجه قرار گیرد.

Quality و Performance

کاربر انتظار ندارد فقط نتیجه درست باشد؛ انتظار دارد نتیجه را در زمان قابل قبول دریافت کند.

به همین دلیل Performance، Scalability و Resource Efficiency نیز می‌توانند بخشی از Quality باشند.

Quality و Maintainability

اگر تغییر یک Feature کوچک به دلیل Architecture نامناسب یا Technical Debt بالا بسیار دشوار باشد، Quality سیستم در بلندمدت تحت تأثیر قرار خواهد گرفت.

Maintainability کمک می‌کند تیم بتواند Software را در طول زمان با هزینه و Risk قابل قبول توسعه دهد.

Quality در تیم‌های Agile

در Agile، Quality نباید یک فعالیت جداگانه باشد که فقط در پایان Sprint انجام شود.

Quality باید در Planning، Refinement، Development، Review و Retrospective حضور داشته باشد.

Definition of Done و Quality

یک Definition of Done مناسب می‌تواند بخشی از Quality Expectations را مشخص کند.

• Acceptance Criteria بررسی شده‌اند.
• Testهای لازم اجرا شده‌اند.
• Defectهای Critical برطرف شده‌اند.
• Automation مناسب اجرا شده است.
• ملاحظات Security در صورت نیاز بررسی شده‌اند.
• Feature برای Release آماده است.

جزئیات Definition of Done باید متناسب با Product و فرآیند تیم باشد.

Quality و Continuous Improvement

هیچ Processای از ابتدا کامل نیست.

تیم باید به‌طور مداوم بررسی کند که چه مشکلاتی تکرار می‌شوند و چگونه می‌توان Process، Architecture، Testing یا Collaboration را بهبود داد.

Quality Checklist نهایی

قبل از Release یا در زمان ارزیابی Quality یک Product، می‌توان از این Checklist به‌عنوان یک نقطه شروع استفاده کرد:

• ☐ Requirementهای مهم واضح و قابل Test هستند.
• ☐ Acceptance Criteria بررسی شده‌اند.
• ☐ Riskهای مهم شناسایی شده‌اند.
• ☐ Testهای متناسب با Riskها طراحی شده‌اند.
• ☐ Functional Testing انجام شده است.
• ☐ Integrationهای مهم بررسی شده‌اند.
• ☐ APIهای مهم Test شده‌اند.
• ☐ جریان‌های حیاتی End-to-End بررسی شده‌اند.
• ☐ Performance متناسب با نیاز Product ارزیابی شده است.
• ☐ Security Riskهای مهم بررسی شده‌اند.
• ☐ Accessibility در صورت مرتبط بودن بررسی شده است.
• ☐ Defectهای Critical و High تعیین تکلیف شده‌اند.
• ☐ Automation Testهای مهم اجرا شده‌اند.
• ☐ Failureهای Test تحلیل شده‌اند.
• ☐ Production Monitoring و Observability مناسب وجود دارد.
• ☐ Rollback یا Recovery Strategy مشخص است.
• ☐ Customer Impact بررسی شده است.
• ☐ Metrics و Feedbackهای قبلی مورد توجه قرار گرفته‌اند.

اگر فقط ۱۰ نکته از این مقاله به خاطر بسپاریم

• Quality فقط نبود Bug نیست.
• Testing تنها مسئول Quality نیست.
• Quality باید از Requirement شروع شود.
• Risk باید تعیین کند کجا بیشتر تست کنیم.
• Test بیشتر الزاماً به معنی Quality بیشتر نیست.
• Automation کیفیت Test بد را بهتر نمی‌کند.
• Production بخشی از Feedback Loop کیفیت است.
• Metrics باید برای تصمیم‌گیری استفاده شوند، نه صرفاً گزارش‌دهی.
• AI می‌تواند توانایی تیم را افزایش دهد، اما جایگزین قضاوت انسانی نیست.
• Quality یک مسئولیت تیمی و یک Continuous Process است.

تفاوت نگاه سنتی و نگاه مدرن به Quality

نگاه سنتی	نگاه مدرن
Quality در پایان بررسی می‌شود.	Quality از ابتدای چرخه ایجاد می‌شود.
Tester مسئول Quality است.	Quality مسئولیت کل تیم است.
هدف پیدا کردن Bug است.	هدف کاهش و مدیریت Risk است.
تعداد Test معیار اصلی است.	ارزش و پوشش Risk مهم‌تر است.
Automation هدف است.	Automation ابزار ایجاد ارزش است.
Production پایان Testing است.	Production منبع Feedback است.
تمرکز روی Software است.	تمرکز روی Software، User و Business است.

در نهایت، Software Quality چیست؟

اگر بخواهیم تمام مقاله را در یک تعریف خلاصه کنیم:

Software Quality توانایی یک Software برای برآورده کردن نیازهای مورد انتظار کاربران و Business، همراه با رفتار قابل اعتماد، امن، قابل استفاده و قابل نگهداری در شرایط واقعی است.

اما مهم‌تر از خود تعریف، نحوه نگاه کردن به Quality است.

Quality نباید یک مرحله پایانی، یک Checklist ساده یا مسئولیت یک Tester تلقی شود. Quality باید در تصمیم‌های Product، Requirement، Design، Development، Testing، Deployment و Production حضور داشته باشد.

جمع‌بندی نهایی مقاله 🎯

Software Quality یک مفهوم گسترده و چندبعدی است. برای ایجاد Software باکیفیت، صرفاً داشتن Test Case، Automation، ابزارهای مدرن یا تعداد زیادی Tester کافی نیست.

تیم باید بداند چه چیزی را می‌سازد، چرا آن را می‌سازد، چه Riskهایی دارد، کاربران چگونه از آن استفاده می‌کنند و در شرایط واقعی چه اتفاقی ممکن است رخ دهد.

Testing در این میان نقش بسیار مهمی دارد، اما Testing تنها یکی از منابع ایجاد Feedback درباره Quality است.

در Softwareهای مدرن، Quality باید با مفاهیمی مانند Automation، Performance، Security، Accessibility، Reliability، Observability، CI/CD و AI نیز در ارتباط باشد.

در نهایت، بهترین تیم‌های Software الزاماً تیم‌هایی نیستند که هیچ Bugی ندارند؛ بلکه تیم‌هایی هستند که می‌توانند Risk را بشناسند، Feedback مناسب ایجاد کنند، مشکلات را سریع شناسایی کنند، از Failureها یاد بگیرند و به‌صورت مداوم Software و فرآیندهای خود را بهبود دهند.

این همان نقطه‌ای است که Software Testing از یک فعالیت صرفاً اجرایی فراتر می‌رود و به بخشی از Quality Engineering تبدیل می‌شود.

سخن پایانی

اگر بخواهیم یک اصل را به‌عنوان مهم‌ترین پیام این مقاله انتخاب کنیم، شاید این جمله بهترین جمع‌بندی باشد:

Quality را نمی‌توان در انتهای مسیر به Software اضافه کرد؛ باید از همان ابتدای مسیر آن را در Software و فرآیند توسعه آن بسازیم.

و این دقیقاً همان نگرشی است که Quality Engineering و Software Testing مدرن بر پایه آن شکل گرفته‌اند.

منابع و مراجع

برای مطالعه بیشتر و بررسی مفاهیم مطرح‌شده در این مقاله، می‌توانید از منابع معتبر زیر استفاده کنید:

• ISO/IEC 25010:2023 – Product Quality Model — استاندارد بین‌المللی برای مدل کیفیت محصولات Software و ICT و یکی از مهم‌ترین مراجع این مقاله.
• ISTQB® – International Software Testing Qualifications Board — منبع معتبر برای مفاهیم، اصطلاحات، استانداردها و دانش حرفه‌ای Software Testing.
• ISTQB® Glossary — مرجع رسمی اصطلاحات و تعاریف حوزه Software Testing.
• ISTQB® Testing Body of Knowledge (TBOK) — پایگاه دانش رسمی ISTQB برای مفاهیم و موضوعات مختلف Software Testing.
• OWASP Web Security Testing Guide (WSTG) — راهنمای جامع و معتبر برای Security Testing برنامه‌های Web و Web Services.
• W3C Web Content Accessibility Guidelines (WCAG) 2.2 — استاندارد اصلی برای Accessibility و طراحی محتوای قابل دسترس در Web.
• Google – Site Reliability Engineering — مجموعه منابع Google درباره Reliability، Monitoring، Incident Management و اجرای سیستم‌های قابل اعتماد در Production.
• NIST AI Risk Management Framework (AI RMF) — چارچوب NIST برای شناسایی و مدیریت Riskهای مرتبط با سیستم‌های هوش مصنوعی.
• NIST AI RMF 1.0 — مرجع رسمی برای مدیریت Risk و بررسی Trustworthiness در سیستم‌های AI.

منابع پیشنهادی برای مطالعه عمیق‌تر

• ISTQB® Certified Tester Scheme — برای مطالعه ساختار دانش حرفه‌ای Software Testing و مسیرهای تخصصی آن.
• OWASP Foundation — مجموعه گسترده‌ای از منابع مربوط به Application Security، Security Testing و Web Security.
• W3C Web Accessibility Initiative (WAI) — منابع آموزشی و استانداردهای مرتبط با Accessibility در Web.