ضمان الجودة لا يعني البحث عن الأخطاء في نهاية المشروع، بل بناء طريقة عمل تجعل الجودة جزءًا من كل قرار: من صياغة المتطلب، إلى تصميم الواجهة العربية، إلى اختبار واجهة API، إلى قياس أداء الدفع تحت الضغط، إلى مراقبة الإصدار بعد الإطلاق. في تقنية التوأم نجمع الاختبار اليدوي المنظم، وأتمتة الاختبارات، واختبار API والأداء والأمان وتطبيقات الجوال وإمكانية الوصول، داخل استراتيجية جودة واضحة. نعمل مع فرق المنتجات السعودية التي تخدم مستخدمين عبر بوابات حكومية أو متاجر إلكترونية أو تطبيقات جوال أو أنظمة ERP، ونراعي اللغة العربية واتجاه RTL وبيانات الاختبار الآمنة. النتيجة ليست تقريرًا يعدد العيوب، بل قدرة أعلى على الإطلاق بثقة، وتقليل المفاجآت، وتحسين تجربة المستخدم، وحماية الإيراد والسمعة. ونؤمن بأن الجودة مسؤولية مشتركة بين المنتج والتطوير والتشغيل، لا مهمة فريق منعزل في نهاية الطريق.
اختبار API والأداء
تطبيقات الجوال وإمكانية الوصول
استراتيجية جودة وإدارة إصدارات
أدلة قابلة لإعادة الإنتاج
تقارير للإدارة والفريق التقني
آخر تحديث: 27 أكتوبر 2026 · 8 فروع خدمة · قراءة تقديرية 35 دقيقة
لماذا أصبح ضمان الجودة عامل ثقة قبل أن يكون بندًا تقنيًا؟
تغيّر شكل الأعمال في السعودية خلال سنوات قليلة. صارت الخدمة الحكومية بوابة إلكترونية، وصار المتجر واجهة رقمية قبل أن يكون معرضًا، وصار تطبيق الجوال قناة التواصل الأولى مع العميل. ومع هذا الانتقال لم يعد المستخدم يقارن تجربتك بمنافسك المحلي فقط، بل بأفضل خدمة استخدمها على هاتفه. إذا تأخرت صفحة الدفع، أو ظهرت رسالة خطأ بالإنجليزية في نموذج عربي، أو رُفض طلب بسبب مشكلة في رمز التحقق، فالمستخدم لا يفكر في «خلل برمجي»؛ بل يستنتج أن الخدمة غير موثوقة ويعيد المحاولة عند جهة أخرى.
رؤية 2030 دفعت التحول الرقمي من مشروع تجريبي إلى مسار تشغيلي أساسي في القطاعين العام والخاص. الجهات الحكومية تتابع رضا المستفيدين وزمن إنجاز الخدمة، والشركات تتنافس على سرعة الشراء وسهولة الإرجاع، والمؤسسات المالية تُقاس تجربتها بالثواني لا بالأيام. في هذا السياق يصبح ضمان الجودة جزءًا من الثقة العامة، لا تفصيلًا داخليًا. الخطأ الذي يظهر لمستخدم واحد قد يتحول إلى منشور أو شكوى أو طلب دعم، والخطأ الذي يظهر لآلاف المستخدمين قد يتحول إلى انقطاع في خدمة يعتمد عليها الناس في يومهم.
الجودة أيضًا ليست «غياب الأخطاء» فقط. النظام قد يعمل دون أعطال لكنه يعطي نتيجة خاطئة، أو يقبل طلبًا مكررًا، أو يسمح لمستخدم برؤية بيانات غيره، أو يرفض اسمًا عربيًا بسبب قاعدة تحقق مكتوبة للإنجليزية. الجودة الحقيقية تعني أن المنتج يفعل ما وُعد به، بالطريقة الصحيحة، للمستخدم الصحيح، في الوقت المناسب، وبدرجة أمان وخصوصية مناسبة. هذا التعريف أوسع من الاختبار الوظيفي، ولهذا نتعامل مع الجودة كمنظومة تشمل المتطلبات والتصميم والبيانات والبيئة والأتمتة والمراقبة.
تكلفة العيب لا تُقاس بساعات الإصلاح فقط
عندما يُكتشف الخلل بعد الإطلاق تتسع دائرة أثره. هناك تكلفة مباشرة لإصلاح الكود وإعادة النشر، وتكلفة غير مباشرة لاستعادة السياق وفهم ما تغيّر، وتكلفة دعم العملاء الذين واجهوا المشكلة، وتكلفة فرص بيع ضائعة، وتكلفة سمعة قد لا تظهر في أي تقرير. وفي الأنظمة المالية أو الحكومية قد يضاف إلى ذلك أثر امتثالي وتوثيقي: تقرير خاطئ، فاتورة غير مطابقة، أو سجل وصول لا يمكن تفسيره. المشكلة أن هذه التكاليف لا تظهر مجتمعة في مكان واحد، لذلك يبدو الاختبار أحيانًا «مصروفًا» يمكن تأجيله، بينما هو في الحقيقة تأمين على وظائف الأعمال.
هناك تكلفة لا تظهر في أي فاتورة: تعوّد الفريق على الحلول المؤقتة. يصبح من الطبيعي أن يعرف الموظف أن «الطلب يعلق أحيانًا» أو أن «التقرير يحتاج تصديرًا يدويًا»، فتُبنى إجراءات حول خلل لم يُحل. هذه الحلول تستهلك وقتًا كل يوم، وتجعل أي تغيير لاحق أكثر خطورة. الاختبار الجيد لا يكشف العيب فقط، بل يمنح الفريق لغة مشتركة لوصفه وترتيب أولوياته ومنع عودته. ولهذا نحرص على أن يكون كل عيب مسجلًا بخطوات واضحة وأثر تجاري، لا بعبارة «لا يعمل» فقط.
العربية واتجاه RTL: حيث تفشل اختبارات كثيرة
كثير من الفرق تختبر المنتج بالإنجليزية ثم تطلب «ترجمة» النصوص إلى العربية وتعتبر المهمة منتهية. النتيجة منتج يعمل تقنيًا لكنه يبدو مقلوبًا أو غير مفهوم للمستخدم العربي. اتجاه RTL لا يعني قلب الألوان فقط؛ بل ترتيب الأعمدة، ومحاذاة النص، واتجاه الأيقونات والأسهم، ومسار الخطوات، وموضع زر الإغلاق، واتجاه الرسوم البيانية، وشريط التقدم، والجداول التي تحتوي أرقامًا ونصوصًا مختلطة. وقد يعمل التخطيط جيدًا في الصفحة الرئيسية ثم ينكسر في نموذج الدفع أو صفحة الفاتورة.
ثم تأتي تفاصيل المحتوى: الأرقام العربية والهندية، وصيغة التاريخ الميلادي والهجري، والوقت، والعملة، والمسافات، وعلامات الترقيم. البحث يحتاج معالجة اختلافات الهمزة والألف والتاء المربوطة والهاء والتشكيل حتى يجد المستخدم ما يقصده. لوحة المفاتيح العربية تختلف في إدخال الأرقام والرموز. أسماء المدن والعناوين قد تكون طويلة أو مختلطة مع الإنجليزية. وقارئ الشاشة العربي قد ينطق النص بشكل مختلف إذا كانت السمات البرمجية غير مناسبة. كل هذه حالات اختبار حقيقية لا تظهر في قائمة فحص إنجليزية جاهزة، وتحتاج مختبرًا يفهم اللغة وسياق الاستخدام.
بيانات الاختبار وخصوصية المستخدم
من أخطر الممارسات الشائعة نسخ قاعدة بيانات الإنتاج إلى بيئة الاختبار «لأن البيانات الحقيقية أسهل». هذا يخلق نسخة إضافية من بيانات العملاء في نظام قد يكون أقل حماية، ويستخدمها عدد أكبر من الأشخاص، وقد تبقى بعد انتهاء المشروع. مبادئ حماية البيانات الشخصية في السعودية (PDPL) تدفع نحو تقليل جمع البيانات، وتحديد الغرض، وتطبيق ضوابط أمنية مناسبة، وعدم الاحتفاظ بما لا حاجة له. ولهذا نستخدم بيانات اصطناعية أو مُقنّعة، وحسابات اختبار محددة، وصلاحيات مؤقتة، ونوثق من اطّلع على ماذا ومتى.
حتى بيانات الدفع والهوية تحتاج تعاملًا خاصًا: لا نطلب بطاقات حقيقية، ونستخدم بيئات الاختبار الرسمية لمزودي الدفع، ونفصل بيانات الاختبار عن الإنتاج، ونحذف ما لم يعد لازمًا. هذه الممارسات لا تحمي المستخدم فقط؛ بل تحمي المؤسسة من حادث تسريب في مكان لم يكن أحد يتوقعه. الاختبار يجب أن يكون آمنًا بذاته، لا أن يصبح بابًا خلفيًا لبيانات حساسة.
الجودة ليست بوابة في نهاية الطريق
إذا كان أول اختبار حقيقي يحدث قبل الإطلاق بأسبوع، فأنت لا تدير الجودة؛ بل تدير أزمة. الجودة تبدأ عندما يُكتب المتطلب بمعيار قبول واضح، وتستمر عبر مراجعة التصميم، واختبار الوحدة، واختبار API، واختبار الواجهة، وقياس الأداء، ثم مراقبة الإصدار. كلما اكتُشف الخلل مبكرًا كان إصلاحه أرخص وأقل تأثيرًا على الفريق والمستخدم.
علامات أن الجودة تُدار بالصدفة
- لا توجد معايير قبول مكتوبة، والاتفاق على «الشكل النهائي» شفهي.
- الاختبار يبدأ بعد اكتمال التطوير، ولا يشارك فيه أحد من المنتج أو الأعمال.
- يعتمد الفريق على «جرّبته على جهازي» قبل النشر.
- تُنسخ بيانات الإنتاج إلى بيئة الاختبار دون تقنيع أو صلاحيات محددة.
- لا توجد اختبارات للعربية واتجاه RTL أو قارئات الشاشة.
- الأخطاء المتكررة تُعالج دون معرفة سببها، وتعود في الإصدار التالي.
- لا أحد يعرف كم يستغرق التحقق من الإصدار أو كم عيبًا وصل إلى المستخدم.
هذه العلامات لا تعني أن الفريق لا يعمل بجد؛ غالبًا يعني أن الجودة لم تُصمم كعملية. في كثير من المشاريع التي نعمل عليها، تكون المشكلة الأولى هي غياب صورة مشتركة عن المخاطر: ما الذي يجب اختباره أولًا؟ وما الذي يمكن تأجيله؟ ومن يملك قرار القبول؟ بمجرد الإجابة عن هذه الأسئلة تبدأ الجودة في التحسن حتى قبل شراء أي أداة جديدة.
ما الذي يشمله قسم ضمان الجودة واختبار البرمجيات؟
يغطي القسم دورة الجودة من لحظة فهم الفكرة إلى ما بعد الإطلاق. نبدأ بتحديد المخاطر ومعايير القبول، ثم نصمم استراتيجية اختبار تناسب طبيعة المنتج وإيقاع الإصدار، ثم ننفذ الاختبارات الوظيفية وغير الوظيفية، ونوثق النتائج، ونساعد على الإصلاح والتحقق، ونبني قدرة مستمرة لدى الفريق. لا نتعامل مع الاختبار كمرحلة منفصلة تمر مرة واحدة، بل كحلقة تغذية راجعة تعود إلى المتطلبات والتصميم والكود.
«ضمان الجودة» و«الاختبار» ليسا مترادفين. ضمان الجودة هو النظام الذي يمنع ظهور العيب ويجعله مكتشفًا مبكرًا: معايير واضحة، مراجعات، بيئات منضبطة، أتمتة مناسبة، مؤشرات، ومسؤوليات. أما الاختبار فهو النشاط الذي يتحقق من سلوك المنتج ويكشف الفجوات. يمكن أن يكون لديك فريق اختبار نشيط ونظام جودة ضعيف إذا كانت المتطلبات غامضة والبيئات غير مطابقة والأخطاء تتكرر بلا تحليل. ولهذا نبدأ بالاستراتيجية قبل تنفيذ أي حالة اختبار.
نعمل بمبدأ المخاطر أولًا: النظام الذي يتعامل مع مدفوعات أو بيانات صحية أو صلاحيات إدارية لا يُختبر بنفس عمق صفحة تعريفية. ثم نوزع الاختبار على مستويات مناسبة: اختبار الوحدة يبقى مسؤولية المطور، والتكامل وAPI يكشفان مشاكل التواصل بين الخدمات، واختبار الواجهة من طرف إلى طرف يتحقق من رحلة المستخدم، والاستكشافي يكشف ما لا تلتقطه الحالات المكتوبة. ونضيف الطبقات غير الوظيفية بحسب الأثر: الأداء، الأمان، إمكانية الوصول، التوافق، والموثوقية.
| نوع الاختبار | السؤال الذي يجيب عنه | متى يُنفذ عادة؟ |
|---|---|---|
| اختبار الوحدة | هل تعمل الدالة أو الوحدة البرمجية كما هو متوقع؟ | مع كل تغيير في الكود، داخل خط التكامل |
| اختبار التكامل وAPI | هل تتفاهم الخدمات والبيانات والعقود البرمجية بشكل صحيح؟ | بعد دمج الخدمات وقبل بناء الواجهة النهائية |
| اختبار الواجهة من طرف إلى طرف | هل تكتمل رحلة المستخدم الأساسية دون انقطاع؟ | على البيئات المشتركة وقبل كل إصدار |
| الاختبار الاستكشافي | ما المشكلات التي لا تغطيها الحالات المكتوبة؟ | عند إضافة ميزة أو تغيير منطق أعمال |
| اختبار الأداء | هل تبقى الخدمة سريعة ومستقرة تحت الحمل؟ | قبل المواسم والإطلاقات والتغييرات المعمارية |
| اختبار الأمان وإمكانية الوصول | هل البيانات محمية؟ وهل يستطيع الجميع استخدام الخدمة؟ | دوريًا وقبل الإصدارات الحساسة |
مبادئ نعمل بها
- المخاطر قبل العدد: نرتب الاختبار بحسب الأثر على المستخدم والأعمال، لا بحسب عدد الحالات.
- الدليل قبل الرأي: كل نتيجة قابلة لإعادة الإنتاج، مع خطوات وبيانات وبيئة واضحة.
- الوقاية قبل الاكتشاف: نشارك في مراجعة المتطلبات والتصميم قبل أن يصل العيب إلى الكود.
- الأتمتة حيث تنفع: نؤتمت ما يتكرر ويستقر، ونحتفظ بالحكم البشري لما يحتاج فهمًا وسياقًا.
- البيئة الواقعية: نختبر على بيئات وبيانات قريبة من الإنتاج، مع حماية الخصوصية.
- التحسين المستمر: نراجع مؤشرات الجودة بعد كل إصدار ونعدل الخطة، لا نكررها حرفيًا.
هذه المبادئ ليست شعارات؛ تظهر في قرارات صغيرة: هل نؤتمت هذا الاختبار؟ هل نؤجل الإطلاق لعيب متوسط؟ هل نطلب بيئة اختبار رسمية من مزود الدفع؟ كل قرار يُتخذ مقابل مخاطرة، والاستراتيجية تجعل المقايضة واضحة. والجودة في النهاية مسؤولية مشتركة: المنتج يحدد المعنى، والتطوير يبني القابلية للاختبار، والجودة تتحقق وتثبت، والتشغيل يراقب. عندما يغيب أحد هذه الأدوار، يتحول الاختبار إلى مطاردة أخطاء بدل منعها.
الفروع والخدمات الثمانية
كل فرع أدناه قابل للتنفيذ بشكل مستقل، لكن قيمته تزيد عندما يرتبط بغيره. قد تبدأ باختبار يدوي لميزة جديدة، ثم تكتشف أن بعض الرحلات تتكرر كل أسبوع فتستحق الأتمتة، أو تظهر مشكلات أداء عند الحمل فتنتقل إلى اختبار التحمل، أو يطلب عميل مؤسسي دليلًا على إمكانية الوصول والأمان. الفروع ليست قائمة تُشترى كاملة، بل خريطة تساعدك على تحديد الأولوية التالية.
الاختبار اليدوي الشامل
الاختبار اليدوي ليس بديلًا ضعيفًا عن الأتمتة، بل القدرة على الحكم فيما لا تحكمه قاعدة ثابتة. المختبر الجيد لا ينقر على الشاشات عشوائيًا؛ بل يبني جلسات استكشافية حول مخاطر محددة، ويستخدم تقنيات تصميم مثل تقسيم فئات التكافؤ، والقيم الحدية، وجداول القرار، وانتقالات الحالة. هذه التقنيات تكشف حالات لا تظهر في «المسار السعيد»: مبلغ صفر، خصم متكرر، طلب يعود بعد انتهاء الجلسة، اسم عربي طويل، أو صلاحية تُمنح ثم تُسحب أثناء الاستخدام.
نغطي الرحلات الحرجة أولًا: التسجيل والدخول، استعادة كلمة المرور، البحث والتصفية، إتمام الطلب، الدفع، الإلغاء والإرجاع، رفع المستندات، إدارة الصلاحيات، والتقارير. ثم نختبر الحالات الحدّية والأخطاء المتوقعة: انقطاع الشبكة، إدخال غير صالح، تكرار الإرسال، الرجوع من المتصفح، وفتح الصفحة نفسها في تبويبين. ونراجع المحتوى العربي واتجاه RTL والنصوص المختلطة والتواريخ والأرقام، لأن هذه التفاصيل هي أول ما يلاحظه المستخدم السعودي وأول ما يغيب عن الاختبارات المكتوبة بالإنجليزية.
جودة تقرير العيب لا تقل أهمية عن اكتشافه. نكتب عنوانًا محددًا، وخطوات إعادة إنتاج مرقمة، والنتيجة المتوقعة والفعلية، والبيئة والمتصفح والحساب المستخدم، مع لقطة أو تسجيل أو سجل شبكة عند الحاجة. ونفرق بين الشدة (أثر العيب) والأولوية (أسرع إصلاح مناسب للأعمال)، لأن عيبًا في تحرير نص قد يكون منخفض الشدة لكنه يمنع الإطلاق، بينما عيبًا في تقرير نادر قد يكون عالي الشدة منخفض الأولوية. نستخدم TestRail أو Xray أو Jira بحسب أدوات الفريق، ونحافظ على تتبع كل متطلب إلى حالات الاختبار والنتائج. ونراجع مع المنتج والفريق التقني ما يعنيه «مقبول» قبل التنفيذ، لأن كثيرًا من الخلافات ليست على وجود العيب بل على تصنيفه وأثره. ونخصص وقتًا لاختبار الأدوار المتقاطعة: مدير يعدّل طلبًا قدمه موظف، ومشرف يعتمد استثناءً، ومستخدم تنتهي صلاحيته في منتصف المهمة. ونعيد اختبار العيب في البيئة التي ظهر فيها، ثم نوسع التحقق إلى الرحلات المجاورة للتأكد من أن الإصلاح لم يكسر شيئًا آخر. ونراجع الرسائل التي يراها المستخدم: هل هي مفهومة؟ هل تخبره بما يجب فعله؟ هل تظهر بالعربية دون خلط مصطلحات إنجليزية غير مبررة؟ هذه المراجعة النصية جزء من الجودة، لأن الرسالة الغامضة قد تتحول إلى تذكرة دعم أو طلب مكرر. ونقدم دليلًا مختصرًا للمختبرين الجدد يشرح المنتج والحسابات والبيانات، حتى لا يعتمد نجاح الاختبار على شخص واحد يعرف كل التفاصيل.
ماذا يشمل؟
- تحليل المتطلبات ومعايير القبول قبل التنفيذ.
- حالات اختبار وظيفية وجلسات استكشافية موثقة.
- اختبار الصلاحيات والأدوار ومنطق الأعمال.
- اختبار النماذج والرسائل والحالات الحدّية.
- مراجعة العربية وRTL والتوافق مع المتصفحات.
- دعم اختبار القبول من المستخدم (UAT).
المخرجات
- خطة اختبار ومصفوفة تغطية مرتبطة بالمخاطر.
- حالات اختبار قابلة لإعادة الاستخدام.
- سجل عيوب مع أدلة وخطوات إعادة.
- تقرير حالة الاختبار ونسبة الإنجاز.
- ملاحظات تجربة استخدام قابلة للتنفيذ.
مؤشرات النجاح: ارتفاع نسبة الرحلات الحرجة المغطاة، انخفاض العيوب التي تصل إلى المستخدم، نجاح اختبار القبول من الجولة الأولى، وقدرة أي شخص على إعادة إنتاج العيب من التقرير دون سؤال. لمن تصلح: البوابات الحكومية والمتاجر الإلكترونية وأنظمة الإدارة المعقدة، والفرق التي تطلق ميزات جديدة دون أن تملك بعد حزمة أتمتة ناضجة. ابدأ بمراجعة اختبار المواقع والتطبيقات لربط الاختبار اليدوي بخدمة تطوير قائمة. ونستخدم جلسات مراجعة سريعة مع المنتج بعد كل دورة، لتحويل الملاحظات المتفرقة إلى قرارات واضحة قبل الإصدار، ونحفظ سجل القرارات حتى لا يعاد نقاش العيب نفسه في كل نسخة.
أتمتة الاختبار
الأتمتة استثمار وليست هدفًا بحد ذاته. الاختبار الآلي الجيد يقلل الوقت اللازم للتحقق من الرحلات المتكررة، ويمنح الفريق تغذية راجعة سريعة بعد كل تغيير، ويحرر المختبر البشري للعمل على الاستكشاف والتجربة. أما الأتمتة السيئة فتنتج حزمة هشة تفشل لأسباب غير متعلقة بالمنتج، فيفقد الفريق الثقة بها ويبدأ بتجاهلها. لذلك نبدأ بسؤالين: ما الذي يستحق الأتمتة؟ وما التكلفة الحقيقية لصيانته على المدى الطويل؟
نؤتمت الرحلات الحرجة المستقرة ذات القيمة العالية: الدخول، البحث، إضافة إلى السلة، الدفع، إدارة الحساب، والعمليات الإدارية المتكررة. نستخدم Playwright عندما نحتاج تغطية متعددة المتصفحات وتحكمًا دقيقًا في الشبكات والجلسات، وCypress لتجارب التطوير السريعة وواجهات الويب التفاعلية، وSelenium عند وجود أنظمة قديمة أو متطلبات تكامل واسعة. نكتب الاختبارات بلغة الفريق نفسها، ونفصل بيانات الاختبار عن منطق الاختبار، ونستخدم أنماطًا مثل Page Objects وFixtures، ونشغل الحزمة عبر GitHub Actions أو GitLab CI مع تقارير Allure وتتبع للفشل.
جودة الحزمة تُقاس بقدرتها على البقاء، لا بعدد ملفاتها. نستخدم محددات مستقرة مثل data-testid بدل الاعتماد على النصوص أو البنية المتغيرة، ونعزل كل اختبار بحيث لا يعتمد على ترتيب تشغيل اختبار آخر، وننظف البيانات قبل وبعد التنفيذ، ونشغل الاختبارات بالتوازي دون تصادم. نفصل حزمة الدخان السريعة عن حزمة الانحدار الكاملة، ونحدد ميزانية زمنية للتغذية الراجعة. ونراجع الاختبارات الهشة دوريًا: إما إصلاحها أو حذفها، لأن اختبارًا يفشل كذبًا أسوأ من عدم وجود اختبار. نقيس زمن تشغيل الحزمة، ونفصل الاختبارات البطيئة عن السريعة، ونستخدم إعادة المحاولة بحدود واضحة فقط للأخطاء الخارجية العابرة، لا لإخفاء عدم استقرار حقيقي. ونحتفظ بسجل للاختبارات المحذوفة وأسبابها، لأن الحذف قرار هندسي يحتاج مراجعة. ونربط كل فشل بتذكرة أو تحليل، ونراجع الاتجاه أسبوعيًا مع الفريق. ونضمن أن بيانات الاختبار لا تعتمد على حالة إنتاج متغيرة، وأن الحسابات تُنشأ وتُحذف بطريقة قابلة للتكرار. ونوثق كيفية إضافة اختبار جديد، حتى يستطيع المطور كتابة اختبار دون انتظار مختبر الجودة في كل مرة. ونحدد مالك الحزمة ومن يراجعها بعد كل تغيير كبير في الواجهة، لأن الأتمتة بلا مالك تتحول بسرعة إلى دين تقني.
لا نؤتمت كل شيء. الشاشات التي تتغير أسبوعيًا، أو التي تعتمد على حكم بصري دقيق، أو التي تمثل حالة نادرة لا تتكرر، قد تكون تكلفة أتمتتها أعلى من قيمتها. نبدأ بتغطية «العمود الفقري» ثم نتوسع بناءً على بيانات الفشل والوقت الموفّر. ونستخدم اختبارات بصرية بجرعات محسوبة، لأنها مفيدة في اكتشاف الانزياح البصري لكنها تحتاج ضبطًا لتقليل الضوضاء.
ماذا يشمل؟
- تقييم ما يستحق الأتمتة وترتيب الأولويات.
- بناء حزمة E2E للرحلات الحرجة.
- تكامل مع GitHub Actions أو GitLab CI.
- بيانات اختبار معزولة وتشغيل متوازٍ.
- تقارير Allure ولقطات وفيديوهات عند الفشل.
- مراجعة الاختبارات الهشة وتقليلها.
المخرجات
- مستودع أتمتة منظم مع توثيق التشغيل.
- حزم Smoke وRegression واضحة.
- خط أنابيب يشغل الاختبارات تلقائيًا.
- لوحة نتائج واتجاهات الفشل.
- دليل صيانة وإضافة اختبارات جديدة.
مؤشرات النجاح: انخفاض زمن التحقق من الإصدار، ارتفاع نسبة الاختبارات المستقرة، تقليل الاختبارات المتخطاة أو المتجاهلة، وزيادة عدد العيوب المكتشفة قبل الوصول إلى الإنتاج. لمن تصلح: فرق SaaS التي تنشر أسبوعيًا، والمتاجر ذات الرحلات المتكررة، والفرق التي تريد تحرير وقت المختبرين للعمل الاستكشافي. اربط الأتمتة بخط النشر عبر الحوسبة السحابية وDevOps لتحصل على تغذية راجعة تلقائية بعد كل دمج. ونراجع تغطية الحزمة مقابل الرحلات التي تغيّرت في كل إصدار، لأن التغطية الثابتة لا تعني الملاءمة.
اختبار API
واجهات API هي الجهاز العصبي للمنتج الحديث: التطبيق والموقع ولوحة الإدارة وخدمة الدفع ونظام ERP كلها تتحدث عبرها. قد تبدو الواجهة سليمة، بينما يسمح API بإرجاع بيانات مستخدم آخر عند تغيير رقم في الرابط، أو يقبل مبلغًا سالبًا، أو يكرر عملية الدفع عند إعادة المحاولة. اختبار API يكتشف هذه المشكلات في طبقة أبكر وأسرع من اختبار الواجهة، ويحمي كل المستهلكين في وقت واحد.
نبدأ بعقد API: مواصفة OpenAPI إن وجدت، أو توثيق فعلي نتحقق منه. نختبر الحقول الإلزامية وأنواع البيانات والحدود القصوى والترميز، والاستجابات الناجحة والفاشلة، وأكواد الحالة، ونموذج الأخطاء الموحد. ثم ننتقل إلى المصادقة والتفويض: صلاحية الرموز، وانتهاء الجلسة، ونطاقات OAuth2/OIDC، ومنع الوصول الأفقي بين المستخدمين، والتحقق من أن كل دور يرى ما يخصه فقط. ونغطي الترقيم والتصفية والترتيب والبحث، وحدود المعدل، والتكرار الآمن (Idempotency)، والويب هوك، والمهل وإعادة المحاولة.
نستخدم Postman لاستكشاف الخدمات وبناء مجموعات قابلة للمشاركة، وREST Assured لاختبارات آلية منظمة داخل مشاريع Java، ونضيف اختبارات تعاقدية بين الخدمات لمنع «انحراف العقد» الذي يظهر متأخرًا في الواجهة. نعزل الأطراف الخارجية عبر محاكاة مزود الدفع أو الرسائل أو الشحن، ونختبر التكامل الحقيقي في بيئة اختبار رسمية. ونراجع ترميز النص العربي، والمناطق الزمنية، وصيغ التاريخ، والعملات، لأن أخطاءها تظهر غالبًا في الفواتير والتقارير لا في الشاشة الأولى.
التغطية لا تعني استدعاء كل نقطة نهاية مرة واحدة، بل اختبار الحالات السلبية والحدّية وسلوك النظام عند فشل الاعتماد. نتحقق أيضًا من أثر العملية في قاعدة البيانات أو الأحداث الصادرة، لا من شكل الاستجابة فقط. ونوثق كل نتيجة مع الطلب والاستجابة والبيانات المستخدمة، حتى يستطيع المطور إعادة إنتاج المشكلة دون تخمين. ونختبر سلوك API عند إعادة إرسال الطلب نفسه، وعند انقطاع الاتصال بعد نجاح العملية، لأن المستخدم قد يعيد المحاولة فيُخصم المبلغ مرتين أو يُنشأ طلبان. ونراجع حدود الصلاحيات عند تغيير الدور أو إلغاء الحساب، ونتأكد من أن الرمز القديم لا يبقى صالحًا. ونفحص الاستجابات التي تحتوي بيانات إضافية غير لازمة، لأن تسريب حقل واحد قد يكشف معلومات عن مستخدم آخر. ونرتب النتائج بحسب المسار الذي يؤثر على المستخدم، لا بحسب عدد النقاط المغطاة، ونقدم أمثلة طلب واستجابة مختصرة يمكن استخدامها كاختبار انحدار. ونراجع سلوك الخدمة عند بطء طرف خارجي، لأن غياب المهلة أو إعادة المحاولة قد يترك المستخدم أمام شاشة معلقة.
ماذا يشمل؟
- مراجعة عقد OpenAPI وتوثيق النقاط.
- اختبار المصادقة والتفويض والصلاحيات.
- الحالات السلبية والحدّية وأكواد الأخطاء.
- الترقيم والتصفية والبحث وحدود المعدل.
- التكامل مع الدفع والرسائل وERP.
- اختبارات تعاقدية داخل خط النشر.
المخرجات
- مجموعة Postman موثقة وقابلة للتشغيل.
- حزمة اختبارات API آلية.
- مصفوفة تغطية النقاط والمخاطر.
- سجل عيوب مع طلب واستجابة.
- تقرير جاهزية التكامل قبل الإطلاق.
مؤشرات النجاح: ارتفاع تغطية النقاط الحرجة، انخفاض العيوب التي تظهر في الواجهة بسبب API، ثبات العقود بين الخدمات، وقدرة الفريق على اكتشاف كسر التكامل قبل النشر. لمن تصلح: الفرق التي تبني خدمات مصغرة أو تطبيق جوال بظهر API، والمنصات التي تتكامل مع بوابات دفع أو أنظمة ERP أو مزودي شحن. إذا كان نظامك يعتمد على ERP، اربط اختبار التكامل بخدمة دعم تقنية المعلومات وERP/CRM لضمان صحة البيانات والصلاحيات بعد الترحيل. وندرج أمثلة الاستجابة في تقرير العيوب، ونربط كل عيب بمسار المستخدم المتأثر، حتى يرى الفريق الأثر لا مجرد حقل ناقص، ثم نعيد تشغيل المجموعة بعد كل تغيير في العقد.
اختبار الأداء والتحمل
الأداء ليس تحسينًا تجميليًا بعد الإطلاق، بل ميزة أعمال. المستخدم الذي ينتظر صفحة الدفع يفقد الثقة، والتاجر الذي يتعطل موقعه في أول يوم من العروض يخسر مبيعات لا تعود. في السوق السعودي توجد مواسم وموجات واضحة: رمضان والعيد، العودة إلى المدارس، اليوم الوطني، الحملات الترويجية، ومواعيد الخدمات الحكومية. الاستعداد لهذه اللحظات يحتاج قياسًا مسبقًا، لا أمنيات.
نبدأ بتعريف أهداف قابلة للقياس: زمن استجابة مقبول، ونسبة أخطاء قصوى، وإنتاجية مطلوبة، وسلوك متوقع عند تجاوز الطاقة. نستخدم k6 لسيناريوهات حديثة قابلة للبرمجة، وJMeter لخطط اختبار تقليدية واسعة، وGatling لسيناريوهات عالية الأداء. نصمم أحمالًا واقعية: مستخدم يتصفح، وآخر يبحث، وثالث يدفع، ورابع يرفع مستندًا، مع توزيع نسب قريب من الاستخدام الفعلي. ونفرق بين اختبار الحمل، والضغط، والارتفاع المفاجئ، والتحمل الطويل.
القياس وحده لا يكفي؛ نحتاج إلى مراقبة متزامنة للخادم وقاعدة البيانات والشبكة والطوابير وذاكرة التخزين المؤقت. نبحث عن نقاط الاختناق: استعلام بطيء، أو مشكلة N+1، أو فهرس ناقص، أو تجمع اتصالات صغير، أو حمل زائد على خدمة خارجية، أو عدم استفادة من CDN. ثم نعيد الاختبار بعد المعالجة لنثبت التحسن. ونضيف اختبار أداء الواجهة عبر Lighthouse ومؤشرات تجربة المستخدم، لأن سرعة الخادم لا تعني بالضرورة سرعة ما يراه المستخدم على هاتفه. نحدد أيضًا سلوك النظام عند فشل خدمة خارجية: هل ينتظر المستخدم بلا نهاية؟ هل تظهر رسالة واضحة؟ هل يعاد الطلب تلقائيًا؟ ونراجع خطط التوسع الأفقي والرأسي وتأثيرها على التكلفة، ونعيد الاختبار بعد كل تغيير معماري كبير لأن الأرقام القديمة لا تبقى صالحة. ونقدم سيناريوهات مراقبة للذروة: ما التنبيه الذي يجب أن يصل؟ ومن يتصرف؟ وما حدود التراجع؟ ونفرق بين بطء الواجهة الناتج عن الصور والخطوط والسكربتات، وبطء الخدمة الناتج عن الخادم أو قاعدة البيانات، لأن العلاج مختلف. ونستخدم النتائج لتقدير سعة النشر وعدد النسخ المطلوبة، لا لاستعراض رقم إنتاجية كبير. ونوثق افتراضات الاختبار، لأن نتيجة حمل مبنية على بيانات غير واقعية تضلل القرار.
نحرص على أن تكون بيئة الاختبار ممثلة للإنتاج في الموارد والإعدادات والبيانات، ونوضح الفرق عندما لا يكون ذلك ممكنًا. لا ننفذ اختبار حمل على الإنتاج دون موافقة صريحة ونافذة محددة وخطة تراجع. ونقدم تقريرًا يشرح الطاقة الحالية، والهامش المتاح، والتكلفة المتوقعة عند التوسع، حتى يقرر صاحب القرار بوعي لا بحدس.
ماذا يشمل؟
- تحديد أهداف الأداء والسيناريوهات الواقعية.
- اختبار الحمل والضغط والارتفاع المفاجئ.
- اختبار التحمل لفترات طويلة.
- مراقبة الخادم وقاعدة البيانات والطوابير.
- قياس أداء الواجهة وCore Web Vitals.
- تحليل نقاط الاختناق وإعادة القياس.
المخرجات
- خطة أداء بسيناريوهات وبيانات محددة.
- تقارير نتائج قبل وبعد التحسين.
- قائمة نقاط اختناق مرتبة بالأثر.
- تقدير الطاقة والهامش والتوسع.
- توصيات لخطة استعداد للمواسم.
مؤشرات النجاح: تحقق أهداف زمن الاستجابة ونسبة الأخطاء تحت الحمل المتوقع، وجود هامش كافٍ للذروة، انخفاض الزمن حتى التفاعل في الواجهة، ووجود قائمة معالجات موثقة بدل مفاجآت يوم الإطلاق. لمن تصلح: المتاجر الإلكترونية، والبوابات الحكومية ذات الطلب الموسمي، وخدمات الدفع، وأي منتج يستعد لحملة تسويقية كبيرة أو إطلاق واسع. اربط نتائج الأداء بخطة التوسع في الحوسبة السحابية وDevOps لتحويل التوصيات إلى موارد وإعدادات فعلية. ونشارك نتائج الاختبار مع فريق التطوير وقاعدة البيانات والتشغيل في جلسة واحدة، لأن تحسين الأداء يحتاج قرارًا مشتركًا لا توصية منفردة، ونحدد ما إذا كان الاختناق في الكود أم في الإعداد أم في المورد.
اختبار تطبيقات الجوال
تطبيق الجوال يعمل في بيئة لا تشبه سطح المكتب: أجهزة بأحجام ونسخ نظام مختلفة، شبكات متغيرة، مقاطعات من المكالمات والإشعارات، صلاحيات يمكن رفضها، وبطارية وذاكرة محدودتان. وقد يعمل التطبيق بشكل مثالي على جهاز المطور ثم يتعطل على جهاز شائع بين المستخدمين. لهذا لا يكفي اختبار نسخة واحدة؛ نحتاج مصفوفة أجهزة مبنية على بيانات الاستخدام الفعلية وأهمية الشريحة، لا على الأجهزة المتوفرة في المكتب.
نستخدم Appium لاختبارات آلية عبر المنصتين، وBrowserStack أو Sauce Labs لتشغيلها على أجهزة حقيقية وسحابية متنوعة. نختبر التثبيت والتحديث وإعادة التثبيت، وتسجيل الدخول ورمز التحقق، والتنقل بين الشاشات، والعمل في الخلفية والعودة، والإشعارات، والروابط العميقة، والمشاركة، ورفع الصور، والدفع. ونختبر الحالات السيئة: شبكة ضعيفة، انقطاع كامل، انتهاء الجلسة، رفض صلاحية الموقع أو الكاميرا، وامتلاء التخزين.
العربية في تطبيقات الجوال لها طبقات إضافية: اتجاه الواجهة، ولوحة المفاتيح العربية، والأرقام، والتاريخ، والأسماء الطويلة، والنصوص المختلطة، وقارئ الشاشة TalkBack أو VoiceOver. نراجع أيضًا حجم التطبيق، واستهلاك الذاكرة والبطارية، وسجلات الانهيار، والتخزين الآمن للرموز، وعدم تسريب المعلومات الحساسة في السجلات. ونلتزم بإرشادات App Store وGoogle Play منذ مرحلة التصميم لتقليل رفض الإصدار. ونراجع سلوك التطبيق عند تغيير إعدادات النظام: الوضع الداكن، تكبير الخط، تغيير اللغة، تعطيل الإشعارات، وتوفير الطاقة. ونختبر الأجهزة اللوحية إن كانت مدعومة، والانتقال بين الشبكة والواي فاي أثناء الطلب. ونفحص تسجيل الخروج عن بعد وإبطال الجلسة على جهاز مفقود، لأن أمان الحساب جزء من تجربة الجوال. ونقارن الأداء بين الإصدارات لرصد أي تدهور بعد إضافة ميزة. ونختبر روابط المشاركة والدعوات، وصلاحية فتح الملفات المرفقة، وسلوك التطبيق عند نفاد المساحة. ونراجع نصوص المتجر ولقطات الشاشة والأذونات المطلوبة، لأن الرفض قد يأتي بسبب وصف مضلل أو صلاحية غير مبررة لا بسبب خلل برمجي. ونحتفظ بسجل للأجهزة التي ظهرت عليها المشكلة، مع نسخة النظام ونوع الشبكة، لتسريع التحليل. ونقدم قائمة أولويات للإصلاح قبل الإطلاق، لأن ليس كل عيب يستحق تأخير الإصدار، لكن العيوب التي تمنع الدفع أو تسجيل الدخول تستحق. ونراجع أداء التطبيق عند العودة من الخلفية، لأن كثيرًا من المشكلات تظهر هناك لا في التشغيل الأول.
قبل الإطلاق نستخدم قنوات الاختبار التجريبي مثل TestFlight وGoogle Play الداخلية، ثم نوفر طرحًا تدريجيًا ومراقبة للانهيارات والملاحظات. ونربط نتائج الاختبار بقمع التحويل: هل يكمل المستخدم التسجيل؟ هل تنجح عملية الدفع؟ أين يتوقف؟ هذه الأسئلة أهم من عدّ الشاشات المختبرة.
ماذا يشمل؟
- مصفوفة أجهزة وأنظمة مبنية على الاستخدام.
- اختبار وظيفي وآلي عبر Appium.
- شبكات ضعيفة ومقاطعات وصلاحيات.
- الإشعارات والروابط العميقة والتحديث.
- العربية وRTL وقارئات الشاشة.
- فحص الانهيارات والأداء والتخزين الآمن.
المخرجات
- نتائج اختبار موزعة على الأجهزة.
- تقرير جاهزية المتاجر والإصدار.
- سجل عيوب مع سجلات انهيار.
- حزمة أتمتة للرحلات الحرجة.
- توصيات لطرح تدريجي ومراقبة.
مؤشرات النجاح: انخفاض جلسات الانهيار، ارتفاع اكتمال رحلة التسجيل والدفع، نجاح الإصدار في المراجعة من المحاولة الأولى، وتغطية الأجهزة الأكثر أهمية لدى الجمهور المستهدف. لمن تصلح: تطبيقات التوصيل والخدمات المالية والولاء والخدمات الحكومية، والشركات التي تعتمد على الجوال كقناة رئيسية. اطّلع على الاختبارات التجريبية لربط اختبار الجوال ببرنامج تجربة مستخدم أوسع. ونراجع سلوك التطبيق بعد تحديث نظام التشغيل، لأن نسخة جديدة قد تغير الأذونات أو الإشعارات أو طريقة عرض الواجهة. ونحتفظ بمصفوفة مختصرة للأجهزة الأكثر أهمية، ونحدّثها بناءً على بيانات الاستخدام لا على التخمين.
اختبار الأمان
اختبار الأمان داخل ضمان الجودة ليس بديلًا عن اختبار الاختراق، لكنه يمنع وصول الثغرات الواضحة إلى الإنتاج. كثير من المشكلات الأمنية تبدأ كعيب وظيفي: واجهة تسمح بتعديل معرّف الطلب، أو API يعيد بيانات مستخدم آخر، أو نموذج رفع ملفات لا يتحقق من النوع والحجم، أو رسالة خطأ تكشف مسار الخادم وإصدار قاعدة البيانات. اختبار الجودة الواعي بالأمان يلتقط هذه المشكلات مبكرًا، ويترك الاختبار المتخصص الأعمق للحالات المعقدة وسلاسل الاستغلال.
نغطي أساسيات OWASP Top 10 بحسب انطباقها: التحقق من المصادقة وإدارة الجلسات، والتحكم في الوصول على مستوى الكائن والدالة، والحقن بأنواعه، والبرمجة النصية عبر المواقع XSS، وتزوير الطلبات CSRF، وتزوير الطلبات من جهة الخادم SSRF، ورفع الملفات، وحدود المعدل، وتسريب المعلومات. ونراجع الترويسات الأمنية، وإعدادات TLS، وسياسة كلمات المرور، واستعادة الحساب، وسجلات الأحداث الحساسة. ونستخدم OWASP ZAP للفحص الآلي الأولي، وBurp Suite للتحقق اليدوي من السلوك والسياق.
لا نكتفي بالأدوات. الفحص الآلي يجد أنماطًا معروفة، لكنه لا يفهم منطق الأعمال: هل يمكن تطبيق خصم أكثر من مرة؟ هل يمكن تجاوز خطوة الموافقة؟ هل يمكن تصدير تقرير يحتوي بيانات خارج نطاق الدور؟ هذه الأسئلة تحتاج سيناريوهات مكتوبة وبيانات اختبار مضبوطة. ونفحص الاعتماديات والمكتبات، ونبحث عن الأسرار المكتوبة في الكود أو متغيرات البيئة المكشوفة، ونراجع كيفية تعامل بيئة الاختبار مع بيانات المستخدمين وفق مبادئ PDPL. نختبر أيضًا استجابة النظام لمحاولات الوصول المتكررة، وسلوك القفل المؤقت، وإعادة تعيين كلمة المرور، وتغيير البريد أو الهاتف. ونراجع صلاحيات لوحة الإدارة لأنها غالبًا أوسع من الحاجة، ونتحقق من أن سجلات الأحداث لا تحتوي رموزًا أو بيانات حساسة. ونفحص رفع الملفات من حيث النوع والحجم والمحتوى، ونتأكد من أن الملفات المرفوعة لا تُخدم كصفحات قابلة للتنفيذ. وننسق مع فريق البنية لتأمين بيئة الاختبار نفسها، لأن اختبار تطبيق آمن على خادم غير محدّث لا يعطي صورة صحيحة. ونعيد الاختبار على نفس المسار بعد الإصلاح، ونضيف حالة انحدار تمنع تكرار الثغرة. ونراجع رسائل الخطأ العامة، لأن الإفصاح عن تفاصيل داخلية يسهل على المهاجم فهم النظام.
قبل أي اختبار نحدد النطاق والتفويض والبيئة. لا ننفذ اختبارات تدخلية على الإنتاج دون موافقة صريحة ونافذة محددة. ونصنف النتائج بحسب الخطورة والأثر، ونقدم دليلًا قابلًا لإعادة الإنتاج، ثم نعيد الاختبار بعد المعالجة. وإذا ظهرت ثغرة حرجة تمس بيانات أو مدفوعات، نبلغ جهة الاتصال فورًا وننسق مع فريق الأمن قبل الاستمرار.
ماذا يشمل؟
- مراجعة المصادقة والجلسات واستعادة الحساب.
- اختبار التفويض والوصول بين المستخدمين.
- فحص الحقن وXSS وCSRF وSSRF ورفع الملفات.
- الترويسات وTLS وتسريب الأخطاء.
- فحص الاعتماديات والأسرار المكشوفة.
- إعادة اختبار بعد الإصلاح.
المخرجات
- تقرير نتائج مصنف بالخطورة.
- خطوات إعادة إنتاج وأدلة.
- خطة معالجة مرتبة بالأولوية.
- تقرير إعادة اختبار.
- توصيات لتحسين دورة التطوير الآمن.
مؤشرات النجاح: إغلاق الثغرات الحرجة والعالية، ارتفاع نسبة تغطية اختبارات التفويض، اختفاء الأسرار من المستودعات، ونجاح إعادة الاختبار قبل الإطلاق. لمن تصلح: المنصات التي تتعامل مع مدفوعات أو بيانات شخصية أو وصول إداري، والقطاعات الصحية والتعليمية والحكومية. اربط هذا الفرع بخدمة الأمن السيبراني وحماية البيانات عندما تحتاج إلى اختبار اختراق كامل أو مراجعة معمارية أعمق. ونراجع صلاحيات حسابات الاختبار نفسها، لأن حسابًا إداريًا واسعًا قد يخفي مشكلة تفويض بدل أن يكشفها. ونوثق أي اختبار لم يُنفذ بسبب قيود البيئة، حتى لا يُفهم التقرير على أنه تغطية كاملة.
اختبار إمكانية الوصول والتوافق
إمكانية الوصول ليست ميزة إضافية للمستخدمين ذوي الإعاقة فقط؛ بل جودة أساسية تعني أن الخدمة تعمل باللوحة والمفاتيح وقارئ الشاشة، وتُقرأ بوضوح، وتُستخدم على شاشة صغيرة أو اتصال بطيء. في السعودية تتزايد توقعات جودة الخدمات العامة والخاصة، وتصبح سهولة الوصول جزءًا من تقييم الخدمة الرقمية. منتج لا يستطيع مستخدم كفيف إكماله، أو لا يعمل دون فأرة، هو منتج ناقص حتى لو اجتاز كل الاختبارات الوظيفية.
نعتمد WCAG 2.2 مستوى AA كمرجع عملي، ونترجمه إلى اختبارات قابلة للتنفيذ: بنية العناوين، والنص البديل للصور، والتباين اللوني، ووضوح التركيز، والتنقل بلوحة المفاتيح، وترتيب القراءة، وتسميات الحقول ورسائل الأخطاء، والنماذج متعددة الخطوات، والجداول، والمحتوى المتحرك، والوسائط. ونراجع اتجاه RTL لأنه يؤثر في ترتيب التركيز وموضع العناصر، ونتحقق من نطق النص العربي عبر NVDA وVoiceOver وTalkBack.
نستخدم axe-core وLighthouse وPa11y للفحص الآلي السريع، لكن نعرف حدودها: هي تكشف جزءًا من المشكلات ولا تثبت أن التجربة قابلة للاستخدام. لذلك نضيف اختبارًا يدويًا شاملًا، ونختبر رحلات كاملة مثل التسجيل والبحث والدفع باستخدام لوحة المفاتيح وقارئ الشاشة فقط. ونراجع مستندات PDF والفواتير والنماذج الحكومية، لأن كثيرًا من الخدمات تنجح في الويب ثم تفشل عند تنزيل مستند أو طباعته. نختبر التكبير حتى 200% وإعادة تدفق المحتوى، والوضع عالي التباين، وتقليل الحركة، والاستخدام على شاشة صغيرة. ونراجع ترتيب التركيز بعد فتح نافذة منبثقة وإغلاقها، لأن التركيز قد يضيع في مكان غير متوقع. ونفحص النماذج من حيث الربط بين التسمية والحقل، ووصف الخطأ، وعدم الاعتماد على اللون وحده. ونراجع الجداول والرسوم البيانية البديلة، والوسائط المترجمة، والروابط التي تُفتح في تبويب جديد. ونختبر العربية مع قارئ الشاشة للتأكد من نطق الأرقام والتواريخ والمصطلحات، ومن أن ترتيب القراءة يتبع المعنى لا موضع العنصر على الشاشة. ونقدم قائمة إصلاح مرتبة: ما يمنع المهمة، وما يسبب إحباطًا، وما يحتاج تحسينًا، ونراجع بيان الوصول قبل نشره. وندرب الفريق على فحص سريع قبل كل إصدار، حتى لا تعود المخالفات نفسها.
عندما نجد مشكلة، نقدم توصية قابلة للتنفيذ للفريق، لا تقريرًا يعدد المخالفات فقط. ونفضل إصلاح البنية والأنماط على إضافة طبقة فوقية لا تعالج السبب. وننصح ببيان إمكانية وصول واضح، وقناة تواصل للمستخدمين، ومراجعة دورية بعد كل تغيير في التصميم أو المكونات.
ماذا يشمل؟
- تدقيق WCAG 2.2 AA للمسارات الحرجة.
- فحص آلي عبر axe-core وLighthouse وPa11y.
- تنقل بلوحة المفاتيح وترتيب التركيز.
- اختبار قارئات الشاشة بالعربية.
- التباين والنماذج والجداول والوسائط.
- مراجعة PDF والتوافق مع المتصفحات.
المخرجات
- تقرير مخالفات مصنف بالأثر.
- توصيات إصلاح للمطورين والتصميم.
- إعادة اختبار بعد المعالجة.
- مسودة بيان إمكانية وصول.
- قائمة فحص للفريق قبل كل إصدار.
مؤشرات النجاح: انخفاض المخالفات الحرجة، نجاح رحلات الشراء والتسجيل بلوحة المفاتيح فقط، قدرة مستخدم قارئ شاشة على إكمال المهمة دون مساعدة، ووجود بيان وصول محدث. لمن تصلح: الجهات الحكومية وشبه الحكومية، والجامعات، والبنوك، والمنصات التي تخدم جمهورًا واسعًا أو تلتزم بمتطلبات شراء عامة. يمكن دمج التدقيق مع خدمات البرمجة والتطوير لمعالجة المشكلات في المصدر بدل ترقيعها لاحقًا. ونراجع مكونات التصميم المشتركة، لأن إصلاح زر أو نموذج في مكتبة المكونات يمنع تكرار المخالفة في عشرات الصفحات. ونقدم أمثلة قبل وبعد للفريق، لأن المطورين يستوعبون التوصية أسرع عندما يرون الأثر على تجربة حقيقية. ونراجع ترتيب العناوين في الصفحة، لأن قارئ الشاشة يعتمد عليه للتنقل السريع بين الأقسام.
استراتيجية الجودة وإدارة الإصدارات
عندما تنمو المنتجات والفرق، يصبح السؤال «هل اختبرنا؟» أقل أهمية من «كيف نعرف أننا جاهزون؟». استراتيجية الجودة تربط مخاطر الأعمال بخطة الاختبار والموارد والقرار. هي التي تحدد ما يُختبر يدويًا وما يُؤتمت، وما المستويات المطلوبة، ومن يملك قبول الإصدار، وما الأدلة التي يجب أن تكون موجودة قبل النشر. بدونها تتحول الجودة إلى مجموعة اجتهادات فردية تختلف من فريق إلى آخر.
نبني الاستراتيجية من أعلى إلى أسفل: أهداف الجودة، ومصفوفة مخاطر، ونطاق الاختبار، ومستوياته وأنواعه، ومعايير الدخول والخروج، وتعريف «منتهي» (Definition of Done)، وإدارة البيئات والبيانات، وخطة الأتمتة، وقائمة جاهزية الإصدار، وقرار الإطلاق، وخطة التراجع، والمراقبة بعد النشر. ونستخدم TestRail أو Xray لإدارة الحالات ودورات الاختبار، وJira لتتبع العمل والعيوب، ونربط التقارير بمؤشرات يمكن للإدارة فهمها.
نحدد نموذج التشغيل بوضوح: هل يعمل مختبرو الجودة داخل الفرق، أم في فريق مركزي، أم بمزيج؟ من يراجع المتطلبات؟ من يقرر شدة العيب؟ ما صلاحية إيقاف الإصدار؟ كيف تُدار الإصدارات الطارئة؟ نضع مسارات للقرارات لا تُترك للضغط اللحظي. ونحرص على أن يكون المطورون مسؤولين عن جودة الوحدة والتكامل، والمختبرون عن التحقق المستقل والتجربة، والمنتج عن معايير القبول، والإدارة عن قبول المخاطر المتبقية.
نقيس ما يفيد: نسبة العيوب التي وصلت إلى المستخدم، وزمن دورة الاختبار، ونسبة الاختبارات الهشة، وزمن الاستجابة لإصلاح العيوب الحرجة، ومدى قابلية التنبؤ بالإصدار. نتجنب المقاييس التي تشجع على السلوك الخاطئ مثل عدد الحالات المكتوبة أو عدد العيوب بلا سياق. ونراجع الاستراتيجية كل ربع أو بعد تغيير كبير، لأن ما يناسب فريقًا صغيرًا لا يناسب مؤسسة متعددة المنتجات. ونحدد أيضًا كيف تُدار الإصدارات الطارئة: من يوافق؟ ما الحد الأدنى من الاختبار؟ كيف يُوثق الاستثناء؟ وكيف يُغلق لاحقًا؟ ونراجع أدوار الجودة بين المنتج والتطوير والتشغيل، ونمنع ازدواجية القرار. ونضع قائمة جاهزية قصيرة يمكن قراءتها في دقائق، لأن القوائم الطويلة تُتجاهل عند الضغط. ونربط كل بوابة جودة بدليل واضح، لا بعبارة «تم الاختبار». ونساعد على بناء خطة أتمتة تدريجية مرتبطة بميزانية الفريق، لا خطة طموحة تُترك نصفها. ونقدم ورشة لتعريف الفريق بالمؤشرات وطريقة قراءتها، لأن المؤشر الذي لا يفهمه أحد لا يغير سلوكًا. ونراجع نتائج كل إصدار مع أصحاب المنتج، ونحوّل الدروس إلى تعديلات ملموسة في الخطة.
ماذا يشمل؟
- استراتيجية جودة ومصفوفة مخاطر.
- معايير الدخول والخروج وتعريف الإنجاز.
- خطة أتمتة وخطة بيئات وبيانات.
- بوابات جودة وقرار جاهزية الإصدار.
- خطة تراجع ومراقبة ما بعد النشر.
- مؤشرات ومراجعة دورية للتحسين.
المخرجات
- وثيقة استراتيجية قابلة للتنفيذ.
- قائمة جاهزية الإصدار وقرار Go/No-Go.
- مؤشرات جودة ولوحة متابعة.
- خطة تحسين على مراحل.
- تمكين الفريق عبر ورش عمل.
مؤشرات النجاح: ارتفاع قابلية التنبؤ بمواعيد الإصدار، انخفاض العيوب الهاربة، تقليل زمن دورة الانحدار، ووضوح مسؤولية القبول لدى الفريق والإدارة. لمن تصلح: الشركات التي تنتقل من إصدارات متباعدة إلى دورات أسرع، والمؤسسات متعددة المنتجات، والقطاعات المنظمة التي تحتاج أدلة على ضبط التغيير. اربط الاستراتيجية بخدمة إصلاح أخطاء المواقع لمعالجة الديون التقنية التي تكشفها المراجعة. ونربط الاستراتيجية بخريطة طريق المنتج، لأن ميزة قادمة قد تغير المخاطر وتستلزم مستويات اختبار مختلفة. ونراجع الأدوار عند كل تغيير تنظيمي، لأن غياب المالك يجعل بوابة الجودة شكلية. ونوثق الاستثناءات والموافقات على المخاطر المتبقية، حتى يكون القرار قابلًا للمراجعة لاحقًا. ونحدد مواعيد مراجعة ثابتة، لأن الجودة التي لا تُراجع تضيع بين الأولويات اليومية.
حالات استخدام عملية
الجودة تصبح واضحة عندما نراها في سياق منتج حقيقي. فيما يلي خمس حالات نعمل عليها بشكل متكرر، مع نقطة البداية، وما نختبره فعليًا، والنتيجة التي تهم صاحب العمل. الأسماء عامة، لكن التفاصيل مستمدة من طبيعة المنتجات السعودية التي تخدم مستخدمين أفرادًا أو جهات. وإذا كان منتجك لعبة أو تجربة واقع معزز أو افتراضي، فتختلف معايير القبول وتجربة الأجهزة والأداء؛ يمكنك مراجعة تطوير الألعاب والواقع المعزز لفهم هذا السياق قبل تصميم خطة الاختبار.
1. متجر إلكتروني يستعد لموسم العروض
متجر يبيع منتجات منزلية وأزياء، ويعتمد على الدفع الإلكتروني والدفع عند الاستلام، ويستخدم أكواد خصم وشحنًا متعدد الخيارات. قبل موسم العروض يخشى الفريق من تعطل الدفع أو ظهور طلبات مكررة. نبدأ بخريطة الرحلات الحرجة: البحث، صفحة المنتج، السلة، تطبيق الخصم، اختيار الشحن، إدخال العنوان العربي، الدفع عبر mada أو Apple Pay، تأكيد الطلب، ثم الإلغاء والإرجاع.
نختبر تكدس الخصومات، ونفاد المخزون أثناء الشراء، وانتهاء جلسة الدفع، وفشل مزود الدفع ثم إعادة المحاولة، وعدم تطابق المبلغ بين السلة والفاتورة. نراجع رسائل الخطأ بالعربية، وصفحة الفاتورة، وإشعارات البريد والرسائل، واتجاه RTL في شاشات الدفع. ثم ننفذ اختبار حمل على سيناريو يشبه الذروة، ونراقب قاعدة البيانات والطوابير. النتيجة خطة إصلاح مرتبة، وقائمة جاهزية للموسم، ومراقبة للطلبات الفاشلة بعد الإطلاق.
2. بوابة خدمات حكومية أو شبه حكومية
بوابة تقدم خدمة مواعيد أو طلبات مستندات، وتتكامل مع الهوية الرقمية ودفع الرسوم وإصدار ملف PDF. الجمهور واسع ومتنوع، وبعض المستخدمين يكملون الخدمة مرة واحدة في السنة، لذلك لا يمكن الاعتماد على تعلمهم للنظام. نبدأ باختبار رحلة المستخدم من أول زيارة إلى استلام المستند، مع التركيز على وضوح التعليمات، والحالات الاستثنائية، واستعادة الطلب بعد انقطاع.
نختبر الصلاحيات والأدوار، وتكامل الهوية، ورفع المستندات، وحساب الرسوم، والإلغاء والتعديل، وإشعارات الحالة، وإمكانية الوصول وفق WCAG، والعربية وقارئ الشاشة. ونراجع الأمان والبيانات الشخصية، وننفذ اختبار حمل لمواعيد الذروة. ونقدم أدلة قابلة للتدقيق، لأن الجهات الحكومية لا تحتاج فقط إلى «يعمل»، بل إلى إثبات أن الخدمة عادلة وواضحة ومتاحة ومستقرة.
3. تطبيق جوال لشركة توصيل أو خدمات
تطبيق يعتمد على الموقع والإشعارات والدفع، ويستخدمه العميل والسائق أو مقدم الخدمة. التحدي أن الجهاز والشبكة والسلوك غير متوقع. نختبر على أجهزة حقيقية من شرائح مختلفة، مع شبكة ضعيفة وانقطاع، وتبديل التطبيق، وإغلاق الشاشة، ورفض صلاحية الموقع، ووصول إشعار أثناء الطلب. ونراجع التسجيل ورمز التحقق، والروابط العميقة، ومشاركة الطلب، وتتبع الحالة.
نختبر الدفع والاسترداد، وسجلات الانهيار، واستهلاك الذاكرة، وحجم التطبيق، والتخزين الآمن للرموز. ونستخدم TestFlight وGoogle Play الداخلي قبل الإطلاق، ثم ندعم طرحًا تدريجيًا مع مراقبة الانهيارات ومعدل إكمال الرحلة. النتيجة ليست «صفر أخطاء» — فهذا وعد غير واقعي — بل مخاطر معروفة ومدارة، وقدرة على الاكتشاف والتراجع بسرعة. ونراجع أيضًا سلوك التطبيق عند تغيير اللغة أو تفعيل الوضع الداكن، لأن إعدادات الجهاز قد تكشف مشكلات تخطيط لم تظهر في الاختبار الافتراضي.
4. شركة SaaS تنشر تحديثات أسبوعية
منصة تقدم خدمة اشتراك للشركات، وتنشر ميزات صغيرة كل أسبوع. الفريق يملك اختبارات وحدة جيدة، لكنه يخسر وقتًا في انحدار يدوي طويل، وتصل أخطاء متكررة إلى العملاء. نبدأ بتحديد الرحلات التي يجب أن تعمل دائمًا، ونبني حزمة دخان سريعة في GitHub Actions، ثم نضيف اختبارات Playwright للرحلات الحرجة واختبارات API للعقود.
نربط الاختبارات ببوابات جودة: لا يتم الدمج إذا فشلت حزمة الدخان، ولا إصدار إذا لم تُحدّث نتائج الانحدار. نستخدم أعلام الميزات (Feature Flags) وطرحًا تدريجيًا، ونراقب الأخطاء والاستجابة بعد النشر. ونخصص وقتًا دوريًا لإصلاح الاختبارات الهشة. النتيجة دورة تغذية راجعة أقصر، وثقة أعلى في النشر، ووقت أقل يُصرف في التحقق اليدوي المتكرر.
5. مؤسسة ترحّل نظام ERP أو CRM
مؤسسة تنتقل من نظام قديم إلى Odoo أو Zoho أو Dynamics، وتحمل معها عملاء وأصنافًا وفواتير وصلاحيات. الخطر الأكبر ليس الشاشة الجديدة، بل البيانات والعمليات التي تعبر بين الأنظمة. نبدأ بمراجعة خطة الترحيل، ونطابق عدد السجلات والحقول الإلزامية والعلاقات، ونختبر الفواتير العربية ومتطلبات الفوترة الإلكترونية، والتقارير، ودور كل مستخدم.
نختبر التكامل مع المتجر أو بوابة الدفع أو البريد، ونراجع الصلاحيات بعد الترحيل، وننفذ UAT مع ممثلين عن الأقسام باستخدام سيناريوهات عمل حقيقية. ثم نضع خطة قطع (Cutover) وخطة تراجع، ونراقب أول أسبوع بعد الانتقال. النتيجة بيانات متسقة، ومستخدمون مدربون، وقائمة مشكلات معروفة بدل مفاجآت تظهر في أول إقفال مالي. اربط هذا السيناريو بخدمة دعم IT وERP/CRM.
في الحالات الخمس نلاحظ نمطًا متكررًا: القيمة لا تأتي من عدد الاختبارات، بل من اختيار الرحلات التي تحمل أكبر أثر. المتجر يخسر عند الدفع، والبوابة الحكومية تفقد الثقة عند تعذر إكمال الطلب، والتطبيق يفقد المستخدم عند أول انقطاع شبكة، وفريق SaaS يفقد سرعته عندما تتراكم الاختبارات الهشة، ومؤسسة ERP تفقد الثقة عندما لا تتطابق الأرقام. لذلك نبدأ دائمًا بخريطة الأثر، ثم نبني التغطية حولها، ونقيس ما تغير بعد الإصلاح. ونحرص على أن تكون كل حالة قابلة للقياس: ما المؤشر الذي سيتحسن؟ هل هو اكتمال الطلب، أم زمن الاستجابة، أم عدد طلبات الدعم، أم نسبة الأخطاء؟ بلا مؤشر واضح يتحول الاختبار إلى نشاط بلا نهاية.
أخطاء شائعة تجعل الاختبار جهدًا بلا أثر
ليست كل مشكلة في الجودة سببها نقص الأدوات أو الميزانية. في كثير من المشاريع نجد فريقًا مجتهدًا يعمل ضمن عملية معيبة، فتضيع الجهود في أنشطة لا تغير قرارًا ولا تمنع عيبًا. هذه أخطاء متكررة، مع طريقة عملية لتصحيحها.
1. اعتبار الاختبار مرحلة أخيرة
إذا وصلت الميزة إلى المختبر بعد اكتمال التصميم والتطوير، فكل عيب جوهري سيصبح مفاوضة على الوقت أو نطاق. الصواب أن يبدأ الاختبار مع المتطلب: هل معيار القبول واضح؟ هل الحالة الاستثنائية معرّفة؟ هل البيانات متاحة؟ مراجعة مبكرة توفر أسابيع لاحقًا، لأنها تمنع بناء الشيء الخطأ لا لأنها تكتشفه بعد بنائه.
2. قياس الجودة بعدد الحالات أو العيوب
عدد الحالات المكتوبة لا يقول شيئًا عن المخاطر المغطاة، وعدد العيوب قد يرتفع لأن الفريق يختبر أكثر أو لأن المنتج أسوأ. الأفضل قياس العيوب التي وصلت إلى المستخدم، ونسبة تغطية الرحلات الحرجة، وزمن التحقق، ونسبة إعادة الفتح. هذه المقاييس توجه القرار، أما الأرقام الكبيرة بلا سياق فتصنع شعورًا زائفًا بالإنجاز.
3. أتمتة كل شيء أو أتمتة غير المستقر
الأتمتة الشاملة تبدو طموحة لكنها تخلق حزمة ضخمة بطيئة وصعبة الصيانة. والأسوأ أتمتة واجهات تتغير كل أسبوع قبل تثبيت المتطلبات. ابدأ بالرحلات الحرجة والمستقرة، وقس الوقت الذي توفرّه، وأضف اختبارات جديدة عندما تثبت الحاجة. لا تجعل عدد الاختبارات هدفًا؛ اجعل الثقة في نتائجها هي الهدف.
4. نسخ بيانات الإنتاج إلى بيئة الاختبار
هذه ممارسة مريحة وخطيرة. بيانات العملاء الحقيقية قد تحتوي هواتف وعناوين وبيانات دفع، وبيئة الاختبار غالبًا أقل حماية وأكثر وصولًا. استخدم بيانات اصطناعية أو مقنعة، وحدد من يحتاج الوصول، واحذف البيانات عند انتهاء الحاجة. مبادئ PDPL لا تنطبق على الإنتاج فقط؛ بل على كل مكان تُعالج فيه البيانات الشخصية، بما في ذلك بيئة الاختبار.
5. التعامل مع العربية كترجمة
استبدال النصوص الإنجليزية بعربية لا يجعل المنتج عربيًا. قد تنكسر المحاذاة، وتنعكس الأيقونات، وتختفي المسافات، وتتغير أطوال الأزرار، وتفشل التواريخ والأرقام. اختبر العربية كلغة أولى لا كحالة إضافية، واستخدم مختبرًا يقرأ النص ويفهم السياق. هذه المراجعة تكشف أخطاء لا تظهر في أي أداة آلية.
6. بيئة اختبار لا تشبه الإنتاج
اختلاف إصدار قاعدة البيانات، أو غياب خدمة خارجية، أو تعطيل التخزين المؤقت، قد يخفي عيبًا أو يخلق عيبًا وهميًا. لا تحتاج إلى نسخة مطابقة تمامًا، لكن يجب أن تكون الفروق معروفة وموثقة. كل نتيجة تُنسب إلى بيئة، وكل قرار إطلاق يجب أن يعرف ما لم يُختبر فيها.
7. التعايش مع الاختبارات الهشة
اختبار يفشل أحيانًا بسبب التوقيت أو البيانات أو الاعتماد على اختبار آخر يُعلّم الفريق تجاهل الأحمر. عالج السبب أو احذف الاختبار، ولا تضع «إعادة تشغيل» كحل دائم. الحزمة التي لا يثق بها أحد أسوأ من عدم وجود حزمة، لأنها تستهلك وقتًا وتعطي إحساسًا زائفًا بالتغطية.
8. إهمال غير الوظيفي حتى وقت متأخر
الأداء والأمان وإمكانية الوصول والتوافق ليست «تحسينات» تُضاف بعد اكتمال الوظائف. قرار معماري واحد قد يجعل تحسين الأداء مكلفًا، أو يجعل إصلاح الوصول إعادة بناء. ضع الحدود غير الوظيفية في المتطلبات، واختبرها تدريجيًا، ولا تنتظر اختبار الحمل قبل الإطلاق بأيام.
| الخطأ | الأثر المعتاد | التصحيح العملي |
|---|---|---|
| تأجيل الاختبار | ضغط على الفريق وتنازل عن النطاق | معايير قبول ومراجعة مبكرة |
| مقاييس شكلية | جهد كبير بلا تحسن في التجربة | مؤشرات هاربة وزمن تحقق |
| بيانات إنتاج غير مقنعة | خطر خصوصية وامتثال | بيانات اصطناعية وصلاحيات مؤقتة |
| تجاهل العربية | تجربة مكسورة لجمهورك الأساسي | اختبار RTL ومحتوى عربي أصلي |
| اختبارات هشة | فقدان الثقة وتجاهل النتائج | عزل واستقرار وصيانة دورية |
انتبه إلى «النجاح» في بيئة المطور
عبارة «يعمل عندي» ليست دليل جودة. قد يعمل على جهاز بمواصفات عالية وشبكة مستقرة وبيانات نظيفة، ثم يفشل على جهاز مستخدم بشبكة ضعيفة وحساب قديم. الجودة تُقاس على بيئة قريبة من الواقع، وببيانات متنوعة، وبمستخدمين مختلفين، لا على ظروف مثالية.
كيف نعمل؟ منهجية من ست مراحل
المنهجية مصممة لتقليل المفاجآت وجعل الجودة قابلة للمتابعة. نتفق على مخرجات كل مرحلة قبل الانتقال إلى التالية، ونوثق الافتراضات والقرارات. بعض المشاريع تمر بالمراحل الست كاملة، وبعضها يبدأ من مرحلة متقدمة إذا كانت هناك مراجعة سابقة موثوقة أو فريق داخلي ناضج. ونحدد من يملك قرار القبول في كل مرحلة، وكيف تُصعّد المخاطر إذا ظهرت.
الاكتشاف وتقييم المخاطر
نجمع المعلومات عن المنتج والمستخدمين والمنصات والتكاملات وإيقاع الإصدار. نحدد الرحلات الحرجة، والبيانات الحساسة، والمخاطر التجارية والتقنية، وما يعنيه النجاح لصاحب العمل. نخرج بخريطة مخاطر أولية وقائمة أسئلة تحتاج حسمًا قبل التخطيط. ونحدد أيضًا ما هو خارج النطاق، لأن قائمة «ما لن نختبره» تحمي الجميع من توقعات غير واقعية.
تصميم الاستراتيجية وخطة الاختبار
نختار مستويات الاختبار وأنواعه وأدواته، ونحدد النطاق والبيئات والبيانات والأدوار والجدول. نكتب معايير الدخول والخروج، ونحدد ما سيُؤتمت وما سيبقى يدويًا، ونضع مؤشرات القياس. الخطة وثيقة عمل حية، لا ملفًا يُكتب للاجتماع الأول ثم يُنسى. ونستخدم TestRail أو Xray لتنظيم الحالات، ونحدد طريقة التواصل اليومية والتصعيد.
تهيئة البيئة والبيانات
نجهز بيئة قريبة من الإنتاج، وحسابات اختبار بصلاحيات محددة، وبيانات اصطناعية أو مقنعة، ومحاكاة للخدمات الخارجية عند الحاجة. نتحقق من الوصول والشبكات والإعدادات، ونوثق الفروق عن الإنتاج. هذه المرحلة غالبًا تُختصر، وهي سبب كثير من النتائج المضللة. ونحتفظ بنسخة قابلة لإعادة الإنشاء من البيانات الاصطناعية، حتى لا تصبح البيئة نفسها مشروعًا هشًا.
تنفيذ الاختبارات
ننفذ الاختبارات الوظيفية والاستكشافية والآلية واختبارات API والأداء والأمان وإمكانية الوصول بحسب الخطة. نجري فرزًا يوميًا للنتائج، ونميز بين عيب مؤكد وسؤال يحتاج توضيحًا. كل نتيجة تُسجل بدليل وبيئة، ويُحدّث تقدم التغطية مقابل المخاطر. ونستخدم Allure أو تقارير CI لتجميع النتائج، ونعقد فرزًا قصيرًا مع المطورين والمنتج لتسريع القرار.
إدارة العيوب وإعادة الاختبار
نصنف العيوب بالشدة والأولوية، ونحدد المالك والموعد، ونتابع الإصلاح مع الفريق. بعد الإصلاح نعيد الاختبار في البيئة الصحيحة، ثم نضيف اختبار انحدار يمنع عودة العيب. لا يُغلق العيب لمجرد أن المطور قال إنه أُصلح؛ يُغلق بدليل. ونفرق بين عيب مؤكد وطلب تحسين، ونتفق على تعريف «مغلق» قبل بدء الدورة.
قرار الإطلاق والمراقبة
نجمع نتائج الاختبارات والمخاطر المتبقية في تقرير جاهزية واضح، ونساعد الإدارة على قرار Go/No-Go. بعد الإطلاق نراقب الأخطاء والأداء والملاحظات، ونراجع ما لم يظهر في الاختبار. كل دورة تنتهي بدروس تُحسّن الخطة التالية. ونسلم قائمة توصيات لما بعد الإطلاق: ما يراقب، وما يعاد اختباره، وما يدخل في الخطة القادمة. ونتفق على موعد مراجعة ما بعد الإطلاق، لأن بعض المشكلات لا تظهر إلا مع بيانات أو سلوك مستخدمين حقيقيين.
هذه المراحل ليست خطًا مستقيمًا دائمًا. قد نعود من التنفيذ إلى التخطيط إذا تغير النطاق، أو من إدارة العيوب إلى التهيئة إذا اتضح أن المشكلة في البيانات. الأهم أن يكون لكل عودة سبب موثق، لا أن تتحول المنهجية إلى قالب جامد. ونراجع في نهاية كل دورة ما تعلّمناه من العيوب التي فاتتنا، ونحوّله إلى تعديل في قائمة الفحص أو الأتمتة. ونحدد في كل دورة ما الذي سيتوقف وما الذي سيستمر، حتى لا تتحول المشاريع إلى متابعة مفتوحة بلا نهاية.
قرار الإطلاق قرار أعمال، لا قرار تقني فقط
قد يكون المنتج خاليًا من العيوب الحرجة لكنه لا يحقق قيمة كافية، وقد تكون هناك مخاطر مقبولة مقابل فرصة سوقية. دورنا أن نعرض المخاطر بوضوح، لا أن نقرر بدل صاحب العمل. نعطي توصية، ونوضح ما لم يُختبر وما قد يحدث، ونترك القرار لمن يملك مسؤوليته.
المخرجات والتسليمات
التسليم الجيد لا يُقاس بعدد الملفات، بل بقدرة الفريق على فهم الحالة واتخاذ قرار. لذلك نفصل بين ما تحتاجه الإدارة وما يحتاجه المطور، ونحافظ على رابط واحد بين المتطلب والاختبار والعيب والقرار. هذه أهم المخرجات التي تحصل عليها، ويمكن تعديلها بحسب نطاق المشروع.
- استراتيجية الجودة وخطة الاختبار: النطاق، والمخاطر، والمستويات، والبيئات، والبيانات، والأدوار، والجدول، ومعايير الدخول والخروج.
- مصفوفة تغطية المخاطر: جدول يربط كل رحلة أو ميزة حرجة بالمخاطر والاختبارات والنتائج، حتى يرى القارئ ما غُطي وما بقي.
- حالات اختبار موثقة: خطوات وشروط مسبقة ونتائج متوقعة، مع بيانات اختبار قابلة لإعادة الاستخدام، في TestRail أو Xray أو Jira.
- تقارير الجلسات الاستكشافية: ملاحظات منظمة عن التجربة والسلوك والحالات غير المتوقعة، لا مجرد قائمة أخطاء.
- حزمة أتمتة قابلة للتشغيل: مستودع منظم، وتعليمات تشغيل، وبيانات اختبار، وتكامل مع خط النشر، وتقارير Allure.
- سجل عيوب موحد: معرف، ووصف، وخطوات إعادة، ودليل، وشدة، وأولوية، ومالك، وحالة، وتاريخ إغلاق.
- تقارير الاختبارات غير الوظيفية: نتائج الأداء وملاحظات الأمان وتقرير إمكانية الوصول والتوافق، كل منها بمنهجية وحدود واضحة.
- تقرير جاهزية الإصدار: ملخص تنفيذي، وما تم اختباره، والمخاطر المتبقية، والتوصية، وشروط الإطلاق أو التراجع.
- بيانات وبيئة اختبار موثقة: كيفية إنشائها وتنظيفها وحمايتها، والفروق عن الإنتاج، حتى تكون النتائج قابلة للتفسير.
- جلسة تسليم وتمكين: شرح للفريق والإدارة، ونقل معرفة، وخطة تحسين لما بعد المشروع.
نراعي أن بعض الفرق تحتاج مخرجات مختصرة تناسب اجتماعًا إداريًا، وبعضها يحتاج تفاصيل تقنية كاملة. نتفق على الشكل مبكرًا، ونستخدم لغة واضحة تفصل بين الحقيقة والاحتمال والتوصية. وإذا كانت هناك نتيجة لم تُختبر بسبب قيد بيئي أو زمني، نذكرها صراحة بدل ترك انطباع خاطئ بالتغطية الكاملة. نستخدم TestRail أو Xray لإدارة الحالات وJira لتتبع العيوب، ويمكن الاستعانة بمساعدات مدعومة بالذكاء الاصطناعي لتوليد أفكار اختبار أولية أو تلخيص النتائج، مع إبقاء المراجعة والقرار البشري؛ اطّلع على وكلاء الذكاء الاصطناعي والأتمتة. ونقدم الملفات بصيغة يمكن للفريق تعديلها، لا صورًا مغلقة، حتى تبقى وثائق حية بعد انتهاء المشروع. ونحدد مالك كل مستند ومكان حفظه وموعد مراجعته، ونصدر الحالات والنتائج بصيغ قابلة للتصدير حتى لا ترتبط المخرجات بأداة واحدة.
التسعير والعوامل المؤثرة
لا ننشر سعرًا ثابتًا لخدمات ضمان الجودة لأن كل منتج يختلف في حجمه ومخاطره وإيقاع إصداره. اختبار متجر صغير لا يشبه اختبار منصة متعددة الخدمات، ومراجعة استراتيجية لفريق ناشئ لا تشبه برنامج جودة لمؤسسة متعددة المنتجات. نقدم عرضًا واضحًا بعد جلسة اكتشاف قصيرة، يحدد ما يشمله السعر وما لا يشمله، وعدد دورات الاختبار، وحدود إعادة الاختبار.
| نموذج التعاون | الأنسب لمن | ما يشمله عادة |
|---|---|---|
| تشخيص جودة سريع | فريق يريد معرفة نقاط ضعفه قبل قرار | مراجعة منتج وبيئة وعملية، عينة اختبار، تقرير فجوات، جلسة توصيات |
| مشروع اختبار محدد | إطلاق ميزة أو نسخة جديدة | خطة، حالات، تنفيذ يدوي وآلي حسب الحاجة، سجل عيوب، تقرير جاهزية |
| بناء حزمة أتمتة | فريق ينشر بانتظام ويريد تقليل التحقق اليدوي | اختيار الرحلات، بناء الحزمة، دمج CI، تقارير، توثيق وصيانة أولية |
| QA مستمر | منتج حي يحتاج تغطية دورية | دورات اختبار شهرية أو ربعية، أتمتة، اختبار انحدار، مؤشرات |
| استراتيجية وتمكين | مؤسسة تبني قدرة جودة داخلية | استراتيجية، نموذج تشغيل، أدوات، تدريب، مراجعة تنفيذ |
العوامل التي ترفع أو تخفض التكلفة
- عدد المنصات: الويب والجوال ولوحة الإدارة وAPI تضيف نطاقًا ووقتًا، خصوصًا إذا اختلفت سلوكياتها.
- تعقيد الرحلات: الدفع متعدد الخطوات والصلاحيات والتكاملات يحتاج سيناريوهات أعمق من صفحة تعريفية.
- عدد التكاملات الخارجية: كل مزود دفع أو رسائل أو شحن أو ERP يحتاج بيئة اختبار ومحاكاة وتحققًا مستقلًا.
- وتيرة الإصدار: النشر اليومي يحتاج أتمتة وبوابات جودة أكثر من النشر الربعي.
- عمق الاختبار غير الوظيفي: الأداء والأمان وإمكانية الوصول تضيف تخصصًا ووقتًا، لكنها تمنع مخاطر باهظة.
- حالة الأتمتة والبيئة: فريق بلا اختبارات أو بيئة غير منضبطة يحتاج تأسيسًا قبل التوسع.
- الاستعجال والتزامن: نافذة إطلاق ضيقة قد تتطلب موارد إضافية أو تقسيم النطاق.
- الاستمرارية: البرنامج الشهري أو الربعي غالبًا أوفر من مشاريع منفصلة متكررة، لأنه يبني معرفة متراكمة.
قبل أن تطلب عرضًا
لا تبدأ بشراء أداة أو حزمة أتمتة قبل معرفة المخاطر. كثير من الفرق تنفق على أدوات لا تستخدمها بينما تحتاج إلى معايير قبول أو بيئة اختبار أو خمسة سيناريوهات حرجة. ابدأ بتشخيص قصير، ثم اشترِ ما يسد فجوة محددة، وقس الأثر بعد شهرين.
للحصول على عرض دقيق، أرسل لنا: وصف النشاط، والمنصات المشمولة، والبيئات المتاحة، وأهم ثلاث رحلات للمستخدم، والتكاملات الخارجية، وهل توجد بيانات دفع أو بيانات شخصية، ووتيرة الإصدار، والموعد المستهدف. يمكننا البدء بجلسة اكتشاف قصيرة دون التزام، ثم نرشح النطاق المناسب بدل بيع أكبر حزمة ممكنة.
الأسئلة الشائعة
ما الفرق بين ضمان الجودة واختبار البرمجيات؟
ضمان الجودة هو النظام الذي يجعل الجودة ممكنة: متطلبات واضحة، ومعايير قبول، ومراجعات، وبيئات منضبطة، وأتمتة مناسبة، ومؤشرات، ومسؤوليات. أما الاختبار فهو النشاط الذي يتحقق من سلوك المنتج ويكشف الفجوات. يمكن أن تختبر كثيرًا وتعاني من جودة ضعيفة إذا كانت المتطلبات غامضة والأخطاء تتكرر بلا تحليل. لذلك نبدأ بالاستراتيجية، ثم نختار الاختبارات التي تخدمها.
هل نحتاج فريق QA داخلي أم يمكن الاستعانة بفريق خارجي؟
يعتمد على حجم المنتج ووتيرة الإصدار وطبيعة المخاطر. الفريق الداخلي يفهم السياق ويستطيع الاستجابة اليومية، بينما الفريق الخارجي يضيف تخصصًا واستقلالية وقدرة على تغطية مراحل الذروة. كثير من الشركات تبدأ بفريق خارجي لبناء العملية والأتمتة، ثم تدرب فريقًا داخليًا يتولى التشغيل. الأهم أن تكون المسؤوليات مكتوبة، وأن تنتقل المعرفة لا أن تبقى محصورة لدى الطرف الخارجي.
كم يستغرق مشروع اختبار كامل؟
المدة تختلف بحسب عدد المنصات والرحلات والتكاملات ومدى جاهزية البيئة. مشروع لميزة واحدة قد يستغرق أيامًا قليلة، بينما منتج متعدد الخدمات يحتاج أسابيع. نفضل تقسيمه إلى دورات قصيرة: تشخيص، ثم تغطية الرحلات الحرجة، ثم توسيع. ونحدد في العرض نقاط التسليم بوضوح. لا نعطي تاريخًا ثابتًا قبل فهم النطاق، لأن الوعود المتسرعة تتحول غالبًا إلى تضحية بالجودة.
هل يمكن أتمتة جميع الاختبارات؟
لا، وليس من الحكمة محاولة ذلك. الأتمتة تناسب السلوك المتكرر والمستقر وذي القيمة العالية، مثل الدخول والبحث والدفع وإدارة الحساب. أما التقييم البصري الدقيق، واستكشاف تجربة جديدة، والحكم على وضوح المحتوى العربي، فيحتاج مختبرًا بشريًا. الأتمتة أيضًا لها تكلفة صيانة، وإذا أُسيء اختيار نطاقها تنتج حزمة هشة تستهلك الوقت بدل أن توفره.
كيف تختبرون اللغة العربية وواجهات RTL؟
نختبر العربية كلغة أساسية لا كترجمة. نراجع اتجاه التخطيط، والمحاذاة، وترتيب العناصر، والأيقونات، والجداول، والرسوم، والتنقل، ولوحة المفاتيح العربية، والأرقام والتواريخ والعملات، والنصوص المختلطة عربي وإنجليزي. ونختبر البحث باختلافات الهمزة والتاء المربوطة والتشكيل، ونراجع رسائل الأخطاء والفواتير وملفات PDF. ونضيف اختبار قارئ الشاشة العربي للتأكد من أن النطق وترتيب القراءة مفهومان.
كيف تتعاملون مع بيانات العملاء في بيئة الاختبار وفق PDPL؟
لا نعتمد على نسخ بيانات الإنتاج كحل افتراضي. نستخدم بيانات اصطناعية أو بيانات مقنعة، ونحدد صلاحيات الوصول إلى بيئة الاختبار، ونمنع استخدام بيانات دفع حقيقية، ونحذف البيانات عند انتهاء الحاجة. نوثق من اطّلع على ماذا ومتى، ونطبق مبدأ تقليل البيانات. وإذا كان المشروع يتطلب بيانات واقعية، نتفق على إجراء تقنيع واضح ومراجعة خصوصية قبل الاستخدام.
هل تختبرون على أجهزة حقيقية أم محاكيات فقط؟
نستخدم المحاكيات للسرعة والتغطية الأولية، لكن القرار النهائي للتطبيقات الحرجة يعتمد على أجهزة حقيقية عبر مختبرات مثل BrowserStack أو Sauce Labs، إضافة إلى أجهزة محلية عند الحاجة. المحاكي لا يعكس بدقة أداء الكاميرا أو البطارية أو الشبكة أو سلوك لوحة المفاتيح العربية. نحدد مصفوفة الأجهزة بناءً على جمهورك وبيانات الاستخدام، لا على أحدث الأجهزة فقط.
هل اختبار الأمان ضمن الخدمة أم يحتاج اختبار اختراق منفصلًا؟
اختبار الأمان داخل ضمان الجودة يغطي الأساسيات ومنطق الصلاحيات والثغرات الشائعة، ويكشف كثيرًا من المشكلات قبل الإنتاج. لكنه لا يغني عن اختبار اختراق متخصص يبحث في سلاسل استغلال معقدة ويقيس الأثر الأمني الكامل. إذا كان منتجك يتعامل مع مدفوعات أو بيانات حساسة أو متطلبات امتثال، ننصح بدمج الخدمتين: اختبار مستمر داخل الجودة، واختبار اختراق دوري مستقل.
كيف تقيسون نجاح مشروع الجودة؟
نبدأ بمؤشرات مرتبطة بهدفك: انخفاض العيوب التي تصل إلى المستخدم، وارتفاع تغطية الرحلات الحرجة، وتقليل زمن التحقق من الإصدار، وانخفاض نسبة إعادة فتح العيوب، وتحسن اكتمال رحلة المستخدم. لا نستخدم عدد الحالات أو عدد الاختبارات كدليل نجاح بحد ذاته. ونراجع المؤشرات معك بعد كل دورة، لأن ما يهم مؤسسة قد لا يهم أخرى.
هل تعملون مع فرق Scrum وAgile؟
نعم، ونتكيف مع إيقاع الفريق. يمكن أن نشارك في تخطيط السبرنت، ونساعد في كتابة معايير القبول، وننفذ اختبارات داخل السبرنت، ونقدم تقريرًا قبل مراجعة السبرنت. ونستخدم أعلام الميزات والطرح التدريجي عندما يكون النشر متكررًا. الأهم أن تكون الجودة جزءًا من تعريف الإنجاز، لا نشاطًا منفصلًا يبدأ بعد انتهاء السبرنت.
ما الأدوات التي تستخدمونها؟
نختار الأداة بحسب السياق لا العكس. نستخدم Playwright وCypress وSelenium لأتمتة الويب، وAppium مع BrowserStack أو Sauce Labs للجوال، وPostman وREST Assured لاختبار API، وk6 وJMeter وGatling للأداء، وOWASP ZAP وBurp Suite للأمان، وaxe-core وLighthouse وPa11y لإمكانية الوصول، وTestRail أو Xray وJira للإدارة، وGitHub Actions أو GitLab CI للتكامل، وAllure للتقارير. ولا نربط جودة العمل بعدد الأدوات.
كيف نبدأ؟
أرسل وصفًا مختصرًا للمنتج والمنصات وأهم الرحلات والمخاطر التي تقلقك. نرتب جلسة اكتشاف قصيرة نحدد فيها الهدف والنطاق والبيئات المتاحة والقيود. ثم نرسل عرضًا يتضمن المراحل والمخرجات والمدة والتكلفة، ونبدأ بتشخيص أو دورة اختبار محددة. لا تحتاج إلى معرفة تقنية مسبقة؛ سنشرح الخيارات بلغة أعمال ونوضح ما ننصح به وما لا ننصح به.
جاهز لتعرف أين تخسر الجودة قبل أن يخسرها مستخدمك؟
ابدأ بجلسة اكتشاف قصيرة. نحدد الرحلات الحرجة والمخاطر والخطوة التالية، دون التزام.