خطوات اختبار تطبيق الويب قبل الإطلاق للجمهور

ابدأ اختبار تطبيق الويب قبل الإطلاق بورقة واحدة: اكتب المسارات التي لا يجوز أن تفشل — التسجيل، الشراء، الحجز — ثم نفّذها بنفسك على هاتف حقيقي قبل أي أداة أو تقرير. هذه الجلسة الواحدة تكشف أكثر من نصف المشكلات. الباقي يأتي من اختبارات الأداء والتوافق والأمان بترتيب واضح.

وأنا لا أتحدث هنا عن منهجية هندسية معقّدة. أتحدث عن خطة يستطيع صاحب مشروع غير تقني تنفيذها في أسبوع، وينام بعدها مرتاحًا ليلة الإطلاق.

ابدأ بقائمة المسارات الحرجة لا بالتفاصيل الصغيرة

المسار الحرج هو أي رحلة إذا تعطّلت خسرت مالًا أو عميلًا. في متجر إلكتروني بالرياض، المسار هو: فتح الصفحة الرئيسية ← البحث عن منتج ← الإضافة للسلة ← إدخال العنوان ← الدفع ← وصول رسالة التأكيد. ست خطوات فقط، لكنها تحمل 90% من قيمة التطبيق.

سجّل في جدول بسيط: اسم المسار، الخطوات، النتيجة المتوقعة، النتيجة الفعلية. لا تحتاج أدوات فاخرة؛ ملف Google Sheets يكفي تمامًا الآن.

رتّب بعدها المسارات حسب الأثر المالي. الدفع أولًا. تعديل الملف الشخصي في الأخير.

• التسجيل والدخول: حساب جديد، تسجيل خروج، دخول مرة أخرى، استعادة كلمة المرور.
• المعاملة: شراء أو حجز أو إرسال طلب، مع تأكيد مكتوب واضح للمستخدم.
• الإدارة: هل ترى أنت — صاحب المشروع — الطلب الجديد في لوحة التحكم فورًا؟
• الإشعارات: بريد أو رسالة واتساب أو SMS تصل فعلًا لا نظريًا.

وهنا تفصيلة يعرفها من جرّب فقط: اختبر كل مسار في نافذة تصفّح خاص. متصفحك يحتفظ بجلستك وبملفات مؤقتة، فيمر التطبيق بنجاح مزيّف عندك ويفشل عند أول زائر جديد. رأيتُ هذا في تطبيق حجز مواعيد كان يعمل ببراعة على جهاز المؤسس وينهار على أي جهاز آخر، لأن الصفحة كانت تعتمد على مستخدم مسجّل مسبقًا.

خصّص ساعتين لهذه الجلسة، وسجّل شاشتك أثناء التنفيذ. مراجعة التسجيل لاحقًا تلتقط أشياء لا تلاحظها وأنت منشغل بالنقر. وإن كنت لا تزال في مرحلة تشكيل الفكرة، فقراءة دليل بناء التطبيقات بالذكاء الاصطناعي توفّر عليك اختبار ميزات لم تكن تحتاجها أصلًا.

ما هي الاختبارات الوظيفية التي لا يجوز تخطيها؟

لا تتخطَّ أبدًا أربعة اختبارات: التسجيل والدخول واستعادة كلمة المرور، عملية الدفع أو الحجز من بدايتها لنهايتها، وصول الإشعارات والبريد فعليًا، وصلاحيات المستخدمين بحيث لا يرى مستخدم بيانات غيره. هذه الأربعة تحمي إيرادك وسمعتك، وأي خلل فيها يعني عميلًا مفقودًا في أول يوم.

بعد هذه الأربعة، انتقل إلى ما أسميه «الاختبار العكسي». لا تجرّب الطريق الصحيح فقط، بل حاول كسر التطبيق عن قصد.

اضغط زر الإرسال مرتين بسرعة. هل تحصل على طلبين؟ في تطبيق توصيل خليجي أنتج هذا فاتورتين للعميل نفسه — كارثة صغيرة كان يمكن منعها بتعطيل الزر بعد النقرة الأولى.

ثم أوقف الإنترنت في منتصف عملية الدفع وأعده. ماذا يحدث؟ الرسالة المطلوبة هي «تمت العملية» أو «فشلت العملية»، لا شاشة بيضاء تترك العميل حائرًا.

• النقرة المزدوجة: نقرتان سريعتان لا تُنشئان طلبين.
• زر الرجوع: العودة للخلف بعد الدفع لا تعيد تنفيذ العملية.
• الرابط المباشر: لصق رابط صفحة داخلية في نافذة جديدة يعمل ولا يعطي خطأ 404.
• الصلاحيات: افتح رابط طلب مستخدم آخر برقم مختلف؛ يجب أن يُرفض.
• التحديث المفاجئ: اضغط F5 في منتصف نموذج طويل ولاحظ هل تضيع البيانات كلها.

وثّق كل خلل بلقطة شاشة ورقم خطوة. «الدفع لا يعمل» ليست تقريرًا، بل شكوى. أما «بعد إدخال بطاقة مدى واختيار التوصيل السريع تظهر رسالة خطأ 500» فهي تقرير قابل للإصلاح في دقائق. الفرق بين الصياغتين قد يساوي يومين من العمل الضائع.

النماذج والمدخلات: حيث تتحطم معظم التطبيقات

النماذج هي المكان الأول للأعطال، وخصوصًا في السوق الخليجي بسبب اختلاف صيغ الأرقام والأسماء. اختبر حقل الهاتف بأربع صيغ: 0501234567 و+966501234567 و00966501234567 و«٠٥٠١٢٣٤٥٦٧» بالأرقام العربية. الصيغة الأخيرة تفشل في أغلب التطبيقات التي أفحصها، لأن أحدًا لم يتخيّل أن المستخدم قد يكتب بلوحة مفاتيح عربية.

جرّب الأسماء الطويلة أيضًا. اكتب «عبد الرحمن بن محمد بن عبد الله العتيبي» وشاهد هل يُقتطع في الفاتورة أو يخرج عن حدود التصميم.

الحقول الفارغة قصة أخرى. اترك كل شيء فارغًا واضغط إرسال. الرسالة يجب أن تكون بالعربية، واضحة، وأسفل الحقل نفسه — لا تحذيرًا إنجليزيًا بلغة تقنية أعلى الصفحة.

• البريد الخاطئ: أدخل «ahmed@@gmail» — يجب أن يُرفض بلطف.
• الأرقام الغريبة: في حقل الكمية أدخل -3 ثم 0 ثم 9999.
• الملفات الكبيرة: ارفع صورة بحجم 15 ميجابايت من كاميرا آيفون؛ كثير من الأنظمة تتجمد بصمت.
• النص الطويل: الصق 2000 حرف في خانة الملاحظات.
• الرموز: ضع وسم سكربت داخل حقل الاسم؛ يجب ألا يُنفَّذ ولا يكسر الصفحة.

وأهم نقطة يغفلها الجميع: رسالة التأكيد. اختبرها على Gmail وOutlook وبريد شركتك، وافتح مجلد الرسائل المزعجة بنفسك. إذا لم تُضبط سجلات SPF وDKIM لنطاقك، ستهبط رسائل التأكيد في السبام، وسيظن العميل أن طلبه لم ينجح فيكرّره أو ينسحب. حدث ذلك مع متجر في دبي خسر جزءًا كبيرًا من عملائه في أسبوعه الأول قبل أن ينتبه أحد. تفاصيل ضبط النطاق والبريد ستجدها في متطلبات نشر تطبيق ويب.

قياس الأداء بأرقام لا بإحساس

«التطبيق سريع عندي» ليس قياسًا. افتح تقرير PageSpeed Insights من Google، وشغّل الفحص على الجوال لا على سطح المكتب — الفرق بينهما مذهل. تشير أبحاث Google حول سلوك مستخدمي الجوال إلى أن نسبة كبيرة من الزيارات تُهجر عندما يتجاوز التحميل ثلاث ثوانٍ. هذا وحده يبرّر يومًا كاملًا من التحسين.

