📣 Finally I managed to release my handbook:
How to Fail Test Automation Easily!
Lessons I’ve Learned (and Unlearned) from Failed Test Automation

This handbook dives deep into 60+ real-world mistakes in test automation that I’ve seen countless teams make, small, daily habits that silently destroy test reliability, slow down development, and erode confidence.

📙 Inside, you’ll find practical guidance and examples on:

1. Strategy & Mindset: How teams think about testing, not just how they do it. Avoid treating testing as a checkbox or a late-phase activity.
2. Test Design & Intent: Writing meaningful tests, avoiding overlapping coverage, and focusing on behavior, not implementation.
3. Technical & Execution Mistakes: Handling flaky, slow, or fragile tests, and creating resilient test setups.
4. Tools & Infrastructure: Choosing frameworks wisely, CI/CD pipelines, observability, and maintaining test suites.
5. Team & Collaboration: Breaking silos between QA, Dev, and Product, defining ownership, and improving knowledge sharing.
6. Cost & Value: Understanding ROI, avoiding uneconomical tests, and prioritizing what really matters.
7. Context & Local Challenges: Real-world constraints, common anti-patterns, and strategies to test effectively in complex domains.

💡 Beyond the lessons, the book also includes:
✅ Checklists for healthy testing habits and common bad smells
✅ A Test Strategy Template to guide your team’s approach
✅ Domain-Centric Test Naming examples to align tests with business intent
✅ A Metrics Cheat Sheet showing what to measure (and what to ignore)

With concrete JavaScript examples, realistic scenarios (like bookings, orders, and accounting), and actionable solutions, this book helps you build tests that actually protect both the software and the business.

Whether you are a developer, QA engineer, architect, or team lead, this book will help you recognize bad practices, understand why they happen, and adopt healthy testing habits that improve confidence, speed, and maintainability.

🙏 It’s completely free, if you find it useful, please share it with your team, colleagues, or anyone who’s passionate about better testing.

✍️ Author: Masoud Bahrami
🌐 MasoudBahrami.com
📘 Version: 1.0.0

Download for free:
https://leanpub.com/TestAutomationMistakes

سلام به همگی عزیزان عصر جمعتون بخیر باشه
لایو به زودی استارت میخوره. منتظرتون هستیم

📚 فهرست منابع و لینک‌های پیشنهادی که در طول لایو دمو به آنها اشاره شد

🔹 وب‌سایت رسمی EDD
🔗 https://exploratorydomaindiscovery.com
خانه‌ی EDD، شامل مقالات، مثال‌ها، ابزارها و نظریه‌های پایه.

🔹 معرفی رسمی Exploratory Domain Discovery
🔗 https://exploratorydomaindiscovery.com/b/introducing-exploratory-domain-discovery/
مقدمه‌ای رسمی بر EDD، هدف، ساختار و طرز فکر پشت آن.

🔹 اولین جریان اکتشاف (مثال دمو)
🔗 https://exploratorydomaindiscovery.com/b/the-first-flow-of-exploratory-domain-discovery/
یک نمونه‌ی عملی و گام‌به‌گام از اولین جریان اکتشاف.

🔹 معرفی Domain Circular Pattern (خیلی مهم) ❗️
🔗 https://exploratorydomaindiscovery.com/b/domain-circular-patterns/
توضیح مفهوم چرخه‌ی ارزش و تکرار الگوها در دامنه‌های پیچیده.

🔹 قلب EDD
🔗 https://exploratorydomaindiscovery.com/b/the-heart-of-exploratory-domain-discovery/
بررسی فلسفه‌ی پشت EDD و مفهوم Main Point.

🔹 بلوک‌های سازنده‌ی EDD
🔗 https://exploratorydomaindiscovery.com/b/building-blocks-of-edd/
شرح دقیق بلوک‌های اساسی مورد استفاده در جلسات اکتشاف.

🔹 چهار نقش از پنج نقش
🔗 https://exploratorydomaindiscovery.com/b/the-4-out-of-5-roles/
تشریح نقش‌ها و دینامیک بین افراد در ورکشاپ EDD

