آزمایش با یک اشکال در سر من (از نوع نرم افزار نیست)

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

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

نکات مثبت Inner Bug: "آیا مطمئن هستید که همه چیز را بررسی کرده اید؟"

این شما را وادار می کند تا حتی به ساده ترین کارها با دقت و توجه به جزئیات نزدیک شوید.

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

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

این اشکال کوچک مزاحم به من اجازه می دهد تا خطاهای غیر ضروری را پیدا کنم و محصول را قابل اعتمادتر کنم

هنگامی که طرح آزمایشی را انجام دادم، این مشکل ساز کوچک شروع به پرتاب ایده هایی می کند، "اگر مشتری از اندازه فونت بزرگتر یا سیستم عامل قدیمی استفاده کند چه؟"

به لطف آن، من آزمایش های خود را به طور کامل مستند می کنم و اغلب فیلم ها و اسکرین شات ها را در گزارش های خود قرار می دهم.

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

در این یادداشت خود انعکاسی، اجازه دهید به جنبه‌های منفی این صدای درونی برویم

من را بیشتر مضطرب می کند، اغلب بدون دلیل موجه

گاهی اوقات این اتفاق پس از خراب شدن می افتد، اما مواقعی نیز وجود دارد که صدای Little Bug بدون هیچ دلیلی بلند می شود. در چند مورد، حتی بعد از اینکه به رختخواب می رفتم، من را تنها نمی گذاشت، و در نهایت برای خودم یادداشت می کردم که چه چیز دیگری را باید بررسی کنم.

اغلب باعث می شود وقتم را روی موارد آزمایشی بسیار پیچیده تلف کنم

این نتیجه مستقیم نکته اول است: اضطراب عجیب ترین و کابوس وارترین سناریوها را در ذهن من ایجاد می کند. در حال حاضر، آنها انتقادی به نظر می رسند، اما با نگاهی به گذشته، اغلب چیزی شبیه به "اگر برفک در درخت کاج زیر ماه سوت بزند، چه می شود؟"

من را از تمرکز روی کارهای دیگر باز می دارد

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

پس چگونه می توان از این باگ به نفع خود استفاده کرد و چگونه از تصرف آن جلوگیری کرد؟

اولین چیز

چیزی که وقتی در مورد نکات منفی می نوشتم به ذهنم خطور کرد - و چیزی که مثل یک مانترا تکرار می کنم - این است: آزمایش جامع یک افسانه است. همیشه باگ وجود خواهد داشت.

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

به خصوص در دنیایی که دائماً در حال تغییر است.

این چیزی است که شما فقط باید بپذیرید و ادامه دهید.

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

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

با این حال آسمان سقوط نکرد. کار ادامه یافت، و همه ما توجه دقیق‌تری به مناطقی داشتیم که قبلاً در آن‌ها دچار لغزش شده بودیم.

مورد دوم

من برای خاموش کردن آزاردهنده Checker-Bug در حال پیاده‌سازی تکنیک‌های طراحی آزمایشی بودم: جداول تصمیم و نمودارهای انتقال حالت.

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

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

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

سوم،

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

ساده، شاید حتی واضح، اما مانند یک جذابیت عمل می کند.

و چهارمی

راه برای آرام کردن مغزم ارزیابی اثربخشی و خطرات بود. وقتی ایننر باگ شروع به زمزمه کردن در گوشم کرد، «چند مورد آزمایشی دیگر را بررسی کنید»، رهبر تیمم را به خاطر می‌آورم و سه سؤال می‌پرسیدم:

• چقدر طول خواهد کشید؟
• چه سودی خواهد داشت؟
• احتمال اینکه این موضوع چیز مهمی را آشکار کند چقدر است؟

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

تصور کنید در حین انجام چنین آزمایشاتی باگ پیدا می کنید: چه اولویتی دارد؟ با توجه به مراحل خاص برای بازتولید، حتی یک تصادف می تواند یک اولویت جزئی اختصاص داده شود.

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

در حال اتمام (امیدوارم)

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

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