🔵 عنوان مقاله
"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…
🔵 عنوان مقاله
Mastering Pytest: The Complete Guide to Modern Python Testing
🟢 خلاصه مقاله:
این مقاله با عنوان Mastering Pytest: The Complete Guide to Modern Python Testing مروری جامع و عملی بر Pytest برای توسعه‌دهندگان Python ارائه می‌دهد. نویسنده، Sharath Chandran، از راه‌اندازی و ساختار پروژه تا امکانات کلیدی مانند fixtures، parametrization، markers و assertهای خوانا را پوشش می‌دهد و سپس به مباحث پیشرفته‌ای مثل افزونه‌های pytest-cov و pytest-xdist، استفاده از Hypothesis برای property-based testing، mocking با unittest.mock یا pytest-mock، تست‌های async و ابزارهایی مانند tmp_path و monkeypatch می‌پردازد. همچنین ادغام تست‌ها با CI/CD (مانند GitHub Actions و GitLab CI و Jenkins)، تولید گزارش‌ها و اعمال آستانه‌های coverage و نکات بهترین‌روش‌ها برای ساخت تست‌های سریع، پایدار و قابل‌نگهداری توضیح داده می‌شود. نتیجه اینکه چه برای شروع با Pytest و چه برای ارتقای مهارت‌ها، این راهنما الگوها و نکات کاربردی لازم برای مدرن‌سازی فرآیند تست در Python را فراهم می‌کند.
#Pytest #Python #Testing #TestAutomation #SoftwareTesting #TDD #CICD
🟣لینک مقاله:
https://cur.at/5l6Ats4?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Mastering Pytest: The Complete Guide to Modern Python Testing
🟢 خلاصه مقاله:
این مقاله با عنوان Mastering Pytest: The Complete Guide to Modern Python Testing مروری جامع و عملی بر Pytest برای توسعه‌دهندگان Python ارائه می‌دهد. نویسنده، Sharath Chandran، از راه‌اندازی و ساختار پروژه تا امکانات کلیدی مانند fixtures، parametrization، markers و assertهای خوانا را پوشش می‌دهد و سپس به مباحث پیشرفته‌ای مثل افزونه‌های pytest-cov و pytest-xdist، استفاده از Hypothesis برای property-based testing، mocking با unittest.mock یا pytest-mock، تست‌های async و ابزارهایی مانند tmp_path و monkeypatch می‌پردازد. همچنین ادغام تست‌ها با CI/CD (مانند GitHub Actions و GitLab CI و Jenkins)، تولید گزارش‌ها و اعمال آستانه‌های coverage و نکات بهترین‌روش‌ها برای ساخت تست‌های سریع، پایدار و قابل‌نگهداری توضیح داده می‌شود. نتیجه اینکه چه برای شروع با Pytest و چه برای ارتقای مهارت‌ها، این راهنما الگوها و نکات کاربردی لازم برای مدرن‌سازی فرآیند تست در Python را فراهم می‌کند.
#Pytest #Python #Testing #TestAutomation #SoftwareTesting #TDD #CICD
🟣لینک مقاله:
https://cur.at/5l6Ats4?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
Mastering Pytest: The Complete Guide to Modern Python Testing
Why Your Python Projects Need Pytest (And How to Use It Like a Pro)
🔵 عنوان مقاله
API Testing vs Browser Automation
🟢 خلاصه مقاله:
دغدغه انتخاب بین API Testing و Browser Automation در وب‌اپ‌ها با یک رویکرد ترکیبی حل می‌شود: بیشترین پوشش را با تست‌های سریع و پایدار API بگیرید و تعداد کمی سناریوی UI انتها‌به‌انتها را برای مسیرهای واقعاً حیاتی نگه دارید. API Testing برای قوانین کسب‌وکار، اعتبارسنجی داده، احراز هویت/مجوزها و Contract Tests سریع و قابل اتکاست؛ در مقابل، UI فقط برای چیزی که صرفاً UI می‌تواند ثابت کند ارزش دارد: تجربه کاربر، رندر، مسیرها و رفتار واقعی مرورگر. برای کاهش شکنندگی، داده‌سازی/پاک‌سازی را از طریق API انجام دهید، سرویس‌های ثالث را Stub/Mock کنید، بین سرویس‌ها Contract Tests داشته باشید و لایه UI را کوچک اما پرارزش حفظ کنید. معیار تصمیم‌گیری ساده است: اگر پرسش درباره درست‌بودن منطق است، API؛ اگر درباره تکمیل‌شدن سفر واقعی کاربر است، UI. با رصد زمان اجرا و نرخ فِلِیک در CI، مجموعه تست را پیوسته بهینه کنید تا هم بازخورد سریع بماند و هم اطمینان عملی بالا برود.
#APITesting #BrowserAutomation #TestAutomation #EndToEndTesting #TestingPyramid #QA #CICD #SoftwareTesting
🟣لینک مقاله:
https://cur.at/Efk7ahy?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
API Testing vs Browser Automation
🟢 خلاصه مقاله:
دغدغه انتخاب بین API Testing و Browser Automation در وب‌اپ‌ها با یک رویکرد ترکیبی حل می‌شود: بیشترین پوشش را با تست‌های سریع و پایدار API بگیرید و تعداد کمی سناریوی UI انتها‌به‌انتها را برای مسیرهای واقعاً حیاتی نگه دارید. API Testing برای قوانین کسب‌وکار، اعتبارسنجی داده، احراز هویت/مجوزها و Contract Tests سریع و قابل اتکاست؛ در مقابل، UI فقط برای چیزی که صرفاً UI می‌تواند ثابت کند ارزش دارد: تجربه کاربر، رندر، مسیرها و رفتار واقعی مرورگر. برای کاهش شکنندگی، داده‌سازی/پاک‌سازی را از طریق API انجام دهید، سرویس‌های ثالث را Stub/Mock کنید، بین سرویس‌ها Contract Tests داشته باشید و لایه UI را کوچک اما پرارزش حفظ کنید. معیار تصمیم‌گیری ساده است: اگر پرسش درباره درست‌بودن منطق است، API؛ اگر درباره تکمیل‌شدن سفر واقعی کاربر است، UI. با رصد زمان اجرا و نرخ فِلِیک در CI، مجموعه تست را پیوسته بهینه کنید تا هم بازخورد سریع بماند و هم اطمینان عملی بالا برود.
#APITesting #BrowserAutomation #TestAutomation #EndToEndTesting #TestingPyramid #QA #CICD #SoftwareTesting
🟣لینک مقاله:
https://cur.at/Efk7ahy?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Reddit
From the QualityAssurance community on Reddit
Explore this post and more from the QualityAssurance community
👍1
🔵 عنوان مقاله
How We Utilize AI Agents in Our Testing and Quality Processes
🟢 خلاصه مقاله:
این مقاله با روایت Utku Kılınçcı چهار کاربرد عملی از به‌کارگیری AI agents در تست و تضمین کیفیت را توضیح می‌دهد: ۱) تبدیل نیازمندی‌ها به تست‌های قابل اجرا و به‌روزرسانی مداوم سبد تست با تغییرات مشخصات، ۲) نقش همکار اکتشافی برای کشف سناریوهای مرزی، ثبت شواهد و بازتولید مشکل، ۳) تحلیل و اولویت‌بندی باگ‌ها از طریق خلاصه‌سازی لاگ‌ها، خوشه‌بندی خطاها و ارائه سرنخ‌های ریشه‌یابی، و ۴) بهبود پایداری رگرسیون و درگاه‌های کیفی CI با شناسایی تست‌های flaky، پیشنهاد خوددرمانی و بهینه‌سازی پایپ‌لاین. در همه موارد، نظارت انسانی، رعایت حریم داده و سنجش نتایج (پوشش، MTTR، روند flakiness و زمان چرخه) ضروری است. نتیجه: پذیرش تدریجی AI agents روی مسائل واقعی، سرعت، پایداری و پوشش تست را به‌طور ملموس افزایش می‌دهد بی‌آنکه مالکیت کیفیت را تضعیف کند.
#SoftwareTesting #AIagents #QualityAssurance #TestAutomation #BugTriage #ContinuousIntegration #SoftwareQuality #DevOps
🟣لینک مقاله:
https://cur.at/qRpZzn9?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
How We Utilize AI Agents in Our Testing and Quality Processes
🟢 خلاصه مقاله:
این مقاله با روایت Utku Kılınçcı چهار کاربرد عملی از به‌کارگیری AI agents در تست و تضمین کیفیت را توضیح می‌دهد: ۱) تبدیل نیازمندی‌ها به تست‌های قابل اجرا و به‌روزرسانی مداوم سبد تست با تغییرات مشخصات، ۲) نقش همکار اکتشافی برای کشف سناریوهای مرزی، ثبت شواهد و بازتولید مشکل، ۳) تحلیل و اولویت‌بندی باگ‌ها از طریق خلاصه‌سازی لاگ‌ها، خوشه‌بندی خطاها و ارائه سرنخ‌های ریشه‌یابی، و ۴) بهبود پایداری رگرسیون و درگاه‌های کیفی CI با شناسایی تست‌های flaky، پیشنهاد خوددرمانی و بهینه‌سازی پایپ‌لاین. در همه موارد، نظارت انسانی، رعایت حریم داده و سنجش نتایج (پوشش، MTTR، روند flakiness و زمان چرخه) ضروری است. نتیجه: پذیرش تدریجی AI agents روی مسائل واقعی، سرعت، پایداری و پوشش تست را به‌طور ملموس افزایش می‌دهد بی‌آنکه مالکیت کیفیت را تضعیف کند.
#SoftwareTesting #AIagents #QualityAssurance #TestAutomation #BugTriage #ContinuousIntegration #SoftwareQuality #DevOps
🟣لینک مقاله:
https://cur.at/qRpZzn9?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
How We Utilize AI Agents in Our Testing and Quality Processes
Hello everyone. In this article, We will try to explain how we utilize AI tools in our team at Trendyol. The purpose of this article is to…
🔵 عنوان مقاله
Writing custom Cypress plug-ins that solve common software testing problems
🟢 خلاصه مقاله:
اکوسیستم افزونه‌های Cypress به تیم‌ها اجازه می‌دهد فراتر از امکانات پیش‌فرض، چالش‌های واقعی تست را حل کنند؛ از کاهش ناپایداری تست‌ها و مدیریت محیط و داده تا یکپارچه‌سازی گزارش‌ها و سرویس‌های بیرونی. Kanika Vatsyayan توضیح می‌دهد چگونه با شناسایی یک مسئله تکراری، طراحی یک API ساده، ساخت پکیج npm، ثبت tasks در Node hook، افزودن تنظیمات و مثال‌های عملی، و همچنین تست و TypeScript typings، یک افزونه قابل اتکا بسازید. او بر نسخه‌بندی شفاف، سازگاری با نسخه‌های مختلف Cypress، کارایی، امنیت داده‌ها، مستندسازی و انتشار در npm تاکید می‌کند تا افزونه‌ها قابل نگهداری و قابل استفاده توسط جامعه باشند. نتیجه این است که با چند الگوی ساده و نمونه‌های واقعی، هر کسی می‌تواند راه‌حل‌های خود را به‌صورت افزونه منتشر کرده و به اکوسیستم تست کمک کند.
#Cypress
#SoftwareTesting
#QA
#JavaScript
#Plugins
#Automation
#OpenSource
#EndToEndTesting
🟣لینک مقاله:
https://cur.at/pj9uiDZ?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Writing custom Cypress plug-ins that solve common software testing problems
🟢 خلاصه مقاله:
اکوسیستم افزونه‌های Cypress به تیم‌ها اجازه می‌دهد فراتر از امکانات پیش‌فرض، چالش‌های واقعی تست را حل کنند؛ از کاهش ناپایداری تست‌ها و مدیریت محیط و داده تا یکپارچه‌سازی گزارش‌ها و سرویس‌های بیرونی. Kanika Vatsyayan توضیح می‌دهد چگونه با شناسایی یک مسئله تکراری، طراحی یک API ساده، ساخت پکیج npm، ثبت tasks در Node hook، افزودن تنظیمات و مثال‌های عملی، و همچنین تست و TypeScript typings، یک افزونه قابل اتکا بسازید. او بر نسخه‌بندی شفاف، سازگاری با نسخه‌های مختلف Cypress، کارایی، امنیت داده‌ها، مستندسازی و انتشار در npm تاکید می‌کند تا افزونه‌ها قابل نگهداری و قابل استفاده توسط جامعه باشند. نتیجه این است که با چند الگوی ساده و نمونه‌های واقعی، هر کسی می‌تواند راه‌حل‌های خود را به‌صورت افزونه منتشر کرده و به اکوسیستم تست کمک کند.
#Cypress
#SoftwareTesting
#QA
#JavaScript
#Plugins
#Automation
#OpenSource
#EndToEndTesting
🟣لینک مقاله:
https://cur.at/pj9uiDZ?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Ministry of Testing
Writing custom Cypress plug-ins that solve common software testing problems
Turn flaky test frustrations into reliable, reusable Cypress plug-ins that strengthen your test automation and contribute towards the quality community
🔵 عنوان مقاله
From Templates to Heuristics: Enhancing Thought Work
🟢 خلاصه مقاله:
تست مؤثر بیش از آن‌که به پر کردن قالب‌ها و چک‌لیست‌ها تکیه کند، به فهم عمیق و تأمل وابسته است. Maria Kedemo تأکید می‌کند که به‌جای تمرکز بر فرم‌ها، باید با نگاه انتقادی و زمینه‌محور به ریسک و ارزش فکر کنیم. در این رویکرد، هیوریستیک‌ها (heuristics) به‌عنوان راهنماهای منعطف و خطاپذیر به ما کمک می‌کنند پرسش‌های بهتری بپرسیم، فرضیات پنهان را آشکار کنیم و بر اساس چرخه‌های مشاهده، فرضیه‌سازی، آزمون و یادگیری مسیر را تنظیم کنیم. سازمان‌ها باید زمان و سازوکارهایی برای بازاندیشی (مثل دی‌بریف و بازبینی همتا) فراهم کنند و موفقیت را با کیفیت اطلاعات ریسکی و یادگیری حاصل بسنجند، نه با تعداد موارد آزمون یا فرم‌های تکمیل‌شده. قالب‌ها می‌توانند نقش داربست داشته باشند، اما مقصد نیستند؛ مقصد، اندیشیدن بهتر و تصمیم‌های سازگار با زمینه است.
#SoftwareTesting #Heuristics #ExploratoryTesting #QualityEngineering #TestingStrategy #CriticalThinking #ContextDrivenTesting
🟣لینک مقاله:
https://cur.at/Q0yh9ik?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
From Templates to Heuristics: Enhancing Thought Work
🟢 خلاصه مقاله:
تست مؤثر بیش از آن‌که به پر کردن قالب‌ها و چک‌لیست‌ها تکیه کند، به فهم عمیق و تأمل وابسته است. Maria Kedemo تأکید می‌کند که به‌جای تمرکز بر فرم‌ها، باید با نگاه انتقادی و زمینه‌محور به ریسک و ارزش فکر کنیم. در این رویکرد، هیوریستیک‌ها (heuristics) به‌عنوان راهنماهای منعطف و خطاپذیر به ما کمک می‌کنند پرسش‌های بهتری بپرسیم، فرضیات پنهان را آشکار کنیم و بر اساس چرخه‌های مشاهده، فرضیه‌سازی، آزمون و یادگیری مسیر را تنظیم کنیم. سازمان‌ها باید زمان و سازوکارهایی برای بازاندیشی (مثل دی‌بریف و بازبینی همتا) فراهم کنند و موفقیت را با کیفیت اطلاعات ریسکی و یادگیری حاصل بسنجند، نه با تعداد موارد آزمون یا فرم‌های تکمیل‌شده. قالب‌ها می‌توانند نقش داربست داشته باشند، اما مقصد نیستند؛ مقصد، اندیشیدن بهتر و تصمیم‌های سازگار با زمینه است.
#SoftwareTesting #Heuristics #ExploratoryTesting #QualityEngineering #TestingStrategy #CriticalThinking #ContextDrivenTesting
🟣لینک مقاله:
https://cur.at/Q0yh9ik?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Curiousity killed the cat
From Templates to Heuristics: Enhancing Thought Work
Update 2025-10-14: This post has been updated to reflect thought work rather than knowledge work – which was pointed out by Fiona Charles as a much better description of the cognitive work pe…
🔵 عنوان مقاله
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…
🔵 عنوان مقاله
QA Engineer Role Transformation in the Age of AI
🟢 خلاصه مقاله:
** در عصر AI نقش مهندسان QA از اجرای دستی آزمون‌ها به طراحی و هدایت جریان‌های تضمین کیفیت هوشمند تغییر می‌کند. به‌گفته Yerem Khalatyan، بهترین نقطهٔ شروع سه کاربرد عملی است: تولید خودکار سناریوهای آزمون، تسریع در خودکارسازی، و بهینه‌سازی اجرای تست‌ها. سامانه‌های هوشمند می‌توانند با تکیه بر نیازمندی‌ها، کد و داده‌های کاربری، سناریوهای مثبت، منفی و مرزی را پیشنهاد دهند، شکاف‌های پوشش را نشان دهند و در CI/CD اولویت اجرای تست‌ها را بر مبنای ریسک و تغییرات کد تنظیم کنند. همچنین با خودترمیمی انتخابگرها، کاهش تست‌های flaky، پیشنهاد assertion و دادهٔ آزمون، و کمک به triage خطاها، هزینهٔ نگهداشت را پایین می‌آورند. در کنار این مزایا باید به محدودیت‌ها نیز توجه کرد: خطای مدلی، تفسیر نادرست نیازمندی‌های مبهم و ملاحظات امنیت و حریم خصوصی، که حضور انسان در حلقه و حاکمیت داده را ضروری می‌سازد. برای بهره‌گیری مؤثر، مهارت‌هایی مانند طراحی پرسش برای مدل، سواد داده، آزمون مبتنی بر ریسک و ادغام ابزارها اهمیت می‌یابد؛ شروع کوچک، سنجش دقیق شاخص‌ها و سپس گسترش کنترل‌شده، مسیر عملی و کم‌ریسک است.
#QA #AIinTesting #TestAutomation #SoftwareTesting #QualityEngineering #DevOps #CICD #MachineLearning
🟣لینک مقاله:
https://cur.at/lOXHasH?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
QA Engineer Role Transformation in the Age of AI
🟢 خلاصه مقاله:
** در عصر AI نقش مهندسان QA از اجرای دستی آزمون‌ها به طراحی و هدایت جریان‌های تضمین کیفیت هوشمند تغییر می‌کند. به‌گفته Yerem Khalatyan، بهترین نقطهٔ شروع سه کاربرد عملی است: تولید خودکار سناریوهای آزمون، تسریع در خودکارسازی، و بهینه‌سازی اجرای تست‌ها. سامانه‌های هوشمند می‌توانند با تکیه بر نیازمندی‌ها، کد و داده‌های کاربری، سناریوهای مثبت، منفی و مرزی را پیشنهاد دهند، شکاف‌های پوشش را نشان دهند و در CI/CD اولویت اجرای تست‌ها را بر مبنای ریسک و تغییرات کد تنظیم کنند. همچنین با خودترمیمی انتخابگرها، کاهش تست‌های flaky، پیشنهاد assertion و دادهٔ آزمون، و کمک به triage خطاها، هزینهٔ نگهداشت را پایین می‌آورند. در کنار این مزایا باید به محدودیت‌ها نیز توجه کرد: خطای مدلی، تفسیر نادرست نیازمندی‌های مبهم و ملاحظات امنیت و حریم خصوصی، که حضور انسان در حلقه و حاکمیت داده را ضروری می‌سازد. برای بهره‌گیری مؤثر، مهارت‌هایی مانند طراحی پرسش برای مدل، سواد داده، آزمون مبتنی بر ریسک و ادغام ابزارها اهمیت می‌یابد؛ شروع کوچک، سنجش دقیق شاخص‌ها و سپس گسترش کنترل‌شده، مسیر عملی و کم‌ریسک است.
#QA #AIinTesting #TestAutomation #SoftwareTesting #QualityEngineering #DevOps #CICD #MachineLearning
🟣لینک مقاله:
https://cur.at/lOXHasH?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
QA Engineer Role Transformation in the Age of AI
How to stay competitive in the current rapidly changing market
🔵 عنوان مقاله
Best Web Test Automation Tool?
🟢 خلاصه مقاله:
در جست‌وجوی بهترین ابزار Web Test Automation، Alan Richardson با نگاهی عملی وضعیت راهکارهای پرطرفدار را بررسی کرده و نشان می‌دهد «بهترین» فقط در بستر نیازها و محدودیت‌های هر تیم معنا پیدا می‌کند. او با آزمون‌های عملی و مقایسه‌ی رو‌به‌رو، معیارهایی مانند پایداری، پوشش cross-browser، اجرای موازی، سهولت یادگیری، نگهداشت تست‌ها، گزارش‌دهی و دیباگ، یکپارچگی با CI/CD و هزینه‌ی کل مالکیت را سنجیده است. تفاوت‌های مهم میان ابزارهای متن‌باز و تجاری، رویکردهای code-first و codeless، و سرویس‌های ابری در برابر راهکارهای on-premise نیز در تحلیل او برجسته شده و به خطر قفل‌شدن در یک اکوسیستم و اهمیت مستندات و جامعه‌ی کاربری اشاره شده است. در نهایت، Richardson بر اساس زمینه‌ی خودش رأی می‌دهد و از خواننده می‌خواهد با توجه به شرایط تیم خود قضاوت کند—به‌نظر شما رقبای اصلی فهرست نهایی کدام‌اند؟
#TestAutomation #WebTesting #SoftwareTesting #QA #AutomationTools #CICD #AlanRichardson
🟣لینک مقاله:
https://cur.at/ApcXBIu?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Best Web Test Automation Tool?
🟢 خلاصه مقاله:
در جست‌وجوی بهترین ابزار Web Test Automation، Alan Richardson با نگاهی عملی وضعیت راهکارهای پرطرفدار را بررسی کرده و نشان می‌دهد «بهترین» فقط در بستر نیازها و محدودیت‌های هر تیم معنا پیدا می‌کند. او با آزمون‌های عملی و مقایسه‌ی رو‌به‌رو، معیارهایی مانند پایداری، پوشش cross-browser، اجرای موازی، سهولت یادگیری، نگهداشت تست‌ها، گزارش‌دهی و دیباگ، یکپارچگی با CI/CD و هزینه‌ی کل مالکیت را سنجیده است. تفاوت‌های مهم میان ابزارهای متن‌باز و تجاری، رویکردهای code-first و codeless، و سرویس‌های ابری در برابر راهکارهای on-premise نیز در تحلیل او برجسته شده و به خطر قفل‌شدن در یک اکوسیستم و اهمیت مستندات و جامعه‌ی کاربری اشاره شده است. در نهایت، Richardson بر اساس زمینه‌ی خودش رأی می‌دهد و از خواننده می‌خواهد با توجه به شرایط تیم خود قضاوت کند—به‌نظر شما رقبای اصلی فهرست نهایی کدام‌اند؟
#TestAutomation #WebTesting #SoftwareTesting #QA #AutomationTools #CICD #AlanRichardson
🟣لینک مقاله:
https://cur.at/ApcXBIu?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Eviltester
What tool to choose for Web UI Test Automation?
What is the best tool to choose for Web UI Test Automation? Is it still Selenium WebDriver? Or should you use Playwright?
🔵 عنوان مقاله
Selenium tests breaking constantly after every UI change. Is test maintenance really supposed to take this much time?
🟢 خلاصه مقاله:
این مسئله مطرح شد که چرا تست‌های Selenium با هر تغییر در UI می‌شکنند و آیا این حجم از نگهداری طبیعی است یا نشانه‌ی مشکل در رویکرد. جامعه‌ی کاربری توصیه کرد وابستگی تست‌ها به جزئیات شکننده‌ی رابط را کم کنند (استفاده از data-test-id)، از الگوهایی مثل Page Object Model برای متمرکزکردن انتخابگرها کمک بگیرند، و طبق Test Pyramid بیشتر پوشش را به لایه‌های Unit/API بدهند و فقط سناریوهای کاربرمحور کلیدی را با end‑to‑end اجرا کنند. برای کاهش test flakiness نیز بر waits مبتنی بر شرایط تجاری، کنترل وضعیت داده و محیط، اجتناب از تاخیرهای ثابت و انیمیشن‌ها، ایزوله‌سازی در CI، mock/stub کردن فراخوانی‌های ناپایدار، و قرنطینه و triage خودکار تست‌های flaky تأکید شد. جمع‌بندی این بود که نگهداری سنگین اغلب نتیجه‌ی استفاده‌ی بیش‌ازحد یا کوپلینگ شدید به UI است؛ با راهبردهای درست می‌توان automated tests پایدارتر و کم‌هزینه‌تر داشت.
#Selenium #TestAutomation #FlakyTests #UITesting #SoftwareTesting #QA #CICD #E2E
🟣لینک مقاله:
https://cur.at/Scyp8xS?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Selenium tests breaking constantly after every UI change. Is test maintenance really supposed to take this much time?
🟢 خلاصه مقاله:
این مسئله مطرح شد که چرا تست‌های Selenium با هر تغییر در UI می‌شکنند و آیا این حجم از نگهداری طبیعی است یا نشانه‌ی مشکل در رویکرد. جامعه‌ی کاربری توصیه کرد وابستگی تست‌ها به جزئیات شکننده‌ی رابط را کم کنند (استفاده از data-test-id)، از الگوهایی مثل Page Object Model برای متمرکزکردن انتخابگرها کمک بگیرند، و طبق Test Pyramid بیشتر پوشش را به لایه‌های Unit/API بدهند و فقط سناریوهای کاربرمحور کلیدی را با end‑to‑end اجرا کنند. برای کاهش test flakiness نیز بر waits مبتنی بر شرایط تجاری، کنترل وضعیت داده و محیط، اجتناب از تاخیرهای ثابت و انیمیشن‌ها، ایزوله‌سازی در CI، mock/stub کردن فراخوانی‌های ناپایدار، و قرنطینه و triage خودکار تست‌های flaky تأکید شد. جمع‌بندی این بود که نگهداری سنگین اغلب نتیجه‌ی استفاده‌ی بیش‌ازحد یا کوپلینگ شدید به UI است؛ با راهبردهای درست می‌توان automated tests پایدارتر و کم‌هزینه‌تر داشت.
#Selenium #TestAutomation #FlakyTests #UITesting #SoftwareTesting #QA #CICD #E2E
🟣لینک مقاله:
https://cur.at/Scyp8xS?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Reddit
From the QualityAssurance community on Reddit
Explore this post and more from the QualityAssurance community
🔵 عنوان مقاله
Every Bug Deserves a Test Case
🟢 خلاصه مقاله:
ایده اصلی این است که هر باگ پس از برطرف‌شدن باید با یک تست اختصاصی پوشش داده شود. به‌گفته‌ی Kevin Konda، برای هر باگ ابتدا یک تست بازتولیدکننده بنویسید، شکست آن را ببینید، مشکل را رفع کنید و سپس همان تستِ سبز را در مجموعه‌ی رگرسیون نگه دارید. این کار از بازگشت خطاها جلوگیری می‌کند، دانشِ لبه‌های پنهان را حفظ می‌کند، ریسکی‌بودن تغییرات را کاهش می‌دهد و به بهبود طراحی کمک می‌کند. با نام‌گذاری شفاف، پیوند به شناسه‌ی Issue، کوچک‌وساده نگه‌داشتن تست‌ها و تفکیک اجرای سریع و شبانه، می‌توان هزینه‌ی زمان و ناپایداری را کنترل کرد. در نهایت، «هر باگ یک تست» یک انضباط فرهنگی است: اشتباهات گذشته را به ریل‌های محافظ آینده تبدیل کنید.
#SoftwareTesting #RegressionTesting #QualityEngineering #TDD #BugFixing #TestCoverage #CI #EngineeringCulture
🟣لینک مقاله:
https://cur.at/Kvqi6KW?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Every Bug Deserves a Test Case
🟢 خلاصه مقاله:
ایده اصلی این است که هر باگ پس از برطرف‌شدن باید با یک تست اختصاصی پوشش داده شود. به‌گفته‌ی Kevin Konda، برای هر باگ ابتدا یک تست بازتولیدکننده بنویسید، شکست آن را ببینید، مشکل را رفع کنید و سپس همان تستِ سبز را در مجموعه‌ی رگرسیون نگه دارید. این کار از بازگشت خطاها جلوگیری می‌کند، دانشِ لبه‌های پنهان را حفظ می‌کند، ریسکی‌بودن تغییرات را کاهش می‌دهد و به بهبود طراحی کمک می‌کند. با نام‌گذاری شفاف، پیوند به شناسه‌ی Issue، کوچک‌وساده نگه‌داشتن تست‌ها و تفکیک اجرای سریع و شبانه، می‌توان هزینه‌ی زمان و ناپایداری را کنترل کرد. در نهایت، «هر باگ یک تست» یک انضباط فرهنگی است: اشتباهات گذشته را به ریل‌های محافظ آینده تبدیل کنید.
#SoftwareTesting #RegressionTesting #QualityEngineering #TDD #BugFixing #TestCoverage #CI #EngineeringCulture
🟣لینک مقاله:
https://cur.at/Kvqi6KW?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
Every Bug Deserves a Test Case
Why adding bug-based test cases to your master suite makes your QA smarter, stronger, and future-ready.
🔵 عنوان مقاله
AI Is Quietly Rewriting the Career Map for QA Engineers
🟢 خلاصه مقاله:
** هوش مصنوعی مسیر شغلی مهندسان QA را دگرگون کرده و نقش «تستر» را از اجرای تست‌ها به «ارکستراسیون» یک سامانه هوشمند از ابزارها، داده‌ها و ایجنت‌ها تغییر می‌دهد. به‌گفته Ryan Craven، ارزش اصلی QA در طراحی و نظارت بر پایپ‌لاین کیفیت است: انتخاب و اتصال ابزارها، تولید و اولویت‌بندی تست با AI، ایجاد گاردریل‌ها، مدیریت داده و بستن درگاه‌های انتشار بر اساس ریسک کسب‌وکار. مهارت‌ها هم توسعه می‌یابد: از اتوماسیون به Prompt Design، ارزیابی مدل، ایمنی، مدیریت داده، سنجش پوشش سناریویی، و تسلط بر CI/CD، Observability و Feature Flags. کار روزمره شامل تولید و پالایش تست‌های AI، کاهش خطاهای مثبت کاذب، خودترمیمی تست‌های flaky، استفاده از تله‌متری کاربر و بستن حلقه بازخورد تولید است. حاکمیت داده، حریم خصوصی، سوگیری و بازتولیدپذیری تصمیم‌های AI ضروری می‌شود و Human-in-the-loop برای تغییرات پرریسک باقی می‌ماند. عنوان‌های تازه‌ای مانند Quality Platform Engineer، QA Orchestrator و AI Test Strategist شکل می‌گیرد و مرز کار ارشد با SRE و Platform Engineering همپوشانی می‌یابد. جمع‌بندی: QA از اجرای تست‌ها به هماهنگ‌سازی انسان و AI برای ارائه کیفیت با سرعت و مقیاس حرکت می‌کند.
#AI #QA #SoftwareTesting #TestAutomation #QualityEngineering #DevOps #AIOps #CareerDevelopment
🟣لینک مقاله:
https://cur.at/bIOtF9U?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
AI Is Quietly Rewriting the Career Map for QA Engineers
🟢 خلاصه مقاله:
** هوش مصنوعی مسیر شغلی مهندسان QA را دگرگون کرده و نقش «تستر» را از اجرای تست‌ها به «ارکستراسیون» یک سامانه هوشمند از ابزارها، داده‌ها و ایجنت‌ها تغییر می‌دهد. به‌گفته Ryan Craven، ارزش اصلی QA در طراحی و نظارت بر پایپ‌لاین کیفیت است: انتخاب و اتصال ابزارها، تولید و اولویت‌بندی تست با AI، ایجاد گاردریل‌ها، مدیریت داده و بستن درگاه‌های انتشار بر اساس ریسک کسب‌وکار. مهارت‌ها هم توسعه می‌یابد: از اتوماسیون به Prompt Design، ارزیابی مدل، ایمنی، مدیریت داده، سنجش پوشش سناریویی، و تسلط بر CI/CD، Observability و Feature Flags. کار روزمره شامل تولید و پالایش تست‌های AI، کاهش خطاهای مثبت کاذب، خودترمیمی تست‌های flaky، استفاده از تله‌متری کاربر و بستن حلقه بازخورد تولید است. حاکمیت داده، حریم خصوصی، سوگیری و بازتولیدپذیری تصمیم‌های AI ضروری می‌شود و Human-in-the-loop برای تغییرات پرریسک باقی می‌ماند. عنوان‌های تازه‌ای مانند Quality Platform Engineer، QA Orchestrator و AI Test Strategist شکل می‌گیرد و مرز کار ارشد با SRE و Platform Engineering همپوشانی می‌یابد. جمع‌بندی: QA از اجرای تست‌ها به هماهنگ‌سازی انسان و AI برای ارائه کیفیت با سرعت و مقیاس حرکت می‌کند.
#AI #QA #SoftwareTesting #TestAutomation #QualityEngineering #DevOps #AIOps #CareerDevelopment
🟣لینک مقاله:
https://cur.at/bIOtF9U?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Substack
AI Is Quietly Rewriting the Career Map for QA Engineers
Automation architects are on the rise — AI is changing what it means to build and break software
👍1
🔵 عنوان مقاله
Secrets Behind 3 Years of Automation Success
🟢 خلاصه مقاله:
Nikolay Advolodkin از Oles Nikaniuk دعوت کرده تا تجربه سه سال موفقیت پایدار در خودکارسازی تست را شرح دهد؛ تمرکزشان بر استراتژی بلندمدت است: انتخاب هوشمندانه ابزارها، تعریف ترکیب درست انواع تست‌ها (با تکیه بر لایه‌های پایین‌تر و مسیرهای حیاتی در UI)، و یکپارچه‌سازی مؤثر با CI/CD برای بازخورد سریع. آن‌ها بر مدیریت دادهٔ تست، کاهش flakyها، اجرای موازی، محیط‌های موقتی و گزارش‌دهی شفاف تأکید می‌کنند و با طراحی ماژولار، بازاستفاده از کتابخانه‌ها، مستندسازی، بازبینی کد و سنجه‌های عملی (پایداری، زمان رفع، پوشش، و زمان عبور در پایپ‌لاین) پایداری و ROI را حفظ می‌کنند. بخش مهمی از موفقیت به فرهنگ همکاری بین توسعه، QA و DevOps، مالکیت مشترک کیفیت و انتشار بهترین رویه‌ها برمی‌گردد. درس‌های کلیدی: کیفیت را بر کمیت ترجیح دهید، تا پایدار شدن جریان‌های متغیر سراغ خودکارسازی آن‌ها نروید، تست‌ها را نزدیک به کد نگه دارید، از feature flagها برای جداسازی انتشار و اعتبارسنجی استفاده کنید، و از همان ابتدا روی زیرساخت و مشاهده‌پذیری سرمایه‌گذاری کنید.
#TestAutomation #CICD #QualityEngineering #DevOps #SoftwareTesting #AutomationStrategy #TestingTools
🟣لینک مقاله:
https://cur.at/sEMpr5K?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Secrets Behind 3 Years of Automation Success
🟢 خلاصه مقاله:
Nikolay Advolodkin از Oles Nikaniuk دعوت کرده تا تجربه سه سال موفقیت پایدار در خودکارسازی تست را شرح دهد؛ تمرکزشان بر استراتژی بلندمدت است: انتخاب هوشمندانه ابزارها، تعریف ترکیب درست انواع تست‌ها (با تکیه بر لایه‌های پایین‌تر و مسیرهای حیاتی در UI)، و یکپارچه‌سازی مؤثر با CI/CD برای بازخورد سریع. آن‌ها بر مدیریت دادهٔ تست، کاهش flakyها، اجرای موازی، محیط‌های موقتی و گزارش‌دهی شفاف تأکید می‌کنند و با طراحی ماژولار، بازاستفاده از کتابخانه‌ها، مستندسازی، بازبینی کد و سنجه‌های عملی (پایداری، زمان رفع، پوشش، و زمان عبور در پایپ‌لاین) پایداری و ROI را حفظ می‌کنند. بخش مهمی از موفقیت به فرهنگ همکاری بین توسعه، QA و DevOps، مالکیت مشترک کیفیت و انتشار بهترین رویه‌ها برمی‌گردد. درس‌های کلیدی: کیفیت را بر کمیت ترجیح دهید، تا پایدار شدن جریان‌های متغیر سراغ خودکارسازی آن‌ها نروید، تست‌ها را نزدیک به کد نگه دارید، از feature flagها برای جداسازی انتشار و اعتبارسنجی استفاده کنید، و از همان ابتدا روی زیرساخت و مشاهده‌پذیری سرمایه‌گذاری کنید.
#TestAutomation #CICD #QualityEngineering #DevOps #SoftwareTesting #AutomationStrategy #TestingTools
🟣لینک مقاله:
https://cur.at/sEMpr5K?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Ultimate QA
Secrets Behind 3 Years of Automation Success!
I’m Nikolay Advolodkin from UltimateQA, and in this article I unpack a two-year journey I led alongside our automation engineer Oles Nikaniuk, on a massive European enterprise migration. If you watched the episode, you already know the highlights; if not…
🔵 عنوان مقاله
Architecture Tests
🟢 خلاصه مقاله:
** تاراس Kizlo در ادامهٔ مجموعهٔ خود دربارهٔ سطوح تست، سراغ موضوع کمتر مطرح‌شده‌ای رفته است: تست‌های معماری. او توضیح می‌دهد که این تست‌ها مجموعه‌ای از قواعد اجرایی‌اند که مرزهای معماری، وابستگی‌های مجاز، نبود حلقه‌های وابستگی و قواعد نام‌گذاری/لایه‌بندی را بررسی می‌کنند تا از فرسایش تدریجی طراحی جلوگیری شود. مقاله نشان می‌دهد چگونه می‌توان این قواعد را کنار تست‌های معمول و در CI/CD اجرا کرد و با ابزارهایی مثل ArchUnit یا NetArchTest آن‌ها را به شکست‌پذیر کردن بیلد گره زد. توصیه‌های عملی شامل شروع از چند قانون پرتأثیر، پرهیز از قواعد شکننده، همگام‌سازی با تصمیم‌های معماری و به‌روزرسانی مداوم تست‌هاست. نتیجهٔ نهایی: تست‌های معماری قصد طراحی را به قراردادهای قابل اجرا تبدیل می‌کنند و به‌عنوان گاردریل‌های ماندگار، ساختار سالم کد را حفظ می‌کنند.
#ArchitectureTests #SoftwareArchitecture #SoftwareTesting #CleanArchitecture #CI/CD #ArchUnit #NetArchTest #CodeQuality
🟣لینک مقاله:
https://cur.at/WG4foAM?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Architecture Tests
🟢 خلاصه مقاله:
** تاراس Kizlo در ادامهٔ مجموعهٔ خود دربارهٔ سطوح تست، سراغ موضوع کمتر مطرح‌شده‌ای رفته است: تست‌های معماری. او توضیح می‌دهد که این تست‌ها مجموعه‌ای از قواعد اجرایی‌اند که مرزهای معماری، وابستگی‌های مجاز، نبود حلقه‌های وابستگی و قواعد نام‌گذاری/لایه‌بندی را بررسی می‌کنند تا از فرسایش تدریجی طراحی جلوگیری شود. مقاله نشان می‌دهد چگونه می‌توان این قواعد را کنار تست‌های معمول و در CI/CD اجرا کرد و با ابزارهایی مثل ArchUnit یا NetArchTest آن‌ها را به شکست‌پذیر کردن بیلد گره زد. توصیه‌های عملی شامل شروع از چند قانون پرتأثیر، پرهیز از قواعد شکننده، همگام‌سازی با تصمیم‌های معماری و به‌روزرسانی مداوم تست‌هاست. نتیجهٔ نهایی: تست‌های معماری قصد طراحی را به قراردادهای قابل اجرا تبدیل می‌کنند و به‌عنوان گاردریل‌های ماندگار، ساختار سالم کد را حفظ می‌کنند.
#ArchitectureTests #SoftwareArchitecture #SoftwareTesting #CleanArchitecture #CI/CD #ArchUnit #NetArchTest #CodeQuality
🟣لینک مقاله:
https://cur.at/WG4foAM?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
Architecture Tests
Architecture tests are an essential part of maintaining a healthy architecture. First time hearing? No worries, we will explore what those…
🔵 عنوان مقاله
Seriously Testing LLMs
🟢 خلاصه مقاله:
این مقاله به این می‌پردازد که برای آزمون جدی LLMs چه نیاز است. نویسنده با تکیه بر مجموعه‌ای از آزمایش‌ها، نشان می‌دهد چرا اتکا به دمو یا امتیازهای سطحی کافی نیست و چگونه رفتار مدل با تغییر متن راهنما، زمینه و زمان تغییر می‌کند. James Bach در این مسیر روش LARC را معرفی می‌کند؛ رویکردی ساخت‌یافته و اکتشافی برای برنامه‌ریزی، اجرای آزمون‌ها و تفسیر نتایج که بر طراحی موارد تنشی و خصمانه، مشاهده نظام‌مند و بهبود تکرارشونده تأکید دارد تا الگوهای خطا و محدودیت‌های قابلیت اعتماد آشکار شوند. مقاله توضیح می‌دهد که چرا آزمون جامع دشوار و پرهزینه است: خروجی‌های غیرقطعی، نبود داور قطعی برای «درستی»، حساسیت به Prompt و زمینه، به‌روزرسانی‌های مدل که بازتولیدپذیری را می‌شکنند، محدودیت معیارهای کمی، و نیاز به ابزار، داده، محاسبات و داوری انسانی. در نهایت پیشنهاد می‌شود آزمون LLM را یک کار تحقیقاتی-حرفه‌ای ببینیم: اهداف و ریسک‌ها را روشن کنیم، داده‌های متنوع و خصمانه بسازیم، ثبت و رهگیری کامل انجام دهیم، و با اجرای تکرارشونده روش LARC میان عمق و وسعت، خودکارسازی و قضاوت کارشناسی، و هزینه و کفایت تصمیم‌گیری کنیم.
#LLMs #SoftwareTesting #AIQuality #Evaluation #PromptEngineering #Reliability #JamesBach #MachineLearning
🟣لینک مقاله:
https://cur.at/OfLtyHW?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Seriously Testing LLMs
🟢 خلاصه مقاله:
این مقاله به این می‌پردازد که برای آزمون جدی LLMs چه نیاز است. نویسنده با تکیه بر مجموعه‌ای از آزمایش‌ها، نشان می‌دهد چرا اتکا به دمو یا امتیازهای سطحی کافی نیست و چگونه رفتار مدل با تغییر متن راهنما، زمینه و زمان تغییر می‌کند. James Bach در این مسیر روش LARC را معرفی می‌کند؛ رویکردی ساخت‌یافته و اکتشافی برای برنامه‌ریزی، اجرای آزمون‌ها و تفسیر نتایج که بر طراحی موارد تنشی و خصمانه، مشاهده نظام‌مند و بهبود تکرارشونده تأکید دارد تا الگوهای خطا و محدودیت‌های قابلیت اعتماد آشکار شوند. مقاله توضیح می‌دهد که چرا آزمون جامع دشوار و پرهزینه است: خروجی‌های غیرقطعی، نبود داور قطعی برای «درستی»، حساسیت به Prompt و زمینه، به‌روزرسانی‌های مدل که بازتولیدپذیری را می‌شکنند، محدودیت معیارهای کمی، و نیاز به ابزار، داده، محاسبات و داوری انسانی. در نهایت پیشنهاد می‌شود آزمون LLM را یک کار تحقیقاتی-حرفه‌ای ببینیم: اهداف و ریسک‌ها را روشن کنیم، داده‌های متنوع و خصمانه بسازیم، ثبت و رهگیری کامل انجام دهیم، و با اجرای تکرارشونده روش LARC میان عمق و وسعت، خودکارسازی و قضاوت کارشناسی، و هزینه و کفایت تصمیم‌گیری کنیم.
#LLMs #SoftwareTesting #AIQuality #Evaluation #PromptEngineering #Reliability #JamesBach #MachineLearning
🟣لینک مقاله:
https://cur.at/OfLtyHW?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Satisfice, Inc.
Seriously Testing LLMs - Satisfice, Inc.
Michael and I are getting a lot of interest about how we apply Rapid Software Testing methodology both to test AI and to use AI in testing. We've developed various answers to such questions in recent years. But now that the book is done (and almost out!)…
👍1
🔵 عنوان مقاله
AI in Testing: Hype or Real Progress?
🟢 خلاصه مقاله:
این یادداشت با نگاهی عمل‌گرایانه، دیدگاه Arik Aharoni را درباره نقش واقعی هوش مصنوعی در تست نرم‌افزار شرح می‌دهد: او نشان می‌دهد کجاها AI ارزش ملموس ایجاد کرده و کجاها همچنان اغراق می‌شود. به‌گفته او، AI در تولید اولیه تست‌ها از نیازمندی‌ها، پیشنهاد موارد مرزی، کاهش شکنندگی تست‌های UI، شناسایی تست‌های flaky، خوشه‌بندی خطاها، اولویت‌بندی ریسک‌محور و ساخت داده‌های آزمایشی مفید است؛ همچنین در بررسی‌های بصری و دسترس‌پذیری می‌تواند رگرسیون‌های ظریف را آشکار کند.
در مقابل، خطاهای مدل‌های زبانی، عدم درک عمیق دامنه، محدودیت‌های امنیت و حریم خصوصی، و دشواری ارزیابی کیفیت تست‌های تولیدی، مانع اعتماد کامل می‌شوند. «عامل‌های» خودمختار تست بدون نظارت انسانی هنوز پایدار نیستند و AI جایگزین طراحی آگاه از معماری، تحلیل ریسک و تأیید انسانی نمی‌شود.
جمع‌بندی Aharoni این است: پیشروی واقعی اما تدریجی است. با اجرای آزمایشی کوچک، معیارهای روشن (مانند نرخ کشف عیب و پایداری تست) و جریان‌های human-in-the-loop، می‌توان از AI در حوزه‌هایی با سیگنال قوی—مثل نگهداشت و تریاژ شکست‌ها—بهره برد؛ AI باید مکمل مهارت تیم‌های QA و مهندسی باشد، نه جایگزین آن.
#AIinTesting #SoftwareTesting #QA #TestAutomation #QualityEngineering #LLM #DevOps #TestStrategy
🟣لینک مقاله:
https://cur.at/6kIevSo?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
AI in Testing: Hype or Real Progress?
🟢 خلاصه مقاله:
این یادداشت با نگاهی عمل‌گرایانه، دیدگاه Arik Aharoni را درباره نقش واقعی هوش مصنوعی در تست نرم‌افزار شرح می‌دهد: او نشان می‌دهد کجاها AI ارزش ملموس ایجاد کرده و کجاها همچنان اغراق می‌شود. به‌گفته او، AI در تولید اولیه تست‌ها از نیازمندی‌ها، پیشنهاد موارد مرزی، کاهش شکنندگی تست‌های UI، شناسایی تست‌های flaky، خوشه‌بندی خطاها، اولویت‌بندی ریسک‌محور و ساخت داده‌های آزمایشی مفید است؛ همچنین در بررسی‌های بصری و دسترس‌پذیری می‌تواند رگرسیون‌های ظریف را آشکار کند.
در مقابل، خطاهای مدل‌های زبانی، عدم درک عمیق دامنه، محدودیت‌های امنیت و حریم خصوصی، و دشواری ارزیابی کیفیت تست‌های تولیدی، مانع اعتماد کامل می‌شوند. «عامل‌های» خودمختار تست بدون نظارت انسانی هنوز پایدار نیستند و AI جایگزین طراحی آگاه از معماری، تحلیل ریسک و تأیید انسانی نمی‌شود.
جمع‌بندی Aharoni این است: پیشروی واقعی اما تدریجی است. با اجرای آزمایشی کوچک، معیارهای روشن (مانند نرخ کشف عیب و پایداری تست) و جریان‌های human-in-the-loop، می‌توان از AI در حوزه‌هایی با سیگنال قوی—مثل نگهداشت و تریاژ شکست‌ها—بهره برد؛ AI باید مکمل مهارت تیم‌های QA و مهندسی باشد، نه جایگزین آن.
#AIinTesting #SoftwareTesting #QA #TestAutomation #QualityEngineering #LLM #DevOps #TestStrategy
🟣لینک مقاله:
https://cur.at/6kIevSo?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Software Test Management | Testuff | SaaS Test Management
AI in Testing: Hype or Real Progress? | Software Test Management | Testuff
Discover how AI is reshaping software testing, from self-healing automation to predictive quality insights, and what it means for the future of QA.
🔵 عنوان مقاله
Epistemic Testing, Chapter 2 — Is that a Test or an Experiment?
🟢 خلاصه مقاله:
در ادامه‌ی یادداشت قبلی، Masoud Bahrami با رویکردی معرفت‌شناختی مرز میان «تست» و «آزمایش» را روشن می‌کند و می‌پرسد: هر بار که می‌گوییم در حال «تست» هستیم، واقعا تست می‌کنیم یا آزمایش؟ او توضیح می‌دهد که تست برای راستی‌آزمایی یک ادعا/الزام مشخص در شرایط کنترل‌شده با اوراکل و معیارهای پذیرش روشن و هدف کاهش سریعِ ریسک‌های شناخته‌شده به‌کار می‌رود؛ در حالی‌که آزمایش برای کشف مجهولات، شکل‌دهی/اصلاح فرضیه‌ها، تحمل ابهام و سنجش سیگنال‌ها از طریق تکرار و اندازه‌گیری طراحی می‌شود. فصل به کیفیت شواهد نیز می‌پردازد: تکرارپذیری، ابطال‌پذیری، دقت اندازه‌گیری و هزینه‌ی کسب اطلاعات. یک تست خوب شامل ادعا، شرایط، اوراکل و قاعده‌ی توقف است؛ یک آزمایش خوب فرضیه، متغیرها، طرح ابزار/اندازه‌گیری و معیار به‌روزرسانی باورها را صریح می‌کند. در هر دو، شفاف‌سازی مفروضات، سوگیری‌ها و تهدیدهای اعتبار ضروری است. راهنمای عملی فصل: پیش از اجرا بپرسید در پی تأیید هستیم یا کشف؛ فرضیه/ادعا چیست؛ چه چیزی شواهد معتبر محسوب می‌شود و کدام اوراکل/متریک به‌کار می‌رود؛ ریسک هدف کدام است؛ و معیار توقف/ادامه/تغییر مسیر چیست. پیام نهایی: با نام‌گذاری درست فعالیت و اتخاذ ذهنیت معرفت‌شناختی، «تست» و «آزمایش» را مکمل هم برای تصمیم‌گیری بهتر و یادگیری سریع‌تر به‌کار بگیرید.
#EpistemicTesting #SoftwareTesting #ExperimentVsTest #QualityAssurance #Evidence #Hypothesis #MasoudBahrami
🟣لینک مقاله:
https://cur.at/4sqUvVw?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Epistemic Testing, Chapter 2 — Is that a Test or an Experiment?
🟢 خلاصه مقاله:
در ادامه‌ی یادداشت قبلی، Masoud Bahrami با رویکردی معرفت‌شناختی مرز میان «تست» و «آزمایش» را روشن می‌کند و می‌پرسد: هر بار که می‌گوییم در حال «تست» هستیم، واقعا تست می‌کنیم یا آزمایش؟ او توضیح می‌دهد که تست برای راستی‌آزمایی یک ادعا/الزام مشخص در شرایط کنترل‌شده با اوراکل و معیارهای پذیرش روشن و هدف کاهش سریعِ ریسک‌های شناخته‌شده به‌کار می‌رود؛ در حالی‌که آزمایش برای کشف مجهولات، شکل‌دهی/اصلاح فرضیه‌ها، تحمل ابهام و سنجش سیگنال‌ها از طریق تکرار و اندازه‌گیری طراحی می‌شود. فصل به کیفیت شواهد نیز می‌پردازد: تکرارپذیری، ابطال‌پذیری، دقت اندازه‌گیری و هزینه‌ی کسب اطلاعات. یک تست خوب شامل ادعا، شرایط، اوراکل و قاعده‌ی توقف است؛ یک آزمایش خوب فرضیه، متغیرها، طرح ابزار/اندازه‌گیری و معیار به‌روزرسانی باورها را صریح می‌کند. در هر دو، شفاف‌سازی مفروضات، سوگیری‌ها و تهدیدهای اعتبار ضروری است. راهنمای عملی فصل: پیش از اجرا بپرسید در پی تأیید هستیم یا کشف؛ فرضیه/ادعا چیست؛ چه چیزی شواهد معتبر محسوب می‌شود و کدام اوراکل/متریک به‌کار می‌رود؛ ریسک هدف کدام است؛ و معیار توقف/ادامه/تغییر مسیر چیست. پیام نهایی: با نام‌گذاری درست فعالیت و اتخاذ ذهنیت معرفت‌شناختی، «تست» و «آزمایش» را مکمل هم برای تصمیم‌گیری بهتر و یادگیری سریع‌تر به‌کار بگیرید.
#EpistemicTesting #SoftwareTesting #ExperimentVsTest #QualityAssurance #Evidence #Hypothesis #MasoudBahrami
🟣لینک مقاله:
https://cur.at/4sqUvVw?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Masoud Bahrami
Epistemic Testing, Chapter 2 – Is that a Test or an Experiment? | Masoud Bahrami
Chapter 2 of Epistemic Testing dives deep into the philosophy and practice of testing. I'll show you why separating experiments from tests clarifies verification, boosts reusability, and turns fragile belief into measurable trust. The Experiment Prepares…
🔵 عنوان مقاله
The Invisible Forces of Testing
🟢 خلاصه مقاله:
این مطلب با عنوان The Invisible Forces of Testing به قلم Taras Mankovski نشان می‌دهد که تصمیم‌های ما در تست تنها حاصل ابزارها و چک‌لیست‌ها نیست، بلکه تحت تاثیر «نیروهای نامرئی» قرار دارد. او با مثال توضیح می‌دهد چگونه هرم‌های آزمون تعادل میان unit، integration و end-to-end را بر اساس ریسک، زمان و معماری تعیین می‌کنند؛ چگونه حلقه‌های بازخورد سریع و قابل‌اعتماد یادگیری را شتاب می‌دهند و حلقه‌های کند یا flaky اعتماد را کاهش می‌دهند؛ و چگونه مرزهای واضح میان مولفه‌ها، قراردادها و وابستگی‌ها تست‌پذیری را بهبود می‌بخشند. نتیجه‌گیری او این است که با رویکرد systems thinking و همراستاسازی با ریسک محصول و اهداف تحویل، می‌توان آگاهانه‌ترین و موثرترین انتخاب‌ها را در استراتژی تست انجام داد.
#SoftwareTesting #TestingPyramid #FeedbackLoops #QualityEngineering #TestStrategy #SystemsThinking #QA
🟣لینک مقاله:
https://cur.at/43H9lzA?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
The Invisible Forces of Testing
🟢 خلاصه مقاله:
این مطلب با عنوان The Invisible Forces of Testing به قلم Taras Mankovski نشان می‌دهد که تصمیم‌های ما در تست تنها حاصل ابزارها و چک‌لیست‌ها نیست، بلکه تحت تاثیر «نیروهای نامرئی» قرار دارد. او با مثال توضیح می‌دهد چگونه هرم‌های آزمون تعادل میان unit، integration و end-to-end را بر اساس ریسک، زمان و معماری تعیین می‌کنند؛ چگونه حلقه‌های بازخورد سریع و قابل‌اعتماد یادگیری را شتاب می‌دهند و حلقه‌های کند یا flaky اعتماد را کاهش می‌دهند؛ و چگونه مرزهای واضح میان مولفه‌ها، قراردادها و وابستگی‌ها تست‌پذیری را بهبود می‌بخشند. نتیجه‌گیری او این است که با رویکرد systems thinking و همراستاسازی با ریسک محصول و اهداف تحویل، می‌توان آگاهانه‌ترین و موثرترین انتخاب‌ها را در استراتژی تست انجام داد.
#SoftwareTesting #TestingPyramid #FeedbackLoops #QualityEngineering #TestStrategy #SystemsThinking #QA
🟣لینک مقاله:
https://cur.at/43H9lzA?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Freestyle Testing
The Invisible Forces of Testing
Testing conversations are shaped by three metaphors — the Pyramid, Feedback Loops, and Boxes. Understanding how these forces interact helps us design test harnesses suited to our context rather than following arbitrary rules.
🔵 عنوان مقاله
Why Your 97% Test Coverage Is a Lie
🟢 خلاصه مقاله:
Ran Algawi یادآوری می‌کند که درصد بالای test coverage الزاماً به معنای کیفیت یا ایمنی نیست؛ این عدد فقط اجرای خطوط کد را می‌سنجد، نه درستی رفتار یا توان کشف خطا. پوشش بالا می‌تواند با تست‌های سطحی و خوش‌بینانه به دست آید و شاخه‌های خطا، لبه‌ها و مسائل یکپارچه‌سازی را نادیده بگیرد؛ بنابراین ریسک‌های همروندی، عملکرد و امنیت باقی می‌مانند. راه مؤثرتر، فرهنگِ تفکر سیستمی و پرسشگری است: شناسایی حالت‌های خرابی، تمرکز بر رفتار و سناریوهای واقعی، تست‌های قراردادی و اکتشافی، و تقویت مشاهده‌پذیری و بازخورد محیط تولید. coverage فقط یک سیگنال است نه هدف؛ اثربخشی را با شاخص‌هایی مثل خطاهای گریزان، زمان کشف/بازیابی و کیفیت طراحی تست بسنجید. نتیجه نهایی: به‌جای تعقیب «۹۷٪»، روی کاهش ریسک واقعی و ساخت اعتماد سرمایه‌گذاری کنید.
#TestCoverage #SoftwareTesting #QualityEngineering #RiskBasedTesting #QA #SoftwareEngineering #DevOps
🟣لینک مقاله:
https://cur.at/5eqX2tW?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Why Your 97% Test Coverage Is a Lie
🟢 خلاصه مقاله:
Ran Algawi یادآوری می‌کند که درصد بالای test coverage الزاماً به معنای کیفیت یا ایمنی نیست؛ این عدد فقط اجرای خطوط کد را می‌سنجد، نه درستی رفتار یا توان کشف خطا. پوشش بالا می‌تواند با تست‌های سطحی و خوش‌بینانه به دست آید و شاخه‌های خطا، لبه‌ها و مسائل یکپارچه‌سازی را نادیده بگیرد؛ بنابراین ریسک‌های همروندی، عملکرد و امنیت باقی می‌مانند. راه مؤثرتر، فرهنگِ تفکر سیستمی و پرسشگری است: شناسایی حالت‌های خرابی، تمرکز بر رفتار و سناریوهای واقعی، تست‌های قراردادی و اکتشافی، و تقویت مشاهده‌پذیری و بازخورد محیط تولید. coverage فقط یک سیگنال است نه هدف؛ اثربخشی را با شاخص‌هایی مثل خطاهای گریزان، زمان کشف/بازیابی و کیفیت طراحی تست بسنجید. نتیجه نهایی: به‌جای تعقیب «۹۷٪»، روی کاهش ریسک واقعی و ساخت اعتماد سرمایه‌گذاری کنید.
#TestCoverage #SoftwareTesting #QualityEngineering #RiskBasedTesting #QA #SoftwareEngineering #DevOps
🟣لینک مقاله:
https://cur.at/5eqX2tW?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
Why Your 97% Test Coverage Is a Lie
A friend recently shared a story about a payment bug that double-charged customers. During their post-mortem, someone pulled up the metrics…
🔵 عنوان مقاله
If you have 100 pages, do you create 100 Page Objects?
🟢 خلاصه مقاله:
اگر در یک اپلیکیشن ۱۰۰ صفحه دارید، آیا باید ۱۰۰ تا Page Objects بسازید؟ Đinh Công Cảnh یادآوری می‌کند که Page Objects قرار نیست نقشه‌ی یک‌به‌یک از UI باشند؛ آن‌ها باید رفتارهای پایدار و معنادار برای کاربر را کپسوله کنند تا تست‌ها خوانا و مقاوم در برابر تغییرات ظاهری بمانند. به‌جای پیروی کورکورانه از ساختار DOM، مرزها را بر اساس «قصد و کار» تعریف کنید: احراز هویت، جست‌وجو، افزودن به سبد، تسویه‌حساب. اجزای تکرارشونده مثل ناوبری، سربرگ، فیلترها، جدول‌ها و مودال‌ها را به صورت component objectهای قابل‌استفاده‌مجدد جدا کنید.
قانون سرانگشتی این است که تعداد Page Objects را نه با تعداد صفحات، بلکه با انسجام مسئولیت‌ها و میزان تغییرپذیری تعیین کنید: گاهی یک صفحه به چند object کوچک‌تر (فرم، لیست، ویجت سبد) نیاز دارد، و گاهی چند صفحه با رفتار مشابه یک object مشترک را به اشتراک می‌گذارند. نام‌گذاری را هدف‌محور کنید و جزییات تعاملی و locatorهای پایدار را در خود Page Objects نگه دارید تا تست‌ها در سطح دامنهٔ کسب‌وکار بیان شوند. از الگوهای مکمل مثل Screenplay Pattern هم می‌توان در دامنه‌های پیچیده بهره گرفت.
نتیجه اینکه عدد «۱۰۰» پاسخی ندارد؛ معیار واقعی، نگهداشت‌پذیری و کاهش اثر موجی تغییرات UI است. پیام اصلی Đinh Công Cảnh درباره شمردن objectها نیست، بلکه ساختن انتزاع‌های درست است تا تست‌ها سریع‌تر تغییر کنند، واضح‌تر بمانند و سخت‌تر بشکنند.
#PageObjects #TestAutomation #UITesting #DesignPatterns #Selenium #QA #SoftwareTesting #Maintainability
🟣لینک مقاله:
https://cur.at/vvybnfG?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
If you have 100 pages, do you create 100 Page Objects?
🟢 خلاصه مقاله:
اگر در یک اپلیکیشن ۱۰۰ صفحه دارید، آیا باید ۱۰۰ تا Page Objects بسازید؟ Đinh Công Cảnh یادآوری می‌کند که Page Objects قرار نیست نقشه‌ی یک‌به‌یک از UI باشند؛ آن‌ها باید رفتارهای پایدار و معنادار برای کاربر را کپسوله کنند تا تست‌ها خوانا و مقاوم در برابر تغییرات ظاهری بمانند. به‌جای پیروی کورکورانه از ساختار DOM، مرزها را بر اساس «قصد و کار» تعریف کنید: احراز هویت، جست‌وجو، افزودن به سبد، تسویه‌حساب. اجزای تکرارشونده مثل ناوبری، سربرگ، فیلترها، جدول‌ها و مودال‌ها را به صورت component objectهای قابل‌استفاده‌مجدد جدا کنید.
قانون سرانگشتی این است که تعداد Page Objects را نه با تعداد صفحات، بلکه با انسجام مسئولیت‌ها و میزان تغییرپذیری تعیین کنید: گاهی یک صفحه به چند object کوچک‌تر (فرم، لیست، ویجت سبد) نیاز دارد، و گاهی چند صفحه با رفتار مشابه یک object مشترک را به اشتراک می‌گذارند. نام‌گذاری را هدف‌محور کنید و جزییات تعاملی و locatorهای پایدار را در خود Page Objects نگه دارید تا تست‌ها در سطح دامنهٔ کسب‌وکار بیان شوند. از الگوهای مکمل مثل Screenplay Pattern هم می‌توان در دامنه‌های پیچیده بهره گرفت.
نتیجه اینکه عدد «۱۰۰» پاسخی ندارد؛ معیار واقعی، نگهداشت‌پذیری و کاهش اثر موجی تغییرات UI است. پیام اصلی Đinh Công Cảnh درباره شمردن objectها نیست، بلکه ساختن انتزاع‌های درست است تا تست‌ها سریع‌تر تغییر کنند، واضح‌تر بمانند و سخت‌تر بشکنند.
#PageObjects #TestAutomation #UITesting #DesignPatterns #Selenium #QA #SoftwareTesting #Maintainability
🟣لینک مقاله:
https://cur.at/vvybnfG?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
If you have 100 pages, do you create 100 Page Objects?
An interview question you may encounter