An alternative to Scrum: no endless backlogs, fixed 6-week cycles, and more autonomy for teams. Focus on shaping, betting, and shipping real work.
یه متدلوژی جایگزین برای Scrum که خیلی جدیدا مد شده. یه سری فرقهای جالب داره و توی این کتاب خلاصه شده خودشون توضیح دادن که دقیقا چیه و کی میشه ازش استفاده کرد.
#Agile #Scrum #Methodology #Software #Practice
https://basecamp.com/shapeup/shape-up.pdf
یه متدلوژی جایگزین برای Scrum که خیلی جدیدا مد شده. یه سری فرقهای جالب داره و توی این کتاب خلاصه شده خودشون توضیح دادن که دقیقا چیه و کی میشه ازش استفاده کرد.
#Agile #Scrum #Methodology #Software #Practice
https://basecamp.com/shapeup/shape-up.pdf
❤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
🔵 عنوان مقاله
How to Contribute Meaningfully in Feature Planning
🟢 خلاصه مقاله:
**این مقاله نشان میدهد تسترها با طرح پرسشهای هدفمند میتوانند از ابتدای برنامهریزی فیچر، ارزش بسازند. محورهای کلیدی شامل روشنکردن مسئله و مخاطب، معیارهای موفقیت و محدوده، و ثبت معیارهای پذیرش شفاف است. سپس باید ریسکها و پوشش را زودهنگام آشکار کرد: مسیرهای خطا و لبه، یکپارچگیها و جریان داده، و نیازهای غیرکارکردی مانند امنیت، حریم خصوصی، عملکرد، دسترسپذیری و بومیسازی. تمرکز بر تستپذیری نیز حیاتی است: مشاهدهپذیری با لاگ و متریک، استراتژی اتوماسیون در لایههای مختلف، مدیریت داده آزمایشی و برابری محیطها، و استفاده از feature flag، mock و sandbox برای交交交交交交. در نهایت، برنامه عرضه و یادگیری را تعریف کنید: rollout مرحلهای یا A/B، پایش و هشدار، و برنامه بازگشت. بهگفته Mona M. Abd El-Rahman داشتن یک بانک پرسش آماده، تستر را از نگهبان انتهایی به شریک زودمرحلهای تبدیل میکند و بازخورد سریعتر و کیفیت قابلاندازهگیری بههمراه دارد.
#SoftwareTesting #FeaturePlanning #QualityEngineering #ShiftLeft #TestStrategy #QA #ProductDevelopment #Agile
🟣لینک مقاله:
https://cur.at/J1qOdPm?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
How to Contribute Meaningfully in Feature Planning
🟢 خلاصه مقاله:
**این مقاله نشان میدهد تسترها با طرح پرسشهای هدفمند میتوانند از ابتدای برنامهریزی فیچر، ارزش بسازند. محورهای کلیدی شامل روشنکردن مسئله و مخاطب، معیارهای موفقیت و محدوده، و ثبت معیارهای پذیرش شفاف است. سپس باید ریسکها و پوشش را زودهنگام آشکار کرد: مسیرهای خطا و لبه، یکپارچگیها و جریان داده، و نیازهای غیرکارکردی مانند امنیت، حریم خصوصی، عملکرد، دسترسپذیری و بومیسازی. تمرکز بر تستپذیری نیز حیاتی است: مشاهدهپذیری با لاگ و متریک، استراتژی اتوماسیون در لایههای مختلف، مدیریت داده آزمایشی و برابری محیطها، و استفاده از feature flag، mock و sandbox برای交交交交交交. در نهایت، برنامه عرضه و یادگیری را تعریف کنید: rollout مرحلهای یا A/B، پایش و هشدار، و برنامه بازگشت. بهگفته Mona M. Abd El-Rahman داشتن یک بانک پرسش آماده، تستر را از نگهبان انتهایی به شریک زودمرحلهای تبدیل میکند و بازخورد سریعتر و کیفیت قابلاندازهگیری بههمراه دارد.
#SoftwareTesting #FeaturePlanning #QualityEngineering #ShiftLeft #TestStrategy #QA #ProductDevelopment #Agile
🟣لینک مقاله:
https://cur.at/J1qOdPm?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
🚀 How to Contribute Meaningfully in Feature Planning
Asking the Right Questions Early to Build Usable, Resilient, and Measurable Features
🔵 عنوان مقاله
"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…
🔵 عنوان مقاله
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
🔵 عنوان مقاله
Developing the Right Test Documentation
🟢 خلاصه مقاله:
مستندسازی تست کار جذابی نیست، اما اگر با نگاه به هدف و مخاطب انجام شود، به تصمیمگیری و همراستاسازی تیم کمک جدی میکند. توصیههای Chris Kenst بر مستندات سبک، زنده و متصل به کار روزمره تأکید دارد: تولید حداقل آثار مؤثر مثل چکلیست، چارتر، نقشه پوشش و فهرست ریسکها؛ پیوند دادن آنها با استراتژی تست، ریسک و نتایج CI؛ خودکارسازی جمعآوری شواهد؛ و بازبینی و هرس مداوم برای حذف زوائد. در محیطهای مقرراتی، فقط لایههای لازم مثل نسخهبندی، تأییدها و حداقل ماتریس رهگیری را اضافه کنید، بدون قربانی کردن شفافیت. معیار موفقیت ساده است: آیا مستندات باعث کاهش پرسشهای تکراری، تسریع عیبیابی و تسهیل آنبوردینگ میشود یا نه.
#تست_نرمافزار #مستندسازی #کیفیت_نرمافزار #QA #توسعه_نرمافزار #مدیریت_ریسک #Agile #DevOps
🟣لینک مقاله:
https://cur.at/JfTbdWG?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Developing the Right Test Documentation
🟢 خلاصه مقاله:
مستندسازی تست کار جذابی نیست، اما اگر با نگاه به هدف و مخاطب انجام شود، به تصمیمگیری و همراستاسازی تیم کمک جدی میکند. توصیههای Chris Kenst بر مستندات سبک، زنده و متصل به کار روزمره تأکید دارد: تولید حداقل آثار مؤثر مثل چکلیست، چارتر، نقشه پوشش و فهرست ریسکها؛ پیوند دادن آنها با استراتژی تست، ریسک و نتایج CI؛ خودکارسازی جمعآوری شواهد؛ و بازبینی و هرس مداوم برای حذف زوائد. در محیطهای مقرراتی، فقط لایههای لازم مثل نسخهبندی، تأییدها و حداقل ماتریس رهگیری را اضافه کنید، بدون قربانی کردن شفافیت. معیار موفقیت ساده است: آیا مستندات باعث کاهش پرسشهای تکراری، تسریع عیبیابی و تسهیل آنبوردینگ میشود یا نه.
#تست_نرمافزار #مستندسازی #کیفیت_نرمافزار #QA #توسعه_نرمافزار #مدیریت_ریسک #Agile #DevOps
🟣لینک مقاله:
https://cur.at/JfTbdWG?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Shattered Illusions by Chris Kenst
Developing the Right Test Documentation
The right test documentation is the one that satisfies the goal for the right audience and at the right cost. More often that not it means focusing on the smallest amount of documentation you need to do your job well.