استهدف مؤشرات Core Web Vitals: زمن أكبر عنصر مرئي (LCP) دون 2.5 ثانية، واستقرار التصميم (CLS) دون 0.1. ولا تكتفِ بالمختبر — افتح التطبيق من شبكة جوال داخل مول مزدحم، فهذه بيئة عميلك الحقيقية لا شبكة الألياف في مكتبك.

الصور متّهم أول في أغلب الحالات التي عالجتها. صورة منتج بعرض 4000 بكسل تُعرض داخل مربع 300 بكسل تعني إهدارًا صافيًا. صغّرها وحوّلها إلى صيغة WebP.

• حجم الصفحة: اجعله تحت 2 ميجابايت للصفحة الرئيسية.
• الخطوط العربية: خط واحد بوزنين يكفي؛ كل وزن إضافي يكلّف مئات الكيلوبايتات.
• الاستعلامات البطيئة: ابحث بكلمة شائعة وقِس الزمن بساعة هاتفك.
• الضغط المتزامن: اطلب من عشرة أشخاص فتح التطبيق في اللحظة نفسها.

اختبار التحمّل لا يحتاج أدوات مؤسسية باهظة. مجموعة واتساب فيها خمسة عشر صديقًا، وموعد محدّد الساعة التاسعة مساءً، ورسالة «افتحوا الرابط الآن». إن صمد التطبيق فأنت جاهز لحملة تسويقية صغيرة، وإن تجمّد فقد اكتشفت سقفك مجانًا. سجّل الرقم واعمل عليه، فالنمو المفاجئ عبر منشور واحد على انستقرام يحدث كثيرًا في الخليج.

التوافق: الأجهزة والمتصفحات واتجاه العربية

افتح تطبيقك على خمسة أجهزة حقيقية على الأقل: آيفون حديث، آيفون قديم بشاشة صغيرة، سامسونج، جهاز أندرويد اقتصادي، وحاسوب مكتبي. لماذا الجهاز الاقتصادي؟ لأن شريحة واسعة من المستخدمين في السوق الخليجي تعتمد هواتف متوسطة، وما ينساب على أحدث آيفون قد يتعثّر على معالج أقدم بأربع سنوات.

Safari هو المتصفح الذي يفاجئك دائمًا. ميزات تعمل في Chrome بلا اعتراض تنكسر فيه بهدوء، خاصة في حقول التاريخ والوقت وتشغيل الفيديو التلقائي. اختبر عليه أولًا لا أخيرًا.

ثم مسألة الاتجاه. تطبيق عربي يعني RTL كاملًا لا نصفيًا.

• الأيقونات: سهم «التالي» يشير لليسار في الواجهة العربية.
• العملة: «120 ر.س» تظهر بترتيب صحيح ولا تنقلب إلى «س.ر 120».
• خلط اللغتين: اسم إنجليزي داخل جملة عربية لا يفسد ترتيب السطر.
• التواريخ: هل يظهر التقويمان الميلادي والهجري حيث يلزم؟ في الخدمات التعليمية والحكومية بالسعودية هذا مطلب واقعي.
• الكتابة: مؤشر النص يبدأ من اليمين في الحقول العربية.

ولا تنسَ الشاشات الصغيرة جدًا. افحص بعرض 320 بكسل عبر أدوات المطوّر في المتصفح (اضغط F12 ثم اختر جهازًا)؛ ستجد أزرارًا متراكبة ونصوصًا مقطوعة لم ترها من قبل. وإن كان تطبيقك ثنائي اللغة فالتبديل بين العربية والإنجليزية يستحق فحصًا مستقلًا كما شرحنا في نشر تطبيق متعدد اللغات. المستخدم يبدّل اللغة في منتصف الشراء أكثر مما تتوقع.

الأمان والامتثال قبل وصول أول عميل

هذه المرحلة ليست ترفًا قانونيًا. نظام حماية البيانات الشخصية السعودي (PDPL) الذي تشرف عليه «سدايا» يفرض التزامات واضحة على أي جهة تجمع بيانات أفراد داخل المملكة، وفي الإمارات هناك المرسوم بقانون اتحادي رقم 45 لسنة 2021. إن كنت تجمع اسمًا ورقم هاتف فقط، فأنت داخل النطاق.

ابدأ بالأساسيات التي تُنجز خلال ساعة:

