منذ بعض الوقت ، كتبت
مقالًا عن تجربتي في تنظيم عمل QA Engineer في المشروع. الآن أريد متابعة هذا الموضوع ، ولكن في اتجاه أضيق - أتمتة الاختبار. سيكون
حول نفس المشروع ، إنه صغير ، لكنه يتطور وفقًا لطلبات العملاء العاديين. ربما لا يكون مقالي مناسبًا جدًا للفرق التي تضم العشرات من الموظفين وكل منهم مسؤول عن دورهم (في رأيي ، ينبغي تنظيم عمل الجميع في مثل هذه المشروعات بشكل صارم ، وإلا فإنه من المستحيل ببساطة إدارة مثل هذا العملاق ، على الرغم من أنهم سيجدون حبوبًا صحية) ، لكنه بالتأكيد سيكون مثيراً للاهتمام لأولئك الذين ، مثلي ، وصلوا ذات مرة إلى وظيفة جديدة ، ووقفوا عند مفترق طرق حول كيفية تنظيم مكانهم تحت الشمس الجديدة.
الاستعداد للدراسة
لذلك ، كيف يمكنك تنظيم التشغيل الآلي للاختبار في المشروع؟ إذا كانت إجابتك هي أن تأخذ السيلينيوم الرائع ونوعًا من الإطار الخاص به ، ثم من 13 عامًا من الخبرة في الاختبار ، لن أفعل ذلك بالتأكيد. سوف تضطر إلى إتقان آفاق جديدة.
ما هو محفوف نهج "الذهاب في دورات في السيلينيوم"؟ وحقيقة أنك قد قرأت بالفعل وسمعت أكثر من مرة. حقيقة أن هذه الاختبارات هي واجهة المستخدم ، فهي مكلفة وطويلة في الكتابة والتشغيل ، وفي الحفاظ على الأداء. يعلم الجميع هذا ، لكن كل ألم هذه الحقيقة لا يتم مواجهته إلا عندما يتم تجاهله. يجب أن تكون الاختبارات التلقائية من UI من طرف إلى طرف إلزامية ، ولن يعطيك أحد سوى تلك الثقة بأن ما
يراه العميل بعد النشر التالي لن يكون مخيباً للآمال بالنسبة له. لكن لا ينبغي أن يصبحوا مركز أتمتة الاختبارات الخاصة بك.
خذ
اختبار مبادئ الهرم كمركز لمراقبة الجودة. نفس الأشياء ، التي قيل عنها الكثير بالفعل ، ولكن في الممارسة العملية ، لا يفهم كل ضمان الجودة كيفية تطبيق هذا الهرم.
يتم رسمها مثل هذا:
ومثل هذا:
الجميع سوف تجد خيارا لهندستها المعمارية.
وضع اختبار مبادئ الهرم في ضمان الجودة
أولاً ، بغض النظر عن مدى كسلها وغير عادية ، يمكنك إتقان الاختبار ذي البشرة البيضاء وتصبح "مطورًا جزئيًا".ارفع المشروع محليًا ، تمامًا كما يفعل كل مطور (بالتأكيد ، يحتوي المشروع على وثائق حول كيفية القيام بذلك ، ابحث عنه). من المحتمل أن تلعن هذا النشاط التجاري عشر مرات ، فحين تقوم بذلك للمرة الأولى ، سيكون لديك مليون سؤال ومشكلة ، لكن عندما تفعل ذلك ، ستعرف الكثير بالفعل: ما هي الأفكار المعمارية ، وقاعدة البيانات ، ومن أين يتم إعادة توجيهها ، وأين هي التكوينات الضرورية والأهم من ذلك ، حيث يتم تخزين الاختبارات التلقائية وكيفية تشغيلها.
ثانيا ، التعامل مع autotests مكتوبة من قبل المطورين أنفسهم.ابحث عن مكانها في هيكل المشروع ، وأنواع الاختبارات والأدوات المستخدمة ، وكيفية إطلاقها. قم بتقييم تغطية المشروع من خلال الاختبارات الذاتية ، وتعلم كيفية التنقل فيها. هناك العديد من الأدوات لتقييم التغطية التلقائية ، يمكنك استخدامها ، لكنني لا أتحدث عن ذلك الآن. أنا أكثر عن تطوير غرائزك: خذ جزءًا من الوظائف وشاهد كيف يتم تغطيتها بواسطة اختبارات تلقائية: جيدة أو سيئة. إذا كان الأمر جيدًا ، فيجب أن تكون هادئًا في هذا الجزء ؛ وإذا كان سيئًا ، فقد وجدت نفسك واجهة عمل لتلك الأيام التي لا توجد فيها مهام عاجلة على جدول الأعمال. في غضون ذلك ، ضع في اعتبارك أنه أثناء كل تشغيل ، ضع في اعتبارك أن هذا المكان في الكود ضعيف.
ثالثًا ، خذ الشجاعة ، راجع طلب سحب المطورين.في كل مرة تبدأ تطوير وظيفي جديد ، اكتب جميع حالات الاختبار لذلك. حدد تلك التي يجب عليك أتمتة بالضرورة حتى لا تعود إلى الاختبار اليدوي لهذه الوظيفة. راجع طلبات السحب الخاصة بالمطورين واطلب بشكل معقول تنفيذ الاختبارات التلقائية التي فاتتهم. في كثير من الأحيان صادفت مطورين رائعين للغاية كتبوا اختبارات رائعة ، لكن حتى خضعوا لجودة ضمان جيدة في فهم مدى دقة استخدام العميل النهائي للمنتج على الأرجح. لذلك ، حتى بالنسبة للمتخصصين المتمرسين ، هناك شيء يمكن التوصية به في كتابة الاختبارات الذاتية.
رابعًا ، كن أكثر شجاعة واكتب اختبارات تلقائية مباشرة في رمز المنتج.نعم ، تماما كما يفعل المطورون. على قدم المساواة معهم. في كل مرة تصادف فيها حالة اختبار تحتاج إلى التشغيل الآلي ، لا تتسرع في تنفيذها على الفور باستخدام أدوات منفصلة تستخدم فقط ضمن فريق ضمان الجودة. أولاً وقبل كل شيء ، اسأل نفسك السؤال التالي: هل يمكن تشغيله تلقائيًا من خلال الاختبارات الذاتية للوحدة / التكامل في رمز المنتج؟ إذا كان الأمر كذلك ، افعل ذلك. إذا كان الأمر مخيفًا ، فهذا أمر مخيف لأول مرة فقط ، ولكن ما هو مستوى مهاراتك ، لأن المبرمجين المتمرسين سيراجعون طلبات السحب الخاصة بك. نعم ، في البداية سوف يتم تفجير كل ما فعلته للأصحاب ، ولكن التطور ينطوي دائمًا على الألم :) ولكن في النهاية ستحصل على أرباح رائعة:
- سيتم دعم هذه الاختبارات من قبل فريق التطوير بأكمله
- سيعملون بشكل مستمر ومستمر وسريع
- سيتم دمجها في CircleCi وسيتم تشغيلها في كل مرة يتم نشرها تلقائيًا (إذا تم تنفيذ ذلك في المشروع)
- سيتم تصحيح الثقوب في الاختبار (تكتب ما لم يكتب قبل)
- يمكنك مساعدة المطورين في كتابة الاختبارات إذا لم يكن لديهم وقت
خامسًا ، قم بإنشاء مجموعة صغيرة محدودة من اختبارات واجهة المستخدم من البداية إلى النهاية التي تحاكي إجراءات المستخدم النهائي في المستعرض.ستكون هذه الاختبارات التي سيتم دعمها فقط من قبل فريق ضمان الجودة. يمكن أن تتجسد
- سيناريوهات العملاء الأكثر شعبية ، حرجة
- حقيقة أنه في اختبارات التكامل في الكود الرئيسي ، لا يمكن التنفيذ الكامل ، على سبيل المثال ، العمل مع خدمات الجهات الخارجية
ونعم ، لديك الآن إمكانية الوصول إلى المشروع ، ولا يكلفك تحديث الواجهة الأمامية للمشروع أي شيء حتى يكون لديك محددات ملائمة وموثوقة لسيلينيوم. لا حاجة إلى الانتظار وطلب أي شخص - فتح طلبات السحب في رمز المنتج الرئيسي.
ما الذي يأتي منه
الآن أنا أعمل على مثل هذا السيناريو. نتيجة لذلك ، في الجزء العلوي من هرمي للاختبار ، لا يوجد سوى 9 قطع من الاختبارات الشاملة. ودعمهم هو مسؤوليتي. وتعيش كل العشرات والمئات من الاختبارات الأخرى جنبًا إلى جنب مع رمز المنتج الرئيسي ، وتبدأ عملها على الكمبيوتر المحلي للمطور ويدعمها فريق المهندسين بأكمله.
تعمل الاختبارات الشاملة الخاصة بي لبعض الوقت ، نظرًا لحقيقة أنها تقوم بتحميل ملفات الفيديو على النظام الأساسي ، ثم تقوم بتحويلها بمعلمات مختلفة ، وإرسالها إلى خدمات تابعة لجهات أخرى للمعالجة ، والانتظار للحصول على إجابة ، وما إلى ذلك ، دون أي نقاط. لذلك ، في autotests هناك العديد من لحظات من انتظار نهاية العملية. لم يعجب الفريق باحتمالية إجراء مثل هذه الاختبارات في CircleCi ، ولا يحتاج إلى ذلك. لذلك قمت بتنفيذها مثل الوظيفة في جنكينز.
عند الانتهاء من جميع اختبارات الاختبار في رمز المنتج ، ننشر وجبة الإفطار المتأخر في بيئة الاختبار ونجري اختبارات شاملة عليها باستخدام جينكينز. بعدد قليل من الاختبارات الوظيفية اليدوية لمزيد من الدقة من ضمان الجودة وهذا كل شيء ، يمكنك دمج الغداء في برنامج الماجستير. اليوم ، لست الشخص الوحيد الذي يقود جنكينز لإجراء اختبارات تلقائية في بيئة اختبار ، فالمطورين يقومون بإطلاقها باستمرار عندما يحتاجون إلى إنشاء بيانات اختبار جديدة ومحاكاة نشاط المستخدم. هناك عدد قليل منهم ، لذلك فهي مستقرة وتعمل دائما. مريحة للجميع.
سألاحظ ميزة أخرى ممتعة لمهندس ضمان الجودة في تنفيذ مثل هذا الاختبار لهرم الاختبار. اتضح أنك أصبحت جزءًا من فريق المهندسين بالكامل. إنك حقًا جزء لا يتجزأ من عمل واحد - كتابة الكود مع الجميع ، وإلقاء نظرة على رمز المطورين ، والتواصل معهم ، ويفعلون الشيء نفسه لك. ترى عمل بعضهم البعض ، تعاون أفضل ، بناء فريق أقوى. سوف تفهم المشروع ليس فقط من الخارج ، ولكن أيضًا من الداخل ، يستحق الاحترام ، أليس كذلك؟
الوداع النهائي
مقالتي لا تدعي أنها حبة عالمية يمكن استخدامها في أي وقت وفي أي مكان. جميع المشاريع مختلفة تمامًا ، وجميع الفرق مختلفة تمامًا - على كل منها أن يبني مساره الأفضل نفسه ، وغالبًا ما يكون هذا هو جوهر الأساليب والأدوات المختلفة. حتى Scrum الشهيرة ، كم عدد المشاريع التي رأيتها ، يصرح كل منها بطريقته الخاصة :) لا أؤمن بالتعليمات الصارمة ، أعتقد أن هناك حاجة إليها كإرشادات ، لكنني بحاجة إلى التصرف وفقًا للموقف.
ومع ذلك ، فإن عالم تكنولوجيا المعلومات يتطور ، والمزيد والمزيد من الناس يدخلون فيه ، لذلك أنا متأكد من أنه من بين قراء هذه المواد سيكون هناك بالتأكيد شخص ما ستساعدني إرشاداتي الصغيرة في اختيار المسار الصحيح. ابتسم لي في التعليقات إذا كان مفيدًا :) ، ستكون التعليقات ممتعة بالنسبة لي!