تصور کنید مهم‌ترین نرم‌افزار شرکت شما ناگهان خراب می‌شود - چه اتفاقی می‌افتد؟ ممکن است سفارشات گم شوند، ضرب الاجل ها ممکن است از دست بروند، اما مشتریان قطعا شکایت خواهند کرد.
این سناریوی کابوس قابل اجتناب است: با اجرای یک فرآیند آزمایش مستمر و دقیق، که مشکلات را قبل از ایجاد هرج و مرج حل می کند. اما اجرای چنین فرآیندی در سازمان شما ساده تر از انجام آن است.
این مقاله به شما همه چیزهایی را که هنگام شروع آزمایش در شرکت خود باید در مورد آن فکر کنید و اینکه چگونه می توانید در بلندمدت از آزمایش سود ببرید را به شما نشان می دهد.
آزمایش بهترین شیوه ها برای تیم های محصول
بخش اول این مقاله روند شروع اجرای آزمایش در گردش کار شما را پوشش می دهد.
فرهنگ آزمایش را در تیم خود پیاده کنید
معرفی موفقیت آمیز تست در تیم شما مستلزم آن است که همه یک طرز فکر مشترک داشته باشند و کیفیت را نه به عنوان یک بار، بلکه به عنوان یک سرمایه گذاری ببینند. این فرآیندی است که مانند هر تغییر فرهنگی دیگری نیازمند زمان و ثبات است.
یکی از چیزهایی که می تواند به شکل گیری این فرهنگ کمک کند، جلسات منظم برای بحث در مورد نقص ها، تأثیری که آنها داشته اند، از کجا آمده اند و آنچه برای رفع آنها نیاز است، می باشد. این به ایجاد آگاهی در مورد اینکه چرا در وهله اول جلوگیری از چنین نقص هایی خوب است کمک می کند.
وجود فردی متعهد در تیم که بر تلاش ها نظارت و هدایت می کند، می تواند شانس موفقیت را به شدت افزایش دهد. کسی که دستورالعمل‌های تیم یا حتی در سطح سازمان را تعریف می‌کند، بهترین شیوه‌ها را جمع‌آوری می‌کند و آنها را به اشتراک می‌گذارد و از تلاش در سطوح مختلف حمایت می‌کند.
ابزار مفید دیگر می تواند چرخش نقش پشتیبانی محصول شما باشد. دریافت بینش دست اول و بدون فیلتر از مشتریان و یادگیری در مورد مشکلات روزمره آنها با محصول شما می تواند یک تجربه ارزشمند برای مدیران محصول، طراحان و توسعه دهندگان باشد.
هدف این است که همه اعضای تیم شما بدانند که کیفیت یک ویژگی است، به اندازه هر قابلیت دیگری که برای محصول خود می سازید. وقتی همه این طرز فکر را پذیرفتند، درک این نکته که تست ها نیز یک ویژگی هستند، پیشرفت طبیعی است. زیرا تست ها کیفیت ارسال را تضمین می کنند.
فرآیند تست گام به گام
هنگامی که بین تیم های مختلف درگیر در توسعه محصول هماهنگی وجود دارد، می توانید وجود و استفاده از آزمایش ها را بیشتر رسمی کنید.
تست ها را بخشی از "تعریف انجام شده" کنید
با افزودن تست‌ها به‌عنوان یک ویژگی مورد نیاز، اعلام می‌کنید که یک ویژگی تا زمانی که به‌درستی و به‌طور خودکار آزمایش نشود، آماده ارسال نیست.
تست ها را به طور منظم اجرا کنید
پس از پیاده سازی، تست های خودکار می توانند محافظ شما در هر مرحله از فرآیند توسعه باشند. آنها نیازی به دخالت انسانی ندارند و می توانند در هر مرحله حیاتی از خط لوله توسعه شما اجرا شوند. مثلا:
- در هر تعهد
- در هر درخواست کشش.
- پس از هر انتشار کامل یا تغییر محیط.
اگر در محیط تولید خود به خدمات شخص ثالث متکی هستید، حتی می‌تواند منطقی باشد که آزمایش‌های خود را در برابر تولید اجرا کنید تا اطمینان حاصل کنید که APIهای شخص ثالث مطابق انتظار عمل می‌کنند.
معیارها را تعریف و جمع آوری کنید
تعریف مجموعه‌ای از معیارها برای اندازه‌گیری اثربخشی آزمایش‌های شما و تأثیر گردش‌های کاری آزمایش بر کسب‌وکارتان مهم است. در اینجا چند نمونه از معیارهایی وجود دارد که می توانید از آنها استفاده کنید:
- انتشار در هر ماه : تعداد بیشتر انتشار در هر ماه می تواند نشان دهنده روند توسعه چابک تر باشد. تست خودکار در اینجا با اطمینان از اینکه نسخه ها می توانند با اطمینان پیش بروند، نقش کلیدی ایفا می کند.
- گزارش‌های اشکال : روند کاهشی در گزارش‌های باگ می‌تواند نشانه مثبتی از مؤثر بودن آزمایش (و فرآیندهای توسعه) شما باشد.
- پوشش آزمایشی : در حالی که هرگز یک معیار دقیق نیست، پوشش می‌تواند نشانگر خوبی از میزان عمیقی باشد که شما موارد استفاده حیاتی را آزمایش می‌کنید.
توجه داشته باشید که این معیارها همچنین تحت تأثیر عوامل دیگری هستند که ممکن است آنها را منحرف کنند. برای مثال، ممکن است تعداد انتشار شما در فصل تعطیلات کاهش یابد، در حالی که گزارش‌های باگ افزایش می‌یابند. بنابراین فقط به چند مورد تکیه نکنید و مطمئن شوید که آنها را با سایر داده های موجود در اختیار تیم خود قرار دهید.
هنگامی که آن مراحل را با موفقیت با تیم خود اجرا کنید، سلامت محصول شما قطعا در دراز مدت سود خواهد برد. اما هنوز کارهای بیشتری می توانید انجام دهید!
آزمایش بهترین روش ها برای مدیران سیستم
تیم های محصول نمی توانند به تنهایی کار کنند. آنها به سخت افزار، ابزارها و زیرساخت های نگهداری شده توسط مدیران سیستم متکی هستند. در حالی که مدیران سیستم معمولاً مستقیماً به توسعه محصول کمک نمی کنند، آنها همچنان می توانند برای همیشه بر روند کار توسعه تأثیر بگذارند. به عنوان مثال با مدیریت فعال نسخه مرورگر گروه های کاربری خاصی در شرکت استفاده می کنند.
این بخش دوم مقاله نحوه عملکرد این کار را با استفاده از کانال‌های Chrome و خط‌مشی‌های سازمانی توضیح می‌دهد.
کانال‌های انتشار کروم
به‌طور پیش‌فرض Chrome به‌روزرسانی خودکار انجام می‌شود تا مطمئن شود هر کاربر آخرین، پایدارترین و ایمن‌ترین نسخه Chrome از جمله آخرین ویژگی‌ها را اجرا می‌کند—نسخه Chrome منتشر شده در کانال پایدار.
به عنوان شرکتی که یک محصول مبتنی بر وب را توسعه می دهد، ممکن است بخواهید از یک مرورگر قبل از کانال پایدار استفاده کنید تا به تیم های محصول خود زمان دهید تا محصول شما را با تغییرات در پلت فرم وب تطبیق دهند.
برای این مورد استفاده، Chrome در مجموع چهار کانال انتشار ارائه می‌کند که برای گروه‌های کاربری مختلف در نظر گرفته شده است.
در مورد کروم، کانال‌های انتشار مختلفی وجود دارد که می‌توانید برای پیش‌بینی تغییرات مرورگر آینده و آزمایش آخرین ویژگی‌ها قبل از اینکه به طور گسترده در دسترس باشند، از آنها استفاده کنید:
- کانال پایدار : این جایی است که اکثر کاربران در آن هستند. هنگامی که نسخه جدیدی از Chrome وجود دارد، کانال پایدار به‌طور خودکار به‌روزرسانی می‌شود که هر ماه انجام می‌شود.
- کانال بتا : این نسخه در عرض چهار تا شش هفته پایدار می شود و به شما فرصتی می دهد تا نسخه پایدار آینده را پیش نمایش و آزمایش کنید و برای آن آماده شوید.
- کانال برنامه‌نویس : این کانال هفته‌ای یکبار نسخه جدید Chrome را دریافت می‌کند و شامل آخرین اصلاحات است که در نهایت به نسخه بتا منتقل می‌شوند. همانطور که از نام کانال پیداست، در حال توسعه است و بنابراین ممکن است به طور غیرمنتظره ای خراب شود - اما جدیدترین ویژگی ها را نیز در بر می گیرد، گاهی اوقات خیلی قبل از اینکه راه خود را به سمت پایداری باز کنند. این باعث می شود کانال توسعه دهنده ابزاری عالی برای نمونه سازی و توسعه پیشرفته باشد.
- کانال قناری : آزمایشی ترین کانال، حاوی آخرین ویژگی ها اما بدون آزمایش زیاد. حداقل روزانه منتشر می شود.
اگر می‌خواهید درباره کانال‌های Chrome بیشتر بدانید، قسمت مربوط به مفاهیم Chrome را بررسی کنید.
استفاده از کانال ها در یک سازمان نمونه
ساختار تیم های محصول در بین سازمان ها متفاوت است، زیرا هیچ رویکردی برای توسعه نرم افزار وجود ندارد. به عنوان مثال، تیمی را با نقش های زیر فرض می کنیم: مدیریت محصول، UX و UI، مهندسی، عملیات و پشتیبانی.
برای سازمانی مانند این، می توانید به تقسیم کانال زیر فکر کنید:
- مدیریت محصول : PM ها معمولاً می توانند در کانال پایدار باشند تا از نسخه مشابه اکثر کاربران استفاده کنند. اگر روی ویژگی‌ای کار می‌کنند که به API نیاز دارد که هنوز راه‌اندازی نشده است، می‌توانند از کانال بتا یا توسعه‌دهنده استفاده کنند.
- مهندسی و تجربه کاربری : بخش‌هایی از این تیم‌ها می‌توانند در کانال توسعه‌دهنده باشند تا به آخرین ویژگی‌ها مانند View Transitions دسترسی داشته باشند، حتی قبل از اینکه در حالت پایدار باشند.
- عملیات : می‌تواند در نسخه بتا باشد، تا پیش‌بینی شود که شکستگی روی کاربران تأثیر می‌گذارد.
- پشتیبانی : می‌تواند در کانال پایدار بماند تا مطمئن شود که با مرورگر مشابه اکثر مشتریان شما با محصول تعامل دارند.
از سیاست های سازمانی برای مدیریت کانال ها استفاده کنید
Chrome به‌جای ارائه دستورالعمل‌ها و تصمیم‌گیری درباره اینکه از کدام کانال استفاده می‌کند، ابزارهای سازمانی و مدیریتی را نیز ارائه می‌کند تا فعالانه مدیریت کنید که هر کاربر از کدام کانال استفاده می‌کند. این مفید است زیرا سطح آزمایش را بلافاصله از چند فرد به مجموعه ای قطعی از کاربران افزایش می دهد، که به شناسایی شکستگی در اسرع وقت و به روشی قابل ردیابی کمک می کند.
اگر می خواهید از آن سطح کنترل استفاده کنید، در اینجا پیکربندی را توصیه می کنیم:
- کارمندان (کاربران برنامه) : برای به حداقل رساندن خطر اختلال، بیشتر کارمندان باید در کانال پایداری باشند که توسط تیم آزمایش کروم کاملاً آزمایش شده است. علاوه بر این، درصد کمی از کاربران (از 5 تا 10٪) می توانند در کانال بتا باشند. این کانال یک پیش‌نمایش 4 تا 6 هفته‌ای از Stable دریافت می‌کند و می‌تواند به سرپرست‌ها کمک کند تا مشکلات احتمالی یک نسخه را کشف کنند، و زمان بیشتری برای رسیدگی به مشکلات قبل از انتشار نسخه برای دیگران فراهم کند.
- بخش فناوری اطلاعات : اعضای بخش فناوری اطلاعات، از جمله خود سرپرست‌های سیستم، می‌توانند در کانال بتا یا برنامه‌نویس باشند تا پیش‌نمایش 4 تا 6 یا 9 تا 12 هفته‌ای از آنچه برای نسخه پایدار Chrome ارائه می‌شود دریافت کنند.
کانال های انتشار بلند مدت
توسعه محصول ممکن است به سرعت برنامه ریزی شده پیش نرود و سرعت انتشار یک ماهه Chrome بسیار زیاد باشد. برای این مورد، Chrome یک کانال پایدار توسعه یافته ارائه می‌کند که به شما امکان می‌دهد به‌روزرسانی‌های ویژگی را کمتر دریافت کنید، اما همچنان رفع‌های امنیتی را دریافت کنید. این کانال هر هشت هفته یکبار به روز می شود.
نمودار زیر نشان می‌دهد که چگونه نقاط عطف مختلف از طریق کانال‌های انتشار مختلف Chrome پیش می‌رود:
- هر دو پایدار و توسعه یافته نسخه های یکسانی را برای چهار هفته اول ارسال می کنند و پس از آن این دو از هم جدا می شوند.
- هیچ کانال بتا توسعه یافته ای وجود ندارد. در عوض، چرخه استاندارد چهار هفته ای بتا برای تثبیت پایداری پایدار و طولانی مدت استفاده می شود. شرکت‌هایی که تصمیم می‌گیرند در استیبل تمدید شده هشت هفته شرکت کنند، باید مانند امروز به اجرای کانال بتا ادامه دهند تا به طور فعال مشکلاتی را که ممکن است بر محیط آنها تأثیر بگذارد شناسایی کنند.
نتیجه
تست بخش مهمی از شرکت‌های توسعه نرم‌افزار برای اطمینان از کیفیت محصولات خود و همچنین گامی مهم برای مدیران سیستم است تا به کارکنان یک سازمان دسترسی به نرم‌افزار با کیفیت بالا و جلوگیری از ایجاد اختلال در فرآیندهای تجاری را انجام دهند.
به منظور موفقیت در اجرای یک گردش کار آزمایشی در سازمان شما، مهم است که همه این طرز فکر مشترک را داشته باشند که کیفیت و بنابراین آزمایش یک ویژگی است.
در این مقاله، روش‌های مختلفی را برای ادغام بهترین روش‌های آزمایش در سازمان شما بررسی کرده‌ایم، برای بررسی عمیق ابزارهای آزمایشی موجود، مقاله ابزارهای Chrome برای آزمایش بدون اصطکاک و خودکار را بررسی کنید.
برای راهنمایی عملی برای آزمایش، از ابتدا تا انتها، دوره اخیر تست یادگیری و تست بهترین شیوه های اتوماسیون را در web.dev نیز بررسی کنید.