نحوه کنترل کیفیت QA نرم افزار در آزمایشگاه های Blue Label

بسیاری از مشاغل فرآیندی را طی می کنند که قبل از حمل محصولات به فروشگاه های سراسر کشور یا جهان انجام می شوند – این مسئله چندان تعجب آور نیست ، اما QA نرم افزار تقریباً یکسان است. هنگامی که شما یک نرم افزار اعم از یک برنامه تلفن همراه یا دیگر برنامه ها را می سازید ، هدف اول این است که عناصر طراحی را از آنجا شروع کنید ، از عملکرد برنامه مطابق هدف استفاده می کنید ، به این معنی که هم “درست به نظر می رسد” و هم “درست رفتار می کند” بسیار شبیه به ساخت یک محصول فیزیکی.

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

برخلاف فرآیند QA که محصولات فیزیکی تحمل می کنند ، QA نرم افزار تلاشی چند وجهی است که برای ارزیابی صحیح محصولات دیجیتالی از چند زاویه به بیش از یک مجموعه چشم نیاز دارد. هر شرکت توسعه دهنده نرم افزار کمی متفاوت است اما هدف نهایی یکسان است. بنابراین در اینجا ، ما قصد داریم یک نمای کلی از نحوه برخورد ما با روند QA نرم افزار مورد استفاده در آزمایشگاه های Blue Label ارائه دهیم.

ساختار تیم QA ما

QA یک کار یا شغل واحد در Blue Label نیست: شامل چندین فعالیت انجام شده توسط اعضای مختلف تیم در طول زندگی یک پروژه است. با این حال ، در هر پروژه توسعه ، همیشه حداقل یک نفر وجود دارد که تنها وظیفه او اطمینان از کیفیت کالای تحویل داده شده پاسخگوی نیاز مشتری ما است ، یعنی مهندس QA.

در آزمایشگاه های Blue Label ، ما مهندسان QA کاملاً مستقل استخدام می کنیم که جدا از تیم توسعه ما عمل می کنند. هدف اصلی آنها این است که اطمینان حاصل کنند عملکرد به درستی پیاده سازی شده است ، هیچ رگرسیونی وارد نمی شود و وضعیت کلی کیفیت در نرم افزار حفظ می شود.

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

کمی در مورد اتوماسیون QA در مقابل بررسی دستی

خالصان مدرن اغلب می گویند شما باید همه چیز را از جمله آزمایش QA به طور خودکار انجام دهید ، اما در واقع ، وقتی در حال ساخت MVP یا اولین نسخه های یک محصول هستید ، آزمایش خودکار چندان مفید نیست. در واقع ، این هزینه مهندسی قابل توجهی را به همراه دارد. نوشتن کد اتوماسیون بار مهندسی شما را بسیار افزایش می دهد ، بدین معنا که هر بار که عملکرد را تغییر می دهید نه تنها باید کد برنامه را تغییر دهید بلکه کد اتوماسیون را نیز تغییر دهید.

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

روند QA نرم افزار ما

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

قلب فرآیند توسعه سیستم فروش بلیط ما JIRA است – هر ویژگی یا اشکالی که تیم توسعه دهنده روی آن کار کرده است به عنوان بلیط Story ، Task یا Bug در JIRA وجود دارد. JIRA به عنوان نقطه اصلی کنترل برای درک اینکه تیم توسعه روی چه چیزی کار می کند ، چه چیزی منتشر می شود و QA بر اساس بلیط های موجود در سیستم قرار دارد ، عمل می کند.

روند QA نرم افزار ما می تواند به چندین دستورالعمل تقسیم شود. موارد زیر مبانی نحوه برخورد ما با این عملکرد در آزمایشگاه های Blue Label است.

تست واحد

قبل از اینکه تیم توسعه ما سازه ای را برای تأیید به تیم های QA ما منتقل کند ، توسعه دهندگان برای اطمینان از اعتبار سنجی اساسی ورودی و خروجی ، مجموعه ای از آزمایشات واحد را بر روی اجزای آنها انجام می دهند. به طور کلی ، ما توسعه دهندگان خود را برای آزمایش واحدهای دستی سناریوهایی که قبلاً مشخص شده اند و به عنوان خط اول دفاع طراحی شده اند ، انجام می دهیم. هنگامی که تیم توسعه آزمایش واحد دستی خود را به پایان رساند ، آنها تمام بلیط های JIRA را که در این نسخه برطرف شده یا برطرف شده اند به وضعیت “آماده برای تست” منتقل می کنند و سپس اسناد یادداشت انتشار نسخه داخلی ما را به روز می کنند ، به طور صریح تمام بلیط های JIRA آماده را لیست می کنند برای تأیید

هنگامی که توسعه دهندگان در محیط آزمایش (که ما از آن به عنوان جعبه ماسه یا مرحله بندی یاد می کنیم) ساختاری را منتشر کردند ، تیم QA ما کار آنها را انجام می دهد.

مرحله 1: تست دود. بلافاصله پس از انتشار ساخت تیم توسعه ، اما قبل از عزیمت به شب ، تیم های QA مجموعه ای از آزمایشات اعتبار سنجی پایان به پایان را انجام می دهند تا اطمینان حاصل کنند که ساخت به طور اساسی شکسته نشده است و تیم QA می تواند بدون کار بیشتر ادامه دهد . اگر یک ساخت شکسته شود و بنابراین توسط تیم QA رد شود ، توسعه دهندگان یک شب طولانی را سپری می کنند زیرا باید قبل از ارسال مجدد ساخت ، هر مشکلی را پیدا کنند حل کنند.

مرحله 2: آزمایش ویژگی و اعتبار سنجی. به محض اینکه تست ساخت دود پاک شد ، تیم QA با آزمایش یک مجموعه کامل از موارد تست دستی ، برای آزمایش هر داستان کاربر و همچنین هر گونه اشکال برگشتی در نسخه ، کار خود را آغاز می کند. تیم QA ما ، زودتر از موعد ، برنامه QA خود را با استفاده از یک افزونه به نام Zephyr در آنچه که “برنامه آزمون” در JIRA نامیده می شود ، سازمان می دهد. همانطور که مهندس QA از طریق طرح آزمایشی خود پیش می رود ، آنها پرونده آزمایشی مرتبط Zephyr را کامل مشخص می کنند که سپس توسط بلیط داستان اصلی در JIRA منعکس می شود.

مراحل بعدی: انتقال پروژه به PM

هنگامی که تیم های QA ما هر یک از بلیط ها را در یک نسخه بررسی و تأیید کردند ، آنها بلیط مربوط به JIRA را به وضعیت “Verified (By QA)” در JIRA منتقل می کنند که در آن زمان بلیط ها به صفحه PM منتقل می شوند. برای مواردی که از اعتبار سنجی کیفیت عبور نمی کنند ، آنها با وضعیت “QA Fail” به تیم توسعه باز می گردند.

PM به عنوان آخرین خط دفاعی از نظر کنترل کیفیت قبل از انتشار سازه ها برای مشتری عمل می کند. یک PM با انجام یک سری اعتبارسنجی اساسی بر اساس عملکرد مورد نظر ، ساخت چرخش را بر عهده خواهد گرفت.

این یک گام بسیار مهم است زیرا در نهایت نخست وزیر مسئول اطمینان از تحقق روح کلی آنچه در نظر گرفته شده بود ساخته شده است. در اینجا ، آنها همچنین “پیدا کردن مسائل مربوط به پایان” را با یافتن عناصری مانند هجی کردن نادرست ، دستور زبان و سایر اختلافات جزئی بصری که ممکن است از طریق شبکه QA سرزده باشند ، شناسایی می کنند.

بلیط ها پس از گذراندن اعتبار PM ، به حالت “انجام شده” در JIRA منتقل می شوند و به طور موثر چرخه حیات بلیط را تکمیل می کنند.

مرحله نهایی نرم افزار QA: تست پذیرش کاربر (UAT)

سرانجام ، ساختها به مشتری منتقل می شوند ، معمولاً از طریق برنامه iTunes External Beta برای برنامه های iOS یا از طریق کانال آزمایش بتا Google Play برای دستگاه های Android.

در طی بخش QAT نرم افزار UAT ، PM با مشتری کار می کند تا هر مشکلی را که مشتری پیدا کرده شناسایی و ثبت کند. هر مشکلی که پیدا شد به JIRA متصل شده و سپس در کنار سایر بلیط های برجسته توسط تیم توسعه دهنده مورد استفاده قرار می گیرد. ما دوست داریم از افزونه هایی مانند Bugsee استفاده کنیم که با استفاده از یک حرکت تکان دهنده برای ایجاد صفحه گزارش جدید اشکال ، برای کاربران نهایی بسیار آسان است که از داخل برنامه اشکالات را وارد کنند.

در Blue Label ، ما می خواهیم تعداد موضوعات موجود در UAT را به حداقل برسانیم ، زیرا ترجیح می دهیم اشتباهات خود را دریافت کنیم تا اینکه مشتریان ما آنها را پیدا کنند. هر بلیط JIRA که در نتیجه UAT باز می شود به همین ترتیب ثبت می شود و حفظ می شود تا بتوانیم بعداً دوباره آنها را مرور کنیم. ما به طور دوره ای این داده ها را بررسی می کنیم تا اطمینان حاصل کنیم که مواردی را که لیز خوردن آنها از طریق کنترل های QA در نقاطی که توسط مشتری پیدا شده اند ، به حداقل می رسانیم.

Blue Label Labs نرم افزاری عالی ایجاد می کند ، بخشی از آن به دلیل کیفیت عالی QA است

در پایان روز ، روند QA نرم افزار ما همان چیزی است که به ما امکان می دهد در شغل خود باقی بمانیم. اگر ما دائماً درگیر طراحی مجدد و تعدیل کد معیوب بودیم ، مشتریان ما نمی خواهند با ما کار کنند.

با استفاده از تجزیه و تحلیل تصویر بزرگ از بازار و آزمایش متمرکز ، تیم طراحان و مهندسان راه حل محور ما نمونه های اولیه و در نهایت محصولات نهایی را برای بازارهای دیجیتال امروز تولید می کنند.