ربما يكون
أليكسي بارانتسيف واحدًا من أشهر الأشخاص في الاختبار الروسي: فهو معروف من خلال
البرمجيات- testing.ru ، و
selenium2.ru ، وبالمشاركة في Selenium WebDriver ، وليس فقط. في الوقت نفسه ، هو أيضًا أحد أكثر الخبراء خبرة: في الاختبار بالفعل منذ عام 1994. وعندما أصبح معروفًا أنه سيتحدث في مؤتمر Heisenbug الخاص بنا مع
تقرير "مشاكل في Selenium WebDriver" ، أردنا أن نسأل مثل هذا المتحدث. بدأنا بأسئلة حول اختلاف الاختبار في التسعينات عن اليوم ، ثم انتقلنا إلى الحقائق الحديثة.
- قد يكون من بين قراء المقابلة أشخاص لم يولدوا حتى عندما بدأت بالفعل في الاختبار. أخبر كيف كان كل شيء مختلفًا عن أيامنا؟- إذا تحدثنا عن بعض أسس الاختبار (النظرية ، التقنيات الأساسية) ، فلن تكون هناك تغييرات خاصة. ولكن في الوقت نفسه ، تتغير أتمتة الاختبار ، بالطبع ، باستمرار. تظهر تقنيات التطوير الجديدة وتختفي ، ومعها تظهر التقنيات والأدوات المصممة لاختبار البرمجيات أو تختفي. كيف يمكن مقارنة اختبار ما كان آنذاك وما هو الآن؟ على أي حال ، للمقارنة ، أيهما أفضل - كان هناك SOAP ، الآن REST. ثم اختبرنا خدمات الويب المكتوبة باستخدام SOAP ، والآن تلك المكتوبة باستخدام REST. ما الفرق الذي يحدثه؟
- حسنًا ، بعض التقنيات لم "ظهرت واختفت" فحسب ، بل أصبحت تقنية بدونها أصبح من الصعب الآن تخيل الصناعة: "كيف نعيش حتى بدون Git؟"- عاشوا بشكل طبيعي بدون جيت. كان هناك CVS ، عشنا بشكل جيد معه ، ثم كان هناك تخريب ، ثم Git. كل هذا ليس مثيرًا للاهتمام ، ولكن ما تغير كثيرًا حقًا هو السرعة. سرعة التطور ، ومعه سرعة الاختبار. لا يتعلق الأمر حتى بالتكرار القصير ، Agile ، نهج تنظيم ساعات العمل. إنها بالضبط سرعة تطوير المنتج التي تغيرت.
عندما بدأنا العمل لأول مرة ، في منتصف التسعينات ، كان لدينا مشاريع تدوم ستة أشهر أو عامًا أو عامين. التطوير والاختبار. ثم بدأت هذه المشاريع في الانخفاض إلى ثلاثة أشهر ، شهرين. في الواقع ، في غضون شهرين تم تطوير نفس الشيء كما في وقت سابق من العام. والآن ما يحدث: يأتي الناس إلى الهاكاثون ، ويطورون منتجًا عمليًا في يوم واحد ، ويختبرونه ويطلقونه. من الواضح أن هذا لا يزال نموذجًا أوليًا ، ولكن مع ذلك ، لمدة يوم. كان من المستحيل تخيل هذا.
لماذا يحدث هذا؟ بالطبع ، تتطور الأدوات. ولكن الأمر لا يتعلق بالأدوات ، فالبعض لا يزال يكتب رمزًا في vi أو emacs. والأهم من ذلك ، تمت كتابة الكثير من التعليمات البرمجية الجاهزة بالفعل ؛ هناك مكتبات جيدة تم اختبارها بدقة. في مكان ما ، ما زلت بحاجة إلى كتابة الكثير من التعليمات البرمجية الخاصة بك ، وتطوير خوارزميات فريدة ، ولا يزال كل شيء يستغرق وقتًا طويلاً هناك. ولكن في حالات أخرى ، يمكنك أخذ مكونات جاهزة ، منها بسرعة ، كما هو الحال مع المصمم ، لتجميع المنتج النهائي. وبالتالي ، من السهل أيضًا اختباره ، لأننا نجمعه بالفعل من مكونات موثوقة ومختبرة. لقد تغير هذا كثيرا.
- وما الذي تغير في رؤية الناس للعالم - في كيفية نظرتنا إلى الاختبار / التطوير وماذا نتوقع منهم؟- في التسعينات ، كان لدى كل من المطورين والمختبرين ثقة أكبر في المعايير. في الواقع ، لم تنشأ رشيقة من الصفر ، ولكن فقط بسبب خيبة الأمل في جميع هذه المعايير.
أولاً ، كانت هناك فكرة أن المعايير ستنقذنا من كود ضعيف الجودة: سنكتب كل شيء وفقًا للمعايير ، وكل شيء سوف يندمج بشكل جيد ، والعمل. ربما يكون هذا صحيحًا ، فقط يتم تطوير المعايير ببطء شديد ، وكل شيء يسير بسرعة كبيرة إلى الأمام ويصبح عفا عليه الزمن قبل قبول المعايير.
ثانيًا ، كانت هناك ثقة أنه سيكون من الممكن رسم الرسوم البيانية رسميًا وفقًا لمخططات UML ، ووصف متطلبات البرامج وإنشاء رمز المصدر تلقائيًا ، وسيعمل كل هذا ، ولن يكون من الضروري حتى اختباره. كان من المفترض أن المطورين سيتوقفون قريبًا عن كتابة التعليمات البرمجية ، بدلاً من ذلك سوف يرسمون مخططات UML ويصفون الشروط في بعض اللغات عالية المستوى. لم تقلع ، لم تنجح. على الرغم من أنني في تلك الحفلة التي تحولت فيها ، تم وضع رهانات كبيرة جدًا على هذا.
الآن ، ربما بدأت نوع جديد من الموجة الجديدة: براعم الذكاء الاصطناعي من كل مكان من جميع الأماكن ، ومرة أخرى تنشأ هذه الفكرة بأن المطورين لن يكتبوا التعليمات البرمجية قريبًا. بدلاً من ذلك ، سيتم تدريب بعض أنظمة الذكاء الاصطناعي ، وسيعمل كل شيء من تلقاء نفسه. وفقًا لذلك ، لن يضطر المختبرون إلى فعل أي شيء. سيقوم المطورون بتدريب الذكاء الاصطناعي ، وسوف يفعل كل شيء. دعونا نرى كيف سيكون. ربما سينجح مثل آخر مرة.
- دعنا ننتقل إلى عصرنا. أنت تستخدم software-tinging.ru. بالنسبة لأولئك الذين لا يتبعونه بنشاط: ماذا يحدث هناك؟- ننشر الكثير من المحتوى ، الآن الجزء الرئيسي هو المحتوى المترجم. لأنه بصراحة في روسيا من الصعب جدًا العثور على مؤلفين يكتبون عن الاختبار. لا أعرف سبب حدوث ذلك: كانت هناك لحظة كتب فيها الكثير من الأشخاص باللغة الروسية ، ثم نفد وقودهم ، أو لسبب ما لم يكن هناك ما يكفي من المدونات والمقالات في RuNet. وفي جزء اللغة الإنجليزية من الإنترنت ، كل هذا لا يزال يزدهر ، وهناك الكثير من المقالات المكتوبة هناك.
انتقل الاتصال تدريجيًا إلى غرف الدردشة ، أي أن الأشخاص لا يكتبون النصوص ، بل يتواصلون. هذا لا يعني أننا نتبع هذا الاتجاه بعناية فائقة. نحن نشارك في الدردشات ، لكننا لا نحاول قيادة هذا الاتجاه. ما زلنا نتصرف بالطريقة القديمة ، نحاول إعطاء الناس المحتوى بالضبط ، وسيجدون مكانًا للتواصل.
- ينتقل الناس الآن بعيدًا عن النصوص إلى تدوين الفيديو أيضًا - ولكن هل يوجد شيء من هذا القبيل في الاختبار؟- في الاختبار ، هذا الاتجاه يكاد يكون غير مرئي. هناك حرفيا واحد أو اثنين من المدونين الفيديو ، وحالات معزولة.
- هناك تعبير "إذا كنت تريد أن تفهم شيئًا حقيقيًا - حاول شرحه للآخرين." وعندما تقوم بتحرير نصوص الآخرين بشكل منهجي ، هل تبدأ في فهم الموضوع بشكل أفضل ، بما في ذلك الزوايا ، حيث لن تنظر بنفسك؟ هل من المفيد أن يكون المختبر محررًا أيضًا؟- العمل التحريري مختلف تمامًا عن القارئ. مهمة المحرر ليست فهم ما هو مكتوب في النص ، بل عدم تفويت العيوب. بصراحة ، هذا لا يساهم في نظرة شمولية. عندما نختار مادة ، أنظر إليها أكثر كقارئ: هل من الممتع القراءة أم لا. في هذه اللحظة لست محررا بعد. ولكن عندما ننظر إلى النص المترجم ونستعد للنشر ، في هذه الحالة كمحرر. لذلك أثناء التحرير ، أثناء التحضير للنشر ، يتم فهم شيء ما - هذا لا يحدث. لذلك هناك أوضاع مختلفة: وضع واحد هو المحرر ، والآخر هو القارئ.
- سؤال غير حكيم. هناك إعلان بانر على software-tinging.ru ، ولكن في الصحافة من الصعب تحقيق الدخل معه - هل هو أفضل في حالة الاختبار ، أم لا يعوض عن عملك والموقع موجود لحب الفن؟- لا يوجد عائد إعلاني لا يعوض عن العمل على الموقع. إنه موجود من أجل إنشاء صورة ، صورة ، من أجل الحفاظ على وجودنا على الشبكة. ويكسب مركز التدريب منا.
- السؤال التالي يتعلق بالتدريب فقط. لقد قمت بتدريس الآخرين للاختبار لسنوات عديدة ، ولكن كيف يؤثر ذلك على الطريقة التي تنظر بها إلى الاختبار بنفسك؟- هنا المبدأ الذي ذكرته عن بعض الأعمال السابقة: بينما تشرح شيئًا لشخص ما ، فإنك ستفهم شيئًا بنفسك. إنه يساعد حقًا على الفهم والفهم بشكل أفضل. عندما تخبر موضوعًا لأول مرة ، يبدو أن كل شيء واضح. ثم تشاهد محاضراتك ، وتفهم ما يمكنك أن تخبره ، وتعيده ، وتظهر بعض الأشياء الجديدة. بعد ذلك ، أحيانًا أكتب بعض المقالات الإضافية: أولاً تقوم بإعداد المادة للدورة ، ثم تفهم أنك بحاجة إلى إضافة شيء آخر لجعلها أكثر وضوحًا. وبالطبع ، من المثير للاهتمام الحصول على نوع من التعليقات. يقول الناس أيضا شيئا مثيرا للاهتمام. يتم سؤالك نوعًا من الأسئلة المفاجئة ، وهنا فقط تفهم أنك لا تفهم. وأنني لم أفكر على الإطلاق في أنني يجب أن أفكر في ذلك. هذه قيمة.
- عندما تعلم الكثير من الناس ، تبدأ في ملاحظة بعض الأخطاء النموذجية لكثير من الناس. هل يمكنك صياغة بعض "أخطاء الاختبار النموذجية" العامة؟- الخطأ النموذجي بشكل عام لأي شخص هو أن معظم الأشخاص في مجال تكنولوجيا المعلومات يحاولون تعلم كل شيء من تجربتهم الخاصة ، ويخوضون جميع المجاري. من وجهة نظري ، من المنطقي التحرك بطريقة مختلفة: دراسة شيء ما ، وبعد ذلك فقط متابعة العمل.
في هذا الصدد ، أنا شخص غير عادي. عندما أشتري بعض الأجهزة المنزلية ، أجلس أولاً وأقرأ التعليمات. لذلك ، فإن نقل تجربتي النفسية إلى أشخاص آخرين أمر صعب للغاية بالنسبة لي. أفهم أن نعم ، معظم الناس لا يتصرفون على هذا النحو ، يتجولون في أشعل النار أولاً ، ثم يبدأون في معرفة كيفية تجنب ذلك. أعتقد أن هذا خطأ ، ويعتقدون أنه صحيح.
- الآن أريد أن أسأل عن السيلينيوم. كيف يدخل مجتمع سائق Selenium والنظام البيئي بأكمله من حوله إلى المجتمع؟ هل هناك خطوات وإنجازات؟ على سبيل المثال ، "قم بعشرة طلبات سحب وانتقل إلى الخطوة التالية".- لا يوجد إجراء موحد ولا لوائح ولا معايير اختيار محددة. كل شيء فردي تمامًا. عندما ترى أن الشخص متورط بالفعل ، يتم منحه تدريجياً المزيد من الحقوق. تحدث عملية تسجيل الدخول هذه بشكل مختلف للجميع. يبدأ شخص ما في تصحيح الأخطاء وإرسال طلبات السحب. ويبدأ شخص ما في الرد على المستخدمين في القائمة البريدية: لدينا شخص مسؤول عن العمل مع المستخدمين الذين ليس لديهم التزام واحد بالرمز على الإطلاق ، ولكنه في الواقع يحمل القائمة البريدية. شخص ما يكتب الوثائق -
هذه مهمة تنطوي أيضًا على العمل مع شفرة المصدر ، ولكن ، بالطبع ، يرى معظم الناس المشاركة في المشروع على وجه التحديد مع طلبات السحب.
هناك مشكلة تنظيمية تتعلق بطلبات السحب المتعلقة بعدم وجود عدد كاف من العاملين ، لذا يمكن أن تكمن طلبات السحب لفترة طويلة جدًا ، ولا أحد يعتبرها. لذلك ، يجب أن تكون مثابرا لكي يتم ملاحظتك. لا تحتاج فقط إلى إرسال طلب سحب ، بل تحتاج إلى اختراقه. أولئك الذين يخترقون هذا الفلتر ينجحون في دخول المشروع تدريجياً.
- ولمن تكتب لاختراق؟- نعم ، اكتب للجميع. في دردشة IRC ، اطلب تقييم طلب السحب. بشكل عام ، هناك مرشحات غير فنية يخترقها الشخص تدريجيًا. وإذا قمت بطلب سحب وانتظرت حتى تتم دعوتك إلى المشروع ، فلا ، فلن يفعلوا ذلك.
- أريد أن افترض بشكل بديهي أنه إذا تم تطوير أداة تحظى بشعبية كبيرة بين المختبرين ، فقد تم اختبارها في حد ذاتها بشكل أكثر دقة من متوسط مشروع تكنولوجيا المعلومات. هل يؤكد مثال السيلينيوم هذا أم لا؟- أنا لا أعرف عن "المشروع المتوسط" ، ولكن السيلينيوم يتم اختباره بدقة شديدة. هناك العديد من الاختبارات ، والاختبارات تعمل باستمرار ، وهم يعثرون باستمرار على أخطاء ، بما في ذلك أخطاء الانحدار ، بما في ذلك أخطاء الانحدار في المتصفحات. أكتب بانتظام تقارير الأخطاء لمطوري المتصفح.
يبدو لي أن الوضع مع الاختبارات مزدهر للغاية ، على الرغم من أنني لا أستطيع أن أقول أن الاختبارات مكتوبة في كل مكان بشكل منهجي تمامًا: بعد كل شيء ، فقد نمت أيضًا عضويًا على مدار العشرين عامًا الماضية. إذا بدأت في كتابتها من الصفر ، خذ المواصفات وقم بتصميمها بعناية ، فربما يكون من الأفضل كتابة العديد من الاختبارات بطريقة مختلفة. ولكن حتى الآن ، لم يكن هناك أي تفكير في الجلوس وإعادة كتابة جزء من الاختبارات بالكامل ، فالاختبارات التي تنمو عضوًا تتكيف مع مهمتها.
- غالبًا ما تكون هناك نزاعات "أي متصفح أفضل" ، وبما أنك ترسل لهم تقارير الأخطاء ، فمن المثير للاهتمام المقارنة من الجانب غير القياسي: ما المتصفحات التي لديها أفضل استجابة لتقارير الأخطاء وأيها أسوأ؟- لا أريد أن أسيء إلى أحد ، لذا لن أنتقد أي شخص ، لكن يمكنني الثناء. رد فعل مطوري فايرفوكس أفضل. هم الأكثر مشاركة والأكثر نشاطًا من حيث العمل مع تقارير الأخطاء. والتي ربما تتطابق فقط مع روح المصدر المفتوح.
والأكثر إزعاجًا ليس رد فعل الفرق لتقارير الأخطاء. هذا ما تمتلكه الشركات التي تطور مستعرضات برموز مغلقة (Microsoft و Apple). بمعنى ، عند الاجتماع مع خطأ ، لا يمكنك معرفة ما إذا كان شخص ما قد أرسل بالفعل تقريرًا عن هذا الخطأ ، هل هذا خطأ معروف.
- قبل بضع سنوات قلتم أن مهمة السيلينيوم هي أن تصبح معيارًا على الويب. أصبح ، ثم ماذا؟ ما هو المعلم الكبير القادم؟- التقاط العالم في مواجهة أدوات الأتمتة. أي أننا بحاجة إلى ضمان دعم كل هذا المعيار الجديد.
- أي أن تصبح وحدة مضمنة لجميع أدوات الأتمتة الجديدة لواجهة المستخدم؟- نعم. أي أنه يمكنهم استخدام عشر وحدات أخرى ، ولكن يجب أن يكونوا جميعًا قادرين على العمل من خلال البروتوكول القياسي.
يوجد داخل السيلينيوم المهمة المهمة التالية ، والتي سيتم حلها أولاً من خلال بعض تطبيقات النموذج الأولي ، ثم في إطار المعيار. بروتوكول HTTP هو في الأساس اتجاه واحد ، أي أن أحد الجانبين يرسل الطلبات ، والآخر يعالجها ، ولا توجد أي ملاحظات تقريبًا. وهذا ليس جيدًا جدًا ، وبالتحديد هنا يشير المنافسون بنشاط إلى هذا الأمر ، مما يضغط على هذه البقعة المؤلمة ، لأنني أود ، تقريبًا ، أن يكون لدي استدعاءات. عندما تحدث بعض الأحداث في المتصفح ، أود الحصول على بعض الإشعارات حول هذا الأمر. هذا ليس بعد في أداة السيلينيوم. لكننا نريد حقًا إضافة هذا. لذلك ، ربما ، ستحدث تغييرات أساسية ، من الممكن تغيير البروتوكول. بدون هذا ، سيكون من الصعب. نحن بحاجة إلى بروتوكول ثنائي الاتجاه.
"أنت وسيمون ستيوارت مساهمان رئيسيان في السيلينيوم ، أليس كذلك؟"- هذا صحيح عندما يتعلق الأمر بجزء جافا.
"على حد علمي ، لم تلتقِ قط". كيف حدث ذلك؟ مطوري السيلينيوم ليس لديهم أي "شركة"؟- "حفلات الشركات" لدينا في شكل اجتماعات في المؤتمرات ، ولكن بشكل منفصل - لا. وفي حالة المؤتمرات ، جاء سايمون حتى إلى Heisenbug العام الماضي في موسكو ، لكنني لم أكن في موسكو في تلك اللحظة ، لذلك لم نتقاطع.
لكن ، بصراحة ، نحن نعيش الآن في عالم لا بأس به ، ما زلنا نتواصل باستمرار.
- السؤال الأخير ، أخيراً. ما رأيك سيكون مستقبل اختبار الأتمتة بشكل عام وواجهة المستخدم بشكل خاص؟- لا أرغب في عمل تنبؤات ، لأنها لا تتحقق أبدًا. الاختبار وراء التطوير مع بعض التأخير ؛ لذلك ، يملي المطورون الموضة: لقد اقتحموا وديا إلى JS - في الاختبار أيضًا ، اقتحموا جميعًا وديا إلى JS. وسنحتاج لمواكبة التغييرات. وماذا سيكون للمطورين - من يدري.
سيقدم أليكسي عرضًا في موسكو Heisenbug في 6-7 ديسمبر - وإلى جانبه ، سيكون هناك العشرات من المتحدثين الآخرين. على موقع Heisenbug يمكنك رؤية البرنامج الكامل وشراء تذكرة.