🔹 سخنرانی کنفرانس Naming is Caring با موضوع DDD Europe 2024
🔗 https://2024.dddeurope.com/program/naming-is-caring/
متدولوژی EDD اولین بار توسط مسعود بهرامی در DDD Europe 2024 معرفی شد. این رویکرد در ابتدا با عنوان Breadth-First Exploration ارائه شده بود و بعدها برای انعکاس بهتر هدف و گستره‌ی آن به Exploratory Domain Discovery تغییر نام پیدا کرد.

📺ویدئوی رویداد سوم نقطه با موضوع: موضوع: چطور تصمیم‌ها در تیم شما گرفته می‌شوند؟

در تیم‌های نرم‌افزاری، تصمیم‌ها فقط گرفته نمی‌شوند، ساخته می‌شوند، توسط آدم‌ها، نقش‌ها و فرهنگ تیم. توی این تیم‌ها تصمیم‌گیری فقط انتخاب بین چند گزینه نیست؛ بلکه ملغمه‌ای است از قدرت، ارتباط، فرهنگ و تعامل بین نقش‌های مختلف است.

در این گفت‌وگوی جمعی از سری برنامه‌های آنلاین نقطه درباره‌ی "فلو تصمیم‌گیری" در تیم‌ها صحبت شد.

ویدئوی این رویداد در کانال یوتیوب منتشر شده است. می‌توانید از طریق لینک زیر ویدئوی کامل رو مشاهده بفرمائید.(توضیح اینکه متاسفانه بخاطر مشکلی که پیش اومد، قسمت‌های ابتدایی برنامه ریکورد نشده)

https://www.youtube.com/watch?v=krbVAXXZsho

🌟 رویداد چهارم نقطه: چه چیزی فرهنگ تیمی موفق را می‌سازد؟

در تیم‌های موفق، فرهنگ فقط به فعالیت‌های سرگرم‌کننده یا ارزش‌های شعاری محدود نمی‌شود، بلکه شامل رفتارها، ارتباطات، اعتماد و روش‌های مشترک کار کردن است.

در این جلسه بحث و تبادل نظر گروهی، بررسی می‌کنیم:
- اعضای تیم چگونه روی فرهنگ اثر می‌گذارند
- چه رفتارهایی تشویق یا محدود می‌شوند
- چگونه تعارضات، بازخورد و موفقیت‌ها تیم را شکل می‌دهند

سؤالات برای بحث:
⬅️ چه رفتارها یا عادت‌هایی تیم را مثبت و مؤثر می‌کنند؟
⬅️ اعتماد در تیم چگونه شکل می‌گیرد و چه چیزی آن را خراب می‌کند؟
⬅️ تیم شما با اختلاف نظر یا تعارض‌ها چگونه برخورد می‌کند؟
⬅️ چه روش‌ها یا مراسمی به تیم کمک می‌کنند هماهنگ و انگیزه‌مند باقی بماند؟

🗓 تاریخ: سه‌شنبه، ۲۸ آبان ۱۴۰۴
🕖 زمان: ۱۹:۰۰ – ۲۰:۳۰
💻 مکان: آنلاین(لینک رویداد برای افراد بعدا ارسال خواهد شد)

🔵 لینک ثبت‌نام:
https://luma.com/r09py22a

🔵 صفحه رویداد در لینکدین(لطفا بر روی attend کلیک کنید)
https://www.linkedin.com/events/7395354056090750976/

برنامه شروع شده عزیزان. لینک رویداد برای همه عزیزان ایمیل شده. می‌تونید از طریق لینک زیر جوین بشید به رویداد

https://event.alocom.co/class/soheilkarami/noghteh0

📚 لیست منابع برای مطالعه بیشتر

1. کتاب Radical Candor
مدیریت انسانی، بازخورد صادقانه و محترمانه
🔗 https://www.radicalcandor.com/the-book

2. مقاله "Communication is The Job"
نوشته‌ی اندرو بوسورث (CTO متا) – اهمیت نقش ارتباطات در تیم‌ها
🔗 https://boz.com/articles/communication-is-the-job

3. پادکست WeAreNetflix – موضوع: Feedback
گفتگو درباره فرهنگ بازخورد در نتفلیکس
🔗 https://www.youtube.com/watch?v=M-NYcfyVMeU

4. ویدیو: 5 درس برتر رید هستینگز، مدیرعامل نتفلیکس
🔗 https://www.youtube.com/watch?v=BH-Dq50Cz8Q

