گوگل چگونه نرم‌افزار را تست می‌کند

در تابستان سال ۹۷، به‌دنبال روشی بودیم که بتوانیم با کمترین هزینه بیشترین کیفیت را در محصولات شرکت ایجاد کنیم. در همین حین با کتاب «گوگل چگونه نرم‌افزار را تست می‌کند» آشنا شده و در جلسات کتاب‌خوانی، شروع کردیم به خواندن و مباحثه پیرامون آن. گسترش این کار در سطح شرکت، کمک کرد تا به‌مرور زمان از کنترل کیفیت فاصله گرفته و به نگاه جدیدی دست پیدا کنیم. تجربه‌ی ایجاد شده بسیار خوب بود و به‌همین دلیل سعی کردم نگاهی گذرا به کتابی که باعث شد دست به تغییرات مثبتی در سطح شرکت بزنیم، داشته باشم.

تست در گوگل

در این کتاب، نگاه شرکت گوگل به مقوله‌ی کیفیت نرم‌افزار با تمرکز بر مباحث آزمون مورد بحث قرار می‌گیرد. این کتاب با تاکید بر نگاه مهندسی بهره‌وری (Productivity Engineering) سعی می‌کند پیاده‌سازی گوگل را از مباحث مرتبط با کیفیت و آزمون، به‌صورت کاملا تشریحی برای مخاطب بیان کند.

مهندسی بهره‌وری که منشا بروز نگاهی نو در شرکت‌های مختلفی مانند گوگل و Netflix به‌‌روش تعامل تیم‌ها و تقسیم وظایف و مسئولیت‌ها است، در زمینه‌ی کارهای عملیاتی منجر به ایجاد مفهوم DevOps شده است. نویسندگان کتاب با همان نگاه مهندسی بهره‌وری اما این بار در زمینه‌ی تست، فرایند‌هایی مشابه DevOps را مطرح می‌کنند. به‌صورت کلی نگاه مهندسی بهره‌وری، شکستن مسائل در راستای اهداف کسب‌وکاری است. برای این منظور باید تیم‌ها هر کدام یک محصول/سرویس را به تیم‌های دیگر بفروشند. لازم به ذکر است که تمامی مراحل تولید هر محصول/سرویس از طراحی تا آزمون و تحویل، با تیم تولید کننده است.

با نگاهی به نویسندگان این کتاب متوجه می‌شویم که اکثر نویسندگان سابقه‌ای طولانی در برنامه نویسی و معماری نرم‌افزار داشته و در ابتدا مهندسان نرم‌افزار بوده‌اند. این مسئله، به خودی خود نشان‌دهنده‌ی متفاوت‌بودن این کتاب از سایر کتاب‌های تست و کیفیت است. کتاب‌هایی که اکثرا توسط مهندسین عموما کم‌تجربه و با تمرکز بر خود تست و کیفیت نوشته شده‌اند. از این رو، این کتاب می‌تواند برای هر مهندس نرم‌افزاری جالب باشد. در ادامه سعی می‌کنم تا مواردی را هر چند مختصر، از این کتاب مرور کنم.

با تست کردن به کیفیت نمی‌رسیم!

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

“Quality is not equal to test. Quality is achieved by putting development and testing into a blender and mixing them until one is indistinguishable from the other.”

کیفیت، وظیفه‌ی توسعه‌دهنده

این کتاب، کیفیت را وظیفه‌ی مهندس نرم‌افزار (SWE) در نظر می‌گیرد. مهندس نرم‌افزار کسی است که زمان زیادی را صرف نوشتن آزمون برای کد‌های خود کرده، مسئول رساندن یک محصول با کیفیت به مشتری است و در این مسیر باید بتواند تمام موارد لازم را از جمله آزمون، به‌خوبی انجام دهد.

این کتاب در کنار مهندس نرم‌افزار، نقش‌های Software Engineer in Test و Test Engineer را معرفی می‌کند. این دو نقش هر کدام به‌نحوی کمک می‌کنند تا کیفیت محصول‌های تولیدی افزایش پیدا کند.

نقش SET معمولا در کنار SWE یا مهندس نرم‌افزار، وظیفه‌ی تولید محصول را بر عهده دارد؛ اما خروجی کار SET بیشتر منجر به قابل‌تست‌بودن محصول و ایجاد روش‌هایی برای ارزیابی محصول می‌شود. به‌طور مثال SET در مراحل مختلف مانند تصمیم‌های معماری و توسعه‌، مشارکت کرده و سعی می‌کند تا محصول را قابل‌‌آزمون نگه دارد. از طرفی، SET به توسعه‌ی ابزار‌های مختلف برای ارزیابی محصول پرداخته و با تولید چارچوب‌ها و ابزار‌ها، به SWE کمک می‌کند تا بتواند از صحت کد تولیدی خود مطمئن شود.

مهندسین آزمون (Test Engineers) وظیفه‌ی بررسی محصول از جانب مشتری را بر عهده داشته و باید با توسعه‌ی ابزار‌ها، ایجاد زیرساخت مناسب و در انتها نوشتن سناریو‌ها با توجه به انتظارات کاربر، محصول را از دید کاربر بررسی کنند.

در این کتاب، تاکید می‌شود که تمامی مهندسان باید توانایی یک مهندس نرم‌افزار را داشته باشند و این، به این معنی‌ است که نقش‌های بالا، افرادی قوی‌تر از مهندسان نرم‌افزار بوده و علاوه بر مهارت‌های لازم برای مهندس نرم‌افزار بودن، مهارت‌های دیگری را نیز کسب کرده‌اند.