• شهادة HTTPS: القفل يظهر في كل الصفحات لا في الرئيسية وحدها.
• الخصوصية والشروط: صفحتان بالعربية، مع اسم الجهة ووسيلة تواصل.
• موافقة صريحة: خانة اختيار غير مفعّلة مسبقًا لجمع البيانات التسويقية.
• كلمات المرور: مخزّنة مشفّرة؛ اسأل مطوّرك سؤالًا واحدًا: هل تستخدمون تجزئة مثل bcrypt؟
• النسخ الاحتياطي: نسخة يومية مؤتمتة، واختبر الاستعادة فعلًا لا وجود الملف فقط.

اختبار الاستعادة هو ما لا يخبرك به أحد. عشرات المشاريع تملك نسخًا احتياطية لم تُجرَّب مرة واحدة، ثم تكتشف يوم الحاجة أن الملف تالف أو ناقص. جرّبها على بيئة تجريبية قبل الإطلاق.

أضف فحصًا بسيطًا للصلاحيات: أنشئ حسابين باسم «عميل أ» و«عميل ب»، وحاول من الأول الوصول لبيانات الثاني بتعديل الرقم في الرابط. إن نجحت فلديك ثغرة تُعرف بـ IDOR، وهي من أشيع الثغرات في التطبيقات المبنية على عجل. وإن كنت تدير بوابة دفع، اطلب من المزوّد — مدى أو تاب أو باي تابس — بيئة الاختبار (Sandbox)، ثم نفّذ عملية حقيقية بريال واحد واستردها. الفجوة بين بيئة الاختبار والواقع أوسع مما تتصور.

كم يستغرق اختبار تطبيق الويب قبل الإطلاق؟

لتطبيق صغير أو متوسط، خصّص من 5 إلى 10 أيام عمل: يومان للمسارات الحرجة والنماذج، يوم للأداء، يوم للتوافق، يوم للأمان، ثم 3 إلى 5 أيام لاختبار تجريبي مع مستخدمين حقيقيين وإصلاح ما يظهر. التسرّع هنا يكلّفك أضعافه شكاوى ودعمًا بعد الإطلاق.

الجزء الأثمن من هذه المدة هو الاختبار مع أشخاص من خارج فريقك. أبحاث Nielsen Norman Group المعروفة تشير إلى أن خمسة مستخدمين يكشفون النسبة الأكبر من مشكلات قابلية الاستخدام. لا تحتاج مئة شخص.

اختر خمسة يشبهون عميلك المستهدف. أعطهم مهمة واحدة: «احجز موعدًا لغدٍ مساءً». ثم اصمت تمامًا.

الصمت مهارة. كلما تدخّلت لتشرح، فقدت ملاحظة ثمينة. راقب أين يتوقفون، وأين ينقرون على شيء غير قابل للنقر، ومتى يسألون «وبعدين؟».

• معدل الإنجاز: كم واحدًا من الخمسة أكمل المهمة دون مساعدة؟ أقل من أربعة يعني خللًا في التصميم.
• زمن الإنجاز: قِسه بالثواني وقارنه بتوقعك.
• نقاط الحيرة: كل سؤال شفهي يعني نصًا ناقصًا في الواجهة.

ثم أطلق نسخة محدودة. أفضّل دائمًا إطلاقًا تجريبيًا لمئة مستخدم على إطلاق مدوٍّ للجميع، لأن إصلاح خلل أمام مئة شخص أرحم بكثير من إصلاحه أمام عشرة آلاف. خطوات هذه المرحلة مشروحة في نشر تطبيق تجريبي، ومنها تنتقل بثقة إلى نشر تطبيق الويب على الإنترنت أمام الجمهور كاملًا.

قائمة التحقق النهائية ليلة الإطلاق

قبل أن تضغط الزر، امسح هذه القائمة بصوت مرتفع مع شريكك في المشروع. عشرون دقيقة تنقذ ليلة كاملة.

