🔵 عنوان مقاله
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.