برنامه‌نویسان، شهروندان درجه یک

این کتاب اشاره می‌کند که اصلی‌ترین وظیفه‌ی همه‌ی مهندسان در گوگل، رساندن کد است. کل گوگل از یک Code Base واحد استفاده می‌کند که تمامی‌ کد‌های موجود در گوگل در آن وجود دارد. این مساله کمک می‌کند که همه‌ی افراد شرکت گوگل بتوانند از چگونگی کارکرد محصولات آگاه بوده و پیشنهاد‌های خود را برای افزایش کیفیت محصول ارائه دهند.

از طرفی چون تمامی افراد حتی افرادی که بر مقوله‌ی تست تمرکز دارند، برنامه‌نویسان ماهری هستند، همواره سعی دارند تا جلوی انجام کار به‌صورت دستی را بگیرند.

کنترل کیفیت، تضمین کیفیت یا توسعه‌ی کیفیت

یکی از دغدغه‌هایی که با خواندن این کتاب تا حدی به آن پاسخ داده می‌شود، نحوه‌ی تعامل تیم کیفیت با تیم‌های دیگر است. به‌صورت معمول شرکت‌ها مایل‌اند یک تیم کیفیت با عنوان تضمین کیفیت یا کنترل کیفیت داشته باشند.

تیم کنترل کیفیت وظیفه دارد که کیفیت محصول را بررسی کند. بنابراین تیم کنترل کیفیتِ خوب، تیمی‌ است که مشکلات بیشتری را در نرم‌افزار کشف کند. این نگاه، معمولا تیم کنترل کیفیت و تیم توسعه را در تقابل با یکدیگر قرار داده و از طرفی، به‌دلیل این که تیم کنترل کیفیت پس از اتمام مراحل طراحی و تولید محصول با محصول مواجه می‌شود، در اکثر اوقات با یک محصول غیرقابل‌آزمون روبه‌رو شده و هزینه‌ی اجرای آزمون بالا می‌رود. در این مدل، تیم تولید، تیم کنترل کیفیت را مسئول کیفیت نرم‌افزار می‌داند.

از طرفی تیم تضمین کیفیت وظیفه دارد تا با پیشنهاد و نظارت بر روش تولید نرم‌افزار، از تولید محصول مشکل‌دار جلوگیری کند. شاید این طور به‌نظر برسد که این روش، مشکلات روش گذشته را حل کرده است؛ اما در واقع مشکل اصلی که مسئولیت‌پذیری در رابطه با کیفیت نرم‌افزار است، هنوز پابرجاست. در این روش، تیم توسعه‌ی خوب، تیمی‌ است که تمامی فرایند‌های مورد تایید تیم تضمین کیفیت را انجام دهد؛ حتی به قیمت این که محصول مورد نظر در محیط واقعی کار نکند. معمولا در شرکت‌هایی که این نگاه به کیفیت را دارند، تیم توسعه، محصول را برای تیم تضمین کیفیت تولید می‌کند، نه برای مشتری.

در عوض، در این کتاب عنوان می‌شود که تنها مسئولِ کیفیتِ نرم‌افزار، تیم توسعه است و تیم‌های دیگر می‌توانند با ارائه‌ی سرویس‌ها و ابزار‌های مختلف، به تیم توسعه در این مسیر کمک کنند. برای مثال، SET ها می‌توانند با مشارکت در جلسات طراحی و معماری، تا حد ممکن به طراحی یک محصول قابل‌آزمون کمک کنند تا هزینه‌ی آزمون‌های بعدی کاهش پیدا کند.

مهندسین آزمون (TEs) می‌توانند ابزار‌هایی برای Acceptance Test محصول‌ها ارائه دهند تا همه‌ی افراد درگیر یک پروژه بتوانند به‌راحتی Acceptance Testها را برای اجرای خودکار پیاده‌سازی کنند.

پلکان کیفیت

مفهوم دیگری که در این کتاب به آن پرداخته می‌شود، یک نردبان برای رشد کیفیت محصول است. این نردبان که با نام Test Certified معرفی می‌شود، به تیم‌ها کمک می‌کند تا مسیری را که با طی‌کردن آن می‌توانند به سمت تولید با کیفیت‌تر حرکت کنند، معرفی می‌کند. استفاده از این پلکان برای تیم‌ها کاملا اختیاری بوده و تیم‌ها می‌توانند با توجه به اهمیت کیفیت در محصول خود، سطح مشخصی را هدف‌گذاری کنند.

سطوح اولیه‌ی Test Certified

نتیجه‌گیری

کتاب «گوگل چگونه نرم‌افزار را تست می‌کند»، نگاهی متفاوت با نگاه معمول را به کیفیت نرم‌افزار معرفی می‌کند. علاوه بر معرفی این نگاه، این کتاب با افراد مختلف مصاحبه کرده و روش رسیدن گوگل به یک کیفیت خوب در توسعه‌ی نرم‌افزار را به مخاطب ارائه می‌دهد.

افراد، تیم‌ها و سازمان‌هایی که دغدغه‌ی تولید محصول با کیفیت دارند، قطعا با مطالعه‌ی این کتاب نکات مفیدی را دریافت خواهند کرد. به‌خصوص شرکت‌هایی که بعد از پیاده‌سازی روش‌هایی مثل کنترل کیفیت، درک درستی از مشکلاتی که در نگاه سنتی به کیفیت وجود دارد، پیدا کرده‌اند.

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *