الاختبار - ربما يكون الجزء الأقل تقديرًا من تطوير التطبيق

لماذا يجب أن أدفع لك مقابل اختبار عملك؟

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

تعد منصة التجارة الإلكترونية الكبيرة شيئًا معقدًا بشكل لا يصدق مع ملايين الأسطر من التعليمات البرمجية وجيجابايت من البيانات والعديد من نقاط التكامل. هناك الكثير من الأجزاء المتحركة المترابطة ؛ العديد من الروابط في السلسلة بحيث يكون من السهل جدًا حدوث خطأ ما. سيتم استخدام التطبيق بملايين الطرق المختلفة من خلال العديد من المتصفحات عبر العديد من أجهزة سطح المكتب والأجهزة المحمولة. سيستمر مشروع التطوير لمدة 6 أشهر على الأقل مع عمل العديد من الأشخاص المختلفين عليه. عدد المجالات والسيناريوهات التي يمكن اختبارها لا حدود لها تقريبًا. إنه لأمر عجيب أن أي شيء يعمل على الإطلاق!

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

وحدة التجارب

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

اختبار الدخان

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

اختبار واجهة المستخدم

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

تقدم بعض خدمات الاختبار التابعة لجهات خارجية مثل Bug Finders خدمة جماعية حيث يتم استخدام مئات من المختبرين البشريين المستقلين من جميع أنحاء العالم لاختبار موقع ويب ويتم الدفع لهم عندما يجدون مشكلة. يمكن أن يكون هذا النهج طريقة فعالة من حيث التكلفة نسبيًا لاختبار تطبيقك عبر مئات من مجموعات الأجهزة / النظام الأساسي / المستعرض. من الطبيعي أن تؤدي دورة الاختبار إلى إثارة حوالي 200 مشكلة. غالبًا ما يكمن التحدي في تصنيف القضايا وترتيبها حسب الأولوية بحيث تركز مواردك على التعامل مع القضايا الأكثر أهمية. سيكون لكل موقع ويب تراكم مستمر من المشكلات ذات المستوى المنخفض والتي من غير المرجح أن يتم حلها على الإطلاق.

اختبار الانحدار

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

UAT

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

غالبًا ما يتم الخلط بين UAT أو دمجه مع SIT (اختبار تكامل النظام) حيث ستختبر على وجه التحديد التكامل بين أنظمة متعددة. تُعد SIT جزءًا من الاختبار الشامل الذي يضمن أن جميع أجزاء السلسلة تعمل معًا بشكل صحيح.

يتضمن UAT الجيد إنشاء حالات اختبار وخطط اختبار. تأخذ هذه بشكل عام شكل مجموعة من البرامج النصية (البرنامج النصي عبارة عن مجموعة من المهام التي يجب تشغيلها من خلالها) التي سيجريها المختبِر اليدوي وإما اجتياز الاختبار أو فشله وفقًا للنتيجة. ليس من غير المعتاد أن تتضمن خطة اختبار UAT الشاملة أكثر من 500 حالة اختبار.

يعد A in UAT أحد الأسباب التي تجعله مهمًا للغاية. في نهاية عملية UAT ، يُعتبر عمومًا أنك قد قبلت الطلب ، لذلك من المهم أن تكون قد اختبرته جيدًا للتأكد من أنه يعمل بالطريقة التي كنت تتوقعها بالضبط. هذا لا يعني أن الأخطاء غير المكتشفة لن تخضع للضمان ولكن إذا كانت هناك وظيفة لا تعمل بالطريقة التي توقعتها ، فيجب التقاطها في UAT. السبب الآخر لأهميتها هو أنها الفرصة الأخيرة لتناول المشكلات قبل نشرها. من المحتمل أن تؤثر أي أخطاء أو مشكلات سلبًا على تجربة المستخدم.

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

اختبار الأمان

أتفاجأ أحيانًا بفشل بعض بائعي التجزئة في أخذ اختبار الأمان بجدية كافية. ليس من غير المعتاد أن تجد أن بائع التجزئة لا يعرف متى أجرى اختبار الاختراق آخر مرة على نظامه الأساسي على الويب. هؤلاء هم عمومًا من لم يتعرضوا لهجوم إلكتروني (أو لا يعرفون بعد أنهم تعرضوا لهجوم إلكتروني). في المناخ الحالي حيث تستمر الجريمة الإلكترونية في النمو من حيث التكرار والتعقيد ، وخاصة مع اللائحة العامة لحماية البيانات في الأفق في أوروبا ، تزداد أهمية اختبار الأمان. يجب اختبار اختراق جميع منصات الويب الخاصة بالتجارة الإلكترونية من قبل طرف ثالث متخصص على الأقل سنويًا ولكن من الناحية المثالية مرتين في السنة. من المستحسن أيضًا أن يتم فحص التطبيق الخاص بك بحثًا عن نقاط الضعف باستخدام برامج متخصصة مثل Nessus على أساس منتظم. في Envoy ، نميل إلى فحص منصات الويب لعملائنا على أساس أسبوعي للتأكد من التقاط ثغرات التطبيقات بسرعة كبيرة. على الأقل ، يجب عليك إجراء عمليات فحص أمان التطبيق قبل كل إصدار للإنتاج. ليس من الجيد الانتظار لمدة 6 أشهر حتى اختبار الاختراق التالي عندما تقوم بإدخال ثغرة أمنية جديدة في التطبيق.

اختبار أداء

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

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

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

في حين أن القائمة أعلاه ليست شاملة ، يمكنك أن ترى أن نطاق الاختبار داخل تطوير البرامج يمكن أن يكون كبيرًا جدًا ومعقدًا. يستغرق كل نوع من الاختبارات وقتًا وجهدًا ولا يجب أن تفترض فقط أنه تم إجراؤه وفقًا للمعايير دون أي رسوم إضافية. ستخصص الشركات التي تركز بشدة على الاختبار ما يصل إلى 40٪ من وقت أي مشروع للاختبار وهو مبلغ قد يكون مفاجئًا للغاية. يمكن أن يؤدي الاختبار الجيد إلى التخلص من مخاطر المشروع ويمكن أن يدفع تكاليف نفسه على المدى الطويل لأنه سينتج عنه أخطاء أقل وأداء أفضل وتجربة شاملة أفضل لعملائك.