چرخه حیات باگ یا نقص

shape
shape
shape
shape
shape
shape
shape
shape

چرخه عمر باگ در تست نرم افزار

مقدمه :

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

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

نقص یا اشکالات چی هستند؟

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

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

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

خب ، الان وقت آن رسیده تا با چرخه حیات باگ آشنا شوید.

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

چرخه حیات باگ/نقص در جزئیات

چرخه زندگی نقص ، همچنین به عنوان چرخه حیات باگ هم شناخته میشود.

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

نقص در گردش کار

خب وقت آن است که با یک نمودار ساده ، جریان کار چرخه حیات نقص را بیشتر درک کنید.

خب اکنون به تعریف هر یک از این موارد میپردازیم:

New : این اولین حالت نقص ، در چرخه حیات باگ است. هر باگ جدیدی پیدا شود ، در حالت ” new ” قرار میگیرد و در مراحل بعدی چرخه حیات باگ ، اعتبار سنجی و تست بر روی این نقص ها انجام میشود.

Assigned : در این مرحله ، باگی که برای کاربر ایجاد شده ، به تیم نوسعه دهنده اختصاص داده میشود. این مورد توسط سرپرست پروژه یا مدیر تیم تست به یک توسعه دهنده اختصاص داده میشود.

Open : در این بخش ، توسعه دهنده روند تجزیه و تحلیل باگ را شروع میکند و در صورت لزوم برای رفع آن کار میکند. اگر توسعه دهنده احساس کند که نقص درست نیست ، ممکن است به چهار جواب زیر یعنی Rejected ، Referred ، Duplicate ، یا Not a bug منتقل شود.

در مورد این چهار جواب صحبت خواهیم کرد.

Fixed : وقتی برنامه نویسی با ایجاد تغییرات لازم کار رفع باگ را به پایان رساند ، میتواند وضعیت نقص را ” Fixed ” علامت گذاری کند.

Pending Retest : پس از رفع باگ ، توسعه دهنده باگ را از تستر میخواهد که بار دیگر تست کند و تا زمانی که باگ برای تستر همچنان وجود داشته باشد حالت باگ بر روی ” در انتظار بررسی مجدد ” باقی می ماند.

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

Reopen : اگر مشکلی در باگ ادامه پیدا کند ، مجددا برای تست به توسعه دهنده اختصاص می یابد و وضعیت نقص به ” Reopen ” تغییر می یابد.

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

Closed : وقتی باگی/ نقصی وجود نداشته باشد تستر وضعیت آن را به “Closed” در می آورد.

خب ، اکنون در مورد آن چها پاسخ توضیح میدهیم:

Rejected : اگر باگ توسط توسعه دهنده به عنوان یک باگ اصلی در نظر گرفته نشود ، توسط توسعه دهنده به عنوان “Rejected” تغییر می یابد.

Duplicate : اگر توسعه دهنده نقص/باگ را مانند یک نقص/باگ دیگری پیدا کند و مفهوم آنها با همدیگر مطابقت داشته باشد ، توسعه دهنده وضعیت باگ را به “Duplicate” تغییر می یابد.

Deferred : اگر توسعه دهنده احساس کند که باگ از الویت چندانی برخوردار نیست و میتوان در نسخه های بعدی یا موارد دیگر برطرف کند ، میتواند وضعییت باگ را به عنوان “Deferred” تغییر دهد.

Not a Bug : اگر باگ تاثیری در عملکرد برنامه نداشته باشد ، وضعیت نقص به ” Not a bug ” تغییر میکند.

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

چند دستور العمل مهم قبل از شروع کار با چرخه حیات باگ/نقص

  • بسیار مهم است که قبل از شروع کار روی چرخه حیات باگ ، کل تیم به وضوح وضعیت های مختلف باگ را درک کند.
  • چرخه حیات باگ باید به درستی مستند شود تا در آینده از هرگونه سردرگمی جلوگیری شود.
  • اطمینان حاصل کنید که هر فردی که وظیفه ی مربوط به چرخه حیات نقص را بر عهده گرفته است باید مسئولیت خود را برای نتایج بهتر کاملا واضح درک کند.
  • باگ میتواند در هر نقطه از چرخه زندگی توسعه نرم افزار معرفی شود.
  • هرچه زودتر باگ ها شناسایی و برطرف شود ، هزینه کلی پایین تر خواهد آمد.
  • وقتی باگ در همان مراحل اول معرفی برطرف شود ، هزینه کلی پایین خواهد آمد و از کیفیت برنامه کاسته نمیشود.
مشاوره رایگان
0991-1001037
#تست_اپ
#آموزش_تست_اپلیکیشن
#تست_اپلیکیشن
#تست_نرم_افزار
#تست_اپ_اندروید
#تست_اپ_آی_او_اس
#تست_وب_سایت
#تست_نرم_افزار_موبایل
#تستر_کینگ
#تسترکینگ
#تست_سایت
#تست_وبسایت
#تست_وب_سایت
#محمدعماد
#چرخه_حیات_باگ
#چرخه_حیات_نقص
#چرخه_حیات_باگ/نقص

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

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