تیستن جامعه مهندسین تست نرم‌افزار ایران
نوشته های مرتبط
خلاصه: توسعه‌دهندگان عادت دارند «روی هم روی هم» کد بزنند. این امر غالباً به دلیل عدم اطلاع دقیق از این موضوع است که آن امکان یا کد چه زمانی تکمیل می‌شود و ایضا به دلیل عدم اطلاع از این موضوع که چقدر یک امکان(Feature) باید قوی باشد. توسعه مبتنی بر آزمون پذیرش(Acceptance Test Driven Development) یک روش عالی برای جلوگیری از این عمل است، زیرا وقتی آزمون پذیرش(Acceptance Testing) با موفقیت(Pass) به اتمام رسید، توسعه‌دهنده متوجه می‌شود که آنها تکمیل این امکان ویژه را به پایان رسانده‌اند.
من به کد زیبا-Elegant Code(نرم‌افزاری که فهم و نگهداری آن آسان باشد) بسیار علاقه دارم، اما تنها دلیل این موضوع علاقه شخصی من نیست، بلکه حس واقع‌بینانه من در این موضوع که کد باید برای مالک خود، تا جای ممکن اقتصادی و کاربردی باشد، دلیل اصلی این علاقه است.
یکی از دوستانم که توسعه‌دهنده نرم‌افزار است، به این خاطر که راه‌ها و تکنولوژی‌های زیاد و متفاوتی برای حل مشکلات پیش رو می‌دید، همیشه سردرگم بود. او بابت این موضوع که باید از چه شاخصی برای ارزیابی یک نرم‌افزار خوب استفاده کند، دو به شک بود، در حقیقت تا آن موقع این سوال که یک نرم‌افزار خوب واقعا چه نرم‌افزاریست برای او پیش نیامده بود.
البته او در این سوال تنها نبود. چرا که به خاطر شخصیت کنجکاوی که داشت از برنامه نویسان زیادی همین سوال را که یک نرم‌افزار خوب چه مشخصه‌هاییی باید داشته باشد را پرسیده بود و می‌گفت که آنها هم به سختی و مبهم به این سوال جواب می‌دادند. البته من به عنوان نگارنده مقاله می‌دانستم که استانداردهای ISO 9126 یا ISO25010 مشخصات یک نرم‌افزار خوب را تعیین می‌کنند. به ویژه دو مشخصه Reliability و Maintainability برای یک نرم‌افزار؛ اما تعداد کمی از توسعه‌دهندگان می‌دانند که در زمان کدنویسی چگونه یک کد قابل اطمینان(Reliable) و نگهداشت‌پذیر(Maintainable) بنویسند.
من فکر می‌کردم که شاخص‌های نرم‌افزار، پروژه به پروژه با هم متفاوت هستند. اما اکنون پی برده‌ام که ساخت نرم‌افزار با کیفیت، ارزانتر است و اگر غیر از این فکر کنیم، خودمان را فریب می‌دهیم.
یک فرض غلط در مدیریت نرم‌افزار وجود دارد که در آن راه صحیح انجام کار، سریعترین راه برای تحویل یک Feature به مشتری تحویل دهید. این می‌تواند یک هدف ارزشمند باشد، اما اغلب، چه در دراز مدت و چه در کوتاه مدت، به برش سر و ته کد و به خطر افتادن کیفیت آن، که منجر به کند شدن پروژه می‌شود، تبدیل می‌گردد.
توسعه نرم‌افزار یک فرآیند اکتشافیست، شاید یک کدنویس فکر کند که برای نوشتن کد استخدام شده است، اما در واقع کد یک تجسم از درک است. تست واقعی(چیزی که باعث می‌شود یک توسعه‌دهنده نرم‌افزار عالی باشد) عبارتست از توانمندی ما در درک آنچه که آنرا خودکار کرده‌ایم. کد از آن درک نشات گرفته و از طریق یک فرآیند اکتشافی پدیدار می‌شود.
بسیاری از شرکت‌های موفق توسط بخش فناوری اطلاعات خود مورد اعتراض قرار می‌گیرند، نه به این دلیل که آنها توسعه‌دهنده‌گان بی پروا دارند، بلکه به دلیل این که فناوری اطلاعات دشوار است و با سایر بخش‌ها در بیشتر شرکت‌ها متفاوت است. بسیاری از پروژه‌های نرم‌افزاری به جای اینکه امکانات(Feature) خود را به وظایف قابل کنترل تبدیل کنند، امکانات بیشتری را در نسخه‌های منتشر شده قرار می‌دهند و سپس سعی می‌کنند تا متوجه کل طرح شوند. پروژه‌های نرم‌افزار باید متفاوت از دیگر پروژه‌های مدیریت شوند.
من همیشه وقتی با تیم‌های توسعه ملاقات می‌کنم، وقتی می‌بینم که مدیران به توسعه‌دهندگان خود اعتماد ندارند، کمی تعجب می‌کنم. من می‌دانم که توسعه‌دهندگان تمایل به کدنویسی «روی هم روی هم» و یا “Gold Plate”(یک اصطلاح دیگر برای روی هم روی هم)دارند. این امر غالباً به دلیل عدم اطلاع دقیق از این موضوع است که آن امکان یا کد چه زمانی تکمیل می‌شود و ایضا به دلیل عدم اطلاع از این موضوع که چقدر یک امکان(Feature) باید قوی باشد. با این حال اغلب، یک گفتگوی کوتاه با صاحب محصول یا مشتری در مورد اولویت نسبی یک Feature نسبت به سایر Featureهای سیستم، به توسعه‌دهندگان کمک می‌کند شفافیت مورد نیاز خود را بدست آورند.
شیوه‌های توسعه‌دهنده Agile و طراحی اضطراری(Emergent Design) به جای تصور کردن همه چیز، روشی بسیار مقرون به صرفه‌تر برای ساختن نرم‌افزار پیشنهاد می‌کند تا با استفاده از آن بتوانیم مواردی را که می‌خواهیم، متوجه شویم. همانطور که معلوم است، این نیز راهی بهتر برای تولید راهکارهای با کیفیت بالاتر از رویکرد استاندارد آبشاریست.
هنگامی که توسعه‌دهندگان نمی‌دانند چگونه از آن استفاده می‌شود، به کد Gold Plate متمایل می‌شوند. ما نمی‌خواهیم کد ما به این دلیل دچار شکست شود، بنابراین سعی می‌کنیم آنرا تا حد امکان مستحکم و قوی کنیم. اما بدون دانستن زمینه کد(Code Context) تنها میتوانیم روی هم روی هم کد بنویسیم و وقت ارزشمند خود را هدر دهیم.
این در حالیست که می‌خواهیم به کارهایی که انجام می‌دهیم افتخار کنیم، و علاوه بر آن تمایل داریم بیشترین ارزش را برای مشتریان خود به ارمغان بیاوریم. ما باید آماده تغییر دنده(مانند تغییر دنده خودرو) یک پروژه باشیم تا در زمان ارائه، آنچه تحویل داده می‌شود معقول و منطقی باشد.
در توسعه نرم افزار Agile، ما با مشتری شریک می‌شویم و با هم بهترین روش ساخت نرم‌افزار را برای نیازهای وی کشف می‌کنیم. این همکاری به مراتب مؤثرتر از رویکرد موجود در توسعه آبشاریست، زیرا بازخورد مداوم را امکان پذیر می‌کند. اما ما به مکانیسم‌هایی نیز برای جذب این بازخورد نیاز داریم. ATDD یک روش خوب برای ایجاد Featureهای مورد نیاز، بدون ساخت «روی هم روی هم» است. به کمک ATDD ما با دانستن تستهای پذیرش برای امکاناتی که می‌خواهیم تولید کنیم، شروع می‌کنیم. با استفاده از یک ATDD Framework مانند SpeceFlow ,Cucumber و یا Fit ما میتوانیم تستهای پذیرش را به صورت اتوماتیک انجام دهیم تا متوجه شویم که کد تولیدی ما مطابق انتظار کار می‌کند یا خیر. علاوه بر این به مدیریت نیز کمک می‌کند تا با یک نگاه متوجه شود تستهای پذیرش قبول شده‌اند یا نه و چه مقدار از آنها باقی مانده‌اند و به برنامه‌نویس هم این بازخورد را می‌دهد که شاخص‌های پذیرش و Featureها تکمیل شده‌اند یا خیر. برای جلوگیری از روش Gold Plate، تستهای پذیرش بهترین روش هستند که به انجام بهتر امور کمک می‌کنند. زمانیکه تست پذیرشِ تعریف شده توسط صاحب محصول، مشتری و تیم پاس شد، این معنی را متبادر می‌کند که ما ساخت Feature را تکمیل کرده‌ایم. این موضوع به ما کمک می‌کند تا کاری که انجام می‌دهیم را بدانیم و تمرکزمان را بروی مهمترین بخش های سیستم قرار دهیم، و مهم تَر از همه تستهای پذیرشی که Pass می‌شوند، نتیجه و بازخوردیست که از سیستم و Featureهای ایجاد شده به ما ارائه می‌شود، و ما بدون ترس از جا انداختن چیزی به کارمان ادامه می‌دهیم.
