📌 Software Test Engineer - Work from home
📝 Type: Remote
🏢 Company: nearsure
📍 Location: GREATER SãO PAULO AREA
⌨️ Category: #Testing
🔗 Tags: #c #ui #aws #microservices #cloud #selenium
📝 Type: Remote
🏢 Company: nearsure
📍 Location: GREATER SãO PAULO AREA
⌨️ Category: #Testing
🔗 Tags: #c #ui #aws #microservices #cloud #selenium
👍2
این سایت به شما اجازه می‌دهد بدون نیاز به کدنویسی یک API ساختگی ایجاد کنید و درخواست‌های HTTP را به راحتی بررسی کنید.
#API #Testing #Beeceptor #WebDev #MockAPI #Mock
https://beeceptor.com/
➖➖➖➖➖➖➖➖
👑 @software_labdon
#API #Testing #Beeceptor #WebDev #MockAPI #Mock
https://beeceptor.com/
➖➖➖➖➖➖➖➖
👑 @software_labdon
📌 Senior Test Engineer
📝 Type: Visa Sponsorship
🌍 Relocation Package: ✅
🏢 Company: flusso limited
📍 Location: UNITED KINGDOM
⌨️ Category: #Testing
🔗 Tags: #storage #responsive #3d #git #aws #grafana
📝 Type: Visa Sponsorship
🌍 Relocation Package: ✅
🏢 Company: flusso limited
📍 Location: UNITED KINGDOM
⌨️ Category: #Testing
🔗 Tags: #storage #responsive #3d #git #aws #grafana
📌 Software Test Engineer (SDET) - Work from home
📝 Type: Remote
🏢 Company: nearsure
📍 Location: GREATER BUENOS AIRES
⌨️ Category: #Testing
🔗 Tags: #c #ui #aws #microservices #cloud #selenium
📝 Type: Remote
🏢 Company: nearsure
📍 Location: GREATER BUENOS AIRES
⌨️ Category: #Testing
🔗 Tags: #c #ui #aws #microservices #cloud #selenium
🔵 عنوان مقاله
From Dependency Hell to Monorepo Harmony: How We 5X Test Engineering with a Gradle Multi-Module Architecture
🟢 خلاصه مقاله:
از تب microservices تا نظم monorepo؛ این مقاله با روایت Pani Kumar نشان می‌دهد چگونه یک modular monolith بر پایه Gradle Multi-Module Architecture می‌تواند «dependency hell» را به هماهنگی ساختارمند تبدیل کند و بهره‌وری تست را تا ۵ برابر افزایش دهد. با یک monorepo و مرزبندی شفاف ماژول‌ها، مدیریت نسخه‌ها یکپارچه می‌شود، تضادهای وابستگی کاهش می‌یابد و تست‌ها سریع‌تر، پایدارتر و قابل تکرار می‌شوند. نتیجه: CI/CD سریع‌تر، کاهش flaky tests، عیب‌یابی ساده‌تر، ناوبری بهتر کد در IDE، و ریسک کمتر در رفرکتورهای سراسری. پیام نهایی: اغلب تیم‌ها با یک modular monolith و مرزهای قوی درون یک کدبیس واحد، زودتر به کیفیت و سرعت می‌رسند و فقط وقتی واقعاً لازم شد، ماژول‌ها را با آگاهی به سرویس‌های مستقل تبدیل می‌کنند.
#Monorepo #ModularMonolith #Gradle #SoftwareArchitecture #Testing #DevExperience #CICD #Microservices
🟣لینک مقاله:
https://cur.at/4FgFHQL?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
From Dependency Hell to Monorepo Harmony: How We 5X Test Engineering with a Gradle Multi-Module Architecture
🟢 خلاصه مقاله:
از تب microservices تا نظم monorepo؛ این مقاله با روایت Pani Kumar نشان می‌دهد چگونه یک modular monolith بر پایه Gradle Multi-Module Architecture می‌تواند «dependency hell» را به هماهنگی ساختارمند تبدیل کند و بهره‌وری تست را تا ۵ برابر افزایش دهد. با یک monorepo و مرزبندی شفاف ماژول‌ها، مدیریت نسخه‌ها یکپارچه می‌شود، تضادهای وابستگی کاهش می‌یابد و تست‌ها سریع‌تر، پایدارتر و قابل تکرار می‌شوند. نتیجه: CI/CD سریع‌تر، کاهش flaky tests، عیب‌یابی ساده‌تر، ناوبری بهتر کد در IDE، و ریسک کمتر در رفرکتورهای سراسری. پیام نهایی: اغلب تیم‌ها با یک modular monolith و مرزهای قوی درون یک کدبیس واحد، زودتر به کیفیت و سرعت می‌رسند و فقط وقتی واقعاً لازم شد، ماژول‌ها را با آگاهی به سرویس‌های مستقل تبدیل می‌کنند.
#Monorepo #ModularMonolith #Gradle #SoftwareArchitecture #Testing #DevExperience #CICD #Microservices
🟣لینک مقاله:
https://cur.at/4FgFHQL?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
From dependency Hell to Monorepo Harmony: How We 5x’d Test Engineering
The monorepo approach isn’t just about organizing code — it’s about treating your test assets as a first-class engineering discipline….
❤1👍1
🔵 عنوان مقاله
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
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
Medium
Beyond the Test Pyramid: Building New Monuments for Testing
🔵 عنوان مقاله
Debugging "No Tests Found" Errors in Playwright: A Comprehensive Guide
🟢 خلاصه مقاله:
راهنمای Marius Besel نشان می‌دهد که خطای “No Tests Found” در Playwright معمولاً به دلیل کشف‌نشدن فایل‌های تست یا حذف‌شدن آن‌ها توسط الگوها و فیلترها رخ می‌دهد. او تأکید می‌کند ابتدا نام‌گذاری و محل فایل‌ها را بررسی کنید: Playwright به‌طور پیش‌فرض در testDir (مثلاً tests) به‌دنبال *.spec.* یا *.test.* می‌گردد و هر تغییری در testMatch/testIgnore یا اجرای دستور در مسیر اشتباه می‌تواند کشف را از کار بیندازد. سپس فیلترها و پروژه‌ها را چک کنید: پارامترهایی مثل --grep، --grep-invert، --project یا دادن مسیری که تستی در آن نیست، ممکن است همه چیز را حذف کند؛ استفاده از --list کمک می‌کند بفهمید دقیقاً چه تست‌هایی شناسایی می‌شوند. در ساختارهای monorepo، چندین فایل playwright.config و اسکریپت‌های workspace می‌توانند Playwright را به دایرکتوری‌های نادرست ببرند.
برای TypeScript، مشکلات outDir، تفاوت ESM/CJS، و تنظیمات include/exclude در tsconfig می‌تواند مانع کشف تست‌ها شود؛ هم‌تراز کردن testDir با tsconfig، پرهیز از تزاحم فرایندهای جداگانه ترنسپایل، و یکنواخت‌کردن تنظیمات ماژول معمولاً مشکل را حل می‌کند. تفاوت محیط‌ها نیز مهم است: حساسیت به حروف در Linux، مسیرها و متغیرهای محیطی در CI، و ناهمخوانی نسخه‌ها می‌توانند باعث بروز خطا شوند. جمع‌بندی او یک چک‌لیست عملی است: نام‌گذاری/محل فایل‌ها، تنظیمات testDir/testMatch/testIgnore، فیلترها و پروژه‌ها، تنظیمات TypeScript/ماژول، و یکسان‌سازی محیط محلی و CI—با این مراحل، پیام “No Tests Found” به‌سادگی برطرف می‌شود.
#Playwright #Testing #Debugging #JavaScript #TypeScript #E2E #CI #TestAutomation
🟣لینک مقاله:
https://cur.at/irqt94X?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Debugging "No Tests Found" Errors in Playwright: A Comprehensive Guide
🟢 خلاصه مقاله:
راهنمای Marius Besel نشان می‌دهد که خطای “No Tests Found” در Playwright معمولاً به دلیل کشف‌نشدن فایل‌های تست یا حذف‌شدن آن‌ها توسط الگوها و فیلترها رخ می‌دهد. او تأکید می‌کند ابتدا نام‌گذاری و محل فایل‌ها را بررسی کنید: Playwright به‌طور پیش‌فرض در testDir (مثلاً tests) به‌دنبال *.spec.* یا *.test.* می‌گردد و هر تغییری در testMatch/testIgnore یا اجرای دستور در مسیر اشتباه می‌تواند کشف را از کار بیندازد. سپس فیلترها و پروژه‌ها را چک کنید: پارامترهایی مثل --grep، --grep-invert، --project یا دادن مسیری که تستی در آن نیست، ممکن است همه چیز را حذف کند؛ استفاده از --list کمک می‌کند بفهمید دقیقاً چه تست‌هایی شناسایی می‌شوند. در ساختارهای monorepo، چندین فایل playwright.config و اسکریپت‌های workspace می‌توانند Playwright را به دایرکتوری‌های نادرست ببرند.
برای TypeScript، مشکلات outDir، تفاوت ESM/CJS، و تنظیمات include/exclude در tsconfig می‌تواند مانع کشف تست‌ها شود؛ هم‌تراز کردن testDir با tsconfig، پرهیز از تزاحم فرایندهای جداگانه ترنسپایل، و یکنواخت‌کردن تنظیمات ماژول معمولاً مشکل را حل می‌کند. تفاوت محیط‌ها نیز مهم است: حساسیت به حروف در Linux، مسیرها و متغیرهای محیطی در CI، و ناهمخوانی نسخه‌ها می‌توانند باعث بروز خطا شوند. جمع‌بندی او یک چک‌لیست عملی است: نام‌گذاری/محل فایل‌ها، تنظیمات testDir/testMatch/testIgnore، فیلترها و پروژه‌ها، تنظیمات TypeScript/ماژول، و یکسان‌سازی محیط محلی و CI—با این مراحل، پیام “No Tests Found” به‌سادگی برطرف می‌شود.
#Playwright #Testing #Debugging #JavaScript #TypeScript #E2E #CI #TestAutomation
🟣لینک مقاله:
https://cur.at/irqt94X?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
Debugging “No Tests Found” Errors in Playwright: A Comprehensive Guide
When working with Playwright for end-to-end testing, few things are more frustrating than encountering the dreaded “No tests found” error…
🔵 عنوان مقاله
Playwright Selectors That Don't Flake — 7 Rules
🟢 خلاصه مقاله:
مقاله‌ی Roshan Manjushree Adhikari راه‌های کاهش flakiness ناشی از selectorها در Playwright را توضیح می‌دهد و تأکید می‌کند که به‌جای اتکا به retry، باید سراغ selectorهای پایدار و استفاده‌ی درست از Locator API و auto-waiting رفت. او هفت قاعده‌ی کاربردی پیشنهاد می‌کند: تکیه بر locatorهای معنایی مثل getByRole/getByLabel/getByText؛ استفاده از data-testid به‌جای کلاس‌ها/IDهای پویا؛ پرهیز از selectorهای موقعیتی مثل nth-child و محدود کردن دامنه‌ی جست‌وجو؛ بهره‌گیری از locator() و expect() با انتظارهای درون‌ساخت به‌جای sleep؛ همگام‌سازی با وضعیت واقعی UI و انجام اکشن‌های کاربرمحور؛ نزدیک‌کردن selectorها به نشانه‌گذاری دسترس‌پذیر و تمرکز آن‌ها در لایه‌ی مشترک؛ و رصد و رفع ریشه‌ای تست‌های flaky به‌جای retry سراسری. این توصیه‌ها در سایر test frameworks نیز کارآمد هستند.
#Playwright #TestAutomation #Selectors #FlakyTests #E2E #QA #Testing
🟣لینک مقاله:
https://cur.at/QPNtNUw?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Playwright Selectors That Don't Flake — 7 Rules
🟢 خلاصه مقاله:
مقاله‌ی Roshan Manjushree Adhikari راه‌های کاهش flakiness ناشی از selectorها در Playwright را توضیح می‌دهد و تأکید می‌کند که به‌جای اتکا به retry، باید سراغ selectorهای پایدار و استفاده‌ی درست از Locator API و auto-waiting رفت. او هفت قاعده‌ی کاربردی پیشنهاد می‌کند: تکیه بر locatorهای معنایی مثل getByRole/getByLabel/getByText؛ استفاده از data-testid به‌جای کلاس‌ها/IDهای پویا؛ پرهیز از selectorهای موقعیتی مثل nth-child و محدود کردن دامنه‌ی جست‌وجو؛ بهره‌گیری از locator() و expect() با انتظارهای درون‌ساخت به‌جای sleep؛ همگام‌سازی با وضعیت واقعی UI و انجام اکشن‌های کاربرمحور؛ نزدیک‌کردن selectorها به نشانه‌گذاری دسترس‌پذیر و تمرکز آن‌ها در لایه‌ی مشترک؛ و رصد و رفع ریشه‌ای تست‌های flaky به‌جای retry سراسری. این توصیه‌ها در سایر test frameworks نیز کارآمد هستند.
#Playwright #TestAutomation #Selectors #FlakyTests #E2E #QA #Testing
🟣لینک مقاله:
https://cur.at/QPNtNUw?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
Playwright Selectors That Don’t Flake — 7 Rules
Your test passes today, fails tomorrow, and nobody touched the code. Most of the time, it’s not Playwright’s fault — it’s your selectors.
🔵 عنوان مقاله
Web Accessibility Testing — Are We There Yet?
🟢 خلاصه مقاله:
**با اجرای European Accessibility Act، آزمون‌های دسترس‌پذیری از یک گزینه جانبی به یک ضرورت قانونی و اخلاقی تبدیل شده‌اند. مقاله می‌گوید با وجود پیشرفت‌ها، وضعیت هنوز مطلوب نیست: ابزارهای خودکار فقط بخشی از مشکلات را می‌یابند و بسیاری از موانع در استفاده واقعی و با فناوری‌های کمکی آشکار می‌شوند. راهکار، ترکیب آزمون خودکار و دستی، مشارکت کاربران دارای معلولیت، و ادغام دسترس‌پذیری در طراحی، توسعه، CI/CD و حاکمیت کیفیت است. پیام نهایی: دسترس‌پذیری باید یک فرایند مستمر و مشترک باشد تا هم ریسک را کاهش دهد و هم تجربه‌ای فراگیرتر ایجاد کند.
#Accessibility #A11y #EuropeanAccessibilityAct #WCAG #InclusiveDesign #Testing #QA #DevOps
🟣لینک مقاله:
https://cur.at/fU9ymSF?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Web Accessibility Testing — Are We There Yet?
🟢 خلاصه مقاله:
**با اجرای European Accessibility Act، آزمون‌های دسترس‌پذیری از یک گزینه جانبی به یک ضرورت قانونی و اخلاقی تبدیل شده‌اند. مقاله می‌گوید با وجود پیشرفت‌ها، وضعیت هنوز مطلوب نیست: ابزارهای خودکار فقط بخشی از مشکلات را می‌یابند و بسیاری از موانع در استفاده واقعی و با فناوری‌های کمکی آشکار می‌شوند. راهکار، ترکیب آزمون خودکار و دستی، مشارکت کاربران دارای معلولیت، و ادغام دسترس‌پذیری در طراحی، توسعه، CI/CD و حاکمیت کیفیت است. پیام نهایی: دسترس‌پذیری باید یک فرایند مستمر و مشترک باشد تا هم ریسک را کاهش دهد و هم تجربه‌ای فراگیرتر ایجاد کند.
#Accessibility #A11y #EuropeanAccessibilityAct #WCAG #InclusiveDesign #Testing #QA #DevOps
🟣لینک مقاله:
https://cur.at/fU9ymSF?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
My world of testing and thoughts
Web Accessibility Testing – Are We There Yet?
In the tech world right now, web accessibility is being talked about a lot. Webinars. Blog posts. Conference talks. Panels. How to do web accessibility testing, the tools and the law etc. There’s n…
❤1
🔵 عنوان مقاله
How Playwright Runs Workers and Test Fixtures (Parallel vs Serial vs Default)!
🟢 خلاصه مقاله:
این مقاله از Thananjayan Rajasekaran به‌صورت عملی نشان می‌دهد Playwright Test چگونه workers و test fixtures را مدیریت می‌کند و تفاوت حالت‌های default، parallel و serial چیست. ابتدا توضیح می‌دهد که به‌طور پیش‌فرض فایل‌های تست روی چند worker به‌صورت موازی اجرا می‌شوند اما تست‌های داخل هر فایل به‌صورت ترتیبی اجرا می‌گردند؛ همچنین به تعامل retries، projects و گزینه‌هایی مانند --workers و sharding برای کنترل سرعت و پایداری اشاره می‌کند. سپس روش‌های افزایش همزمانی را بررسی می‌کند: فعال‌کردن fullyParallel در تنظیمات یا استفاده از test.describe.configure({ mode: 'parallel' }) برای موازی‌سازی بخشی از تست‌ها، همراه با هشدار درباره ریسک‌های وضعیت مشترک و flaky شدن. در بخش serial، با test.describe.serial یا تنظیم mode: 'serial' می‌توان اجرای ترتیبی و توقف زنجیره پس از شکست را تضمین کرد؛ راهکاری که برای گردش‌کارهای وابسته یا منابع غیرقابل‌اشتراک میان workers مفید است، هرچند توصیه می‌شود فقط در صورت نیاز استفاده شود. بخش مهم دیگر به fixtures می‌پردازد: تفاوت بین per-test و worker-scoped و تأثیر مستقیم آن‌ها بر موازی‌سازی؛ اینکه worker-scoped بین workers به‌اشتراک گذاشته نمی‌شود و ممکن است چند نمونه مستقل از یک منبع ایجاد شود. مقاله با نمونه‌کدهای روشن برای تنظیم workers، فعال‌سازی fullyParallel، علامت‌گذاری suiteها به‌صورت serial یا parallel و ترکیب آن‌ها با projects و retries، یک الگوی ذهنی شفاف برای انتخاب بهینه بین default، parallel و serial ارائه می‌دهد تا هم سرعت اجرا بالا برود و هم پایداری CI حفظ شود.
#Playwright #Testing #E2E #ParallelTesting #TestAutomation #JavaScript #Fixtures #CI
🟣لینک مقاله:
https://cur.at/93wY1jL?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
How Playwright Runs Workers and Test Fixtures (Parallel vs Serial vs Default)!
🟢 خلاصه مقاله:
این مقاله از Thananjayan Rajasekaran به‌صورت عملی نشان می‌دهد Playwright Test چگونه workers و test fixtures را مدیریت می‌کند و تفاوت حالت‌های default، parallel و serial چیست. ابتدا توضیح می‌دهد که به‌طور پیش‌فرض فایل‌های تست روی چند worker به‌صورت موازی اجرا می‌شوند اما تست‌های داخل هر فایل به‌صورت ترتیبی اجرا می‌گردند؛ همچنین به تعامل retries، projects و گزینه‌هایی مانند --workers و sharding برای کنترل سرعت و پایداری اشاره می‌کند. سپس روش‌های افزایش همزمانی را بررسی می‌کند: فعال‌کردن fullyParallel در تنظیمات یا استفاده از test.describe.configure({ mode: 'parallel' }) برای موازی‌سازی بخشی از تست‌ها، همراه با هشدار درباره ریسک‌های وضعیت مشترک و flaky شدن. در بخش serial، با test.describe.serial یا تنظیم mode: 'serial' می‌توان اجرای ترتیبی و توقف زنجیره پس از شکست را تضمین کرد؛ راهکاری که برای گردش‌کارهای وابسته یا منابع غیرقابل‌اشتراک میان workers مفید است، هرچند توصیه می‌شود فقط در صورت نیاز استفاده شود. بخش مهم دیگر به fixtures می‌پردازد: تفاوت بین per-test و worker-scoped و تأثیر مستقیم آن‌ها بر موازی‌سازی؛ اینکه worker-scoped بین workers به‌اشتراک گذاشته نمی‌شود و ممکن است چند نمونه مستقل از یک منبع ایجاد شود. مقاله با نمونه‌کدهای روشن برای تنظیم workers، فعال‌سازی fullyParallel، علامت‌گذاری suiteها به‌صورت serial یا parallel و ترکیب آن‌ها با projects و retries، یک الگوی ذهنی شفاف برای انتخاب بهینه بین default، parallel و serial ارائه می‌دهد تا هم سرعت اجرا بالا برود و هم پایداری CI حفظ شود.
#Playwright #Testing #E2E #ParallelTesting #TestAutomation #JavaScript #Fixtures #CI
🟣لینک مقاله:
https://cur.at/93wY1jL?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
How Playwright Runs Workers and Test Fixtures (Parallel vs Serial vs Default)!
If you are using a playwright for quite some time, definitely you use fixture or parallel execution or both, In this blog we will see how…
❤1