اختبار المثلية أو مشاكل التوظيف المزمنة

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

عند بدء مهنة ، تم عرض عرض تقديمي في الدورات التي تؤكد الحاجة للاختبار. يقرأ توقيع الشريحة: "كلما وجدت خطأً في دورة حياة المنتج ، يكون إصلاحه أرخص". معدلات الاختبارات أقل من المبرمجين. نحن نوظف مختبرين ← نضمن الجودة ونوفر على التطوير. الربح!

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

زادت سرعة تطوير المشاريع الحديثة. ظهر مفهوم CI / CD. لا يفاجأ أحد بمشاريع النشر اليومية. أدركت الشركات أن الشيكات اليدوية ليست قابلة للتطوير. شارك المختبرون في أتمتة اختبار القبول باستخدام السيلينيوم أو الأطر المشابهة. يتم تغيير التغيير في الدواخل ، إذا بقيت الواجهة الأمامية فقط مع تحديد المواقع اللازمة.

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

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

1. ليس لدى المختبرين أي فكرة عن بنية المشروع

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

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

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

البديل الهرم من قبل مارتن فاولر

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

ميزة اختبار الصندوق الأسود هي أن الاختبارات مستقلة عن التنفيذ. نجاح باهر. لكن هذا التقييد المصطنع يجب ألا يتداخل مع فهم الدواخل. عندما يعرف المختبر كيف يعمل المنتج:

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

ماليفيتش يستفز لاختبار الصندوق الأسود

ربما أدى نفس الحب للمربع الأسود إلى المشكلة الثانية.

2. لا يفهم المختبرون ما يحدث داخل المتصفح

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

يذكر معظم المتقدمين أمثلة لرموز HTTP وأنواع طلبات HTTP. السؤال التالي هو في كثير من الأحيان المحير.

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

إذا لم يجيب المختبر على هذه الأسئلة ، فإن شكوكه تزحف. هذا يشير إلى أن المرشح:

• لا يمكن اختبار منتج بدون واجهة مستخدم ؛
• لا يعرف كيفية استخدام أدوات المطور في المتصفح ؛
• لست معتادًا على معرفة سبب الخطأ (الواجهة الأمامية أو الخلفية).

سيكون من السهل للمطور إصلاح الخلل إذا تم وصفه بالتفاصيل الفنية.

3. إهمال الموقف تجاه رمز الاختبار

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

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

مع ظهور Agile ، توحيدت الفرق. مفقود "نحن" و "هم". الفريق مسؤول عن النتيجة النهائية. وبما أن الممارسات الهندسية أصبحت شائعة ، فيجب وضع متطلبات رمز الاختبار كما هي بالنسبة لرمز المنتج.

لإسقاط المرشحين ، أرسلنا مهمة اختبار دون موعد نهائي:

   Java           http://todomvc.com/examples/react/ 

قائمة الأخطاء الشائعة

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

  
  

• انتهاك اصطلاحات تسمية الفئات والأساليب والمتغيرات
  CamelCase مختلطة مع الشرطة السفلية. لذا فهم لا يرتدونها الآن. حفظ تلميحات Linter و IDE.

  
  

• مسارات مساعدة Hardcode

  
  

   String exePath = "Chrome_driver/chromedriver.exe"; System.setProperty("webdriver.chrome.driver", exePath); 

  
  

  الكلاسيكية "يعمل على الجهاز الخاص بي."

  
  

• تخزين الملفات الثنائية داخل المستودع
  هناك git-lfs لحل هذه المشكلة.

  
  

• عدم الاتساق في الأساليب
  في أحد الحلول ، وصف المرشح طرقًا للحذف ووضع علامة "تم" مثل هذا:

  
  

   public void DeleteTask(String task) ... public void CompleteTask(int taskno) 

  
  

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

  
  

• System.out.println() للتسجيل
  لا يوفر معلومات داعمة في أي فئة حدث فيها الحدث.

  
  

• باستخدام Thread.sleep
  لحل هذه المشكلة ، هناك مكتبة انتظار . يساعد على إضافة ملاحظات إلى توقع تحقيق الشرط الضروري.

  
  

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

  
  

• إساءة استخدام بيرتيك Acerts
  assertTrue أو assertFalse يستخدم في كل شيء على التوالي:

  
  

   assertTrue("One To Do item should be added", toDosPage.getToDoListCount(false) == 1); 

  
  

  من الأفضل استخدام assertEquals هنا للحصول على السياق عند تعطل الاختبار.

  
  

• لا يوجد أي معاملات لتشغيل الاختبارات
  مثال: عنوان URL للاختبار مسمر برمز.

  
  

يجب أن نذكر أيضا العمل مع git . في معظم الأحيان ، تم إرسال المهمة في التزام واحد. تعد كتابة رسائل مفهومة وتقسيم مهمة كبيرة إلى عدة رسائل منفصلة مهارة ضرورية ، لا سيما في العمل الجماعي.

النتائج

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

سأكون سعيدًا لأن أكون مخطئًا وسعيدًا إذا كان كل شيء مختلفًا في شركتك المستأجرة.

UPD 11/02/20 : في ندوة "صورة اختبار" عبر الويب ، أشاطر رأيي حول كيفية رؤيتي للمهنة من الداخل.

• لماذا يحتاج العمل إلى اختبار؟
• دور المختبر في الفريق
• اختبار VS الآلي اليدوي
• جوانب جذابة للمهنة وسعر الخبرة
• المهارات الصلبة / لينة اللازمة
• أخطاء في استئناف المهنيين المبتدئين
• Devops في الاختبار
• النمو الوظيفي