خلاصه: علاقه زیادی در میان سازمانها در تبدیل به یک سازمان Agile در همه شئون وجود دارد. با این حال، معمولا در بهترین حالت تمرکز بر توسعه چابک است، و این یعنی غالبا برنامه و ذهنیت مشخصی برای تست چابک وجود ندارد. اگر مسئولیت هدایت تیم تست خود را بر عهده دارید، اجازه ندهید موضوع تست چابک توسط آنها به حاشیه برود. در اینجا چگونگی ایجاد تسترهای چابک به عنوان بخشی از این تحول Agile را، به صورت گام به گام ارائه کردهایم.
بیایید به وضعیت عمومی سازمانی که به یک سازمان چابک تبدیل میشود، اما تست چابک را پشت سر انداخته و رها میکند نگاهی بیندازیم.
فرض کنید شما سالها به عنوان مدیر تست نرم افزار مشغول به کار بودهاید، و برای خود شهرتی حرفه ای کسب کردهاید، اما اکنون در شرکتی استخدام شدهاید که به تازگی چابک شده است. شما مثل همیشه در تیم تست کمبود نیرو دارید، آنچنانکه دو یا سه تستر با تعداد زیادی توسعهدهنده در یک تیم کار میکنند.
وقتی نوبت به مستندات تست میرسد، شما و تیمتان چیزهایی در انبار اسناد دارید، اما مدتیست که هیچ به روزرسانی جدیدی روی Test Plan قدیمی رخ نداده است. در مجموع، اسناد تست شما تمرکزی بر فعالیتهای روزانه تست ندارند.
تسترهای شما مشتاق تحویل هستند. آنها از اینکه به عنوان گلوگاه و تنگنای تحویل نسخه در نظر گرفته شوند متنفر هستند. اما همه آنها در مورد درک نیازمندیها، تعریف تحویل دادنیهای تست، یا شیوه تعامل اعضای تیم، با هم متفق القول نیستند. آنچه که باید تحویل داده شود اغلب با عجله در پایان کار رخ میدهد.
تیمها با Iterationهای دو هفتهای کار میکنند، و به تسترها مدام گوشزد میشود که صبر کنید تا چیزی برای تست تولید شود. آنها این نرمافزار را در اواخر Iteration دریافت میکنند، و طبعا نمیتوانند در پایان چرخه تولید، تست خود را به پایان برسانند، بنابراین اضافه کاری ثابت در کار آنها یک موضوع معمول است. تسترها تنها مسئول نواقص، روی امکانات قابل بهرهبرداری(اصطلاحا Go Live) هستند. در جلسه بازبینی، یک عبارت دائمی استفاده میشود: ” کار انجام شد، اما تستهای بیشتری لازم است”.
به نظر شما هم چنین چیزی شرایط مناسبی نیست. برای بهبود اوضاع چه کاری میتوانید انجام دهید؟
قبل از همه چیز، شما باید انتظار خود را با توجه به جایگاهتان تغییر دهید. از این به بعد، شما فقط مجری متدهای تست نیستید. شما هنوز هم این کار را انجام خواهید داد، اما تمرکز شما به سمت یک رویکرد چابک منتقل خواهد شد. کیفیت نباید فقط در مرحله آخر بررسی شود، بلکه باید از مراحل اول در محصول تعبیه شود.
و به جای اینکه به عنوان محافظ تیم تست عمل کنید، باید به آنها اجازه دهید، خودشان را هدایت کنند. با پیشرفت تسترها، باید بتوانید آنها را رها کنید و اعلام حضورها را به یک جلسهی دو بار در هفته یا حتی ماهانه کاهش دهید. تمرکز شما باید کار با ذینفعان اصلی در طول زنجیره ارزش باشد.
شما حداقل دو لایه مسئولیت دارید:
- بر تغییر ذهنیت و توانایی تسترهای خود تمرکز کنید و برای اینکه یک عضو توانمند در تیم Agile باشند، آنها را توانمند کنید.
- ذهنیت کیفیت را به ذینفعان القا کنید
تغییر ذهنیت
بیایید ابتدا بر روی تسترها تمرکز کنیم. آنها در سطوح مختلف توسط اعضای تیم خود پذیرفته میشوند. ممکن است یک تستر در پروژه، رگ و ریشه داشته باشد، ممکن است تستر فقط در تیم به عنوان یک تستر معمولی حضور داشته باشد، و حتی ممکن است دسترسی تستر به تیم از طریق الکترونیکی و سیستمهای Ticketing برقرار شود. همه آنها در نیمه دوم Iteration مجبور به اضافه کاری هستند. آنها در آن زمان واقعاً بخشی از جلسات برنامهریزی(Planning) نیستند و وقتی میتوانند شرکت کنند، در یک جلسه Planning عمیق فنی راحت نیستند. البته وقت کافی برای یادگیری رویکردها یا تکنیکهای جدید و مدرن نیز برایشان وجود ندارد.
اولین اقدام شما به عنوان مدیر جدید تست باید رفتن و دیدن فعالیتهای روزمره آنها باشد. در این زمان برخی از فعالیتها و فرایندهایی را مییابید که میتوانند بهبود یابند. علاوه بر این باید جلساتی کوتاه با تسترها را نیز آغاز کنید تا بتوانید نقاط ناراحتی آنها درک کرده و میزان تغییر را تنظیم کنید.
اولین تغییری که به عنوان یک تیم پیادهسازی میکنید، باید تا حد امکان کوچک و سهل و الوصول باشد، تا بتوانید یک پیروزی سریع کسب کنید و به تیم برای ادامه راه انگیزه دهد. برای تقویت گامهای توافق شده به منظور تغییرات مذبور، حمایت و پشتیبانی شما طی چند ماه آینده لازم است، اما اطمینان حاصل کنید که این ابتکار تحت مالکیت و نفوذ افرادیست که باید آن را تحقق بخشند.
این مجموعه از تغییرات، در نهایت شرایطی را ایجاد میکند که بهرهوری تست را افزایش داده و در نتیجه باعث اضافه کاری کمتر میشود. شما مسئولیت محافظت از این زمان آزاد شده کم را دارید تا به خوبی از آن استفاده شود. به تسترها کمک کنید تا در توسعه شغلی خود سرمایهگذاری کنند، نه فقط از طریق آموزش تست. چرا که در تیمهای Agile، برای انجام فعالیت با راندمان بالا باید Cross Functional عمل کرد، و این یعنی نیروها باید در همه امور توانمند بوده، و در بین موارد توانمندی خود در یک یا چند حوزهی محدود متخصص باشند.
یکی از ارکان مانیفستِ چهار بخشیِ چابک میگوید که ارتباط رو در رو موثرترین راه است. برای مستقر کردن بیشتر تسترهای خود در تیمهای مربوطه، باید آنها را قادر به صحبت با همان زبان توسعهدهندگان کنید. این به معنای گذراندن دورههای سطح پایه در Java ، .Net ، پایگاه داده، Apache، Linux و هر چیز دیگریست که هم تیمیهای آنها با آنها کار میکنند. این موضوع به همان Cross Functional بودن اشاره دارد که در پاراگراف بالا بدان پرداختیم. Source Control را در دسترس آنها قرار دهید و رشد توانمندی آنها روی جنبههای فنی را بدون پاداش نگذارید.
برنامه ما، ایجادِ توسعهدهندگان خردسال نیست. بلکه میخواهیم با ایجاد توانایی فنی در تسترها، آنها شخصیت تاثیرگذارتری در این تیمها داشته باشند، و اگر بخواهم خیلی ساده بگویم، هدف ما کسب احترام و بُرِش بیشتر برای تسترهاست. البته در یک تیم Agile همه اعضا باید Cross Functional باشند، تا همه از این احترام برخوردار باشند. وقتی ارتباط افراد در تیمهای Agile نزدیک است، پذیرفته نیست که اظهار نظر یک تستر توسط Developer تحقیر شود، و البته بالعکس. در یک تیم Agile علیرغم اینکه برای افراد، تخصص واحدی را قائل هستیم، اما باید سعی کنیم آنها را به مانند یک کاراکتر همه فن حرف تربیت کنیم.
یک فراورده جانبی خوب در این وضعیت، افزایش تعداد اسکریپتهای تست اتوماتیک(به دلیل ایجاد نگرش فنی در تسترها) و نیز احترام توسعهدهدنگان به تسترها، خواهد بود. اکنون شما افزایش پوشش در تست و نیز تسترهای فنی و پیشرفتهای را به دست آوردهاید که هر روز بیشتر در تیمهای خود جا میافتند.
القای ذهنیت کیفیت به ذینفعان
اکنون میتوانید به القای ذهنیت کیفیت در سایر ذینفعان بپردازید.
یافتن PO و Scrum Master(البته اگر Framework مدیریت پروژه ما Scrum باشد) خوب سخت است. با سازمانی که تازه به حالت چابک در آمده است، شما امیدوارید افرادی را در این سمتها داشته باشید، اما آنها احتمالاً هنوز هم با ایفای نقش قبلی و سنتی خود سازگار هستند. PO شما با توجه به مقدار Functionality تحویل شده هدایت میشود. Scrum Master شما نیز ممکن است یک توسعه دهنده ارشد سابق در شرکت یا شخصی استخدام شده از خارج شرکت باشد که هدف آنها تأمین نیازمندیهاست.
همکاری خوب که از سوی یک تستر فنی با دیگران انجام میشود، باعث میشود که موضوع کیفیت در صدر اذهان افراد نهادینه شود.
سنگ بنای ارتباطات پیرامون کیفیت در تحویل چابک(Agile Delivery)، تعریف آماده بودن(DoR) و تعریف انجام شده(DoD) است.
تعریف آماده بودن(DoR) یک قرارداد کیفی بین Poها و تیمهای Scrum است. پس از تعریف، این موارد، به عنوان ضامن کیفیت آغاز تولید شناخته میشود.
PO به خاطر آنچه که به عنوان DoR با تیم Scrum در یک اسپرینت خاص بسته است، طبعا خوشحال خواهد بود. اما لایههای بیشتری از تضمین کیفیت نیز وجود دارد، که در این راستا میتوانید مواردی از جمله مشخص بودن ملاکهای Security، Performance، Usability و … را نیز به عنوان بخشی از DoR بدانید. تجربه یک مهندس تست در زمان Backlog Grooming و Sprint Planning، میتواند بسیار ارزشمند باشد، بنابراین از حضور آنها در این روبدادها اطمینان حاصل کنید.
DoR گمراه کننده یا منسوخ منجر به موقعیتهای گیج کننده و غیرمولد میشود. پس DoRها باید به صورت واضح، غبرقابل تفسیر و قابل انجام، نگاشته شوند. چنین DoRای به تیم توسعه آرامش خاطر و فرصت موفقیت میدهد.
اما تعریف انجام شده(DoD) به عنوان یک قرارداد کیفی دیگر عمل میکند. اگر به خوبی تعریف و پیگیری شود، باعث تحویل محصولاتی با کیفیت میشود.
موارد مطروحه تا اینجا یک سری الزام اولیه در تیمهای Agile بود، که علیرغم ناکافی بودن، پایه و اساس تست Agile هستند.