🔵 عنوان مقاله
FunnelPeek: A Modern Tool for Exploring Android UI Elements
🟢 خلاصه مقاله:
** معرفی FunnelPeek به‌عنوان یک UI inspector متن‌باز برای Android نشان می‌دهد چطور می‌توان مسیرها و locatorهای پایدار را سریع‌تر پیدا کرد. Saeed Roshan در این ابزار کاوش سلسله‌مراتب نما، برجسته‌سازی عناصر و بررسی ویژگی‌هایی مثل resource ID و content description را نشان می‌دهد تا انتخاب locatorهای قابل اعتماد آسان‌تر شود. نتیجه برای تیم‌های توسعه و QA، کاهش خطاپذیری تست‌ها و تسریع در آماده‌سازی خودکارسازی است.
#Android #MobileTesting #UIInspector #OpenSource #QA #TestAutomation #Locators
🟣لینک مقاله:
https://cur.at/O3rNmRU?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
FunnelPeek: A Modern Tool for Exploring Android UI Elements
🟢 خلاصه مقاله:
** معرفی FunnelPeek به‌عنوان یک UI inspector متن‌باز برای Android نشان می‌دهد چطور می‌توان مسیرها و locatorهای پایدار را سریع‌تر پیدا کرد. Saeed Roshan در این ابزار کاوش سلسله‌مراتب نما، برجسته‌سازی عناصر و بررسی ویژگی‌هایی مثل resource ID و content description را نشان می‌دهد تا انتخاب locatorهای قابل اعتماد آسان‌تر شود. نتیجه برای تیم‌های توسعه و QA، کاهش خطاپذیری تست‌ها و تسریع در آماده‌سازی خودکارسازی است.
#Android #MobileTesting #UIInspector #OpenSource #QA #TestAutomation #Locators
🟣لینک مقاله:
https://cur.at/O3rNmRU?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
FunnelPeek: A Modern Tool for Exploring Android UI Elements
Inspecting and analyzing Android UI elements is a common step — whether you’re debugging an interface or automating app usage (for QA…
🔵 عنوان مقاله
Playwright in Practice: Writing Better Tests for Beginners with Page Object Pattern, Fixtures
🟢 خلاصه مقاله:
** این مطلب با یک رویکرد گام‌به‌گام نشان می‌دهد چگونه با تکیه بر ساختاردهی و نگه‌داشت‌پذیری، از Playwright بهترین استفاده را ببریم. Michał Ślęzak با یک نمونه عملی توضیح می‌دهد که چطور از یک تست ساده شروع کنیم و آن را به مجموعه‌ای تمیز و مقیاس‌پذیر تبدیل کنیم.
نویسنده بر Page Object Pattern تأکید می‌کند تا مکان‌یاب‌ها و اعمال صفحه به‌جای پراکندگی در تست‌ها، در آبجکت‌های اختصاصی متمرکز شوند؛ این کار خوانایی را بالا می‌برد، تکرار را کم می‌کند و تغییرات بعدی را ساده‌تر می‌سازد. همچنین نشان می‌دهد چگونه Fixtures می‌تواند آماده‌سازی و پاک‌سازی را استاندارد کند؛ مثلا ایجاد contextهای احراز هویت، داده‌های اولیه، یا پیکربندی مشترک، که نتیجه‌اش تست‌های ایزوله‌تر، سریع‌تر و پایدارتر است.
در پایان، مجموعه‌ای از بهترین‌عمل‌ها مطرح می‌شود: نام‌گذاری و ساختار پوشه‌ها، انتخاب locatorهای پایدار و استراتژی‌های انتظار درست، assertionهای قابل اعتماد، آمادگی برای اجرا در مرورگرهای مختلف و پایداری در CI. حاصل کار، مسیری روشن برای مبتدیان است تا بدون قربانی کردن خوانایی یا سرعت، تدریجاً الگوهای پیشرفته‌تر را وارد فرایند تست خود کنند.
#Playwright #Testing #TestAutomation #PageObjectPattern #Fixtures #QA #EndToEndTesting #BestPractices
🟣لینک مقاله:
https://cur.at/UUnbbtX?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Playwright in Practice: Writing Better Tests for Beginners with Page Object Pattern, Fixtures
🟢 خلاصه مقاله:
** این مطلب با یک رویکرد گام‌به‌گام نشان می‌دهد چگونه با تکیه بر ساختاردهی و نگه‌داشت‌پذیری، از Playwright بهترین استفاده را ببریم. Michał Ślęzak با یک نمونه عملی توضیح می‌دهد که چطور از یک تست ساده شروع کنیم و آن را به مجموعه‌ای تمیز و مقیاس‌پذیر تبدیل کنیم.
نویسنده بر Page Object Pattern تأکید می‌کند تا مکان‌یاب‌ها و اعمال صفحه به‌جای پراکندگی در تست‌ها، در آبجکت‌های اختصاصی متمرکز شوند؛ این کار خوانایی را بالا می‌برد، تکرار را کم می‌کند و تغییرات بعدی را ساده‌تر می‌سازد. همچنین نشان می‌دهد چگونه Fixtures می‌تواند آماده‌سازی و پاک‌سازی را استاندارد کند؛ مثلا ایجاد contextهای احراز هویت، داده‌های اولیه، یا پیکربندی مشترک، که نتیجه‌اش تست‌های ایزوله‌تر، سریع‌تر و پایدارتر است.
در پایان، مجموعه‌ای از بهترین‌عمل‌ها مطرح می‌شود: نام‌گذاری و ساختار پوشه‌ها، انتخاب locatorهای پایدار و استراتژی‌های انتظار درست، assertionهای قابل اعتماد، آمادگی برای اجرا در مرورگرهای مختلف و پایداری در CI. حاصل کار، مسیری روشن برای مبتدیان است تا بدون قربانی کردن خوانایی یا سرعت، تدریجاً الگوهای پیشرفته‌تر را وارد فرایند تست خود کنند.
#Playwright #Testing #TestAutomation #PageObjectPattern #Fixtures #QA #EndToEndTesting #BestPractices
🟣لینک مقاله:
https://cur.at/UUnbbtX?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Your Gateway to Efficient Test Automation
Playwright in Practice: Writing Better Tests for Beginners with Page Object Pattern, Fixtures (TS) - Your Gateway to Efficient…
Learn how to write cleaner, more maintainable Playwright tests with Page Object Pattern, fixtures, and TypeScript. A beginner-friendly refactoring guide.
🔵 عنوان مقاله
LOLMIL: Living Off the Land Models and Inference Libraries (8 minute read)
🟢 خلاصه مقاله:
بدافزارهای مبتنی بر LOLMIL با سوءاستفاده از LLMهای روی دستگاه و inference libraries پیش‌فرض سیستم، بدون تکیه بر زیرساخت خارجی عمل می‌کنند و شناسایی را دشوارتر می‌سازند. پروژه PromptLock از NYU نشان داد یک LLM میزبان‌شده می‌تواند به‌صورت خودگردان عملیات مخرب را برنامه‌ریزی و اجرا کند. نویسنده با الهام از آن، یک ابزار post-exploitation ساخت که از LLM موجود در Microsoft’s Copilot+ PCs استفاده می‌کند تا بدون نیاز به C2 Server و به‌صورت محلی عمل کند. در یک نمونه آزمایشی و کنترل‌شده، با دادن قابلیت‌هایی برای شناسایی، تغییر و راه‌اندازی مجدد سرویس‌های آسیب‌پذیر، LLM توانست دو سرویس را exploit کند. پیامد دفاعی: کاهش تله‌متری شبکه، نیاز به پایش رفتار سرویس‌ها و استفاده از LLM روی دستگاه، اعمال least privilege و سخت‌سازی سرویس‌ها؛ همراه با توجه به ریسک‌های دوکاربردی این فناوری.
#LOLMIL #LLM #Cybersecurity #MalwareResearch #CopilotPlusPCs #AIThreats #PostExploitation #C2
🟣لینک مقاله:
https://dreadnode.io/blog/lolmil-living-off-the-land-models-and-inference-libraries?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
LOLMIL: Living Off the Land Models and Inference Libraries (8 minute read)
🟢 خلاصه مقاله:
بدافزارهای مبتنی بر LOLMIL با سوءاستفاده از LLMهای روی دستگاه و inference libraries پیش‌فرض سیستم، بدون تکیه بر زیرساخت خارجی عمل می‌کنند و شناسایی را دشوارتر می‌سازند. پروژه PromptLock از NYU نشان داد یک LLM میزبان‌شده می‌تواند به‌صورت خودگردان عملیات مخرب را برنامه‌ریزی و اجرا کند. نویسنده با الهام از آن، یک ابزار post-exploitation ساخت که از LLM موجود در Microsoft’s Copilot+ PCs استفاده می‌کند تا بدون نیاز به C2 Server و به‌صورت محلی عمل کند. در یک نمونه آزمایشی و کنترل‌شده، با دادن قابلیت‌هایی برای شناسایی، تغییر و راه‌اندازی مجدد سرویس‌های آسیب‌پذیر، LLM توانست دو سرویس را exploit کند. پیامد دفاعی: کاهش تله‌متری شبکه، نیاز به پایش رفتار سرویس‌ها و استفاده از LLM روی دستگاه، اعمال least privilege و سخت‌سازی سرویس‌ها؛ همراه با توجه به ریسک‌های دوکاربردی این فناوری.
#LOLMIL #LLM #Cybersecurity #MalwareResearch #CopilotPlusPCs #AIThreats #PostExploitation #C2
🟣لینک مقاله:
https://dreadnode.io/blog/lolmil-living-off-the-land-models-and-inference-libraries?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
dreadnode.io
LOLMIL: Living Off the Land Models and Inference Libraries
Can we eliminate the C2 server entirely and create truly autonomous malware? It’s not only possible, but fairly straightforward to implement, as demonstrated in our latest experiment.
🔵 عنوان مقاله
Keeping the Internet fast and secure: introducing Merkle Tree Certificates (12 minute read)
🟢 خلاصه مقاله:
Cloudflare و Chrome در حال آزمایش Merkle Tree Certificates (MTCs) هستند تا با چالش بزرگیِ امضاهای پساکوانتومی مقابله کنند؛ امضاهایی که بسیار بزرگ‌تر از ECDSA هستند (مثلاً ML-DSA-44 حدود ۲۴۲۰ بایت در برابر ۶۴ بایت برای ECDSA-P256). این افزایش اندازه می‌تواند زمان برقراری اتصال در TLS را بالا ببرد و پهنای‌باند بیشتری مصرف کند. MTCs با دسته‌بندی گواهی‌ها در یک درخت Merkle و توزیع خارج‌از‌باند سرآیند امضا‌شدهٔ درخت، داده‌های لازم در هنگام دست‌دهی را به «یک امضا، یک کلید عمومی و یک اثبات شمول Merkle» کاهش می‌دهد؛ در حالی که روش فعلی معمولاً به حدود پنج امضا و دو کلید عمومی نیاز دارد. نتیجه، کاهش پهنای‌باند و عملیات رمزنگاری روی مسیر بحرانی و حفظ سرعت وب در کنار امنیت در دوران پساکوانتومی است. این آزمایش‌ها به‌صورت عملی اثرات کارایی، قابلیت اتکا و شیوهٔ استقرار را می‌سنجند تا مهاجرت به الگوریتم‌های پساکوانتومی مانند ML-DSA بدون افت عملکرد ممکن شود.
#PostQuantum #PQC #TLS #MerkleTreeCertificates #WebPerformance #WebSecurity #Cloudflare #Chrome
🟣لینک مقاله:
https://blog.cloudflare.com/bootstrap-mtc/?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Keeping the Internet fast and secure: introducing Merkle Tree Certificates (12 minute read)
🟢 خلاصه مقاله:
Cloudflare و Chrome در حال آزمایش Merkle Tree Certificates (MTCs) هستند تا با چالش بزرگیِ امضاهای پساکوانتومی مقابله کنند؛ امضاهایی که بسیار بزرگ‌تر از ECDSA هستند (مثلاً ML-DSA-44 حدود ۲۴۲۰ بایت در برابر ۶۴ بایت برای ECDSA-P256). این افزایش اندازه می‌تواند زمان برقراری اتصال در TLS را بالا ببرد و پهنای‌باند بیشتری مصرف کند. MTCs با دسته‌بندی گواهی‌ها در یک درخت Merkle و توزیع خارج‌از‌باند سرآیند امضا‌شدهٔ درخت، داده‌های لازم در هنگام دست‌دهی را به «یک امضا، یک کلید عمومی و یک اثبات شمول Merkle» کاهش می‌دهد؛ در حالی که روش فعلی معمولاً به حدود پنج امضا و دو کلید عمومی نیاز دارد. نتیجه، کاهش پهنای‌باند و عملیات رمزنگاری روی مسیر بحرانی و حفظ سرعت وب در کنار امنیت در دوران پساکوانتومی است. این آزمایش‌ها به‌صورت عملی اثرات کارایی، قابلیت اتکا و شیوهٔ استقرار را می‌سنجند تا مهاجرت به الگوریتم‌های پساکوانتومی مانند ML-DSA بدون افت عملکرد ممکن شود.
#PostQuantum #PQC #TLS #MerkleTreeCertificates #WebPerformance #WebSecurity #Cloudflare #Chrome
🟣لینک مقاله:
https://blog.cloudflare.com/bootstrap-mtc/?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
The Cloudflare Blog
Keeping the Internet fast and secure- introducing Merkle Tree Certificates
Cloudflare is launching an experiment with Chrome to evaluate fast, scalable, and quantum-ready Merkle Tree Certificates, all without degrading performance or changing WebPKI trust relationships.
❤1
🔵 عنوان مقاله
Streamlining Vulnerability Research with the idalib Rust Bindings for IDA 9.2 (5 minute read)
🟢 خلاصه مقاله:
** این پست سه افزونه مبتنی بر Rust برای IDA Pro 9.2 را معرفی می‌کند که با تکیه بر idalib از Binarly مراحل رایج در پژوهش آسیب‌پذیری را خودکار می‌کنند. rhabdomancer فراخوانی‌های بالقوه ناامنِ API را شناسایی و بر اساس شدت اولویت‌بندی می‌کند؛ haruspex شبه‌کدِ دیکامپایل‌شده را برای ابزارهای تحلیل ایستا مثل Semgrep استخراج می‌کند؛ و augur کد مرتبط با رشته‌ها را سازمان‌دهی می‌کند تا نقاط حساس برای تحلیل سریع‌تر مشخص شوند. هر سه ابزار به‌صورت headless اجرا می‌شوند، برای پردازش دسته‌ای و ادغام در CI مناسب‌اند، و با تمرکز بر مقیاس و اتوماسیون، تحلیل سریع و خروجی‌های قابل استفاده در زنجیره ابزارها را فراهم می‌کنند.
#IDAPro #Rust #ReverseEngineering #VulnerabilityResearch #Binarly #idalib #Semgrep #StaticAnalysis
🟣لینک مقاله:
https://hnsecurity.it/blog/streamlining-vulnerability-research-with-the-idalib-rust-bindings-for-ida-9-2/?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Streamlining Vulnerability Research with the idalib Rust Bindings for IDA 9.2 (5 minute read)
🟢 خلاصه مقاله:
** این پست سه افزونه مبتنی بر Rust برای IDA Pro 9.2 را معرفی می‌کند که با تکیه بر idalib از Binarly مراحل رایج در پژوهش آسیب‌پذیری را خودکار می‌کنند. rhabdomancer فراخوانی‌های بالقوه ناامنِ API را شناسایی و بر اساس شدت اولویت‌بندی می‌کند؛ haruspex شبه‌کدِ دیکامپایل‌شده را برای ابزارهای تحلیل ایستا مثل Semgrep استخراج می‌کند؛ و augur کد مرتبط با رشته‌ها را سازمان‌دهی می‌کند تا نقاط حساس برای تحلیل سریع‌تر مشخص شوند. هر سه ابزار به‌صورت headless اجرا می‌شوند، برای پردازش دسته‌ای و ادغام در CI مناسب‌اند، و با تمرکز بر مقیاس و اتوماسیون، تحلیل سریع و خروجی‌های قابل استفاده در زنجیره ابزارها را فراهم می‌کنند.
#IDAPro #Rust #ReverseEngineering #VulnerabilityResearch #Binarly #idalib #Semgrep #StaticAnalysis
🟣لینک مقاله:
https://hnsecurity.it/blog/streamlining-vulnerability-research-with-the-idalib-rust-bindings-for-ida-9-2/?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
HN Security
Streamlining Vulnerability Research with the idalib Rust Bindings for IDA 9.2 - HN Security
HN Security's Technical Director Marco Ivaldi walks through using idalib's Rust bindings with IDA 9.2 to streamline vulnerability research.
🔵 عنوان مقاله
The Day I Stopped Trusting My Load Tests (And Started Simulating Chaos Instead)
🟢 خلاصه مقاله:
**هری‌پراساث V S توضیح می‌دهد چرا به تست‌های بار سنتی که بر میانگین‌ها و سناریوهای قابل پیش‌بینی تکیه می‌کنند اعتماد نکرد و چگونه با به‌کارگیری روش Monte Carlo رفتارهای غیرقابل‌پیش‌بینی کاربران و رخدادهای دمِ‌سنگین را آشکار کرد. با مدل‌کردن عدم‌قطعیت‌ها به‌صورت توزیع‌های احتمالی و اجرای هزاران سناریوی تصادفی، آن‌ها توانستند احتمال ازدست‌رفتن SLO، تشکیل صف‌ها، و بروز جهش‌های تاخیری در p99+ را بسنجند؛ ریسک‌هایی که در تست‌های عادی پنهان می‌مانند، مثل هجوم هم‌زمان retryها، داغ‌شدن پارتیشن‌ها و اسپایک‌های نادر اما مخرب. سپس با تزریق آشوب (خرابی گره، packet loss، timeout، وقفه GC و اختلالات جزئی وابستگی‌ها) دیدند خطاها چگونه در معماری پخش می‌شود و بر این اساس به الگوهای انعطاف‌پذیرتر مانند retry با jitter و سقف، timeoutهای بودجه‌محور، circuit breaker، backpressure، load shedding و طراحی‌های idempotent روی آوردند. نتیجه، گذار از «تست قبولی/ردی» به ارزیابی احتمالاتی ریسک است که در CI/CD، برنامه‌ریزی ظرفیت و اولویت‌بندی بهبودهای تاب‌آوری به کار گرفته می‌شود.
#LoadTesting #ChaosEngineering #MonteCarlo #Reliability #Resilience #PerformanceEngineering #SRE #Scalability
🟣لینک مقاله:
https://cur.at/f4RKFUM?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
The Day I Stopped Trusting My Load Tests (And Started Simulating Chaos Instead)
🟢 خلاصه مقاله:
**هری‌پراساث V S توضیح می‌دهد چرا به تست‌های بار سنتی که بر میانگین‌ها و سناریوهای قابل پیش‌بینی تکیه می‌کنند اعتماد نکرد و چگونه با به‌کارگیری روش Monte Carlo رفتارهای غیرقابل‌پیش‌بینی کاربران و رخدادهای دمِ‌سنگین را آشکار کرد. با مدل‌کردن عدم‌قطعیت‌ها به‌صورت توزیع‌های احتمالی و اجرای هزاران سناریوی تصادفی، آن‌ها توانستند احتمال ازدست‌رفتن SLO، تشکیل صف‌ها، و بروز جهش‌های تاخیری در p99+ را بسنجند؛ ریسک‌هایی که در تست‌های عادی پنهان می‌مانند، مثل هجوم هم‌زمان retryها، داغ‌شدن پارتیشن‌ها و اسپایک‌های نادر اما مخرب. سپس با تزریق آشوب (خرابی گره، packet loss، timeout، وقفه GC و اختلالات جزئی وابستگی‌ها) دیدند خطاها چگونه در معماری پخش می‌شود و بر این اساس به الگوهای انعطاف‌پذیرتر مانند retry با jitter و سقف، timeoutهای بودجه‌محور، circuit breaker، backpressure، load shedding و طراحی‌های idempotent روی آوردند. نتیجه، گذار از «تست قبولی/ردی» به ارزیابی احتمالاتی ریسک است که در CI/CD، برنامه‌ریزی ظرفیت و اولویت‌بندی بهبودهای تاب‌آوری به کار گرفته می‌شود.
#LoadTesting #ChaosEngineering #MonteCarlo #Reliability #Resilience #PerformanceEngineering #SRE #Scalability
🟣لینک مقاله:
https://cur.at/f4RKFUM?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
The Day I Stopped Trusting My Load Tests (And Started Simulating Chaos Instead)
Or: How Monte Carlo Simulation Saved me
🔵 عنوان مقاله
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?
🔵 عنوان مقاله
I Integrated AI in a Listener to Heal Locators in The Real Time
🟢 خلاصه مقاله:
عبدالقادر حسینی نشان می‌دهد چگونه می‌توان با ادغام AI در یک listener، مشکل ناپایداری تست‌های موبایل را با «خودترمیمی لوکیتورها» در لحظه کاهش داد. وقتی یافتن یک المنت به‌دلیل تغییرات UI شکست می‌خورد، listener خطا را رهگیری می‌کند، ماژول AI بر اساس سیگنال‌های مختلف (ویژگی‌ها، برچسب‌های دسترسی، شباهت متنی، ساختار صفحه و داده‌های تاریخی) یک لوکیتور جایگزین با امتیاز اطمینان پیشنهاد می‌دهد و در صورت موفقیت، آن را به‌صورت خودکار به‌روزرسانی می‌کند. با اعمال آستانه اطمینان، لاگ شفاف و امکان بازگشت، این روش بدون افزایش ریسک، پایداری CI را بالا می‌برد و هزینه نگهداری تست‌ها را کم می‌کند. الگوی ارائه‌شده قابل تعمیم به فراتر از موبایل است و پیشنهاد می‌شود ابتدا در حالت فقط-پیشنهاد اجرا، سپس با تنظیم آستانه‌ها، به حالت خودترمیمی خودکار برای موارد با اطمینان بالا منتقل شود.
#AI #TestAutomation #MobileTesting #SelfHealingLocators #FlakyTests #QualityEngineering #DevOps #CICD
🟣لینک مقاله:
https://cur.at/s6YdwTw?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
I Integrated AI in a Listener to Heal Locators in The Real Time
🟢 خلاصه مقاله:
عبدالقادر حسینی نشان می‌دهد چگونه می‌توان با ادغام AI در یک listener، مشکل ناپایداری تست‌های موبایل را با «خودترمیمی لوکیتورها» در لحظه کاهش داد. وقتی یافتن یک المنت به‌دلیل تغییرات UI شکست می‌خورد، listener خطا را رهگیری می‌کند، ماژول AI بر اساس سیگنال‌های مختلف (ویژگی‌ها، برچسب‌های دسترسی، شباهت متنی، ساختار صفحه و داده‌های تاریخی) یک لوکیتور جایگزین با امتیاز اطمینان پیشنهاد می‌دهد و در صورت موفقیت، آن را به‌صورت خودکار به‌روزرسانی می‌کند. با اعمال آستانه اطمینان، لاگ شفاف و امکان بازگشت، این روش بدون افزایش ریسک، پایداری CI را بالا می‌برد و هزینه نگهداری تست‌ها را کم می‌کند. الگوی ارائه‌شده قابل تعمیم به فراتر از موبایل است و پیشنهاد می‌شود ابتدا در حالت فقط-پیشنهاد اجرا، سپس با تنظیم آستانه‌ها، به حالت خودترمیمی خودکار برای موارد با اطمینان بالا منتقل شود.
#AI #TestAutomation #MobileTesting #SelfHealingLocators #FlakyTests #QualityEngineering #DevOps #CICD
🟣لینک مقاله:
https://cur.at/s6YdwTw?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
I Integrated AI in a Listener to Heal Locators in The Real Time
A Self-Healing Robot Framework Listener That Prevents Tests From Failing Due Locator Update
Rust vs. Python: Finding the right balance between speed and simplicity
https://blog.jetbrains.com/rust/2025/11/10/rust-vs-python-finding-the-right-balance-between-speed-and-simplicity/
https://blog.jetbrains.com/rust/2025/11/10/rust-vs-python-finding-the-right-balance-between-speed-and-simplicity/
The JetBrains Blog
Rust vs. Python: Finding the right balance between speed and simplicity | The RustRover Blog
Compare Rust and Python across performance, usability, tooling, and ecosystem. Learn which language is best for your next project.
🔵 عنوان مقاله
Determinism is Overrated
🟢 خلاصه مقاله:
Determinism is Overrated یادآور می‌شود که توسعه و آزمون اپلیکیشن‌های AI با نرم‌افزارهای سنتی فرق دارد، چون خروجی‌ها ذاتاً غیردترمینستیک‌اند. به‌جای تکیه بر تطابق دقیق رشته‌ای، باید کیفیت را در سطح توزیع نتایج سنجید: تعریف بازه‌های پذیرش، روبریک‌ها و امتیازدهی سازگار با هدف کاربر، و آزمون‌های سناریومحور. Jarad DeLorenzo پیشنهاد می‌کند در کنار تست‌های کاملاً دترمینستیک برای منطق اطراف مدل، از ابزارهای بازتولیدپذیری (نسخه‌بندی داده/پرومپت/مدل، ثبت seed و پارامترها) و ارزیابی احتمالاتی (آستانه‌های شباهت، top-k، چند seed) استفاده شود. در استقرار نیز A/B testing، canary، گاردریل‌ها، fallback و observability برای هزینه، تأخیر، درستی و ایمنی لازم است. پیام اصلی: به‌جای اجبار به خروجی‌های یکسان، برای نتایج قابل اتکا در دل تغییرپذیری طراحی کنید.
#AI #LLM #NonDeterminism #Testing #Evaluation #MLOps #AIBestPractices #SoftwareEngineering
🟣لینک مقاله:
https://cur.at/sfc6P6g?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Determinism is Overrated
🟢 خلاصه مقاله:
Determinism is Overrated یادآور می‌شود که توسعه و آزمون اپلیکیشن‌های AI با نرم‌افزارهای سنتی فرق دارد، چون خروجی‌ها ذاتاً غیردترمینستیک‌اند. به‌جای تکیه بر تطابق دقیق رشته‌ای، باید کیفیت را در سطح توزیع نتایج سنجید: تعریف بازه‌های پذیرش، روبریک‌ها و امتیازدهی سازگار با هدف کاربر، و آزمون‌های سناریومحور. Jarad DeLorenzo پیشنهاد می‌کند در کنار تست‌های کاملاً دترمینستیک برای منطق اطراف مدل، از ابزارهای بازتولیدپذیری (نسخه‌بندی داده/پرومپت/مدل، ثبت seed و پارامترها) و ارزیابی احتمالاتی (آستانه‌های شباهت، top-k، چند seed) استفاده شود. در استقرار نیز A/B testing، canary، گاردریل‌ها، fallback و observability برای هزینه، تأخیر، درستی و ایمنی لازم است. پیام اصلی: به‌جای اجبار به خروجی‌های یکسان، برای نتایج قابل اتکا در دل تغییرپذیری طراحی کنید.
#AI #LLM #NonDeterminism #Testing #Evaluation #MLOps #AIBestPractices #SoftwareEngineering
🟣لینک مقاله:
https://cur.at/sfc6P6g?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
Determinism is Overrated
Why Your Best Engineers Can’t Build AI Systems
🔵 عنوان مقاله
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.
🔵 عنوان مقاله
If It's Not Written Down, Did You Really Test It?
🟢 خلاصه مقاله:
اگر چیزی ثبت نشود، اثبات‌پذیری و تکرارپذیری تست زیر سوال می‌رود. Marina Jordão هشدار می‌دهد حذف «مدیریت تست» شاید کار را سریع‌تر نشان دهد، اما در عمل به افزایش ریسک، خطاهای تکراری، پوشش ناقص سناریوها و کاهش اعتماد ذی‌نفعان به QA منجر می‌شود. راه‌حل او، افزودن ساختارِ سبک و مؤثر است: یک استراتژی حداقلی برای محدوده و ریسک‌ها، ردیابی تست‌ها به نیازمندی‌ها، چک‌لیست یا چارتر برای تست اکتشافی همراه با یادداشت‌های خلاصه و شواهد، استانداردسازی شدت/اولویت، و استفاده از ابزارهای یکپارچه با CI/CD. با قرار دادن مستندسازی در Definition of Done و بهبود مستمر مبتنی بر داده، تیم‌ها بدون بروکراسی سنگین، کیفیت شفاف و پایدار را حفظ می‌کنند.
#QA
#TestManagement
#مستندسازی
#آزمایش_نرم‌افزار
#کیفیت_نرم‌افزار
#توسعه_چابک
#DevOps
🟣لینک مقاله:
https://cur.at/QQmdklz?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
If It's Not Written Down, Did You Really Test It?
🟢 خلاصه مقاله:
اگر چیزی ثبت نشود، اثبات‌پذیری و تکرارپذیری تست زیر سوال می‌رود. Marina Jordão هشدار می‌دهد حذف «مدیریت تست» شاید کار را سریع‌تر نشان دهد، اما در عمل به افزایش ریسک، خطاهای تکراری، پوشش ناقص سناریوها و کاهش اعتماد ذی‌نفعان به QA منجر می‌شود. راه‌حل او، افزودن ساختارِ سبک و مؤثر است: یک استراتژی حداقلی برای محدوده و ریسک‌ها، ردیابی تست‌ها به نیازمندی‌ها، چک‌لیست یا چارتر برای تست اکتشافی همراه با یادداشت‌های خلاصه و شواهد، استانداردسازی شدت/اولویت، و استفاده از ابزارهای یکپارچه با CI/CD. با قرار دادن مستندسازی در Definition of Done و بهبود مستمر مبتنی بر داده، تیم‌ها بدون بروکراسی سنگین، کیفیت شفاف و پایدار را حفظ می‌کنند.
#QA
#TestManagement
#مستندسازی
#آزمایش_نرم‌افزار
#کیفیت_نرم‌افزار
#توسعه_چابک
#DevOps
🟣لینک مقاله:
https://cur.at/QQmdklz?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
If It’s Not Written Down, Did You Really Test It?
In the rush of agile development, I’ve seen many teams skip over what some might call “formal QA practices.” No test plans, no test…
🔵 عنوان مقاله
Building a Solid Foundation for Performance Testing
🟢 خلاصه مقاله:
این یادداشت توضیح می‌دهد که پیش از اجرای هر نوع تست کارایی، باید زیرساخت فکری و عملی درستی بسازیم تا نتایج قابل اتکا باشند. به گفته‌ی Yanming Zhai، گام‌های کلیدی مستقل از ابزارند: هدف‌ها و معیارهای موفقیت را مشخص کنید (مثل پرسن‌تایل‌های زمان پاسخ، توان عملیاتی، نرخ خطا، و SLA/SLO)، سناریوهای کاربری مهم و الگوهای بار واقعی را تعریف کنید، معماری و وابستگی‌ها را بشناسید و محیطی نزدیک به تولید بسازید. داده‌ی تست واقعی آماده کنید، وضعیت کش و گرم‌کردن را کنترل کنید، و پارامترهای اجرای تست مثل ramp-up، مدت پایدار و think time را دقیق تعیین کنید.
رصدپذیری را جدی بگیرید: متریک‌ها، لاگ‌ها و تِرِیس‌ها را انتهابه‌انتها جمع‌آوری کنید؛ منابع زیرساخت، سرویس‌های خارجی و شبکه را زیر نظر داشته باشید؛ نسخه‌ها و تنظیمات را ثبت کنید تا آزمون‌ها قابل تکرار باشند. اسکریپت‌های پایدار بنویسید: احراز هویت و نشست را درست مدیریت کنید، پارامتری‌سازی و correlation انجام دهید، رفتار کاربر را واقع‌نما کنید و مطمئن شوید گلوگاه سمت کلاینت یا شبکه نیست. پیش‌اجرای سبک و بازبینی همتایان خطاهای پنهان را کم می‌کند.
در نهایت، تست کارایی یک فعالیت تیمی است: با تیم‌های توسعه، SRE/ops و محصول هم‌راستا شوید، در صورت نیاز در CI/CD ادغام کنید، و گزارش‌دهی شفاف داشته باشید؛ نتایج را نسبت به baseline و SLO بسنجید و آن‌ها را به اقدام‌های مشخص برای بهینه‌سازی و ظرفیت تبدیل کنید. با رعایت این اصول، انتخاب هر ابزاری نتیجه‌های سریع‌تر و قابل اعتمادتر به‌همراه دارد.
#تست_کارایی #تست_بار #مهندسی_عملکرد #DevOps #Observability #SLA #کیفیت_نرم‌افزار #PerformanceTesting
🟣لینک مقاله:
https://cur.at/ybKggdo?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Building a Solid Foundation for Performance Testing
🟢 خلاصه مقاله:
این یادداشت توضیح می‌دهد که پیش از اجرای هر نوع تست کارایی، باید زیرساخت فکری و عملی درستی بسازیم تا نتایج قابل اتکا باشند. به گفته‌ی Yanming Zhai، گام‌های کلیدی مستقل از ابزارند: هدف‌ها و معیارهای موفقیت را مشخص کنید (مثل پرسن‌تایل‌های زمان پاسخ، توان عملیاتی، نرخ خطا، و SLA/SLO)، سناریوهای کاربری مهم و الگوهای بار واقعی را تعریف کنید، معماری و وابستگی‌ها را بشناسید و محیطی نزدیک به تولید بسازید. داده‌ی تست واقعی آماده کنید، وضعیت کش و گرم‌کردن را کنترل کنید، و پارامترهای اجرای تست مثل ramp-up، مدت پایدار و think time را دقیق تعیین کنید.
رصدپذیری را جدی بگیرید: متریک‌ها، لاگ‌ها و تِرِیس‌ها را انتهابه‌انتها جمع‌آوری کنید؛ منابع زیرساخت، سرویس‌های خارجی و شبکه را زیر نظر داشته باشید؛ نسخه‌ها و تنظیمات را ثبت کنید تا آزمون‌ها قابل تکرار باشند. اسکریپت‌های پایدار بنویسید: احراز هویت و نشست را درست مدیریت کنید، پارامتری‌سازی و correlation انجام دهید، رفتار کاربر را واقع‌نما کنید و مطمئن شوید گلوگاه سمت کلاینت یا شبکه نیست. پیش‌اجرای سبک و بازبینی همتایان خطاهای پنهان را کم می‌کند.
در نهایت، تست کارایی یک فعالیت تیمی است: با تیم‌های توسعه، SRE/ops و محصول هم‌راستا شوید، در صورت نیاز در CI/CD ادغام کنید، و گزارش‌دهی شفاف داشته باشید؛ نتایج را نسبت به baseline و SLO بسنجید و آن‌ها را به اقدام‌های مشخص برای بهینه‌سازی و ظرفیت تبدیل کنید. با رعایت این اصول، انتخاب هر ابزاری نتیجه‌های سریع‌تر و قابل اعتمادتر به‌همراه دارد.
#تست_کارایی #تست_بار #مهندسی_عملکرد #DevOps #Observability #SLA #کیفیت_نرم‌افزار #PerformanceTesting
🟣لینک مقاله:
https://cur.at/ybKggdo?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
The Map Before the Battle: Building a Solid Foundation for Performance Testing
Part I · Theory
🔵 عنوان مقاله
Analysing ClickFix: 3 Reasons Why Copy/Paste Attacks Are Driving Security Breaches (7 minute read)
🟢 خلاصه مقاله:
حملات ClickFix با سوءاستفاده از تعامل‌های عادی مرورگر، کاربر را با یک CAPTCHA جعلی فریب می‌دهند تا متنی را کپی کرده و در ترمینال یا Command Prompt دستگاه خود Paste کند؛ دستوری که سپس محلی اجرا می‌شود و بسیاری از کنترل‌های سنتی را دور می‌زند. این کمپین‌ها عمدتاً از طریق SEO poisoning و malvertising پخش می‌شوند، نه ایمیل، و با صفحات ظاهراً معتبر کاربر را به انجام مراحل ترغیب می‌کنند.
موفقیت این حملات بر سه ضعف اصلی تکیه دارد: ۱) آگاهی ناکافی کاربران؛ آموزش‌ها معمولاً درباره لینک و فایل آلوده است، نه خطرات Copy/Paste از مرورگر به شِل. ۲) گریز از شناسایی؛ چون تحویل از مسیر ایمیل نیست و «Payload» یک متن به‌شدت مبهم‌سازی‌شده است که با Clipboard جابه‌جا می‌شود، دروازه‌های ایمیلی و بسیاری از Web Proxyها کارایی کمی دارند. ۳) محدودیت‌های EDR؛ اجرای فرمان‌های مخرب توسط مفسرهای معتبر و در زمینه کاربر مورداعتماد، آن هم کوتاه‌عمر و مبهم‌سازی‌شده، دید و تله‌متری دفاع‌های نقطه پایانی را کاهش می‌دهد.
نتیجه اینکه کپی/پیست نیز باید به‌عنوان یک کانال غیرقابل‌اعتماد دیده شود. کاهش ریسک مستلزم آموزش بهتر کاربران درباره تهدیدهای Copy/Paste، سخت‌گیری روی سیاست‌های اجرای شِل/اسکریپت و پایش الگوهای مشکوک Clipboard-to-Shell است، در کنار اقداماتی برای کاهش مواجهه با SEO poisoning و malvertising.
#ClickFix #CopyPasteAttack #SocialEngineering #SEOpoisoning #Malvertising #EDR #CyberSecurity #AwarenessTraining
🟣لینک مقاله:
https://thehackernews.com/2025/10/analysing-clickfix-3-reasons-why.html?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Analysing ClickFix: 3 Reasons Why Copy/Paste Attacks Are Driving Security Breaches (7 minute read)
🟢 خلاصه مقاله:
حملات ClickFix با سوءاستفاده از تعامل‌های عادی مرورگر، کاربر را با یک CAPTCHA جعلی فریب می‌دهند تا متنی را کپی کرده و در ترمینال یا Command Prompt دستگاه خود Paste کند؛ دستوری که سپس محلی اجرا می‌شود و بسیاری از کنترل‌های سنتی را دور می‌زند. این کمپین‌ها عمدتاً از طریق SEO poisoning و malvertising پخش می‌شوند، نه ایمیل، و با صفحات ظاهراً معتبر کاربر را به انجام مراحل ترغیب می‌کنند.
موفقیت این حملات بر سه ضعف اصلی تکیه دارد: ۱) آگاهی ناکافی کاربران؛ آموزش‌ها معمولاً درباره لینک و فایل آلوده است، نه خطرات Copy/Paste از مرورگر به شِل. ۲) گریز از شناسایی؛ چون تحویل از مسیر ایمیل نیست و «Payload» یک متن به‌شدت مبهم‌سازی‌شده است که با Clipboard جابه‌جا می‌شود، دروازه‌های ایمیلی و بسیاری از Web Proxyها کارایی کمی دارند. ۳) محدودیت‌های EDR؛ اجرای فرمان‌های مخرب توسط مفسرهای معتبر و در زمینه کاربر مورداعتماد، آن هم کوتاه‌عمر و مبهم‌سازی‌شده، دید و تله‌متری دفاع‌های نقطه پایانی را کاهش می‌دهد.
نتیجه اینکه کپی/پیست نیز باید به‌عنوان یک کانال غیرقابل‌اعتماد دیده شود. کاهش ریسک مستلزم آموزش بهتر کاربران درباره تهدیدهای Copy/Paste، سخت‌گیری روی سیاست‌های اجرای شِل/اسکریپت و پایش الگوهای مشکوک Clipboard-to-Shell است، در کنار اقداماتی برای کاهش مواجهه با SEO poisoning و malvertising.
#ClickFix #CopyPasteAttack #SocialEngineering #SEOpoisoning #Malvertising #EDR #CyberSecurity #AwarenessTraining
🟣لینک مقاله:
https://thehackernews.com/2025/10/analysing-clickfix-3-reasons-why.html?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
🔵 عنوان مقاله
Developing the Right Test Documentation
🟢 خلاصه مقاله:
مستندسازی تست کار جذابی نیست، اما اگر با نگاه به هدف و مخاطب انجام شود، به تصمیم‌گیری و هم‌راستاسازی تیم کمک جدی می‌کند. توصیه‌های Chris Kenst بر مستندات سبک، زنده و متصل به کار روزمره تأکید دارد: تولید حداقل آثار مؤثر مثل چک‌لیست، چارتر، نقشه پوشش و فهرست ریسک‌ها؛ پیوند دادن آن‌ها با استراتژی تست، ریسک و نتایج CI؛ خودکارسازی جمع‌آوری شواهد؛ و بازبینی و هرس مداوم برای حذف زوائد. در محیط‌های مقرراتی، فقط لایه‌های لازم مثل نسخه‌بندی، تأییدها و حداقل ماتریس رهگیری را اضافه کنید، بدون قربانی کردن شفافیت. معیار موفقیت ساده است: آیا مستندات باعث کاهش پرسش‌های تکراری، تسریع عیب‌یابی و تسهیل آنبوردینگ می‌شود یا نه.
#تست_نرم‌افزار #مستندسازی #کیفیت_نرم‌افزار #QA #توسعه_نرم‌افزار #مدیریت_ریسک #Agile #DevOps
🟣لینک مقاله:
https://cur.at/JfTbdWG?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Developing the Right Test Documentation
🟢 خلاصه مقاله:
مستندسازی تست کار جذابی نیست، اما اگر با نگاه به هدف و مخاطب انجام شود، به تصمیم‌گیری و هم‌راستاسازی تیم کمک جدی می‌کند. توصیه‌های Chris Kenst بر مستندات سبک، زنده و متصل به کار روزمره تأکید دارد: تولید حداقل آثار مؤثر مثل چک‌لیست، چارتر، نقشه پوشش و فهرست ریسک‌ها؛ پیوند دادن آن‌ها با استراتژی تست، ریسک و نتایج CI؛ خودکارسازی جمع‌آوری شواهد؛ و بازبینی و هرس مداوم برای حذف زوائد. در محیط‌های مقرراتی، فقط لایه‌های لازم مثل نسخه‌بندی، تأییدها و حداقل ماتریس رهگیری را اضافه کنید، بدون قربانی کردن شفافیت. معیار موفقیت ساده است: آیا مستندات باعث کاهش پرسش‌های تکراری، تسریع عیب‌یابی و تسهیل آنبوردینگ می‌شود یا نه.
#تست_نرم‌افزار #مستندسازی #کیفیت_نرم‌افزار #QA #توسعه_نرم‌افزار #مدیریت_ریسک #Agile #DevOps
🟣لینک مقاله:
https://cur.at/JfTbdWG?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Shattered Illusions by Chris Kenst
Developing the Right Test Documentation
The right test documentation is the one that satisfies the goal for the right audience and at the right cost. More often that not it means focusing on the smallest amount of documentation you need to do your job well.
🔵 عنوان مقاله
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
🔵 عنوان مقاله
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
🔵 عنوان مقاله
Hackers could've drained millions from Shopify rival (3 minute read)
🟢 خلاصه مقاله:
این گزارش می‌گوید پلتفرم تجارت الکترونیک Dukaan در هند بیش از دو سال یک Apache Kafka ناایمن را در دسترس عموم گذاشته بود و در نتیجه توکن‌های احراز هویت درگاه‌های پرداخت برای Stripe، PayPal و RazorPay همراه با اطلاعات مشتریانِ مربوط به ۳.۵ میلیون تاجر افشا شده است. این افشا می‌توانست به مهاجمان امکان دهد با جا زدن خود به جای فروشندگان و فراخوانی APIهای پرداخت، تراکنش‌های غیرمجاز انجام دهند، بازپرداخت‌ها را منحرف کنند یا پرداخت‌ها را به حساب‌های خودشان هدایت کنند و بالقوه صدها میلیون دلار از حساب‌های تجار به سرقت ببرند. این رخداد ریسک بزرگ پیکربندی‌های نادرست در زنجیره داده را یادآور می‌شود و بر ضرورت کنترل دسترسی سخت‌گیرانه، رمزنگاری، ایزوله‌سازی شبکه و مدیریت امن اسرار و چرخش سریع توکن‌ها تأکید دارد.
#CyberSecurity #DataLeak #Ecommerce #ApacheKafka #Dukaan #Stripe #PayPal #RazorPay
🟣لینک مقاله:
https://cybernews.com/security/dukaan-ecommerce-data-leak-india/?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Hackers could've drained millions from Shopify rival (3 minute read)
🟢 خلاصه مقاله:
این گزارش می‌گوید پلتفرم تجارت الکترونیک Dukaan در هند بیش از دو سال یک Apache Kafka ناایمن را در دسترس عموم گذاشته بود و در نتیجه توکن‌های احراز هویت درگاه‌های پرداخت برای Stripe، PayPal و RazorPay همراه با اطلاعات مشتریانِ مربوط به ۳.۵ میلیون تاجر افشا شده است. این افشا می‌توانست به مهاجمان امکان دهد با جا زدن خود به جای فروشندگان و فراخوانی APIهای پرداخت، تراکنش‌های غیرمجاز انجام دهند، بازپرداخت‌ها را منحرف کنند یا پرداخت‌ها را به حساب‌های خودشان هدایت کنند و بالقوه صدها میلیون دلار از حساب‌های تجار به سرقت ببرند. این رخداد ریسک بزرگ پیکربندی‌های نادرست در زنجیره داده را یادآور می‌شود و بر ضرورت کنترل دسترسی سخت‌گیرانه، رمزنگاری، ایزوله‌سازی شبکه و مدیریت امن اسرار و چرخش سریع توکن‌ها تأکید دارد.
#CyberSecurity #DataLeak #Ecommerce #ApacheKafka #Dukaan #Stripe #PayPal #RazorPay
🟣لینک مقاله:
https://cybernews.com/security/dukaan-ecommerce-data-leak-india/?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Cybernews
This million-dollar leak from a Shopify rival went unnoticed for 2 years
Shopify rival Dukaan exposed server leaked customer data and payment account tokens, leaving millions across India vulnerable to financial abuse.
🔵 عنوان مقاله
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
🔵 عنوان مقاله
Running Lighthouse CI in a Lightweight Docker Container
🟢 خلاصه مقاله:
**این مطلب نشان می‌دهد چگونه می‌توان Lighthouse CI را در یک Docker کانتینر سبک اجرا کرد تا سنجش عملکرد وب‌اپ‌ها به‌صورت خودکار و قابل‌اتکا در CI انجام شود. ایده اصلی، ساخت یک ایمیج کوچک (مثلاً بر پایه Alpine + Node) با CLI مربوط به Lighthouse CI و یک Chromium هدلس است تا روی GitHub Actions، GitLab CI، یا CircleCI کاملاً یکسان عمل کند و زمان راه‌اندازی و هزینه‌های CI را پایین نگه دارد. در خط لوله، پس از build و serve کردن برنامه (یا هدف‌گیری یک URL مستقر)، کانتینر اجرا می‌شود، معیارهایی مانند LCP، CLS و TBT را استخراج می‌کند، گزارش‌های HTML/JSON تولید می‌کند، و با baseline و بودجه‌های عملکردی مقایسه می‌کند تا در صورت عقب‌گرد یا عبور از آستانه‌ها، build را fail کند. برای پایداری نتایج، باید شبکه و CPU را شبیه‌سازی (throttle) کرد، cacheها را بین اجراها نگه داشت، به‌صورت non-root اجرا شد و تنها در صورت نیاز از پرچم‌هایی مثل no-sandbox استفاده کرد. این چیدمان به‌راحتی در PRها برای gate کردن mergeها و نیز در اجرای شبانه روی محیط production قابل استفاده است و در نهایت یک سازوکار سبک، تکرارپذیر و کم‌هزینه برای کنترل دائمی عملکرد ارائه می‌دهد.
#Lighthouse #LighthouseCI #Docker #WebPerformance #CI #DevOps #PerformanceBudgets #ContinuousIntegration
🟣لینک مقاله:
https://cur.at/ghYEsiF?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Running Lighthouse CI in a Lightweight Docker Container
🟢 خلاصه مقاله:
**این مطلب نشان می‌دهد چگونه می‌توان Lighthouse CI را در یک Docker کانتینر سبک اجرا کرد تا سنجش عملکرد وب‌اپ‌ها به‌صورت خودکار و قابل‌اتکا در CI انجام شود. ایده اصلی، ساخت یک ایمیج کوچک (مثلاً بر پایه Alpine + Node) با CLI مربوط به Lighthouse CI و یک Chromium هدلس است تا روی GitHub Actions، GitLab CI، یا CircleCI کاملاً یکسان عمل کند و زمان راه‌اندازی و هزینه‌های CI را پایین نگه دارد. در خط لوله، پس از build و serve کردن برنامه (یا هدف‌گیری یک URL مستقر)، کانتینر اجرا می‌شود، معیارهایی مانند LCP، CLS و TBT را استخراج می‌کند، گزارش‌های HTML/JSON تولید می‌کند، و با baseline و بودجه‌های عملکردی مقایسه می‌کند تا در صورت عقب‌گرد یا عبور از آستانه‌ها، build را fail کند. برای پایداری نتایج، باید شبکه و CPU را شبیه‌سازی (throttle) کرد، cacheها را بین اجراها نگه داشت، به‌صورت non-root اجرا شد و تنها در صورت نیاز از پرچم‌هایی مثل no-sandbox استفاده کرد. این چیدمان به‌راحتی در PRها برای gate کردن mergeها و نیز در اجرای شبانه روی محیط production قابل استفاده است و در نهایت یک سازوکار سبک، تکرارپذیر و کم‌هزینه برای کنترل دائمی عملکرد ارائه می‌دهد.
#Lighthouse #LighthouseCI #Docker #WebPerformance #CI #DevOps #PerformanceBudgets #ContinuousIntegration
🟣لینک مقاله:
https://cur.at/ghYEsiF?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
Running Lighthouse CI in a Lightweight Docker Container
This guide demonstrates how to run Lighthouse CI performance tests for www.pradappandiyan.com using a lightweight Docker container. By…