توی این اپیزود با رامین زارع از سرزمین‌های شمال همراه میشیم. البته این شمال یکم زیادی شماله! رامین به قولی بکند کاره و در کشور دانمارک مشغول کاره؛ علاوه بر این، پادکستر کار درستیه و پادکست کامپایل رو میچرخونه!
من و رامین تا وسطهای اپیزود در مورد دانمارک، فرهنگشون، نحوه‌ی کار و خیلی چیزای جالب دیگه صحبت کردیم. بعد از اون رفتیم سراغ کتاب تست در چابک؛ حالا چرا این کتاب اونم داستان داره که مفصل در موردش گپ زدیم. داستان تست، داستان بسیار مهمیه که متاسفانه در صنعت ما مظلوم واقع شده!! امیدوارم با این اپیزود به این بیچاره بیشتر توجه بشه.
ما اولین باره که در مورد کتابی در حوزه‌ی اجایل حرف میزنیم. اینو مدت‌های وعده‌اش رو داده بودیم حالا گفتیم بریم امتحانش کنیم. امیدوارم فیدبک‌ها و نقدتون رو داشته باشیم تا در این مسیر بتونیم بهترعمل کنیم.
تدوین و اجرا: پدرام کشاورزی
مهمان: رامین زارع
طراح پوستر: سید محمد حسین بطحایی
لینک‌های مهم:
Agile Testing: A Practical Guide for Tester and Agile Teams
More Agile Testing: Learning Journeys for the Whole Team
سلام و درود به همه‌ی شنوندگان عزیز.
من پدرام کشاورزی هستم و بسیار خوشحالم که پس از مدتی دوباره در کنار شما هستم. امروز با یک گفت‌وگوی ویژه همراه خواهیم بود؛ گفت‌وگویی مشترک میان دو پادکست: «اجایل‌گپ» و «کامپایل».
من به رسم ادب ابتدا خودم را معرفی می‌کنم. همان‌طور که می‌دانید، من اسکرام مستر و پادکستر «اجایل‌گپ» هستم. در این پادکست تلاش می‌کنیم درباره‌ی به‌کارگیری تفکر اجایل و فریم‌ورک‌های آن گفت‌وگو کنیم؛ اینکه چرا بعضی سازمان‌ها در اجرای این تفکر و چارچوب‌ها موفق نمی‌شوند و چه عواملی در این میان مؤثر است. فرض اصلی ما این است که شنوندگان دست‌کم یک بار با واژه‌ی «اجایل» یا «چابک» آشنا شده‌اند. با این حال، اگر بخواهم خیلی خلاصه بگویم: اجایل رویکردی است برای مدیریت پروژه‌هایی که هم در محصول و هم در محیط پیرامون خود با پیچیدگی بالا روبه‌رو هستند. ما با بهره‌گیری از این تفکر می‌کوشیم مدیریت بهتری داشته باشیم و نتایج مؤثرتری به دست آوریم.
رامین جان، حالا نوبت توست که خودت را معرفی کنی.
رامین:
اول از همه، پدرام جان بهت تبریک می‌گویم که دوران سربازی‌ات را به پایان رساندی. واقعاً حس شیرینی است و کاملاً درکت می‌کنم. من رامین زارع هستم و پادکست «کامپایل» را تهیه می‌کنم. البته نه به انسجام و پیوستگی کار تو در «اجایل‌گپ»، اما بیشتر به چشم یک تفریح و فرصتی برای به اشتراک‌گذاری تجربه‌هایم به آن نگاه می‌کنم. در این پادکست از تجربه‌های شخصی‌ام گفته‌ام: از مهاجرت گرفته تا تفاوت‌هایی که در خارج از ایران دیده‌ام، و حتی کمی هم درباره‌ی اجایل صحبت کرده‌ام.
خودم توسعه‌دهنده‌ی بک‌اند هستم و بیشتر با زبان جاوا کار کرده‌ام. اما همان‌طور که می‌دانی، در دنیای برنامه‌نویسی آشنایی با ذهنیت اجایل و یادگیری اصول آن ضروری است. یکی از اپیزودهایی که منتشر کردم، درباره‌ی تجربه‌ی شخصی‌ام با اسکرام بود. شاید جالب باشد بگویم که آن اپیزود برای من ساده‌ترین بود، چون فقط آنچه دیده بودم تعریف کردم. اما بازخورد بسیار خوبی گرفت و خیلی‌ها بعد از آن از من سؤال‌های زیادی پرسیدند.
پدرام:
دقیقاً. به نظرم یکی از جذاب‌ترین بخش‌های کار تو همین بود که تجربه‌ی واقعی‌ات را تعریف کردی؛ اینکه چطور در ایران با اسکرام کار می‌کردید و بعد چه تفاوت‌هایی در خارج دیدی. آن مقایسه خیلی ارزشمند بود.
رامین:
بله همین‌طور است. واقعیت این است که در ایران ما به اسم اسکرام کار می‌کردیم، اما عملاً همان روش سنتی یا واترفال بود که فقط چند تکنیک اسکرام را در آن گنجانده بودیم. نتیجه این شد که «روح» واقعی اجایل در کار وجود نداشت. همیشه هم مشکل این بود که مدیریت بدبین بود و می‌گفت: «این روش احتمالاً جواب نمی‌دهد» یا «ممکن است هزینه‌ی بیشتری روی دست ما بگذارد.» در حالی که واقعیت چیز دیگری بود.
پدرام:
بله، این حرفت کاملاً درست است. البته بحث در این زمینه بسیار گسترده است و می‌توانیم ساعت‌ها درباره‌اش صحبت کنیم. اما اجازه بده یک نکته‌ی جالب دیگر بگویم برای شنوندگان «اجایل‌گپ»: طولانی‌ترین مسافتی که تاکنون برای ضبط پادکست طی کرده بودم، مربوط به گفت‌وگویی با محمد پدرم در اصفهان بود. حالا خیلی خوشحالم که ناگهان یک جهش عجیب رخ داده و مهمانم از کیلومترها دورتر با من همراه شده. رامین جان، خودت بگو الان کجایی؟
رامین:
من الان دانمارک هستم. حدود سه سال و نیم است که مهاجرت کرده‌ام و اینجا مشغول کار هستم...
تقریباً سه سال و نیم از مهاجرت من به دانمارک می‌گذرد. موفق شدم ویزای کاری بگیرم و اینجا ماندگار شوم. دانمارک کشور کوچکی است با جمعیتی حدود پنج و نیم تا شش میلیون نفر. تنها سه استان دارد که از نظر وسعت حتی به اندازه‌ی استان اصفهان هم نیستند. به همین دلیل شرایط این کشور به‌طور کلی با کشور ما بسیار متفاوت است؛ چه از نظر شلوغی و تراکم جمعیت و چه از نظر ساختار سیاسی و اجتماعی.
در همان ابتدای مهاجرت، خانواده و دوستانم حتی دقیقاً نمی‌دانستند دانمارک روی نقشه کجاست. اما به مرور با این کشور کوچک و آرام بیشتر آشنا شدیم.
یادم می‌آید در فصل اول پادکستم درباره‌ی روند اپلای و گرفتن ویزا صحبت کرده بودم، و در فصل سوم یا چهارم بیشتر به تجربیات زندگی پس از مهاجرت پرداختم؛ از چالش‌ها گرفته تا تجربه‌های کاری. جالب است که امروز وقتی به آن اپیزودها برمی‌گردم، احساس می‌کنم باز هم حرف‌های تازه‌ای برای گفتن دارم. چون نگاه یک مهاجر به کشور میزبان دائماً در حال تغییر است؛ گاهی مثبت‌تر می‌شود، گاهی منفی‌تر. برای من هم چنین بود: دوره‌هایی داشتم که بسیار مشتاق و راضی بودم و دوره‌هایی هم که نگاه منفی پیدا کردم. به هر حال، مهاجرت یک سفر درونی است و هر کس تجربه‌ی خاص خودش را دارد.
از نظر آب‌وهوا هم دانمارک شرایط خاصی دارد. اینجا بسیار متغیر است و به همین دلیل اپلیکیشن هواشناسی، پرکاربردترین برنامه‌ی موبایل برای مردم محسوب می‌شود. در ایران ما عادت داشتیم بدانیم برای هفته یا حتی ماه آینده وضعیت هوا چگونه خواهد بود، اما در دانمارک همه‌چیز لحظه‌ای تغییر می‌کند. خود من هر روز صبح که از خواب بیدار می‌شوم، اول از همه اپلیکیشن هواشناسی را چک می‌کنم تا ببینم در چه ساعتی از روز باران می‌بارد یا هوا آفتابی است.
ماجرای کرونا هم در دانمارک تجربه‌ی خاص خودش را داشت. از همان ابتدای شیوع، کشور چندین بار قرنطینه‌ی کامل را تجربه کرد. رستوران‌ها، کافه‌ها و بسیاری از کسب‌وکارها برای مدتی تعطیل شدند. اما پس از مدتی، به‌ویژه با ورود سویه‌ی اومیکرون، سیاست‌ها تغییر کرد. چون بیش از ۷۰ درصد جامعه در آن زمان یا واکسینه شده بودند یا به کرونا مبتلا شده بودند، دولت تصمیم گرفت به سمت ایمنی جمعی حرکت کند. در نتیجه تقریباً همه‌چیز باز شد، استفاده از ماسک اختیاری اعلام شد، و مردم به تدریج به زندگی عادی بازگشتند. شرکت‌ها هم ابتدا اجازه‌ی دورکاری دادند اما کم‌کم توصیه کردند که افراد دوباره به محل کار برگردند.
به بیان ساده، دانمارک در نهایت موضوع را به «سازگاری طبیعی مردم» و «قدرت سیستم درمانی» سپرد. این هم بخشی از همان تفاوت نگاه آن‌ها به مدیریت بحران است.
زمستان‌های دانمارک واقعاً تاریک هستند. میانگین دما معمولاً حول و حوش صفر درجه است و شاید خیلی غیرقابل‌تحمل نباشد، اما شدت بادها شرایط را دشوار می‌کند. هفته‌ی گذشته طوفان بسیار شدیدی رخ داد که دو روز کامل ادامه داشت و خسارت‌های زیادی بر جای گذاشت؛ از کنده شدن سقف خانه‌های قدیمی گرفته تا شکستن پنجره‌ها. در ساختمانی که من زندگی می‌کنم، با وجود عایق‌بندی مدرن و پنجره‌های چندجداره، باز هم می‌شد لرزش را احساس کرد. این تجربه واقعاً ترسناک بود.
نکته‌ی جالب اینجاست که دانمارک حدود ۳۰ درصد برق خود را از انرژی باد تأمین می‌کند و یکی از بزرگ‌ترین صادرکنندگان توربین بادی در جهان است. حتی میان دانمارک و نروژ مزارع بادی عظیمی در دل اقیانوس ایجاد کرده‌اند. به همین دلیل، پس از وزش آن طوفان سهمگین، تولید برق افزایش یافت و قبض‌های برق برای مدتی کاهش پیدا کرد. اینجا قیمت برق لحظه‌ای محاسبه می‌شود و در اپلیکیشن‌های شرکت‌های تأمین‌کننده می‌توانید نمودار دقیق قیمت‌ها را بر اساس ساعت روز مشاهده کنید.
از نظر آب هم مشکلی وجود ندارد. بر خلاف اصفهان که در سال‌های اخیر با بحران کم‌آبی مواجه بوده، در دانمارک بارش باران بسیار زیاد است. گاهی در زمستان طی یک هفته، چهار یا پنج روز بارانی پشت سر هم تجربه می‌شود. همین باران‌های مداوم به همراه روزهای کوتاه و تاریک، شرایطی افسرده‌کننده ایجاد می‌کند. بسیاری از مهاجران با این موضوع دچار مشکل می‌شوند.
خود من امسال به‌طور عجیبی راحت‌تر با این شرایط کنار آمدم. شاید به این دلیل که به مرور با آن سازگار شده‌ام. با این حال، کمبود نور خورشید آثار واقعی بر روحیه و سلامت انسان می‌گذارد. برای جبران، ابزارهای مختلفی وجود دارد؛ مثلاً چراغ‌هایی که نور مصنوعی شبیه نور خورشید تولید می‌کنند و می‌توان آن‌ها را طوری تنظیم کرد که صبح‌ها به تدریج روشن شوند و بدن به‌طور طبیعی از خواب بیدار شود. ورزش هم بسیار توصیه می‌شود؛ هرچه بیشتر ورزش کنید، وضعیت روانی‌تان بهتر خواهد شد.
این‌ها مسائلی هستند که بسیاری از متقاضیان مهاجرت کمتر به آن فکر می‌کنند. معمولاً ذهن افراد درگیر مشکلات اقتصادی است و تصور می‌کنند با مهاجرت همه‌چیز بهتر خواهد شد. اما واقعیت این است که شرایط آب‌وهوا و سبک زندگی هم می‌توانند تأثیرات عمیقی بر تجربه‌ی زندگی در کشور مقصد داشته باشند.
یکی از اتفاقات جالب برای من وقتی بود که روی میز «لارس»؛ پروداکت اونر باهوش و باسواد تیم‌مان، کتابی دیدم با عنوان Agile Testing: A Practical Guide for Testers and Agile Teams. همان لحظه متوجه شدم بسیاری از ایده‌ها و پیشنهادهایی که او در جلسات مطرح می‌کند، ریشه در منابع معتبر دارد. بعدها متوجه شدم نسخه‌ی دوم این کتاب نیز با عنوان More Agile Testing: Learning Journeys for the Whole Team منتشر شده است. همین موضوع باعث شد خودم نیز مطالعه‌ی این کتاب‌ها را آغاز کنم و حتی ویدئوهای آموزشی نویسندگان آن را پیگیری کنم.
با خواندن این منابع تازه درک کردم که چقدر در پروژه‌های قبلی زمان و انرژی زیادی به‌خاطر نبود یک رویکرد درست در تست تلف کرده بودیم. ادعای ما این بود که «چابک» کار می‌کنیم، اما فرآیند تست‌مان ناقص، مبهم و سطحی بود. در بسیاری از شرکت‌ها وقتی صحبت از تست‌نویسی می‌شود، معمولاً واکنش این است که «چرا وقت تلف کنیم؟ بهتر است تکنولوژی‌های جدید یاد بگیریم یا فریم‌ورک‌های تازه را تجربه کنیم». یا حتی بعضی توسعه‌دهندگان می‌گویند: «مگر ما تستر هستیم که کدمان را تست کنیم؟» در حالی که چنین طرز فکری خطرناک است.
مطالعه‌ی این کتاب‌ها به من نشان داد که رویکرد درست به تست، سرمایه‌گذاری روی کیفیت محصول است. نوشتن تست‌های خودکار شاید در ابتدا زمان‌بر و دشوار باشد، اما در بلندمدت از هزینه‌های روانی و زمانی جلوگیری می‌کند. تیم‌هایی که تست را جدی نمی‌گیرند، معمولاً با انباشت «بدهی فنی» (Technical Debt) و باگ‌های پی‌درپی روبه‌رو می‌شوند. نتیجه هم روشن است: تماس‌های اضطراری آخر هفته، تحویل‌های پر از خطا، و فشارهای مداوم بر تیم.
به همین دلیل تصمیم گرفتم در کانال‌ها و پادکست‌هایم بیشتر روی موضوع تست تمرکز کنم. بازخوردها متفاوت بود؛ بعضی‌ها استقبال کردند و بعضی‌ها گفتند «کمی از این فضا فاصله بگیر و برو سراغ تکنولوژی‌های روز». اما من احساس کردم خلأ بزرگی در حوزه‌ی آموزش تست وجود دارد و باید درباره‌اش محتوا تولید شود.
واقعیت این است که داشتن تکنولوژی جدید بدون تضمین کیفیت، ارزشی ایجاد نمی‌کند. حتی با تکنولوژی‌های قدیمی هم می‌توان محصولی موفق ساخت، اگر کیفیت آن تضمین شده باشد. بنابراین تست‌نویسی نباید به چشم یک کار فرعی یا «لوکس» دیده شود، بلکه یکی از ارکان اصلی توسعه‌ی نرم‌افزار باکیفیت است.
اتفاقاً در چارچوب‌های چابک هم تأکید می‌شود که تست بخشی از «تعریف انجام کار» (Definition of Done) است. بسیاری از شرکت‌ها این اصل را نادیده می‌گیرند و صرفاً به ساخت سریع یک محصول حداقلی (MVP) اکتفا می‌کنند. نتیجه این است که در همان نقطه متوقف می‌شوند و کیفیت محصولشان هیچ‌گاه به سطح پایدار نمی‌رسد.
خوشبختانه تجربه نشان داده که در بسیاری از شرکت‌های ایرانی، توسعه‌دهندگانی که استخدام می‌شوند معمولاً بیش از یک سال در شرکت باقی نمی‌مانند. این رفت‌وآمد زیاد باعث شده بسیاری از افراد با خود بگویند: «وقتی قرار نیست مدت طولانی در این شرکت بمانم، چرا باید تست بنویسم؟» در حالی که اگر توسعه‌دهنده بداند قرار است در بلندمدت روی همان محصول کار کند، احتمالاً احساس مسئولیت بیشتری نسبت به کیفیت کدی که تحویل می‌دهد خواهد داشت.
در همین زمینه، کتابی وجود دارد با عنوان Agile Testing: A Practical Guide for Testers and Agile Teams که نویسندگان آن دو بانوی باتجربه در حوزه تست هستند. این کتاب چاپ اول است، ویدیوی آموزشی کوتاه و کاربردی هم دارد و صرفاً تئوریک نیست؛ بلکه با طرح پرسش و پاسخ‌های عملی، مفاهیم را بهتر جا می‌اندازد. چاپ دوم این کتاب نیز با عنوان More Agile Testing: Learning Journeys for the Whole Team منتشر شده است. به نظر من این کتاب‌ها شاید «کتاب شماره یک» در این حوزه نباشند، اما بدون تردید از بهترین منابع مرجع محسوب می‌شوند. علاوه بر این، نویسندگان کتاب از نخستین افرادی بوده‌اند که در دوران شکل‌گیری جنبش اجایل، تلاش کردند نقش تست و کیفیت (QA) را در این چارچوب بازتعریف کنند.
ما در تیم خودمان بسیاری از پرکتیس‌های مطرح‌شده در این کتاب را اجرا کردیم و از نتایج آن راضی هستیم. بارها پیش آمده که همین شیوه‌ها ما را از بروز باگ‌های حیاتی یا مشکلاتی که می‌توانست کل محصول را مختل کند، نجات داده است.
پیش از آنکه وارد جزئیات کتاب شوم، بد نیست به پرسشی که مدتی است ذهنم را مشغول کرده اشاره کنم: چرا توسعه‌دهندگان بک‌اند این‌قدر به کتاب علاقه‌مندند؟ پاسخ من شاید علمی نباشد، اما بر اساس تجربه شخصی می‌توانم بگویم یکی از دلایلش این است که بسیاری از مفاهیم بک‌اند ذاتاً پیچیده و غیرقابل نمایش بصری هستند. دنیای بک‌اند شبیه یک شهربازی پر از مفاهیم و ابزارهای متنوع است که مدام در حال تغییرند و پیگیری همه آن‌ها به‌سادگی امکان‌پذیر نیست.
برای من، کتاب خواندن در این حوزه جذابیت خاصی دارد. وقتی کتابی خوب نوشته شده باشد، شبیه خواندن یک داستان است؛ مسئله را باز می‌کند، بستر و کانتکس را توضیح می‌دهد، سپس مسیر رسیدن به راه‌حل را مرحله‌به‌مرحله پیش می‌برد. این نوع روایت برای من بسیار آموزنده‌تر و ماندگارتر از مقالات پراکنده یا آموزش‌های ویدئویی کوتاه است.
البته این به آن معنا نیست که هر چیزی را باید از طریق کتاب یاد گرفت. برای یک فریم‌ورک یا کتابخانه ساده، مطالعه‌ی مستندات رسمی کافی است. اما برای موضوعات عمیق‌تر یا مفهومی‌تر، کتاب همچنان بهترین مرجع است.
این علاقه به کتاب‌خوانی باعث شد برخی کتاب‌های فنی، مثل How to Write Maintainable Code، تأثیر عمیقی روی من بگذارد. آن کتاب‌ها نه‌تنها محتوای کاربردی داشتند، بلکه توانستند مفاهیم پیچیده را به زبانی ساده و روشن منتقل کنند.
تجربه‌ی شخصی من در زمینه‌ی تولید محتوا بر پایه‌ی کتاب این بوده است که همیشه تلاش کرده‌ام مطالب را از فیلتر خودم عبور بدهم؛ به اصطلاح به آن «رنگ شخصی» بدهم. با این حال، هنوز احساس رضایت کامل ندارم. وقتی بعداً محتوای تولیدشده را دوباره گوش می‌دهم، گاهی به این نتیجه می‌رسم که بهتر بود بعضی بخش‌ها کوتاه‌تر گفته می‌شد یا برعکس، در برخی قسمت‌ها باید مکث بیشتری می‌کردم.
به همین دلیل قصد ندارم کتاب Agile Testing را صرفاً به شیوه‌ی «خلاصه‌نویسی کامل» بازگو کنم. فضای گفت‌وگوی ما بیشتر مناسب مرور نکات کلیدی است تا اینکه بخواهیم کل کتاب را بازخوانی کنیم. به همین خاطر بهتر است همانند یک شهربازی به آن نگاه کنیم: چرخی بزنیم، چند بخش مهم را انتخاب کنیم، سوار شویم و از آن لذت ببریم.
این کتاب چند بخش اصلی دارد. در آغاز، از مایندست و فرهنگ (Mindset & Culture) شروع می‌کند؛ اینکه وقتی می‌گوییم «تست در محیط اجایل»، دقیقاً چه تفاوتی با شیوه‌های سنتی دارد. سپس به موضوعاتی مانند پلنینگ (Planning)، بیزینس ولیوها (Business Value)، استراتژی‌های تست در اجایل، و در نهایت تست اتومیشن و تکنیک‌های مرتبط می‌پردازد. کتاب پیچیدگی بالایی ندارد، اما نسبتاً مفصل است و به‌ویژه برای تیم‌هایی که تازه وارد فضای اجایل می‌شوند و می‌خواهند تست را همگام با آن پیاده‌سازی کنند، بسیار مفید خواهد بود.
کتاب در همان ابتدا تأکید می‌کند که نقش تستر در اجایل دیگر مانند گذشته نیست. در مدل‌های سنتی (واترفال) معمول بود که تستر بگوید: «وظیفه‌ی من یافتن باگ است» یا «چک کردن انطباق محصول با مستندات». اما در اجایل، مایندست باید متفاوت باشد. تستر (و در واقع کل تیم) باید به جلوگیری از خطا از همان ابتدای کار فکر کند، حتی پیش از آغاز کدنویسی.
به همین دلیل، کتاب به جای واژه‌ی Role بیشتر از Discipline استفاده می‌کند. در اجایل، تست فقط کار یک فرد یا یک دپارتمان نیست؛ بلکه بخشی از مسئولیت همه‌ی اعضای تیم است. در اسکرام، همه‌ی این افراد ذیل واژه‌ی «Developer» تعریف می‌شوند. این «Developer» صرفاً به معنای برنامه‌نویس نیست، بلکه شامل هر فردی است که در خلق محصول پیچیده مشارکت دارد: از کدنویس گرفته تا تستر.
این نکته مهم است، چون در بسیاری از تیم‌های قدیمی، مدیران سعی می‌کردند دپارتمان جداگانه‌ای برای تست ایجاد کنند. در حالی‌که در اجایل، تست بخشی از جریان کار تیمی است، نه فعالیتی مجزا. این مایندست هم برای تسترها و هم برای برنامه‌نویس‌ها اهمیت دارد. برنامه‌نویس نباید صرفاً کد بنویسد و آن را «به دیوار پرت کند» تا تستر عیب‌ها را پیدا کند. بلکه باید از همان ابتدا به این فکر کند که چگونه می‌تواند کدی بنویسد که تست‌پذیر باشد و احتمال بروز خطا در آن کمتر شود.
اینجا کتاب به TDD (Test-Driven Development) اشاره می‌کند؛ روشی که ابتدا تست‌ها نوشته می‌شوند و سپس برای گذراندن آن تست‌ها کد توسعه می‌یابد. هدف این است که کد از همان ابتدا بر پایه‌ی سناریوهای واقعی و خطاهای احتمالی شکل بگیرد.
در ادامه، کتاب به موضوع Acceptance Testing هم می‌پردازد. یکی از ایده‌های اصلی این است که تست باید «از همان ابتدا» شروع شود؛ یعنی حتی در مرحله‌ی تعریف یوزر استوری‌ها. به این ترتیب، می‌توان یوزر استوری‌ها را به سناریوها و مثال‌های مشخص نگاشت و در عمل از روش‌هایی مثل BDD (Behavior-Driven Development) بهره گرفت. این روش کمک می‌کند همه‌ی اعضای تیم—از بیزینس تا توسعه‌دهنده—درک مشترکی از رفتار مورد انتظار سیستم داشته باشند.
نکته‌ی جالب دیگری که کتاب مطرح می‌کند این است که تیم‌ها باید ساختاری T-Shaped داشته باشند: یعنی هر فرد یک «عمق تخصصی» در یک حوزه‌ی خاص (مثلاً جاوا یا تست اتومیشن) داشته باشد و در عین حال سطحی از دانش عمومی در حوزه‌های دیگر هم بداند تا بتواند با سایر اعضا همکاری کند.
برای نمونه، یک برنامه‌نویس بک‌اند ممکن است در زمینه‌ی پایگاه داده تخصص عمیقی داشته باشد و دانش فنی او در آن حوزه بسیار قوی باشد. با این حال، او باید در سایر حوزه‌ها نیز سطحی از آگاهی داشته باشد؛ برای مثال بداند که تست‌های دستی (Manual Testing) چگونه انجام می‌شوند، با تست‌های عملکردی (Functional Testing) آشنا باشد، بتواند تست‌های خودکار (Automation Tests) بنویسد و حتی کدی را که توسعه داده است از نظر کارایی (Performance) و امنیت (Security) بررسی کند.
متأسفانه، برخی برنامه‌نویسان در این زمینه جبهه می‌گیرند و می‌گویند: «این وظیفه‌ی من نیست» یا «برای این کار درس نخوانده‌ام». چنین نگرشی دیگر پذیرفتنی نیست. در تیم‌های امروزی، همه‌ی اعضا مسئول کیفیت محصول هستند و تقسیم‌بندی سنتی بر اساس نقش‌ها (Role) دیگر کارایی ندارد. اگر تیمی ساختار T-Shape را به‌طور کامل نداشته باشد، باید فرهنگ یادگیری مستمر (Learning Culture) در سازمان تقویت شود؛ خواه از طریق آموزش‌های داخلی، خواه از طریق سرمایه‌گذاری شرکت بر توسعه‌ی مهارت‌های افراد. چنین سرمایه‌گذاری‌ای در حوزه‌ی کیفیت، در بلندمدت بسیار سودآور است: هم موجب افزایش رضایت مشتری می‌شود و هم توسعه‌دهندگان می‌توانند کدها را راحت‌تر نگهداری و توسعه دهند.
کتاب همچنین به مهارت‌های نرم (Soft Skills) اشاره می‌کند. کیفیت محصول تنها با مهارت‌های فنی تضمین نمی‌شود، بلکه ارتباطات مؤثر (Communication) نیز نقش مهمی دارد. برای مثال، در یک تیم ممکن است تستر از پیش‌زمینه‌ی برنامه‌نویسی برخوردار نباشد و در نتیجه توضیحات فنی پیچیده برای او قابل درک نباشد. در چنین شرایطی، اگر برنامه‌نویس صرفاً به او بگوید «به سندباکس برو، این API را فراخوانی کن و با مطالعه‌ی مستندات مشکل را حل کن»، این ارتباط به شکست می‌انجامد. به‌جای آن، گاهی لازم است یک نشست کوتاه و غیررسمی برگزار شود تا همه‌ی اعضای تیم درک مشترکی از نحوه‌ی تست پیدا کنند.
از سوی دیگر، تسترها نیز ممکن است به دلیل احساس ضعف نسبت به توسعه‌دهندگان، واکنش‌های تدافعی نشان دهند. برای نمونه، اگر باگی بیابند، به‌جای طرح مؤدبانه‌ی موضوع، ممکن است آن را به‌صورت تلافی‌جویانه و علنی در حضور همه اعلام کنند؛ به گونه‌ای که گویی از کشف ایراد در کد هم‌تیمی خود خوشحال‌اند. این نوع ارتباط به جای تقویت روحیه‌ی تیمی، به ایجاد تنش منجر می‌شود.
بنابراین، نحوه‌ی انتقال خبرهای ناخوشایند نیز اهمیت دارد. اعضای تیم باید سیاست و مهارت لازم برای گزارش مشکلات را بیاموزند. این مهارت تنها به تعامل بین برنامه‌نویسان و تسترها محدود نمی‌شود، بلکه شامل همکاری با سایر تیم‌ها، ذی‌نفعان و حتی مشتریان نیز هست. به همین دلیل، علاوه بر مهارت گفتاری، مهارت شنیداری (Active Listening) نیز اهمیت دارد؛ چرا که گاهی کشف یک مشکل توسط فردی غیرتوسعه‌دهنده یا حتی از طریق مشاهده‌ی مستقیم (Visual Check) امکان‌پذیر می‌شود. در این شرایط، داشتن گوش شنوا برای پذیرش بازخورد، شرط اساسی موفقیت تیم است.
برای نمونه، یکی از ارزش‌های پنج‌گانه در اسکرام Openness است. وقتی فرد در برابر انتقاد و نظر دیگران «اوپن» یا گشوده باشد، عملاً راه ورود داده‌های بیشتر به سمت خود را باز می‌کند. این داده‌ها می‌توانند دیدگاه‌های تازه‌ای برای تحلیل، نتیجه‌گیری و تصمیم‌گیری فراهم کنند. در مقابل، اگر فرد در برابر نظرات بسته باشد، گویی دیواری آجری در برابر خود می‌سازد و مانع ورود اطلاعات ارزشمند می‌شود؛ در نهایت، این رویکرد به زیان او تمام خواهد شد.
در همین راستا، وقتی فردی با مهارت تست وارد تیم می‌شود (آن‌بوردینگ)، ضروری است از همان ابتدا مجموعه‌ای از اطلاعات کلیدی را در اختیار او قرار دهیم:
توضیح معماری کلی سیستم،
آشنایی با مفاهیم اصلی توسعه در تیم،
تشریح قواعد بیزینسی و حتی قوانین کشوری مرتبط با محصول.
این کار موجب می‌شود ارتباطات (Communication) در تیم روان‌تر و مؤثرتر شکل گیرد.
کتاب Agile Testing بر این نکته تأکید دارد که تست در اجایل یک فعالیت (Activity) است، نه یک فاز جداگانه. به عبارت دیگر، تست بخشی از جریان کار تیم است و می‌تواند در قالب تعریف انجام کار (Definition of Done) لحاظ شود. به طور نمونه، وقتی یک تسک تعریف می‌شود، تکمیل آن می‌تواند شامل:
کدنویسی،
بازبینی کد (Code Review)،
تست‌های مختلف (تست دستی، تست خودکار، تست عملکرد و غیره).
در این حالت، تا زمانی که تست‌های مشخص‌شده انجام نشده باشند، آیتم مورد نظر «تمام‌شده» محسوب نمی‌شود. این نکته باز هم نشان می‌دهد که تست صرفاً وظیفه‌ی یک فرد خاص (تستر) نیست، بلکه مسئولیتی تیمی است که تمام توسعه‌دهندگان نیز در آن نقش دارند.
اشتباهی که گاه رخ می‌دهد این است که واژه‌ی «Agile» را صرفاً به معنای «سریع بودن» می‌فهمند. حال آنکه اجایل به معنای ایجاد یک روند پایدار و تکرارشونده در تحویل ارزش است. به بیان دیگر، اجایل بودن یعنی یادگیری مداوم، انطباق سریع و یافتن راه‌هایی برای کاهش اتلاف.
برای مثال، در تجربه‌ای عملی، تیم متوجه شد که نرم‌افزار در بازه‌های زمانی مشخصی به‌طور ناگهانی ری‌استارت می‌شود. این مشکل باعث می‌شد یک ساعت کار توسعه از دست برود. تیم با یادگیری سریع، تصمیم گرفت هر ۱۰ تا ۱۵ دقیقه یک‌بار خروجی کار را ذخیره کند. همین تغییر ساده موجب شد زیان ناشی از ری‌استارت‌ها به حداقل برسد. این یعنی «چابک شدن»؛ نه با دویدن سریع‌تر، بلکه با یادگیری سریع‌تر و اصلاح فرایندها.
همین نگاه است که باعث می‌شود تیم‌ها حتی در جلسات بازنگری (Retrospective) دوباره به تعریف انجام کار (DoD) خود بازگردند و آن را اصلاح کنند. ممکن است پس از چند اسپرینت به این نتیجه برسند که یک بند از DoD بیش از حد دست‌وپاگیر است یا برعکس، بخشی از کیفیت محصول را پوشش نمی‌دهد. در نتیجه، تیم با شفافیت و اشتیاق (Openness) آن را تغییر می‌دهد تا جریان کار روان‌تر و مؤثرتر شود.
وقتی یک تیم پنج نفره از توسعه‌دهندگان داریم، این پرسش پیش می‌آید که آیا لازم است یک تستر (QA) هم به تیم اضافه شود یا نه. رویکرد پیشنهادی کتاب Agile Testing این است که تست صرفاً نقش یک فرد خاص نیست، بلکه یک فعالیت تیمی است. با این حال، داشتن یک تستر متخصص می‌تواند ارزش‌آفرین باشد، به‌ویژه در بخش‌هایی که نیازمند دقت بیشتری است (مانند تست‌های ریسک‌پذیر یا حیاتی).
از سوی دیگر، تیم می‌تواند به‌تدریج مهارت‌های خود را گسترش دهد. برای مثال، همه‌ی اعضا یاد بگیرند تست عملکرد (Performance Testing) یا سایر انواع تست را نیز انجام دهند. این یادگیری می‌تواند به کمک دوره‌های آموزشی درون‌سازمانی یا حمایت شرکت صورت بگیرد. اینجاست که ویژگی اصلی اجایل و اسکرام معنا پیدا می‌کند: پویایی و قابلیت انطباق.
نکته‌ی ظریف این است که اسکرام و اجایل عمداً «ناقص» طراحی شده‌اند. آن‌ها خود را به‌صورت یک ساختار مینیمال ارائه می‌دهند تا فضای کافی برای تیم باقی بماند که متناسب با شرایط خود، سازوکارها و شیوه‌های مکمل را اضافه کند. به تعبیر زیبا می‌توان گفت: اجایل مانند مایعی است که در میان ستون‌های سخت‌افزاری و فرهنگی سازمان جریان می‌یابد و شکل آن را می‌گیرد.
این نگرش متفاوت است از اینکه بگوییم «ما یک چارچوب کامل داریم که حالا می‌خواهیم آن را دستکاری و کاستومایز کنیم.» در حقیقت، خودِ اسکرام و اجایل بر این اساس بنا شده‌اند که تیم‌ها با یادگیری و تجربه، آن را تکمیل کنند. برای همین هم راهنماها و فریم‌ورک‌ها کوتاه و مینیمال نوشته شده‌اند (مثلاً راهنمای اسکرام تنها ۱۹ صفحه است)، چون هدف این نیست که پاسخ همه‌چیز داده شود؛ بلکه قرار است اصول بنیادین مشخص شوند و باقی‌اش بر دوش تیم گذاشته شود.
در همین زمینه، کتاب به یک شاخص رایج اشاره می‌کند: نسبت تسترها به توسعه‌دهندگان. در بسیاری از تیم‌های چابک، این نسبت معمولاً سه به یک یا چهار به یک در نظر گرفته می‌شود. البته این یک قاعده‌ی قطعی نیست و بسته به ماهیت محصول و میزان پیچیدگی آن تغییر می‌کند. در تیم‌های کوچک‌تر، به‌ویژه اگر اعضا مهارت‌های T-شکل داشته باشند (یعنی هم در یک حوزه عمق تخصصی داشته باشند و هم در سایر حوزه‌ها در سطح عمومی مهارت داشته باشند)، ممکن است حتی بدون تستر اختصاصی هم بتوان کیفیت مطلوب را حفظ کرد.
اگر تمام کارهای تست دستی (Manual Testing) و طراحی تست‌ها را فقط به یک نفر بسپاریم، به‌ویژه وقتی حجم تیم بزرگ می‌شود، آن فرد عملاً زیر بار کارها از پا درمی‌آید. یکی از نویسندگان کتاب Agile Testing مثال جالبی آورده است: در تیمی که ۱۲ توسعه‌دهنده داشت، او تنها فرد رسمی مسئول تست بود. در چنین شرایطی دیگر نمی‌توانست خودش همه‌ی تست‌ها را اجرا کند. بنابراین نقش خود را به‌عنوان «مشاور تست» تعریف کرد: طراحی سناریوها و راهنمایی تیم در اجرای آن‌ها، اما بخش زیادی از انجام تست‌ها را به عهده‌ی توسعه‌دهندگان گذاشت.
این همان نقطه‌ای است که اجیلیتی واقعی معنا پیدا می‌کند: تیم‌ها می‌آموزند که بسته به شرایط، ساختار و فرآیند مناسب خود را بسازند. هیچ نسخه‌ی از پیش‌نوشته‌شده‌ای برای همه وجود ندارد.
نکته‌ی مهم دیگر این است که در ابتدا، چارچوب‌هایی مثل اجایل و اسکرام عمدتاً برای صنعت نرم‌افزار شکل گرفتند؛ زیرا این حوزه پیچیدگی و سرعت تغییر بالایی داشت. اما امروز مرزهای فناوری اطلاعات با صنایع دیگر ترکیب شده و آن‌ها هم به همان میزان با تغییرات سریع روبه‌رو هستند. بنابراین، تفکر اجایل به‌تدریج به حوزه‌های غیرنرم‌افزاری نیز وارد شده است و حتی به سمت مفاهیمی مانند Agile Government حرکت کرده است. این ایده به‌ویژه پس از تجربه‌ی بحران کرونا جدی‌تر شد: اینکه دولت‌ها چگونه می‌توانند در مواجهه با بحران‌ها سازگارتر و پاسخگوتر باشند.
برای مثال، کشوری مانند استرالیا با اولین نشانه‌های کرونا مرزهای خود را به‌طور کامل بست و ارتباط با جهان را قطع کرد. در نتیجه، شیوع بیماری در آن کشور بسیار محدود شد. در مقابل، کشورهایی مثل ایران بارها موج‌های متعدد و سنگین کرونا را تجربه کردند. این تفاوت نشان می‌دهد که «الگوی واکنش» و میزان چابکی در سطح حکمرانی می‌تواند نتایج کاملاً متفاوتی ایجاد کند.
کتاب همچنین هشدار می‌دهد که نباید تمرکز اصلی را صرفاً بر سرعت قرار داد. اگر تنها هدف تیم، «تحویل سریع» باشد، اغلب به بدهی فنی (Technical Debt) منجر می‌شود. بدهی فنی درست مانند گرفتن وامی است که هر چه دیرتر بازپرداخت شود، بهره‌ی بیشتری بر آن افزوده می‌شود. در نرم‌افزار نیز، هر چه دیرتر این بدهی‌ها برطرف شوند، هزینه‌ی اصلاح و نگهداری بیشتر می‌شود. در نهایت، برخی کدهای قدیمی به‌قدری پیچیده و غیرقابل تغییر می‌شوند که تیم حتی جرات دست زدن به آن‌ها را ندارد.
بنابراین سرعت بالا ممکن است در کوتاه‌مدت خروجی دهد، اما در بلندمدت کیفیت تیم و محصول را به‌شدت تضعیف می‌کند. تعادل بین سرعت، کیفیت، و مدیریت بدهی فنی، کلید پایداری در کار تیمی است.
واقعاً درست نیست که ما دوباره محصول اصلی را بر پایه‌ی یک نسخه‌ی حداقلی (MVP) ادامه بدهیم. چنین کاری بی‌کیفیتی را در پی دارد و اصلاً پذیرفتنی نیست. در مقابل، اگر تمرکزمان را بر کیفیت بگذاریم، طبیعتاً لازم است ابتدا چیزهای جدیدی یاد بگیریم و مسیر دشوارتری طی کنیم. اما در نهایت پاداش آن، کدی پایدارتر و محصولی با ارزش‌تر است.
نمونه‌ی روشن این موضوع را می‌توان در رویکرد توسعه‌ی آزمون‌محور (TDD) دید. در این روش ابتدا تست نوشته می‌شود و سپس کد متناسب با آن توسعه پیدا می‌کند. شاید در نگاه اول فرآیندی کند و سخت به نظر برسد، اما در بلندمدت بسیار پاداش‌دهنده است: چرا که یافتن باگ‌ها ساده‌تر می‌شود، کد قابلیت جست‌وجو و نگهداری بالاتری پیدا می‌کند و فرایند اشکال‌زدایی زمان بسیار کمتری می‌گیرد. این همان جایی است که شعار «Go Slow to Go Fast» معنا پیدا می‌کند؛ یعنی آهسته و اصولی شروع کن تا بتوانی در ادامه سریع‌تر و مؤثرتر حرکت کنی.
این مسیر بدون حمایت مدیریتی امکان‌پذیر نیست. اگر مدیران ذهنیت درستی نسبت به کیفیت نداشته باشند و صرفاً سرعت را مطالبه کنند، تیم تحت فشار قرار می‌گیرد و محصول به سمت فرسایش می‌رود. در مقابل، وقتی کیفیت ارزش اصلی باشد، باید در برابر باگ‌ها نیز سیاست صفر تحمل (Zero Tolerance) داشت. باگ‌ها نباید در بکلاگ باقی بمانند و انباشته شوند؛ بلکه باید فوراً شناسایی، اولویت‌بندی و رفع شوند. در غیر این صورت، به ریشه‌ی مشکلات بزرگ‌تری تبدیل خواهند شد.
در بحث بدهی فنی (Technical Debt) هم وضعیت مشابهی وجود دارد. اگر تیم صرفاً با رویکرد سرعتی پیش برود و کیفیت را فدا کند، بدهی فنی به‌تدریج انباشته می‌شود و پروژه را به نقطه‌ی بحرانی می‌رساند. این همان چیزی است که برخی متخصصان به‌طور تجربی می‌گویند: «بدون پرداخت بدهی فنی، یک نرم‌افزار بیش از ۹ ماه دوام نخواهد داشت.» هرچند این عدد دقیق و علمی نیست، اما پیام روشنی دارد: دیر یا زود، هزینه‌های اصلاح و نگهداری به‌قدری سنگین می‌شود که تیم از پا درمی‌آید.
نمونه‌ی ملموس این موضوع کدهای قدیمی و Legacy Code است. تغییر و نگهداری چنین کدهایی به‌قدری پرهزینه و پرخطر است که تیم‌ها از دست زدن به آن‌ها هراس دارند. کوچک‌ترین تغییر ممکن است چندین خطای پیش‌بینی‌نشده ایجاد کند. راهکار این مشکل تعریف تسک‌های اکتشافی (Investigation Tasks) و اسپایک‌ها (Spikes)، افزودن تدریجی تست‌ها و سرمایه‌گذاری مدیریتی بر روی بازنویسی یا بهبود بخش‌های کلیدی است. هرچند پرهزینه است، اما پاداش آن محصولی پایدار و قابل توسعه خواهد بود.
در ادامه، کتاب Agile Testing بر اهمیت برنامه‌ریزی مشترک (Test Planning) تأکید می‌کند. طراحی تست نباید فقط بر دوش تستر باشد. بهترین شیوه این است که سه نقش کلیدی—تستر، توسعه‌دهنده، و مالک محصول—به‌عنوان Three Amigos کنار هم بنشینند. آن‌ها با همکاری یکدیگر یوزر استوری‌ها را بررسی می‌کنند، قوانین کسب‌وکار (Business Rules) را استخراج می‌کنند و برای هر سناریو مثال‌ها و تست‌کیس‌های مشخص می‌سازند.
برای نمونه، در طراحی سیستم رزرو قطار:
هر مسافر در صورت وجود ظرفیت می‌تواند رزرو انجام دهد.
خانواده‌ها می‌توانند یک کوپه‌ی کامل را رزرو کنند.
اگر بیش از ۸۰٪ صندلی‌ها خالی بماند، امکان لغو سرویس وجود دارد.
بر پایه‌ی این قوانین، تست‌کیس‌ها و سناریوهای گوناگون طراحی می‌شوند و تیم مرز مشخصی برای دامنه‌ی فیچر (Scope) تعیین می‌کند. بدین ترتیب از گسترش بی‌پایان محدوده (Scope Creep) جلوگیری می‌شود و ارزش واقعی هر فیچر در بازبینی با مشتری سنجیده خواهد شد.
در نهایت، یکی از مهم‌ترین دستاوردها، پیوند همین فرایند با توسعه‌ی رفتارمحور (BDD) است. زمانی که تست‌ها به شکل Given-When-Then نوشته شوند، توسعه‌دهندگان می‌توانند به‌طور مستقیم از آن‌ها برای پیاده‌سازی و نوشتن تست‌های خودکار استفاده کنند.
این مسیر—از تغییر ذهنیت درباره‌ی تست گرفته تا همکاری نزدیک در طراحی، و نهایتاً تمرکز بر کیفیت—همان چیزی است که به‌تدریج تیم‌ها را از دام سرعت‌زدگی، بدهی فنی و محصول بی‌کیفیت رها می‌کند و به سمت پایداری و اجیلیتی واقعی می‌برد.
