شیفت دادن تست به سمت چپ در کیفیت از ابتدای کار

نوشته های مرتبط

اتوماسیون تست بیش از حد

آبان ۲۴, ۱۴۰۰

نحوه بهینه سازی تجربه مشتری با استفاده از تست

آبان ۱۲, ۱۴۰۰

چگونه تعامل صحیح کسب و کاری می تواند به تحول “همیشه شاد” یا Happy Ever After منجر شود؟

آبان ۱۰, ۱۴۰۰

“Shift Left” یکی از واژگان شایع اخیر در تست نرم‌افزار است. حرکت‌هایی از قبیل Agile، و DevOps، موضوع Shift Left را به تسترها توصیه می‌کنند، اما دقیقا معنی این موضوع چیست؟ معمول است که توسعه نرم‌افزار به صورت تقسیم شده به فازهای کاملا واضح دیده شود: تحلیلگران یک ایده را تحلیل می‌کنند تا ببینند آیا آن ایده قابل قبول است یا خیر. طراحان می‌توانند چگونگی آن را طراحی کنند. توسعه دهندگان راهکار(Solution) را ایجاد می کنند. سپس تسترها آنرا تحت تست قرار می‌دهند تا ببینند که فرآورده حاصله کار می کند یا خیر. در آخر مهندسان ریلیز(Release Enigineer) آنرا به فضای عملیاتی می‌سپارند.
اگر مراحل را به صورت انگلیسی و چپ به راست یادداشت نمایید، با یک دنباله مانند زیر مواجه خواهید شد:

Analyze > Design > Develop > Test > Release

