🔵 عنوان مقاله
Too close to see the canvas — Part 1
🟢 خلاصه مقاله:
در قسمت اول این مجموعه، Lena Pejgan Nyström روایت میکند که پس از پذیرش رهبری بخش QA با نتایج متناقض اتوماسیون روبهرو شد و دریافت که نشانههای ظاهراً «سبز» الزاماً کیفیت واقعی محصول را نشان نمیدهند؛ او با ترکیب تحلیل دادهها و گفتوگو با مهندسان، تسترها و مدیران محصول، ریشه مشکلات پنهان را آشکار میکند—from flaky tests و پوشش ناکافی تا سوءبرداشت در تفسیر شاخصها—و بر همسویی درباره تعریف مشترک «کیفیت»، مرزبندی نقش اتوماسیون در برابر تست اکتشافی، پاکسازی داشبوردها و رفع ناپایداری تستها تمرکز میکند تا اعتماد به خروجی QA بازسازی و بستر تغییرات پایدار برای بخشهای بعدی فراهم شود.
#QA
#تست_نرمافزار
#اتوماسیون_تست
#کیفیت_نرمافزار
#رهبری_تیم
#داده_محور
#تست_اکتشافی
🟣لینک مقاله:
https://cur.at/Jy3u75q?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Too close to see the canvas — Part 1
🟢 خلاصه مقاله:
در قسمت اول این مجموعه، Lena Pejgan Nyström روایت میکند که پس از پذیرش رهبری بخش QA با نتایج متناقض اتوماسیون روبهرو شد و دریافت که نشانههای ظاهراً «سبز» الزاماً کیفیت واقعی محصول را نشان نمیدهند؛ او با ترکیب تحلیل دادهها و گفتوگو با مهندسان، تسترها و مدیران محصول، ریشه مشکلات پنهان را آشکار میکند—from flaky tests و پوشش ناکافی تا سوءبرداشت در تفسیر شاخصها—و بر همسویی درباره تعریف مشترک «کیفیت»، مرزبندی نقش اتوماسیون در برابر تست اکتشافی، پاکسازی داشبوردها و رفع ناپایداری تستها تمرکز میکند تا اعتماد به خروجی QA بازسازی و بستر تغییرات پایدار برای بخشهای بعدی فراهم شود.
#QA
#تست_نرمافزار
#اتوماسیون_تست
#کیفیت_نرمافزار
#رهبری_تیم
#داده_محور
#تست_اکتشافی
🟣لینک مقاله:
https://cur.at/Jy3u75q?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
🔵 عنوان مقاله
Looking for AI that helps write and run automated UI tests (Playwright + Jira stack)
🟢 خلاصه مقاله:
** این بحث درباره نیاز تیمها به بهرهگیری از AI در خودکارسازی تستهای UI با محوریت Playwright و Jira است. کاربران Reddit راهکارهایی را مطرح میکنند: تبدیل داستانها و معیارهای پذیرش در Jira به سناریوهای تست و کد Playwright با کمک LLMها، استفاده از locatorهای پایدار و Page Object Model، و تغذیه AI با دانش دامنه و اجزای UI. در اجرای تست نیز به نگهداری اهمیت میدهند: پیشنهاد رفع شکستهای ناشی از تغییر selectorها، کاهش flakiness، خلاصهسازی خطاها با اسکرینشات و لاگ، و ایجاد خودکار تیکتهای Jira با جزئیات بازتولید. یک محور دیگر، اتصال به CI/CD و مدیریت داده/محیط تست با رعایت امنیت و گاردریلها برای سنجش ROI است. جمعبندی این است که ابزار یگانهای وجود ندارد؛ مسیر عملی، شروع کوچک، رعایت الگوهای مهندسی و استفاده کمکی از AI در کنار Playwright و Jira است.
#Playwright #Jira #UIAutomation #AI #Testing #QA #DevOps
🟣لینک مقاله:
https://cur.at/7CKr1ju?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Looking for AI that helps write and run automated UI tests (Playwright + Jira stack)
🟢 خلاصه مقاله:
** این بحث درباره نیاز تیمها به بهرهگیری از AI در خودکارسازی تستهای UI با محوریت Playwright و Jira است. کاربران Reddit راهکارهایی را مطرح میکنند: تبدیل داستانها و معیارهای پذیرش در Jira به سناریوهای تست و کد Playwright با کمک LLMها، استفاده از locatorهای پایدار و Page Object Model، و تغذیه AI با دانش دامنه و اجزای UI. در اجرای تست نیز به نگهداری اهمیت میدهند: پیشنهاد رفع شکستهای ناشی از تغییر selectorها، کاهش flakiness، خلاصهسازی خطاها با اسکرینشات و لاگ، و ایجاد خودکار تیکتهای Jira با جزئیات بازتولید. یک محور دیگر، اتصال به CI/CD و مدیریت داده/محیط تست با رعایت امنیت و گاردریلها برای سنجش ROI است. جمعبندی این است که ابزار یگانهای وجود ندارد؛ مسیر عملی، شروع کوچک، رعایت الگوهای مهندسی و استفاده کمکی از AI در کنار Playwright و Jira است.
#Playwright #Jira #UIAutomation #AI #Testing #QA #DevOps
🟣لینک مقاله:
https://cur.at/7CKr1ju?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Reddit
From the QualityAssurance community on Reddit
Explore this post and more from the QualityAssurance community
🔵 عنوان مقاله
Understanding Playwright Agents
🟢 خلاصه مقاله:
**عرضه اخیر Playwright Agents یک گام مهم در خودکارسازی آزمونهای مرورگری است: بهجای نوشتن تکتک گامها، هدف را توصیف میکنید و عاملها با برنامهریزی، اجرا و پایش تکرارشونده، مسیر رسیدن به آن هدف را در مرورگرهای واقعی پیدا میکنند. این رویکرد با تکیه بر نقاط قوت Playwright—پوشش چندمرورگری، ابزارهای رهگیری و انتخابگرهای پایدار—زمان ساخت تست را کاهش میدهد و نگهداری را آسانتر میکند. معماری هسته شامل سه بخش برنامهریز، اجراکننده و ناظر است که با ترکیب منطق قطعی و استدلال مدلمحور تلاش میکند هم انعطافپذیر باشد و هم قابلیت بازپخش و مشاهدهپذیری را حفظ کند. Sławomir Radzymiński در یک بررسی عمیق، نحوه کار داخلی این عاملها، الگوی حلقه تصمیمگیری، ساخت مدل از DOM و مثالهای عملی (ورود، پرداخت، و پایدارسازی سناریوهای شکننده) را توضیح میدهد و در کنار آن، محدودیتها و بهترینروشها را نیز بیان میکند: تعریف هدف شفاف، استفاده از data-testid پایدار، محدود کردن عمق اکتشاف، و پینکردن محیط در CI. مسیر پیشنهادی پذیرش نیز استفاده از Agent برای اکتشاف و تولید تستهای اولیه و سپس تثبیت آنها به اسکریپتهای قطعی Playwright است.
#Playwright #PlaywrightAgents #E2ETesting #BrowserAutomation #TestAutomation #LLM #QA #DevTools
🟣لینک مقاله:
https://cur.at/NqUSz5D?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Understanding Playwright Agents
🟢 خلاصه مقاله:
**عرضه اخیر Playwright Agents یک گام مهم در خودکارسازی آزمونهای مرورگری است: بهجای نوشتن تکتک گامها، هدف را توصیف میکنید و عاملها با برنامهریزی، اجرا و پایش تکرارشونده، مسیر رسیدن به آن هدف را در مرورگرهای واقعی پیدا میکنند. این رویکرد با تکیه بر نقاط قوت Playwright—پوشش چندمرورگری، ابزارهای رهگیری و انتخابگرهای پایدار—زمان ساخت تست را کاهش میدهد و نگهداری را آسانتر میکند. معماری هسته شامل سه بخش برنامهریز، اجراکننده و ناظر است که با ترکیب منطق قطعی و استدلال مدلمحور تلاش میکند هم انعطافپذیر باشد و هم قابلیت بازپخش و مشاهدهپذیری را حفظ کند. Sławomir Radzymiński در یک بررسی عمیق، نحوه کار داخلی این عاملها، الگوی حلقه تصمیمگیری، ساخت مدل از DOM و مثالهای عملی (ورود، پرداخت، و پایدارسازی سناریوهای شکننده) را توضیح میدهد و در کنار آن، محدودیتها و بهترینروشها را نیز بیان میکند: تعریف هدف شفاف، استفاده از data-testid پایدار، محدود کردن عمق اکتشاف، و پینکردن محیط در CI. مسیر پیشنهادی پذیرش نیز استفاده از Agent برای اکتشاف و تولید تستهای اولیه و سپس تثبیت آنها به اسکریپتهای قطعی Playwright است.
#Playwright #PlaywrightAgents #E2ETesting #BrowserAutomation #TestAutomation #LLM #QA #DevTools
🟣لینک مقاله:
https://cur.at/NqUSz5D?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Awesome Testing
Understanding Playwright Agents
A deep dive into Playwright Agents and the Model Context Protocol (MCP) — how Microsoft’s latest AI-powered Playwright release automates test planning, script generation, and self-healing browser tests across Chrome, Firefox, and WebKit.
🔵 عنوان مقاله
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.
🔵 عنوان مقاله
The New QA Mindset: Testing AI and LLMs
🟢 خلاصه مقاله:
تست محصولات مبتنی بر AI و بهویژه LLMs با نرمافزارهای کلاسیک فرق اساسی دارد: خروجیها قطعی نیستند و به داده، پرامپت و زمینه وابستهاند. در نتیجه بهجای «صحت دقیق»، باید کیفیت رفتاری، آستانهها و شواهد آماری را سنجید. این رویکرد مستلزم تعریف معیارهای روشن، ساخت دیتاستهای ارزیابی باکیفیت، اتکا به human-in-the-loop برای برچسبگذاری و تفسیر موارد مرزی، و پوشش سناریوهای متنوع و حتی مخرب (مانند prompt injection) است. جنبههای ایمنی، سوگیری، توهینآمیز بودن، حریم خصوصی و جلوگیری از hallucination به معیارهای پذیرش تبدیل میشوند. علاوه بر ارزیابی آفلاین، باید آزمایشهای آنلاین، مانیتورینگ مستمر، فیدبکلوپ و طبقهبندی خطا برای اولویتبندی اصلاحات وجود داشته باشد. توصیه کلیدی Vladimir Josifoski این است که داده، پرامپت و سیاستها را بهعنوان مصنوعات قابلتست در نظر بگیرید، از ارزیابی آماری و پیوسته بهره ببرید، و هرجا لازم است قضاوت انسانی را وارد کنید تا کیفیت واقعی تضمین شود.
#AI #LLMs #QA #AITesting #QualityAssurance #MachineLearning #PromptEngineering
🟣لینک مقاله:
https://cur.at/8mbcLve?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
The New QA Mindset: Testing AI and LLMs
🟢 خلاصه مقاله:
تست محصولات مبتنی بر AI و بهویژه LLMs با نرمافزارهای کلاسیک فرق اساسی دارد: خروجیها قطعی نیستند و به داده، پرامپت و زمینه وابستهاند. در نتیجه بهجای «صحت دقیق»، باید کیفیت رفتاری، آستانهها و شواهد آماری را سنجید. این رویکرد مستلزم تعریف معیارهای روشن، ساخت دیتاستهای ارزیابی باکیفیت، اتکا به human-in-the-loop برای برچسبگذاری و تفسیر موارد مرزی، و پوشش سناریوهای متنوع و حتی مخرب (مانند prompt injection) است. جنبههای ایمنی، سوگیری، توهینآمیز بودن، حریم خصوصی و جلوگیری از hallucination به معیارهای پذیرش تبدیل میشوند. علاوه بر ارزیابی آفلاین، باید آزمایشهای آنلاین، مانیتورینگ مستمر، فیدبکلوپ و طبقهبندی خطا برای اولویتبندی اصلاحات وجود داشته باشد. توصیه کلیدی Vladimir Josifoski این است که داده، پرامپت و سیاستها را بهعنوان مصنوعات قابلتست در نظر بگیرید، از ارزیابی آماری و پیوسته بهره ببرید، و هرجا لازم است قضاوت انسانی را وارد کنید تا کیفیت واقعی تضمین شود.
#AI #LLMs #QA #AITesting #QualityAssurance #MachineLearning #PromptEngineering
🟣لینک مقاله:
https://cur.at/8mbcLve?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
QAlogy
The New QA Mindset: Testing AI and LLMs - QAlogy
For years, QA engineers have tested deterministic systems — applications that behave predictably when given specific inputs. But with the rise of AI-driven apps and large language models (LLMs), the rules have changed. The systems we’re testing today are…
🔵 عنوان مقاله
Our Journey Through Optimising Cypress End-to-End Tests
🟢 خلاصه مقاله:
** این مقاله به قلم Omer Keskinkilic مجموعهای از تجربههای عملی برای بهینهسازی تستهای انتهابهانتها با Cypress ارائه میکند. محورها سهگانهاند: طراحی درست تست، افزایش سرعت اجرا و نگهداری بلندمدت.
در طراحی، تمرکز بر پایداری و خوانایی است: استفاده از selectorهای پایدار مانند data-test، کوچک و متمرکز نگهداشتن سناریوها، استخراج گامهای تکراری به custom commandها و پرهیز از waitهای دلخواه با همگامسازی قطعی مبتنی بر وضعیت.
برای سرعت، توصیهها شامل استفاده هدفمند از cy.intercept برای stub کردن ضروری، seed کردن داده، میانبر زدن ورود با cy.session، تقسیم مجموعه به smoke و full، موازیسازی در CI با Cypress Dashboard، اجرای headless و کش وابستگیها و محدود کردن خروجیها به شکستهاست.
در نگهداری، ساختار پوشه و نامگذاری یکدست، کمکهزینههای DRY بهجای page objectهای سنگین، مدیریت سریع flakyها (با retry بهعنوان چاره موقت)، استفاده از TypeScript برای اطمینان بیشتر در utilityها و commandها، و پیکربندی محیط از طریق cypress.config.js و متغیرهای محیطی پیشنهاد میشود. با اجرای تدریجی این نکات، مجموعه تستهای Cypress پایدارتر، سریعتر و قابل اتکاتر میشود.
#Cypress #E2E #TestAutomation #QA #JavaScript #CI #CypressDashboard #Performance
🟣لینک مقاله:
https://cur.at/YjuFkp3?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Our Journey Through Optimising Cypress End-to-End Tests
🟢 خلاصه مقاله:
** این مقاله به قلم Omer Keskinkilic مجموعهای از تجربههای عملی برای بهینهسازی تستهای انتهابهانتها با Cypress ارائه میکند. محورها سهگانهاند: طراحی درست تست، افزایش سرعت اجرا و نگهداری بلندمدت.
در طراحی، تمرکز بر پایداری و خوانایی است: استفاده از selectorهای پایدار مانند data-test، کوچک و متمرکز نگهداشتن سناریوها، استخراج گامهای تکراری به custom commandها و پرهیز از waitهای دلخواه با همگامسازی قطعی مبتنی بر وضعیت.
برای سرعت، توصیهها شامل استفاده هدفمند از cy.intercept برای stub کردن ضروری، seed کردن داده، میانبر زدن ورود با cy.session، تقسیم مجموعه به smoke و full، موازیسازی در CI با Cypress Dashboard، اجرای headless و کش وابستگیها و محدود کردن خروجیها به شکستهاست.
در نگهداری، ساختار پوشه و نامگذاری یکدست، کمکهزینههای DRY بهجای page objectهای سنگین، مدیریت سریع flakyها (با retry بهعنوان چاره موقت)، استفاده از TypeScript برای اطمینان بیشتر در utilityها و commandها، و پیکربندی محیط از طریق cypress.config.js و متغیرهای محیطی پیشنهاد میشود. با اجرای تدریجی این نکات، مجموعه تستهای Cypress پایدارتر، سریعتر و قابل اتکاتر میشود.
#Cypress #E2E #TestAutomation #QA #JavaScript #CI #CypressDashboard #Performance
🟣لینک مقاله:
https://cur.at/YjuFkp3?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
Our Journey Through Optimising Cypress End-to-End Tests
The purpose of automated tests is not to find bugs. It’s to give you confidence to make changes. — Gojko Adžić
🔵 عنوان مقاله
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.
👍1
🔵 عنوان مقاله
How to Migrate Flaky XPath to Stable Native Locators in Appium
🟢 خلاصه مقاله:
** این مقاله بهقلم Josphine Job نشان میدهد چرا استفاده از XPath در Appium اغلب شکننده و کند است و چگونه میتوان با مهاجرت به locatorهای native (مانند accessibility id و resource-id) پایداری و سرعت تستهای موبایل را افزایش داد. نویسنده روشهای عملی برای جایگزینی XPath، افزودن شناسههای پایدار با همکاری تیم توسعه و نگهداری آسانتر Page Objectها را توضیح میدهد. بخش مهم دیگر، نوشتن locatorهای native بهصورت cross-platform برای iOS و Android است تا با اتکا به نامگذاری یکسان در accessibility label یا testID، تستها در هر دو پلتفرم پایدار بمانند و فقط در صورت نیاز از fallbackهای اختصاصی استفاده شود. همچنین استفاده درست از noReset برای اجرای سریعتر و fullReset برای محیطهای تمیز و قابلتکرار تشریح میشود تا در مجموع، شکنندگی تستها کاهش یافته و اجرای آنها سریعتر و قابل اتکا گردد.
#Appium #MobileTesting #XPath #TestAutomation #Android #iOS #QA #Automation
🟣لینک مقاله:
https://cur.at/zxuVQ2?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
How to Migrate Flaky XPath to Stable Native Locators in Appium
🟢 خلاصه مقاله:
** این مقاله بهقلم Josphine Job نشان میدهد چرا استفاده از XPath در Appium اغلب شکننده و کند است و چگونه میتوان با مهاجرت به locatorهای native (مانند accessibility id و resource-id) پایداری و سرعت تستهای موبایل را افزایش داد. نویسنده روشهای عملی برای جایگزینی XPath، افزودن شناسههای پایدار با همکاری تیم توسعه و نگهداری آسانتر Page Objectها را توضیح میدهد. بخش مهم دیگر، نوشتن locatorهای native بهصورت cross-platform برای iOS و Android است تا با اتکا به نامگذاری یکسان در accessibility label یا testID، تستها در هر دو پلتفرم پایدار بمانند و فقط در صورت نیاز از fallbackهای اختصاصی استفاده شود. همچنین استفاده درست از noReset برای اجرای سریعتر و fullReset برای محیطهای تمیز و قابلتکرار تشریح میشود تا در مجموع، شکنندگی تستها کاهش یافته و اجرای آنها سریعتر و قابل اتکا گردد.
#Appium #MobileTesting #XPath #TestAutomation #Android #iOS #QA #Automation
🟣لینک مقاله:
https://cur.at/zxuVQ2?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
How to Migrate Flaky XPath to Stable Native Locators in Appium
How brittle locator strategy breaks your mobile tests and what actually works when the easiest option is the worst one.
🔵 عنوان مقاله
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…
👍1
🔵 عنوان مقاله
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
👍1