تنفيذ اختبار قبول المستخدم والاعتماد
تنفيذ اختبار قبول المستخدم (UAT Execution) هو الجزء من اختبار قبول المستخدم الذي يعمل فيه المستخدمون المقصودون على سيناريوهات UAT المُعدّة مسبقاً على الإصدار المرشّح (Release Candidate)، بينما يسجّل الفريق كل نتيجة وكل مشكلة يثيرها المستخدمون. أما الاعتماد (Sign-off) فهو القرار المسجَّل الذي يلي ذلك: يقبل مالك عملية العمل النظام، أو يقبله بشروط، أو يرفضه، بناءً على الأدلة التي أنتجتها الجلسات.
مثال: في شركة غير التي تناولها درس تخطيط اختبار قبول المستخدم، يقضي عشرة من الموظفين والمديرين وموظفي المالية ثلاثة صباحات في تقديم مطالبات المصروفات واعتمادها وصرفها على بيئة UAT. ومن بين تسع مشكلات أثاروها، كانت اثنتان منها عيبين. أُصلح أحدهما وأُعيد اختباره أثناء UAT؛ أما الآخر، وله حل بديل، فوقّع المدير المالي بشأنه قبولاً مشروطاً بإصلاحه خلال أسبوعين.
لماذا يهم
حتى السيناريوهات المخطط لها جيداً لا تؤدي غرضها في جلسات سيئة الإدارة: يتّبع المستخدمون المختبِر بدلاً من أداء عملهم الحقيقي، وتضيع المشكلات أو تختلط بالرغبات، ويُبنى القرار على الانطباعات. فيُطلَق المنتج بفجوات لم تقبلها جهة العمل عن علم.
وسجل الاعتماد يحمي الجميع: فهو يخبر جهة العمل بدقة بما قبلته وبالمخاطر المتبقية، ويمنح فريق التسليم نهاية واضحة لاختبار القبول، ويمنح المختبِر جواباً قائماً على الوقائع حين يسأل أحدهم لاحقاً: من قرّر أن الإصدار جاهز؟
إدارة جلسات UAT
جلسة UAT فترة زمنية محددة، غالباً نصف يوم، ينفّذ فيها فريق من المستخدمين مجموعة مخططاً لها من السيناريوهات. وقبل الجلسة الأولى تأكّد من معايير الدخول الواردة في خطة UAT: استوفى اختبار النظام معايير الخروج الخاصة به، وبيئة الاختبار والحسابات والبيانات جاهزة. فالبناء (Build) غير المستقر يهدر أندر الموارد في UAT: وقت المستخدمين.
وتسير كل جلسة على الإيقاع نفسه: إحاطة قصيرة تشرح نطاق اليوم، وطريقة تسجيل النتائج وإثارة المشكلات، ومن يجيب عن الأسئلة. ثم يؤدي المستخدمون العمل بأنفسهم بينما يراقب الفريق ويساعد. وفي الختام مراجعة تؤكد النتائج وتستعرض المشكلات الجديدة وتخطط للجلسة التالية. وإذا أوقف عيب حاجب أو عطل في البيئة معظم السيناريوهات، فعلّق الجلسة بدلاً من ترك المستخدمين ينتظرون، واستأنفها حين تتحقق معايير الاستئناف المتفق عليها، مثل بناء مُصلَح اجتاز اختبار الدخان (Smoke Test)؛ ويشرح درس معايير الدخول والخروج كيف تُكتب معايير التعليق والاستئناف.
- مستخدمو الأعمال: ينفّذون السيناريوهات ويحكمون هل تدعم النتيجة عملهم.
- منسّق UAT، وغالباً قائد الاختبار: يدير الجدول وسجل النتائج والمراجعة الختامية.
- المختبِر ميسّراً (Facilitator): يراقب، ويساعد المستخدمين على تسجيل ما رأوه، ويعيد إنتاج المشكلات، دون أن يستولي على لوحة المفاتيح.
- مالك المنتج أو محلل الأعمال، ومعه مطوّر عند الطلب: يجيبون عن الأسئلة حول السلوك المقصود، ويصلحون مشكلات البيئة بسرعة.
تسجيل ما يجده المستخدمون وفرزه
سجّل كل ملاحظة مشكلةً (Issue) بكلمات المستخدم قبل أن تقرر ما هي. ويسمّي ISTQB كل حالة تحيد عن المتوقع شذوذاً (Anomaly)، وينبّه منهج المستوى التأسيسي إلى أن الشذوذ المُبلَّغ عنه قد يتبيّن أنه عيب حقيقي أو شيء آخر، مثل طلب تغيير. دوّن السيناريو والمستخدم والبناء، وما فعله وما توقعه وما رآه، والدليل (لقطة شاشة أو رقم السجل)، والأثر على العمل بكلماته. ثم يحوّل المختبِر كل عيب مؤكد إلى تقرير خطأ (Bug Report) كامل.
افرز المشكلات الجديدة يومياً على الأقل مع مالك المنتج وممثل عن جهة العمل: ففي UAT تتحدد الخطورة والأولوية بحسب الأثر على العمل، فلا بد من مشاركة جهة العمل. وتأخذ كل مشكلة تصنيفاً واحداً:
- عيب (Defect): لا يستوفي النظام معيار قبول أو متطلباً متفقاً عليه؛ فيدخل دورة حياة العيب.
- طلب تغيير (Change Request): يعمل النظام كما اتُّفق، لكن المستخدمين يريدون الآن شيئاً مختلفاً؛ فيذهب إلى قائمة المهام المتراكمة (Backlog) أو إلى ضبط التغيير، ولا يُعدّ السيناريو فاشلاً بسببه.
- مشكلة تدريب أو توثيق: النظام صحيح، لكن المستخدمين لم يجدوا شيئاً أو لم يفهموه؛ فتذهب إلى دليل المستخدم أو إلى التدريب.
- مشكلة بيئة أو بيانات اختبار: الخلل في إعداد UAT لا في المنتج؛ أصلحه وأعد تشغيل السيناريو، فقد كان محجوباً لا فاشلاً.
- مكرر أو سؤال: اربطه بالأصل أو أغلقه مع الإجابة، ليرى المستخدم ما حدث لمشكلته.
القرار: مقبول أو مقبول بشروط أو مرفوض
ينتهي UAT بقرار يتخذه مالك عملية العمل المسمّى في خطة UAT، وفق معايير الخروج المتفق عليها فيها، مثل: تنفيذ كل السيناريوهات المخطط لها، وعدم وجود عيب مفتوح بخطورة حاجب (Blocker) أو حرج (Critical)، واستيفاء كل معيار قبول أو تغطيته بشرط متفق عليه. ويقدّم المختبِر الأدلة والتوصية، أما القرار فلجهة العمل.
القبول المشروط (Conditional Acceptance) يعني أن جهة العمل تقبل الآن، لكن القبول يتوقف على أمور لم تحدث بعد. وهو يناسب العيوب المفتوحة التي لها حل بديل وأثر محدود. ولا يناسب عادةً قاعدة عمل حرجة معطّلة، أو متطلباً قانونياً، أو سلامة البيانات، أو الأمان: فهذه تعني في الغالب الرفض حتى تُصلَح.
| # | من | إلى | الحدث أو القرار |
|---|---|---|---|
| 1 | قيد اختبار القبولالبداية | مقبولالنهايةنجاح | القرار: كل معايير القبول مستوفاة، والمشكلات المتبقية ثانوية ومسجّلة |
| 2 | قيد اختبار القبولالبداية | مقبول بشروطتنبيه | القرار: للعيوب المفتوحة حل بديل، ولكل شرط مالك وموعد وطريقة تحقق |
| 3 | قيد اختبار القبولالبداية | مرفوضفشل | القرار: معيار حرج غير مستوفى ولا حل بديل مقبولاً |
| 4 | مرفوضفشل | قيد اختبار القبولالبداية | بناء جديد فيه الإصلاحات: اختبار التأكيد والانحدار، ثم السيناريوهات الفاشلة مجدداًمسار بديل |
| 5 | مقبول بشروطتنبيه | مقبولالنهايةنجاح | تحقّقت كل الشروط وسُجّل إغلاقها |
| 6 | مقبول بشروطتنبيه | مرفوضفشل | فات شرطٌ موعده، فقرّر مالك عملية العمل من جديد سحب القبول بدلاً من الاتفاق على موعد جديدمسار بديل |
| 7 | قيد اختبار القبولالبداية | معلَّق | عيب حاجب أو عطل في البيئة يوقف معظم السيناريوهاتمسار بديل |
| 8 | معلَّق | قيد اختبار القبولالبداية | تحققت معايير الاستئناف: بناء مُصلَح أو بيئة مستعادةمسار بديل |
يُسجَّل كل قرار، بما فيه الرفض، مع البناء والمشكلات المفتوحة واسم صاحب القرار.
- مقبول: كل معايير القبول مستوفاة، والمشكلات المتبقية ثانوية ومسجّلة ومخطط لها.
- مقبول بشروط: يسمّي كل شرط المشكلةَ، والحلَّ البديل حتى إغلاقها، والمالكَ، والموعدَ أو الإصدار المستهدف، ومن يتحقق من الإغلاق وكيف.
- مرفوض: يذكر السجل المعايير غير المستوفاة وما يجب أن يحدث قبل استئناف UAT، وهو عادةً بناء جديد فيه الإصلاحات، واختبار التأكيد والانحدار، ثم إعادة السيناريوهات الفاشلة.
- لا يتحوّل القبول المشروط إلى قبول كامل تلقائياً: سجّل لحظة التحقق من كل الشروط، وإذا فات شرطٌ موعده يقرّر مالك عملية العمل من جديد: إما الاتفاق على موعد جديد وإما سحب القبول.
أدلة الاعتماد: ما يتضمنه السجل
سجل الاعتماد، سواء كان وثيقة أو موافقة في أداة، يحفظ القرار والوقائع التي بُني عليها. وهو يتضمن أهم البنود التي يذكرها منهج ISTQB للمستوى التأسيسي لتقرير إتمام الاختبار (ملخص، وتقييم وفق معايير الخروج، والانحرافات عن الخطة، والعيوب غير المُصلَحة، والمخاطر المتبقية)، ويضيف إليه القرار. اكتبه بحيث يفهم من لم يحضر، بعد أشهر، ما الذي قُبل ولماذا.
- بيانات التعريف: النظام، والإصدار، والبناء المعتمد بالضبط، والبناء الذي جاءت منه كل نتيجة، والبيئة، والتواريخ.
- التغطية: السيناريوهات المخطط لها والمنفّذة والناجحة والفاشلة والمحجوبة، متتبَّعةً إلى معايير القبول، وكل ما لم يُختبر مع السبب.
- المشاركون: أسماء المستخدمين الذين نفّذوا السيناريوهات وأدوارهم.
- المشكلات: العيوب المفتوحة بخطورتها وأولويتها وحلّها البديل، وأين ذهبت طلبات التغيير وبنود التدريب.
- القرار: النتيجة، وكل شرط كاملاً، واسم صاحب القرار ودوره، والتاريخ، والموافقة نفسها.
- الأدلة: روابط سجلات الجلسات ولقطات الشاشة وسجل المشكلات، مع حجب البيانات الشخصية قبل المشاركة.
جرّبها: المتطلبات ← حالات اختبار جرّبها: تحويل الصور إلى PDF جرّبها: تنقيح PDF (حجب المعلومات)
مثال تطبيقي: اعتماد وحدة مطالبات المصروفات
يتناول هذا المثال شركة أخرى وإصداراً آخر، لا الخطة التي رأيتها في درس تخطيط اختبار قبول المستخدم. يضيف الإصدار 2.3 من نظامها المالي وحدة لمطالبات المصروفات، وفي خطة UAT الخاصة بها ستة معايير قبول، و18 سيناريو، وثلاث جلسات صباحية (من S1 إلى S3) يشارك فيها خمسة موظفين، ومديران مباشران، ومدير الحسابات، وموظفا حسابات. وصاحب القرار هو مديرها المالي.
في S1 كان السيناريوهان UAT-07 وUAT-08 محجوبين: حسابات المديرين في UAT تفتقر إلى صلاحية الاعتماد (ISS-03، مشكلة بيانات اختبار). وبعد إصلاح الحسابات نُفّذ السيناريوهان في S2، فكشف UAT-08 العيب ISS-06 بخطورة حرج (Critical): المطالبات التي تتجاوز 5,000 ريال تتخطى اعتماد مدير الحسابات. وأصلحه البناء rc3، وفي S3 نجح السيناريو في اختبار التأكيد، ونجحت مجدداً سيناريوهات الاعتماد والصرف، وهي التي قد يمسّها الإصلاح، بوصفها اختبار انحدار على rc3، وهو البناء الذي سيُشغَّل فعلياً.
المجموع تسع مشكلات: عيبان، وطلب تغيير، وبندا تدريب، ومشكلة بيانات، ومكرران، وسؤال أُجيب عنه. وبقي ISS-07 مفتوحاً: تُرفض صور الإيصالات التي تزيد على 5 MB مع أن AC-2 يسمح بحجم يصل إلى 10 MB. ويستطيع المستخدمون ضغط الصورة، لذا يوصي قائد ضمان الجودة بالقبول المشروط. ويُحوَّل السجل إلى ملف PDF ويوقّعه المدير المالي.
سجل الاعتماد (مقتطف): مطالبات المصروفات 2.3
البناءات: S1-S2 على 2.3.0-rc2؛ وS3 على 2.3.0-rc3 (إعادة الاختبار والانحدار)
بناء التشغيل الفعلي: 2.3.0-rc3، على بيئة اختبار القبول
المشاركون: 5 موظفين، ومديران مباشران، ومدير الحسابات، وموظفا حسابات
السيناريوهات: 18 مخطط لها، و18 منفذة، و17 ناجحة، و1 فاشل، و0 محجوب
AC Scenarios Result Evidence
AC-1 UAT-01..UAT-03 Met session log S1
AC-2 UAT-04..UAT-06 Not met UAT-06 failed, ISS-07 (Major)
AC-3 UAT-07..UAT-10 Met ISS-06 (Critical) fixed in rc3, retest S3
AC-4 UAT-11..UAT-13 Met session log S2
AC-5 UAT-14..UAT-16 Met bank file totals checked, S2; regression S3
AC-6 UAT-17..UAT-18 Met report exports, S3
مفتوح: ISS-07 (رئيسي، Major): تُرفض صور الإيصالات فوق 5 MB؛ الحل البديل: ضغط الصورة
مشكلات أخرى: طلب تغيير واحد إلى قائمة المهام المتراكمة، وبندا تدريب في الدليل المختصر
القرار: مقبول بشروط في 7 مايو 2026، في نهاية S3
التوقيع: خالد الحربي، المدير المالي
الشرط: إصلاح ISS-07 في 2.3.1 خلال أسبوعين من التشغيل الفعلي (المالك: قائد التطوير)؛
يتحقق منه موظف حسابات بإعادة تشغيل UAT-06؛ ويؤكد المدير المالي الإغلاقأخطاء شائعة
- إجراء عرض توضيحي بدلاً من UAT: يقود المختبِر السيناريوهات والمستخدمون يتفرجون، فلا يُختبر حكم المستخدمين أنفسهم أبداً.
- تسجيل كل ملاحظة من المستخدم عيباً، أو إسقاط ما ليس عيباً بصمت؛ فلطلبات التغيير ومشكلات التدريب مسارها الخاص، ومن حق المستخدم أن يرى ما حدث لمشكلته.
- كتابة شروط غامضة مثل «يُصلَح لاحقاً»: فالشرط الذي لا مالك له ولا موعد ولا خطوة تحقق لا يُغلق أبداً.
- اعتماد بناء غير الذي سيُشغَّل فعلياً، أو تغيير البناء بعد الاعتماد دون إعادة تشغيل السيناريوهات المتأثرة.
- عدّ رسالة بريد عابرة تقول «يبدو جيداً» اعتماداً، أو ترك المختبِر يوقّع نيابةً عن جهة العمل؛ فالسجل يجب أن يسمّي صاحب القرار والبناء والنطاق والمشكلات المفتوحة.
من منظور ضمان الجودة
المختبِر أثناء UAT ميسّر وحافظ للسجل. أبقِ سجل النتائج وسجل المشكلات محدَّثين في كل جلسة، ودوّن البناء الذي جاءت منه كل نتيجة، واكتب تقارير أخطاء كاملة من ملاحظات المستخدمين في اليوم نفسه، واعرض كل مشكلة جديدة في الفرز اليومي مع مالك المنتج وجهة العمل. واحمِ وقت المستخدمين: افحص البيئة والبيانات قبل كل جلسة، وعلّق الجلسة مبكراً حين يعترضهم عائق.
وفي النهاية أعدّ سجل الاعتماد وتوصية مبنية على الوقائع: ما الذي غُطّي، وما الذي فشل، وما الذي ما زال مفتوحاً، وماذا يعني ذلك لجهة العمل. وتأكد أن صاحب القرار يفهم كل خطر متبقٍّ قبل التوقيع، ثم تابع كل شرط حتى إغلاقه وتحقق منه، واحفظ السجل مع أدلته حيث يجده مدقق أو عضو جديد في الفريق.
تمرين عملي
افرز سجل مشكلات UAT واقترح قراراً
تُجري عيادةٌ اختبار قبول المستخدم للإصدار 1.4 من نظام حجز المواعيد لديها، وصاحب القرار هو مدير عمليات العيادة. استخدم سجل المشكلات أدناه، المكتوب بعد جلسة UAT الثانية، وافترض أن ISS-01 وISS-05 ما زالا مفتوحين عند انتهاء UAT.
حجز العيادة 1.4، البناء 1.4.0-rc2، سجل مشكلات UAT بعد الجلسة S2
AC-1 الحجز، AC-2 الإلغاء، AC-3 إعادة الجدولة، AC-4 تذكير SMS
ISS-01 UAT-03 موظف الاستقبال: حجز مريض عائد يُنشئ له سجلاً ثانياً
ISS-02 UAT-05 طبيب: يريد عرض عمر المريض بجانب اسمه في عرض اليوم
ISS-03 UAT-02 موظف الاستقبال: لم يجد «إلغاء»؛ إنه تحت قائمة «المزيد»
ISS-04 UAT-07 موظف الاستقبال: لم يصل تذكير SMS؛ أرقام مرضى UAT غير صالحة
ISS-05 UAT-06 موظف الاستقبال: بعد إعادة الجدولة يبقى الموعد القديم محجوزاً
ISS-06 UAT-04 موظف الاستقبال: سجل ثانٍ مرة أخرى، لمريض آخر- صنّف كل مشكلة: عيب، أو طلب تغيير، أو مشكلة تدريب أو توثيق، أو مشكلة بيئة أو بيانات، أو مكرر.
- لكل عيب، اقترح خطورة وسمِّ معيار القبول الذي يمسّه.
- أوصِ بقرار لنهاية UAT مع أسبابك.
- افترض أن ISS-01 أُصلح بعد ذلك وأُعيد اختباره؛ اكتب شروط القبول مع بقاء ISS-05 مفتوحاً.
إظهار الإجابة النموذجية
ISS-01: عيب، حرج (Critical)، يمسّ AC-1: يحصل المريض العائد على سجل ثانٍ، فينقسم تاريخه الطبي، ولا يوجد حل بديل موثوق. ISS-06: مكرر للمشكلة ISS-01؛ اربطه بها، فظهوره مع مريض ثانٍ يثبت أن العيب لا يخص سجلاً واحداً. ISS-05: عيب، رئيسي (Major)، يمسّ AC-3: كل إعادة جدولة تُضيّع موعداً متاحاً، لكن الاستقبال يستطيع تحريره يدوياً.
ISS-02: طلب تغيير (لم يُطلب قط عرض العمر في عرض اليوم)، يذهب إلى قائمة المهام المتراكمة. ISS-03: بند تدريب للدليل المختصر، وملاحظة عن قابلية الاستخدام لمالك المنتج. ISS-04: مشكلة بيانات اختبار؛ حمّل أرقام اختبار يتحكم فيها الفريق وأعد تشغيل UAT-07، الذي كان محجوباً لا فاشلاً.
القرار: الرفض ما دام ISS-01 مفتوحاً، لأن AC-1 غير مستوفى في سلامة سجلات المرضى ولا حل بديل. وبعد الإصلاح: اختبار التأكيد للسيناريوهين UAT-03 وUAT-04، والانحدار لسيناريوهات الحجز، وإعادة تشغيل UAT-07.
شروط ISS-05: الحل البديل اليدوي موجود في الدليل المختصر، وأُحيط موظفو الاستقبال به قبل التشغيل الفعلي؛ ويُطلق قائد التطوير الإصلاح في 1.4.1 بموعد متفق عليه؛ ويعيد موظف استقبال تشغيل UAT-06 على 1.4.1؛ ويؤكد مدير العمليات الإغلاق في سجل الاعتماد.
أسئلة شائعة
من يعتمد UAT: المختبِر أم جهة العمل؟
مالك عملية العمل المسمّى في خطة UAT أو في العقد. يُعدّ المختبِر أو قائد ضمان الجودة السجل ويوصي بقرار، وفي بعض المؤسسات يؤكد أيضاً اكتمال السجل، لكنه لا يقبل النظام أبداً نيابةً عن جهة العمل.
هل القبول المشروط هو نفسه القبول مع عيوب معروفة؟
ليس تماماً. يمكن قبول النظام قبولاً كاملاً مع عيوب ثانوية معروفة مسجّلة ومخطط لها. أما القبول المشروط فيعني أن القبول نفسه يتوقف على أمر لم يحدث بعد، مثل إصلاح في موعد محدد، ويُتابَع كل شرط ويُتحقق منه قبل أن يصبح القبول نهائياً.
هل يحتاج الاعتماد إلى توقيع بخط اليد؟
لا يوجد شكل واحد مطلوب: وثيقة موقّعة، أو موافقة في أداة إدارة الاختبار أو أداة سير العمل، أو موافقة محفوظة بالبريد الإلكتروني، كلها قد تصلح. المهم أن يحدد صاحب القرار والقرار والبناء والنطاق، وأن يمكن العثور عليه لاحقاً. وقد تفرض العقود والبيئات الخاضعة للتنظيم شكلاً معيناً؛ فالتزم به.
ماذا لو تغيّر البناء بعد الاعتماد؟
يغطي الاعتماد البناء الذي اختُبر. ولأي تغيير لاحق، قيّم أثره، وأعد تشغيل سيناريوهات UAT واختبارات الانحدار المتأثرة، وأضف النتيجة وتأكيداً للقرار إلى السجل قبل تشغيل ذلك البناء فعلياً.
المراجع
- ISTQB Certified Tester Foundation Level (CTFL) v4.0المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
- Certified Tester Acceptance Testing (CT-AcT)منهج ISTQB التخصصي لاختبار القبول: اختبار قبول المستخدم والقبول التعاقدي والتنظيمي، واختبارا ألفا وبيتا، وتعاون المختبِرين مع مالكي المنتج ومحللي الأعمال.
- ISTQB Glossaryالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
- ISO/IEC/IEEE 29119-3:2021 — Software and systems engineering — Software testing — Part 3: Test documentationنماذج ومحتوى وثائق الاختبار — سياسة الاختبار واستراتيجيته وخطته وتقارير الحالة والإنجاز وتقارير الحوادث.
تدرّب بأدوات متقن
حوّل قائمة متطلبات مرقّمة إلى حالات اختبار قابلة للتتبّع مع مصفوفة تربط المتطلبات بالاختبارات.
اجمع الصور والمسوحات ولقطات الشاشة بأي صيغة في ملف PDF واحد، صورة في كل صفحة، دون اتصال.
أزل النص والصور من ملف PDF نهائيًا — ارسم مربعات سوداء فيُعاد تصيير الصفحات المنقَّحة بدون المحتوى الذي تحتها.
حوّل ملفات Markdown (md.) إلى PDF في متصفحك: العناوين والقوائم والجداول وكتل الشيفرة والاقتباسات والروابط والصور منسّقة بخطوط مضمّنة.
وقّع ملف PDF برسم توقيعك أو كتابة اسمك أو رفع صورة، ثم ضعه على الصفحة وغيّر حجمه.
للتعمّق أكثر
- فرز العيوب (Defect Triage)كيف تدير فرز العيوب: المشاركون، والإيقاع، وقائمة تحقق لكل عيب، ومصفوفة الخطورة × الأولوية، والإسناد، وتحليل السبب الجذري، والأنماط الخاطئة.
- كيف تكتب تقرير خطأ (Bug Report)ما الذي يحتويه تقرير الخطأ الجيد
- ضمان جودة المنتج من البداية إلى النهايةبوابات الإصدار وإدارة العيوب والأرقام التي تستحق المتابعة
- دورة حياة اختبار البرمجيات (STLC)المرحلة 6 — إغلاق دورة الاختبار (إتمام الاختبار)
تقدّمك في هذا الموضوع
سجّل الدخول لتتابع تقدّمك
علّم الموضوعات مكتملة، وتابع من حيث توقفت، وافتح امتحانات التخصص.