• النطاق: يعمل مع www وبدونها، ويحوّل تلقائيًا إلى HTTPS.
• صفحة 404: موجودة، بالعربية، وفيها زر عودة للرئيسية.
• بيانات الاختبار: حُذفت الطلبات الوهمية وحسابات «تجربة 1» و«asdf».
• التحليلات: Google Analytics أو بديله يسجّل الزيارات فعلًا — افتح التقرير المباشر وتأكد بنفسك.
• قنوات التواصل: رقم الواتساب والبريد يعملان، ورد تلقائي جاهز للرسائل الأولى.
• الضريبة: 15% في السعودية و5% في الإمارات، محسوبة وظاهرة بشكل صحيح في الفاتورة.
• المراقبة: خدمة تنبيه بسيطة مثل UptimeRobot تُخبرك فور توقف الموقع.

جهّز أيضًا خطة رجوع. اسأل نفسك: إن ظهر خلل خطير الساعة الثانية فجرًا، كيف أعيد النسخة السابقة خلال دقائق؟ إن لم تعرف الجواب فأنت غير جاهز بعد. طريقة التحديث والتراجع بأمان شرحناها في تحديث تطبيق منشور بدون توقف.

نصيحة أخيرة من التجربة: لا تُطلق يوم خميس ولا قبل عطلة رسمية. أطلق صباح ثلاثاء، حين يكون فريقك متاحًا ومزوّد الاستضافة يعمل ودعم بوابة الدفع يرد على الهاتف. رأيتُ مشروعًا أطلق عصر خميس قبل العيد، فبقي خلل الدفع أربعة أيام بلا إصلاح. كل ريال إعلاني في تلك الأيام ذهب هدرًا، والمراجعات الأولى جاءت قاسية بلا داعٍ.

الأسئلة الشائعة

هل أحتاج مبرمجًا لاختبار تطبيق الويب قبل الإطلاق؟

لا لمعظم الخطوات. المسارات الحرجة والنماذج والتوافق واختبار المستخدمين تنفّذها بنفسك بجهاز وورقة. تحتاج مساعدة تقنية في ثلاث نقاط فقط: تشفير كلمات المرور، ضبط النسخ الاحتياطي والاستعادة، ومراجعة الصلاحيات. اسأل عنها تحديدًا، أو تواصل مع فريق دعم codeyy للتحقق منها.

ما أكثر خطأ يُكتشف بعد الإطلاق ويمكن منعه مسبقًا؟

رسائل التأكيد التي تسقط في مجلد الرسائل المزعجة. السبب دائمًا سجلات النطاق (SPF وDKIM وDMARC) غير المضبوطة. العميل يظن أن طلبه فشل فيكرّره أو ينسحب. اختبر إرسال تأكيد إلى Gmail وOutlook وبريد شركة قبل الإطلاق، وافتح مجلد السبام بنفسك في كل حساب.

كيف أختبر بوابة الدفع دون خسارة أموال حقيقية؟

استخدم بيئة الاختبار (Sandbox) التي يوفّرها مزوّد الدفع مثل تاب أو باي تابس أو مدى، وجرّب فيها حالات النجاح والفشل والإلغاء. بعدها نفّذ عملية حقيقية واحدة بمبلغ رمزي كريال أو درهم من بطاقتك ثم استردها، لأن البيئة التجريبية لا تكشف كل مشكلات الإعداد الفعلي.

كم مستخدمًا يكفي في مرحلة الاختبار التجريبي؟

خمسة أشخاص لاختبار قابلية الاستخدام، ثم 50 إلى 100 مستخدم في الإطلاق المحدود لرصد مشكلات الأداء والحالات النادرة. الأهم من العدد هو التنوّع: أجهزة مختلفة، أعمار مختلفة، سرعات إنترنت متفاوتة، ومستخدم واحد على الأقل غير معتاد على التطبيقات الرقمية.

اختبار تطبيق الويب قبل الإطلاق ليس مرحلة تكميلية تُضاف إن بقي وقت. إنه الفرق بين إطلاق هادئ وأسبوع من إطفاء الحرائق أمام عملائك الأوائل. ابدأ بالمسارات الحرجة اليوم، خصّص أسبوعًا، ونفّذ القائمة بالترتيب. ستكتشف على الأرجح ثمانية أخطاء أو عشرة، وكل واحد منها كان سيكلّفك عميلًا حقيقيًا. الانطباع الأول لا يتكرر أبدًا.