🔵 عنوان مقاله
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
🔵 عنوان مقاله
Test Automation: How to Turn Regression Routine into a Reliable System
🟢 خلاصه مقاله:
این مقاله روایت عملی Maksim Laptev از گذار تیم از رگرسیون دستی به یک سامانه خودکار و قابل اتکاست. او بر اولویتبندی مبتنی بر ریسک تأکید میکند: شروع با اسموک تستهای سریع، افزودن تستهای پایدار در سطح API برای هسته سیستم و خودکارسازی محدود اما هدفمند مسیرهای UI پرارزش، در کنار حفظ تستهای اکتشافی. معیارهای انتخاب ابزار شامل همراستایی با زبان تیم، یکپارچگی با CI/CD، اجرای موازی، گزارشدهی و نگهداشتپذیری است و پرهیز از تنوع بیرویه ابزار توصیه میشود. در معماری، جداسازی لایهها (الگوهایی مانند Page Object/Screenplay)، مدیریت داده و محیط تکرارپذیر، حذف منابع flakiness با انتظارهای قطعی و setup/teardown ایمن، و برچسبگذاری و شاردینگ برای سرعت، نقش کلیدی دارند. ادغام در CI/CD با دروازههای سریع، رگرسیونهای دورهای و سنجههایی مانند پوشش جریانهای حیاتی، نرخ flake و زمان رفع، کیفیت را پایدار میکند. در نهایت با یک نقشه راه گامبهگام، آموزش و کدنویسی استاندارد برای تستها، و بازبینی و هرس منظم، میتوان سامانهای ساخت که چرخه بازخورد را کوتاه و ریسک انتشار را کم میکند.
#TestAutomation #SoftwareTesting #QA #RegressionTesting #CICD #DevOps #SDET
🟣لینک مقاله:
https://cur.at/Z0J7xPm?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Test Automation: How to Turn Regression Routine into a Reliable System
🟢 خلاصه مقاله:
این مقاله روایت عملی Maksim Laptev از گذار تیم از رگرسیون دستی به یک سامانه خودکار و قابل اتکاست. او بر اولویتبندی مبتنی بر ریسک تأکید میکند: شروع با اسموک تستهای سریع، افزودن تستهای پایدار در سطح API برای هسته سیستم و خودکارسازی محدود اما هدفمند مسیرهای UI پرارزش، در کنار حفظ تستهای اکتشافی. معیارهای انتخاب ابزار شامل همراستایی با زبان تیم، یکپارچگی با CI/CD، اجرای موازی، گزارشدهی و نگهداشتپذیری است و پرهیز از تنوع بیرویه ابزار توصیه میشود. در معماری، جداسازی لایهها (الگوهایی مانند Page Object/Screenplay)، مدیریت داده و محیط تکرارپذیر، حذف منابع flakiness با انتظارهای قطعی و setup/teardown ایمن، و برچسبگذاری و شاردینگ برای سرعت، نقش کلیدی دارند. ادغام در CI/CD با دروازههای سریع، رگرسیونهای دورهای و سنجههایی مانند پوشش جریانهای حیاتی، نرخ flake و زمان رفع، کیفیت را پایدار میکند. در نهایت با یک نقشه راه گامبهگام، آموزش و کدنویسی استاندارد برای تستها، و بازبینی و هرس منظم، میتوان سامانهای ساخت که چرخه بازخورد را کوتاه و ریسک انتشار را کم میکند.
#TestAutomation #SoftwareTesting #QA #RegressionTesting #CICD #DevOps #SDET
🟣لینک مقاله:
https://cur.at/Z0J7xPm?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
Test Automation: How to Turn Regression Routine into a Reliable System
In my previous article, I discussed the “Three Pillars” of high-quality QA: documentation, stable environments, and streamlined processes…
🔵 عنوان مقاله
"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…
🔵 عنوان مقاله
👼 A cloud firewall you don't need to babysit (Sponsor)
🟢 خلاصه مقاله:
سامانههای فایروال ابری بهویژه برای تیمهای کوچک بهسرعت پیچیده و پر از هشدار میشوند و همین پیچیدگی هم ریسک خطای پیکربندی را بالا میبرد و هم تمرکز تیم را میگیرد. Intrusion Shield for AWS با اتکا به دههها تهدیدشناسی قابل اتکا، ترافیک پرریسک را بهصورت خودکار شناسایی و مسدود میکند. هر تلاش مخرب برای اتصال، بیدرنگ به یک قانون فایروال دقیق تبدیل میشود؛ بدون نیاز به اقدام دستی. خروجی این رویکرد، کاهش هشدارها و اولویتبندی هوشمند است تا تیم روی مسائل مهمتر تمرکز کند، در حالیکه دفاعها با بهروزرسانی مداوم هوشمندانه با تهدیدات جدید همگام میمانند.
#CloudSecurity #Firewall #AWS #ThreatIntelligence #Automation #DevOps #NetworkSecurity
🟣لینک مقاله:
https://www.intrusion.com/intrusion-shield-cloud-for-aws-tldr/?utm_campaign=22505002-AWS_Launch_2025&utm_source=TLDR&utm_medium=100825
➖➖➖➖➖➖➖➖
👑 @software_Labdon
👼 A cloud firewall you don't need to babysit (Sponsor)
🟢 خلاصه مقاله:
سامانههای فایروال ابری بهویژه برای تیمهای کوچک بهسرعت پیچیده و پر از هشدار میشوند و همین پیچیدگی هم ریسک خطای پیکربندی را بالا میبرد و هم تمرکز تیم را میگیرد. Intrusion Shield for AWS با اتکا به دههها تهدیدشناسی قابل اتکا، ترافیک پرریسک را بهصورت خودکار شناسایی و مسدود میکند. هر تلاش مخرب برای اتصال، بیدرنگ به یک قانون فایروال دقیق تبدیل میشود؛ بدون نیاز به اقدام دستی. خروجی این رویکرد، کاهش هشدارها و اولویتبندی هوشمند است تا تیم روی مسائل مهمتر تمرکز کند، در حالیکه دفاعها با بهروزرسانی مداوم هوشمندانه با تهدیدات جدید همگام میمانند.
#CloudSecurity #Firewall #AWS #ThreatIntelligence #Automation #DevOps #NetworkSecurity
🟣لینک مقاله:
https://www.intrusion.com/intrusion-shield-cloud-for-aws-tldr/?utm_campaign=22505002-AWS_Launch_2025&utm_source=TLDR&utm_medium=100825
➖➖➖➖➖➖➖➖
👑 @software_Labdon
👍2
🔵 عنوان مقاله
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…
🔵 عنوان مقاله
trdl (GitHub Repo)
🟢 خلاصه مقاله:
خلاصهای متنباز به نام trdl با تمرکز بر «تحویل مطمئن» آخرین مرحلهی توزیع نرمافزار را امن میکند: رساندن بهروزرسانیها از Git به کاربر نهایی با کانالی قابلاعتماد و قابلراستیآزمایی. این راهکار با اتصال طبیعی به فرآیندهای مبتنی بر Git و ادغام در اتوماسیون انتشار، تضمین میکند آنچه نصب میشود همان چیزی است که نگهدارندگان منتشر کردهاند. با تکیه بر امضا و راستیآزمایی رمزنگاری، اصالت، تمامیت و مبدأ بهروزرسانیها قبل از اعمال بررسی میشود؛ در نتیجه ریسکهای زنجیره تأمین کاهش مییابد و امکان انتشارهای قابلممیزی، بازگشت نسخه و سیاستهای بهروزرسانی (مانند stable یا pre-release) فراهم میشود. trdl متنباز است، میتواند self-hosted اجرا شود، و از طریق GitHub Repo در دسترس است؛ کاربران و تیمهای عملیاتی نیز میتوانند با یک رابط ساده مانند CLI بهروزرسانیهای مورد اعتماد را دریافت و اعمال کنند.
#trdl #SupplyChainSecurity #SecureUpdates #Git #OpenSource #DevOps #SoftwareDelivery #CI/CD
🟣لینک مقاله:
https://github.com/werf/trdl?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
trdl (GitHub Repo)
🟢 خلاصه مقاله:
خلاصهای متنباز به نام trdl با تمرکز بر «تحویل مطمئن» آخرین مرحلهی توزیع نرمافزار را امن میکند: رساندن بهروزرسانیها از Git به کاربر نهایی با کانالی قابلاعتماد و قابلراستیآزمایی. این راهکار با اتصال طبیعی به فرآیندهای مبتنی بر Git و ادغام در اتوماسیون انتشار، تضمین میکند آنچه نصب میشود همان چیزی است که نگهدارندگان منتشر کردهاند. با تکیه بر امضا و راستیآزمایی رمزنگاری، اصالت، تمامیت و مبدأ بهروزرسانیها قبل از اعمال بررسی میشود؛ در نتیجه ریسکهای زنجیره تأمین کاهش مییابد و امکان انتشارهای قابلممیزی، بازگشت نسخه و سیاستهای بهروزرسانی (مانند stable یا pre-release) فراهم میشود. trdl متنباز است، میتواند self-hosted اجرا شود، و از طریق GitHub Repo در دسترس است؛ کاربران و تیمهای عملیاتی نیز میتوانند با یک رابط ساده مانند CLI بهروزرسانیهای مورد اعتماد را دریافت و اعمال کنند.
#trdl #SupplyChainSecurity #SecureUpdates #Git #OpenSource #DevOps #SoftwareDelivery #CI/CD
🟣لینک مقاله:
https://github.com/werf/trdl?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
GitHub
GitHub - werf/trdl: The universal solution for delivering your software updates securely from a trusted The Update Framework (TUF)…
The universal solution for delivering your software updates securely from a trusted The Update Framework (TUF) repository. - werf/trdl
🔵 عنوان مقاله
In Sprint Test Automation
🟢 خلاصه مقاله:
در آزمونسازی دروناسپرینت در Agile، هدف این است که تستها همزمان با توسعه نوشته و اجرا شوند تا بازخورد سریع و خطاهای انباشته کاهش یابد. تجربهها نشان میدهد موفقیت به چند عامل وابسته است: خرد کردن قصهها به قطعات کوچک و قابلآزمون، پذیرش «Definition of Ready» و «Definition of Done» که شامل آزمون خودکار است، همکاری نزدیک Dev و QA با رویکردهای TDD/BDD، و برخورد با تست مثل کد (همان مخزن، همان استراتژی شاخه، همان بازبینی کد).
برای پشتیبانی از این جریان، CI/CD باید سریع و قابلاعتماد باشد: اجرای موازی، محیطهای موقتی مبتنی بر کانتینر، مجازیسازی سرویسها و Mockها برای قطع وابستگیها، و مدیریت دادهی تست که آزمونها را تکرارپذیر و بدون نوسان نگه میدارد. تمرکز بر هرم تست ضروری است: پوشش بالای Unit و Integration/Contract، و تنها یک لایه نازک از E2E UI (مثلاً با Cypress یا Playwright)؛ در کنار آن، سنجههایی مانند زمان رسیدن تغییر تا استقرار، نرخ شکست و زمان ترمیم رصد میشوند و تستهای flaky سریع قرنطینه و اصلاح میگردند.
همچنین پرهیز از الگوهای ضدِکیفیت مانند «Hardening Sprint»، عقبانداختن اتوماسیون بهعنوان بدهی، یا اتکا به E2E شکننده توصیه میشود. استفاده از Feature Flag، Contract Testing در معماریهای مبتنی بر سرویس، و مالکیت مشترک کیفیت در کل تیم به تحقق «اتمام واقعی کار» در همان اسپرینت کمک میکند.
#Agile #TestAutomation #InSprintTesting #CI_CD #TDD #BDD #DevOps
🟣لینک مقاله:
https://cur.at/46VanjF?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
In Sprint Test Automation
🟢 خلاصه مقاله:
در آزمونسازی دروناسپرینت در Agile، هدف این است که تستها همزمان با توسعه نوشته و اجرا شوند تا بازخورد سریع و خطاهای انباشته کاهش یابد. تجربهها نشان میدهد موفقیت به چند عامل وابسته است: خرد کردن قصهها به قطعات کوچک و قابلآزمون، پذیرش «Definition of Ready» و «Definition of Done» که شامل آزمون خودکار است، همکاری نزدیک Dev و QA با رویکردهای TDD/BDD، و برخورد با تست مثل کد (همان مخزن، همان استراتژی شاخه، همان بازبینی کد).
برای پشتیبانی از این جریان، CI/CD باید سریع و قابلاعتماد باشد: اجرای موازی، محیطهای موقتی مبتنی بر کانتینر، مجازیسازی سرویسها و Mockها برای قطع وابستگیها، و مدیریت دادهی تست که آزمونها را تکرارپذیر و بدون نوسان نگه میدارد. تمرکز بر هرم تست ضروری است: پوشش بالای Unit و Integration/Contract، و تنها یک لایه نازک از E2E UI (مثلاً با Cypress یا Playwright)؛ در کنار آن، سنجههایی مانند زمان رسیدن تغییر تا استقرار، نرخ شکست و زمان ترمیم رصد میشوند و تستهای flaky سریع قرنطینه و اصلاح میگردند.
همچنین پرهیز از الگوهای ضدِکیفیت مانند «Hardening Sprint»، عقبانداختن اتوماسیون بهعنوان بدهی، یا اتکا به E2E شکننده توصیه میشود. استفاده از Feature Flag، Contract Testing در معماریهای مبتنی بر سرویس، و مالکیت مشترک کیفیت در کل تیم به تحقق «اتمام واقعی کار» در همان اسپرینت کمک میکند.
#Agile #TestAutomation #InSprintTesting #CI_CD #TDD #BDD #DevOps
🟣لینک مقاله:
https://cur.at/46VanjF?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Reddit
From the QualityAssurance community on Reddit
Explore this post and more from the QualityAssurance community
👍1
🔵 عنوان مقاله
Why QA Keep Losing the Same Battles, even when Automation and AI is integrated
🟢 خلاصه مقاله:
این مقاله میگوید با وجود سرمایهگذاری در Automation و AI، مشکلات QA تکرار میشوند، چون مسأله اصلی کمبود ابزار نیست، بلکه نبود همراستایی بر سر معنای «کیفیت» و شیوه ساختن آن است. بهگفته Marina Jordão، کیفیت واقعی از انسانها، استراتژی و حمایت از کاربر میآید؛ ابزارها فقط سرعت میدهند، اما جای تحلیل ریسک، معیارهای شفاف و آزمون اکتشافی را نمیگیرند. شکستهای تکراری زمانی رخ میدهد که QA دیر وارد چرخه میشود، شاخصها سطحیاند و تمرکز از نتایج واقعی برای کاربر دور میشود. راهحل، دیدن کیفیت بهعنوان مسئولیت تیمی، درگیر کردن زودهنگام QA، تکیه بر پیشگیری بهجای صرفاً کشف خطا و بهکارگیری Automation و AI بهعنوان تقویتکننده قضاوت انسانی است.
#QA #Testing #Automation #AI #QualityEngineering #UserAdvocacy #TestStrategy #DevOps
🟣لینک مقاله:
https://cur.at/UzsHvzU?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Why QA Keep Losing the Same Battles, even when Automation and AI is integrated
🟢 خلاصه مقاله:
این مقاله میگوید با وجود سرمایهگذاری در Automation و AI، مشکلات QA تکرار میشوند، چون مسأله اصلی کمبود ابزار نیست، بلکه نبود همراستایی بر سر معنای «کیفیت» و شیوه ساختن آن است. بهگفته Marina Jordão، کیفیت واقعی از انسانها، استراتژی و حمایت از کاربر میآید؛ ابزارها فقط سرعت میدهند، اما جای تحلیل ریسک، معیارهای شفاف و آزمون اکتشافی را نمیگیرند. شکستهای تکراری زمانی رخ میدهد که QA دیر وارد چرخه میشود، شاخصها سطحیاند و تمرکز از نتایج واقعی برای کاربر دور میشود. راهحل، دیدن کیفیت بهعنوان مسئولیت تیمی، درگیر کردن زودهنگام QA، تکیه بر پیشگیری بهجای صرفاً کشف خطا و بهکارگیری Automation و AI بهعنوان تقویتکننده قضاوت انسانی است.
#QA #Testing #Automation #AI #QualityEngineering #UserAdvocacy #TestStrategy #DevOps
🟣لینک مقاله:
https://cur.at/UzsHvzU?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
Why QA Keep Losing the Same Battles, even when Automation and is integrated
Why QA Keep Losing the Same Battles, even when Automation and AI is integrated Today, building software without test automation and AI is like trying to run a modern city without electricity. You can …
🔵 عنوان مقاله
Power pairing our people process: How we moved to a collaborative QA Engineer and QA Analyst model
🟢 خلاصه مقاله:
** این مقاله نشان میدهد که با جفتکردن نقشهای مکمل در کیفیت، یعنی QA Engineer و QA Analyst، میتوان کیفیت را از یک مرحله انتهایی به یک فعالیت پیوسته و مشارکتی در دل فرایند توسعه تبدیل کرد. بر اساس ایدههای Matthew Whitaker و همسو با فلسفه pair-programming، QA Engineer روی اتوماسیون، ابزارها و CI/CD تمرکز میکند و QA Analyst بر تحلیل نیازمندیها، آزمون اکتشافی و مدیریت ریسک؛ و همکاری نزدیک آنها شکافهای فنی و محصولی را کاهش میدهد. این جفت بهصورت مشترک معیارهای پذیرش و استراتژی آزمون را مینویسد، بین نقش «راننده/راهنما» جابهجا میشود و یافتههای اکتشافی را سریع به تستهای خودکار قابل نگهداری تبدیل میکند. پیادهسازی موفق با یک پایلوت، برنامه pairing شفاف، ابزارهای دیدپذیری، و سنجههایی مانند نرخ خطای فرار، زمان چرخه و نرخ بازکار آغاز میشود و با مدیریت چالشهایی مانند ابهام نقش و خستگی جلسات از طریق RACI سبک، پلیبوک، تایمباکس و آداب pairing تثبیت میشود. دستاوردها شامل بازخورد سریعتر، کاهش خطاهای فرار، مالکیت مشترک کیفیت و انتقال دانش گستردهتر در تیم است؛ همان درسی که از pair-programming میگیریم: دو ذهن مکمل، از یک متخصص تنها مؤثرترند.
#QA #PairProgramming #QualityAssurance #AgileTesting #Collaboration #DevOps #TestAutomation #TeamCulture
🟣لینک مقاله:
https://cur.at/EuZObTr?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Power pairing our people process: How we moved to a collaborative QA Engineer and QA Analyst model
🟢 خلاصه مقاله:
** این مقاله نشان میدهد که با جفتکردن نقشهای مکمل در کیفیت، یعنی QA Engineer و QA Analyst، میتوان کیفیت را از یک مرحله انتهایی به یک فعالیت پیوسته و مشارکتی در دل فرایند توسعه تبدیل کرد. بر اساس ایدههای Matthew Whitaker و همسو با فلسفه pair-programming، QA Engineer روی اتوماسیون، ابزارها و CI/CD تمرکز میکند و QA Analyst بر تحلیل نیازمندیها، آزمون اکتشافی و مدیریت ریسک؛ و همکاری نزدیک آنها شکافهای فنی و محصولی را کاهش میدهد. این جفت بهصورت مشترک معیارهای پذیرش و استراتژی آزمون را مینویسد، بین نقش «راننده/راهنما» جابهجا میشود و یافتههای اکتشافی را سریع به تستهای خودکار قابل نگهداری تبدیل میکند. پیادهسازی موفق با یک پایلوت، برنامه pairing شفاف، ابزارهای دیدپذیری، و سنجههایی مانند نرخ خطای فرار، زمان چرخه و نرخ بازکار آغاز میشود و با مدیریت چالشهایی مانند ابهام نقش و خستگی جلسات از طریق RACI سبک، پلیبوک، تایمباکس و آداب pairing تثبیت میشود. دستاوردها شامل بازخورد سریعتر، کاهش خطاهای فرار، مالکیت مشترک کیفیت و انتقال دانش گستردهتر در تیم است؛ همان درسی که از pair-programming میگیریم: دو ذهن مکمل، از یک متخصص تنها مؤثرترند.
#QA #PairProgramming #QualityAssurance #AgileTesting #Collaboration #DevOps #TestAutomation #TeamCulture
🟣لینک مقاله:
https://cur.at/EuZObTr?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Ministry of Testing
Power pairing our people process: How we moved to a collaborative QA Engineer and QA Analyst model
Pairing QA Engineers and Analysts isn't just a process tweak, it's a cultural shift that transforms siloed testing into a collaborative, balanced and business-aligned effort.
🔵 عنوان مقاله
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…