فن اختبار المنتج الأولي القابل للتطبيق (MVP)

الإنجاز أفضل من الكمال. لا تقلق، ابدأ ولو بشيء متواضع. fancy-quote

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

الاختبار من الجوانب التي تُهمَل كثيرًا عند تطوير التطبيقات، وخاصة في مرحلة المنتج الأولي القابل للتطبيق (MVP). فهناك الكثير من المقالات حول كتابة الاختبارات الآلية، ما يوحي بأننا دخلنا عصرًا جديدًا في هندسة البرمجيات لا يحتاج إلى "الاختبار على الطريقة القديمة". وأقصد بالاختبار على الطريقة القديمة أن تتصفحوا تطبيقكم بأنفسكم وتتحققوا من كل ميزة للتأكد من أنها تعمل.

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

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

• القليل يكفي

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

• قسّموا العمل

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

• اختبروا معًا

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

• لا تتهاونوا في المدفوعات

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

• الأخطاء اللغوية

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