5. سخنرانی Patty McCord – Creating High Performance Culture (Talks at Google)
🔗 https://www.youtube.com/watch?v=thzDy5A-KfE

6. Netflix’s Engineering Culture
پست / پادکست گرگ اوروز با CTO نتفلیکس، الیزابت استون
🔗 https://newsletter.pragmaticengineer.com/p/netflix

7. Sustaining a Day 1 Culture – Amazon
سخنرانی بث گالتی (Amazon SVP HR)
🔗 https://www.youtube.com/watch?v=oq69KKpq0b0

8. How Netflix builds a culture of excellence – Lenny’s Podcast
گفتگو با الیزابت استون (CTO)
🔗 https://www.youtube.com/watch?v=2XgU6T4DalY

📺How AI will change Software Engineering?

Hosted by Gergely Orosz from The Pragmatic Engineer with Martin Fowler

🔹Abstract:
In this episode, they discuss how AI is changing software development: the shift from deterministic! to non-deterministic! coding; where generative models help with legacy code; and the narrow but useful cases for vibe coding. Martin explains why LLM output must be tested rigorously, why refactoring is more important than ever, and how combining AI tools with deterministic techniques may be what engineering teams need.

They also revisit the origins of the Agile Manifesto and talk about why, despite rapid changes in tooling and workflows, the skills that make a great engineer remain largely unchanged.

🔵 Watch the video:
https://www.youtube.com/watch?v=CQmI4XKTa0U

🎬 ویدئوی رویداد: Exploratory Domain Discovery - Live Demo

🔵 معرفی کوتاه: Exploratory Domain Discovery(EDD) یک رویکرد مدل‌سازی و طراحی مشارکتی است که با شروع از نتیجه (Outcome) مورد انتظار از سیستم، فضای مسئله را به صورت معکوس (Backward) مدل‌سازی می‌کند.

این رویکرد با داشتن متدولوژی منحصر به فرد خود، ابزاری قدرتمند برای فهم و مدل‌سازی دامنه‌های پیچیده به شمار می‌رود. EDD یک روش تجربی و سریع است که به ما کمک می‌کند تا کلیدی‌ترین مفاهیمی که نقشی اساسی در طراحی و مدل‌سازی فضای مسئله دارند را کشف کنیم.

اجزای سازنده اصلی EDD (ساده و کم‌تعداد):
🔹 کارت مفهوم دامنه (Domain Concept)
🔹 ارتباطات بین مفاهیم دامنه
🔹 کارت مثال (Example) به ازای هر مفهوم دامنه
🔹 کارت سوال یا چالش
🔹 کارت قانون کسب‌وکار (Business Rule)

🎙 محتوای این رویداد:
مسعود بهرامی در این رویداد، ضمن معرفی کامل EDD، به صورت عملی و زنده (Live Demo) نشان داد که چطور می‌توان از این رویکرد برای مدل‌سازی یک دامنه پیچیده بهره برد.

خبر خوب برای علاقه‌مندان: در وبینار بعدی به صورت زنده نشان خواهیم داد که EDD چگونه می‌تواند در مرحله طراحی سیستم (System Design) به ما کمک کند.

لینک تماشای کامل ویدئو: 👇
https://www.youtube.com/watch?v=brMtD9s7Ne4&t

💭 سؤال گروهی امروز:
مسئله‌که در ادامه مطرح میشه، شاید کمی عجیب یا حتی بدیهی به نظر برسه در نگاه اول، اما کمی که غرق مسئله‌اش بشیم خواهیم دید که اینطوری هم فکر میکنیم نیست...

تو پروژه‌های مختلف، وقتی می‌خواید دامنه یک مسئله را درک کنید، معمولاً روی کدام تمرکز می‌کنید؟

🔹جمع‌آوری نیازها (Requirements) از بیزنس و ذینفعان، مثل لیست فیچرها، KPIها، محدودیت‌ها و توقعات مدیر محصول

🔹ساخت و تثبیت زبان مشترک دامنه (Ubiquitous Language) بین تیم توسعه و بیزنس، یعنی همه درباره مفاهیم کلیدی دامنه با یک زبان واحد حرف بزنند و مدل ذهنی مشترک شکل بگیره

💡 تفاوت دیدگاه‌ها در اینجا مطرح هست. برخی معتقدند:

