أعددنا لك مقالًا كتبه Dmitry Yarygin ، مهندس ضمان الجودة مع خبرة في المشاريع الكبرى في العالم لأكثر من 8 سنوات ، وهو مدرس لدورة مهندس QA للهاتف المحمول في OTUS. هل هو مثير للاهتمام لتطوير في هذا الاتجاه؟ نحن ندعوك لاتخاذ مكثفة مجانية لمدة يومين "مقدمة لأتمتة اختبار تطبيقات الهاتف المحمول على السيلينيوم و Appium . "
اختبار الجودة. من المسؤول عن هذا؟ لسنوات عديدة ، كان الجواب الوحيد على هذا السؤال في رأسي. بالطبع ، مهندس ضمان الجودة! بعد كل شيء ، أنا نفسي أنتمي إلى مهندسي ضمان الجودة.
أعرف بالتأكيد مدى أهمية اختبار جودة منتج البرنامج الذي يتم طرحه في السوق. ومع ذلك ، لاحظت بعض الأنماط التي تحدث أثناء الاختبار. لقد جعلوني أفكر في عملية الاختبار ككل وكيف يمكن تحسينها.
ينبغي للمطورين اختبار التعليمات البرمجية الخاصة بهم؟
شكرا لسؤالك. إذا كنت مطورًا ، فأنت تعلم كل التفاصيل الدقيقة والمزالق في التعليمات البرمجية الخاصة بك ، أو على الأقل تعرف المزيد عن الكود الخاص بك أكثر من مهندس ضمان الجودة. أنت تعرف رمزك بعيدًا وواسعًا وتفهم أين قد تنشأ المشكلة.
إذا كنت تعرف مكان وجود المشكلة ، فأخبر مهندس ضمان الجودة. نعم ، هو نفسه سيجدها في لحظة معينة ، لكنك لا تزال تعرف بنية التطبيق بشكل أفضل. سيكون الممتحنون ممتنين إذا أخبرتهم بمكان توقع المتاعب.
نحن مهندسون لضمان الجودة ، وسنركز عليها ونغطيها مع الاختبارات بحيث تكون أقل قلقًا. أي معلومات إضافية قد يقدمها المطورون مفيدة بشكل واضح.
اختبارات الوحدة هي بالتأكيد شيء يجب على المطورين القيام به ، وهذا هو مجال مسؤوليتهم. ستساعد اختبارات الوحدة في تجنب الأخطاء غير الضرورية والتقارير غير الضرورية عنها. من الأفضل تجنب الخطأ قبل وصول الكود إلى فريق الاختبار ، أليس كذلك؟
بضع كلمات حول اختبار التعليمات البرمجية الخاصة بك. أعتقد أنه يجب على المطورين القيام على الأقل باختبار اختبار الكود الخاص بهم. لا حاجة لاختبار واسع النطاق. ما عليك سوى التحقق من أن الشفرة تعمل على بعض مجموعة بيانات الإدخال ومنحها لفريق الاختبار حتى يعملوا بالفعل عليها.
إذا كانت الكود لا يعمل بالفعل في هذه المرحلة ، فلماذا نعطيها لضمان الجودة على الإطلاق؟ ستتلقى العشرات من رسائل الخطأ على الرغم من حقيقة أنك تعرف بالفعل أن هناك مشاكل - سيؤدي ذلك إلى إبطاء عملية التطوير فقط.
فاتنا الشوائب. هل يجب إلقاء اللوم على المختبرين؟
نعم ولا. في كل مرة يتم فيها اكتشاف خطأ ، لا سيما في الإنتاج ، يكون لديك أنت وفريقك شيء تناقشه. هناك عدة أسباب لظهور الخطأ فقط في هذه المرحلة:
- لم يكن المكان الذي ظهر فيه الخطأ أولوية بالنسبة للمختبرين. في كثير من الأحيان ، لم يفكر أحد في الخطأ الذي ظهر في الإنتاج. هذا هو نتيجة لعدم وجود اتصال بين المطورين والمختبرين. لم يتم التوصل إلى تفاهم متبادل حول مسألة مدى أهمية التحقق من المنطقة. الأمثلة الكلاسيكية لهذا الإهمال هي مشاكل الأداء والأمان. إذا كنت تعرف أن هذه المناطق مهمة لتطبيقك ، فأعلم الفريق بذلك.
- ضمان الجودة ليس لديه المعرفة اللازمة في المنطقة التي تم اختبارها. هذه أيضا مشكلة شائعة. قام المطورون بكتابة الوظيفة وافترضوا تلقائيًا أن ضمان الجودة يفهم كيف يعمل من وإلى. حسنًا ، لم يكن وضع الافتراضات استراتيجية جيدة لتحليل جودة المشروع الجاد. إذا رأيت بعض الجوانب المهمة ، فتأكد من أن مهندس ضمان الجودة الرئيسي وفريقه يرونه ويفهمونه أيضًا. لا توجد وسيلة للتغلب على هذه الخطوة.
- المطورين لا يهتمون حقا. نحن جميعا بشر. ونحن جميعا لدينا حياة خارج العمل. يعمل بعض المطورين بجد واجتهاد لإنشاء منتج عالي الجودة ، ويتحدثون مع المختبرين ، ويبلغونهم بالمشكلات المحتملة وما شابه ذلك. وهناك المطورين الذين لا يهتمون. لا يستخدمون هذا المنتج كل يوم ولا يفهمون أهميته. بالنسبة لهم ، هذه مجرد مهمة جانبية يجب إكمالها ونسيانها. ببساطة ، لا يهتمون بأن المنتج النهائي سيكون بجودة غير كافية.
- المهندسين QA لا يهمني. هنا هو الوجه الآخر للعملة. ليس كل اختبار يهتم المشروع. يحتاج البعض فقط إلى الانتهاء من الاختبار ، وتقديم تقرير جميل ونسيانها. تغطية اختبار عالية الجودة لا تزعجهم ، فهم لا يريدون التواصل مع المطورين. يمكنك مناقشة الأخطاء ، لكن هؤلاء المختبرين قد لا يجدونها مهمة أو حتى تسجل.
- الفاحصات غير مؤهلين بدرجة كافية. قد تكمن مشكلة أخرى في حقيقة أن المختبرين ببساطة غير مؤهلين بدرجة كافية لاختبار طلبك. على سبيل المثال ، تحتاج إلى إجراء اختبار الاختراق ، وكل ما هو تحت تصرفك هو فريق من الفاحصين الذين يمكنهم إجراء الاختبار اليدوي فقط. في هذه الحالة ، فإنهم ببساطة لن يعرفون كيفية التعامل معه. تحتاج هنا إلى الاعتماد على المطورين أو تحديد المزيد
المهندسون QA المؤهلون الذين سيعرفون بالضبط كيفية اختبار هذه المنطقة بالذات. - عدم وجود أبحاث المستخدم. يعرف المطورون كيفية إنشاء تطبيق ، والمهندسين QA كيفية كسره. ماذا عن المستخدمين؟ المستخدمون هم أناس حقيقيون يستخدمون تطبيقك في العالم الحقيقي. إنهم لن يكسروا ذلك. إنهم مختلفون تمامًا ولهم أهداف مختلفة ، لكنهم جميعًا يريدون تحقيقها باستخدام التطبيق الخاص بك. يمكن لمهندسي ضمان الجودة التعود على الخطأ وإدراك أنه يحدث بشكل متكرر ، وبالتالي ، لا يهم كثيرًا. لن يتسامح المستخدم مع هذا. إذا تعطل التطبيق الخاص بك ، فإن الخطوة التالية هي إزالته ، ثم البحث عن بديل. هذه هي الحقيقة. يعد البحث عن جمهور مستخدم و / أو وجود مجموعة مستخدمين للاختبار أمرين مهمين من الناحية الاستراتيجية.
- سوء تنظيم عملية الاتصال. من الناحية المثالية ، تحتاج إلى عملية بسيطة لفرز الأخطاء التي تسمح لك بتقييم الأخطاء من QA (أو على الأقل ترتيبها بشكل صحيح) وتمريرها إلى المطورين بحيث يفهمون عبء العمل الخاص بهم. عندما يكون هناك أي سوء فهم ، يجب أن يكون المختبر والمطور قادرين دائمًا على الاقتراب من بعضهما البعض وحل هذه المشكلة في غضون بضع دقائق أو ساعات. إذا لم يتم تأسيس هذه العملية ولم يتعجل الجانبان للبحث عن سبب سوء الفهم ، فلن يتحقق أي شيء جيد. سوف يقلد الطرفان الأنشطة ، لكن في الواقع سيكونان في طريق مسدود وينتظران شخصًا آخر يمكنه المجيء وحل الوضع بطريقة سحرية. هذا هو في الأساس النهج الخاطئ.
- لا يكفي اختبار. قد يكون التطبيق معقدًا وقد يتطلب اختبارًا على منصات ومتصفحات متعددة. قد لا يكفي مجرد عدد قليل من مهندسي ضمان الجودة لهذه المهمة. فكر في توظيف المزيد من الأشخاص أو إعادة توزيع الموارد التي لديك بطريقة تزيد من التركيز على الاختبار.
- مثقلة المطورين. قد تكون من حولك متخصصين مثاليين ومؤهلين تأهيلا عاليا ، لكنهم يعملون في توتر مستمر ولا يمكن لأحد مساعدتهم. نعم ، إنهم يتعرضون لضغوط ، وليس لديهم وقت للتحدث مع فريق ضمان الجودة. هذه مشكلة شائعة جدًا وهذا أحد الأسباب الرئيسية لضعف جودة البرنامج.
- الجودة ليست في دائرة الضوء. النظر في هذا السيناريو كذلك. هنا وكان هناك بعض الأخطاء الطفيفة. لا أحد منهم بالغ الأهمية. ومع ذلك ، لا يحب المستخدمون التطبيق. التعليقات سيئة. UX أقل من المتوسط. ولماذا؟ نعم ، لأنه لم يفكر أحد في إنشاء منتج عالي الجودة. قام المطورون بعملهم ، وقام المختبرون بعملهم ، لكن لم يتبع أحد عملية مراقبة الجودة نفسها. يجب أن يجمع تطوير التطبيق بين الفرق ، مما يجعلها واحدة كاملة. إذا لم يكن لدى المجموعة مزاج كهذا ، فلا أحد يهتم بالجودة.
استنتاج
اليوم ، أصبحت التطبيقات أكثر صعوبة وأصعب. إذا كنت ترغب في العثور على من يقع اللوم على فشل المشروع ، فمن السهل. قد يكون اللوم المهندسين QA والمطورين والمديرين التنفيذيين. أو كل ذلك معا. والسؤال الرئيسي هو لماذا يجب أن نبحث عن من يلومون بدلاً من تحمل مسؤولية جودة المشروع؟ أي شخص لم يدرك أهمية اختبار وظيفة محددة قد يكون في مكان المذنب.
يجب أن يكون السؤال الوحيد هو: "هل نصنع منتجًا جيدًا حقًا؟" . إذا كانت الإجابة على هذا السؤال بنعم ، فلا ينبغي أن يكون هناك شك في أن جميع الفرق تقوم بعمل واحد كبير.
لن يضطر أي شخص إلى اللوم وسيكون الجميع سعداء ، لأن ضمان الجودة مهمة شائعة!