Mob Testing یا چگونه با هم مهربان باشیم

تاریخ انتشار نسخه اصلی نوامبر 20, 2016
نمیدانم شما هم مثل من تنها و با هدفونی در گوش کار میکنید یا اینکه دوست دارید با همکارتان با هم کد بزنید، ولی در هر صورت با گسترش و محبوب شدن شیوه های Agile در شرکتهای نرم افزاری، تیم ها هر چه بیشتر به سمت کار گروهی متمایل میشوند. Pair programming یکی از همین روشهای رایج با هم کار کردن است که شاید نیاز چندانی به توضیح نداشته باشد. دو برنامه نویس با هم پشت یک کامپیوتر مینشینند، فکرها را روی هم میگذارند و سعی میکنند باهم مسئله ای را حل کنند. ولی چند سالی است مفهوم جدیدی در Agile مطرح شده است بنام Mob programming و در ادامه آن Mob testing. برای فهم بهتر این دو بنظرم لازم است ابتدا دو مفهوم دیگه توضیح داده شود:

روش Strong-style pairing: این روش اولین بار سال 2014 توسط Lewellyn Falco مطرح شد. Lewellyn که برنامه نویس و مربی Agile است با مشاهده Pair programming مشکلاتی در آن دید. مثل اینکه کسی که مشاهده گر است نمیداند کنترل کننده به چه چیزی فکر میکند یا فردی که با تجربه تر است مدام کنترل دست اش هست و فرد کم تجربه تقریباً از بازی بیرون. یا اینکه برعکس بعضی وقتها سر کنترل کیبورد مشاجره پیش میاد. Lewellyn این مشکل ارتباطی را به این شکل حل کرد:

هر فکری که از ذهن یک نفر بیرون میاد باید از طریق فردی دیگری به کامپیوتر منتقل شود

در این روش یک نفر اصطلاحاً نقشه خوان (navigator) میشود و به راننده (driver) که پشت کامپیوتر نشسته، میگوید که چکار کند. این کار تا مدت زمانی مشخص (حدود 15 دقیقه) ادامه دارد تا اینکه جاها عوض شود. با اینکار هر دو نفر به یک مقدار در برنامه نویسی شریک میشوند، فرد کم تجربه فرصت آموختن به صورت عملی پیدا میکند و فرد با تجربه نیز فرصتی دارد تا کار را با دید متفاوت نگاه کند.

روش Mob: خود من اولین بار این واژه را در عنوان ویدئوهایی دیدم که در آنها افرادی با هم در یک مکان عمومی یک دفعه شروع میکنند به رقصیدن یا انجام دادن کارهای جالب دیگر. بقیه مردم هم میایستند و لذت میبرند. این واژه هم در دنیای نرم افزار به همین معنی است:

افرادی در یک زمان و مکان مشخص، یک کار مشخص را با همدیگر از طریق یک کامپیوتر انجام دهند.

در Mob programming، اعضای یک تیم برنامه نویسی (و در صورت وجود، tester با توانایی کد نویسی) در یک اتاق مینشینند و از طریق Strong-style pairing بر روی یک مسئله کار میکنند. به این صورت که driver پشت کامپیوتر نشسته و دستورات در بدون دخالت اجرا میکند. نفر دیگر در نقش نقشه خوان دستورات را میدهد و سایر اعضای تیم نظاره گر هستند، تا آنکه بعد از مدتی مشخص جاها عوض شود. قبل از عوض شدن جاها، در صورت لزوم افراد در مورد دستورات و کارهای انجام شده باهم گفتگو میکنند. تجربه شخصی من از مشاهده و انجام این شیوه با برنامه نویسان این است که 1) افراد تازه وارد به گروه فرصتی پیدا میکنند که هم با خلق و خو و نظرات بقیه آشنا شوند و هم کار را سریعتر یاد بگیرند. 2)علاوه بر آن این شیوه در ابتدای حل یک مسئله بسیار کمک میکند. بعد از آنکه راه حل پیدا شد. افراد با تقسیم کار، به طور جداگانه و با سرعت بیشتر پروژه را پیش خواهند برد.

و اما Mob testing. با توضحات بالا تعریف این شیوه هم تفریباً مشخص است. اعضای یک تیم با همدیگر و به شیوه Strong-style pairing قسمتی از نرم افزار را تست کنند. ولی چند نکته در اینجا مهم است:

• نوع تست. بنظر من این شیوه برای انجام Exploratory testing مفید است. در مورد این شیوه در آینده بیشتر توضیح میدهم ولی خلاصه آن این است که تست به صورت دستی و black box روی قسمتی از نرم افزار به منظور شبیه سازی رفتار کاربر نهایی انجام میشود. بر خلاف تست های معمول که برنامه ریزی آن به صورت مفصل انجام و مستند میشود، در اینجا برنامه ریزی سریع و تمرکز بر روی اجرای تست و یادداشت بازخوردهاست. البته که mob testing میتواند به منظور نوشتن کد test (مثلا Selenium) و نوشتن unit تست هم باشد ولی من به شخصه به اینها عنوان mob programming میدهم.
• لازم نیست افرادی که در جلسه تست شرکت میکنند اعضای یک گروه باشند. تست Exploratory به شیوه mob این امکان را میدهد که افراد از سایر تیمها و حتی سایر بخشها در آن شرکت کنند تا بیشتر با نرم افزار آشنا شوند.
• مدت زمان جلسات نباید از حدود یک ساعت بیشتر شود.
• بهتر است جلسه در اتاق جدا (برای عدم ایجاد مزاحت برای سایر افراد) و با مانیتوری بزرگ انجام شد.
• مهم است که مشکلات پیدا شده در جریان تست یادداشت شوند. برای همین بهتر است یک tester در جلسه شرکت داشته باشد تا بتواند موارد پیدا شده را جمع آوری کند و بعد از جلسه، در صورتی که این موارد از قبل در سیستم Bug tracking ثبت نشده باشد، با مشورت مدیر نرمافزار آنها را اضافه کند.

این شیوه هم مثل سایر شیوه ها مدت زمانی لازم دارد که در تیمهای نرم افزاری جا بیافتد و البته جا افتاده آن وابسته به میزان فشار کار و روحیه افراد دارد. از نظر بعضی مدیران این شیوه میتواند اتلاف وقت تلقی شود اما مسلما برای حل مسائل پیچیده و شکل گیری کار گروهی میان اعضا بسیار مفید است.