شاهد الفيديو واقرأ النص واكتب رأيك في الأسئلة المطروحة في التعليقات. دعونا نكتشفها معًا: أكون أو لا أكون؟
المناقشة رقم واحد
الرموز الزمنية 0:56 - هل الاختبار ضروري دائمًا؟
2:00 - لماذا تختبر ما إذا كنت بحاجة إلى طرح ميزات في السوق في أسرع وقت ممكن؟
3:24 - هل من الممكن اختبار الوظائف الأساسية فقط أو جزء واحد من التطبيق؟
5:29 - معايير اختبار الوظيفة
7:28 - في أي مرحلة يجب أن تتوقف شركة ناشئة أو شركة تعهيد إطلاق الميزات والبدء في إضاعة الوقت في الاختبار
بدأ اللقاء على الفور باجتماع ساخن - بالمناقشات. لذلك ، سوف نقدم المشاركين في مناقشتنا عبر الإنترنت:
- ديمتري فورونين ، مهندس رئيسي في فريق Speed (Avito).
- يوري Chechetkin ، مطور المحمول (Revolut)
- ديمتري مانكو ، مطور Android (Citymobil)
- نينا سيمكينا ، مبرمجة أولى (Yandex.Money)
- فلاديمير جينوفيتش ، المبرمج الرئيسي (Yandex.Money)
- ديمتري زاكوف ، مختبر (Yandex.Money)
نينا سيمكينا: كثير من الناس يقولون إنه يجب إدخال الاختبار في المشاريع ... لكن الجميع يفهم أنه مكلف للغاية. من المكلف للغاية قضاء وقت المطورين ومجموعة من الموارد التي تغطي جميع الكود بالاختبارات. هل يجب إجراء الاختبار دائمًا؟
ديمتري مانكو: ما الذي ستختبره؟
نينا سمكة: تطبيق أندرويد. متى أحتاج إلى فهم أن 100٪ منها بحاجة إلى الاختبار؟
ديمتري مانكو:إذا كان السوق لا ينتظر ظهور أي وظيفة ، إذن ، من وجهة نظر التطوير أو من وجهة نظر التغطية ، يمكن تبسيط الاختبار أو إهماله تمامًا. كل هذا يتوقف على المنتج. إذا كنا نصنع آلة حاسبة بوظيفتين ، فمن المرجح أننا مررنا بسلسلة من حالات الاختبار أكثر من مرة. وبالتالي ، يمكن حذف الاختبارات ، ويمكن طرح التطبيق في السوق بشكل أسرع ، ويمكن تقليل وقت الوصول إلى السوق.
نينا سمكينه:لدينا دائمًا سباق من الوقت إلى السوق ، يتطلب السوق دائمًا مجموعة من الميزات ، ولا يمكننا إبطائها. خاصة عندما يتعلق الأمر بمشروع بدأ للتو والذي يجب إطلاقه في السوق الآن ، ليس لدينا اسم ، نحن نتنافس مع شركات أخرى. ما الذي يهمنا إجراء الاختبار في هذه اللحظة؟ نحتاج إلى تزويد تطبيقنا بالميزات ورميها بشكل أسرع ، وإلا فستصبح قديمة في غضون 3 أسابيع. لماذا تختبرهم؟
ديمتري فورونين:في الواقع ، تبدأ سرعة التطوير في مرحلة ما بالاعتماد على تغطية الاختبار. على سبيل المثال ، إذا كان النشاط التجاري مرتبطًا بشكل معماري بشاشة رئيسية واحدة ، حيث توجد جميع الميزات الرئيسية ، ويتم إجراء التغييرات هناك مرات عديدة ، فعندئذٍ بدون اختبارات يمكنك البدء في التحرك ببطء أكثر ، حتى مع وجود "خط أنابيب كبير للميزات". يبدو أنه بمجرد ظهور إشارات تدل على أنك غالبًا ما تعود إلى الانحدار ، أي سبب للتفكير في حقيقة أن هناك خطأ ما في الغلاف وأنك لا تتخذ إجراءات رد الفعل. على سبيل المثال ، غالبًا ما ينكسر شيء ما ، مما يعني أن هذا المكان لا يتم اختباره كما ينبغي.
نينا سمكينه:هل يمكنني أن أستنتج أنك بحاجة إلى اختبار الوظائف الأساسية فقط باستمرار ، وربط الميزات "بنقطة واحدة". دع هذه الميزات الفردية تحتوي على أخطاء ، لكنها ربما لن تكون موجودة اليوم وغدًا. هل يمكنني اختبار جزء واحد فقط من التطبيق؟
ديمتري مانكو: أفضل أن أقول إن الأجزاء الرئيسية تستحق الاختبار. ما هو مهم من وجهة نظر العمل لهذا المنتج. وإذا كانت هناك ميزات بها أخطاء ، فستكون موجودة في مكان ما بشكل منفصل ولا تؤثر على شيء مشترك ، ثم أغلقها بشكل مثالي بتبديل عن بُعد. وإذا رأيت وفقًا للتحليلات أن هناك أخطاء بالفعل ويشكو المستخدمون ، فقم بإيقاف تشغيل هذه الميزة.
ديمتري فورونين:تطرقت ديما إلى موضوع جيد ، وهو أن الاختبارات ليست أداة مراقبة الجودة الوحيدة التي يمتلكها المطور. يجب أن تتذكر دائمًا أنه بالإضافة إلى اختبارات الوحدة والتكامل ، الاختبار اليدوي ، هناك ويجب أن تكون المراقبة. وهناك طرق لطرح التغييرات والتراجع عنها. إذا كانت لديك كل هذه الممارسات الهندسية ، فيمكنك من حيث المبدأ إهمال بعض الأدوات لصالح أدوات أخرى ، إذا كانت السرعة تستفيد من ذلك. ولكن بشكل عام ، يُعتبر دائمًا شكلًا جيدًا إذا كان المطور لديه ثقافة اختبار - أنه أكثر راحة وموثوقية بالنسبة له لتقديم التغييرات حتى يختبر الوظائف التي يجب أن يؤديها. في شركتنا ، من المعتاد ترك مثل هذا الرمز ، حيث يمكنك بعد ذلك إجراء التغييرات بسهولة ، وإجراء الاختبارات بسرعة لفهم أنك لم تفسد ما حدث بالفعل.
نينا سمكينا: في الدردشة يكتبون أنك بحاجة لاختبار ما يجلب لك الدخل. وعند اختبار التكاليف أقل من الخسائر المحتملة من الوظائف غير العاملة. من حيث المبدأ ، يعد هذا معيارًا جيدًا لفهم ما يجب اختباره بالضبط. هل يمكنك تسمية أي معايير أخرى لاختبار وظيفة معينة؟
ديمتري مانكو: يمكن تحديد المعايير باستخدام التحليلات. على سبيل المثال ، إذا قمت بإصلاح الوظائف الأكثر استخدامًا ، فمن المستحسن أيضًا اختبارها بحيث يواجه المستخدمون أخطاءً قليلة قدر الإمكان. إذا كانت الحشرات في أماكن نادرة ، فهذه مشكلة صغيرة. وإذا كان الحظر على شاشة التفويض ، فقد لا يكون حرجًا ، لكنه لا يزال خطأ سيراه الجميع. وهذا بالفعل خطر على السمعة.
ديمتري زاكوف:بشكل عام هناك حاجة للاختبار. يجب ألا ننسى أن الاختبار هو اختبار للمتطلبات التي نضعها على المنتج. إذا كان هناك شيء لا يفي بالمتطلبات ، فهذه مشكلة أو خطأ أو مشكلة. يمكن أتمتة جميع حالات الاختبار والاختبار ، وإذا لم يكن هناك وقت كافٍ ، فمن الجدير أولاً التحقق من اللحظات الحرجة ، ثم كل شيء آخر. على سبيل المثال ، إذا كان لديك إصدار غدًا وتريد الشركة ميزة غدًا ، فعليك التحقق من الوظائف الأكثر أهمية. وإذا كان لديك ما يكفي من الوقت ، يمكنك التحقق من الحالات المتوسطة والمنخفضة. يتعلق الأمر أكثر بما إذا كان الاختبار الخاص بك سيكون يدويًا أم آليًا. سواء كانت مقاييس أو اختبار واجهة المستخدم ، يمكن التحقق منها بالكامل بواسطة روبوت.
نينا سمكة:نتحدث جميعًا الآن نيابة عن الشركات الكبيرة التي لديها العديد من الموارد والفرص. وإذا أخذنا في الاعتبار وجهة نظر الشركات الصغيرة والشركات الناشئة التي لديها وقت وموارد محدودة. أعتقد أنه في البداية سيضحي الجميع بالاختبار هناك. في أي نقطة يمكننا أن نفهم أن هذا هو المعلم الهام عندما يجب أن نتوقف ونوقف عرض الميزات وننفق الموارد على الاختبار؟
ديمتري مانكو:يمكنني مشاركة رأيي ، لأنني جئت من شركة تعهيد. يتعلق الاستعانة بمصادر خارجية في المقام الأول بمكان بيع ساعات العمل ، والاختبار مكلف حقًا هناك. في بعض الأحيان يكلف أكثر من تطوير الوظيفة نفسها. شركات التعهيد هذه ، عندما ينتظر العميل التطبيق و "يركلها جانبًا" ، لا تشتهر بالاختبار. في فريقنا ، نواجه الموقف التالي. المنتج عبارة عن قائمة للأشرطة ، حيث تم استخدام العروض الترويجية لعدد كبير من الحالات (عيد ميلاد ، 2 مقابل 1 ، طالب ، إلخ). ولاحظنا أن وظيفة الأسهم هذه كانت تتعطل كل شهر لمدة عام. ثم وصفت اختبارات الوحدة جميع الحالات بشكل مثالي. لقد فهمنا كيف يعمل كل شيء (كان هناك حوالي 70 حالة اختبار). لقد تغلبنا على هذا المنتج ، لكن ، بالطبع ، لن يكون من الممكن القيام بذلك في كل مكان.
يوري تشيشتكين:تجربتي في العمل في الشركات الكبيرة - Yandex و Alfa-Bank و Revolut - في مجال التكنولوجيا المالية ، حيث تنفد أهمية أي خطأ على نطاق واسع. ومع ذلك ، لدي خبرة في بدء التشغيل ، وحتى هناك ، كان الاختبار ضروريًا للغاية. أعتقد أنه لا يهم ما إذا كانت شركة ناشئة أم لا ، لأن المطور يجب أن يكون مسؤولاً عن الكود الخاص به ، والاختبارات هي ضمان عمل هذا الرمز. المطور هو في الأساس مهندس مسئول عن المنتج الذي يتم تطويره. لذلك ، تحتاج إلى كتابة الاختبارات ليس لأنك بحاجة إلى ذلك ، ولكن لأنها يجب أن تساعدك. إذا كانت هذه الاختبارات مكتوبة للعرض ، فقد يؤدي ذلك إلى إبطاء التطور. وإذا كنت بحاجة إلى اختبارات وفهمتها بنفسك ، فيجب كتابتها. إذا كتب المطور كودًا وكان واثقًا من أنه يعمل بدون اختبارات ، فهذه مخاطرة وهي اختياره. لكن ما زلت أعتقدأن المطور لا يجب أن يخاطر وأن يغطي نفسه ويغطي كل شيء بالاختبارات.
نينا سيمكينا: لذلك ، قررنا أننا بحاجة إلى اختبار الكود بطريقة ما ، وسنحلل هذا الموضوع بمزيد من التفصيل. أعطي الكلمة الآن لفلاديمير جينوفيتش بتقريره .
المناقشة رقم اثنين
الرموز الزمنية 0:09 - كيفية إزالة حمل الانحدار من QA قبل الإصدارات؟ هل لدى الشركات إستراتيجية لتحسين استقرار التطبيق؟
4:25 - هل يعقل استخدام أدوات وهمية أو وهمية في اختبارات واجهة المستخدم
8:05 - اختبار على المستخدمين: هل هذا مقبول أم لا؟
نينا سمكينا: خلال التقرير تلقينا سؤالا في الدردشة ومنه أود أن أكمل مناقشتنا. كيف يمكن إزالة حمل الانحدار من ضمان الجودة قبل الإصدارات؟ ما هي الممارسات التي يستخدمها المتحدثون لدينا في اختيار الأماكن للاختبار؟ هل لدى الشركات استراتيجية لتحسين استقرار التطبيق وتفريغ متخصصي ضمان الجودة؟
ديمتري زاكوف:استراتيجيتنا هي أن نختبر كل شيء. لأننا آخر الحدود ، كموظفين قبل المستخدمين. لذلك ، نقدم فقط مثل هذا التطبيق للعميل ، والذي يعمل بثبات دائمًا وفي كل مكان. السؤال الوحيد هو السرعة. في البداية ، استغرقنا التشغيل اليدوي وقتًا طويلاً - يصل إلى أسبوع. ولكن بفضل الأتمتة ، توصلنا إلى أن الإصدار يستمر بمعدل 24 ساعة. لذلك ، إذا كنت تقوم بتطوير أي وظيفة ، فأنت بحاجة إلى الموافقة على قيامك أنت أو المختبرين بكتابة الاختبارات التلقائية على الفور. وبعض الحالات الخاصة بالهواتف المحمولة التي لا يمكنك أتمتتها سيتعين فقط التحقق منها عند الانحدار ، وسيقوم الروبوت بفحص الباقي. وبالتالي ، ستقوم بإلغاء تحميل المختبرين ، وسوف يشاركون في أعمال بحثية أكثر إثارة للاهتمام ، وستمنح الروبوت الروتين بأكمله - النقر فوق البرامج النصية.
يوري Chechetkin: معظم الشركات الكبرى ترفض اختبار الجودة ، يدويًا. هذا ليس مسارًا ثوريًا تمامًا ، ولكنه جزء من بقايا الماضي. وعلى سبيل المثال ، في شركتي ، حيث أعمل الآن ، لم يتم حتى نطق كلمة مثل الانحدار. ليس لدينا قسم لضمان الجودة على الإطلاق.
فلاديمير جينوفيتش: ربما قمت بأتمتة ذلك؟
يوري تشيتكين: ليس بالضبط ، لقد كان فقط في المراحل الأولى من المشروع ، ثم رحل على الإطلاق.
فلاديمير جينوفيتش: أنت تجري اختبارات واجهة المستخدم ، أليس كذلك؟
يوري تشيتكين: هناك بالطبع اختبارات لواجهة المستخدم.
فلاديمير جينوفيتش: وماذا عن اختبارات الوحدة؟ إذن ، إجراء هذه الاختبارات عند الإصدار ليس تراجعًا؟
يوري تشيشتكين:نعم ، هذا انحدار ، لكن لا يوجد اختبار يدوي اعتدنا على الحديث عنه. وهذا نهج مثير للاهتمام. إنه يبعث على اليقظة ويحول المطور من "طفل" يكتب التعليمات البرمجية ويعطيها للمختبرين ، إلى مهندس أكثر نضجًا واستقلالية يكون مسؤولاً عن الكود الخاص به. بالنسبة للأشياء المرئية ، يمكن إجراء المراجعة بواسطة مصمم أو PO. وهناك أشياء مثل اختبارات لقطة الشاشة - مثل Facebook. لذلك يبدو أن شركات الأغذية الآن يمكنها الاستغناء عن ضمان الجودة. ويمكن للمختبرين أنفسهم القيام بعمل أكثر إثارة للاهتمام. بالطبع ، هناك قصة مختلفة قليلاً في الاستعانة بمصادر خارجية - يبيعون ساعات العمل ، ويمكن بيع ضمان الجودة كخدمة إضافية.
ديمتري زاكوف:اتضح أن لديك تراجعًا ، يتم تسليمه ببساطة إلى الأتمتة ، ولديك أشخاص يشاركون في العمل البحثي لتطبيقك. لا يمكن أن يكون الاختبار واجهة مستخدم فحسب ، بل يمكن أن يكون مختلفًا أيضًا.
يوري تشيتكين: نعم ، على سبيل المثال ، الاختبار على المستخدمين.
نينا سمكينا: قبل أن نتطرق إلى هذا الموضوع الخطير للغاية ، أود أن أقرأ السؤال التالي من مستمعينا. هل يعقل استخدام أدوات وهمية أو أشياء مزيفة في اختبارات واجهة المستخدم؟
ديمتري فورونين:من المنطقي ، وبدونهم لا مكان. لأن اختبارات واجهة المستخدم المتكاملة تمامًا أمر غير موثوق به للغاية. ولا يمكنك أبدًا الاعتماد على اختبار يحتوي على 30 نظامًا ، لكل منها مجموعة من نقاط الفشل التي تقوم بتنفيذ طلب سحب. هذه الاختبارات ليست قابلة للتطبيق. ولا يمكن لأي شخص في أي شركة أن يجعل مثل هذه الأشياء تعمل. لذلك ، فإن اختبارات واجهة المستخدم هي لعنة تطوير الأجهزة المحمولة. إذا كان ذلك ممكنًا ، فمن الأفضل الاختبار بدون واجهة المستخدم. ولكن نظرًا لحقيقة أننا مجبرون على العيش مع إطار عمل ، والبديل الوحيد هو نوع من الروبوتات ، وفي نظام iOS ، حتى هذا ليس كذلك. ومن أجل التحقق من التفاعل مع واحد على الأقل من الأنظمة المهمة بالنسبة لنا ، نقوم بتشغيل كل شيء على الجهاز. واجهة المستخدم موجودة هنا بقدر ما ، نظرًا لعدم نضجنا في التطوير ، نريد التقاط أكبر قدر ممكن من أجل التحقق من كيفية نقر المستخدم - فنحن أكثر هدوءًا. يبدو لي،أنه بعد مرور بعض الوقت سيصبح هذا شيئًا من الماضي ولن نخاف بعد الآن من السخرية والنقرات ولن نقاتل النظام للتحقق من كل شيء كما ينبغي ، لأننا لن نتحقق من كل شيء على أي حال. قد تكون هناك أخطاء بصرية لن يتم التحقق منها بواسطة أي اختبارات لواجهة المستخدم. لذلك ، أعتقد أن الاستهزاء في اختبارات واجهة المستخدم يمكن ويجب أن يتم ، والهدف الرئيسي من ذلك هو زيادة استقرار هذه الأداة ، للوصول بها إلى هذه الحالة التي تكون مفيدة. والفائدة الحقيقية في هذه الحالة هي التأكد من عدم وجود تراجعات. وأي أداة تتدفق تتحول إلى "D" الثاني من التقرير السابق لفلاديمير جينوفيتش ، عندما نتوقف عن الثقة. يحدث هذا عندما يبدأ عدد كبير من القيم العشوائية في الوصول إلى اختبارنا. ومثل هذا الاختبار لا يعطي أي ثقة بالنفس ، ولكنه يعطي فقط أملًا كاذبًا في اختبار شيء ما.
ديمتري زاكوف: حوالي 70٪ من حالاتنا آلية ، ولا يستخدمون نموذجًا وهميًا واحدًا في التطبيق. قد يكون من الأسهل ترحيلها إلى الخلفية. على سبيل المثال ، إذا كان يشير إلى رقم البطاقة ، فإنك تتوقع عدم طلب 3DS منك. أي أن التطبيق لا يعرف أنه مقفل. أعتقد أن هذه مشكلة بنية تحتية.
نينا سيمكينا: قبل الانتقال إلى التقرير التالي ، أود أن أذكر موضوعًا زلقًا واحدًا - اختبار المستخدم. كثيرون يخطئون في هذا: إنهم يريدون دائمًا ويحقنون ... ما رأيك في هذا؟ هل من الممكن أن تسمح لنفسك بالاطلاع على المستخدمين الخادعين ، وجمع الأعطال منهم وإصلاحها بنفسك. وبعد الاختبار عليها ، قم بطرح إصدارات كاملة جيدة. أم أنها غير مقبولة بشكل عام؟ أم أن هناك حدودا معقولة؟
يوري تشيشتكين:نحن في Revolut نمارس هذا قليلاً بمعنى أنه لا يذهب مباشرة إلى المعركة ، ولكن على مستخدمين حقيقيين. العرض التوضيحي هو أيضًا بعض الاختبارات على المستخدمين ، وخلال العرض التوضيحي تظهر أسئلة حول التدفق وما إلى ذلك. في هذه المرحلة ، قد تكون هناك أسئلة حول التصميم والميكانيكا العامة. من بين أشياء أخرى ، هناك تدحرج داخلي - الشركة كبيرة ، أكثر من 1000 شخص ، ويمكننا طرحها بين الزملاء. هذا اختبار المستخدم ، ولكن ليس خارجيًا ، ويبدو أنه آمن. وبعد ذلك يمكن طرحها لنسبة صغيرة من المستخدمين الحقيقيين بالخارج ، ولكن مع إمكانية إغلاق هذه الميزة بتبديل. ما رأيك يمكن أن يحدث خطأ خلال هذه المراحل؟
ديمتري مانكو:في واقعنا ، يمكن أن تسوء الأمور. بغض النظر عن مدى صعوبة محاولتنا تنفيذ هذه المراحل بشكل جيد ، على أي حال ، تقفز الحالات عندما نحتاج إلى مراقبة تحليلات الأعطال. لا ينتهي الإصدار بحقيقة أننا أرسلناه إلى المتجر ، فقد مرت جميع المراحل ، وكل شيء على ما يرام معنا. عليك أن تتابع كيف يتصرف التطبيق.
يوري تشيتكين: نعم بالتأكيد. في حالتنا ، لدينا عرض توضيحي وطرح داخلي واختبار لـ 5٪ من المستخدمين بدلاً من الاختبار اليدوي. بالطبع ، بعد إصدار الميزة ، تحتاج إلى النظر. يجب ألا يكون التدحرج 100٪ على الفور - فهذه هي آلية الدفاع الرئيسية.
ديمتري فورونين:تتعامل Google مع المسألة الأخلاقية الخاصة باختبار المستخدم. لا يبدو أن Apple لديها ذلك. هناك قنوات توزيع خاصة كما تعلم (ألفا ، بيتا ... إنتاج). يمكن لأي شخص الدخول في اختبار بيتا ، وهم يوافقون على نموذج مفهوم ، والذي ينص على أنهم يوافقون تمامًا على أنهم قد يتلقون نسخة غير مستقرة من المنتج. ولذا فهو يريد التطوع ومساعدة الشركة على تحسين المنتج. بمجرد أن نخبر شخصًا ما عن هذا الأمر علانية ، أعتقد أنه يجب إزالة هذه المشكلة ويجب ألا نخاف من طرح إصدار لسنا متأكدين منه بنسبة 100٪. بل إنه أفضل عندما يكون لدينا ملاحظات من هناك ، ومع كل إصدار غير مستقر ، نقوم بتحسين هذه العملية. إذا كانت الشركة لديها عمليات تتبع اتجاهات الجودة في الإصدار التجريبي ، فيجب أن تتحسن الأمور فقط.وهذه أيضًا ميزة إضافية للمستخدمين - سيكونون أول من يتلقى الميزات. هؤلاء هم في الغالب مستخدمون متحمسون ومخلصون لمنتجك ، وسيرغبون هم أنفسهم في اختبار أشياء جديدة تظهر في التطبيق. وسيكونون مستعدين حتى للتضحية بشيء من أجل ذلك.
نينا سمكة: نفهم أننا عندما نتحدث عن جمهور مخلص فهو مخلص طالما أنه لا يؤثر على مصالحه الشخصية. هذه هي الطريقة التي يمكننا بها طرح ميزات مع كعكات صغيرة إضافية ، والتي حتى لو سقطت ، لن يشعر هؤلاء المستخدمون بالضيق الشديد. ولكن حتى إذا أكد هذا الشخص أنه مستعد لأخذ نسخة الاختبار ، ولكن حدث خطأ ما خطير معه (على سبيل المثال ، سيتم شطب أموال إضافية) ، فلن يكون مخلصًا بعد الآن. وكلما كبرت الشركة ، زادت قسوة استجابة المستخدم بشأن المنتج.
فلاديمير جينوفيتش:ولكن ماذا عن المتبني الأوائل ، الذي يحبك ، بغض النظر عن كيفية إفساد الشركة؟ وعلى الأرجح ، ستكون هذه الشركة قادرة على تعويض الخسائر. موافق ، إذا طرحنا شيئًا ما ، نقول للمستخدم: "اسمع ، نحن خائفون جدًا. ويمكنك أن تخسر 1000 روبل. لكننا سنعوضك ". على الأرجح ، سيفعل هذا المستخدم ذلك على مسؤوليته ومخاطرته الخاصة ، وإذا ضاع المال ، فلن نخبره لاحقًا: "حسنًا ، أنت نفسك الملام". لذلك ، أعتقد أنه حتى في حالة التطبيق المصرفي ، يمكننا مساعدة المستخدمين.
ديمتري زاكوف:وإذا كان لديك عدد قليل جدًا من مختبري الإصدارات التجريبية ، فيمكنك استخدام اختبار A / B بمساعدة ملفات التكوين لتمكين / تعطيل بعض الميزات ، بحيث في حالة حدوث عطل ، يمكنك تعطيل أي شيء على الفور واختباره حسب الحاجة. كما نتذكر ، من الصعب جدًا التراجع في الهاتف المحمول ، لذلك من الأفضل التحقق من كل شيء إلى أقصى حد قبل الإصدار.
فلاديمير جينوفيتش: أو اكتب في React Native))
نينا سيمكينا: سأقاطع محادثتنا ، حيث حان وقت التقرير التالي. ديما ، أعطي الكلمة لك.
رقم ثلاثة المناقشة
الرموز الزمنية 0:05 - كيفية تحسين اختبار الانحدار؟ كيف ومتى يتم تقديم الاختبار في تطوير الميزات (تجربة Avito)
10:43 - أين تتابع اختبارات الوحدة: على CI أو محليًا قبل الدفع؟
نينا سيمكينا: أود الاتصال بـ Dima Voronin للاستماع إلى رأيه وعن تجربته حول كيفية تحسين اختبار الانحدار في الشركة ومتى يقدمون الاختبار عند تطوير الميزات.
ديمتري فورونين:أنا حقا لدي شيء لأشاركه. هذا هو تاريخ خمس سنوات من التعامل مع الانحدار اليدوي. وهذا جزئيًا استمرار للإجابة على السؤال الذي كان لدينا بين التقريرين الأولين. هذا السؤال يدور حول ما يجب فعله إذا كان لديك انحدار يدوي. لأنه لن يتمكن الجميع من تكرار تجربة الثورة. الرجال رائعون ، لقد قطعوا الكتف ، وتمكنوا من القيام بذلك بشكل موثوق. يتطلب الأمر الكثير من الشجاعة ، وثقافة إنمائية جيدة ، والأهم من ذلك ، فهم قادة التنمية الذين لا يشعرون بالحماس تجاه هذا النهج. يحدث هذا بسبب القصور الذاتي في عملنا وقد يكون من الصعب تغيير الأسس ، خاصة في الشركات الكبيرة. يثبت مثال Revolut أنه إذا نجح ، فهو على الأقل أسرع من الانحدار اليدوي ، ويبدأ كل مطور في طرح الأسئلة الصحيحة على نفسه.أي أنه يبدأ في تحمل المسؤولية عن معظم دورة الإصدار ، أي ليس حتى اللحظة التي يرتكب فيها التغييرات ، ولكن مثل أي مهندس بالغ ، فإنه يقود المنتج أيضًا في مرحلة الإصدار.
ماذا حدث معنا؟ لقد وصلنا إلى النقطة التي كان لدينا فيها انحدار يدوي قام به 5 أشخاص لمدة 12 يوم عمل ، وبدون ذلك لن يتم تشغيل تطبيق الهاتف المحمول. كان عام 2015. وفي تلك اللحظة ، لم يكن لدينا اختبار واحد تلقائي لواجهة المستخدم. لقد كتبنا اختبارات الوحدة تقريبًا منذ البداية وكتبنا بنشاط كبير. تحدث فلاديمير في تقريره عن 10 ثوانٍ و 1000 اختبار - إنه أمر مخيف بالنسبة لي أن أتخيل عندما مررنا بهذه اللحظة في عام 2014. الآن لدينا 12000 اختبار وحدة ، ولا تستغرق 10 ثوانٍ ، وهذه أيضًا ليست قطعة مجانية. على الرغم من أن جميع المهندسين يفهمون ويكتبون الاختبارات ، إلا أن هناك لحظة صعبة. لا تثبت كل اختبارات الوحدة هذه وجود غرام واحد عن الأخطاء في الإنتاج وكيف يتصرف التطبيق. وهذا يعني أن الاختبار يلتقط السلوك ويسهل إجراء التغييرات ويعطي التعليقات ،هل تفعل ذلك بشكل صحيح. المشكلة هي أن هناك قسم ضمان الجودة. بالطبع ، ليست هذه هي المشكلة. المشكلة هي أن لديهم مهمة لتوفير مستوى معين من الجودة. وهم معتادون على الوصول إلى هذا المستوى ، يتحملون هذه المسؤولية. ومن الصعب تغيير هذه اللحظة إذا لم تأت من بداية منتجك. ما هي الوصفات الموجودة؟ أصح شيء هو عدم تشغيل الوضع الصعب عندما نقوم بفصل الجميع ويتم الاستيلاء على كل شيء بواسطة الأتمتة. ربما كان هذا هو النهج الأكثر رعبًا والأكثر نضجًا الذي رأيته. ما المشكلة في هذا الأمر؟ أولاً ، ستفقد جودة الاختبار لبعض الوقت. ثانيًا ، يتم تدمير جميع العمليات ، ولا يتم إنشاء عمليات جديدة بسرعة.وهم معتادون على الوصول إلى هذا المستوى ، يتحملون هذه المسؤولية. ومن الصعب تغيير هذه اللحظة إذا لم تأت من بداية منتجك. ما هي الوصفات الموجودة؟ أصح شيء هو عدم تشغيل الوضع الصعب عندما نقوم بفصل الجميع ويتم الاستيلاء على كل شيء بواسطة الأتمتة. ربما كان هذا هو النهج الأكثر رعبًا والأكثر نضجًا الذي رأيته. ما المشكلة في هذا الأمر؟ أولاً ، ستفقد جودة الاختبار لبعض الوقت. ثانيًا ، يتم تدمير جميع العمليات ، ولا يتم إنشاء عمليات جديدة بسرعة.وهم معتادون على الوصول إلى هذا المستوى ، يتحملون هذه المسؤولية. ومن الصعب تغيير هذه اللحظة إذا لم تأت من بداية منتجك. ما هي الوصفات الموجودة؟ أصح شيء هو عدم تشغيل الوضع الصعب عندما نقوم بفصل الجميع ويتم الاستيلاء على كل شيء بواسطة الأتمتة. ربما كان هذا هو النهج الأكثر رعبًا والأكثر نضجًا الذي رأيته. ما المشكلة في هذا الأمر؟ أولاً ، ستفقد جودة الاختبار لبعض الوقت. ثانيًا ، يتم تدمير جميع العمليات ، ولا يتم إنشاء عمليات جديدة بسرعة.ستفقد جودة الاختبار لبعض الوقت. ثانيًا ، يتم تدمير جميع العمليات ، ولا يتم إنشاء عمليات جديدة بسرعة.ستفقد جودة الاختبار لبعض الوقت. ثانيًا ، يتم تدمير جميع العمليات ، ولا يتم إنشاء عمليات جديدة بسرعة.
ماذا فعلنا؟ بدأنا التحسين من خلال كتابة اختبارات واجهة المستخدم التي تحل محل الانحدار. وهذا يعني أن هذه اختبارات بنية تحتية كاملة تلامس الخلفية مع مستخدمي الاختبار. وفي الواقع ، كانت نتيجة هذا العمل ، كما تعلمون ، كل أنواع الأطر الشائعة - على سبيل المثال ، Kaspresso. هذا هو بالضبط ما وضعناه عندما بدأنا. تركنا وراءنا مجموعة من القطع الأثرية التي يمكن أن تساعد المطورين. وبالتالي ، من السهل الدخول في الاختبار الآن. نضع أيضًا عدائين مختلفين في المصدر المفتوح ، ويمكن للجميع رؤية كيفية عملنا معهم. لكننا لم ننسى الاختبار اليدوي ، والتحسين ، وكيف يبدأ هذان القسمان في الاندماج في عملية واحدة فعالة. ربما النقطة ب هي حالة الثورة. لكن طريقنا من النقطة أ إلى النقطة ب ، مثل العديد من الشركات الأخرى ،يستغرق وقتا طويلا. نحن الآن في المرحلة التي يلعب فيها ضمان الجودة دور الباحثين ، فهم يغمرون أنفسهم أكثر في المنتج ، ويعملون على المتطلبات الوظيفية ، ويكتبون الاختبارات التلقائية.
الشيء الأكثر إثارة للاهتمام حول ممارسة تحسين الانحدار اليدوي هو تحليل التأثير. أي محاولة للإجابة على السؤال: "ما الذي تغير في هذا الإصدار؟" وما الذي يمكننا اختباره وما الذي يمكننا طرحه براحة البال للمراحل التالية. يعد تحليل التأثير سؤالًا صعبًا ، لأنه عندما يكون لديك دورة إصدار كبيرة ، أي يتم الإفراج عنك لمدة 2-3 أشهر ، فإن تحليل التأثير سيجيب عليك دائمًا ، لأنه خلال هذا الوقت ، لم يتم التطرق إلى أي جزء من التطبيق. ولكن إذا قمت بتقصير دورة الإصدار هذه إلى أسبوع ، أو حتى أفضل من ذلك إلى يوم واحد ، فإن تحليل التأثير يظهر أشياء مناسبة تمامًا ، ويترك علامات تساعد في تحسين الانحدار اليدوي. لقد طبقنا هذه الممارسة بنجاح كبير. في البداية ، كانت هناك أخطاء ، لكننا قللنا مقدار الاختبار اليدوي لمرة واحدة.
الممارسة التالية هي تحسين نموذج الاختبار. الغريب ، ولكن في الاختبارات هناك أيضًا تراث: الاختبارات مكتوبة ، لكنها قد لا تكون مثالية جدًا ، ثم تمت إضافة شيء آخر هناك ، ولم تتم معالجة حالات الاختبار لهذا ... مع تحليل مفصل ، اتضح أنه يمكن تقليلها عدة مرات عدد سيناريوهات الاختبار.
سمحت لنا هذه الاتجاهات الثلاثة بالوصول إلى النقطة التي نطلقها إلى الإصدار التجريبي مرة واحدة يوميًا ، ومرة واحدة في الأسبوع تصل إلى 100٪ من المستخدمين ، ولا يوجد تراجع يدوي. آمل أن تحفز هذه القصة الشركات ، غير الراضية عن حالة إصدارها ، على التصرف - من أجل الضغط فقط على زر التحرير في المستقبل ، كل شيء يذهب إلى المستخدمين ، والجميع ينظر إلى الرسوم البيانية فقط.
يوري تشيشتكين:هذه ، بالطبع ، ليست فقط ممارسات Revolut ، ولكن أيضًا في جميع أنحاء العالم ، يتم استخدامها بواسطة Google و Facebook وما إلى ذلك. أوافق على أن هذا يجب أن يكون انتقالًا سلسًا. وعندما يصبح العديد منهم نقاط بيع أو يذهبون إلى ضمان الجودة الآلي ، يصبح كل شيء ضبابيًا قليلاً ويتطور ويتحول إلى شيء يقال. ومع ذلك ، فإن هذا الاتجاه في روسيا قد بدأ للتو. وكما قلت بحق ، يجب أن يكون بصحة جيدة قدر الإمكان.
نينا سمكينه: كان هناك مثل هذا السؤال. من الذي أجرى اختبارات الوحدة وأين؟ على CI أو محليًا قبل الدفع؟
يوري تشيتكين: يبدو أن القيادة محليًا هي مهمة المطور ، أي أنه لا يجب عليك القيام بذلك بالقوة. من الواضح بالنسبة لي أنه يجب أن يكون هناك 100٪ في CI.
نينا سمكينا: شكراً لجميع المشاركين على المناقشة! أعطي الكلمة لمتحدثناديما مانكو مع تقريره.