🔵 اول باید Requirements کامل فهمیده شود و بعد سراغ مدل‌سازی و زبان مشترک رفت.

دیگرانی هم می‌گویند:
🔴 تا وقتی زبان مشترک شکل نگرفته، فهم واقعی امکان‌پذیر نیست و باید از ابتدا روی آن کار کرد.

❓ پرسش برای بحث:
- آیا بدون زبان مشترک می‌توانیم Requirements واقعی را درست بفهمیم؟
- یا بدون جمع‌آوری نیازها، زبان مشترک دقیقی شکل نمی‌گیرد؟


🔹 تجربه شما چیست و شما کدام رو برای شروع ترجیح می‌دهید؟ توی گروه کانال می‌تونید نظرات و تجربیاتتون رو به اشتراک بگذارید

پنج‌شنبه‌ی گذشته توی یک ورکشاپ خصوصی طراحی شی‌ءگرا که سهیل کرمی برگزار کرده بود شرکت کردم. قرار بود بازی Catan رو یاد بگیریم، مدل کنیم و طراحی کنیم.

برای من که تجربه‌ی زیادی در بازی‌های اینچنینی ندارم، دنیای این بازی واقعاً پیچیده بود و طبیعتاً مدل‌سازی‌ش هم همینطور 😋😏
اما جذاب‌ترین بخش ماجرا همکاری دولوپرهایی بود با تجربه‌های متفاوت از نظر quantity، quality و depth و اینکه چطور با هم توی مدل‌سازی یک مسئله‌ی پیچیده همکاری می‌کردند.

بچه‌ها مشغول بازی شدن، دیاگرام می‌کشیدن، تست‌کیس می‌نوشتن، حرف می‌زدن، کد می‌زدن و دوباره اصلاح می‌کردن.
میز و کد ظرف چند دقیقه تبدیل شد به جنگلی از اسم‌ها(تا جایی که حضور ذهن دارم!):
Hexagon, Tile, Board, Player, Road, Dice, City, Village, Wood, Brick, Sheep, … 🌪

و خیلی زود این جنگل از اسم‌ها باعث یک سردرگمی مشترک شد:
🔴 پیدا کردن مسیر طراحی بین یک عالمه اسم و رابطه‌ی احتمالی.

توی چنین لحظه‌هایی یک اصل ساده همیشه به من کمک کرده، و همونجا پیشنهاد دادم امتحانش کنن:

از مفاهیم Active شروع کنید، نه Passive
خیلی خلاصه اگر بخوام بگم.
🔹 مفاهیم Passive در دامنه چیزهایی هستند که هیچ جریان فعالی را شروع نمی‌کنند. مدل می‌شوند، یک جایی قرار می‌گیرند، و منتظر می‌مانند تا توسط یک use case دیگر تریگر شوند. معمولاً اطلاعات پایه و context را شکل می‌دهند. مثلاً در حسابداری: Account، Currency، CostCenter

🔹 مفاهیم Active در نقطه مقابل قرار دارند، چیزهایی که اتفاق را رقم می‌زنند. رفتار ایجاد می‌کنند، تصمیم می‌گیرند و بقیه اجزا را به هم وصل می‌کنند. مثلاً: PostTransaction, TransferMoney, PlaceOrder, BookAppointment

حتی در مثال Catan، شما اول Board و قطعات و مخلفاتش رو می‌سازید؛ اما تا وقتی Player شروع به بازی نکند، هیچ اتفاق معناداری نمی‌افتد. همون لحظه است که ارتباط مفاهیم آشکار می‌شود.

وقتی مدل‌سازی را از Active شروع می‌کنیم:

🔹 نقطه ورود روشن می‌شود
🔹 رفتار سیستم شکل می‌گیرد
🔹 ساختار و وابستگی‌ها به طور طبیعی کشف می‌شوند
🔹 به جای نمودارهای زیبا و بی‌معنی، یک سیستم زنده ساخته می‌شود
🔹 مدل‌سازی اسم‌ها نیست؛ مدل‌سازی اتفاق‌هاست
🔹این Behavior است که ساختار را می‌سازد، نه برعکس


خلاصه پیشنهادم برای دامنه‌های پیچیده یا ناشناخته:
✔️ از رفتار شروع کنید
✔️ طراحی را از مفاهیم Active آغاز کنید
✔️ اجازه دهید ساختار از دل اتفاق‌ها شکل بگیرد

