🔵 عنوان مقاله
"Why didn't testing find this issue?" Because you desire something that doesn't exist!
🟢 خلاصه مقاله:
وقتی خطایی به تولید می‌رسد، پرسش تکراری این است: «چرا تست‌ها این مشکل را پیدا نکردند؟» Maaike Brinkhof می‌گوید ریشه‌ی این پرسش اشتباه است، چون چنین قطعیتی از تست انتظار داریم که اصلاً وجود ندارد. تست فقط می‌تواند اعتماد را افزایش دهد و ریسک‌ها را آشکار کند؛ هرگز نمی‌تواند نبودِ باگ را ثابت کند.
به‌جای سرزنش «تست»، بحث را به مسئولیت جمعی و یادگیری سیستمی تغییر دهیم: «چطور فرایند، فرض‌ها و طراحی ما اجازه‌ی فرار این باگ را داده‌اند؟» عوامل رایج شامل ابهام در نیازها، تفاوت محیط‌ها با تولید، داده‌ی ناکافی، مشاهده‌پذیری ضعیف، یا مصالحه‌های زمان‌بندی است. مجموعه تست‌ها فقط نمونه‌ای از واقعیت‌اند، نه تمام آن.
راه‌حل، مدیریت ریسک و بهبود چرخه‌های بازخورد است: تقویت logging و telemetry، استفاده از feature flag و انتشار تدریجی، بهبود تست‌های قرارداد و سفرهای حیاتی کاربر، و سرمایه‌گذاری روی تست اکتشافی برای کشف ناشناخته‌ها. با postmortem بدون سرزنش بپرسیم: ریسک را درست فهمیدیم؟ نظارت ما برای کشف سریع و محدودکردن دامنه مشکل کافی بود؟ داده و محیط مناسب داشتیم؟ آیا pairing، بازبینی یا risk storming می‌توانست زودتر هشدار بدهد؟
جمع‌بندی: تست تضمین نیست؛ ابزاری برای آشکارسازی و مدیریت ریسک است. به‌جای انتظار قطعیت، روی کشف سریع‌تر، عرضه‌های ایمن‌تر و تصمیم‌های هوشمندانه درباره محل سرمایه‌گذاری تمرکز کنیم.
#SoftwareTesting #QualityEngineering #BlamelessPostmortem #RiskBasedTesting #Testability #Observability #DevOps #Agile
🟣لینک مقاله:
https://cur.at/7DobXrn?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
"Why didn't testing find this issue?" Because you desire something that doesn't exist!
🟢 خلاصه مقاله:
وقتی خطایی به تولید می‌رسد، پرسش تکراری این است: «چرا تست‌ها این مشکل را پیدا نکردند؟» Maaike Brinkhof می‌گوید ریشه‌ی این پرسش اشتباه است، چون چنین قطعیتی از تست انتظار داریم که اصلاً وجود ندارد. تست فقط می‌تواند اعتماد را افزایش دهد و ریسک‌ها را آشکار کند؛ هرگز نمی‌تواند نبودِ باگ را ثابت کند.
به‌جای سرزنش «تست»، بحث را به مسئولیت جمعی و یادگیری سیستمی تغییر دهیم: «چطور فرایند، فرض‌ها و طراحی ما اجازه‌ی فرار این باگ را داده‌اند؟» عوامل رایج شامل ابهام در نیازها، تفاوت محیط‌ها با تولید، داده‌ی ناکافی، مشاهده‌پذیری ضعیف، یا مصالحه‌های زمان‌بندی است. مجموعه تست‌ها فقط نمونه‌ای از واقعیت‌اند، نه تمام آن.
راه‌حل، مدیریت ریسک و بهبود چرخه‌های بازخورد است: تقویت logging و telemetry، استفاده از feature flag و انتشار تدریجی، بهبود تست‌های قرارداد و سفرهای حیاتی کاربر، و سرمایه‌گذاری روی تست اکتشافی برای کشف ناشناخته‌ها. با postmortem بدون سرزنش بپرسیم: ریسک را درست فهمیدیم؟ نظارت ما برای کشف سریع و محدودکردن دامنه مشکل کافی بود؟ داده و محیط مناسب داشتیم؟ آیا pairing، بازبینی یا risk storming می‌توانست زودتر هشدار بدهد؟
جمع‌بندی: تست تضمین نیست؛ ابزاری برای آشکارسازی و مدیریت ریسک است. به‌جای انتظار قطعیت، روی کشف سریع‌تر، عرضه‌های ایمن‌تر و تصمیم‌های هوشمندانه درباره محل سرمایه‌گذاری تمرکز کنیم.
#SoftwareTesting #QualityEngineering #BlamelessPostmortem #RiskBasedTesting #Testability #Observability #DevOps #Agile
🟣لینک مقاله:
https://cur.at/7DobXrn?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Maaike Brinkhof's blog
"Why didn't testing find this issue?" Because you desire something that doesn't exist!
After 15 years in software testing, this is still a topic I'm dealing with way too often: people who have a completely misguided understanding of what testing can and cannot do.
In the year 2025, too many people think testing is:
* a phase, not a continuous…
In the year 2025, too many people think testing is:
* a phase, not a continuous…
🔵 عنوان مقاله
It's Not Your Tests, It's Your Testability
🟢 خلاصه مقاله:
**
بی‌ثباتی تست‌ها همیشه تقصیر تست‌ها نیست؛ اغلب ریشه در سیستم کم‌تست‌پذیر دارد. وقتی زمان، هم‌روندی، تصادفی‌بودن یا وابستگی‌های بیرونی کنترل‌نشده باشند، تست‌ها ناپایدار می‌شوند. راه‌حل، ارتقای تست‌پذیری است: قابل‌کنترل و قابل‌مشاهده کردن سیستم، تزریق زمان و بذر تصادفی، جداسازی مرزهای شبکه با قراردادها و فیک‌ها، و هرمتیک‌کردن محیط تست. Gil Zilberfeld توصیه می‌کند برای جلب حمایت، هزینه فلیکینس را با داده نشان دهید و از بردهای کوچک (مثل افزودن seam، تزریق وابستگی برای زمان/I-O، و تست‌های قراردادی) شروع کنید. با گنجاندن تست‌پذیری در تصمیم‌های معماری و معیارهای پذیرش، تیم از آتش‌نشانی تست‌های flaky به ساخت نرم‌افزار ذاتاً تست‌پذیر و قابل‌اتکا منتقل می‌شود.
#Testability #FlakyTests #SoftwareTesting #QualityEngineering #DevOps #ContinuousIntegration #TestDesign #Observability
🟣لینک مقاله:
https://cur.at/3RbJDxt?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
It's Not Your Tests, It's Your Testability
🟢 خلاصه مقاله:
**
بی‌ثباتی تست‌ها همیشه تقصیر تست‌ها نیست؛ اغلب ریشه در سیستم کم‌تست‌پذیر دارد. وقتی زمان، هم‌روندی، تصادفی‌بودن یا وابستگی‌های بیرونی کنترل‌نشده باشند، تست‌ها ناپایدار می‌شوند. راه‌حل، ارتقای تست‌پذیری است: قابل‌کنترل و قابل‌مشاهده کردن سیستم، تزریق زمان و بذر تصادفی، جداسازی مرزهای شبکه با قراردادها و فیک‌ها، و هرمتیک‌کردن محیط تست. Gil Zilberfeld توصیه می‌کند برای جلب حمایت، هزینه فلیکینس را با داده نشان دهید و از بردهای کوچک (مثل افزودن seam، تزریق وابستگی برای زمان/I-O، و تست‌های قراردادی) شروع کنید. با گنجاندن تست‌پذیری در تصمیم‌های معماری و معیارهای پذیرش، تیم از آتش‌نشانی تست‌های flaky به ساخت نرم‌افزار ذاتاً تست‌پذیر و قابل‌اتکا منتقل می‌شود.
#Testability #FlakyTests #SoftwareTesting #QualityEngineering #DevOps #ContinuousIntegration #TestDesign #Observability
🟣لینک مقاله:
https://cur.at/3RbJDxt?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
TestinGil | By Gil Zilberfeld
It’s Not Your Tests, It’s Your Testability | TestinGil
Let's talk about that test. The one that's always flaky. The one that takes twenty minutes to run and fails for a different reason every time. Your first instinct is to blame the test. Maybe the locator is wrong, maybe the wait time isn't long enough. But…