🔵 عنوان مقاله
RtlHijack (GitHub Repo)
🟢 خلاصه مقاله:
RtlHijack (GitHub Repo) مجموعه‌ای از اسکریپت‌هاست که نشان می‌دهد چگونه می‌توان برخی توابع Rtl* در Windows را به‌صورت ناخواسته برای ایجاد «primitive»های جایگزین خواندن و نوشتن حافظه به‌کار گرفت. هدف پروژه، آموزش و پژوهش امنیتی است تا پژوهشگران و مدافعان بتوانند رفتارهای سطح پایین و پیامدهای امنیتی آن‌ها را بهتر درک کنند. بر کاربرد اخلاقی و آموزشی تأکید دارد، کلاس‌های رفتاری را توضیح می‌دهد و به مدافعان برای شناسایی الگوهای غیرعادی در استفاده از APIها، بهبود پایش و سخت‌سازی کمک می‌کند؛ بدون ارائه جزئیات اجرایی یا روش‌های مرحله‌به‌مرحله.
#RtlHijack #CyberSecurity #ExploitResearch #WindowsInternals #MemorySafety #BlueTeam #RedTeam #GitHub
🟣لینک مقاله:
https://github.com/kleiton0x00/RtlHijack?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
RtlHijack (GitHub Repo)
🟢 خلاصه مقاله:
RtlHijack (GitHub Repo) مجموعه‌ای از اسکریپت‌هاست که نشان می‌دهد چگونه می‌توان برخی توابع Rtl* در Windows را به‌صورت ناخواسته برای ایجاد «primitive»های جایگزین خواندن و نوشتن حافظه به‌کار گرفت. هدف پروژه، آموزش و پژوهش امنیتی است تا پژوهشگران و مدافعان بتوانند رفتارهای سطح پایین و پیامدهای امنیتی آن‌ها را بهتر درک کنند. بر کاربرد اخلاقی و آموزشی تأکید دارد، کلاس‌های رفتاری را توضیح می‌دهد و به مدافعان برای شناسایی الگوهای غیرعادی در استفاده از APIها، بهبود پایش و سخت‌سازی کمک می‌کند؛ بدون ارائه جزئیات اجرایی یا روش‌های مرحله‌به‌مرحله.
#RtlHijack #CyberSecurity #ExploitResearch #WindowsInternals #MemorySafety #BlueTeam #RedTeam #GitHub
🟣لینک مقاله:
https://github.com/kleiton0x00/RtlHijack?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
GitHub
GitHub - kleiton0x00/RtlHijack: Alternative Read and Write primitives using Rtl* functions the unintended way.
Alternative Read and Write primitives using Rtl* functions the unintended way. - kleiton0x00/RtlHijack
❤1
این کتاب خیلی ساده و روان توضیح میده چرا Rust اینقدر سر و صدا کرده و چرا خیلی‌ها دارن سمتش میرن:
نشون میده چطوری با سیستم ownership و borrowing میشه حافظه رو بدون دردسر مدیریت کرد
توضیح میده چرا توی Rust باگ‌هایی مثل null pointer یا data race کلاً از همون اول جلوی راهت سبز نمی‌شن
یاد میده چطوری میشه به راحتی برنامه‌های چندنخی و امن نوشت، بدون استرس خطاهای عجیب غریب
تأکید میکنه که همه‌ی این امکانات رو می‌گیری، ولی سرعتش در حد C/C++ باقی می‌مونه
نشون میده چطوری با سیستم ownership و borrowing میشه حافظه رو بدون دردسر مدیریت کرد
توضیح میده چرا توی Rust باگ‌هایی مثل null pointer یا data race کلاً از همون اول جلوی راهت سبز نمی‌شن
یاد میده چطوری میشه به راحتی برنامه‌های چندنخی و امن نوشت، بدون استرس خطاهای عجیب غریب
تأکید میکنه که همه‌ی این امکانات رو می‌گیری، ولی سرعتش در حد C/C++ باقی می‌مونه
❤1
🔵 عنوان مقاله
Testing and Programming Are Not Separate Disciplines
🟢 خلاصه مقاله:
** این یادآوری از Ravisuriya Eswara تأکید می‌کند که توسعه و تست نرم‌افزار باید یک فرایند یکپارچه باشند، نه دو رشته جدا. با وارد کردن تست در متن کار روزانه—از تعریف معیارهای پذیرش و شناسایی ریسک‌ها تا نوشتن تست‌ها کنار کد، اجرای TDD و پایپ‌لاین‌های CI/CD—کیفیت از ابتدا طراحی می‌شود، نه در انتها ارزیابی.
این رویکرد مزایایی مانند کاهش نقیصه‌های تولید، بازخورد سریع‌تر، تحویل قابل‌پیش‌بینی، تجربه کاربری بهتر و هزینه نگهداری کمتر دارد. همکاری جایگزین تحویل‌های مرحله‌ای می‌شود: توسعه‌دهندگان بر طراحیِ قابل‌تست تمرکز می‌کنند و تسترها با نگاه اکتشافی و کل‌نگر کیفیت را غنی می‌کنند؛ اتوماسیون و تست اکتشافی مکمل هم‌اند. نتیجه، چرخه‌ای سالم‌تر و محصولی پایدارتر در راستای اصول Agile و DevOps است.
#تست_نرم‌افزار #برنامه‌نویسی #کیفیت #DevOps #TDD #CI_CD #Agile #مهندسی_نرم‌افزار
🟣لینک مقاله:
https://cur.at/N39OqUZ?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Testing and Programming Are Not Separate Disciplines
🟢 خلاصه مقاله:
** این یادآوری از Ravisuriya Eswara تأکید می‌کند که توسعه و تست نرم‌افزار باید یک فرایند یکپارچه باشند، نه دو رشته جدا. با وارد کردن تست در متن کار روزانه—از تعریف معیارهای پذیرش و شناسایی ریسک‌ها تا نوشتن تست‌ها کنار کد، اجرای TDD و پایپ‌لاین‌های CI/CD—کیفیت از ابتدا طراحی می‌شود، نه در انتها ارزیابی.
این رویکرد مزایایی مانند کاهش نقیصه‌های تولید، بازخورد سریع‌تر، تحویل قابل‌پیش‌بینی، تجربه کاربری بهتر و هزینه نگهداری کمتر دارد. همکاری جایگزین تحویل‌های مرحله‌ای می‌شود: توسعه‌دهندگان بر طراحیِ قابل‌تست تمرکز می‌کنند و تسترها با نگاه اکتشافی و کل‌نگر کیفیت را غنی می‌کنند؛ اتوماسیون و تست اکتشافی مکمل هم‌اند. نتیجه، چرخه‌ای سالم‌تر و محصولی پایدارتر در راستای اصول Agile و DevOps است.
#تست_نرم‌افزار #برنامه‌نویسی #کیفیت #DevOps #TDD #CI_CD #Agile #مهندسی_نرم‌افزار
🟣لینک مقاله:
https://cur.at/N39OqUZ?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Blogspot
Testing and Programming Are Not Separate Disciplines
Programming, Testing, Coding, Skills, Practice, Thinking, Debugging, Programming Languages, Data Structures, Tester, SDET, Developer, Myth
❤1
🔵 عنوان مقاله
The Over-Framework Trap: Preventing the Maze of Test Complexity
🟢 خلاصه مقاله:
Roman Kostenko هشدار می‌دهد به دام «Over‑Framework» نیفتید؛ جایی که چارچوب‌های تست با لایه‌های اضافی، wrapperها و DSLهای پیچیده بهره‌وری را کم و نگهداری را سخت می‌کنند. او توصیه می‌کند از ساده‌ترین راهکار شروع کنید، تا حد امکان از ابزارها و الگوهای پذیرفته‌شده استفاده کنید، و فقط زمانی abstraction اضافه کنید که درد تکرار واقعاً احساس می‌شود—آن هم به سبک مینیمال تا خوانایی تست‌ها حفظ شود. همچنین بر قابلیت اتکا و مشاهده‌پذیری تأکید دارد: داده‌ی تست قطعی، setup/teardown تمیز، پیام خطای مفید، لاگ مختصر و سریع‌بودن چرخه‌ی بازخورد. چارچوب را به‌تدریج و بر اساس نیازهای واقعی رشد دهید، بخش‌های بلااستفاده را حذف کنید و با مستندسازی سبک و بازبینی‌های سبک از پیچیدگی ناخواسته جلوگیری کنید.
#TestAutomation #SoftwareTesting #QA #TestFramework #Simplicity #CleanCode #DevOps #BestPractices
🟣لینک مقاله:
https://cur.at/NeRvNG1?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
The Over-Framework Trap: Preventing the Maze of Test Complexity
🟢 خلاصه مقاله:
Roman Kostenko هشدار می‌دهد به دام «Over‑Framework» نیفتید؛ جایی که چارچوب‌های تست با لایه‌های اضافی، wrapperها و DSLهای پیچیده بهره‌وری را کم و نگهداری را سخت می‌کنند. او توصیه می‌کند از ساده‌ترین راهکار شروع کنید، تا حد امکان از ابزارها و الگوهای پذیرفته‌شده استفاده کنید، و فقط زمانی abstraction اضافه کنید که درد تکرار واقعاً احساس می‌شود—آن هم به سبک مینیمال تا خوانایی تست‌ها حفظ شود. همچنین بر قابلیت اتکا و مشاهده‌پذیری تأکید دارد: داده‌ی تست قطعی، setup/teardown تمیز، پیام خطای مفید، لاگ مختصر و سریع‌بودن چرخه‌ی بازخورد. چارچوب را به‌تدریج و بر اساس نیازهای واقعی رشد دهید، بخش‌های بلااستفاده را حذف کنید و با مستندسازی سبک و بازبینی‌های سبک از پیچیدگی ناخواسته جلوگیری کنید.
#TestAutomation #SoftwareTesting #QA #TestFramework #Simplicity #CleanCode #DevOps #BestPractices
🟣لینک مقاله:
https://cur.at/NeRvNG1?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
The Over-Framework Trap: Preventing the Maze of Test Complexity.
Today I want to talk about something that hurts every developer sooner or later — complexity. Especially in tests. You know the moment: a…
🤡1
🔵 عنوان مقاله
AI Picks Tests To Run On A Bug
🟢 خلاصه مقاله:
این مقاله یک نمونه عملی از کاربست هوش مصنوعی در تست نرم‌افزار را نشان می‌دهد: Gleb Bahmutov توضیح می‌دهد چگونه می‌توان با تحلیل سرنخ‌های مرتبط با باگ—مثل پیام خطا، stack trace، تغییرات اخیر کد و نسبت تاریخی میان بخش‌های کد و تست‌ها—مجموعه‌ای از آزمون‌های واقعاً مرتبط را انتخاب و اجرا کرد. این روش با اجرای هدفمند تست‌ها، زمان بازخورد را کوتاه‌تر و هزینه اجرا را کمتر می‌کند و هم در محیط توسعه محلی و هم در CI قابل استفاده است. در عین حال، با حفظ نظارت انسانی، سنجش دقت و پوشش انتخاب‌ها، ثبت دلایل انتخاب هر تست و در صورت ابهام، بازگشت به اجرای کامل، اعتمادپذیری حفظ می‌شود. نتیجه، چرخه عیب‌یابی سریع‌تر و تمرکز بیشتر روی تست‌هایی است که بیشترین احتمال کشف یا بازتولید باگ را دارند.
#SoftwareTesting #AI #TestAutomation #QualityAssurance #BugFixing #TestSelection #CICD
🟣لینک مقاله:
https://cur.at/QPMAEXI?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
AI Picks Tests To Run On A Bug
🟢 خلاصه مقاله:
این مقاله یک نمونه عملی از کاربست هوش مصنوعی در تست نرم‌افزار را نشان می‌دهد: Gleb Bahmutov توضیح می‌دهد چگونه می‌توان با تحلیل سرنخ‌های مرتبط با باگ—مثل پیام خطا، stack trace، تغییرات اخیر کد و نسبت تاریخی میان بخش‌های کد و تست‌ها—مجموعه‌ای از آزمون‌های واقعاً مرتبط را انتخاب و اجرا کرد. این روش با اجرای هدفمند تست‌ها، زمان بازخورد را کوتاه‌تر و هزینه اجرا را کمتر می‌کند و هم در محیط توسعه محلی و هم در CI قابل استفاده است. در عین حال، با حفظ نظارت انسانی، سنجش دقت و پوشش انتخاب‌ها، ثبت دلایل انتخاب هر تست و در صورت ابهام، بازگشت به اجرای کامل، اعتمادپذیری حفظ می‌شود. نتیجه، چرخه عیب‌یابی سریع‌تر و تمرکز بیشتر روی تست‌هایی است که بیشترین احتمال کشف یا بازتولید باگ را دارند.
#SoftwareTesting #AI #TestAutomation #QualityAssurance #BugFixing #TestSelection #CICD
🟣لینک مقاله:
https://cur.at/QPMAEXI?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Better world by better software
AI Picks Tests To Run On A Bug
In the blog post Test Tag Suggestions Using AI I described a system to pick a testing tag based on a pull request's title and body text. In this blog post, I will make it useful. Whenever a user o
کامپیوترها برای نگهداری و نمایش کاراکترهای یک متن از یه فضای یک بایتی (معادل هشت بیت 0 یا 1) استفاده میکردن
این میزان فضا توی کامپیوتر میتونه شامل 255 حالت مختلف بشه
کامپیوترها برای نشانه‌های گرامری، حروف انگلیسی و عدد از استاندارد اسکی (ASCII) استفاده میکردن
این استاندارد آمریکایی میاد برای هر کاراکتر یه معادل عددی تعریف میکنه
مثلا کاراکتر A در اسکی معادل عدد 65هست
قرار گرفتن این اعداد پشت سر هم در کامپیوتر یک متن رو میسازه
مشابه این استاندارد معادل عددی برای پشتیبانی از تمام زبان‌های دنیا به وجود اومد که یونیکد (Unicode) نام داره
کاراکترهای انگلیسی و اعداد انگلیسی توی یونیکد از همون اعداد استاندارد اسکی استفاده میکنن و در ادامه پشتیبانی از کاراکترهای بقیه زبان‌های دنیا بهش اضافه میشه
یونیکد در حال حاضر دارای چیزی حدود 297,000 معادل عددی برای کاراکترهای مختلف از زبان‌های مختلف، اموجی‌ها و ... هست
فضای یک بایتی برای پشتیبانی از این میزان حالت‌های مختلف کافی نیس
شما برای این جا دادن این میزان از حالت‌های مختلف به شکل بیت کامیپوتر به حداقل سه بایت نیاز دارین
سه بایت میتونه تا حدود 16 میلیون عدد مختلف رو برای شما نگه داری کنه
حالا شما برای نگهداری یک متن که شامل کاراکترهای
یونیکد هست نیاز دارین 3 بایت برای هر کاراکتر اختصاص بدین
کاراکترهای انگلیسی تو یونیکد تنها یک بایت هم براشون کافیه ولی اگه شما برای یه متن انگلیسی، هر کاراکتر رو سه بایت در نظر بگیرین عملا به ازای هر کاراکتر انگلیسی دو بایت فضا رو هدر دادین
مثلا تو یه متن با ده هزار کاراکتر،
یه چیزی حدود 20 کیلوبایت فضای کامپیوتر رو هدر دادین
چه وقتی میخاین ازش استفاده کنین و توی رم هست و چه وقتی که روی هارد دیسک برای استفاده در آینده ذخیره شده
اینجاست که UTF-8 میتونه کمک کنه
این استاندارد که توسط یونیکد تعریف شده به جای اینکه بیاد فضای 3 بایتی به هر کاراکتر
اختصاص بده، میاد از 7 بیت راست یک بایت برای کاراکترهای اسکی استفاده میکنه
و برای کاراکترهای بعدی علاوه بر خود کاراکتر، تعداد بایت مصرف شده برای اون کاراکتر هم داخل بایت اول ذخیره میکنه
یعنی 128 کاراکتر اول اسکی به شکل عادی ذخیره میشن بدون تغییر خاصی با فقط یک بایت فضا
ولی برای کاراکترهای بعدی میاد و داخل بایت اول مشخص میکنه چه میزان فضا برای کاراکتر استفاده شده
این میزان فضا از یک بایت تا چهاربایت میتونه متغیر باشه
حالا چه شکلی اینکارو میکنه
تو یه بایت برای 128 عدد اولیه اسکی، بیت چپ همیشه صفر هست
اما وقتی بیت چپ یک میشه یعنی با یه کاراکتر UTF8 طرف هستیم
همونطور که گفتم هر کاراکتر توی UTF-8 میتونه از یک بایت تا چهاربایت متغیر باشه
کامپیوتر چطور اینو تشخیص میده؟
بیت‌های 1 اولِ بایت رو میشماره تا به عدد 0 صفر برسه
یعنی اگه بایت اول با عدد باینری 110 شروع بشه، یعنی دوبایت فضا استفاده شده
اگه 1110 باشه سه بایت و ...
تو UTF-8 فضای بیت‌های بایت اول بین خود کاراکتر و تعداد بایت تقسیم میشه و متغیره
اما تو بایت‌های دوم و سوم و چهارم همیشه شش تا بیت راست برای خود کاراکتر استفاده میشه و دو بیت دیگه برای هندل کردن ارور تو utf-8 استفاده میشه
امیدوارم تونسته باشم با دانش ناقص خودم شما رو در مورد این انکدینگ رایج دنیای کامپیوتر آشنا کرده باشم
توضیحات دقیق‌تر:
https://en.wikipedia.org/wiki/UTF-8
سایت استفاده شده برای تست بایت UTF-8:
https://utf8-playground.netlify.app/
| <Amir/>
این میزان فضا توی کامپیوتر میتونه شامل 255 حالت مختلف بشه
کامپیوترها برای نشانه‌های گرامری، حروف انگلیسی و عدد از استاندارد اسکی (ASCII) استفاده میکردن
این استاندارد آمریکایی میاد برای هر کاراکتر یه معادل عددی تعریف میکنه
مثلا کاراکتر A در اسکی معادل عدد 65هست
قرار گرفتن این اعداد پشت سر هم در کامپیوتر یک متن رو میسازه
مشابه این استاندارد معادل عددی برای پشتیبانی از تمام زبان‌های دنیا به وجود اومد که یونیکد (Unicode) نام داره
کاراکترهای انگلیسی و اعداد انگلیسی توی یونیکد از همون اعداد استاندارد اسکی استفاده میکنن و در ادامه پشتیبانی از کاراکترهای بقیه زبان‌های دنیا بهش اضافه میشه
یونیکد در حال حاضر دارای چیزی حدود 297,000 معادل عددی برای کاراکترهای مختلف از زبان‌های مختلف، اموجی‌ها و ... هست
فضای یک بایتی برای پشتیبانی از این میزان حالت‌های مختلف کافی نیس
شما برای این جا دادن این میزان از حالت‌های مختلف به شکل بیت کامیپوتر به حداقل سه بایت نیاز دارین
سه بایت میتونه تا حدود 16 میلیون عدد مختلف رو برای شما نگه داری کنه
حالا شما برای نگهداری یک متن که شامل کاراکترهای
یونیکد هست نیاز دارین 3 بایت برای هر کاراکتر اختصاص بدین
کاراکترهای انگلیسی تو یونیکد تنها یک بایت هم براشون کافیه ولی اگه شما برای یه متن انگلیسی، هر کاراکتر رو سه بایت در نظر بگیرین عملا به ازای هر کاراکتر انگلیسی دو بایت فضا رو هدر دادین
مثلا تو یه متن با ده هزار کاراکتر،
یه چیزی حدود 20 کیلوبایت فضای کامپیوتر رو هدر دادین
چه وقتی میخاین ازش استفاده کنین و توی رم هست و چه وقتی که روی هارد دیسک برای استفاده در آینده ذخیره شده
اینجاست که UTF-8 میتونه کمک کنه
این استاندارد که توسط یونیکد تعریف شده به جای اینکه بیاد فضای 3 بایتی به هر کاراکتر
اختصاص بده، میاد از 7 بیت راست یک بایت برای کاراکترهای اسکی استفاده میکنه
و برای کاراکترهای بعدی علاوه بر خود کاراکتر، تعداد بایت مصرف شده برای اون کاراکتر هم داخل بایت اول ذخیره میکنه
یعنی 128 کاراکتر اول اسکی به شکل عادی ذخیره میشن بدون تغییر خاصی با فقط یک بایت فضا
ولی برای کاراکترهای بعدی میاد و داخل بایت اول مشخص میکنه چه میزان فضا برای کاراکتر استفاده شده
این میزان فضا از یک بایت تا چهاربایت میتونه متغیر باشه
حالا چه شکلی اینکارو میکنه
تو یه بایت برای 128 عدد اولیه اسکی، بیت چپ همیشه صفر هست
اما وقتی بیت چپ یک میشه یعنی با یه کاراکتر UTF8 طرف هستیم
همونطور که گفتم هر کاراکتر توی UTF-8 میتونه از یک بایت تا چهاربایت متغیر باشه
کامپیوتر چطور اینو تشخیص میده؟
بیت‌های 1 اولِ بایت رو میشماره تا به عدد 0 صفر برسه
یعنی اگه بایت اول با عدد باینری 110 شروع بشه، یعنی دوبایت فضا استفاده شده
اگه 1110 باشه سه بایت و ...
تو UTF-8 فضای بیت‌های بایت اول بین خود کاراکتر و تعداد بایت تقسیم میشه و متغیره
اما تو بایت‌های دوم و سوم و چهارم همیشه شش تا بیت راست برای خود کاراکتر استفاده میشه و دو بیت دیگه برای هندل کردن ارور تو utf-8 استفاده میشه
امیدوارم تونسته باشم با دانش ناقص خودم شما رو در مورد این انکدینگ رایج دنیای کامپیوتر آشنا کرده باشم
توضیحات دقیق‌تر:
https://en.wikipedia.org/wiki/UTF-8
سایت استفاده شده برای تست بایت UTF-8:
https://utf8-playground.netlify.app/
| <Amir/>
👍1🕊1
🔵 عنوان مقاله
How to Contribute Meaningfully in Feature Planning
🟢 خلاصه مقاله:
**این مقاله نشان می‌دهد تسترها با طرح پرسش‌های هدفمند می‌توانند از ابتدای برنامه‌ریزی فیچر، ارزش بسازند. محورهای کلیدی شامل روشن‌کردن مسئله و مخاطب، معیارهای موفقیت و محدوده، و ثبت معیارهای پذیرش شفاف است. سپس باید ریسک‌ها و پوشش را زودهنگام آشکار کرد: مسیرهای خطا و لبه، یکپارچگی‌ها و جریان داده، و نیازهای غیرکارکردی مانند امنیت، حریم خصوصی، عملکرد، دسترس‌پذیری و بومی‌سازی. تمرکز بر تست‌پذیری نیز حیاتی است: مشاهده‌پذیری با لاگ و متریک، استراتژی اتوماسیون در لایه‌های مختلف، مدیریت داده آزمایشی و برابری محیط‌ها، و استفاده از feature flag، mock و sandbox برای交交交交交交. در نهایت، برنامه عرضه و یادگیری را تعریف کنید: rollout مرحله‌ای یا A/B، پایش و هشدار، و برنامه بازگشت. به‌گفته Mona M. Abd El-Rahman داشتن یک بانک پرسش آماده، تستر را از نگهبان انتهایی به شریک زودمرحله‌ای تبدیل می‌کند و بازخورد سریع‌تر و کیفیت قابل‌اندازه‌گیری به‌همراه دارد.
#SoftwareTesting #FeaturePlanning #QualityEngineering #ShiftLeft #TestStrategy #QA #ProductDevelopment #Agile
🟣لینک مقاله:
https://cur.at/J1qOdPm?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
How to Contribute Meaningfully in Feature Planning
🟢 خلاصه مقاله:
**این مقاله نشان می‌دهد تسترها با طرح پرسش‌های هدفمند می‌توانند از ابتدای برنامه‌ریزی فیچر، ارزش بسازند. محورهای کلیدی شامل روشن‌کردن مسئله و مخاطب، معیارهای موفقیت و محدوده، و ثبت معیارهای پذیرش شفاف است. سپس باید ریسک‌ها و پوشش را زودهنگام آشکار کرد: مسیرهای خطا و لبه، یکپارچگی‌ها و جریان داده، و نیازهای غیرکارکردی مانند امنیت، حریم خصوصی، عملکرد، دسترس‌پذیری و بومی‌سازی. تمرکز بر تست‌پذیری نیز حیاتی است: مشاهده‌پذیری با لاگ و متریک، استراتژی اتوماسیون در لایه‌های مختلف، مدیریت داده آزمایشی و برابری محیط‌ها، و استفاده از feature flag، mock و sandbox برای交交交交交交. در نهایت، برنامه عرضه و یادگیری را تعریف کنید: rollout مرحله‌ای یا A/B، پایش و هشدار، و برنامه بازگشت. به‌گفته Mona M. Abd El-Rahman داشتن یک بانک پرسش آماده، تستر را از نگهبان انتهایی به شریک زودمرحله‌ای تبدیل می‌کند و بازخورد سریع‌تر و کیفیت قابل‌اندازه‌گیری به‌همراه دارد.
#SoftwareTesting #FeaturePlanning #QualityEngineering #ShiftLeft #TestStrategy #QA #ProductDevelopment #Agile
🟣لینک مقاله:
https://cur.at/J1qOdPm?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
🚀 How to Contribute Meaningfully in Feature Planning
Asking the Right Questions Early to Build Usable, Resilient, and Measurable Features
Forwarded from Bardia & Erfan
پاول دورُف: حاضرَم بمیرم، ولی آزادی و امنیت کاربران رو نفروشم!
در گفت‌وگوی عمیق با «لِکس فریدمن»، بنیان‌گذار تلگرام از فلسفهٔ زندگی، حریم خصوصی، بیت‌کوین و مقاومتش در برابر فشار دولت‌ها گفت.
> 🗣
🔒
او تأکید کرد تلگرام هیچوقت “در پشتی” برای دولت‌ها باز نکرده و در برابر فشار روسیه و ایران برای دسترسی به اطلاعات یا سانسور مقاومت کرده است.
>
📱 ۷ اصل فکری و مدیریتی پاول دورُف (بر اساس مصاحبه):
1️⃣ آزادی و اخلاق بالاتر از هر سود مالی — او می‌گوید حاضر است تمام دارایی‌اش را از دست بدهد تا آزادی بیان و امنیت کاربران حفظ شود.
2️⃣ مینیمالیسم و انضباط شخصی — سبک زندگی‌اش ساده، بدون الکل، قهوه یا حواس‌پرتی است؛ تمرکز کامل روی مأموریت و نظم ذهنی.
3️⃣ تیم کوچک، تأثیر بزرگ — معتقد است تیم‌های بزرگ بهره‌وری را می‌کُشند؛ موفقیت تلگرام حاصل اعتماد به چند نابغهٔ منضبط است.
4️⃣ مقاومت در برابر سانسور و در پشتی — هیچ دولت یا شرکتی حق کنترل یا شنود تلگرام را ندارد. رمزنگاری و طراحی MTProto را «دیوار آزادی دیجیتال» می‌نامد.
5️⃣ پول و قدرت ابزارند، نه هدف — او از مدل‌های انحصاری و کمیسیون‌های اپل و گوگل انتقاد می‌کند و تأکید دارد که ثروت نباید آزادی را محدود کند.
6️⃣ باور به فناوری آزاد مثل بیت‌کوین — بیت‌کوین را «نمادِ کاهش نیاز به اعتماد به واسطه‌ها و آزادی مالی» می‌داند؛ از پروژه TON به‌عنوان زیربنای اقتصاد آزاد تلگرام یاد می‌کند.
7️⃣ نگاه فلسفی به زندگی و مرگ — از کافکا، شوپنهاور و «جاودانگی کوانتومی» می‌گوید؛ باور دارد انسان باید بدون ترس از مرگ، بر پایهٔ ارزش‌های خودش زندگی کند.
در گفت‌وگوی عمیق با «لِکس فریدمن»، بنیان‌گذار تلگرام از فلسفهٔ زندگی، حریم خصوصی، بیت‌کوین و مقاومتش در برابر فشار دولت‌ها گفت.
> 🗣
«من ترجیح می‌دم بمیرم و تمام داراییم رو از دست بدهم تا اینکه اطلاعات کاربران رو به هر دولتی تحویل بدم.
آزادی و امنیت داده‌ها، خط قرمز من و تلگرامه.»
🔒
او تأکید کرد تلگرام هیچوقت “در پشتی” برای دولت‌ها باز نکرده و در برابر فشار روسیه و ایران برای دسترسی به اطلاعات یا سانسور مقاومت کرده است.
>
«در روسیه و ایران بارها تلاش شد ما رو مجبور به همکاری کنن. ولی ما مقاومت کردیم چون اگر یک‌بار کوتاه بیای، دیگه آزادی واقعی وجود نداره.»
📱 ۷ اصل فکری و مدیریتی پاول دورُف (بر اساس مصاحبه):
1️⃣ آزادی و اخلاق بالاتر از هر سود مالی — او می‌گوید حاضر است تمام دارایی‌اش را از دست بدهد تا آزادی بیان و امنیت کاربران حفظ شود.
2️⃣ مینیمالیسم و انضباط شخصی — سبک زندگی‌اش ساده، بدون الکل، قهوه یا حواس‌پرتی است؛ تمرکز کامل روی مأموریت و نظم ذهنی.
3️⃣ تیم کوچک، تأثیر بزرگ — معتقد است تیم‌های بزرگ بهره‌وری را می‌کُشند؛ موفقیت تلگرام حاصل اعتماد به چند نابغهٔ منضبط است.
4️⃣ مقاومت در برابر سانسور و در پشتی — هیچ دولت یا شرکتی حق کنترل یا شنود تلگرام را ندارد. رمزنگاری و طراحی MTProto را «دیوار آزادی دیجیتال» می‌نامد.
5️⃣ پول و قدرت ابزارند، نه هدف — او از مدل‌های انحصاری و کمیسیون‌های اپل و گوگل انتقاد می‌کند و تأکید دارد که ثروت نباید آزادی را محدود کند.
6️⃣ باور به فناوری آزاد مثل بیت‌کوین — بیت‌کوین را «نمادِ کاهش نیاز به اعتماد به واسطه‌ها و آزادی مالی» می‌داند؛ از پروژه TON به‌عنوان زیربنای اقتصاد آزاد تلگرام یاد می‌کند.
7️⃣ نگاه فلسفی به زندگی و مرگ — از کافکا، شوپنهاور و «جاودانگی کوانتومی» می‌گوید؛ باور دارد انسان باید بدون ترس از مرگ، بر پایهٔ ارزش‌های خودش زندگی کند.
کامپایلرهای درجا (JIT Compilers) در JVM چگونه پرفورمنس برنامه‌ها را بهبود می‌دهند؟
می‌دونیم که برنامه‌های نوشته شده با جاوا، ابتدا به بایت‌کد (bytecode) کامپایل میشن و JVM بایت‌کدها رو به‌صورت مفسری اجرا میکنه. این فرآیند نسبت به این که کدهای جاوا مستقیم به زبان ماشین کامپایل و اجرا بشن کندتره اما وجود همین مکانیزمه که جاوا رو کراس‌پلتفرم میکنه.
برای حل این مساله، دو کامپایلر درجا به نام‌های C1 و C2 در JVM وجود دارن. وظیفه این کامپایلرها به‌طور خلاصه اینه که قسمت‌هایی از برنامه که بیشتر از میزان مشخصی اجرا میشن (اصطلاحا نقاط داغ) رو به زبان ماشین کامپایل میکنن تا اون قسمت‌ها دیگه به‌صورت مفسری اجرا نشن. کدهای ماشینی که این کامپایلرها تولید میکنن در محلی از حافظه به نام Code Cache ذخیره میشه.
واحد کامپایل برای کامپایلرهای درجا، متده. تعداد دفعاتی که یه متد اجرا میشه توسط JVM ذخیره میشه و وقتی این تعداد از میزان مشخصی بالاتر بره، کامپایلرهای درجا وارد عمل میشن.
نحوه عملکرد این دو کامپایلر به‌طور خلاصه به این صورته:
۱- متد به‌صورت پیش‌فرض، مفسری اجرا میشه.
۲- وقتی تعداد دفعات اجرای متد از مقدار خاصی بیشتر بشه، کامپایلر C1 اون متد رو به زبان ماشین کامپایل میکنه. همچنین C1 دستورهایی رو در متد کامپایل شده قرار میده تا اطلاعاتی رو درباره جزئیات عملکرد متد در طول اجرای برنامه جمع‌آوری کنن (پروفایلینگ). این اطلاعات بعدا توسط C2 استفاده میشن.
۳- اگر متد همچنان زیاد اجرا بشه یعنی واقعا متد پرکاربرد و اصطلاحا داغیه. اینجا C2 وارد عمل میشه و متد رو دوباره به کد ماشین کامپایل میکنه. اما این بار C2 از اطلاعاتی که از اجرای متد در طول برنامه جمع‌آوری شده (با استفاده از دستورایی که C1 به متد اضافه کرده بود) استفاده میکنه و با این اطلاعات میتونه بهینه‌ترین و سریع‌ترین کد ماشین ممکن رو تولید کنه.
پس ممکنه متدی که کم اجرا میشه هیچوقت به کد ماشین کامپایل نشه. یا متدی با C1 کامپایل بشه اما به اندازه‌ای زیاد اجرا نشه که C2 کامپایلش کنه. این که دقیقا بعد از چندبار اجرای یه متد این دوتا کامپایلر وارد عمل بشن قابل تنظیمه اما مقادیر پیش‌فرضی که دارن احتمالا برای اکثر برنامه‌ها مناسبه و نیازی به تغییرشون نیست.
<Mostafa Nasiri/>
می‌دونیم که برنامه‌های نوشته شده با جاوا، ابتدا به بایت‌کد (bytecode) کامپایل میشن و JVM بایت‌کدها رو به‌صورت مفسری اجرا میکنه. این فرآیند نسبت به این که کدهای جاوا مستقیم به زبان ماشین کامپایل و اجرا بشن کندتره اما وجود همین مکانیزمه که جاوا رو کراس‌پلتفرم میکنه.
برای حل این مساله، دو کامپایلر درجا به نام‌های C1 و C2 در JVM وجود دارن. وظیفه این کامپایلرها به‌طور خلاصه اینه که قسمت‌هایی از برنامه که بیشتر از میزان مشخصی اجرا میشن (اصطلاحا نقاط داغ) رو به زبان ماشین کامپایل میکنن تا اون قسمت‌ها دیگه به‌صورت مفسری اجرا نشن. کدهای ماشینی که این کامپایلرها تولید میکنن در محلی از حافظه به نام Code Cache ذخیره میشه.
واحد کامپایل برای کامپایلرهای درجا، متده. تعداد دفعاتی که یه متد اجرا میشه توسط JVM ذخیره میشه و وقتی این تعداد از میزان مشخصی بالاتر بره، کامپایلرهای درجا وارد عمل میشن.
نحوه عملکرد این دو کامپایلر به‌طور خلاصه به این صورته:
۱- متد به‌صورت پیش‌فرض، مفسری اجرا میشه.
۲- وقتی تعداد دفعات اجرای متد از مقدار خاصی بیشتر بشه، کامپایلر C1 اون متد رو به زبان ماشین کامپایل میکنه. همچنین C1 دستورهایی رو در متد کامپایل شده قرار میده تا اطلاعاتی رو درباره جزئیات عملکرد متد در طول اجرای برنامه جمع‌آوری کنن (پروفایلینگ). این اطلاعات بعدا توسط C2 استفاده میشن.
۳- اگر متد همچنان زیاد اجرا بشه یعنی واقعا متد پرکاربرد و اصطلاحا داغیه. اینجا C2 وارد عمل میشه و متد رو دوباره به کد ماشین کامپایل میکنه. اما این بار C2 از اطلاعاتی که از اجرای متد در طول برنامه جمع‌آوری شده (با استفاده از دستورایی که C1 به متد اضافه کرده بود) استفاده میکنه و با این اطلاعات میتونه بهینه‌ترین و سریع‌ترین کد ماشین ممکن رو تولید کنه.
پس ممکنه متدی که کم اجرا میشه هیچوقت به کد ماشین کامپایل نشه. یا متدی با C1 کامپایل بشه اما به اندازه‌ای زیاد اجرا نشه که C2 کامپایلش کنه. این که دقیقا بعد از چندبار اجرای یه متد این دوتا کامپایلر وارد عمل بشن قابل تنظیمه اما مقادیر پیش‌فرضی که دارن احتمالا برای اکثر برنامه‌ها مناسبه و نیازی به تغییرشون نیست.
<Mostafa Nasiri/>
❤3
🔵 عنوان مقاله
What does successful automation look like to you? Have you ever seen it?
🟢 خلاصه مقاله:
اتوماسیون موفق در شرکت‌های مختلف شکل‌های متفاوتی دارد، اما نقطه مشترک آن نتایج تجاری ملموس و اعتماد تیم است: چرخه انتشار سریع‌تر، خطاهای فراری کمتر، و شکست‌های معنادار به‌جای نویز. تجربه‌های مطرح‌شده در Reddit بر چند اصل تاکید دارند: پایداری و سرعت در CI/CD، هرم تست با تمرکز بر unit و integration و تعداد اندک E2E برای مسیرهای حیاتی، کد تست قابل نگهداری و مدیریت داده/محیط قابل اتکا. مالکیت مشترک بین Dev و QA، معیارهای روشن، و قابلیت مشاهده‌پذیری (لاگ، اسکرین‌شات، ترِیس و ردیابی flaky) ضروری‌اند. موفقیت یعنی ROI واقعی: زمان آزادشده برای بهبود محصول، کاهش hotfix، و اطمینان در هر PR—و دوری از ضدالگوهایی مثل افراط در UI tests یا تعقیب پوشش ۱۰۰٪.
#TestAutomation #SoftwareTesting #QA #DevOps #CICD #AutomationStrategy #QualityEngineering
🟣لینک مقاله:
https://cur.at/w3kN7Xu?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
What does successful automation look like to you? Have you ever seen it?
🟢 خلاصه مقاله:
اتوماسیون موفق در شرکت‌های مختلف شکل‌های متفاوتی دارد، اما نقطه مشترک آن نتایج تجاری ملموس و اعتماد تیم است: چرخه انتشار سریع‌تر، خطاهای فراری کمتر، و شکست‌های معنادار به‌جای نویز. تجربه‌های مطرح‌شده در Reddit بر چند اصل تاکید دارند: پایداری و سرعت در CI/CD، هرم تست با تمرکز بر unit و integration و تعداد اندک E2E برای مسیرهای حیاتی، کد تست قابل نگهداری و مدیریت داده/محیط قابل اتکا. مالکیت مشترک بین Dev و QA، معیارهای روشن، و قابلیت مشاهده‌پذیری (لاگ، اسکرین‌شات، ترِیس و ردیابی flaky) ضروری‌اند. موفقیت یعنی ROI واقعی: زمان آزادشده برای بهبود محصول، کاهش hotfix، و اطمینان در هر PR—و دوری از ضدالگوهایی مثل افراط در UI tests یا تعقیب پوشش ۱۰۰٪.
#TestAutomation #SoftwareTesting #QA #DevOps #CICD #AutomationStrategy #QualityEngineering
🟣لینک مقاله:
https://cur.at/w3kN7Xu?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Reddit
From the softwaretesting community on Reddit
Explore this post and more from the softwaretesting community
🔵 عنوان مقاله
Apple patches critical zero-day in ImageIO amid reports of targeted exploits (2 minute read)
🟢 خلاصه مقاله:
اپل یک آسیب‌پذیری بحرانی از نوع zero-day با شناسه CVE-2025-43300 را در چارچوب ImageIO برطرف کرد؛ نقص «out-of-bounds write» می‌تواند هنگام پردازش تصاویر مخرب باعث خرابی حافظه و در سناریوهای بدتر اجرای کد شود. بنا بر گزارش‌ها، این آسیب‌پذیری در حملات بسیار پیشرفته و هدفمند علیه افراد خاص مورداستفاده قرار گرفته است. به‌روزرسانی‌ها برای iOS، iPadOS و macOS—including older devices—منتشر شده و تعداد zero-dayهای فعالاً بهره‌برداری‌شده که اپل در سال 2025 رفع کرده را به هفت مورد رسانده است. توصیه می‌شود کاربران فوراً دستگاه‌های خود را به‌روزرسانی و به‌روزرسانی خودکار را فعال کنند.
#Apple #ImageIO #CVE-2025-43300 #ZeroDay #iOS #iPadOS #macOS #Cybersecurity
🟣لینک مقاله:
https://www.csoonline.com/article/4058589/apple-patches-critical-zero-day-in-imageio-amid-reports-of-targeted-exploits.html?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Apple patches critical zero-day in ImageIO amid reports of targeted exploits (2 minute read)
🟢 خلاصه مقاله:
اپل یک آسیب‌پذیری بحرانی از نوع zero-day با شناسه CVE-2025-43300 را در چارچوب ImageIO برطرف کرد؛ نقص «out-of-bounds write» می‌تواند هنگام پردازش تصاویر مخرب باعث خرابی حافظه و در سناریوهای بدتر اجرای کد شود. بنا بر گزارش‌ها، این آسیب‌پذیری در حملات بسیار پیشرفته و هدفمند علیه افراد خاص مورداستفاده قرار گرفته است. به‌روزرسانی‌ها برای iOS، iPadOS و macOS—including older devices—منتشر شده و تعداد zero-dayهای فعالاً بهره‌برداری‌شده که اپل در سال 2025 رفع کرده را به هفت مورد رسانده است. توصیه می‌شود کاربران فوراً دستگاه‌های خود را به‌روزرسانی و به‌روزرسانی خودکار را فعال کنند.
#Apple #ImageIO #CVE-2025-43300 #ZeroDay #iOS #iPadOS #macOS #Cybersecurity
🟣لینک مقاله:
https://www.csoonline.com/article/4058589/apple-patches-critical-zero-day-in-imageio-amid-reports-of-targeted-exploits.html?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
CSO Online
Apple patches critical zero-day in ImageIO amid reports of targeted exploits
With no workaround available, Apple advises all users to install iOS 16.7.12 and iPadOS 16.7.12 without delay.
🔵 عنوان مقاله
Windows (GitHub Repo)
🟢 خلاصه مقاله:
** این GitHub Repo راه‌اندازی Windows داخل یک محیط Docker را ساده می‌کند: با دانلود خودکار ISO و بهره‌گیری از شتاب‌دهی KVM، یک ماشین مجازی Windows با کارایی نزدیک به بومی اجرا می‌شود. هدف، ارائه محیطی تکرارپذیر، قابل‌حمل و یک‌بارمصرف برای توسعه و تست است؛ با امکان دسترسی از راه دور (مثلاً RDP/VNC) و نگهداری داده‌ها از طریق volumeها. این راه‌حل برای CI/CD، تست میان‌سکویی و اجرای ابزارهای مخصوص Windows مفید است. نیازمندی‌ها معمولاً شامل یک میزبان Linux با پشتیبانی KVM و رعایت الزامات لایسنس Windows است.
#Windows #Docker #KVM #Virtualization #DevOps #ISO #CloudNative #CI_CD
🟣لینک مقاله:
https://github.com/dockur/windows?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Windows (GitHub Repo)
🟢 خلاصه مقاله:
** این GitHub Repo راه‌اندازی Windows داخل یک محیط Docker را ساده می‌کند: با دانلود خودکار ISO و بهره‌گیری از شتاب‌دهی KVM، یک ماشین مجازی Windows با کارایی نزدیک به بومی اجرا می‌شود. هدف، ارائه محیطی تکرارپذیر، قابل‌حمل و یک‌بارمصرف برای توسعه و تست است؛ با امکان دسترسی از راه دور (مثلاً RDP/VNC) و نگهداری داده‌ها از طریق volumeها. این راه‌حل برای CI/CD، تست میان‌سکویی و اجرای ابزارهای مخصوص Windows مفید است. نیازمندی‌ها معمولاً شامل یک میزبان Linux با پشتیبانی KVM و رعایت الزامات لایسنس Windows است.
#Windows #Docker #KVM #Virtualization #DevOps #ISO #CloudNative #CI_CD
🟣لینک مقاله:
https://github.com/dockur/windows?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
GitHub
GitHub - dockur/windows: Windows inside a Docker container.
Windows inside a Docker container. Contribute to dockur/windows development by creating an account on GitHub.
🤝1
🔵 عنوان مقاله
The Automation Maturity Pyramid
🟢 خلاصه مقاله:
این هرم با عنوان The Automation Maturity Pyramid روشی از David Ingraham برای ارزیابی بلوغ اتوماسیون تست در چهار مرحله است: ایجاد اعتماد به نتایج تست‌ها، بازخورد کوتاه‌مدت و سریع در جریان توسعه، افزایش سرعت توسعه با تکیه بر تست‌های پایدار، و در نهایت بازخورد بلندمدت برای حفظ کیفیت در گذر زمان. ایده اصلی این است که اتوماسیون باید هدفمند باشد: ابتدا تست‌های قابل‌اعتماد و غیرلغزان برای مسیرهای حیاتی بسازیم، سپس بازخورد سریع در CI و روی هر تغییر فراهم کنیم، بعد با کاهش زمان چرخه و افزایش اطمینان، توسعه را شتاب دهیم، و در پایان با چک‌های دوره‌ای، سنجه‌های عملکرد و نشانه‌های تولید، سلامت بلندمدت سیستم را پایش کنیم. این چارچوب به تیم‌ها کمک می‌کند شکاف‌ها را بشناسند، سرمایه‌گذاری‌ها را اولویت‌بندی کنند و از دام‌هایی مثل تمرکز زودهنگام بر پوشش یا سرعت بدون اعتماد پرهیز کنند.
#TestAutomation #AutomationMaturity #SoftwareTesting #QualityEngineering #DevOps #CICD #FeedbackLoops #SoftwareDelivery
🟣لینک مقاله:
https://cur.at/syMd8RG?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
The Automation Maturity Pyramid
🟢 خلاصه مقاله:
این هرم با عنوان The Automation Maturity Pyramid روشی از David Ingraham برای ارزیابی بلوغ اتوماسیون تست در چهار مرحله است: ایجاد اعتماد به نتایج تست‌ها، بازخورد کوتاه‌مدت و سریع در جریان توسعه، افزایش سرعت توسعه با تکیه بر تست‌های پایدار، و در نهایت بازخورد بلندمدت برای حفظ کیفیت در گذر زمان. ایده اصلی این است که اتوماسیون باید هدفمند باشد: ابتدا تست‌های قابل‌اعتماد و غیرلغزان برای مسیرهای حیاتی بسازیم، سپس بازخورد سریع در CI و روی هر تغییر فراهم کنیم، بعد با کاهش زمان چرخه و افزایش اطمینان، توسعه را شتاب دهیم، و در پایان با چک‌های دوره‌ای، سنجه‌های عملکرد و نشانه‌های تولید، سلامت بلندمدت سیستم را پایش کنیم. این چارچوب به تیم‌ها کمک می‌کند شکاف‌ها را بشناسند، سرمایه‌گذاری‌ها را اولویت‌بندی کنند و از دام‌هایی مثل تمرکز زودهنگام بر پوشش یا سرعت بدون اعتماد پرهیز کنند.
#TestAutomation #AutomationMaturity #SoftwareTesting #QualityEngineering #DevOps #CICD #FeedbackLoops #SoftwareDelivery
🟣لینک مقاله:
https://cur.at/syMd8RG?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
The Automation Maturity Pyramid
How effective is your automation test suite? How impactful is it for your product and your team? Do you know how to grow your test suite…
Forwarded from Bardia & Erfan
♨️ راز خواب 12 ساعته پاول دورف؛ جایی که ایده‌های تلگرام شکل می‌گیرن!
▪️پاول دورف، مدیرعامل تلگرام، گفته روزی بین ۱۱ تا ۱۲ ساعت می‌خوابه ، و جالبه که اینو نه تنبلی، بلکه منبع اصلی ایده‌های درخشانش می‌دونه!
▪️دورف صبح‌ها حتی سراغ گوشی هم نمی‌ره، چون معتقده موبایل‌ها جلوی تفکر مستقل رو می‌گیرن.
خودش می‌گه:
♨️ راز خواب 12 ساعته پاول دورف؛ جایی که ایده‌های تلگرام شکل می‌گیرن!
▪️پاول دورف، مدیرعامل تلگرام، گفته روزی بین ۱۱ تا ۱۲ ساعت می‌خوابه ، و جالبه که اینو نه تنبلی، بلکه منبع اصلی ایده‌های درخشانش می‌دونه!
▪️دورف صبح‌ها حتی سراغ گوشی هم نمی‌ره، چون معتقده موبایل‌ها جلوی تفکر مستقل رو می‌گیرن.
خودش می‌گه:
«می‌خوام خودم تصمیم بگیرم چی تو زندگیم مهمه، نه اینکه شرکت‌ها یا الگوریتم‌ها برام تعیین کنن.»
🔵 عنوان مقاله
This one feature from Cypress I didn't know I needed
🟢 خلاصه مقاله:
کنیت Bati تجربه‌ی مهاجرت یک مجموعه تست انتها‌به‌انتها از Cypress به Playwright را روایت می‌کند و نشان می‌دهد تفاوت‌های کوچک چقدر در کار روزمره اثر دارند. مهم‌ترین غافلگیری او فقدان همان قابلیت «گزارش فرمان‌ها با عکس‌های لحظه‌ای DOM و زمان‌گردانی» در Cypress بود؛ قابلیتی که عیب‌یابی ناپایداری و اشکالات انتخاب‌گرها را بسیار سریع می‌کرد.
در Playwright او با فعال‌کردن Trace Viewer، استفاده هدفمند از trace در CI، تکیه بر auto-waiting و assertionهای دقیق‌تر، و افزودن خروجی‌های کمکی (لاگ شبکه، اسکرین‌شات‌های هدفمند) بیشترِ آن بازخورد را جبران کرد. با استاندارد کردن test idها و کمی بازطراحی تست‌ها برای حذف فرض‌های زمانی، جریان کاری جدید شکل گرفت و در نهایت با سرعت اجرای بالاتر به پایداری مشابه رسیدند.
جمع‌بندی: هیچ‌کدام بر دیگری مطلقاً برتری ندارند؛ اما ارگونومی ابزار سرعت تیم را می‌سازد. در مهاجرت، زمان بگذارید تا چرخه‌های بازخورد محبوب‌تان را بازسازی کنید و جاهایی که همتای مستقیم ندارند، عادت‌های جدید بسازید. این‌گونه می‌توان مزایای Playwright را به‌دست آورد بدون از دست دادن تجربه توسعه‌دهنده‌ای که با Cypress داشتید.
#Cypress #Playwright #E2ETesting #TestAutomation #Migration #QA #JavaScript
🟣لینک مقاله:
https://cur.at/ZiBGzOL?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
This one feature from Cypress I didn't know I needed
🟢 خلاصه مقاله:
کنیت Bati تجربه‌ی مهاجرت یک مجموعه تست انتها‌به‌انتها از Cypress به Playwright را روایت می‌کند و نشان می‌دهد تفاوت‌های کوچک چقدر در کار روزمره اثر دارند. مهم‌ترین غافلگیری او فقدان همان قابلیت «گزارش فرمان‌ها با عکس‌های لحظه‌ای DOM و زمان‌گردانی» در Cypress بود؛ قابلیتی که عیب‌یابی ناپایداری و اشکالات انتخاب‌گرها را بسیار سریع می‌کرد.
در Playwright او با فعال‌کردن Trace Viewer، استفاده هدفمند از trace در CI، تکیه بر auto-waiting و assertionهای دقیق‌تر، و افزودن خروجی‌های کمکی (لاگ شبکه، اسکرین‌شات‌های هدفمند) بیشترِ آن بازخورد را جبران کرد. با استاندارد کردن test idها و کمی بازطراحی تست‌ها برای حذف فرض‌های زمانی، جریان کاری جدید شکل گرفت و در نهایت با سرعت اجرای بالاتر به پایداری مشابه رسیدند.
جمع‌بندی: هیچ‌کدام بر دیگری مطلقاً برتری ندارند؛ اما ارگونومی ابزار سرعت تیم را می‌سازد. در مهاجرت، زمان بگذارید تا چرخه‌های بازخورد محبوب‌تان را بازسازی کنید و جاهایی که همتای مستقیم ندارند، عادت‌های جدید بسازید. این‌گونه می‌توان مزایای Playwright را به‌دست آورد بدون از دست دادن تجربه توسعه‌دهنده‌ای که با Cypress داشتید.
#Cypress #Playwright #E2ETesting #TestAutomation #Migration #QA #JavaScript
🟣لینک مقاله:
https://cur.at/ZiBGzOL?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
This one feature from Cypress I didn’t know I needed
So a couple of months ago I wrote an article about the start of our journey with the migration of our tests from Cypress to Playwright. And…
❤1
🔵 عنوان مقاله
Contain or be contained: The security imperative of controlling autonomous AI (4 minute read)
🟢 خلاصه مقاله:
امنیت سایبری وارد مرحله‌ای شده که نبردها با سرعت ماشین انجام می‌شوند؛ حملات مبتنی بر AI می‌توانند در چند میلی‌ثانیه شبکه‌ها را کاوش کنند، زنجیره‌ای از سوءاستفاده‌ها بسازند و زیرساخت‌های حیاتی را دستکاری کنند، در حالی‌که عملیات انسانی برای دیدن الگوهای هماهنگ، ساعت‌ها زمان می‌برد. نویسنده می‌گوید تمرکز بر «اخلاقی کردن» AI راه‌حل عملی نیست؛ باید AI را مهار کرد: سیستم‌های احتمالاتی را آزاد بگذاریم اما فقط در مرزهای کنترلی قطعی و غیرقابل‌انعطاف. مهار مؤثر یعنی معماری چندلایه با least privilege و قابلیت‌محور، اجرای sandbox، policy engineهای ازپیش‌تعریف‌شده، بررسی مداوم قواعد و محدودیت‌ها، پایش بلادرنگ، tripwire و circuit breaker خودکار، ثبت و ممیزی کامل، امکان rollback فوری و ایزوله‌سازی control plane بر مبنای اصول zero trust و attestation. در این الگو، انسان از حلقه واکنش لحظه‌ای بیرون می‌آید اما در حلقه راهبردی باقی می‌ماند: تعیین هدف، سیاست‌گذاری، تنظیم ریسک و بازبینی نتایج، در حالی‌که ماشین‌ها پاسخ‌های سریع را فقط در مرزهای سخت اجرا می‌کنند. پیام اصلی روشن است: یا مهار می‌کنید یا مهار می‌شوید؛ برای حفاظت از زیرساخت‌های حیاتی باید همین امروز مهار عملی و قابل‌راستی‌آزمایی را پیاده‌سازی کنیم.
#Cybersecurity #AI #AutonomousAgents #Containment #ZeroTrust #CriticalInfrastructure #SecurityArchitecture #MachineSpeed
🟣لینک مقاله:
https://cyberscoop.com/security-automonous-ai-threat-response/?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Contain or be contained: The security imperative of controlling autonomous AI (4 minute read)
🟢 خلاصه مقاله:
امنیت سایبری وارد مرحله‌ای شده که نبردها با سرعت ماشین انجام می‌شوند؛ حملات مبتنی بر AI می‌توانند در چند میلی‌ثانیه شبکه‌ها را کاوش کنند، زنجیره‌ای از سوءاستفاده‌ها بسازند و زیرساخت‌های حیاتی را دستکاری کنند، در حالی‌که عملیات انسانی برای دیدن الگوهای هماهنگ، ساعت‌ها زمان می‌برد. نویسنده می‌گوید تمرکز بر «اخلاقی کردن» AI راه‌حل عملی نیست؛ باید AI را مهار کرد: سیستم‌های احتمالاتی را آزاد بگذاریم اما فقط در مرزهای کنترلی قطعی و غیرقابل‌انعطاف. مهار مؤثر یعنی معماری چندلایه با least privilege و قابلیت‌محور، اجرای sandbox، policy engineهای ازپیش‌تعریف‌شده، بررسی مداوم قواعد و محدودیت‌ها، پایش بلادرنگ، tripwire و circuit breaker خودکار، ثبت و ممیزی کامل، امکان rollback فوری و ایزوله‌سازی control plane بر مبنای اصول zero trust و attestation. در این الگو، انسان از حلقه واکنش لحظه‌ای بیرون می‌آید اما در حلقه راهبردی باقی می‌ماند: تعیین هدف، سیاست‌گذاری، تنظیم ریسک و بازبینی نتایج، در حالی‌که ماشین‌ها پاسخ‌های سریع را فقط در مرزهای سخت اجرا می‌کنند. پیام اصلی روشن است: یا مهار می‌کنید یا مهار می‌شوید؛ برای حفاظت از زیرساخت‌های حیاتی باید همین امروز مهار عملی و قابل‌راستی‌آزمایی را پیاده‌سازی کنیم.
#Cybersecurity #AI #AutonomousAgents #Containment #ZeroTrust #CriticalInfrastructure #SecurityArchitecture #MachineSpeed
🟣لینک مقاله:
https://cyberscoop.com/security-automonous-ai-threat-response/?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
CyberScoop
Contain or be contained: The security imperative of controlling autonomous AI
The most secure and resilient AI systems will be those with minimal direct human interaction, the CEO of Owl Cyber Defense argues.
🔵 عنوان مقاله
Supercharging Test Automation with Java Faker: Generating Realistic Test Data
🟢 خلاصه مقاله:
با استفاده از داده‌های واقع‌نما، تست‌ها خطاهای پنهان را بهتر آشکار می‌کنند و از شکنندگی ناشی از مقادیر ثابت دور می‌مانند. Java Faker یک کتابخانه سبک در Java است که نام، آدرس، ایمیل، داده‌های اینترنتی، تاریخ و زمان و موارد دیگر را با پشتیبانی از locale تولید می‌کند و با قابلیت seed، توازن میان واقع‌نمایی و تکرارپذیری را فراهم می‌سازد. این ابزار به‌سادگی در واحدتست‌ها و سناریوهای API و UI با JUnit، TestNG، Selenium و REST Assured ترکیب می‌شود تا فرم‌ها را با داده‌های معتبر پر کند و payloadهای واقعی بسازد. بهترین رویه‌ها شامل کنترل تصادفی بودن با seed، تطبیق با قوانین و قیود دامنه، حفظ یکپارچگی داده، تولید موارد مرزی و منفی، بومی‌سازی و پرهیز از تصادفی‌سازی بیش‌ازحد است. نتیجه، پوشش بهتر، پایداری بیشتر و نگهداری آسان‌تر است. Sajith Dilshan در این مرور نشان می‌دهد چگونه با تکیه بر Java Faker می‌توان خودکارسازی تست را توانمندتر کرد.
#TestAutomation #JavaFaker #TestData #SoftwareTesting #QA #Selenium #APITesting
🟣لینک مقاله:
https://cur.at/GmPnbFy?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Supercharging Test Automation with Java Faker: Generating Realistic Test Data
🟢 خلاصه مقاله:
با استفاده از داده‌های واقع‌نما، تست‌ها خطاهای پنهان را بهتر آشکار می‌کنند و از شکنندگی ناشی از مقادیر ثابت دور می‌مانند. Java Faker یک کتابخانه سبک در Java است که نام، آدرس، ایمیل، داده‌های اینترنتی، تاریخ و زمان و موارد دیگر را با پشتیبانی از locale تولید می‌کند و با قابلیت seed، توازن میان واقع‌نمایی و تکرارپذیری را فراهم می‌سازد. این ابزار به‌سادگی در واحدتست‌ها و سناریوهای API و UI با JUnit، TestNG، Selenium و REST Assured ترکیب می‌شود تا فرم‌ها را با داده‌های معتبر پر کند و payloadهای واقعی بسازد. بهترین رویه‌ها شامل کنترل تصادفی بودن با seed، تطبیق با قوانین و قیود دامنه، حفظ یکپارچگی داده، تولید موارد مرزی و منفی، بومی‌سازی و پرهیز از تصادفی‌سازی بیش‌ازحد است. نتیجه، پوشش بهتر، پایداری بیشتر و نگهداری آسان‌تر است. Sajith Dilshan در این مرور نشان می‌دهد چگونه با تکیه بر Java Faker می‌توان خودکارسازی تست را توانمندتر کرد.
#TestAutomation #JavaFaker #TestData #SoftwareTesting #QA #Selenium #APITesting
🟣لینک مقاله:
https://cur.at/GmPnbFy?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
❤1
🔵 عنوان مقاله
Full Pipeline: Appium + WebdriverIO + BrowserStack + GitHub Actions for Native Mobile Tests
🟢 خلاصه مقاله:
این ویدئوی ۱۵ دقیقه‌ای از Joan Esquivel Montero یک مسیر کامل و فشرده برای خودکارسازی تست‌های اپلیکیشن‌های بومی موبایل نشان می‌دهد: اجرای تست‌ها با Appium، مدیریت و نگارش تست‌ها با WebdriverIO، اجرای گسترده روی دستگاه‌های واقعی در BrowserStack، و یکپارچه‌سازی فرآیند در GitHub Actions.
در ویدئو نحوه پیکربندی WebdriverIO + Appium، ساختاردهی تست‌ها با Page Object Model، انتخاب سلکتورهای پایدار و مدیریت هوشمند انتظارها برای کاهش فلاکی توضیح داده می‌شود. سپس اجرای ابری در BrowserStack را می‌بینید: آپلود بیلد، تعریف capabilities برای دستگاه‌ها و نسخه‌های مختلف، موازی‌سازی و استفاده از ویدئو/لاگ/اسکرین‌شات برای دیباگ سریع.
در بخش CI/CD، یک Workflow در GitHub Actions روی Push و Pull Request اجرا می‌شود، وابستگی‌ها را نصب و کش می‌کند، با Secrets امن به BrowserStack وصل می‌شود، با ماتریس Job تست‌ها را گسترش می‌دهد و گزارش‌ها را به‌صورت Artifact ذخیره می‌کند تا وضعیت مرج‌ها کنترل شود. نکات عملی مثل Retry، بهبود همگام‌سازی شبکه، استفاده از Environment Variables، تمایز اجرای محلی و ریموت، و BrowserStack Local برای محیط‌های داخلی نیز پوشش داده می‌شود. خروجی، یک پایپ‌لاین مقیاس‌پذیر و قابل‌انتقال است که بازخورد قابل‌اعتماد را برای هر تغییر فراهم می‌کند.
#Appium #WebdriverIO #BrowserStack #GitHubActions #MobileTesting #TestAutomation #CICD #NativeApps
🟣لینک مقاله:
https://cur.at/GI1n0KX?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Full Pipeline: Appium + WebdriverIO + BrowserStack + GitHub Actions for Native Mobile Tests
🟢 خلاصه مقاله:
این ویدئوی ۱۵ دقیقه‌ای از Joan Esquivel Montero یک مسیر کامل و فشرده برای خودکارسازی تست‌های اپلیکیشن‌های بومی موبایل نشان می‌دهد: اجرای تست‌ها با Appium، مدیریت و نگارش تست‌ها با WebdriverIO، اجرای گسترده روی دستگاه‌های واقعی در BrowserStack، و یکپارچه‌سازی فرآیند در GitHub Actions.
در ویدئو نحوه پیکربندی WebdriverIO + Appium، ساختاردهی تست‌ها با Page Object Model، انتخاب سلکتورهای پایدار و مدیریت هوشمند انتظارها برای کاهش فلاکی توضیح داده می‌شود. سپس اجرای ابری در BrowserStack را می‌بینید: آپلود بیلد، تعریف capabilities برای دستگاه‌ها و نسخه‌های مختلف، موازی‌سازی و استفاده از ویدئو/لاگ/اسکرین‌شات برای دیباگ سریع.
در بخش CI/CD، یک Workflow در GitHub Actions روی Push و Pull Request اجرا می‌شود، وابستگی‌ها را نصب و کش می‌کند، با Secrets امن به BrowserStack وصل می‌شود، با ماتریس Job تست‌ها را گسترش می‌دهد و گزارش‌ها را به‌صورت Artifact ذخیره می‌کند تا وضعیت مرج‌ها کنترل شود. نکات عملی مثل Retry، بهبود همگام‌سازی شبکه، استفاده از Environment Variables، تمایز اجرای محلی و ریموت، و BrowserStack Local برای محیط‌های داخلی نیز پوشش داده می‌شود. خروجی، یک پایپ‌لاین مقیاس‌پذیر و قابل‌انتقال است که بازخورد قابل‌اعتماد را برای هر تغییر فراهم می‌کند.
#Appium #WebdriverIO #BrowserStack #GitHubActions #MobileTesting #TestAutomation #CICD #NativeApps
🟣لینک مقاله:
https://cur.at/GI1n0KX?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
YouTube
Full Pipeline: Appium + WebdriverIO + BrowserStack + GitHub Actions for Native Mobile Tests
In this video, I’ll walk you through the complete pipeline for mobile automation — from upgrading to Appium 3 and setting up dependencies, to running tests locally on iOS, and finally scaling them with BrowserStack and GitHub Actions CI/CD using an Android…
🔵 عنوان مقاله
AI + Chrome DevTools MCP: Trace, Analyse, Fix Performance
🟢 خلاصه مقاله:
این مقاله از Sławomir Radzymiński نشان می‌دهد چگونه می‌توان با تکیه بر AI و Chrome DevTools MCP مسیر «ردیابی، تحلیل و رفع» مشکلات کارایی وب را کوتاه کرد. نویسنده ابتدا کارکرد Chrome DevTools MCP را برای دسترسی به داده‌های کم‌سطح مرورگر و تبدیل آن‌ها به راهنمای عملی توضیح می‌دهد، سپس آن را با Playwright MCP مقایسه می‌کند: اولی برای تشخیص عمیق و لحظه‌ای در خود مرورگر مناسب است، دومی برای سناریوهای انتها‌به‌انتها، بازتولید پایدار و پایش در CI. جمع‌بندی مقاله راهنمایی می‌کند که چه زمانی از هرکدام استفاده کنید و چگونه با ترکیب آن‌ها، مشکل را بازتولید، ریشه‌یابی، اصلاح و در نهایت به‌صورت خودکار تأیید کنید.
#WebPerformance #ChromeDevTools #MCP #Playwright #AIForDevelopers #Tracing #PerformanceTesting
🟣لینک مقاله:
https://cur.at/BXEl5JE?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
AI + Chrome DevTools MCP: Trace, Analyse, Fix Performance
🟢 خلاصه مقاله:
این مقاله از Sławomir Radzymiński نشان می‌دهد چگونه می‌توان با تکیه بر AI و Chrome DevTools MCP مسیر «ردیابی، تحلیل و رفع» مشکلات کارایی وب را کوتاه کرد. نویسنده ابتدا کارکرد Chrome DevTools MCP را برای دسترسی به داده‌های کم‌سطح مرورگر و تبدیل آن‌ها به راهنمای عملی توضیح می‌دهد، سپس آن را با Playwright MCP مقایسه می‌کند: اولی برای تشخیص عمیق و لحظه‌ای در خود مرورگر مناسب است، دومی برای سناریوهای انتها‌به‌انتها، بازتولید پایدار و پایش در CI. جمع‌بندی مقاله راهنمایی می‌کند که چه زمانی از هرکدام استفاده کنید و چگونه با ترکیب آن‌ها، مشکل را بازتولید، ریشه‌یابی، اصلاح و در نهایت به‌صورت خودکار تأیید کنید.
#WebPerformance #ChromeDevTools #MCP #Playwright #AIForDevelopers #Tracing #PerformanceTesting
🟣لینک مقاله:
https://cur.at/BXEl5JE?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Awesome Testing
AI + Chrome DevTools MCP: Trace, Analyse, Fix Performance
How DevTools MCP enables AI agents to record real performance traces (LCP/CLS/TBT), analyse them, and apply fixes—bringing Lighthouse-style audits into an iterative debugging session. Notes on INP (field) vs TBT (lab) included.