📄 کل مقاله و مثال‌های بیشتر را اینجا بخوانید:
https://masoudbahrami.com/article/active-vs-passive-domain-concepts-in-designing-complex-domains/

🔔Design Time Exploratory Domain Discovery

در رویداد قبل، به‌صورت لایو و عملی نشان دادیم چطور می‌توان Exploratory Domain Discovery (EDD) را برای مدلسازی یک دومین پیچیده به‌کار برد.

در جلسه‌ی پیش‌رو، یک گام جلوتر خواهیم رفت و بررسی می‌کنیم که EDD چگونه می‌تواند در طراحی سرویس‌ها، تعیین مرزهای Bounded Context، ساخت Aggregates و ماژولار‌سازی سیستم نقش کلیدی داشته باشد.

در این جلسه به‌طور عملی خواهیم دید که EDD چگونه به موارد زیر کمک می‌کند:
✅ شفاف‌سازی مرزهای سرویس‌ها و باندد کانتکست‌ها
✅ بهبود طراحی اگریگیت‌ها و ساختار ماژولار سیستم
✅ اتخاذ تصمیم‌های طراحی بر اساس فهم مشترک و مشارکتی

📅 زمان: پنجشنبه 13 آذرماه 1404، ساعت 14:00 الی 15:30
🌐 محل: آنلاین – LinkedIn Live
💬 شرکت رایگان است

در این جلسه، با کمک EDD به‌صورت عملی طراحی سرویس‌ها و مدل‌سازی دامنه را بررسی خواهیم کرد و کاربرد آن در پروژه‌های واقعی را مرور می‌کنیم.

🔗 لینک رویداد(لطفاً دکمه Attend را بزنید)
linkedin.com/events/7400403756896399360/

🔗 اطلاعات بیشتر درباره EDD:
exploratorydomaindiscovery.com
🔗 مکتب‌خانه DDD:
domaindrivendesign.ir

سلام به همگی عزیزان
داریم برای لایو آماده میشیم. 🫰

با تشکر از همه عزیزانی که در لایو شرکت کردند.❤️

بابت مشکلات پیش‌اومده و تاخیر لایو عذرخواهی ‌می‌کنیم. اگر سوالی داشتید که نتونستید مطرح کنید یا در لایو کاور نشده بود، بپرسید، حتما پاسخ داده خواهد شد.

در نهایت هم لطفا فیدبک خودتون رو هم مطرح کنید این باعث میشه برنامه‌های بعدی خیلی بهتر طراحی و اجرا بشوند.


🟡🔴همانطور که جلسه قبل هم اشاره شد، همانند طرحی که سال گذشته اجرا کردیم، اگر تصمیم گرفتید EDD رو توی تیم خودتون اجرا کنید، می‌تونید پیام بدید، که در حد ۱-۲ جلسه، کارگاه رو براتون به عنوان facilitator برگزار کنیم. این اجرا هزینه‌ای برای شما نخواهد داشت.

دو نوع ورکشاپ متفاوت در Exploratory Domain Discovery وجود دارد:

ورکشاپ Discovery-Time EDD: این نوع برای مدلسازی فضای مسئله در یک دومین پیچیده استفاده می‌شود.

ورکشاپ Design-Time EDD: این ورکشاپ برای فاز طراحی و ترسیم مرزهای تفکیک دومین کاربرد دارد.

در رویداد زنده‌ی امروز، تمرکز ما بر Design-Time EDD بود. در این جلسه، چند رهیافت معرفی و بررسی شدند که می‌توانند در فرآیند Design-Time EDD مفید واقع شوند. این رهیافت‌ها به صورت خلاصه در زیر آمده‌اند:

🔵 Heuristic 1 – Invariants Define Boundaries
مرزها(خواه در سطح یک سرویس باشند و خواه در سطح طراحی یک AR) جایی ایجاد می‌شوند که یک قاعده همیشه باید برقرار باشد.

🔵 Heuristic 2 – Events Connect, Not Shared Data
مرزهای Bounded Context‌ها باید از طریق رویدادها با هم ارتباط برقرار کنند، نه با اشتراک داده‌ها یا جداول.

