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