همانطور که می‌بینید، تست در سمت راست چرخه حیات توسعه(Development Lifecycle) است. اما روش‌های مدرن توسعه نرم‌افزار این ساختار خطی معمولی را لرزاند و انجام تست را در خلال فازهای تحلیل، طراحی و توسعه گنجاند. به عبارت دیگر، تست به سمت چپ و جایی که مسائل طرح می‌شوند شیفت پیدا کرد.
تئوری این است که شیفت دادن به سمت چپ به این روش، کمک می کند تا نرم افزار بهتر و سریعتر Build(ساخته) شود. تجربه شخصی من ارزش شیفت دادن به سمت چپ را به صورت تصادفی برای من روشن کرد.
تبدیل شدن به کسی که به Shifting Left معتقد است!
Build Server ما کار را متوقف کرده بود. رسما می‌توانم بگویم که مرده بود، و چیزی که به ما گفتند این بود که رفع این موضوع یک هفته طول می‌کشد. این بدین معنی بود که هیچ کدام از توسعه دهندگان ما نمی‌توانستند هیچ یک از کارهایشان را در محیط عملیاتی ما Deploy(مستقر) کنند. آنها می‌توانستند برنامه‌نویسی را ادامه دهند، اما با توجه به فرآیند ما، من نمی‌توانستم چیزی را تست کنم.
برای حل مشکل، یکی از توسعه‌دهندگان مرا را دعوت کرد تا کار را به صورت Locally روی این ماشین تست کنم. با هم نشستیم و او تغییراتی را که داده بود به من نشان داد. من سوالاتی در مورد آن پرسیدم و از او خواستم چند مورد را امتحان نماید(دقیقا به همان شکلی که اگر میخواستم آن را در محیط عملیاتی تست کنم).
حدس بزن چی شد؟ ما یک اشکال پیدا کردیم!
در وضعیت معمول، این به معنی ثبت نقص، و در اختیار گرفتن آن کار توسط نیروی فنی برای رفع مشکل، استقرار مجدد در محیط عملیاتی و آغاز مجدد فرآیند بود. اما به دلیل اینکه ما به صورت Locally تست کرده بودیم، می‌توانستیم باگ را رفع کرده و به سرعت Retest را انجام دهیم. ما مجبور نبودیم تشریفات ثبت باگ و Redeploy کردن را برای تست انجام دهیم.
پس از چند بار انجام این کار، ما متوجه شدیم که این روش بسیار کارآمدتر است!
در نتیجه، حتی زمانی که Build Server بالا آمد، ما روش تست Locally قبل از Deploy را ادامه دادیم. این روش به قول معروف “گرفت”، و به زودی من این کار را با بسیاری از توسعه‌دهندگان تیم انجام دادم.
این فقط یک نمونه از چگونگی ارزشمندی تست زود هنگام است. در این مورد، Pair up(جفت کردن-اصطلاحی که بیشتر برای کار کردن توسعه‌دهنده و تستر در کنار هم استفاده می‌شود) تعداد زیادی فرآیند اضافی را حذف کرد. پیدا کردن این اشکالات در طول توسعه به این معنی است که ما زمان کمتری برای برطرف کردن آنها صرف می‌کنیم، اما علاوه بر بهبود حاصل شده در صرف زمان، ما هزینه مالی را نیز صرفه‌جویی می‌کنیم، چرا که ثبت کردن یک باگ و Redeploy کردن یک Fix برای شرکت هزینه بر بود.
این یک روش عالی برای کار در این حوزه است، اما این تنها راه برای ایجاد Shifting Left نیست.
تسترها همچنین قادرند در مراحل دیگر چرخه حیات توسعه نرم افزار، در Planning، تحلیل و جلسات طراحی نیز شرکت کنند. با آوردن Domain Knowledge و نگاه انتقادی به یک جدول، می‌توان باگ‌ها را قبل از اینکه حتی کد نوشته شود کشف کرد.
من بخشی از یک جلسه برای راه اندازی یک Feature بودم، که در آن به عنوان یک تیم، ما نمونه اولیه‌ای(Prototype) را که یکی از طراحان تولید کرده بود، دیدیم. در آن جلسه من متوجه شدم طرح صفحه جدید با سایر قسمت‌های مشابه محصول در تناقض است. به نظرم آمد، این یک تجربه گیج کننده برای کاربران خواهد بود. من در این مرحله درگیر کار شدم، و توانستم تصمیمگیری در رابطه با طراحی را در اوایل کار به چالش بکشم. این یک زمان طلایی برای این کار بود، چرا که انجام چنین کاری در این مرحله بسیار ساده‌تر(و کم زمان‌تر و ارزان‌تر) از تعمیر آن در مراحل بعدی بود.
اگر شما به دنبال نظرات الهام بخش بیشتری هستید که ارزش خواندن داشته باشند، مایکل بولتون(Michael Bolton) دارای چند پست وبلاگی بزرگ در مورد مسائلیست که تسترها می‌توانند در برنامه‌ریزی انجام دهند.
آغاز Shift دادن
خیلی خوب است که در مورد مزایای Shifting Left صحبت کنیم. اما این شیفت دادن می‌تواند دشوار باشد! چند کار انجام می‌دهیم تا این شیفت دادن را آسان تر کنیم.
بعضی اوقات تسترها در جلسات اولیه در پروژه جایی ندارند. یکی از چیزهایی که می توانیم انجام دهیم این است که خودمان را به چیزهایی مانند Project Kickoffها و جلسات طراحی نمونه‌های اولیه(Prototype) دعوت کنیم. ممکن است به نظر ترسناک برسد که خودمان را به جلساتی مانند این دعوت کنیم، اما حتی اگر جلسه در حال پیشرفت باشد ما باید در بزنیم و بخواهیم تا به جلسه بپیوندیم. اما بدترین چیزی که در این حالت می‌تواند اتفاق بیفتد این است که آنها بگویند نه.
با این حال، با احتمال بسیار زیادی آنها بله خواهند گفت. هنگامی که ما در جلسه هستیم، می‌توانیم به تصمیم‌گیری‌های تحلیل و طراحی کمک کنیم. علاوه بر این تیم ما ارزش درگیر شدن تسترها در این مرحله زودهنگام را برانداز می‌کند.
یکی دیگر از ابزار ارزشمند در رویکرد shift-left، تست دو نفری با توسعه دهندگان است. اگر این موضوع برای یک سازمان جدید است، برای این کار نیاز به پیدا کردن برخی از توسعه‌دهندگان دارید که برای انجام این کار مخالفتی ندارند. اگر چنین اتفاقی رخ دهد، می‌توان امیدوار بود که این ایده گسترش یابد، همانطور که در محل کار من چنین اتفاقی رخ داد.
یکی از چیزهایی که در هنگام جفت شدن با توسعه‌دهندگان به خوبی کار می‌کند “Rubber Ducking” است؛ تکنیکی که از کتاب Pragmatic Programmer اثر اندرو هانت(Andrew Hunt) و دیوید توماس(David Thomas) استخراج شده است. در این موضوع، ایده این است که یک توسعه‌دهنده، کد خود، Feature، یا سوییت تست‌ها را برای یک Rubber Duck(اردک لاستیکی) یا شی بی جان دیگر که روی میز وی قرار دارد، تشریح می‌کند. این موضوع نیازمند این است که آنها کار خود را به صورت گام به گام، Walk Throw(یک روش مرور کار که در Exploratory Testing به عنوان یک روش کارا و غیررسمی در مرور یک فعالیت مطرح می‌شود) نمایند. در مورد ما، تستر نقش اردک لاستیکی را بازی می‌کند و توسعه‌دهنده در مورد کارهای خود با وی صحبت می‌کند. این یک روش ساده شکستن یخ تست در حالت جفتیست.
هنگامی که شروع به جفت شدن با یک توسعه‌دهنده می‌کنم، این تکنیک را زیاد انجام می‌دهم. سپس می‌توانم سوالات خود را مطرح کنم، و کارهای آنها را تست کنم. پس از مدتی، توسعه‌دهندگان می‌توانند چیزهایی را که میخواهم از آنها بپرسم پیشبینی کنند!
وقتیکه چنین روشی را در پیش بگیرید، امیدوار باشید که جفت شدن رخ دهد. گاهی اوقات متوجه می‌شوم که من با یک توسعه دهنده نشسته‌ام، و آنها شروع می‌کنند آنچه ساخته‌اند را به من نشان می‌دهند. جالب اینکه بدون اینکه من کلامی صحبت کنم، یک مشکل یا مورد به ذهن آنها خطور می‌کند، و آنها از من می‌خواهند تا بروم و بعدا دوباره پیش آنها بازگردم. در حقیقت خود آنها باگ کارشان را پیدا می‌کنند.
این موضوع به یکی از مزایای کلیدی در Shifting Left منجر می‌شود که عبارتست از: “به اشتراک گذاری مهارت‌های تست با دیگر اعضای تیم”.
Shifting Left همه را منتفع می‌کند
تست مهارت خاصی است. با آوردن تست به بخش‌های دیگر فرآیند توسعه، می‌توانیم برخی از ارزش‌های تست را نشان دهیم، و دیگر نقش‌های موجود در سازمان ما نیز می‌توانند یاد بگیرند که یک تستر چگونه فکر می‌کنند.
هنگامی که من تغییرات ایجاد شده توسط توسعه‌دهندگان در Front-End را تست می‌کنم، اغلب درباره کامپوننت‌های آنها می‌پرسم که: “آیا این کامپوننت که شما تغییر داده‌اید، در جاهای دیگری از محصول استفاده می‌شود یا خیر؟” اگر پاسخ بله باشد، پس باید بررسی کنیم که Featureهای دیگر(که از این کامپوننت استفاده کرده‌اند) را رها نکنیم. این سوال باعث گسترش این نوع تفکر می‌شود!
بسیار خوب است که توسعه‌دهندگان این موضوع را متوجه شوند. اگر آنها در حال تغییر دادن یک کامپوننت باشند، همانطور که آنها کدنویسی کرده و تغییرات را ایجاد می‌کنند، درباره استفاده‌های دیگر از این کامپوننت فکر می‌کنند، و طبعا تغییرات را با استحکام و دقت بیشتری ایجاد می‌کنند. علاوه بر این، هنگامی که یک طرز تفکر در مورد تست را توسعه می‌دهید و به این روش کار می‌کنید، زمان را برای تستر آزاد می‌کنید تا سناریوهای پیچیده‌تر و مشکلتر را Explore کرده و بررسی نماید.
شیفت دادن تست به سمت چپ، یک پیروزی برای کل تیم و همچنین تستر است. تست شدن کار در مراحل اولیه توسعه باعث می‌شود کل پروسه توسعه سریع‌تر شده و یک محصول قوی‌تر تولید شود.
کیفیت را نمی‌توان در اواخر بازی به یک محصول اضافه کرد؛ بلکه کیفیت باید از اوایل کار پخته شود. این کار می‌تواند سخت باشد، اما با انجام دادن کارهایی مانند دعوت از خود به جلسات، پیدا کردن توسعه‌دهندگان برای پیوستن و به اشتراک گذاری مهارت‌های ما با دیگران، می‌توانیم به آن دست یابیم و در نتیجه محصولات بسیار خوبی داشته باشیم.