اکانت یکی از برنامه‌نویس‌های معروف هک شده و پکیج‌های جاوا اسکریپت اون که بیشتر از ۱ میلیارد دانلود داشتن، آلوده شدن. پکیج‌هایی مثل chalk, strip, ansi, debug و حدود ۱۵ پکیج دیگه از پکیج‌های آلوده شده هستن و آدرس مقصد تراکنش‌های کریپتو رو به آدرس هکرها تغییر می‌دن و یه جورایی کل اکو سیستم جاوااسکریپت آلوده شده. پیشنهاد شده فعلا رو ولت‌های نرم‌افزاری تراکنشی انجام ندید.
دلیل اینکه در زبان‌هایی مثل Go یا Rust یا حتی C دچار سردرگمی میشید، بخاطر این هست که میخواهید ساختارهایی که از زبان‌های شی‌گرا در ذهن دارید رو دقیقا به همون شکل در این‌ها هم داشته باشید. این زبان‌ها هم تا حدی این توهم رو ایجاد میکنند که اینکار شدنی هست؛ و میتوان گفت که همینطور است، ولی فقط در ظاهر!
بسیاری از چیزهایی که شما در زبان‌های شی‌گرا با آن‌ها اشنا شدید، مختص و منحصر به شی‌گرایی نیستند. صرفا چون شما احتمالا به دلایل تاریخی برنامه‌نویسی رو با شی‌گرایی یاد گرفتید، ممکن هست اینطور تصور کنید که این مفاهیم فقط مختص به شی گرایی هستند. در حالی که بیشتر مفاهیمی که در ذهن دارید در هر پارادایم و هر زبانی قابل پیاده سازی هست.
مثلا اگر امروز به یک برنامه‌نویس Go یا Rust یک پروژه‌ی بانکی یا یک سیستم فروشگاه رو محول کنید، به احتمال زیاد این پروژه رو مبتنی بر DDD انجام خواهد داد! حتی یک برنامه‌نویس Clojure هم احتمالا همین رویه را دنبال خواهد کرد! الان احتمالا در ذهن شما این سوال پیش آمده که DDD؟ چطور همچین چیزی ممکن هست؟ مگه این برای شی گرایی نیست؟ خیر، «شما» اون رو با شی گرایی یاد گرفتید، ولی خودش یک ایده‌ی عمومی است.
شما به شکلی آموزش دیده‌اید که یونیت‌های کد را در قالب کلاس ها ببینید. و وقتی به زبان‌هایی میرسید که دارای کلاس نیستند، اولین چیزی که به فکرتان میرسد این است که کلاس را در آن‌ها شبیه سازی کنید. درست است؟
این دیدگاه، شما را دچار مشکل میکند، و دلیل اصلی اش این است که شما حتی در زبان‌های شی‌گرا هم به درستی درک نکرده بودید که کلاس چیست! و همان دیدگاه اشتباه خود درباره کلاس رو به سایر زبان‌ها هم انتقال میدهید!
وقتی حرف از کلاس میشود، بیشتر افراد میکنند کلاس یک بلاک از کد است که تعدادی فیلد و متد را بین دو {} گرد هم آورده است.
اما کسی سوال نمیکند خب چرا اینکار را کردند؟ فقط چون میخواستند یک سری فیلد داشته باشند و یک سری تابع بتوانند روی ان‌ها کار کنند؟
خب این رو که از قدیم در همه زبان‌ها داشتیم. مگر اصلا جور دیگری میشود برنامه نویسی کرد؟ در تمام زبان‌ها یک سری دیتا داریم و یک سری تابع که روی آن دیتا کار میکنند. قدیمی ترین کد C ای که میتوانید پیدا کنید را باز کنید، احتمالا در آن یک استراکت پیدا میکنید به همراه تعدادی تابع که روی آن استراکت کار میکنند. این رویه قبل از شی گرایی هم وجود داشته... فقط چون این دو را کنار هم درون {} قرار میدهید اسمش میشود کلاس؟ یعنی فقط چون میخواستند کنار هم باشن؟ که تنها نباشن؟ غصه نخورن؟ فکر نمیکنید شاید دلایل مهمتری برای این موضوع وجود داشته؟
ویژگی‌هایی وجود دارد که باعث میشود کلاس، کلاس بشود:
۱. کلاس دارای مکانیزم وراثت است.
۲. کلاس پلی مورفیسم مبتنی بر وراثت را فراهم میکند (متدهای virtual)
۳. از روی کلاس، میتوان آبجکتی در حافظه تولید کرد.
۴. کلاس آبجکت‌ها را دسته بندی میکند (برای همین اسمش class است). یعنی باید بتوان جواب این سوال را جویا شد: ایا فلان آبجکت جزو فلان کلاس است؟
۵. آبجکت‌های ساخته شده از روی کلاس، دارای لایف تایم متفاوتی از سایر بلاک ها هستند. ابجکت‌ها حالت رفرنس دارند. به این معنی که تقریبا در تمام زبان‌ها، در هیپ قرار میگیرند.
اینکه دیتا و توابع را کنار هم و در یک بلاک به اسم کلاس جمع کردن‌اند، به خاطر این است که یک کانتکست یکپارچه پدید آورند که در قالب آن بتوانند همه‌ی ویژگی‌های بالا را برآورده کنند.
اینکه شما یک استراکت بسازید، و چند تابع تعریف کنید که روی آن استراکت کار کنند، کدام یک از ویژگی‌های بالا را شامل میشود؟ این دو بخش لزومی هم ندارد که جدا از هم باشند. مثلا در zig میتوانید توابع را عین یک کلاس درون همان بلاک مربوط به استراکت قرار دهید. ولی باز هم در صورت انجام اینکار، تبدیل به کلاس نمیشود چون هیچکدام از ویژگی‌های بالا را ندارد.
یا مثلا در C یا سایر زبان‌ها، فیلدها و متدها را در ماژول‌ها گرد هم میاورند. ایا با اینکار آن ماژول تبدیل به کلاس شده است؟
اتفاقی که این وسط افتاده این است:
۱. شما در حین یادگیری شی گرایی بدرستی درک نکردید که کلاس چیست!
۲. بر مبنای آن درک اشتباه، فکر کردید شی گرایی یعنی کنار هم قرار دادن فیلدها و متدها در یک بلاک.
۳. اصرار به این دارید که این درک اشتباه را در زبان‌هایی که اصلا دارای کلاس نیستند پیاده سازی کنید.
این همان جایی است که در زبان‌هایی مانند Go و Rust و Zig و C سایرین به مشکل بر میخورید. برای همین هست که میگویند این‌ها را با زبان‌های شی گرا اشتباه نگیرید. چون این‌ها از نظر ظاهری، شاید شرایطی را فراهم کنند که به چشم شما مشابه چیزی باشد که در شی گرایی به یاد داشتید، ولی از نظر Semantics با زبان‌های شی گرا متفاوت اند.
| <Amirreza Gh/>
بسیاری از چیزهایی که شما در زبان‌های شی‌گرا با آن‌ها اشنا شدید، مختص و منحصر به شی‌گرایی نیستند. صرفا چون شما احتمالا به دلایل تاریخی برنامه‌نویسی رو با شی‌گرایی یاد گرفتید، ممکن هست اینطور تصور کنید که این مفاهیم فقط مختص به شی گرایی هستند. در حالی که بیشتر مفاهیمی که در ذهن دارید در هر پارادایم و هر زبانی قابل پیاده سازی هست.
مثلا اگر امروز به یک برنامه‌نویس Go یا Rust یک پروژه‌ی بانکی یا یک سیستم فروشگاه رو محول کنید، به احتمال زیاد این پروژه رو مبتنی بر DDD انجام خواهد داد! حتی یک برنامه‌نویس Clojure هم احتمالا همین رویه را دنبال خواهد کرد! الان احتمالا در ذهن شما این سوال پیش آمده که DDD؟ چطور همچین چیزی ممکن هست؟ مگه این برای شی گرایی نیست؟ خیر، «شما» اون رو با شی گرایی یاد گرفتید، ولی خودش یک ایده‌ی عمومی است.
شما به شکلی آموزش دیده‌اید که یونیت‌های کد را در قالب کلاس ها ببینید. و وقتی به زبان‌هایی میرسید که دارای کلاس نیستند، اولین چیزی که به فکرتان میرسد این است که کلاس را در آن‌ها شبیه سازی کنید. درست است؟
این دیدگاه، شما را دچار مشکل میکند، و دلیل اصلی اش این است که شما حتی در زبان‌های شی‌گرا هم به درستی درک نکرده بودید که کلاس چیست! و همان دیدگاه اشتباه خود درباره کلاس رو به سایر زبان‌ها هم انتقال میدهید!
وقتی حرف از کلاس میشود، بیشتر افراد میکنند کلاس یک بلاک از کد است که تعدادی فیلد و متد را بین دو {} گرد هم آورده است.
اما کسی سوال نمیکند خب چرا اینکار را کردند؟ فقط چون میخواستند یک سری فیلد داشته باشند و یک سری تابع بتوانند روی ان‌ها کار کنند؟
خب این رو که از قدیم در همه زبان‌ها داشتیم. مگر اصلا جور دیگری میشود برنامه نویسی کرد؟ در تمام زبان‌ها یک سری دیتا داریم و یک سری تابع که روی آن دیتا کار میکنند. قدیمی ترین کد C ای که میتوانید پیدا کنید را باز کنید، احتمالا در آن یک استراکت پیدا میکنید به همراه تعدادی تابع که روی آن استراکت کار میکنند. این رویه قبل از شی گرایی هم وجود داشته... فقط چون این دو را کنار هم درون {} قرار میدهید اسمش میشود کلاس؟ یعنی فقط چون میخواستند کنار هم باشن؟ که تنها نباشن؟ غصه نخورن؟ فکر نمیکنید شاید دلایل مهمتری برای این موضوع وجود داشته؟
ویژگی‌هایی وجود دارد که باعث میشود کلاس، کلاس بشود:
۱. کلاس دارای مکانیزم وراثت است.
۲. کلاس پلی مورفیسم مبتنی بر وراثت را فراهم میکند (متدهای virtual)
۳. از روی کلاس، میتوان آبجکتی در حافظه تولید کرد.
۴. کلاس آبجکت‌ها را دسته بندی میکند (برای همین اسمش class است). یعنی باید بتوان جواب این سوال را جویا شد: ایا فلان آبجکت جزو فلان کلاس است؟
۵. آبجکت‌های ساخته شده از روی کلاس، دارای لایف تایم متفاوتی از سایر بلاک ها هستند. ابجکت‌ها حالت رفرنس دارند. به این معنی که تقریبا در تمام زبان‌ها، در هیپ قرار میگیرند.
اینکه دیتا و توابع را کنار هم و در یک بلاک به اسم کلاس جمع کردن‌اند، به خاطر این است که یک کانتکست یکپارچه پدید آورند که در قالب آن بتوانند همه‌ی ویژگی‌های بالا را برآورده کنند.
اینکه شما یک استراکت بسازید، و چند تابع تعریف کنید که روی آن استراکت کار کنند، کدام یک از ویژگی‌های بالا را شامل میشود؟ این دو بخش لزومی هم ندارد که جدا از هم باشند. مثلا در zig میتوانید توابع را عین یک کلاس درون همان بلاک مربوط به استراکت قرار دهید. ولی باز هم در صورت انجام اینکار، تبدیل به کلاس نمیشود چون هیچکدام از ویژگی‌های بالا را ندارد.
یا مثلا در C یا سایر زبان‌ها، فیلدها و متدها را در ماژول‌ها گرد هم میاورند. ایا با اینکار آن ماژول تبدیل به کلاس شده است؟
اتفاقی که این وسط افتاده این است:
۱. شما در حین یادگیری شی گرایی بدرستی درک نکردید که کلاس چیست!
۲. بر مبنای آن درک اشتباه، فکر کردید شی گرایی یعنی کنار هم قرار دادن فیلدها و متدها در یک بلاک.
۳. اصرار به این دارید که این درک اشتباه را در زبان‌هایی که اصلا دارای کلاس نیستند پیاده سازی کنید.
این همان جایی است که در زبان‌هایی مانند Go و Rust و Zig و C سایرین به مشکل بر میخورید. برای همین هست که میگویند این‌ها را با زبان‌های شی گرا اشتباه نگیرید. چون این‌ها از نظر ظاهری، شاید شرایطی را فراهم کنند که به چشم شما مشابه چیزی باشد که در شی گرایی به یاد داشتید، ولی از نظر Semantics با زبان‌های شی گرا متفاوت اند.
| <Amirreza Gh/>
❤1
Forwarded from AI Labdon
تازه منتشر شد!
مقاله‌ی من با عنوان:
«Revolutionizing Software Intelligence: A Convergent Framework of Neural Program Synthesis, Quantum-Secure DevOps, and Explainable AI for Next-Generation Autonomous Systems»
در این پژوهش به سراغ آینده‌ی سیستم‌های هوشمند خودمختار رفتم؛ جایی که تولید کد با هوش مصنوعی، امنیت در برابر تهدیدات کوانتومی، و هوش قابل توضیح در یک چارچوب واحد ترکیب می‌شوند تا نسل جدیدی از نرم‌افزارهای امن، شفاف و سازگار را بسازند.
https://msipublishers.com/volume-1-issue-2-jul-sep-msijat-2025/
<Mohammad Hossein Alikhani/>
مقاله‌ی من با عنوان:
«Revolutionizing Software Intelligence: A Convergent Framework of Neural Program Synthesis, Quantum-Secure DevOps, and Explainable AI for Next-Generation Autonomous Systems»
در این پژوهش به سراغ آینده‌ی سیستم‌های هوشمند خودمختار رفتم؛ جایی که تولید کد با هوش مصنوعی، امنیت در برابر تهدیدات کوانتومی، و هوش قابل توضیح در یک چارچوب واحد ترکیب می‌شوند تا نسل جدیدی از نرم‌افزارهای امن، شفاف و سازگار را بسازند.
https://msipublishers.com/volume-1-issue-2-jul-sep-msijat-2025/
<Mohammad Hossein Alikhani/>
🔵 عنوان مقاله
Software Testing Hacks for Product Managers
🟢 خلاصه مقاله:
**این مقاله نشان می‌دهد که مدیران محصول، به‌دلیل نزدیکی به نیازهای کاربر و اهداف کسب‌وکار، می‌توانند تسترهای بسیار مؤثری باشند. در یک مرور ۲۲ دقیقه‌ای، دانیل نات رویکردی عملی ارائه میکند: طرز فکر کنجکاو و ریسک‌محور، تعریف معیارهای پذیرش روشن، و استفاده از تکنیک‌های سبک مثل اکسپلوریتوری‌های زمان‌بندی‌شده، چک‌لیست‌های مسیرهای حیاتی، گزارش باگ دقیق و قابل اقدام، اولویت‌بندی نقص‌ها بر اساس اثر بر کاربر/کسب‌وکار، تست در محیط و دستگاه واقعی، و همکاری نزدیک با QA و مهندسی. هدف این است که تست به‌صورت طبیعی در جریان کاری PM جا بیفتد، بدون کند کردن تیم، و حلقه بازخورد، کیفیت محصول و سرعت تصمیم‌گیری را بهبود دهد.
🟣لینک مقاله:
https://cur.at/bTOAU2u?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Software Testing Hacks for Product Managers
🟢 خلاصه مقاله:
**این مقاله نشان می‌دهد که مدیران محصول، به‌دلیل نزدیکی به نیازهای کاربر و اهداف کسب‌وکار، می‌توانند تسترهای بسیار مؤثری باشند. در یک مرور ۲۲ دقیقه‌ای، دانیل نات رویکردی عملی ارائه میکند: طرز فکر کنجکاو و ریسک‌محور، تعریف معیارهای پذیرش روشن، و استفاده از تکنیک‌های سبک مثل اکسپلوریتوری‌های زمان‌بندی‌شده، چک‌لیست‌های مسیرهای حیاتی، گزارش باگ دقیق و قابل اقدام، اولویت‌بندی نقص‌ها بر اساس اثر بر کاربر/کسب‌وکار، تست در محیط و دستگاه واقعی، و همکاری نزدیک با QA و مهندسی. هدف این است که تست به‌صورت طبیعی در جریان کاری PM جا بیفتد، بدون کند کردن تیم، و حلقه بازخورد، کیفیت محصول و سرعت تصمیم‌گیری را بهبود دهد.
🟣لینک مقاله:
https://cur.at/bTOAU2u?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
YouTube
Software Testing Hacks for Product Managers
Software testing Hacks for Product Managers | How I Drive Product Quality Without Dedicated Testers
As a product manager, how do you ensure top-notch product quality—especially when you don't have a dedicated QA team?
In this talk, which I gave on World…
As a product manager, how do you ensure top-notch product quality—especially when you don't have a dedicated QA team?
In this talk, which I gave on World…
🔵 عنوان مقاله
Testing with guardrails
🟢 خلاصه مقاله:
** با وجود تمرکز شدید بر خودکارسازی و هوش مصنوعی، این مقاله تأکید میکند که آزمون اکتشافیِ انسانی همچنان نقشی اساسی دارد. «ریل‌گذاری» یعنی مجموعه‌ای از مرزها و رویه‌ها—مثل منشورهای آزمون، نقشه‌های ریسک، قیود داده و حریم خصوصی، و حلقه‌های بازخورد—که خودکارسازی را قابل اعتماد و همسو با ریسک نگه می‌دارند و به کشف‌های انسانی خوراک می‌دهند. رویکرد متوازن این است: خودکارسازی برای رگرسیون و کارهای تکراری، و نشست‌های زمان‌بندی‌شده اکتشافی برای مواجهه با ابهام و سناریوهای واقعی؛ سپس آموخته‌ها به تست‌های خودکار تبدیل شوند. پیام نهایی: پیشرفت واقعی از تلفیق هوشمندانهٔ ماشین‌ها در چارچوب ریل‌ها و حفظ کنجکاوی و قضاوت انسانی در مرکز کیفیت به‌دست می‌آید.
🟣لینک مقاله:
https://cur.at/MPmhk2C?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Testing with guardrails
🟢 خلاصه مقاله:
** با وجود تمرکز شدید بر خودکارسازی و هوش مصنوعی، این مقاله تأکید میکند که آزمون اکتشافیِ انسانی همچنان نقشی اساسی دارد. «ریل‌گذاری» یعنی مجموعه‌ای از مرزها و رویه‌ها—مثل منشورهای آزمون، نقشه‌های ریسک، قیود داده و حریم خصوصی، و حلقه‌های بازخورد—که خودکارسازی را قابل اعتماد و همسو با ریسک نگه می‌دارند و به کشف‌های انسانی خوراک می‌دهند. رویکرد متوازن این است: خودکارسازی برای رگرسیون و کارهای تکراری، و نشست‌های زمان‌بندی‌شده اکتشافی برای مواجهه با ابهام و سناریوهای واقعی؛ سپس آموخته‌ها به تست‌های خودکار تبدیل شوند. پیام نهایی: پیشرفت واقعی از تلفیق هوشمندانهٔ ماشین‌ها در چارچوب ریل‌ها و حفظ کنجکاوی و قضاوت انسانی در مرکز کیفیت به‌دست می‌آید.
🟣لینک مقاله:
https://cur.at/MPmhk2C?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Maaike Brinkhof's blog
Testing with guardrails
"We want you to test our software well!" - says the manager type. "We care about quality, you can see that reflected in our company values".
"Okay", I say as I try to surpress a cough after that last bit about company values, and I begin to thoroughly test…
"Okay", I say as I try to surpress a cough after that last bit about company values, and I begin to thoroughly test…
🔵 عنوان مقاله
Shifting software testing left with operational definitions
🟢 خلاصه مقاله:
مایک هریس توضیح می‌دهد که اثربخش‌کردن «شیفت لِفت» در تست، با نوشتن الزامات به‌صورت «تعاریف عملیاتی» آغاز میشود؛ یعنی تبدیل خواسته‌های کلی به گزاره‌های شفاف، قابل‌اندازه‌گیری و بدون ابهام. وقتی الزامات همراه با معیارهای پذیرش دقیق، مثال‌های روشن و مرزهای مشخص نوشته شوند، طراحی تست همزمان با توسعه پیش می‌رود، خودکارسازی آسان‌تر میشود و دوباره‌کاری‌های بعدی کاهش می‌یابد. این رویکرد با بهبود هم‌فهمی میان ذی‌نفعان، ردیابی بین الزام و تست را تقویت میکند و بازخورد زودهنگام در CI/CD را ممکن می‌سازد. نتیجه نهایی، تست مؤثرتر، خطاهای کمتر در مراحل پایانی و تحویل سریع‌تر و مطمئن‌تر است.
🟣لینک مقاله:
https://cur.at/4bL4bb7?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Shifting software testing left with operational definitions
🟢 خلاصه مقاله:
مایک هریس توضیح می‌دهد که اثربخش‌کردن «شیفت لِفت» در تست، با نوشتن الزامات به‌صورت «تعاریف عملیاتی» آغاز میشود؛ یعنی تبدیل خواسته‌های کلی به گزاره‌های شفاف، قابل‌اندازه‌گیری و بدون ابهام. وقتی الزامات همراه با معیارهای پذیرش دقیق، مثال‌های روشن و مرزهای مشخص نوشته شوند، طراحی تست همزمان با توسعه پیش می‌رود، خودکارسازی آسان‌تر میشود و دوباره‌کاری‌های بعدی کاهش می‌یابد. این رویکرد با بهبود هم‌فهمی میان ذی‌نفعان، ردیابی بین الزام و تست را تقویت میکند و بازخورد زودهنگام در CI/CD را ممکن می‌سازد. نتیجه نهایی، تست مؤثرتر، خطاهای کمتر در مراحل پایانی و تحویل سریع‌تر و مطمئن‌تر است.
🟣لینک مقاله:
https://cur.at/4bL4bb7?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Ministry of Testing
Shifting software testing left with operational definitions
See how operational definitions bring clarity to requirements and support earlier testing
فرض کن مسئول فنی توییتری، ساعت ۸ شبه و یه نفر با ۳۰ میلیون فالوور یه توییت میزنه، تو چند ثانیه، سیستم تو باید توییت رو ببره تو تایم لایت همه فالوراش
حالا سؤال اینه: چطوری سیستم شما باید با کمترین هزینه و بیشترین سرعت این توییت رو بزاره تو تایم لاین فالورا؟
این مشکلی بود که توییتر تو سال 2012 باید حلش میکرد اما راه حلشون چی بود؟
دوتا راهکار روبروشون بود
1- توییت یکبار تو دیتابیس ذخیره شه و هر بار کاربرا با باز کردن تایم لاین یه کوئری بزنن ببینن اونایی که فالو کردن چیا توییت کردن
2- تویتت به محض ارسال تو کش تایم لاین همه فالورا ذخیره بشه
اون اولا توییتر راه اول شماره 1 رو انتخاب کرد که این باعث میشه هر کاربر موقع باز کردن صفحه اول توییتر یک کوئری read بزنه که به مرور با افزایش تعداد خواننده ها که تقریبا دوبرابر نویسنده ها بودن بازدهیش اومد پایین
پس توییتر اومد سویچ کرد رو حالت دوم که با زدن هر توییت میومد تو کش تایم لاین فالورا اون توییت رو اضافه میکرد اینطوری برا نوشتن یه توییت پردازش بیشتری میکرد اما این به سرعتش می ارزید اما خب همچنان یه مشکلی بود!
مشکل این بود ممکن بود یه نفر 30 میلیون فالور داشته باشه و خب نوشتن و قرار دادن اون توییت جدید برای 30 میلیون فالور پردازش و زمان زیادی میخواست و این باز سرعتو میورد پایین
راه حل جدید چی بود؟
ترکیبی از این دوتا روش!
به این صورت که برای اونا که فالورشون کم بود توییت هاشونو میزاشت تو کش تایم لاین فالوراشون و کنارش میمود برای افراد با فالور زیاد هم کوئری read میزد و بعد بر اساس زمان سورتش میکرد
البته احتمالا تا الان باید نحوه کار خیلی تغیر کرده باشه و روش ها بهتری رو انتخاب کرده باشن
| <ixAbolfazl/>
حالا سؤال اینه: چطوری سیستم شما باید با کمترین هزینه و بیشترین سرعت این توییت رو بزاره تو تایم لاین فالورا؟
این مشکلی بود که توییتر تو سال 2012 باید حلش میکرد اما راه حلشون چی بود؟
دوتا راهکار روبروشون بود
1- توییت یکبار تو دیتابیس ذخیره شه و هر بار کاربرا با باز کردن تایم لاین یه کوئری بزنن ببینن اونایی که فالو کردن چیا توییت کردن
2- تویتت به محض ارسال تو کش تایم لاین همه فالورا ذخیره بشه
اون اولا توییتر راه اول شماره 1 رو انتخاب کرد که این باعث میشه هر کاربر موقع باز کردن صفحه اول توییتر یک کوئری read بزنه که به مرور با افزایش تعداد خواننده ها که تقریبا دوبرابر نویسنده ها بودن بازدهیش اومد پایین
پس توییتر اومد سویچ کرد رو حالت دوم که با زدن هر توییت میومد تو کش تایم لاین فالورا اون توییت رو اضافه میکرد اینطوری برا نوشتن یه توییت پردازش بیشتری میکرد اما این به سرعتش می ارزید اما خب همچنان یه مشکلی بود!
مشکل این بود ممکن بود یه نفر 30 میلیون فالور داشته باشه و خب نوشتن و قرار دادن اون توییت جدید برای 30 میلیون فالور پردازش و زمان زیادی میخواست و این باز سرعتو میورد پایین
راه حل جدید چی بود؟
ترکیبی از این دوتا روش!
به این صورت که برای اونا که فالورشون کم بود توییت هاشونو میزاشت تو کش تایم لاین فالوراشون و کنارش میمود برای افراد با فالور زیاد هم کوئری read میزد و بعد بر اساس زمان سورتش میکرد
البته احتمالا تا الان باید نحوه کار خیلی تغیر کرده باشه و روش ها بهتری رو انتخاب کرده باشن
| <ixAbolfazl/>
❤2
🔵 عنوان مقاله
QA Engineer in a Product Company: How I Left Outsourcing and Stopped Panicking Before Releases
🟢 خلاصه مقاله:
**این مقاله تجربه گریگوری سدلنیکوف از مهاجرت از شرکت‌های برون‌سپار (مشاوره‌ای) به شرکت محصول‌محور را روایت میکند. او می‌گوید در برون‌سپاری، تغییر مداوم پروژه‌ها و فشار زمان باعث اضطراب پیش از انتشار میشود، در حالی که در شرکت محصولی با مالکیت بلندمدت، همکاری نزدیک تیمی، و سرمایه‌گذاری در CI/CD، اتوماسیون، فلگ‌های فیچر و مشاهده‌پذیری، ریسک‌ها کنترل‌پذیر و انتشارها آرام‌تر می‌شوند. نقش QA از «دروازه انتهایی» به مشارکت زودهنگام در نیازمندی‌ها و تصمیم‌های فنی تغییر میکند؛ معیار موفقیت نیز از تحویلِ صرف به اثر بر تجربه کاربر و سرعت تحویل تبدیل میشود. نکات کلیدی او: تست مبتنی بر ریسک، مسئولیت مشترک کیفیت، گفتن «نه» به کار کم‌اثر، سرمایه‌گذاری در زیرساخت تست و یادگیری مداوم از رفتار محصول در محیط واقعی.
🟣لینک مقاله:
https://cur.at/RVcKkoE?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
QA Engineer in a Product Company: How I Left Outsourcing and Stopped Panicking Before Releases
🟢 خلاصه مقاله:
**این مقاله تجربه گریگوری سدلنیکوف از مهاجرت از شرکت‌های برون‌سپار (مشاوره‌ای) به شرکت محصول‌محور را روایت میکند. او می‌گوید در برون‌سپاری، تغییر مداوم پروژه‌ها و فشار زمان باعث اضطراب پیش از انتشار میشود، در حالی که در شرکت محصولی با مالکیت بلندمدت، همکاری نزدیک تیمی، و سرمایه‌گذاری در CI/CD، اتوماسیون، فلگ‌های فیچر و مشاهده‌پذیری، ریسک‌ها کنترل‌پذیر و انتشارها آرام‌تر می‌شوند. نقش QA از «دروازه انتهایی» به مشارکت زودهنگام در نیازمندی‌ها و تصمیم‌های فنی تغییر میکند؛ معیار موفقیت نیز از تحویلِ صرف به اثر بر تجربه کاربر و سرعت تحویل تبدیل میشود. نکات کلیدی او: تست مبتنی بر ریسک، مسئولیت مشترک کیفیت، گفتن «نه» به کار کم‌اثر، سرمایه‌گذاری در زیرساخت تست و یادگیری مداوم از رفتار محصول در محیط واقعی.
🟣لینک مقاله:
https://cur.at/RVcKkoE?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
QA Engineer in a Product Company: How I Left Outsourcing and Stopped Panicking Before Releases
From outsourcing to product: a QA engineer’s honest journey to better releases, healthier work culture & real impact on the product.
❤1
🔵 عنوان مقاله
Recommended Software Testing Reading List
🟢 خلاصه مقاله:
این مطلب معرفی یک فهرست پیشنهادی مطالعه برای آزمون‌گران نرم‌افزار است که پس از وقفه‌ای طولانی، توسط آلن ریچاردسون گردآوری شده است. فهرست با تمرکز بر مهارت‌های ماندگار و کاربردی، برای سطوح مختلف تجربه مناسب است و به آزمون‌گران کمک میکند مسیر یادگیری خود را از مبانی تا رویکردهای پیشرفته سامان دهند. این گردآوری دعوتی به یادگیری مستمر و به‌کارگیری آموخته‌ها در عمل است و امکان تکمیل و به‌روزرسانی توسط جامعه را نیز ترغیب میکند.
🟣لینک مقاله:
https://cur.at/uXG3WVF?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Recommended Software Testing Reading List
🟢 خلاصه مقاله:
این مطلب معرفی یک فهرست پیشنهادی مطالعه برای آزمون‌گران نرم‌افزار است که پس از وقفه‌ای طولانی، توسط آلن ریچاردسون گردآوری شده است. فهرست با تمرکز بر مهارت‌های ماندگار و کاربردی، برای سطوح مختلف تجربه مناسب است و به آزمون‌گران کمک میکند مسیر یادگیری خود را از مبانی تا رویکردهای پیشرفته سامان دهند. این گردآوری دعوتی به یادگیری مستمر و به‌کارگیری آموخته‌ها در عمل است و امکان تکمیل و به‌روزرسانی توسط جامعه را نیز ترغیب میکند.
🟣لینک مقاله:
https://cur.at/uXG3WVF?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Eviltester
Recommended Reading
A list of books that have helped me improve my Testing and thinking around testing.
🤝1
🔵 عنوان مقاله
Cypress-split with Github Actions variables
🟢 خلاصه مقاله:
در نسخه متن‌باز Cypress امکان اجرای موازی به‌صورت داخلی وجود ندارد، اما میتوان در CI با تقسیم تست‌ها میان چند job به نتیجه‌ای مشابه رسید. راهکار پیشنهادی با استفاده از ابزار cypress-split و متغیرهای GitHub Actions کار میکند: یک ماتریس job تعریف میشود، به هر job شاخص (index) و تعداد کل jobها داده میشود، و cypress-split بر اساس همین مقادیر فایل‌های تست را به‌صورت قطعی میان jobها پخش میکند تا هر کدام زیرمجموعه‌ای یکتا را اجرا کند. این روش زمان اجرای کل را کاهش می‌دهد و بازخورد PRها را سریع‌تر میکند، هرچند توازن بار به‌صورت پویا نیست و امکانات تحلیلی داشبورد را ندارد. اولیسس کوستا فیلیو نمونه‌ای عملی از این پیاده‌سازی با متغیرهای GitHub Actions ارائه کرده است.
🟣لینک مقاله:
https://cur.at/c6kAXqp?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Cypress-split with Github Actions variables
🟢 خلاصه مقاله:
در نسخه متن‌باز Cypress امکان اجرای موازی به‌صورت داخلی وجود ندارد، اما میتوان در CI با تقسیم تست‌ها میان چند job به نتیجه‌ای مشابه رسید. راهکار پیشنهادی با استفاده از ابزار cypress-split و متغیرهای GitHub Actions کار میکند: یک ماتریس job تعریف میشود، به هر job شاخص (index) و تعداد کل jobها داده میشود، و cypress-split بر اساس همین مقادیر فایل‌های تست را به‌صورت قطعی میان jobها پخش میکند تا هر کدام زیرمجموعه‌ای یکتا را اجرا کند. این روش زمان اجرای کل را کاهش می‌دهد و بازخورد PRها را سریع‌تر میکند، هرچند توازن بار به‌صورت پویا نیست و امکانات تحلیلی داشبورد را ندارد. اولیسس کوستا فیلیو نمونه‌ای عملی از این پیاده‌سازی با متغیرهای GitHub Actions ارائه کرده است.
🟣لینک مقاله:
https://cur.at/c6kAXqp?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
Cypress-split with Github Actions variables
Reduce the time of testing in 75% and save your budget while you scale the automation testing effort
🔵 عنوان مقاله
Testing AI: lessons from wearing three hats
🟢 خلاصه مقاله:
این مقاله توضیح می‌دهد چرا آزمون‌گری در محصولات مبتنی بر LLM با نرم‌افزار کلاسیک فرق دارد: خروجی‌ها غیردترمینستیک‌اند، معیار درست‌ونادرست مطلق وجود ندارد و رفتار مدل‌ها دچار تغییر و رانش میشود. از دید سه نقش، درس‌ها چنین‌اند: به‌عنوان QA باید مجموعه‌های طلایی و رده‌بندی خطا بسازیم، ارزیابی معنایی و بازبینی انسانی کنار تست‌های ایمنی، سوگیری، حملات تزریق و رد تیمینگ داشته باشیم و رگرسیون‌ها را با کنترل‌هایی مثل دما/بذر پیگیری کنیم. از دید توسعه‌دهنده باید معماری را برای تست‌پذیری طراحی کرد: جداسازی منطق پرامپت و ابزارها، اعتبارسنجی خروجی‌های ساخت‌یافته، زمان‌سنجی/بازیابی/فالبک، هارنس ارزیابی در CI/CD، لاگ و تله‌متری ویژه LLM، و نسخه‌بندی داده/پرامپت و دیپلوی‌های سایه. از دید مدیر محصول، معیارهای موفقیت باید ارزش کاربر را بسنجند و بین کیفیت-تأخیر-هزینه توازن برقرار کنند؛ انتشار مرحله‌ای، حاکمیت و حریم خصوصی، و حلقه‌های بازخورد و برچسب‌گذاری ضروری‌اند. جمع‌بندی: آزمون‌گری مؤثر در LLM یک کار میان‌رشته‌ای است؛ با مجموعه‌های طلایی کوچک اما نماینده، آستانه‌های شفاف، ارزیابی خودکار متصل به انتشار، مانیتورینگ تولید و تکرار مستمر میتوان عدم‌قطعیت را مدیریت و محصولی قابل‌اعتماد و قابل‌بهبود ساخت.
🟣لینک مقاله:
https://cur.at/eZENZw9?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Testing AI: lessons from wearing three hats
🟢 خلاصه مقاله:
این مقاله توضیح می‌دهد چرا آزمون‌گری در محصولات مبتنی بر LLM با نرم‌افزار کلاسیک فرق دارد: خروجی‌ها غیردترمینستیک‌اند، معیار درست‌ونادرست مطلق وجود ندارد و رفتار مدل‌ها دچار تغییر و رانش میشود. از دید سه نقش، درس‌ها چنین‌اند: به‌عنوان QA باید مجموعه‌های طلایی و رده‌بندی خطا بسازیم، ارزیابی معنایی و بازبینی انسانی کنار تست‌های ایمنی، سوگیری، حملات تزریق و رد تیمینگ داشته باشیم و رگرسیون‌ها را با کنترل‌هایی مثل دما/بذر پیگیری کنیم. از دید توسعه‌دهنده باید معماری را برای تست‌پذیری طراحی کرد: جداسازی منطق پرامپت و ابزارها، اعتبارسنجی خروجی‌های ساخت‌یافته، زمان‌سنجی/بازیابی/فالبک، هارنس ارزیابی در CI/CD، لاگ و تله‌متری ویژه LLM، و نسخه‌بندی داده/پرامپت و دیپلوی‌های سایه. از دید مدیر محصول، معیارهای موفقیت باید ارزش کاربر را بسنجند و بین کیفیت-تأخیر-هزینه توازن برقرار کنند؛ انتشار مرحله‌ای، حاکمیت و حریم خصوصی، و حلقه‌های بازخورد و برچسب‌گذاری ضروری‌اند. جمع‌بندی: آزمون‌گری مؤثر در LLM یک کار میان‌رشته‌ای است؛ با مجموعه‌های طلایی کوچک اما نماینده، آستانه‌های شفاف، ارزیابی خودکار متصل به انتشار، مانیتورینگ تولید و تکرار مستمر میتوان عدم‌قطعیت را مدیریت و محصولی قابل‌اعتماد و قابل‌بهبود ساخت.
🟣لینک مقاله:
https://cur.at/eZENZw9?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
Testing AI: lessons from wearing three hats
AI is not like traditional software. It doesn’t run on deterministic logic, it doesn’t always give the same output twice, and it doesn’t…
Forwarded from Bardia & Erfan
✨ درود به همه دوستان ✨
به مناسبت روز برنامه‌نویس 🎉
می‌تونید فقط با ۲۰۰ هزار تومان تبلیغ‌تون رو توی تمام کانال‌های زیر منتشر کنید!
📌 این فرصت ویژه فقط تا پایان همین هفته اعتبار داره.
⏳برای هماهنگی بیشتر به ای دی زیر پیام بدید👾
@mrbardia72
🔽 لیست کانال‌هایی که تبلیغ در اون‌ها قرار میگیره:
https://t.iss.one/addlist/AJ7rh2IzIh02NTI0
به مناسبت روز برنامه‌نویس 🎉
می‌تونید فقط با ۲۰۰ هزار تومان تبلیغ‌تون رو توی تمام کانال‌های زیر منتشر کنید!
📌 این فرصت ویژه فقط تا پایان همین هفته اعتبار داره.
⏳برای هماهنگی بیشتر به ای دی زیر پیام بدید👾
@mrbardia72
🔽 لیست کانال‌هایی که تبلیغ در اون‌ها قرار میگیره:
https://t.iss.one/addlist/AJ7rh2IzIh02NTI0
🔵 عنوان مقاله
How to implement self-healing tests with AI
🟢 خلاصه مقاله:
** خودبهبودی در تست یعنی استفاده از هوش مصنوعی برای ترمیم خودکار تست‌هایی که به‌دلیل تغییرات جزئی محصول (مثل جابه‌جایی المنت‌ها، تغییر متن یا ساختار DOM) می‌شکنند. رویکرد پیشنهادی این است که لایه‌ای به چارچوب تست اضافه شود تا هنگام شکست جست‌وجوی المنت یا شکنندگیِ یک گزاره، با تحلیل همزمان سیگنال‌های ساختاری، متنی و بصری، جایگزین مناسب را پیدا کند، با امتیاز اطمینان تصمیم بگیرد و تغییر را ثبت کند.
برای پیاده‌سازی، چهار جزء کلیدی لازم است: داده (لاگ‌ها، اسکرین‌شات‌ها، اسنپ‌شات‌های DOM)، مدل (ابتدا قواعد و سپس ML برای رتبه‌بندی شباهت المنت‌ها)، رهگیری در زمان اجرا (قطع شکست، پیشنهاد جایگزین، تکرار اکشن با بهترین کاندیدا) و حاکمیت (نسخه‌بندی و ثبت تغییرات، آستانه‌های اطمینان، بازبینی انسانی و گزارش‌دهی). پیشنهاد میشود ابتدا در حالت «صرفاً پیشنهاد» شروع کنید، سپس با کاهش خطاها، خودبهبودی خودکار را برای سناریوهای کم‌ریسک فعال و برای جریان‌های حیاتی بازبینی دستی را حفظ کنید. نتیجه، کاهش تست‌های ناپایدار و تسریع بازخورد است؛ و با آستانه‌های محافظه‌کارانه، قوانین «عدم خودبهبودی» برای گزاره‌های حساس و رصد مداوم، خطر پنهان‌شدن باگ‌های واقعی مدیریت میشود.
🟣لینک مقاله:
https://cur.at/CeE3oBA?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
How to implement self-healing tests with AI
🟢 خلاصه مقاله:
** خودبهبودی در تست یعنی استفاده از هوش مصنوعی برای ترمیم خودکار تست‌هایی که به‌دلیل تغییرات جزئی محصول (مثل جابه‌جایی المنت‌ها، تغییر متن یا ساختار DOM) می‌شکنند. رویکرد پیشنهادی این است که لایه‌ای به چارچوب تست اضافه شود تا هنگام شکست جست‌وجوی المنت یا شکنندگیِ یک گزاره، با تحلیل همزمان سیگنال‌های ساختاری، متنی و بصری، جایگزین مناسب را پیدا کند، با امتیاز اطمینان تصمیم بگیرد و تغییر را ثبت کند.
برای پیاده‌سازی، چهار جزء کلیدی لازم است: داده (لاگ‌ها، اسکرین‌شات‌ها، اسنپ‌شات‌های DOM)، مدل (ابتدا قواعد و سپس ML برای رتبه‌بندی شباهت المنت‌ها)، رهگیری در زمان اجرا (قطع شکست، پیشنهاد جایگزین، تکرار اکشن با بهترین کاندیدا) و حاکمیت (نسخه‌بندی و ثبت تغییرات، آستانه‌های اطمینان، بازبینی انسانی و گزارش‌دهی). پیشنهاد میشود ابتدا در حالت «صرفاً پیشنهاد» شروع کنید، سپس با کاهش خطاها، خودبهبودی خودکار را برای سناریوهای کم‌ریسک فعال و برای جریان‌های حیاتی بازبینی دستی را حفظ کنید. نتیجه، کاهش تست‌های ناپایدار و تسریع بازخورد است؛ و با آستانه‌های محافظه‌کارانه، قوانین «عدم خودبهبودی» برای گزاره‌های حساس و رصد مداوم، خطر پنهان‌شدن باگ‌های واقعی مدیریت میشود.
🟣لینک مقاله:
https://cur.at/CeE3oBA?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
How to implement self-healing tests with AI
Part 1: the foundations of self-healing
🔵 عنوان مقاله
Lessons in Testing Same-Same, Just Different Projects
🟢 خلاصه مقاله:
این مقاله با تکیه بر نکات عملی یسپر اوتوسن توضیح می‌دهد که در پروژه‌های مهاجرت نرم‌افزار، هدف «همان، فقط متفاوت» به معنای حفظ رفتارهای ضروری در عین تغییر زیرساخت‌ها و یکپارچه‌سازی‌هاست. راهبرد پیشنهادی شامل تعیین دقیق دامنه و معیارهای برابری (چه چیز باید دقیقاً یکسان بماند و چه تفاوت‌هایی مجاز است)، تمرکز بر ریسک‌های اصلی، فهرست‌برداری و آزمون قراردادهای تمامی یکپارچه‌سازی‌ها، اجرای تست‌های موازی/سایه‌ای، و اعتبارسنجی دقیق مهاجرت داده است. همچنین بر کارایی، امنیت و مشاهده‌پذیری پس از مهاجرت، برنامه برش/بازگشت، و پایش تقویتی تأکید میکند تا «همان ولی متفاوت» به نتیجه‌ای قابل سنجش و قابل اطمینان تبدیل شود.
🟣لینک مقاله:
https://cur.at/vjUEMnd?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Lessons in Testing Same-Same, Just Different Projects
🟢 خلاصه مقاله:
این مقاله با تکیه بر نکات عملی یسپر اوتوسن توضیح می‌دهد که در پروژه‌های مهاجرت نرم‌افزار، هدف «همان، فقط متفاوت» به معنای حفظ رفتارهای ضروری در عین تغییر زیرساخت‌ها و یکپارچه‌سازی‌هاست. راهبرد پیشنهادی شامل تعیین دقیق دامنه و معیارهای برابری (چه چیز باید دقیقاً یکسان بماند و چه تفاوت‌هایی مجاز است)، تمرکز بر ریسک‌های اصلی، فهرست‌برداری و آزمون قراردادهای تمامی یکپارچه‌سازی‌ها، اجرای تست‌های موازی/سایه‌ای، و اعتبارسنجی دقیق مهاجرت داده است. همچنین بر کارایی، امنیت و مشاهده‌پذیری پس از مهاجرت، برنامه برش/بازگشت، و پایش تقویتی تأکید میکند تا «همان ولی متفاوت» به نتیجه‌ای قابل سنجش و قابل اطمینان تبدیل شود.
🟣لینک مقاله:
https://cur.at/vjUEMnd?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Leading Testing Activities
Lessons in Testing Same-Same, Just Different Projects
Three key lessons for testing enterprise lift & shift programs. It's same-same to classic testing, yet very different too.
🔵 عنوان مقاله
Say Hello to Your New QA Teammate: E2E Test AI Agent
🟢 خلاصه مقاله:
** این متن از یک دمو به ارائه زهاوپِنگ شوآن می‌گوید که در آن یک عامل هوش مصنوعی به‌عنوان «هم‌تیمی جدید QA» برای اجرای تست‌های انتهابهانتها معرفی میشود. مقاله توضیح می‌دهد که رویکردهای گوناگونی برای به‌کارگیری هوش مصنوعی در تست وجود دارد—from قواعد ازپیش‌تعریف‌شده تا مدل‌های زبانی برای تفسیر نیازمندی‌ها—و این دمو نشان می‌دهد چگونه چنین عاملی می‌تواند نیت را به گام‌های اجرایی تبدیل کند، اجرا را رصد کند و نتایج را برای بازبینی انسانی خلاصه کند. در کنار مزایایی مثل سرعت بیشتر، پوشش بالاتر و نگهداری آسان‌تر، بر چالش‌هایی مانند قابلیت اتکا، قطعیت، امنیت و ضرورت نظارت انسانی نیز تأکید میشود؛ هدف، تکمیل توان کارشناسان تست است نه جایگزینی آن‌ها.
🟣لینک مقاله:
https://cur.at/wV0CnB6?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Say Hello to Your New QA Teammate: E2E Test AI Agent
🟢 خلاصه مقاله:
** این متن از یک دمو به ارائه زهاوپِنگ شوآن می‌گوید که در آن یک عامل هوش مصنوعی به‌عنوان «هم‌تیمی جدید QA» برای اجرای تست‌های انتهابهانتها معرفی میشود. مقاله توضیح می‌دهد که رویکردهای گوناگونی برای به‌کارگیری هوش مصنوعی در تست وجود دارد—from قواعد ازپیش‌تعریف‌شده تا مدل‌های زبانی برای تفسیر نیازمندی‌ها—و این دمو نشان می‌دهد چگونه چنین عاملی می‌تواند نیت را به گام‌های اجرایی تبدیل کند، اجرا را رصد کند و نتایج را برای بازبینی انسانی خلاصه کند. در کنار مزایایی مثل سرعت بیشتر، پوشش بالاتر و نگهداری آسان‌تر، بر چالش‌هایی مانند قابلیت اتکا، قطعیت، امنیت و ضرورت نظارت انسانی نیز تأکید میشود؛ هدف، تکمیل توان کارشناسان تست است نه جایگزینی آن‌ها.
🟣لینک مقاله:
https://cur.at/wV0CnB6?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
DEV Community
Say Hello to Your New QA Teammate: E2E Test AI Agent
For some background, see The Past Story about using UI-Tars for AI Testing, which shows practical AI...
🔵 عنوان مقاله
The Three Pillars of QA: Why Testing Alone is Never Enough
🟢 خلاصه مقاله:
کیفیت فراتر از یافتن باگ است و تنها با تست به دست نمی‌آید؛ ماکسیم لاپتف سه ستون اصلی آن را «فرآیند»، «مستندسازی» و «محیط‌ها» می‌داند. با فرآیندهای شفاف (تعریف دقیق آماده/انجام، تست مبتنی بر ریسک، بازبینی کد، CI/CD و تحلیل ریشه‌ای خطا) خطاها زودتر پیشگیری و بازخورد سریع‌تر میشود. مستندسازی زنده و در دسترس (الزامات، استراتژی تست، چک‌لیست‌های ضروری، ردیابی نیازمندی تا نتایج و گزارش‌های خطای استاندارد) ابهام و دانش ضمنی را کاهش می‌دهد. محیط‌های پایدار و شبیه تولید با داده‌های تست مدیریت‌شده، جداسازی مناسب، محیط‌های موقت، پرچم ویژگی و قابلیت مشاهده‌پذیری، اتکا‌پذیری نتایج تست را بالا می‌برند و شکنندگی را کم میکنند. نتیجه: با سرمایه‌گذاری روی این سه ستون، تست مؤثرتر میشود، نقص‌های فراری کمتر، انتشارها قابل‌پیش‌بینی‌تر و هزینه کیفیت پایین‌تر؛ میتوان با یک ممیزی کوچک، اصلاح یک گلوگاه فرآیندی، به‌روزرسانی اسناد کلیدی و پایدارسازی یک محیط شروع کرد.
🟣لینک مقاله:
https://cur.at/OczDsyB?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
The Three Pillars of QA: Why Testing Alone is Never Enough
🟢 خلاصه مقاله:
کیفیت فراتر از یافتن باگ است و تنها با تست به دست نمی‌آید؛ ماکسیم لاپتف سه ستون اصلی آن را «فرآیند»، «مستندسازی» و «محیط‌ها» می‌داند. با فرآیندهای شفاف (تعریف دقیق آماده/انجام، تست مبتنی بر ریسک، بازبینی کد، CI/CD و تحلیل ریشه‌ای خطا) خطاها زودتر پیشگیری و بازخورد سریع‌تر میشود. مستندسازی زنده و در دسترس (الزامات، استراتژی تست، چک‌لیست‌های ضروری، ردیابی نیازمندی تا نتایج و گزارش‌های خطای استاندارد) ابهام و دانش ضمنی را کاهش می‌دهد. محیط‌های پایدار و شبیه تولید با داده‌های تست مدیریت‌شده، جداسازی مناسب، محیط‌های موقت، پرچم ویژگی و قابلیت مشاهده‌پذیری، اتکا‌پذیری نتایج تست را بالا می‌برند و شکنندگی را کم میکنند. نتیجه: با سرمایه‌گذاری روی این سه ستون، تست مؤثرتر میشود، نقص‌های فراری کمتر، انتشارها قابل‌پیش‌بینی‌تر و هزینه کیفیت پایین‌تر؛ میتوان با یک ممیزی کوچک، اصلاح یک گلوگاه فرآیندی، به‌روزرسانی اسناد کلیدی و پایدارسازی یک محیط شروع کرد.
🟣لینک مقاله:
https://cur.at/OczDsyB?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
The Three Pillars of QA: Why Testing Alone is Never Enough
In my career as a QA, I’ve faced a ton of problems that, for some reason, management almost never sees. In most companies, managers think…
چطور یه سیستم غیرقابل نگهداری میشه؟
وقتی همه اعضای تیم حرفه ای و متخصص، بیزنس هم عالی ولی توسعه سیستم داره روز به روز سخت تر میشه و برای هر فیچر کوچیک و بزرگ زمان زیادی باید انتظار کشید تا به سیستم اضافه بشه وقتی هم اضافه میشه دیگه صدای تیم پروداکت و بیزنس در اومده!
تو این مطلب یه مقدار عمیقتر رفتم سراغ اینکه در چنین شرایطی، وقتی فشار روی تیم فنی هست یا یک سیستم legacy رو تحویل گرفتیم چه کارهایی (بخوانیم تصمیمات غلط) جلوی توسعه و نگهداری سیستم رو میگیره.
لینک مطلب:
https://mohammadkeshavarz.substack.com/p/anti-patterns-and-solutions
وقتی همه اعضای تیم حرفه ای و متخصص، بیزنس هم عالی ولی توسعه سیستم داره روز به روز سخت تر میشه و برای هر فیچر کوچیک و بزرگ زمان زیادی باید انتظار کشید تا به سیستم اضافه بشه وقتی هم اضافه میشه دیگه صدای تیم پروداکت و بیزنس در اومده!
تو این مطلب یه مقدار عمیقتر رفتم سراغ اینکه در چنین شرایطی، وقتی فشار روی تیم فنی هست یا یک سیستم legacy رو تحویل گرفتیم چه کارهایی (بخوانیم تصمیمات غلط) جلوی توسعه و نگهداری سیستم رو میگیره.
لینک مطلب:
https://mohammadkeshavarz.substack.com/p/anti-patterns-and-solutions
Substack
وقتی راه‌حل خودش دردسرساز میشه!
گاهی تلاش برای حل یک مشکل، با انتخاب راه‌حل‌های پیچیده یا نادرست، مشکلات بزرگ‌تری خلق میکنه که سیستم رو در باتلاق بدهی فنی و نگهداری غیرممکن گرفتار میکنه.
🍾1
🔵 عنوان مقاله
How to Know When Simple Isn't Enough Anymore (The TDD Answer)
🟢 خلاصه مقاله:
این مقاله با عنوان «How to Know When Simple Isn't Enough Anymore (The TDD Answer)» و به قلم Herbert Moroni Gois با مثال‌های مرحله‌به‌مرحله نشان می‌دهد که ارزش توسعه آزمون‌محور زمانی آشکار میشود که سادگی اولیه دیگر پاسخگو نیست. نوشتن آزمون‌ها پیش از کدنویسی نقاط اصطکاک را عیان میکند، به جداسازی مسئولیت‌ها و وابستگی‌های قابل‌تعویض می‌انجامد و بازآرایی امن را ممکن می‌سازد؛ در نتیجه کدی شکل می‌گیرد که ذاتاً قابل‌تست و قابل‌تغییر است، بدون نیاز به پیش‌طراحی بیش از حد.
🟣لینک مقاله:
https://cur.at/Dt6KYJw?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
How to Know When Simple Isn't Enough Anymore (The TDD Answer)
🟢 خلاصه مقاله:
این مقاله با عنوان «How to Know When Simple Isn't Enough Anymore (The TDD Answer)» و به قلم Herbert Moroni Gois با مثال‌های مرحله‌به‌مرحله نشان می‌دهد که ارزش توسعه آزمون‌محور زمانی آشکار میشود که سادگی اولیه دیگر پاسخگو نیست. نوشتن آزمون‌ها پیش از کدنویسی نقاط اصطکاک را عیان میکند، به جداسازی مسئولیت‌ها و وابستگی‌های قابل‌تعویض می‌انجامد و بازآرایی امن را ممکن می‌سازد؛ در نتیجه کدی شکل می‌گیرد که ذاتاً قابل‌تست و قابل‌تغییر است، بدون نیاز به پیش‌طراحی بیش از حد.
🟣لینک مقاله:
https://cur.at/Dt6KYJw?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
How to Know When Simple Isn’t Enough Anymore (The TDD Answer)
How I rebuilt the same API using TDD and discovered that tests naturally guide you toward clean design
🔵 عنوان مقاله
Transforming UI Test Report: Harnessing HAR Files in Playwright
🟢 خلاصه مقاله:
این مقاله نشان می‌دهد چگونه با استفاده از فایل‌های HAR در اجرای تست‌های UI با Playwright میتوان گزارش‌ها را غنی‌تر کرد و دید دقیقی از درخواست‌ها و پاسخ‌های API به دست آورد. نویسنده توضیح می‌دهد که HAR چه اطلاعاتی (هدرها، بدنه‌ها، وضعیت‌ها، زمان‌بندی و…) را ثبت میکند و چطور میتوان آن را به گزارش‌های Playwright پیوست یا تحلیل کرد تا کندی‌ها، خطاها و ریشه ناپایداری‌ها سریع‌تر شناسایی شود. نتیجه این رویکرد، بهبود ردیابی خطا، تشخیص سریع تفاوت مشکلات فرانت‌اند و بک‌اند، و تبدیل تست‌های UI به پروب‌های سبکِ سرتاسری برای کارایی و پایداری است.
🟣لینک مقاله:
https://cur.at/XRMDwxX?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Transforming UI Test Report: Harnessing HAR Files in Playwright
🟢 خلاصه مقاله:
این مقاله نشان می‌دهد چگونه با استفاده از فایل‌های HAR در اجرای تست‌های UI با Playwright میتوان گزارش‌ها را غنی‌تر کرد و دید دقیقی از درخواست‌ها و پاسخ‌های API به دست آورد. نویسنده توضیح می‌دهد که HAR چه اطلاعاتی (هدرها، بدنه‌ها، وضعیت‌ها، زمان‌بندی و…) را ثبت میکند و چطور میتوان آن را به گزارش‌های Playwright پیوست یا تحلیل کرد تا کندی‌ها، خطاها و ریشه ناپایداری‌ها سریع‌تر شناسایی شود. نتیجه این رویکرد، بهبود ردیابی خطا، تشخیص سریع تفاوت مشکلات فرانت‌اند و بک‌اند، و تبدیل تست‌های UI به پروب‌های سبکِ سرتاسری برای کارایی و پایداری است.
🟣لینک مقاله:
https://cur.at/XRMDwxX?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
Transforming UI Test Report: Harnessing HAR Files in Playwright
Hey there! Let’s chat about modern websites and all the fascinating stuff happening behind the scenes. So, imagine you’re building a sleek…
🔵 عنوان مقاله
The Tetris Principle aka "Test as Low as Possible"
🟢 خلاصه مقاله:
الکس شوارتز «اصل تتریس» یا همان «تا حد امکان در سطوح پایین تست کنید» را مطرح میکند: با الهام از بازی تتریس، می‌گوید بهتر است بیشتر تضمین‌ها و خطاها را در پایین‌ترین لایه‌های هرم تست حل کنیم. تست‌های واحد و کامپوننت سریع‌تر، ارزان‌تر و قابل اتکاترند، در حالی‌که تست‌های انتهابهانتها کند، شکننده و پرهزینه‌اند. مانند پاک‌کردن ردیف‌ها در پایینِ تتریس، باید رفتارها و خطاها را در پایین‌ترین لایه‌ی قابل اعتماد تثبیت کرد تا مشکل به لایه‌های بالاتر سرریز نشود. نتیجه عملی: برای هر نیازمندی یا باگ، پایین‌ترین لایه‌ی ممکن را هدف بگیرید، از تست‌های قراردادی برای مرز سرویس‌ها استفاده کنید و فقط یک لایه نازک از تست‌های انتهابهانتها را برای مسیرهای حیاتی نگه دارید؛ این کار بازخورد سریع‌تر، خط لوله CI چابک‌تر و نگهداشت آسان‌تر را به همراه دارد.
🟣لینک مقاله:
https://cur.at/DsA5k3T?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
The Tetris Principle aka "Test as Low as Possible"
🟢 خلاصه مقاله:
الکس شوارتز «اصل تتریس» یا همان «تا حد امکان در سطوح پایین تست کنید» را مطرح میکند: با الهام از بازی تتریس، می‌گوید بهتر است بیشتر تضمین‌ها و خطاها را در پایین‌ترین لایه‌های هرم تست حل کنیم. تست‌های واحد و کامپوننت سریع‌تر، ارزان‌تر و قابل اتکاترند، در حالی‌که تست‌های انتهابهانتها کند، شکننده و پرهزینه‌اند. مانند پاک‌کردن ردیف‌ها در پایینِ تتریس، باید رفتارها و خطاها را در پایین‌ترین لایه‌ی قابل اعتماد تثبیت کرد تا مشکل به لایه‌های بالاتر سرریز نشود. نتیجه عملی: برای هر نیازمندی یا باگ، پایین‌ترین لایه‌ی ممکن را هدف بگیرید، از تست‌های قراردادی برای مرز سرویس‌ها استفاده کنید و فقط یک لایه نازک از تست‌های انتهابهانتها را برای مسیرهای حیاتی نگه دارید؛ این کار بازخورد سریع‌تر، خط لوله CI چابک‌تر و نگهداشت آسان‌تر را به همراه دارد.
🟣لینک مقاله:
https://cur.at/DsA5k3T?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
The Tetris Principle aka “Test as Low↓ as Possible”
A powerful principle to improve your test automation
🍾1