🔵 Heuristic 3 – High-Churn Areas Should Be Separate
بخش‌هایی از دومین که تغییرات زیادی دارند بهتر است در باوندد کانتکست جداگانه‌ای قرار بگیرند.

🔵 Heuristic 4 – Model the Rules First, Not the Data
ابتدا با قواعد کسب‌وکار شروع کنید و سپس داده‌ها را اضافه کنید. در غیر این صورت، Aggregate حجیم و ناکارآمد خواهد شد.

🔵 Heuristic 5 – Focus on Flow of Value (Not Components)
پرسش کنید: ارزش کجا ایجاد، تبدیل و تحویل داده می‌شود؟

🔵 Heuristic 6 – Each Aggregate Protects Only One Critical Consistency Rule
یک Aggregate که چندین قاعده‌ی حیاتی را اعمال کند، Aggregate شکست خورده‌ای است(تصحیح می‌کنم :)).

🔵 Heuristic 7 – Domain Circular Pattern: Finding Natural Boundaries

🔵 Heuristic 8 – Ubiquitous Language: Why Words Matter

برای مطالعه‌ی کامل‌تر و جزئیات بیشتر درباره‌ی Design-Time EDD، می‌توانید به لینک‌های زیر مراجعه کنید:
🔹 Introducing Design-Time EDD

🔹 EDD Heuristics for Design-Time

🔵 Clean Code Mastery – Advanced Software Craftsmanship Workshop


در سال‌های اخیر، بسیاری از تیم‌ها با رشد پروژه و اضافه‌شدن فیچرها، به‌جای سرعت بیشتر، با کدهای سنگین، سخت‌خوان، پر از بدهی فنی و توسعه‌پذیری پایین روبه‌رو شده‌اند. از Refactorهای پرهزینه گرفته تا باگ‌هایی که در ساده‌ترین تغییرات ظهور می‌کنند.

تقریباً تمام تیم‌ها در نقطه‌ای از مسیر توسعه، با یک حقیقت تلخ روبه‌رو می‌شوند:
مشکل اصلی، زبان برنامه‌نویسی یا تکنولوژی‌ها نیست، کیفیت کدی است که هر روز تولید می‌شود. حتی در حضور و ظهور AI.

⚪️ ویژگی‌های کلیدی دوره:
🔹آموزش عملی Clean Code، Refactoring، Design Principles و معماری تمیز
🔹تمرین‌های واقعی روی کدهای Legacy
🔹شناسایی و حذف Code Smellها در پروژه‌های واقعی
🔹کارگروهی، Code Review، PR Workflow و تحلیل مشکلات واقعی تیم‌ها
🔹آشنایی با معماری‌های Clean/Hexagonal و رویکرد DDD در سطح کاربردی
🔹یادگیری TDD، Unit/Integration Testing و طراحی Evolvable Code


📅ساختار دوره:
۵ جلسه تخصصی × ۴ ساعت
یک جلسهٔ Hands-on عملی + Q&A

برای جزئیات کامل و ثبت‌نام:
🔗domaindrivendesign.ir

🌟 رویداد پنجم نقطه:
شفافیت در کار تیمی: چطور بگوییم چه می‌خواهیم؟
نقطه به ایستگاه ششم خود (ایندکس پنجم!) رسید.

در این جلسه گفت‌وگو محور، با هم درباره‌ی روش‌های شفاف بیان کردن خواسته‌ها و بهبود همکاری در تیم‌ها حرف می‌زنیم. فرصتی است برای تجربه، یادگیری و شنیدن دیدگاه‌های مختلف.

گاهی در هیاهوی زندگی و روزمرگی‌های کاری، حرف‌هایمان در ذهن‌مان گم می‌شوند. بیایید لحظه‌ای توقف کنیم، گوش دهیم و با هم هم‌کلام شویم؛ دور از شلوغی‌ها و دغدغه‌های روزانه، فرصتی برای تبادل نظر و اشتراک تجربه‌هایمان با یکدیگر.

🗓 تاریخ: سه‌شنبه، 25 آذر ۱۴۰۴
🕖 زمان: ۱۹:۰۰ – ۲۰:۳۰
💻 مکان: آنلاین(لینک رویداد برای افراد بعدا ارسال خواهد شد)

🔗 ثبت‌نام: https://luma.com/kkyijah7