إدارة مخاطر المشروع
إدارة مخاطر المشروع (Project risk management) هي الطريقة التي يُبقي بها مدير الاختبار اختبارَ الإصدار ممكناً حين تتعثر الأمور في المشروع من حوله. وخطر المشروع (Project risk) حدث غير مؤكد، إن وقع، يؤثر في الجدول الزمني للمشروع أو ميزانيته أو نطاقه، لا في جودة المنتج نفسه. مثال ذلك: قد تتعطل بيئة sandbox المشتركة لدى مزوّد الدفع (بيئة الاختبار التي يتيحها لعملائه) أياماً خلال نافذة الاختبار، فتتوقف كل اختبارات الدفع.
وإدارتها حلقة تستمر طوال الإصدار: صِف كل خطر بدقة، وقيّم احتماله وأثره، واختر الاستجابة، وحدّد له مالكاً واحداً ومحفّزاً عند الحاجة، واحفظه في سجل المخاطر (Risk register)، وراجعه عند نقاط ثابتة، ثم أبلغ عمّا بقي مفتوحاً في اجتماع قرار الإطلاق (Go/No-Go)، حيث يقرّر أصحاب الإصدار هل يُطلَق أم لا.
لماذا يهم
حين يقع خطر مشروع لم يخطط له أحد، يتحمّل الاختبار الضرر في الغالب: تصل البيئة متأخرة أسبوعاً، ولا يتغيّر موعد الإصدار، فتنكمش نافذة الاختبار بصمت. وعندها تُختبر مخاطر المنتج التي كان الاختبار سيخفّضها بعمق أقل، دون أن يقرّر أحد ذلك عن قصد.
أما لمدير الاختبار، فسجل المخاطر يحوّل الشكاوى إلى قرارات: فعبارة «ما زلنا بلا بيانات اختبار» تصبح خطراً مسجّلاً له مالك وموعد نهائي وخطة بديلة، يُرفع ما دام في الوقت متسع للتصرف. وفي اجتماع قرار الإطلاق يبيّن السجل نفسه كيف غيّرت مشكلات المشروع الاختبار، قبل أن يكتشف أحد الفجوة في بيئة الإنتاج.
خطر المشروع ومن أين يأتي
تذكير من دليل الاختبار المبني على المخاطر: يفصل منهج ISTQB للمستوى التأسيسي (CTFL v4.0) بين مخاطر المنتج (Product risks)، أي الطرق التي قد يخذل بها المنتج مستخدميه (إجمالي خاطئ، أو تسرّب بيانات)، ومخاطر المشروع، أي الطرق التي قد يعجز بها المشروع عن التسليم في الموعد أو ضمن الميزانية أو بالنطاق الكامل. يخفّض الاختبار خطر المنتج مباشرة، لأن الاختبار قد يكشف الإخفاق الذي نخشاه قبل أن يصادفه المستخدمون؛ أما زيادة حالات الاختبار فلا تجعل بيئة متأخرة تصل. ويُقيَّم النوعان بالاحتمال والأثر، اللذين يعطيان مستوى الخطر، ويُحفظان في قائمتين منفصلتين لكل منهما مالكون مختلفون.
اكتب كل خطر بصيغة السبب والحدث والأثر حتى تجد الاستجابة ما تعمل عليه: بيئة sandbox الخاصة بالدفع مشتركة مع عملاء آخرين (السبب)، فقد لا تكون متاحة في نافذة اختبارنا (الحدث) فتتوقف اختبارات الدفع (الأثر). أما الحدث المؤكد، مثل موعد إطلاق ثابت، فليس خطراً بل قيدٌ (Constraint) تخطط حوله.
ويصنّف المنهج مخاطر المشروع إلى مشكلات تنظيمية، ومشكلات تتعلق بالأفراد، ومشكلات تقنية، ومشكلات تتعلق بالمورّدين. وفي الاختبار تظهر عادةً في أربعة مواضع:
- البيئات: بيئة staging مشتركة مع فريق آخر، أو بيئة اختبار لا تشبه الإنتاج، أو بيئة sandbox متعطلة خلال نافذة الاختبار.
- الكوادر: الشخص الوحيد الذي يعرف تكاملاً ما، أو مختبِر يُنقل إلى مشروع آخر، أو نوع اختبار لم ينفّذه أحد من قبل.
- المورّدون: واجهة API من طرف ثالث تتأخر أو تتغيّر دون إشعار، أو فريق خارجي يفوّت موعد تسليم.
- الجدول الزمني: بناءات (Builds) متأخرة، أو تقدير بلا وقت لإعادة الاختبار، أو موعد إصدار ثابت يجعل نافذة الاختبار هي الاحتياطي.
اختيار الاستجابة
بعد تحليل الخطر، يذكر منهج CTFL v4.0 (القسم 5.2.4) أربعة أمثلة على الاستجابات الممكنة: تخفيف الخطر بالاختبار، وقبول الخطر، ونقل الخطر، وخطة الطوارئ (Contingency plan). ويتناول ذلك القسم مخاطر المنتج؛ أما مخاطر المشروع فتنطبق عليها الخيارات نفسها، لكن التخفيف فيها يعني إجراءً إدارياً لا اختبارات. وتضيف ممارسات إدارة المخاطر العامة خياراً خامساً هو التجنّب.
ويمكن الجمع بين الخيارات، ونقطة بداية مفيدة تربطها بالتقييم: زد التخفيف كلما ارتفع الاحتمال، وأضف خطة طوارئ أو النقل كلما ارتفع الأثر، وإذا ارتفع الاثنان ففكّر في التجنّب وصعّد الأمر. وفي التطبيق:
- القبول (Acceptance): الخطر صغير، أو الاستجابة تكلّف أكثر من الضرر. سجّل من قَبِله واستمر في مراقبته؛ فالقبول قرار يحمل اسم صاحبه، لا صمت.
- النقل (Transfer): انقل الخطر إلى طرف أقدر على تحمّله، مثل شركة متخصصة متعاقد معها لتنفيذ اختبار الحمل بحلول موعد محدد. ويصبح تسليم الشركة عندها خطر مورّد في سجلك.
- خطة الطوارئ: قرّر الآن ما ستفعله إن وقع الخطر (الاختبار على محاكٍ Mock، أو استعارة مختبِر، أو تأجيل الاختبارات منخفضة الخطر)، واتفق على المحفّز (Trigger) الذي يطلقها.
- التخفيف (Mitigation): تصرّف الآن لخفض الاحتمال أو الأثر: احجز البيئة مبكراً، واجعل مختبِراً ثانياً يعمل مع الخبير الوحيد، واطلب بناءات أصغر وأبكر.
- التجنّب (Avoidance): أزِل السبب بتغيير الخطة، كنقل ميزة تعتمد على مورّد غير جاهز إلى الإصدار التالي؛ وهو يغيّر النطاق، لذا يقرّره مالك المنتج.
| الاحتمال | الأثر | ||
|---|---|---|---|
| منخفض | متوسط | عالٍ | |
| عالٍ | خفّف أو اقبلمتكرر لكنه صغير: خفّفه إن كان ذلك رخيصاً | خفّفتصرّف الآن لخفض احتماله | تجنّب، أو خفّف + خطة طوارئ أو نقلصعّد: الموعد أو النطاق أو الميزانية |
| متوسط | اقبل وراقبسجّل من قَبِله | خفّف أو خطة طوارئقارن كلفة كل منهما | خفّف + خطة طوارئاتفق على المحفّز مسبقاً |
| منخفض | اقبلدوّنه في السجل | اقبل وراقبأعد تقييمه في كل مراجعة | خطة طوارئ أو نقلنادر لكنه بالغ الأثر: لا تكتفِ بالقبول |
- القبول: سجّل القرار واستمر في المراقبة
- استجب إن كانت الكلفة مبرّرة
- استجب الآن: تصرّف أو استعدّ قبل وقوعه
- صعّد: القرار أعلى من صلاحية فريق الاختبار
- احتمال منخفض وأثر عالٍ: خطّط له رغم ندرته
- الاستجابات الخمس
- القبول تحمّله بقرار مسجّل يذكر صاحبه
- النقل يتحمّله طرف أقدر، عادةً بعقد
- خطة الطوارئ تُعَدّ الآن ولا تبدأ إلا حين ينطلق محفّزها
- التخفيف تصرّف الآن لخفض الاحتمال أو الأثر
- التجنّب غيّر الخطة ليزول السبب
نقطة بداية لا قاعدة: كلفة كل استجابة ومن يملك القدرة على التصرف يحددان الاختيار أيضاً.
التخفيف بالاختبار
حين ينعكس خطر مشروع على خطر منتج، كبناء متأخر يقلّص الوقت المتبقي لميزة عالية الخطر، لا يستطيع الاختبار أن يقدّم موعد البناء، لكنه يحدّد أين يذهب الجهد المتبقي؛ وما يبقى دون اختبار يصبح خطراً متبقياً (Residual risk) تبلّغ عنه. ويعدّد منهج CTFL v4.0 الإجراءات التالية لتخفيف مخاطر المنتج بالاختبار:
- اختيار مختبِرين لديهم الخبرة والمهارات التي يتطلبها نوع الخطر.
- تطبيق المستوى المناسب من استقلالية الاختبار: يختبر المنطقةَ عالية الخطر شخصٌ لم يبنِها.
- إجراء المراجعات والتحليل الساكن (Static analysis)، وهي تعمل قبل جاهزية البيئة.
- تطبيق تقنيات الاختبار ومستويات التغطية المناسبة، مثل جداول القرار لقواعد التسعير.
- تطبيق أنواع الاختبار الخاصة بخصائص الجودة المتأثرة، مثل اختبارات الأداء لخطر السعة.
- إجراء الاختبار الديناميكي، بما فيه اختبار الانحدار، حتى لا تكسر الإصلاحات المتعجلة ما كان يعمل.
جرّبها: مولّد الاختبار المبني على المخاطر جرّبها: مولّد سيناريوهات الانحدار
المحفّزات والمالكون وسجل المخاطر
محفّز خطة الطوارئ شرط يمكن ملاحظته، يُتفق عليه مسبقاً، ويطلق الخطة البديلة، مثل: «بناء الدفع ليس في بيئة الاختبار بنهاية اليوم 5». ومن دونه ينتظر الفريق ويأمل حتى لا يبقى وقت للاستفادة من الخطة البديلة.
لكل خطر مالك واحد: شخص مسمّى لا فريق، يراقبه وينفّذ الاستجابة ويبلّغ عن حالته، وكثيراً ما يكون من خارج فريق الجودة (قائد التطوير للبناءات، وقائد فريق العمليات للبيئات، ومدير المورّدين لمخاطر المورّدين). واتفقوا كذلك على قاعدة للتصعيد: حين تحتاج الاستجابة إلى قرار بشأن الموعد أو النطاق أو الميزانية، يرفعها المالك إلى مدير المشروع أو مالك المنتج مع الخيارات وموعد القرار.
وحافظ على السجل طوال الإصدار:
- ارفع المخاطر عند تخطيط الاختبار، وأضف الجديد منها يوم ظهوره.
- راجع السجل عند نقاط ثابتة: اجتماع الحالة الأسبوعي، ونهاية كل دورة اختبار، وقبل قرار الإطلاق.
- سجّل التغييرات مع تواريخها: إعادة التقييم، والمحفّزات التي انطلقت، والقرارات ومن اتخذها.
- حين يقع خطر، حوّله إلى مشكلة (Issue) وتابع أثره في الاختبار؛ ولا تغلق خطراً إلا بدليل أو بقبول مسجّل.
مثال تطبيقي: من سجل المخاطر إلى قرار الإطلاق
تطبيق افتراضي لحجز مواعيد عيادة، الإصدار 2.4، يضيف الدفع الإلكتروني عبر مزوّد خارجي وتذكيرات SMS؛ نافذة الاختبار 15 يوم عمل، وموعد الإطلاق ثابت. وقد انطلق خلال الإصدار محفّزا طوارئ. ويعرض السجل في نهاية هذا القسم مخاطر المشروع الخمسة عند اجتماع قرار الإطلاق.
في اجتماع قرار الإطلاق لا يقرأ مدير الاختبار السجل بصوت عالٍ. فالجزء الخاص بمخاطر المشروع في التقرير يجيب عن ثلاثة أسئلة:
- ماذا وقع وماذا فعل بالاختبار: تعطل sandbox (قُيّم احتماله منخفضاً، لكن أُعدّت له خطة طوارئ لأن أثره عالٍ) غُطّي بالمحاكي وبإعادة اختبار 8 مسارات رئيسية، وأطلق البناءُ المتأخر خطةَ الطوارئ.
- ماذا ترك دون اختبار: انحدار وحدة التقارير، ومخاطر المنتج فيها منخفضة. وقد قَبِل مالك المنتج ذلك كتابةً في اليوم 7، وهو مدرج ضمن المخاطر المتبقية.
- ماذا يجب أن يقرّر الاجتماع: تأكيد الإصدار مع هذا الخطر المتبقي، وتنفيذ الانحدار المؤجل في الأسبوع الأول بعد الإصدار.
سجل مخاطر المشروع - حجز العيادة 2.4 - الحالة عند قرار الإطلاق (اليوم 15)
PR1 بيئة sandbox للدفع مشتركة ← تتعطل في نافذتنا ← تتوقف اختبارات الدفع
الاحتمال: منخفض | الأثر: عالٍ | طوارئ: الاختبار على Mock المزوّد ثم إعادته لاحقاً
المحفّز: تعطل sandbox أكثر من 4 ساعات عمل | المالك: قائد الاختبار
اليوم 6: انطلق المحفّز. اليوم 11: أُعيد اختبار 8 مسارات رئيسية على sandbox. مغلق
PR2 عمر وحده يعرف بوابة SMS ← يغيب ← تتوقف اختبارات SMS
الاحتمال: متوسط | الأثر: متوسط | تخفيف: هدى تعمل مع عمر من اليوم 1 إلى 3
المالك: مدير الجودة | اليوم 3: كُتبت ملاحظات الاختبار. مغلق
PR3 تأخر بناء الدفع ← تنكمش نافذة الاختبار ← يُقلَّص الانحدار
الاحتمال: عالٍ | الأثر: عالٍ | تخفيف: تسليمان أصغر
طوارئ: تأجيل الانحدار منخفض الخطر
المحفّز: البناء ليس في بيئة الاختبار بنهاية اليوم 5 | المالك: مدير الاختبار
اليوم 6: انطلق المحفّز وصُعِّد الأمر. اليوم 7: قَبِل مالك المنتج تأجيل
انحدار وحدة التقارير إلى الأسبوع الأول بعد الإصدار. مشكلة مفتوحة
PR4 لا مهارات لاختبار الحمل في الفريق ← لا يُنفَّذ اختبار ساعة الذروة
الاحتمال: عالٍ | الأثر: عالٍ | نقل: شركة متخصصة، التقرير مستحق في اليوم 12
المالك: مدير الجودة | اليوم 12: استُلم التقرير. مغلق
PR5 واجهة شركة التأمين API بلا بيئة اختبار ← لا يمكن اختبار فحص الأهلية
الاحتمال: عالٍ | الأثر: عالٍ | تجنّب: نُقل فحص الأهلية إلى الإصدار 2.5
المالك: مالك المنتج | اليوم 2: اتُّخذ القرار. مغلقأخطاء شائعة
- خلط مخاطر المشروع ومخاطر المنتج في قائمة واحدة، أو الرد على بيئة متأخرة بمزيد من حالات الاختبار.
- تسجيل الأمور المؤكدة على أنها مخاطر: موعد إطلاق ثابت أو عطلة مقررة قيدٌ تخطط حوله، لا حدث غير مؤكد.
- كتابة خطة طوارئ دون محفّز، فلا يعرف أحد متى يتحوّل إليها، وتبدأ الخطة البديلة بعد فوات الأوان.
- تسمية فريق («التطوير» أو «الجودة») مالكاً للخطر أو عدم تسمية أحد، وغياب قاعدة لتصعيد القرارات التي لا يملكها فريق الاختبار.
- امتصاص خطر المشروع بصمت عبر تقليص الاختبار، فيُخفي تقرير قرار الإطلاق التغطية التي ضاعت.
- كتابة السجل عند انطلاق المشروع ثم عدم مراجعته أبداً، أو إغلاق المخاطر دون دليل أو قبول مسجّل.
من منظور ضمان الجودة
ابدأ قائمة مخاطر المشروع أثناء تخطيط الاختبار، في جلسة قصيرة مع مدير المشروع وقائد التطوير ومالك المنتج ومن يدير البيئات. واطرح سؤالين: ما الذي قد يمنع الاختبار من السير كما خُطط له؟ وماذا سنخسر إن حدث ذلك؟ سجّل الإجابات بصيغة السبب والحدث والأثر، واتفقوا على المالكين قبل انتهاء الجلسة.
ثم أبقِ السجل حياً: راجعه أسبوعياً، وأبلغ عن المحفّز الذي انطلق في اليوم نفسه مع كلفة الخطة البديلة، وأحِل المخاطر التي لا تستطيع معالجتها إلى سجل مدير المشروع بدلاً من الاحتفاظ بقائمة خاصة. وفي قرار الإطلاق اربط كل خطر مشروع وقع بمخاطر المنتج التي تركها أقل اختباراً، حتى يقبل مالك الإصدار الخطر المتبقي عن علم.
تمرين عملي
ابنِ سجل مخاطر مشروع لبوابة تسجيل الطلاب
أنت مدير الاختبار للإصدار أدناه. استخدم ملاحظات اجتماع التخطيط لبناء سجل مخاطر المشروع، ثم اكتب مسودة الجزء الخاص بمخاطر المشروع في تقرير قرار الإطلاق.
بوابة تسجيل الطلاب، الإصدار 3.1
نافذة الاختبار: 10 أيام عمل. موعد الإطلاق ثابت: يبدأ التسجيل في 1 سبتمبر.
ملاحظات اجتماع التخطيط:
1. سيسلّم فريق نظام معلومات الطلاب (SIS) واجهة المقررات API الجديدة
«في حدود اليوم 3»؛ وقد تأخر آخر تسليمين لهذا الفريق.
2. رنا وحدها اختبرت تكامل دفع الرسوم؛ وهي في إجازة يومي 7 و8.
3. تتولى شركة خارجية تدقيق إمكانية الوصول؛ ولم تؤكد موعد البدء بعد.
4. لم يسبق لأحد في الفريق اختبار حمل حركة يوم التسجيل.- افصل الحقائق والقيود عن المخاطر، واكتب كل خطر بصيغة السبب والحدث والأثر.
- قيّم الاحتمال والأثر بـ«عالٍ» أو «متوسط» أو «منخفض»، واختر الاستجابة، واجمع بين الخيارات عند الحاجة.
- أعطِ كل خطة طوارئ محفّزاً يمكن التحقق منه، وكل خطر مالكاً واحداً، وأخطر المخاطر قاعدة تصعيد.
- افترض أن واجهة المقررات وصلت في اليوم 6، واكتب في بضع جمل الجزء الخاص بمخاطر المشروع في تقرير قرار الإطلاق.
إظهار الإجابة النموذجية
ليست مخاطر: موعد الإطلاق الثابت وإجازة رنا أمران مؤكدان، فتخطط حولهما. ويعني الموعد الثابت أن مخاطر الجدول الزمني ستقع على نطاق الاختبار.
R1: قد تصل واجهة المقررات بعد اليوم 3 (فقد تأخر فريق SIS من قبل)، فلا يبقى وقت كافٍ لاختبارات المقررات. الاحتمال عالٍ والأثر عالٍ. التخفيف: احصل على عقد الواجهة (API contract) وعلى تسليم جزئي مبكر. الطوارئ: الاختبار على محاكٍ Mock مبني من العقد؛ والمحفّز: الواجهة ليست في بيئة الاختبار بنهاية اليوم 3. وهو أخطر المخاطر لأن تسجيل المقررات جوهر الإصدار والموعد لا يتحرك، لذا يحصل على قاعدة التصعيد: إن بقيت الواجهة غائبة بنهاية اليوم 5، يختار مالك المنتج بين تأجيل الميزة وتأجيل الانحدار منخفض الخطر. المالك: قائد الاختبار.
R2: إصلاحات دفع الرسوم في اليومين 7 و8 لن يعيد اختبارها أحد يعرف التكامل. الاحتمال عالٍ والأثر متوسط. التخفيف: مختبِر ثانٍ يعمل مع رنا في الأيام من 1 إلى 3 ويكتبان ملاحظات الاختبار. المالك: مدير الجودة. R3: تبدأ شركة إمكانية الوصول متأخرة فلا يُجرى تدقيق قبل الإطلاق. الاحتمال متوسط والأثر عالٍ. التخفيف: حجز مكتوب ومؤرَّخ. الطوارئ: مراجعة داخلية بقائمة تحقق للمسارات الرئيسية؛ والمحفّز: لا موعد بدء بحلول اليوم 2. المالك: مدير الجودة.
R4: من دون خبرة يُنفَّذ اختبار الحمل لذروة الحركة بشكل سيئ أو لا يُنفَّذ أصلاً. الاحتمال عالٍ والأثر عالٍ. انقله إلى شركة متخصصة يُستحق تقريرها في اليوم 8، وسجّل تسليم الشركة خطرَ مورّد. المالك: مدير الجودة.
قرار الإطلاق: «وقع R1: وصلت الواجهة في اليوم 6. بدأت خطة الطوارئ في اليوم 4، فاختُبرت المقررات على المحاكي ثم على الواجهة الحقيقية في الأيام من 6 إلى 10. صعّدنا الأمر في اليوم 5، وقَبِل مالك المنتج تأجيل انحدار صفحات الجداول الدراسية منخفضة الخطر، وهو مدرج الآن ضمن المخاطر المتبقية.» ثم اذكر حالة R2 إلى R4 بالطريقة نفسها مع دليل كل منها، والقرار المطلوب: الإصدار مع قبول هذا الخطر المتبقي.
أسئلة شائعة
هل إدارة مخاطر المشروع مهمة مدير المشروع أم مدير الاختبار؟
كلاهما. يملك مدير المشروع سجل مخاطر المشروع. ويحدّد مدير الاختبار المخاطر التي تهدد الاختبار، ويعالج ما يقع منها ضمن صلاحيات فريق الاختبار، ويحيل الباقي إلى مدير المشروع مع استجابة مقترحة وموعد للتصعيد.
ما الفرق بين التخفيف وخطة الطوارئ؟
التخفيف يُنفَّذ الآن، وقع الخطر أم لم يقع، ليصبح أقل احتمالاً أو أقل ضرراً. أما خطة الطوارئ فتُعَدّ الآن لكنها لا تُنفَّذ إلا إذا وقع الخطر، حين ينطلق محفّزها.
ماذا يحدث للخطر بعد وقوعه؟
يصبح مشكلة (Issue): شيئاً يجب حله لا التنبؤ به. احتفظ بمدخل الخطر مع تاريخه، وسجّل أثره في الاختبار، وتابع المشكلة حتى إغلاقها. وبعض الفرق تجمع المخاطر والافتراضات والمشكلات والاعتماديات في سجل واحد يسمى RAID.
المراجع
- ISTQB Certified Tester Foundation Level (CTFL) v4.0المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
- Certified Tester Advanced Level Test Management (CTAL-TM) v3.0منهج ISTQB المتقدم لإدارة الاختبار: التخطيط والتقدير، والاختبار المبني على المخاطر، والمتابعة، والمقاييس والتقارير.
- ISO/IEC/IEEE 29119-2:2021 — Software and systems engineering — Software testing — Part 2: Test processesنموذج عمليات الاختبار: العمليات المؤسسية وعمليات إدارة الاختبار وعمليات الاختبار الديناميكي، مع أنشطتها ومخرجاتها.
- ISTQB Glossaryالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
تدرّب بأدوات متقن
قيّم الميزات حسب الاحتمالية والأثر، ثم ولّد خطة اختبار مبنية على المخاطر ومرتّبة حسب الأولوية.
ولّد سيناريوهات اختبار الانحدار من وصف التغيير وقائمة الوحدات المتأثرة والمرتبطة.
أضف أو اطرح أياماً أو أسابيع أو أشهراً أو سنوات أو ساعات أو دقائق من تاريخ.
حوّل ملفات CSV وTSV إلى جداول PDF في متصفحك: اكتشاف الفاصل، تكرار صف الترويسة في كل صفحة، واختيار الوضع الأفقي تلقائيًا للجداول العريضة.
للتعمّق أكثر
تقدّمك في هذا الموضوع
سجّل الدخول لتتابع تقدّمك
علّم الموضوعات مكتملة، وتابع من حيث توقفت، وافتح امتحانات التخصص.