Software Engineer Labdon
586 subscribers
42 photos
3 videos
2 files
717 links
👑 Software Labdon

حمایت مالی:
https://www.coffeete.ir/mrbardia72

ادمین:
@mrbardia72
Download Telegram
🔵 عنوان مقاله
I think, therefore I test: the importance of thinking for testers

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

#SoftwareTesting #QualityAssurance #TestMindset #CriticalThinking #ExploratoryTesting #RiskBasedTesting #SystemsThinking

🟣لینک مقاله:
https://cur.at/5QQO8RK?m=web


👑 @software_Labdon
🔵 عنوان مقاله
Beyond the Test Pyramid: Building New Monuments for Testing

🟢 خلاصه مقاله:
خوانش تازه‌ای از مدل کلاسیک test pyramid ارائه می‌شود: Juan Rada می‌گوید تکیه افراطی بر لایه‌های پایین (مثل unit tests) همیشه به‌صرفه نیست، چون در سیستم‌های توزیع‌شده نیاز به mocking زیاد، شکنندگی و هزینه نگه‌داری بالا ایجاد می‌کند و اعتماد کاذب می‌دهد. او پیشنهاد می‌کند به‌جای قالب ثابت، پرتفوی آزمون بر اساس ریسک و زمینه تیم چیده شود: تمرکز بیشتر بر integration tests معنادار، چند E2E هدفمند و سریع، و contract testing برای محافظت از مرز سرویس‌ها. این رویکرد با observability، tracing، health checks، و به‌کارگیری feature flags و canary releases برای اعتبارسنجی امن در محیط واقعی تکمیل می‌شود. هدف کنار گذاشتن unit tests نیست، بلکه اندازه‌کردن درست آن‌ها و ساختن «monuments» متناسب با معماری و اهداف است تا تعادل بهینه‌ای میان هزینه، سرعت و ریسک ایجاد شود.

#Testing #TestPyramid #SoftwareQuality #RiskBasedTesting #IntegrationTesting #E2E #QualityEngineering

🟣لینک مقاله:
https://cur.at/3i5XRwi?m=web


👑 @software_Labdon
🔵 عنوان مقاله
The Testing Skyscraper: A Modern Alternative to the Testing Pyramid

🟢 خلاصه مقاله:
Andrew Knight مدل سنتی Testing Pyramid را ناکافی می‌داند و به‌جای آن رویکرد منعطف‌تری به نام Testing Skyscraper پیشنهاد می‌کند. در این مدل، به‌جای نسبت‌های ثابت بین لایه‌های تست، «طبقات» متناسب با ریسک‌ها و نیازهای سیستم شکل می‌گیرند؛ مثلا ممکن است یک سیستم به طبقه پررنگ‌تری از contract testing، یا عملکرد و تاب‌آوری، یا سناریوهای end-to-end نیاز داشته باشد. این رویکرد بر تناسب پوشش با معماری و اهداف محصول، بازخورد سریع، و ارزش‌سنجی بر اساس کاهش ریسک و افزایش اطمینان تأکید دارد، نه شمارش تست‌ها. در عمل، ترکیبی از unit، integration، contract، end-to-end، تست‌های غیرعملکردی (کارایی، امنیت، دسترس‌پذیری)، و حتی observability و synthetic monitoring به‌عنوان طبقات مستقل در نظر گرفته می‌شوند و با تغییر سیستم، به‌صورت پویا تقویت، بازچینی یا حذف می‌گردند.

#SoftwareTesting #TestingPyramid #TestingSkyscraper #QualityEngineering #DevOps #Automation #RiskBasedTesting #TestStrategy

🟣لینک مقاله:
https://cur.at/W2rklZc?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