🔵 عنوان مقاله
Mutation testing — not just for unit tests
🟢 خلاصه مقاله:
mutation testing روشی برای سنجش کیفیت واقعی آزمون‌هاست: با ایجاد تغییرات کوچک در کد، بررسی می‌کند آیا تست‌ها می‌توانند خطاهای احتمالی را کشف کنند یا نه. این رویکرد فقط مخصوص unit tests نیست؛ می‌توان آن را در سطح integration و API و حتی سناریوهای انتها به انتها به‌کار گرفت تا مطمئن شویم تست‌ها رفتار قابل مشاهده را به‌خوبی پوشش می‌دهند. Bas Dijkstra با یک مثال گام‌به‌گام نشان می‌دهد چگونه ابزار را پیکربندی کنیم، mutants بسازیم، تست‌ها را اجرا کنیم و نتایج را تفسیر کنیم؛ و چگونه با تقویت assertions، افزودن سناریوهای لبه، یا حذف کد مرده کیفیت را بالا ببریم. پیشنهاد عملی این است که با یک بخش کوچک شروع کنید، ابزار مناسب پشته‌تان را انتخاب کنید، در CI آستانه‌های معقول بگذارید و اجرای سنگین‌تر را دوره‌ای انجام دهید تا با هزینه منطقی، بازخورد مؤثر بگیرید.
#MutationTesting #SoftwareTesting #UnitTesting #TestQuality #BasDijkstra #CodeCoverage #CI_CD #DevOps
🟣لینک مقاله:
https://cur.at/gKlipIY?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Mutation testing — not just for unit tests
🟢 خلاصه مقاله:
mutation testing روشی برای سنجش کیفیت واقعی آزمون‌هاست: با ایجاد تغییرات کوچک در کد، بررسی می‌کند آیا تست‌ها می‌توانند خطاهای احتمالی را کشف کنند یا نه. این رویکرد فقط مخصوص unit tests نیست؛ می‌توان آن را در سطح integration و API و حتی سناریوهای انتها به انتها به‌کار گرفت تا مطمئن شویم تست‌ها رفتار قابل مشاهده را به‌خوبی پوشش می‌دهند. Bas Dijkstra با یک مثال گام‌به‌گام نشان می‌دهد چگونه ابزار را پیکربندی کنیم، mutants بسازیم، تست‌ها را اجرا کنیم و نتایج را تفسیر کنیم؛ و چگونه با تقویت assertions، افزودن سناریوهای لبه، یا حذف کد مرده کیفیت را بالا ببریم. پیشنهاد عملی این است که با یک بخش کوچک شروع کنید، ابزار مناسب پشته‌تان را انتخاب کنید، در CI آستانه‌های معقول بگذارید و اجرای سنگین‌تر را دوره‌ای انجام دهید تا با هزینه منطقی، بازخورد مؤثر بگیرید.
#MutationTesting #SoftwareTesting #UnitTesting #TestQuality #BasDijkstra #CodeCoverage #CI_CD #DevOps
🟣لینک مقاله:
https://cur.at/gKlipIY?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
On Test Automation
Mutation testing - not just for unit tests
I wrote about mutation testing a few times on this blog, and I even have a mutation testing workshop that I run on a pretty frequent basis.
🎉1
🔵 عنوان مقاله
How We Systematized Technical Debt Management in Our QA Team
🟢 خلاصه مقاله:
Ilia Golos نشان می‌دهد که «بدهی فنی» مانند باگ‌ها اجتناب‌ناپذیر است، اما اگر سیستماتیک مدیریت شود به‌جای مانع، به اهرمی برای سرعت و پایداری تبدیل می‌شود. او برای تیم‌های QA یک چارچوب عملی پیشنهاد می‌کند: دسته‌بندی شفاف بدهی‌ها (مثل کد تست، تست‌های flaky یا کند، محیط و پیکربندی، داده تست، شکاف‌های پوشش و فرایندها)، نگه‌داشتن همه موارد در یک بک‌لاگ واحد با برچسب‌های یکنواخت، و اولویت‌بندی بر مبنای ریسک و اثر روی کاربر. برای حفظ تمرکز، بخشی از ظرفیت هر اسپرینت به بدهی اختصاص می‌یابد یا اسپرینت‌های ویژه بدهی برگزار می‌شود؛ افزودن کنترل‌های بدهی به Definition of Done از ایجاد بدهی جدید جلوگیری می‌کند و داشبوردهایی مانند نرخ flaky، زمان اجرای تست و سن بدهی، تصمیم‌گیری را داده‌محور می‌سازند. در عمل، توصیه‌ها شامل بازآرایی کد تست، حذف تست‌های منسوخ، پایدارسازی flakyها، خودکارسازی بررسی‌های تکراری، بازتولیدپذیر کردن محیط و داده، و مشارکت نزدیک با توسعه و محصول برای توازن میان قابلیت‌ها و ریسک است. با مالکیت روشن، الگوی ثبت ساده، بازبینی‌های دوره‌ای و قانون «جلوگیری از خونریزی» برای بدهی‌های جدید، مدیریت بدهی تدریجی اما پیوسته می‌شود و به انتشارهای سریع‌تر و قابل‌اعتمادتر می‌انجامد.
#TechnicalDebt #QualityAssurance #SoftwareTesting #TestAutomation #AgileTesting #DevOps #QA #EngineeringManagement
🟣لینک مقاله:
https://cur.at/196LoVa?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
How We Systematized Technical Debt Management in Our QA Team
🟢 خلاصه مقاله:
Ilia Golos نشان می‌دهد که «بدهی فنی» مانند باگ‌ها اجتناب‌ناپذیر است، اما اگر سیستماتیک مدیریت شود به‌جای مانع، به اهرمی برای سرعت و پایداری تبدیل می‌شود. او برای تیم‌های QA یک چارچوب عملی پیشنهاد می‌کند: دسته‌بندی شفاف بدهی‌ها (مثل کد تست، تست‌های flaky یا کند، محیط و پیکربندی، داده تست، شکاف‌های پوشش و فرایندها)، نگه‌داشتن همه موارد در یک بک‌لاگ واحد با برچسب‌های یکنواخت، و اولویت‌بندی بر مبنای ریسک و اثر روی کاربر. برای حفظ تمرکز، بخشی از ظرفیت هر اسپرینت به بدهی اختصاص می‌یابد یا اسپرینت‌های ویژه بدهی برگزار می‌شود؛ افزودن کنترل‌های بدهی به Definition of Done از ایجاد بدهی جدید جلوگیری می‌کند و داشبوردهایی مانند نرخ flaky، زمان اجرای تست و سن بدهی، تصمیم‌گیری را داده‌محور می‌سازند. در عمل، توصیه‌ها شامل بازآرایی کد تست، حذف تست‌های منسوخ، پایدارسازی flakyها، خودکارسازی بررسی‌های تکراری، بازتولیدپذیر کردن محیط و داده، و مشارکت نزدیک با توسعه و محصول برای توازن میان قابلیت‌ها و ریسک است. با مالکیت روشن، الگوی ثبت ساده، بازبینی‌های دوره‌ای و قانون «جلوگیری از خونریزی» برای بدهی‌های جدید، مدیریت بدهی تدریجی اما پیوسته می‌شود و به انتشارهای سریع‌تر و قابل‌اعتمادتر می‌انجامد.
#TechnicalDebt #QualityAssurance #SoftwareTesting #TestAutomation #AgileTesting #DevOps #QA #EngineeringManagement
🟣لینک مقاله:
https://cur.at/196LoVa?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
How We Systematized Technical Debt Management in Our QA Team
I'll share the steps we took, and the metrics that helped us turn technical debt into a manageable part of our workflow.
❤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
🔵 عنوان مقاله
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
🔵 عنوان مقاله
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…
🔵 عنوان مقاله
k6 Scenarios & Metrics You Must Know
🟢 خلاصه مقاله:
این مرور ۲۵ دقیقه‌ای با ارائه Joan Esquivel Montero به‌صورت فشرده نشان می‌دهد چگونه با استفاده از سناریوها و متریک‌های کلیدی در k6 آزمون‌های کارایی دقیق‌تری بسازیم. ابتدا انتخاب صحیح executorها را پوشش می‌دهد: از constant-vus و ramping-vus برای پایه‌گیری، تست ماندگاری و استرس؛ per-vu-iterations و shared-iterations برای اجرای کنترل‌شده؛ و constant-arrival-rate و ramping-arrival-rate زمانی که هدفتان کنترل نرخ درخواست (RPS) است. ساختاردهی تست با setup/teardown، گروه‌بندی مراحل مهم، و برچسب‌گذاری برای تفکیک نتایج نیز توضیح داده می‌شود.
در بخش متریک‌ها، اهمیت http_req_duration (با تأکید بر صدک‌ها نه میانگین)، http_req_failed، http_reqs، iterations، vus/vus_max، checks، و حجم داده‌ها مطرح است و نحوه ساخت متریک‌های سفارشی با Trend، Counter، Gauge و Rate و برچسب‌گذاری برای تحلیل جزئی‌تر مرور می‌شود.
سپس تبدیل SLOها به thresholdهای قابل‌اجرا در k6 نشان داده می‌شود؛ مانند محدود کردن p(95) زمان پاسخ، نرخ خطا، یا حداقل RPS، و استفاده از abortOnFail برای توقف سریع. نکاتی برای جلوگیری از خطاهای رایج نیز ارائه می‌شود: هدف‌گذاری شفاف، داده و think time واقعی، رمپ منطقی، و انتخاب مدل بار مناسب (VU در برابر نرخ ورود).
در نهایت به جنبه‌های عملیاتی اشاره می‌شود: اجرای محلی و ادغام با CI/CD، ارسال نتایج به InfluxDB/Prometheus و مشاهده در Grafana، و مقیاس‌پذیری با k6 Cloud یا Kubernetes. با نسخه‌بندی اسکریپت‌ها، پارامترگذاری و برچسب‌گذاری، می‌توانید سریع‌تر عیب‌یابی کرده و محدودیت‌ها، رگرسیون‌ها و نقاط گلوگاهی را با دقت شناسایی کنید.
#k6 #PerformanceTesting #LoadTesting #DevOps #JavaScript #Grafana #Metrics #SRE
🟣لینک مقاله:
https://cur.at/U5oID4d?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
k6 Scenarios & Metrics You Must Know
🟢 خلاصه مقاله:
این مرور ۲۵ دقیقه‌ای با ارائه Joan Esquivel Montero به‌صورت فشرده نشان می‌دهد چگونه با استفاده از سناریوها و متریک‌های کلیدی در k6 آزمون‌های کارایی دقیق‌تری بسازیم. ابتدا انتخاب صحیح executorها را پوشش می‌دهد: از constant-vus و ramping-vus برای پایه‌گیری، تست ماندگاری و استرس؛ per-vu-iterations و shared-iterations برای اجرای کنترل‌شده؛ و constant-arrival-rate و ramping-arrival-rate زمانی که هدفتان کنترل نرخ درخواست (RPS) است. ساختاردهی تست با setup/teardown، گروه‌بندی مراحل مهم، و برچسب‌گذاری برای تفکیک نتایج نیز توضیح داده می‌شود.
در بخش متریک‌ها، اهمیت http_req_duration (با تأکید بر صدک‌ها نه میانگین)، http_req_failed، http_reqs، iterations، vus/vus_max، checks، و حجم داده‌ها مطرح است و نحوه ساخت متریک‌های سفارشی با Trend، Counter، Gauge و Rate و برچسب‌گذاری برای تحلیل جزئی‌تر مرور می‌شود.
سپس تبدیل SLOها به thresholdهای قابل‌اجرا در k6 نشان داده می‌شود؛ مانند محدود کردن p(95) زمان پاسخ، نرخ خطا، یا حداقل RPS، و استفاده از abortOnFail برای توقف سریع. نکاتی برای جلوگیری از خطاهای رایج نیز ارائه می‌شود: هدف‌گذاری شفاف، داده و think time واقعی، رمپ منطقی، و انتخاب مدل بار مناسب (VU در برابر نرخ ورود).
در نهایت به جنبه‌های عملیاتی اشاره می‌شود: اجرای محلی و ادغام با CI/CD، ارسال نتایج به InfluxDB/Prometheus و مشاهده در Grafana، و مقیاس‌پذیری با k6 Cloud یا Kubernetes. با نسخه‌بندی اسکریپت‌ها، پارامترگذاری و برچسب‌گذاری، می‌توانید سریع‌تر عیب‌یابی کرده و محدودیت‌ها، رگرسیون‌ها و نقاط گلوگاهی را با دقت شناسایی کنید.
#k6 #PerformanceTesting #LoadTesting #DevOps #JavaScript #Grafana #Metrics #SRE
🟣لینک مقاله:
https://cur.at/U5oID4d?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
YouTube
k6 Scenarios & Metrics You Must Know
Learn how to do API load testing with k6 step by step using the QuickPizza demo app 🍕. In this tutorial, you’ll see how to spin up QuickPizza with Docker, configure smoke and stress scenarios in k6, create custom metrics and thresholds, and analyze everything…
🔵 عنوان مقاله
My Load Testing Journey: Why Artillery Won over JMeter and K6
🟢 خلاصه مقاله:
جاناهان سیوانانتهامورتی تجربه خود در آزمون کارایی را توضیح می‌دهد و می‌گوید چرا پس از ارزیابی JMeter و K6، در نهایت Artillery را برگزیده است. معیارهای اصلی او سادگی راه‌اندازی، خوانایی و نگهداری سناریوها، سازگاری با کنترل نسخه و CI/CD، و گزارش‌های قابل اتکا بوده است. به‌گفته او JMeter هرچند قدرتمند است اما برای تیم‌شان سنگین و پیچیده بود؛ K6 هم با وجود مزایای فنی، در گردش‌کارشان کمی اصطکاک ایجاد می‌کرد. در مقابل، Artillery با تنظیمات سبک، توسعه‌پذیری مبتنی بر JavaScript و زمان رسیدن سریع به نتیجه، بهتر با نیازها و سرعت تیم هماهنگ شد—هرچند تأکید می‌کند انتخاب ابزار به زمینه و محدودیت‌های هر تیم بستگی دارد.
#LoadTesting #PerformanceTesting #Artillery #JMeter #K6 #DevOps #CICD #TestingTools
🟣لینک مقاله:
https://cur.at/CRuqO1c?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
My Load Testing Journey: Why Artillery Won over JMeter and K6
🟢 خلاصه مقاله:
جاناهان سیوانانتهامورتی تجربه خود در آزمون کارایی را توضیح می‌دهد و می‌گوید چرا پس از ارزیابی JMeter و K6، در نهایت Artillery را برگزیده است. معیارهای اصلی او سادگی راه‌اندازی، خوانایی و نگهداری سناریوها، سازگاری با کنترل نسخه و CI/CD، و گزارش‌های قابل اتکا بوده است. به‌گفته او JMeter هرچند قدرتمند است اما برای تیم‌شان سنگین و پیچیده بود؛ K6 هم با وجود مزایای فنی، در گردش‌کارشان کمی اصطکاک ایجاد می‌کرد. در مقابل، Artillery با تنظیمات سبک، توسعه‌پذیری مبتنی بر JavaScript و زمان رسیدن سریع به نتیجه، بهتر با نیازها و سرعت تیم هماهنگ شد—هرچند تأکید می‌کند انتخاب ابزار به زمینه و محدودیت‌های هر تیم بستگی دارد.
#LoadTesting #PerformanceTesting #Artillery #JMeter #K6 #DevOps #CICD #TestingTools
🟣لینک مقاله:
https://cur.at/CRuqO1c?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
My Load Testing Journey: Why Artillery Won over JMeter and K6
Load Testing Shouldn’t be Harder Than Building Your App
🔵 عنوان مقاله
"Shift Right" Testing, Done Right
🟢 خلاصه مقاله:
تست شیفت-رایت یعنی ادامه‌دادن اعتبارسنجی و پایش نرم‌افزار پس از انتشار و یادگیری از رفتار واقعی کاربران در محیط Production. Arik Aharoni توصیه‌هایی در سطح بالا ارائه می‌دهد: تعریف SLO و بودجه خطا، سرمایه‌گذاری در Observability، تحویل تدریجی با Feature Flags و Canary Release، خودکارسازی انتشار و Rollback، توجه به حریم خصوصی و امنیت، شروع تدریجی در سناریوهای کم‌ریسک، و همکاری میان Dev، QA، Ops، SRE و Product. دستاوردها شامل بازخورد سریع‌تر و واقعی‌تر، شناسایی مشکلاتی که قبل از انتشار دیده نمی‌شوند، بهبود قابلیت اتکا و تاب‌آوری، و کاهش MTTR است. شیفت-رایت جایگزین شیفت-لفت نیست، بلکه مکمل آن است و نیازمند ریل‌گذاری‌های ایمن مانند کنترل دسترسی، محدودکردن شعاع ریسک و برنامه‌های Rollback روشن است.
#ShiftRightTesting #Observability #DevOps #SRE #ProgressiveDelivery #FeatureFlags #CanaryRelease #SoftwareQuality
🟣لینک مقاله:
https://cur.at/VbiIVHW?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
"Shift Right" Testing, Done Right
🟢 خلاصه مقاله:
تست شیفت-رایت یعنی ادامه‌دادن اعتبارسنجی و پایش نرم‌افزار پس از انتشار و یادگیری از رفتار واقعی کاربران در محیط Production. Arik Aharoni توصیه‌هایی در سطح بالا ارائه می‌دهد: تعریف SLO و بودجه خطا، سرمایه‌گذاری در Observability، تحویل تدریجی با Feature Flags و Canary Release، خودکارسازی انتشار و Rollback، توجه به حریم خصوصی و امنیت، شروع تدریجی در سناریوهای کم‌ریسک، و همکاری میان Dev، QA، Ops، SRE و Product. دستاوردها شامل بازخورد سریع‌تر و واقعی‌تر، شناسایی مشکلاتی که قبل از انتشار دیده نمی‌شوند، بهبود قابلیت اتکا و تاب‌آوری، و کاهش MTTR است. شیفت-رایت جایگزین شیفت-لفت نیست، بلکه مکمل آن است و نیازمند ریل‌گذاری‌های ایمن مانند کنترل دسترسی، محدودکردن شعاع ریسک و برنامه‌های Rollback روشن است.
#ShiftRightTesting #Observability #DevOps #SRE #ProgressiveDelivery #FeatureFlags #CanaryRelease #SoftwareQuality
🟣لینک مقاله:
https://cur.at/VbiIVHW?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Software Test Management | Testuff | SaaS Test Management
“Shift Right” Testing, Done Right | Software Test Management | Testuff
Discover why “Shift Right” testing. Monitoring and experimentation in production—is essential for modern QA strategies. Learn how to implement it responsibly and gain real-world insights that pre-production testing can’t deliver.
🔵 عنوان مقاله
The Testing Skyscraper: A Modern Alternative to the Testing Pyramid
🟢 خلاصه مقاله:
Andrew Knight مدل سنتی Testing Pyramid را ناکافی می‌داند و به‌جای آن رویکرد منعطف‌تری به نام Testing Skyscraper پیشنهاد می‌کند. در این مدل، به‌جای نسبت‌های ثابت بین لایه‌های تست، «طبقات» متناسب با ریسک‌ها و نیازهای سیستم شکل می‌گیرند؛ مثلا ممکن است یک سیستم به طبقه پررنگ‌تری از contract testing، یا عملکرد و تاب‌آوری، یا سناریوهای end-to-end نیاز داشته باشد. این رویکرد بر تناسب پوشش با معماری و اهداف محصول، بازخورد سریع، و ارزش‌سنجی بر اساس کاهش ریسک و افزایش اطمینان تأکید دارد، نه شمارش تست‌ها. در عمل، ترکیبی از unit، integration، contract، end-to-end، تست‌های غیرعملکردی (کارایی، امنیت، دسترس‌پذیری)، و حتی observability و synthetic monitoring به‌عنوان طبقات مستقل در نظر گرفته می‌شوند و با تغییر سیستم، به‌صورت پویا تقویت، بازچینی یا حذف می‌گردند.
#SoftwareTesting #TestingPyramid #TestingSkyscraper #QualityEngineering #DevOps #Automation #RiskBasedTesting #TestStrategy
🟣لینک مقاله:
https://cur.at/W2rklZc?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
The Testing Skyscraper: A Modern Alternative to the Testing Pyramid
🟢 خلاصه مقاله:
Andrew Knight مدل سنتی Testing Pyramid را ناکافی می‌داند و به‌جای آن رویکرد منعطف‌تری به نام Testing Skyscraper پیشنهاد می‌کند. در این مدل، به‌جای نسبت‌های ثابت بین لایه‌های تست، «طبقات» متناسب با ریسک‌ها و نیازهای سیستم شکل می‌گیرند؛ مثلا ممکن است یک سیستم به طبقه پررنگ‌تری از contract testing، یا عملکرد و تاب‌آوری، یا سناریوهای end-to-end نیاز داشته باشد. این رویکرد بر تناسب پوشش با معماری و اهداف محصول، بازخورد سریع، و ارزش‌سنجی بر اساس کاهش ریسک و افزایش اطمینان تأکید دارد، نه شمارش تست‌ها. در عمل، ترکیبی از unit، integration، contract، end-to-end، تست‌های غیرعملکردی (کارایی، امنیت، دسترس‌پذیری)، و حتی observability و synthetic monitoring به‌عنوان طبقات مستقل در نظر گرفته می‌شوند و با تغییر سیستم، به‌صورت پویا تقویت، بازچینی یا حذف می‌گردند.
#SoftwareTesting #TestingPyramid #TestingSkyscraper #QualityEngineering #DevOps #Automation #RiskBasedTesting #TestStrategy
🟣لینک مقاله:
https://cur.at/W2rklZc?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Automation Panda
The Testing Skyscraper: A Modern Alternative to the Testing Pyramid
The Testing Pyramid, once a foundational model in software testing, is now deemed outdated. The emergence of advanced tools and continuous testing feedback necessitates a shift to a more flexible m…
🔵 عنوان مقاله
Web Accessibility Testing — Are We There Yet?
🟢 خلاصه مقاله:
**با اجرای European Accessibility Act، آزمون‌های دسترس‌پذیری از یک گزینه جانبی به یک ضرورت قانونی و اخلاقی تبدیل شده‌اند. مقاله می‌گوید با وجود پیشرفت‌ها، وضعیت هنوز مطلوب نیست: ابزارهای خودکار فقط بخشی از مشکلات را می‌یابند و بسیاری از موانع در استفاده واقعی و با فناوری‌های کمکی آشکار می‌شوند. راهکار، ترکیب آزمون خودکار و دستی، مشارکت کاربران دارای معلولیت، و ادغام دسترس‌پذیری در طراحی، توسعه، CI/CD و حاکمیت کیفیت است. پیام نهایی: دسترس‌پذیری باید یک فرایند مستمر و مشترک باشد تا هم ریسک را کاهش دهد و هم تجربه‌ای فراگیرتر ایجاد کند.
#Accessibility #A11y #EuropeanAccessibilityAct #WCAG #InclusiveDesign #Testing #QA #DevOps
🟣لینک مقاله:
https://cur.at/fU9ymSF?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Web Accessibility Testing — Are We There Yet?
🟢 خلاصه مقاله:
**با اجرای European Accessibility Act، آزمون‌های دسترس‌پذیری از یک گزینه جانبی به یک ضرورت قانونی و اخلاقی تبدیل شده‌اند. مقاله می‌گوید با وجود پیشرفت‌ها، وضعیت هنوز مطلوب نیست: ابزارهای خودکار فقط بخشی از مشکلات را می‌یابند و بسیاری از موانع در استفاده واقعی و با فناوری‌های کمکی آشکار می‌شوند. راهکار، ترکیب آزمون خودکار و دستی، مشارکت کاربران دارای معلولیت، و ادغام دسترس‌پذیری در طراحی، توسعه، CI/CD و حاکمیت کیفیت است. پیام نهایی: دسترس‌پذیری باید یک فرایند مستمر و مشترک باشد تا هم ریسک را کاهش دهد و هم تجربه‌ای فراگیرتر ایجاد کند.
#Accessibility #A11y #EuropeanAccessibilityAct #WCAG #InclusiveDesign #Testing #QA #DevOps
🟣لینک مقاله:
https://cur.at/fU9ymSF?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
My world of testing and thoughts
Web Accessibility Testing – Are We There Yet?
In the tech world right now, web accessibility is being talked about a lot. Webinars. Blog posts. Conference talks. Panels. How to do web accessibility testing, the tools and the law etc. There’s n…
❤1
🔵 عنوان مقاله
Test Automation: How to Turn Regression Routine into a Reliable System
🟢 خلاصه مقاله:
این مقاله روایت عملی Maksim Laptev از گذار تیم از رگرسیون دستی به یک سامانه خودکار و قابل اتکاست. او بر اولویت‌بندی مبتنی بر ریسک تأکید می‌کند: شروع با اسموک تست‌های سریع، افزودن تست‌های پایدار در سطح API برای هسته سیستم و خودکارسازی محدود اما هدفمند مسیرهای UI پرارزش، در کنار حفظ تست‌های اکتشافی. معیارهای انتخاب ابزار شامل هم‌راستایی با زبان تیم، یکپارچگی با CI/CD، اجرای موازی، گزارش‌دهی و نگهداشت‌پذیری است و پرهیز از تنوع بی‌رویه ابزار توصیه می‌شود. در معماری، جداسازی لایه‌ها (الگوهایی مانند Page Object/Screenplay)، مدیریت داده و محیط تکرارپذیر، حذف منابع flakiness با انتظارهای قطعی و setup/teardown ایمن، و برچسب‌گذاری و شاردینگ برای سرعت، نقش کلیدی دارند. ادغام در CI/CD با دروازه‌های سریع، رگرسیون‌های دوره‌ای و سنجه‌هایی مانند پوشش جریان‌های حیاتی، نرخ flake و زمان رفع، کیفیت را پایدار می‌کند. در نهایت با یک نقشه راه گام‌به‌گام، آموزش و کدنویسی استاندارد برای تست‌ها، و بازبینی و هرس منظم، می‌توان سامانه‌ای ساخت که چرخه بازخورد را کوتاه و ریسک انتشار را کم می‌کند.
#TestAutomation #SoftwareTesting #QA #RegressionTesting #CICD #DevOps #SDET
🟣لینک مقاله:
https://cur.at/Z0J7xPm?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Test Automation: How to Turn Regression Routine into a Reliable System
🟢 خلاصه مقاله:
این مقاله روایت عملی Maksim Laptev از گذار تیم از رگرسیون دستی به یک سامانه خودکار و قابل اتکاست. او بر اولویت‌بندی مبتنی بر ریسک تأکید می‌کند: شروع با اسموک تست‌های سریع، افزودن تست‌های پایدار در سطح API برای هسته سیستم و خودکارسازی محدود اما هدفمند مسیرهای UI پرارزش، در کنار حفظ تست‌های اکتشافی. معیارهای انتخاب ابزار شامل هم‌راستایی با زبان تیم، یکپارچگی با CI/CD، اجرای موازی، گزارش‌دهی و نگهداشت‌پذیری است و پرهیز از تنوع بی‌رویه ابزار توصیه می‌شود. در معماری، جداسازی لایه‌ها (الگوهایی مانند Page Object/Screenplay)، مدیریت داده و محیط تکرارپذیر، حذف منابع flakiness با انتظارهای قطعی و setup/teardown ایمن، و برچسب‌گذاری و شاردینگ برای سرعت، نقش کلیدی دارند. ادغام در CI/CD با دروازه‌های سریع، رگرسیون‌های دوره‌ای و سنجه‌هایی مانند پوشش جریان‌های حیاتی، نرخ flake و زمان رفع، کیفیت را پایدار می‌کند. در نهایت با یک نقشه راه گام‌به‌گام، آموزش و کدنویسی استاندارد برای تست‌ها، و بازبینی و هرس منظم، می‌توان سامانه‌ای ساخت که چرخه بازخورد را کوتاه و ریسک انتشار را کم می‌کند.
#TestAutomation #SoftwareTesting #QA #RegressionTesting #CICD #DevOps #SDET
🟣لینک مقاله:
https://cur.at/Z0J7xPm?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
Test Automation: How to Turn Regression Routine into a Reliable System
In my previous article, I discussed the “Three Pillars” of high-quality QA: documentation, stable environments, and streamlined processes…
🔵 عنوان مقاله
"Why didn't testing find this issue?" Because you desire something that doesn't exist!
🟢 خلاصه مقاله:
وقتی خطایی به تولید می‌رسد، پرسش تکراری این است: «چرا تست‌ها این مشکل را پیدا نکردند؟» Maaike Brinkhof می‌گوید ریشه‌ی این پرسش اشتباه است، چون چنین قطعیتی از تست انتظار داریم که اصلاً وجود ندارد. تست فقط می‌تواند اعتماد را افزایش دهد و ریسک‌ها را آشکار کند؛ هرگز نمی‌تواند نبودِ باگ را ثابت کند.
به‌جای سرزنش «تست»، بحث را به مسئولیت جمعی و یادگیری سیستمی تغییر دهیم: «چطور فرایند، فرض‌ها و طراحی ما اجازه‌ی فرار این باگ را داده‌اند؟» عوامل رایج شامل ابهام در نیازها، تفاوت محیط‌ها با تولید، داده‌ی ناکافی، مشاهده‌پذیری ضعیف، یا مصالحه‌های زمان‌بندی است. مجموعه تست‌ها فقط نمونه‌ای از واقعیت‌اند، نه تمام آن.
راه‌حل، مدیریت ریسک و بهبود چرخه‌های بازخورد است: تقویت logging و telemetry، استفاده از feature flag و انتشار تدریجی، بهبود تست‌های قرارداد و سفرهای حیاتی کاربر، و سرمایه‌گذاری روی تست اکتشافی برای کشف ناشناخته‌ها. با postmortem بدون سرزنش بپرسیم: ریسک را درست فهمیدیم؟ نظارت ما برای کشف سریع و محدودکردن دامنه مشکل کافی بود؟ داده و محیط مناسب داشتیم؟ آیا pairing، بازبینی یا risk storming می‌توانست زودتر هشدار بدهد؟
جمع‌بندی: تست تضمین نیست؛ ابزاری برای آشکارسازی و مدیریت ریسک است. به‌جای انتظار قطعیت، روی کشف سریع‌تر، عرضه‌های ایمن‌تر و تصمیم‌های هوشمندانه درباره محل سرمایه‌گذاری تمرکز کنیم.
#SoftwareTesting #QualityEngineering #BlamelessPostmortem #RiskBasedTesting #Testability #Observability #DevOps #Agile
🟣لینک مقاله:
https://cur.at/7DobXrn?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
"Why didn't testing find this issue?" Because you desire something that doesn't exist!
🟢 خلاصه مقاله:
وقتی خطایی به تولید می‌رسد، پرسش تکراری این است: «چرا تست‌ها این مشکل را پیدا نکردند؟» Maaike Brinkhof می‌گوید ریشه‌ی این پرسش اشتباه است، چون چنین قطعیتی از تست انتظار داریم که اصلاً وجود ندارد. تست فقط می‌تواند اعتماد را افزایش دهد و ریسک‌ها را آشکار کند؛ هرگز نمی‌تواند نبودِ باگ را ثابت کند.
به‌جای سرزنش «تست»، بحث را به مسئولیت جمعی و یادگیری سیستمی تغییر دهیم: «چطور فرایند، فرض‌ها و طراحی ما اجازه‌ی فرار این باگ را داده‌اند؟» عوامل رایج شامل ابهام در نیازها، تفاوت محیط‌ها با تولید، داده‌ی ناکافی، مشاهده‌پذیری ضعیف، یا مصالحه‌های زمان‌بندی است. مجموعه تست‌ها فقط نمونه‌ای از واقعیت‌اند، نه تمام آن.
راه‌حل، مدیریت ریسک و بهبود چرخه‌های بازخورد است: تقویت logging و telemetry، استفاده از feature flag و انتشار تدریجی، بهبود تست‌های قرارداد و سفرهای حیاتی کاربر، و سرمایه‌گذاری روی تست اکتشافی برای کشف ناشناخته‌ها. با postmortem بدون سرزنش بپرسیم: ریسک را درست فهمیدیم؟ نظارت ما برای کشف سریع و محدودکردن دامنه مشکل کافی بود؟ داده و محیط مناسب داشتیم؟ آیا pairing، بازبینی یا risk storming می‌توانست زودتر هشدار بدهد؟
جمع‌بندی: تست تضمین نیست؛ ابزاری برای آشکارسازی و مدیریت ریسک است. به‌جای انتظار قطعیت، روی کشف سریع‌تر، عرضه‌های ایمن‌تر و تصمیم‌های هوشمندانه درباره محل سرمایه‌گذاری تمرکز کنیم.
#SoftwareTesting #QualityEngineering #BlamelessPostmortem #RiskBasedTesting #Testability #Observability #DevOps #Agile
🟣لینک مقاله:
https://cur.at/7DobXrn?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Maaike Brinkhof's blog
"Why didn't testing find this issue?" Because you desire something that doesn't exist!
After 15 years in software testing, this is still a topic I'm dealing with way too often: people who have a completely misguided understanding of what testing can and cannot do.
In the year 2025, too many people think testing is:
* a phase, not a continuous…
In the year 2025, too many people think testing is:
* a phase, not a continuous…
🔵 عنوان مقاله
👼 A cloud firewall you don't need to babysit (Sponsor)
🟢 خلاصه مقاله:
سامانه‌های فایروال ابری به‌ویژه برای تیم‌های کوچک به‌سرعت پیچیده و پر از هشدار می‌شوند و همین پیچیدگی هم ریسک خطای پیکربندی را بالا می‌برد و هم تمرکز تیم را می‌گیرد. Intrusion Shield for AWS با اتکا به دهه‌ها تهدیدشناسی قابل اتکا، ترافیک پرریسک را به‌صورت خودکار شناسایی و مسدود می‌کند. هر تلاش مخرب برای اتصال، بی‌درنگ به یک قانون فایروال دقیق تبدیل می‌شود؛ بدون نیاز به اقدام دستی. خروجی این رویکرد، کاهش هشدارها و اولویت‌بندی هوشمند است تا تیم روی مسائل مهم‌تر تمرکز کند، در حالی‌که دفاع‌ها با به‌روزرسانی مداوم هوشمندانه با تهدیدات جدید همگام می‌مانند.
#CloudSecurity #Firewall #AWS #ThreatIntelligence #Automation #DevOps #NetworkSecurity
🟣لینک مقاله:
https://www.intrusion.com/intrusion-shield-cloud-for-aws-tldr/?utm_campaign=22505002-AWS_Launch_2025&utm_source=TLDR&utm_medium=100825
➖➖➖➖➖➖➖➖
👑 @software_Labdon
👼 A cloud firewall you don't need to babysit (Sponsor)
🟢 خلاصه مقاله:
سامانه‌های فایروال ابری به‌ویژه برای تیم‌های کوچک به‌سرعت پیچیده و پر از هشدار می‌شوند و همین پیچیدگی هم ریسک خطای پیکربندی را بالا می‌برد و هم تمرکز تیم را می‌گیرد. Intrusion Shield for AWS با اتکا به دهه‌ها تهدیدشناسی قابل اتکا، ترافیک پرریسک را به‌صورت خودکار شناسایی و مسدود می‌کند. هر تلاش مخرب برای اتصال، بی‌درنگ به یک قانون فایروال دقیق تبدیل می‌شود؛ بدون نیاز به اقدام دستی. خروجی این رویکرد، کاهش هشدارها و اولویت‌بندی هوشمند است تا تیم روی مسائل مهم‌تر تمرکز کند، در حالی‌که دفاع‌ها با به‌روزرسانی مداوم هوشمندانه با تهدیدات جدید همگام می‌مانند.
#CloudSecurity #Firewall #AWS #ThreatIntelligence #Automation #DevOps #NetworkSecurity
🟣لینک مقاله:
https://www.intrusion.com/intrusion-shield-cloud-for-aws-tldr/?utm_campaign=22505002-AWS_Launch_2025&utm_source=TLDR&utm_medium=100825
➖➖➖➖➖➖➖➖
👑 @software_Labdon
👍2
🔵 عنوان مقاله
How We Utilize AI Agents in Our Testing and Quality Processes
🟢 خلاصه مقاله:
این مقاله با روایت Utku Kılınçcı چهار کاربرد عملی از به‌کارگیری AI agents در تست و تضمین کیفیت را توضیح می‌دهد: ۱) تبدیل نیازمندی‌ها به تست‌های قابل اجرا و به‌روزرسانی مداوم سبد تست با تغییرات مشخصات، ۲) نقش همکار اکتشافی برای کشف سناریوهای مرزی، ثبت شواهد و بازتولید مشکل، ۳) تحلیل و اولویت‌بندی باگ‌ها از طریق خلاصه‌سازی لاگ‌ها، خوشه‌بندی خطاها و ارائه سرنخ‌های ریشه‌یابی، و ۴) بهبود پایداری رگرسیون و درگاه‌های کیفی CI با شناسایی تست‌های flaky، پیشنهاد خوددرمانی و بهینه‌سازی پایپ‌لاین. در همه موارد، نظارت انسانی، رعایت حریم داده و سنجش نتایج (پوشش، MTTR، روند flakiness و زمان چرخه) ضروری است. نتیجه: پذیرش تدریجی AI agents روی مسائل واقعی، سرعت، پایداری و پوشش تست را به‌طور ملموس افزایش می‌دهد بی‌آنکه مالکیت کیفیت را تضعیف کند.
#SoftwareTesting #AIagents #QualityAssurance #TestAutomation #BugTriage #ContinuousIntegration #SoftwareQuality #DevOps
🟣لینک مقاله:
https://cur.at/qRpZzn9?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
How We Utilize AI Agents in Our Testing and Quality Processes
🟢 خلاصه مقاله:
این مقاله با روایت Utku Kılınçcı چهار کاربرد عملی از به‌کارگیری AI agents در تست و تضمین کیفیت را توضیح می‌دهد: ۱) تبدیل نیازمندی‌ها به تست‌های قابل اجرا و به‌روزرسانی مداوم سبد تست با تغییرات مشخصات، ۲) نقش همکار اکتشافی برای کشف سناریوهای مرزی، ثبت شواهد و بازتولید مشکل، ۳) تحلیل و اولویت‌بندی باگ‌ها از طریق خلاصه‌سازی لاگ‌ها، خوشه‌بندی خطاها و ارائه سرنخ‌های ریشه‌یابی، و ۴) بهبود پایداری رگرسیون و درگاه‌های کیفی CI با شناسایی تست‌های flaky، پیشنهاد خوددرمانی و بهینه‌سازی پایپ‌لاین. در همه موارد، نظارت انسانی، رعایت حریم داده و سنجش نتایج (پوشش، MTTR، روند flakiness و زمان چرخه) ضروری است. نتیجه: پذیرش تدریجی AI agents روی مسائل واقعی، سرعت، پایداری و پوشش تست را به‌طور ملموس افزایش می‌دهد بی‌آنکه مالکیت کیفیت را تضعیف کند.
#SoftwareTesting #AIagents #QualityAssurance #TestAutomation #BugTriage #ContinuousIntegration #SoftwareQuality #DevOps
🟣لینک مقاله:
https://cur.at/qRpZzn9?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
How We Utilize AI Agents in Our Testing and Quality Processes
Hello everyone. In this article, We will try to explain how we utilize AI tools in our team at Trendyol. The purpose of this article is to…
🔵 عنوان مقاله
trdl (GitHub Repo)
🟢 خلاصه مقاله:
خلاصه‌ای متن‌باز به نام trdl با تمرکز بر «تحویل مطمئن» آخرین مرحله‌ی توزیع نرم‌افزار را امن می‌کند: رساندن به‌روزرسانی‌ها از Git به کاربر نهایی با کانالی قابل‌اعتماد و قابل‌راستی‌آزمایی. این راهکار با اتصال طبیعی به فرآیندهای مبتنی بر Git و ادغام در اتوماسیون انتشار، تضمین می‌کند آنچه نصب می‌شود همان چیزی است که نگه‌دارندگان منتشر کرده‌اند. با تکیه بر امضا و راستی‌آزمایی رمزنگاری، اصالت، تمامیت و مبدأ به‌روزرسانی‌ها قبل از اعمال بررسی می‌شود؛ در نتیجه ریسک‌های زنجیره تأمین کاهش می‌یابد و امکان انتشارهای قابل‌ممیزی، بازگشت نسخه و سیاست‌های به‌روزرسانی (مانند stable یا pre-release) فراهم می‌شود. trdl متن‌باز است، می‌تواند self-hosted اجرا شود، و از طریق GitHub Repo در دسترس است؛ کاربران و تیم‌های عملیاتی نیز می‌توانند با یک رابط ساده مانند CLI به‌روزرسانی‌های مورد اعتماد را دریافت و اعمال کنند.
#trdl #SupplyChainSecurity #SecureUpdates #Git #OpenSource #DevOps #SoftwareDelivery #CI/CD
🟣لینک مقاله:
https://github.com/werf/trdl?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
trdl (GitHub Repo)
🟢 خلاصه مقاله:
خلاصه‌ای متن‌باز به نام trdl با تمرکز بر «تحویل مطمئن» آخرین مرحله‌ی توزیع نرم‌افزار را امن می‌کند: رساندن به‌روزرسانی‌ها از Git به کاربر نهایی با کانالی قابل‌اعتماد و قابل‌راستی‌آزمایی. این راهکار با اتصال طبیعی به فرآیندهای مبتنی بر Git و ادغام در اتوماسیون انتشار، تضمین می‌کند آنچه نصب می‌شود همان چیزی است که نگه‌دارندگان منتشر کرده‌اند. با تکیه بر امضا و راستی‌آزمایی رمزنگاری، اصالت، تمامیت و مبدأ به‌روزرسانی‌ها قبل از اعمال بررسی می‌شود؛ در نتیجه ریسک‌های زنجیره تأمین کاهش می‌یابد و امکان انتشارهای قابل‌ممیزی، بازگشت نسخه و سیاست‌های به‌روزرسانی (مانند stable یا pre-release) فراهم می‌شود. trdl متن‌باز است، می‌تواند self-hosted اجرا شود، و از طریق GitHub Repo در دسترس است؛ کاربران و تیم‌های عملیاتی نیز می‌توانند با یک رابط ساده مانند CLI به‌روزرسانی‌های مورد اعتماد را دریافت و اعمال کنند.
#trdl #SupplyChainSecurity #SecureUpdates #Git #OpenSource #DevOps #SoftwareDelivery #CI/CD
🟣لینک مقاله:
https://github.com/werf/trdl?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
GitHub
GitHub - werf/trdl: The universal solution for delivering your software updates securely from a trusted The Update Framework (TUF)…
The universal solution for delivering your software updates securely from a trusted The Update Framework (TUF) repository. - werf/trdl
🔵 عنوان مقاله
In Sprint Test Automation
🟢 خلاصه مقاله:
در آزمون‌سازی درون‌اسپرینت در Agile، هدف این است که تست‌ها همزمان با توسعه نوشته و اجرا شوند تا بازخورد سریع و خطاهای انباشته کاهش یابد. تجربه‌ها نشان می‌دهد موفقیت به چند عامل وابسته است: خرد کردن قصه‌ها به قطعات کوچک و قابل‌آزمون، پذیرش «Definition of Ready» و «Definition of Done» که شامل آزمون خودکار است، همکاری نزدیک Dev و QA با رویکردهای TDD/BDD، و برخورد با تست مثل کد (همان مخزن، همان استراتژی شاخه، همان بازبینی کد).
برای پشتیبانی از این جریان، CI/CD باید سریع و قابل‌اعتماد باشد: اجرای موازی، محیط‌های موقتی مبتنی بر کانتینر، مجازی‌سازی سرویس‌ها و Mockها برای قطع وابستگی‌ها، و مدیریت داده‌ی تست که آزمون‌ها را تکرارپذیر و بدون نوسان نگه می‌دارد. تمرکز بر هرم تست ضروری است: پوشش بالای Unit و Integration/Contract، و تنها یک لایه نازک از E2E UI (مثلاً با Cypress یا Playwright)؛ در کنار آن، سنجه‌هایی مانند زمان رسیدن تغییر تا استقرار، نرخ شکست و زمان ترمیم رصد می‌شوند و تست‌های flaky سریع قرنطینه و اصلاح می‌گردند.
همچنین پرهیز از الگوهای ضدِکیفیت مانند «Hardening Sprint»، عقب‌انداختن اتوماسیون به‌عنوان بدهی، یا اتکا به E2E شکننده توصیه می‌شود. استفاده از Feature Flag، Contract Testing در معماری‌های مبتنی بر سرویس، و مالکیت مشترک کیفیت در کل تیم به تحقق «اتمام واقعی کار» در همان اسپرینت کمک می‌کند.
#Agile #TestAutomation #InSprintTesting #CI_CD #TDD #BDD #DevOps
🟣لینک مقاله:
https://cur.at/46VanjF?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
In Sprint Test Automation
🟢 خلاصه مقاله:
در آزمون‌سازی درون‌اسپرینت در Agile، هدف این است که تست‌ها همزمان با توسعه نوشته و اجرا شوند تا بازخورد سریع و خطاهای انباشته کاهش یابد. تجربه‌ها نشان می‌دهد موفقیت به چند عامل وابسته است: خرد کردن قصه‌ها به قطعات کوچک و قابل‌آزمون، پذیرش «Definition of Ready» و «Definition of Done» که شامل آزمون خودکار است، همکاری نزدیک Dev و QA با رویکردهای TDD/BDD، و برخورد با تست مثل کد (همان مخزن، همان استراتژی شاخه، همان بازبینی کد).
برای پشتیبانی از این جریان، CI/CD باید سریع و قابل‌اعتماد باشد: اجرای موازی، محیط‌های موقتی مبتنی بر کانتینر، مجازی‌سازی سرویس‌ها و Mockها برای قطع وابستگی‌ها، و مدیریت داده‌ی تست که آزمون‌ها را تکرارپذیر و بدون نوسان نگه می‌دارد. تمرکز بر هرم تست ضروری است: پوشش بالای Unit و Integration/Contract، و تنها یک لایه نازک از E2E UI (مثلاً با Cypress یا Playwright)؛ در کنار آن، سنجه‌هایی مانند زمان رسیدن تغییر تا استقرار، نرخ شکست و زمان ترمیم رصد می‌شوند و تست‌های flaky سریع قرنطینه و اصلاح می‌گردند.
همچنین پرهیز از الگوهای ضدِکیفیت مانند «Hardening Sprint»، عقب‌انداختن اتوماسیون به‌عنوان بدهی، یا اتکا به E2E شکننده توصیه می‌شود. استفاده از Feature Flag، Contract Testing در معماری‌های مبتنی بر سرویس، و مالکیت مشترک کیفیت در کل تیم به تحقق «اتمام واقعی کار» در همان اسپرینت کمک می‌کند.
#Agile #TestAutomation #InSprintTesting #CI_CD #TDD #BDD #DevOps
🟣لینک مقاله:
https://cur.at/46VanjF?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Reddit
From the QualityAssurance community on Reddit
Explore this post and more from the QualityAssurance community
👍1
🔵 عنوان مقاله
Why QA Keep Losing the Same Battles, even when Automation and AI is integrated
🟢 خلاصه مقاله:
این مقاله می‌گوید با وجود سرمایه‌گذاری در Automation و AI، مشکلات QA تکرار می‌شوند، چون مسأله اصلی کمبود ابزار نیست، بلکه نبود هم‌راستایی بر سر معنای «کیفیت» و شیوه ساختن آن است. به‌گفته Marina Jordão، کیفیت واقعی از انسان‌ها، استراتژی و حمایت از کاربر می‌آید؛ ابزارها فقط سرعت می‌دهند، اما جای تحلیل ریسک، معیارهای شفاف و آزمون اکتشافی را نمی‌گیرند. شکست‌های تکراری زمانی رخ می‌دهد که QA دیر وارد چرخه می‌شود، شاخص‌ها سطحی‌اند و تمرکز از نتایج واقعی برای کاربر دور می‌شود. راه‌حل، دیدن کیفیت به‌عنوان مسئولیت تیمی، درگیر کردن زودهنگام QA، تکیه بر پیشگیری به‌جای صرفاً کشف خطا و به‌کارگیری Automation و AI به‌عنوان تقویت‌کننده قضاوت انسانی است.
#QA #Testing #Automation #AI #QualityEngineering #UserAdvocacy #TestStrategy #DevOps
🟣لینک مقاله:
https://cur.at/UzsHvzU?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Why QA Keep Losing the Same Battles, even when Automation and AI is integrated
🟢 خلاصه مقاله:
این مقاله می‌گوید با وجود سرمایه‌گذاری در Automation و AI، مشکلات QA تکرار می‌شوند، چون مسأله اصلی کمبود ابزار نیست، بلکه نبود هم‌راستایی بر سر معنای «کیفیت» و شیوه ساختن آن است. به‌گفته Marina Jordão، کیفیت واقعی از انسان‌ها، استراتژی و حمایت از کاربر می‌آید؛ ابزارها فقط سرعت می‌دهند، اما جای تحلیل ریسک، معیارهای شفاف و آزمون اکتشافی را نمی‌گیرند. شکست‌های تکراری زمانی رخ می‌دهد که QA دیر وارد چرخه می‌شود، شاخص‌ها سطحی‌اند و تمرکز از نتایج واقعی برای کاربر دور می‌شود. راه‌حل، دیدن کیفیت به‌عنوان مسئولیت تیمی، درگیر کردن زودهنگام QA، تکیه بر پیشگیری به‌جای صرفاً کشف خطا و به‌کارگیری Automation و AI به‌عنوان تقویت‌کننده قضاوت انسانی است.
#QA #Testing #Automation #AI #QualityEngineering #UserAdvocacy #TestStrategy #DevOps
🟣لینک مقاله:
https://cur.at/UzsHvzU?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
Why QA Keep Losing the Same Battles, even when Automation and is integrated
Why QA Keep Losing the Same Battles, even when Automation and AI is integrated Today, building software without test automation and AI is like trying to run a modern city without electricity. You can …
🔵 عنوان مقاله
Power pairing our people process: How we moved to a collaborative QA Engineer and QA Analyst model
🟢 خلاصه مقاله:
** این مقاله نشان می‌دهد که با جفت‌کردن نقش‌های مکمل در کیفیت، یعنی QA Engineer و QA Analyst، می‌توان کیفیت را از یک مرحله انتهایی به یک فعالیت پیوسته و مشارکتی در دل فرایند توسعه تبدیل کرد. بر اساس ایده‌های Matthew Whitaker و همسو با فلسفه pair-programming، QA Engineer روی اتوماسیون، ابزارها و CI/CD تمرکز می‌کند و QA Analyst بر تحلیل نیازمندی‌ها، آزمون اکتشافی و مدیریت ریسک؛ و همکاری نزدیک آن‌ها شکاف‌های فنی و محصولی را کاهش می‌دهد. این جفت به‌صورت مشترک معیارهای پذیرش و استراتژی آزمون را می‌نویسد، بین نقش «راننده/راهنما» جابه‌جا می‌شود و یافته‌های اکتشافی را سریع به تست‌های خودکار قابل نگهداری تبدیل می‌کند. پیاده‌سازی موفق با یک پایلوت، برنامه pairing شفاف، ابزارهای دیدپذیری، و سنجه‌هایی مانند نرخ خطای فرار، زمان چرخه و نرخ بازکار آغاز می‌شود و با مدیریت چالش‌هایی مانند ابهام نقش و خستگی جلسات از طریق RACI سبک، پلی‌بوک، تایم‌باکس و آداب pairing تثبیت می‌شود. دستاوردها شامل بازخورد سریع‌تر، کاهش خطاهای فرار، مالکیت مشترک کیفیت و انتقال دانش گسترده‌تر در تیم است؛ همان درسی که از pair-programming می‌گیریم: دو ذهن مکمل، از یک متخصص تنها مؤثرترند.
#QA #PairProgramming #QualityAssurance #AgileTesting #Collaboration #DevOps #TestAutomation #TeamCulture
🟣لینک مقاله:
https://cur.at/EuZObTr?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Power pairing our people process: How we moved to a collaborative QA Engineer and QA Analyst model
🟢 خلاصه مقاله:
** این مقاله نشان می‌دهد که با جفت‌کردن نقش‌های مکمل در کیفیت، یعنی QA Engineer و QA Analyst، می‌توان کیفیت را از یک مرحله انتهایی به یک فعالیت پیوسته و مشارکتی در دل فرایند توسعه تبدیل کرد. بر اساس ایده‌های Matthew Whitaker و همسو با فلسفه pair-programming، QA Engineer روی اتوماسیون، ابزارها و CI/CD تمرکز می‌کند و QA Analyst بر تحلیل نیازمندی‌ها، آزمون اکتشافی و مدیریت ریسک؛ و همکاری نزدیک آن‌ها شکاف‌های فنی و محصولی را کاهش می‌دهد. این جفت به‌صورت مشترک معیارهای پذیرش و استراتژی آزمون را می‌نویسد، بین نقش «راننده/راهنما» جابه‌جا می‌شود و یافته‌های اکتشافی را سریع به تست‌های خودکار قابل نگهداری تبدیل می‌کند. پیاده‌سازی موفق با یک پایلوت، برنامه pairing شفاف، ابزارهای دیدپذیری، و سنجه‌هایی مانند نرخ خطای فرار، زمان چرخه و نرخ بازکار آغاز می‌شود و با مدیریت چالش‌هایی مانند ابهام نقش و خستگی جلسات از طریق RACI سبک، پلی‌بوک، تایم‌باکس و آداب pairing تثبیت می‌شود. دستاوردها شامل بازخورد سریع‌تر، کاهش خطاهای فرار، مالکیت مشترک کیفیت و انتقال دانش گسترده‌تر در تیم است؛ همان درسی که از pair-programming می‌گیریم: دو ذهن مکمل، از یک متخصص تنها مؤثرترند.
#QA #PairProgramming #QualityAssurance #AgileTesting #Collaboration #DevOps #TestAutomation #TeamCulture
🟣لینک مقاله:
https://cur.at/EuZObTr?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Ministry of Testing
Power pairing our people process: How we moved to a collaborative QA Engineer and QA Analyst model
Pairing QA Engineers and Analysts isn't just a process tweak, it's a cultural shift that transforms siloed testing into a collaborative, balanced and business-aligned effort.