🔵 عنوان مقاله
Power pairing our people process: How we moved to a collaborative QA Engineer and QA Analyst model
🟢 خلاصه مقاله:
** این مقاله نشان میدهد که با جفت‌کردن نقشهای مکمل در کیفیت، یعنی QA Engineer و QA Analyst، می‌توان کیفیت را از یک مرحله انتهایی به یک فعالیت پیوسته و مشارکتی در دل فرایند توسعه تبدیل کرد. بر اساس ایده‌های Matthew Whitaker و همسو با فلسفه pair-programming، QA Engineer روی اتوماسیون، ابزارها و CI/CD تمرکز می‌کند و QA Analyst بر تحلیل نیازمندی‌ها، آزمون اکتشافی و مدیریت ریسک؛ و همکاری نزدیک آن‌ها شکاف‌های فنی و محصولی را کاهش میدهد. این جفت به‌صورت مشترک معیارهای پذیرش و استراتژی آزمون را می‌نویسد، بین نقش «راننده/راهنما» جابه‌جا می‌شود و یافته‌های اکتشافی را سریع به تست‌های خودکار قابل نگهداری تبدیل می‌کند. پیاده‌سازی موفق با یک پایلوت، برنامه pairing شفاف، ابزارهای دیدپذیری، و سنجه‌هایی مانند نرخ خطای فرار، زمان چرخه و نرخ بازکار آغاز می‌شود و با مدیریت چالش‌هایی مانند ابهام نقش و خستگی جلسات از طریق RACI سبک، پلی‌بوک، تایم‌باکس و آداب pairing تثبیت می‌شود. دستاوردها شامل بازخورد سریع‌تر، کاهش خطاهای فرار، مالکیت مشترک کیفیت و انتقال دانش گسترده‌تر در تیم است؛ همان درسی که از pair-programming می‌گیریم: دو ذهن مکمل، از یک متخصص تنها مؤثرترند.
#QA #PairProgramming #QualityAssurance #AgileTesting #Collaboration #DevOps #TestAutomation #TeamCulture
🟣لینک مقاله:
https://cur.at/EuZObTr?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Power pairing our people process: How we moved to a collaborative QA Engineer and QA Analyst model
🟢 خلاصه مقاله:
** این مقاله نشان میدهد که با جفت‌کردن نقشهای مکمل در کیفیت، یعنی QA Engineer و QA Analyst، می‌توان کیفیت را از یک مرحله انتهایی به یک فعالیت پیوسته و مشارکتی در دل فرایند توسعه تبدیل کرد. بر اساس ایده‌های Matthew Whitaker و همسو با فلسفه pair-programming، QA Engineer روی اتوماسیون، ابزارها و CI/CD تمرکز می‌کند و QA Analyst بر تحلیل نیازمندی‌ها، آزمون اکتشافی و مدیریت ریسک؛ و همکاری نزدیک آن‌ها شکاف‌های فنی و محصولی را کاهش میدهد. این جفت به‌صورت مشترک معیارهای پذیرش و استراتژی آزمون را می‌نویسد، بین نقش «راننده/راهنما» جابه‌جا می‌شود و یافته‌های اکتشافی را سریع به تست‌های خودکار قابل نگهداری تبدیل می‌کند. پیاده‌سازی موفق با یک پایلوت، برنامه pairing شفاف، ابزارهای دیدپذیری، و سنجه‌هایی مانند نرخ خطای فرار، زمان چرخه و نرخ بازکار آغاز می‌شود و با مدیریت چالش‌هایی مانند ابهام نقش و خستگی جلسات از طریق RACI سبک، پلی‌بوک، تایم‌باکس و آداب pairing تثبیت می‌شود. دستاوردها شامل بازخورد سریع‌تر، کاهش خطاهای فرار، مالکیت مشترک کیفیت و انتقال دانش گسترده‌تر در تیم است؛ همان درسی که از pair-programming می‌گیریم: دو ذهن مکمل، از یک متخصص تنها مؤثرترند.
#QA #PairProgramming #QualityAssurance #AgileTesting #Collaboration #DevOps #TestAutomation #TeamCulture
🟣لینک مقاله:
https://cur.at/EuZObTr?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Ministry of Testing
Power pairing our people process: How we moved to a collaborative QA Engineer and QA Analyst model
Pairing QA Engineers and Analysts isn't just a process tweak, it's a cultural shift that transforms siloed testing into a collaborative, balanced and business-aligned effort.
تفاوت Access Token و Refresh Token به زبان ساده
در سیستم‌های احراز هویت مدرن مثل Keycloak یا IdentityServer،
دوبار اسم «توکن» رو می‌شنویم:
ولی واقعاً فرقشون چیه؟
Access Token
توکن کوتاه‌مدتیه (مثلاً ۵ تا ۱۵ دقیقه) که بعد از لاگین کاربر صادر میشه.
هر بار که کاربر به API درخواست می‌فرسته، این توکن همراه درخواست میره تا سرور بفهمه کاربر کیه.
Refresh Token
طول عمر بیشتری داره (مثلاً ۳۰ دقیقه یا حتی چند ساعت).
اگر Access Token منقضی بشه، سیستم با استفاده از Refresh Token یه Access Token جدید می‌گیره
— بدون اینکه کاربر مجبور باشه دوباره لاگین کنه.
به زبان ساده Access Token مثل بلیط ورود به یک سالن هست ️
اما Refresh Token مثل کارت عضویت اون سالنه
باهاش می‌تونی هر بار بلیط جدید بگیری بدون ایستادن تو صف لاگین.
مزیت این روش:
امنیت بیشتر (Access Token کوتاه‌مدت و ایمن‌تره)
تجربه کاربری بهتر (کاربر کمتر لاگ‌اوت میشه)
کنترل بهتر سمت سرور روی اعتبار توکن‌ها
در پروژه‌ی اخیرم با Keycloak این مکانیزم رو پیاده‌سازی کردم.
کاربر بعد از ثبت‌نام، هم در Keycloak و هم در SQL Server ذخیره میشه تا
میان سیستم احراز هویت و اپلیکیشن اصلی یکپارچگی کامل برقرار باشه.
هر وقت در مورد Authentication کار می‌کنی،
یادت باشه که هدف فقط «ورود کاربر» نیست —
بلکه «مدیریت ایمن و هوشمند عمر نشست (Session Lifecycle)» هست.
در دنیای Api ها ما موظفیم با توکن ها کار کنیم
در ریزور پیج ها یک ورودی هیدن داشتیم که مدیریت توسط آن توسط خود asp بود
اما در api ها مدیریت توکن ها با ماست
بهترین گزینه هم استفاده از IDP (Identity Provider) هاست چون هم فرانت و هم بک را برای ما پوشش میدهد.
<Hossein Molaei/>
در سیستم‌های احراز هویت مدرن مثل Keycloak یا IdentityServer،
دوبار اسم «توکن» رو می‌شنویم:
ولی واقعاً فرقشون چیه؟
Access Token
توکن کوتاه‌مدتیه (مثلاً ۵ تا ۱۵ دقیقه) که بعد از لاگین کاربر صادر میشه.
هر بار که کاربر به API درخواست می‌فرسته، این توکن همراه درخواست میره تا سرور بفهمه کاربر کیه.
Refresh Token
طول عمر بیشتری داره (مثلاً ۳۰ دقیقه یا حتی چند ساعت).
اگر Access Token منقضی بشه، سیستم با استفاده از Refresh Token یه Access Token جدید می‌گیره
— بدون اینکه کاربر مجبور باشه دوباره لاگین کنه.
به زبان ساده Access Token مثل بلیط ورود به یک سالن هست ️
اما Refresh Token مثل کارت عضویت اون سالنه
باهاش می‌تونی هر بار بلیط جدید بگیری بدون ایستادن تو صف لاگین.
مزیت این روش:
امنیت بیشتر (Access Token کوتاه‌مدت و ایمن‌تره)
تجربه کاربری بهتر (کاربر کمتر لاگ‌اوت میشه)
کنترل بهتر سمت سرور روی اعتبار توکن‌ها
در پروژه‌ی اخیرم با Keycloak این مکانیزم رو پیاده‌سازی کردم.
کاربر بعد از ثبت‌نام، هم در Keycloak و هم در SQL Server ذخیره میشه تا
میان سیستم احراز هویت و اپلیکیشن اصلی یکپارچگی کامل برقرار باشه.
هر وقت در مورد Authentication کار می‌کنی،
یادت باشه که هدف فقط «ورود کاربر» نیست —
بلکه «مدیریت ایمن و هوشمند عمر نشست (Session Lifecycle)» هست.
در دنیای Api ها ما موظفیم با توکن ها کار کنیم
در ریزور پیج ها یک ورودی هیدن داشتیم که مدیریت توسط آن توسط خود asp بود
اما در api ها مدیریت توکن ها با ماست
بهترین گزینه هم استفاده از IDP (Identity Provider) هاست چون هم فرانت و هم بک را برای ما پوشش میدهد.
<Hossein Molaei/>
❤1
🔵 عنوان مقاله
When Tests Start Drawing the Map
🟢 خلاصه مقاله:
** در دنیای واقعی توسعه، محیط‌های تست به‌ندرت کامل‌اند: اطلاعات ناقص است، وابستگی‌ها تغییر می‌کنند و قطعیت کم است. Charlie Kingston پیشنهاد می‌کند به تست مثل «نقشه‌کش» نگاه کنیم؛ هر تست یک کاوش است که مرزها، خطرها و رفتارهای واقعی سیستم را روشن می‌کند و نقشهای زنده از آنچه می‌دانیم می‌سازد.
با بیان شفاف فرضیه‌ها و تبدیلشان به تست، استفاده از ابزارهـای مشاهده‌پذیری برای رفع نقاط کور، ایجاد چرخه‌های بازخورد سریع و اولویت‌بندی ریسک (مسیرهای بحرانی، حالت‌های خرابی، و درزهای یکپارچه‌سازی)، این نقشه قابل اعتماد می‌شود. تست‌ها فقط دروازه انتشار نیستند؛ دانسته‌های تیم را مستند می‌کنند، قراردادهای بین سرویس‌ها را شفاف می‌سازند و بازطراحی امن را ممکن می‌کنند. با هر تغییر، تست‌ها نشان می‌دهند کجا نقشه با واقعیت نمی‌خواند و باید دقیق‌تر بررسی شود.
ترکیبی از روش‌ها این نقشه را کامل‌تر می‌کند: Contract Testها برای انتظارات بین سرویس‌ها، Property-based Testing برای پوشش لبه‌ها، تست اکتشافی برای کشف ناشناخته‌ها، و پایش مصنوعی در محیط اجرا برای تشخیص تغییر رفتار. پیام نهایی: منتظر مشخصات کامل نمانید؛ با تست، نقشه را همزمان با حرکت ترسیم کنید تا عدم‌قطعیت کاهش یابد و کیفیت با اطمینان بیشتری ارائه شود.
#تست_نرم‌افزار #کیفیت #بازخورد_سریع #مدیریت_ریسک #Observability #مهندسی_نرم‌افزار #توسعه_چابک #QA
🟣لینک مقاله:
https://cur.at/m1egK0h?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
When Tests Start Drawing the Map
🟢 خلاصه مقاله:
** در دنیای واقعی توسعه، محیط‌های تست به‌ندرت کامل‌اند: اطلاعات ناقص است، وابستگی‌ها تغییر می‌کنند و قطعیت کم است. Charlie Kingston پیشنهاد می‌کند به تست مثل «نقشه‌کش» نگاه کنیم؛ هر تست یک کاوش است که مرزها، خطرها و رفتارهای واقعی سیستم را روشن می‌کند و نقشهای زنده از آنچه می‌دانیم می‌سازد.
با بیان شفاف فرضیه‌ها و تبدیلشان به تست، استفاده از ابزارهـای مشاهده‌پذیری برای رفع نقاط کور، ایجاد چرخه‌های بازخورد سریع و اولویت‌بندی ریسک (مسیرهای بحرانی، حالت‌های خرابی، و درزهای یکپارچه‌سازی)، این نقشه قابل اعتماد می‌شود. تست‌ها فقط دروازه انتشار نیستند؛ دانسته‌های تیم را مستند می‌کنند، قراردادهای بین سرویس‌ها را شفاف می‌سازند و بازطراحی امن را ممکن می‌کنند. با هر تغییر، تست‌ها نشان می‌دهند کجا نقشه با واقعیت نمی‌خواند و باید دقیق‌تر بررسی شود.
ترکیبی از روش‌ها این نقشه را کامل‌تر می‌کند: Contract Testها برای انتظارات بین سرویس‌ها، Property-based Testing برای پوشش لبه‌ها، تست اکتشافی برای کشف ناشناخته‌ها، و پایش مصنوعی در محیط اجرا برای تشخیص تغییر رفتار. پیام نهایی: منتظر مشخصات کامل نمانید؛ با تست، نقشه را همزمان با حرکت ترسیم کنید تا عدم‌قطعیت کاهش یابد و کیفیت با اطمینان بیشتری ارائه شود.
#تست_نرم‌افزار #کیفیت #بازخورد_سریع #مدیریت_ریسک #Observability #مهندسی_نرم‌افزار #توسعه_چابک #QA
🟣لینک مقاله:
https://cur.at/m1egK0h?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
When Tests Start Drawing the Map
How tests that explore become documentation you can trust
❤1
🔵 عنوان مقاله
Apple alerts exploit developer that his iPhone was targeted with government spyware (4 minute read)
🟢 خلاصه مقاله:
اپل به یک توسعه‌دهنده اکسپلویت iOS با نام مستعار Jay Gibson اطلاع داده که آیفون شخصی او در ماه مارس هدف جاسوس‌افزار «مزدور» قرار گرفته است؛ اتفاقی که می‌تواند نخستین مورد مستند از هدف قرار گرفتن توسعه‌دهندگان چنین ابزارهایی توسط همان طبقه از ابزارها باشد. این فرد چند هفته قبل از دریافت هشدار، از شرکت Trenchant (زیرمجموعه L3Harris) اخراج شده بود؛ به اتهام افشای زیرو-دی‌های Chrome، اتهامی که او و همکاران سابقش رد می‌کنند. اپل معمولاً جزئیات فنی یا نسبت‌دهی ارائه نمی‌دهد، اما این هشدارها نشانه خطر جدی تلقی می‌شود. این پرونده نشان میدهد استفاده از جاسوس‌افزارهای تجاری به حوزه متخصصان فنی نیز سرایت کرده و پرسش‌هایی درباره منبع حمله، انگیزه‌ها و راهکارهای حفاظتی مطرح می‌کند.
#Apple #iOS #iPhone #Spyware #MercenarySpyware #L3Harris #Trenchant #Cybersecurity
🟣لینک مقاله:
https://techcrunch.com/2025/10/21/apple-alerts-exploit-developer-that-his-iphone-was-targeted-with-government-spyware/?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Apple alerts exploit developer that his iPhone was targeted with government spyware (4 minute read)
🟢 خلاصه مقاله:
اپل به یک توسعه‌دهنده اکسپلویت iOS با نام مستعار Jay Gibson اطلاع داده که آیفون شخصی او در ماه مارس هدف جاسوس‌افزار «مزدور» قرار گرفته است؛ اتفاقی که می‌تواند نخستین مورد مستند از هدف قرار گرفتن توسعه‌دهندگان چنین ابزارهایی توسط همان طبقه از ابزارها باشد. این فرد چند هفته قبل از دریافت هشدار، از شرکت Trenchant (زیرمجموعه L3Harris) اخراج شده بود؛ به اتهام افشای زیرو-دی‌های Chrome، اتهامی که او و همکاران سابقش رد می‌کنند. اپل معمولاً جزئیات فنی یا نسبت‌دهی ارائه نمی‌دهد، اما این هشدارها نشانه خطر جدی تلقی می‌شود. این پرونده نشان میدهد استفاده از جاسوس‌افزارهای تجاری به حوزه متخصصان فنی نیز سرایت کرده و پرسش‌هایی درباره منبع حمله، انگیزه‌ها و راهکارهای حفاظتی مطرح می‌کند.
#Apple #iOS #iPhone #Spyware #MercenarySpyware #L3Harris #Trenchant #Cybersecurity
🟣لینک مقاله:
https://techcrunch.com/2025/10/21/apple-alerts-exploit-developer-that-his-iphone-was-targeted-with-government-spyware/?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
TechCrunch
Exclusive: Apple alerts exploit developer that his iPhone was targeted with government spyware
A developer at Trenchant, a leading Western spyware and zero-day maker, was suspected of leaking company tools and was fired. Weeks later, Apple notified him that his personal iPhone was targeted with spyware.
🔵 عنوان مقاله
How to Test Asynchronous Processes That Complete Hours Later
🟢 خلاصه مقاله:
** دانیل Delimata نشان میدهد چگونه با بازطراحی کوچک در سیستم و تست‌ها می‌توان فرایندهای ناهمگامی را که نتیجه‌شان ساعت‌ها بعد دیده می‌شود، به‌صورت خودکار و سریع راستی‌آزمایی کرد. رویکرد پیشنهادی بر «assertionهای در نهایت» با مهلت مشخص تکیه دارد: به‌جای sleep طولانی، رویداد را آغاز کنید و با polling یا اشتراک در خروجی‌ها (داده، رویداد، ایمیل) نتیجه را تا ضرب‌الاجل تعیین‌شده بررسی کنید. زمان را تزریق‌پذیر کنید (clock فیک)، زمان‌بندی‌ها را قابل‌پیکربندی کنید یا test hook امن برای اجرای فوری کارها فراهم کنید؛ و با شناسه‌های همبستگی و مشاهده‌پذیری (مثل OpenTelemetry) مسیر انتهابه‌انتها را رهگیری کنید. برای پایداری، هندلرهای idempotent، داده‌ی تست ایزوله و محیط‌های موقتی به کار ببرید و سطح مناسب تست (واحد، یکپارچه، انتهابه‌انتها، contract) را انتخاب کنید. در CI، مسیر سریع با زمان شتاب‌داده/هوک و مسیر آهسته شبانه‌ی واقع‌گرایانه را ترکیب کنید تا فرایندهایی که ساعت‌ها طول می‌کشند، در چند دقیقه به‌طور مطمئن تست شوند.
#AsynchronousTesting #EventualConsistency #Automation #DistributedSystems #E2ETesting #Observability #CI_CD #MessageQueues
🟣لینک مقاله:
https://cur.at/tVLKSEQ?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
How to Test Asynchronous Processes That Complete Hours Later
🟢 خلاصه مقاله:
** دانیل Delimata نشان میدهد چگونه با بازطراحی کوچک در سیستم و تست‌ها می‌توان فرایندهای ناهمگامی را که نتیجه‌شان ساعت‌ها بعد دیده می‌شود، به‌صورت خودکار و سریع راستی‌آزمایی کرد. رویکرد پیشنهادی بر «assertionهای در نهایت» با مهلت مشخص تکیه دارد: به‌جای sleep طولانی، رویداد را آغاز کنید و با polling یا اشتراک در خروجی‌ها (داده، رویداد، ایمیل) نتیجه را تا ضرب‌الاجل تعیین‌شده بررسی کنید. زمان را تزریق‌پذیر کنید (clock فیک)، زمان‌بندی‌ها را قابل‌پیکربندی کنید یا test hook امن برای اجرای فوری کارها فراهم کنید؛ و با شناسه‌های همبستگی و مشاهده‌پذیری (مثل OpenTelemetry) مسیر انتهابه‌انتها را رهگیری کنید. برای پایداری، هندلرهای idempotent، داده‌ی تست ایزوله و محیط‌های موقتی به کار ببرید و سطح مناسب تست (واحد، یکپارچه، انتهابه‌انتها، contract) را انتخاب کنید. در CI، مسیر سریع با زمان شتاب‌داده/هوک و مسیر آهسته شبانه‌ی واقع‌گرایانه را ترکیب کنید تا فرایندهایی که ساعت‌ها طول می‌کشند، در چند دقیقه به‌طور مطمئن تست شوند.
#AsynchronousTesting #EventualConsistency #Automation #DistributedSystems #E2ETesting #Observability #CI_CD #MessageQueues
🟣لینک مقاله:
https://cur.at/tVLKSEQ?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
How to Test Asynchronous Processes That Complete Hours Later
In most automated tests, we expect systems to react immediately: send a request → get a response → verify the result.
🔵 عنوان مقاله
It's Not Your Tests, It's Your Testability
🟢 خلاصه مقاله:
**
بی‌ثباتی تست‌ها همیشه تقصیر تست‌ها نیست؛ اغلب ریشه در سیستم کم‌تست‌پذیر دارد. وقتی زمان، هم‌روندی، تصادفی‌بودن یا وابستگی‌های بیرونی کنترل‌نشده باشند، تست‌ها ناپایدار می‌شوند. راه‌حل، ارتقای تست‌پذیری است: قابل‌کنترل و قابل‌مشاهده کردن سیستم، تزریق زمان و بذر تصادفی، جداسازی مرزهای شبکه با قراردادها و فیک‌ها، و هرمتیک‌کردن محیط تست. Gil Zilberfeld توصیه می‌کند برای جلب حمایت، هزینه فلیکینس را با داده نشان دهید و از بردهای کوچک (مثل افزودن seam، تزریق وابستگی برای زمان/I-O، و تست‌های قراردادی) شروع کنید. با گنجاندن تست‌پذیری در تصمیم‌های معماری و معیارهای پذیرش، تیم از آتش‌نشانی تست‌های flaky به ساخت نرم‌افزار ذاتاً تست‌پذیر و قابل‌اتکا منتقل می‌شود.
#Testability #FlakyTests #SoftwareTesting #QualityEngineering #DevOps #ContinuousIntegration #TestDesign #Observability
🟣لینک مقاله:
https://cur.at/3RbJDxt?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
It's Not Your Tests, It's Your Testability
🟢 خلاصه مقاله:
**
بی‌ثباتی تست‌ها همیشه تقصیر تست‌ها نیست؛ اغلب ریشه در سیستم کم‌تست‌پذیر دارد. وقتی زمان، هم‌روندی، تصادفی‌بودن یا وابستگی‌های بیرونی کنترل‌نشده باشند، تست‌ها ناپایدار می‌شوند. راه‌حل، ارتقای تست‌پذیری است: قابل‌کنترل و قابل‌مشاهده کردن سیستم، تزریق زمان و بذر تصادفی، جداسازی مرزهای شبکه با قراردادها و فیک‌ها، و هرمتیک‌کردن محیط تست. Gil Zilberfeld توصیه می‌کند برای جلب حمایت، هزینه فلیکینس را با داده نشان دهید و از بردهای کوچک (مثل افزودن seam، تزریق وابستگی برای زمان/I-O، و تست‌های قراردادی) شروع کنید. با گنجاندن تست‌پذیری در تصمیم‌های معماری و معیارهای پذیرش، تیم از آتش‌نشانی تست‌های flaky به ساخت نرم‌افزار ذاتاً تست‌پذیر و قابل‌اتکا منتقل می‌شود.
#Testability #FlakyTests #SoftwareTesting #QualityEngineering #DevOps #ContinuousIntegration #TestDesign #Observability
🟣لینک مقاله:
https://cur.at/3RbJDxt?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
TestinGil | By Gil Zilberfeld
It’s Not Your Tests, It’s Your Testability | TestinGil
Let's talk about that test. The one that's always flaky. The one that takes twenty minutes to run and fails for a different reason every time. Your first instinct is to blame the test. Maybe the locator is wrong, maybe the wait time isn't long enough. But…
🔵 عنوان مقاله
QA Engineer Role Transformation in the Age of AI
🟢 خلاصه مقاله:
** در عصر AI نقش مهندسان QA از اجرای دستی آزمون‌ها به طراحی و هدایت جریان‌های تضمین کیفیت هوشمند تغییر می‌کند. به‌گفته Yerem Khalatyan، بهترین نقطهٔ شروع سه کاربرد عملی است: تولید خودکار سناریوهای آزمون، تسریع در خودکارسازی، و بهینه‌سازی اجرای تست‌ها. سامانه‌های هوشمند می‌توانند با تکیه بر نیازمندی‌ها، کد و داده‌های کاربری، سناریوهای مثبت، منفی و مرزی را پیشنهاد دهند، شکاف‌های پوشش را نشان دهند و در CI/CD اولویت اجرای تست‌ها را بر مبنای ریسک و تغییرات کد تنظیم کنند. همچنین با خودترمیمی انتخابگرها، کاهش تست‌های flaky، پیشنهاد assertion و دادهٔ آزمون، و کمک به triage خطاها، هزینهٔ نگهداشت را پایین می‌آورند. در کنار این مزایا باید به محدودیت‌ها نیز توجه کرد: خطای مدلی، تفسیر نادرست نیازمندی‌های مبهم و ملاحظات امنیت و حریم خصوصی، که حضور انسان در حلقه و حاکمیت داده را ضروری می‌سازد. برای بهره‌گیری مؤثر، مهارت‌هایی مانند طراحی پرسش برای مدل، سواد داده، آزمون مبتنی بر ریسک و ادغام ابزارها اهمیت می‌یابد؛ شروع کوچک، سنجش دقیق شاخص‌ها و سپس گسترش کنترل‌شده، مسیر عملی و کم‌ریسک است.
#QA #AIinTesting #TestAutomation #SoftwareTesting #QualityEngineering #DevOps #CICD #MachineLearning
🟣لینک مقاله:
https://cur.at/lOXHasH?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
QA Engineer Role Transformation in the Age of AI
🟢 خلاصه مقاله:
** در عصر AI نقش مهندسان QA از اجرای دستی آزمون‌ها به طراحی و هدایت جریان‌های تضمین کیفیت هوشمند تغییر می‌کند. به‌گفته Yerem Khalatyan، بهترین نقطهٔ شروع سه کاربرد عملی است: تولید خودکار سناریوهای آزمون، تسریع در خودکارسازی، و بهینه‌سازی اجرای تست‌ها. سامانه‌های هوشمند می‌توانند با تکیه بر نیازمندی‌ها، کد و داده‌های کاربری، سناریوهای مثبت، منفی و مرزی را پیشنهاد دهند، شکاف‌های پوشش را نشان دهند و در CI/CD اولویت اجرای تست‌ها را بر مبنای ریسک و تغییرات کد تنظیم کنند. همچنین با خودترمیمی انتخابگرها، کاهش تست‌های flaky، پیشنهاد assertion و دادهٔ آزمون، و کمک به triage خطاها، هزینهٔ نگهداشت را پایین می‌آورند. در کنار این مزایا باید به محدودیت‌ها نیز توجه کرد: خطای مدلی، تفسیر نادرست نیازمندی‌های مبهم و ملاحظات امنیت و حریم خصوصی، که حضور انسان در حلقه و حاکمیت داده را ضروری می‌سازد. برای بهره‌گیری مؤثر، مهارت‌هایی مانند طراحی پرسش برای مدل، سواد داده، آزمون مبتنی بر ریسک و ادغام ابزارها اهمیت می‌یابد؛ شروع کوچک، سنجش دقیق شاخص‌ها و سپس گسترش کنترل‌شده، مسیر عملی و کم‌ریسک است.
#QA #AIinTesting #TestAutomation #SoftwareTesting #QualityEngineering #DevOps #CICD #MachineLearning
🟣لینک مقاله:
https://cur.at/lOXHasH?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
QA Engineer Role Transformation in the Age of AI
How to stay competitive in the current rapidly changing market
🔵 عنوان مقاله
Linux Capabilities Revisited (4 minute read)
🟢 خلاصه مقاله:
امنیت در Linux با تقسیم قدرت‌های root به «capabilities» ظریف‌تر می‌شود، اما مهاجمان می‌توانند از همین سازوکار سوءاستفاده کنند: با setcap دادن قابلیتی مثل cap_setuid به یک باینری معمولی (مثلاً Python)، بدون نیاز به SUID به روت تبدیل می‌شوند و در نتیجه بک‌دوری پنهان می‌سازند. چون این مجوزها به‌صورت xattr روی inode و در security.capability ذخیره می‌شوند، در خروجی‌های معمولِ بررسی مجوزها به‌راحتی دیده نمی‌شوند و حتی بعد از rename یا ریبوت باقی می‌مانند. راهکار دفاعی این است که جست‌وجوی ارتقای دسترسی را از SUID/SGID فراتر ببریم: با getcap -r / همه قابلیت‌ها را فهرست کنیم، setcap و هر تغییر روی security.capability را مانیتور کنیم، فهرست سفید بسازیم، قابلیت‌های غیرضروری را با setcap -r حذف کنیم و این کنترل‌ها را در CI/CD و سخت‌سازی ایمیج‌ها بگنجانیم تا باینری‌های دارای capability ناخواسته وارد محیط نشوند.
#Linux #Capabilities #PrivilegeEscalation #setcap #SUID #BlueTeam #SecurityMonitoring #IncidentResponse
🟣لینک مقاله:
https://dfir.ch/posts/linux_capabilities/?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Linux Capabilities Revisited (4 minute read)
🟢 خلاصه مقاله:
امنیت در Linux با تقسیم قدرت‌های root به «capabilities» ظریف‌تر می‌شود، اما مهاجمان می‌توانند از همین سازوکار سوءاستفاده کنند: با setcap دادن قابلیتی مثل cap_setuid به یک باینری معمولی (مثلاً Python)، بدون نیاز به SUID به روت تبدیل می‌شوند و در نتیجه بک‌دوری پنهان می‌سازند. چون این مجوزها به‌صورت xattr روی inode و در security.capability ذخیره می‌شوند، در خروجی‌های معمولِ بررسی مجوزها به‌راحتی دیده نمی‌شوند و حتی بعد از rename یا ریبوت باقی می‌مانند. راهکار دفاعی این است که جست‌وجوی ارتقای دسترسی را از SUID/SGID فراتر ببریم: با getcap -r / همه قابلیت‌ها را فهرست کنیم، setcap و هر تغییر روی security.capability را مانیتور کنیم، فهرست سفید بسازیم، قابلیت‌های غیرضروری را با setcap -r حذف کنیم و این کنترل‌ها را در CI/CD و سخت‌سازی ایمیج‌ها بگنجانیم تا باینری‌های دارای capability ناخواسته وارد محیط نشوند.
#Linux #Capabilities #PrivilegeEscalation #setcap #SUID #BlueTeam #SecurityMonitoring #IncidentResponse
🟣لینک مقاله:
https://dfir.ch/posts/linux_capabilities/?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
dfir.ch
Linux Capabilities Revisited | dfir.ch
Technical blog by Stephan Berger (@malmoeb)