من الناحية النظرية ، من المفترض أن تعمل برامج أو أدوات أتمتة الاختبار على تسهيل الأمور على المختبرين ، ووقت الفراغ وتزويدنا ببطانية استرخاء إضافية لتغطية التقييم لدينا.
والعديد من المؤسسات تفشل في تنفيذ بنية تحتية لأتمتة الاختبارات قابلة للتطوير وقوية وجيدة تعيد الموارد التي تم استثمارها ويمكن أن توفرها. بعض وظائف أتمتة الاختبار المكتوبة "تخلص من" والبعض الآخر تكافح باستمرار مع أهدافهم لكسب مجموعة أتمتة مستقرة.
على مر السنين ، لاحظت أن العديد من الشركات تحاول تنفيذ جهود الأتمتة الخاصة بها ، وقد لاحظت التخلص من المشاريع المكتوبة ، وتبديل الأطر ، وفصل المديرين لأنهم فشلوا في توفير ما تم التعهد به أو تحديده كهدف.
هناك الكثير من أسباب الفشل ، على الرغم من أن الأتمتة منطقية تمامًا على المدى الطويل ، إلا أننا نحتاج إلى فهم أنها أصعب بكثير كما تبدو.
فيما يلي بعض الأسباب التي يجب أن تعرفها قبل المضي قدمًا والبدء في بناء مشروع أتمتة الاختبار الخاص بك:
تحليل وطرح الأسئلة: وظيفة أتمتة الاختبار هي وظيفة مثل أي مشروع تطبيقات آخر ويجب التعامل معها تمامًا ؛ كيف ستعمل على تخطيط مشروع برمجي؟ دع هذه الفكرة توجهك عندما تفكر في تنفيذ مشروع Test Automation الخاص بك. من الذي ستختاره للوظيفة؟ من سيستخدم المنتج المنتج؟ ما هي اللغة أو الإطار الأنسب للوظيفة؟ هل تفهم من التحديات وإرشاداتها وتلقي نظرة خاطفة؟ هل ستؤلف هندسة معمارية لا تعرف عنها شيئًا بمفردك ، أم ستتصل بمستشار لتقديم النصح لك ببعض الأفكار؟
كل هذه الأسئلة هي مجرد غيض من فيض لما يجب أن تطرحه على نفسك قبل أن تكتب سطرًا واحدًا من التعليمات البرمجية أو حتى اختبار الموقف.
مجموعة المهارات غير الكافية: دعني أطرح عليك سؤالاً. هل تسمح للمبرمجين الأسوأ أو غير المتمرسين ، بشخص لا يفهم كيفية تكوين رمز رائع نظيف وقابل للبحث - نمط تصميم تطبيقك وكتابته من البداية؟ أعتقد أن الجواب لا. فلماذا تعتقد العديد من الشركات أنه يمكن تنفيذ الجودة من قبل شخص ما البنية التحتية لأتمتة التقييم دون الخبرة والمهارة؟ إذا لم يكن لدى الموظفين المتفانين الخبرة والمعرفة ولم تكن تخطط لتوظيف شخص يمتلكها ، فأنت بحاجة إلى التفكير في استخدام أدوات التشغيل الآلي التي لا تحتوي على رموز.
توقعات / مقاربة غير واقعية: سأقسم ذلك الجزء إلى قسمين. الأول هو الفهم الخاطئ لعائد الاستثمار (ROI) (عائد الاستثمار) لأتمتة الاختبار والمكون الثاني هو التوقعات غير الواقعية لإطار العمل لكل وقت. هناك وظيفة جيدة كما هي من صنعها ، ولا يمكنك توقع شيء ما دون استثمار الوقت ، لتقديم قيمة. لقد تحدثت إلى مهندس ضمان الجودة الذي أخبرني أنه حصل على 6 ساعات أسبوعيًا لتكوين بنية تحتية سرية. ماذا تتوقع منه أن يحقق 6 ساعات؟
لإنجاز هذا العمل عليك الاستفسار:
- ما هي بالضبط الأهداف التي ترغب في تحقيقها مع أتمتة الاختبار؟
- ما الذي يمكن اعتباره قيمة رائعة للجهود / الوقت؟
- ما هي معايير الإنجاز؟
- ما مقدار الوقت / المال الذي أنت مستعد لإنفاقه لتحقيق ذلك؟
الأتمتة ليست مهمة "الإطلاق والنسيان" . تريد أن تقر بأنها عملية مستمرة تتطلب صيانة وجهدًا جماعيًا وتقدمًا.
يجب أن أعترف ، للأسف من خلال ما رأيته ، أن بعض الشركات ترى توفير وظيفة سرية لمهندس ضمان الجودة كمجرد وسيلة للحفاظ على العامل أو وضع بعض " التوابل " في روتينه الأسبوعي. لا تفهموني بشكل خاطئ ، فأنا لا أقول أنه لا ينبغي علينا الحفاظ على عمالنا أو توفير الوقت لهم للتعلم والتقدم ، بل أقول فقط إنه يجب أن يتماشى مع التوقعات الواقعية والشفافية تجاه العامل ، وهذا بحد ذاته .
التخطيط غير الكافي: يجب أن يبدأ مشروع الأتمتة الرائع بخطة عالية المستوى وخطة تتطور إلى أسلوب تقني شامل. حتى استراتيجية "مقاس واحد يناسب الجميع" يمكن أن تكون كارثية على نجاحك. ما نجح بشكل ممتاز لشركة واحدة لا يعني بالضرورة أنها ستؤدي المهمة نيابةً عنك. يمكن أن يكون هذا الإعلان صحيحًا بشأن اختيار الأداة. عندما لا تضطر بالفعل إلى استخدام التكنولوجيا المعنية ، فإنها ترتفع إلى حد كبير. هذا مهم للغاية أن نلاحظ. هناك عدد كبير من الأدوات التجارية والمفتوحة المصدر التي يمكن أن توفر قيمة عالية مقابل المال وبدون حتى التفكير في البدائل والفوائد / البدائل التي يمكن أن تقدمها هذه الأدوات. اختر الأداة التي تلبي احتياجاتك. إليكم سنتي - من الأفضل بكثير الدفع مقابل حل بدلاً من إضاعة الكثير من المرات (سيصعد ذلك ليكون أغلى بكثير من علامة تكلفة البرنامج).
الآن ، بينما نواصل مناقشة طريقة تخطيط تصميمنا ، سيتعين علينا التفكير في الهندسة الفنية الشاملة ومتطلبات العمل. فيما يلي بعض الجوانب التي يجب أن تأخذها في الاعتبار:
- تخيل الوظائف والوحدات وتدفقات الأعمال التي سيفحصها الناس؟
- ما هي السياسة المخططة لكل مرحلة تنفيذ؟ (العقل ، الانحدار ، حزمة مخصصة CI / CD؟)
- ما هي التدفقات / الوظائف المشتركة / المشتركة / المتكررة؟
- كيف نخطط لكل اختبار لقطعة أثرية موجزة قائمة بذاتها؟ (SetUp و TearDown ، الاعتماد على البيانات الخارجية بدلاً من بيانات التقييم التي تم إنشاؤها ، ما الذي يجب تشغيله قبل كل اختبار ، فئة المجموعة؟)
- كيف نمنع أحد التقييمات "كسر" آخر إذا تم تشغيلهما بالتزامن؟
- كيف يمكننا إنتاج جو جيد قابل للتطوير ونظيف ومناسب؟ (خوادم وهمية ، حالات قاعدة البيانات ، برنامج التنظيف النصي ، تفضيلات المتصفح ، تكوينات الشبكة / الخادم ، الإعداد والتنظيف ، البيئة الافتراضية أو حاويات عامل الإرساء).
- ما هي الأدوات التي نبنيها بالضبط إذا استخدمناها؟
- بالضبط كيف يمكن إدارة تبعياتنا؟
- أين يتم تخزين مشروعنا؟
- كم عدد المهندسين الذين يعملون في المشروع والطريقة التي ستدار بها إدارة المتغير؟
- ما هي أفضل أدوات CI لأداء بنياتنا؟
- هل ستقوم بتنفيذ سير عمل CI / CD؟
- أين ستجري الاختبارات والموارد التي يمكنك استخدامها لتصميم منصة التنفيذ الخاصة بك؟ (هل تم تزويدك بالأموال لشراء تصاريح الحلول السحابية؟ هل لديك الأدوات أو الدعم لإنشاء البنية التحتية لخادم السيلينيوم الخاص بك؟)
- ما نوع الاختبارات التي ستصبح تلقائية قريبًا؟ (API ، المفاهيم المرئية ، عمليات الخادم ، أتمتة الويب / واجهة المستخدم ، الهاتف المحمول - Android / IOS).
- هل هناك بعض مجموعات البيانات الكبيرة ، والتدفقات الطويلة ، والعمليات المعقدة ، والتكاملات التي تتطلب تقييمًا إضافيًا؟
- ما الذي يجب أن نختبره من خلال واجهة المستخدم الرسومية وما الذي يمكن أن يكون أكثر أمانًا للتحقق منه عبر واجهة برمجة التطبيقات؟
- ما هي السجلات وآليات إعداد التقارير والمعالجات والمستمعون بالضبط التي سنحتاج إلى تنفيذها من أجل إنشاء تقييم السبب الجذري وتصحيح الأخطاء بشكل أبسط؟ (ما هي مجموعة الأتمتة لمدة ساعة واحدة إذا خصصت يومًا لفهم النتيجة؟)
- ما المقاييس / التقرير / المخرجات التي يجب أن يوفرها التشغيل؟
- ما هي عمليات الدمج بالضبط التي نريدها حقًا؟ (برامج التقارير ، أدوات ALM ، تعقب الأخطاء ، برامج إدارة التقييم).
- من الذي قد يؤلف البنية التحتية ومن المفترض أن ينفذ الاختبارات؟ (هل يمكن أن يكون هناك فرع بينهما؟)
- من المسؤول عن تزويد مهندسي الأتمتة بتدفقات الأعمال / حالات الاختبار / منطق الأعمال الذي من المفترض أن يكون تلقائيًا؟
- هل هناك مراحل POC (إثبات المفهوم) محددة لتحديد الأهداف المستقبلية؟
هذه فقط بعض الأسئلة بإيجاز وما يجب أن تستخلصه من هذا هو ذلك
خيار أداة مناسب ، من المرجح أن ينتج عن التخطيط / التصميم المتفوق الفرق بين الفشل والنجاح.
أتمتة كل شيء : هناك نقطة مهمة يجب ملاحظتها وهي أنه لا يمكن أو يجب أن يكون تلقائيًا. في بعض الأحيان التصور أو قرارات الإدارة الخاطئة ، نقوم بأتمتة كل ما يأتي إلى رأس المختبر أو تحويل حالات الاختبار بشكل أعمى إلى نصوص. بادئ ذي بدء ، ليست كل التقييمات مناسبة للأتمتة. ثانيًا ، حالات الاختبار نفسها غير مقبولة للوظيفة. ينتهي هذا بمجموعة لا يمكن إدارتها من الاختبارات التلقائية التي يستحيل الاحتفاظ بها ، وللأسف فإن غالبية المناسبات ستؤدي إلى وضع علامات على الكثير من أعمالنا المكتوبة. لا توجد قيمة إضافية للأتمتة إذا لم يكن لدى شركتك الأموال اللازمة للحفاظ على فرق التشغيل الآلي عشرات الآلاف من حالات الاختبار التي تتحقق أحيانًا من نفس منطق الأعمال.
سنحتاج أيضًا إلى وضع خطة واضحة حول ما يحتاج إلى صيانة كل بناء آلي. ما هو مدرج في انحدارنا؟ ما الذي يوصف بأنه عقولنا؟ ما هو الأمان والموثوقية الكافية للدخول إلى خط أنابيب CI / CD الخاص بنا؟
يحتاج برنامج Test-Automation إلى تخطيط قوي وفهم والتزام وتفاني لتقديم قيمة مناسبة.
نقص المهارات / التعليمات المناسبة ، اختيار الأدوات غير الصحيح ، الموارد غير الكافية ، الافتقار إلى الإعداد المناسب ، التوقع غير الواقعي ، كل ذلك قد يؤدي إلى فشل المشروع.
آمل أن يكون لهذا التقرير تأثير إيجابي وأن يساعد عددًا قليلاً منكم على اتباع عقلية منتجة.