Get best of the week

هل تفكر الاختبارات الذاتية في الأخطاء الكهربائية

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

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

حاولت في هذه المقالة:

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

مصدر 

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

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

في الواقع ، بهذه الأفكار ، ذهبت لتقديم عرض تقديمي حول "Strike-2019" ثم كتبت هذا المنشور بناءً عليه.

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

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

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

انضغاط صغير. طرق الأتمتة


هناك طريقتان رئيسيتان لأتمتة اختبار واجهة المستخدم. 

مصدر

الأتمتة بواسطة المختبرين اليدويين


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

أسلوب التصميم


وهناك نهج ثانٍ: يتم تعيين فريق من المختبرين التلقائيين - من ذوي الخبرة والمعرفة والمهارات في OOP ، ويتم تنفيذ الأتمتة مباشرة من قبل قوى هذا الفريق ، ويعمل فريق من المختبرين اليدويين كعملاء وخبراء. نعم ، يمكن أن يتدفقوا إلى فريق الأتمتة بعد التدريب والاختيار ، لكنهم لا يجمعون بين دورين في نفس الوقت.

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

ميزات الأتمتة "بمفردها"


المصدر

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

2) لا مواعيد نهائية. من ناحية ، هذا جيد: لا أحد يشجع الفريق ، "دعونا بسرعة أتمتة كل شيء ، دعنا نتعلم بسرعة" ، لا ينمو التوتر في الشخص. وهو يواصل الاختبار بيديه ويغرق بهدوء في الأتمتة. من ناحية أخرى ، لا توجد مواعيد نهائية ، لا يمكننا أن نسأل عن النتائج ، ولا نفهم متى ستكون جاهزة.

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

ملامح نهج المشروع


المصدر

1) في هذه الحالة ، نحن نتحدث بالفعل عن المشروع. والمشروع ماذا؟ هذه هي الموارد والوقت والمال. وبناءً عليه ، يتم حساب الميزانية هنا ، مع مراعاة جميع الفروق الدقيقة الموجودة في هذا المشروع. يتم حساب جميع المخاطر ، يتم حساب جميع الأعمال الإضافية. وفقط بعد الموافقة على الميزانية ، يتم اتخاذ قرار بالبدء.

2) بناءً على ذلك ، من المرجح أن تكون مرحلة التحضير غير سريعة ، حيث يجب بناء حساب الميزانية لشيء ما.

3) بطبيعة الحال ، يتم زيادة الطلبات على هؤلاء المتخصصين الذين سيشاركون في المشروع. 

4) هنا سأكتب أيضًا حلول البنية التحتية المعقدة ، ولكن المزيد عن ذلك لاحقًا. 

5) تحديث الاختبارات الحالية وعمليات التحرير. لأن الاختبارات الذاتية هي عنصر جديد في الفريق. إذا لم يتم توفيرها مسبقًا ، على التوالي ، فأنت بحاجة إلى دمجها في العملية. لا يجب أن يعلق المختبرون التلقائيون على الجانب الأيمن ، الأيسر ، من المشروع.

6) يعطي منهج المشروع انتظامًا واتساقًا ، على الرغم من أنه من ناحية أخرى ، يمكن أن يكون تنفيذه أبطأ من تنفيذ النهج الأول.

7) حسنًا ، الإبلاغ. الكثير من التقارير. لأنه لأي ميزانية سوف يطلب منك. وفقًا لذلك ، يجب أن تفهم كيف تعمل الاختبارات الذاتية (سيئة ، جيدة) ، ما هي الاتجاهات ، وما هي الاتجاهات ، وما الذي يجب زيادته ، وما الذي يجب تحسينه. يتم التحكم في ذلك عن طريق إعداد التقارير.

طريق طويل إلى مستقبل أكثر إشراقا


تنويه: كنا أذكياء على الفور (في الواقع ليس كذلك).

المصدر

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

مصدر

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

طرق مختلفة للتشغيل الآلي


مصدر 

عدد مرات التعذيب


المحاولة الأولى التي أجريناها كانت وفقًا للنموذج الأول (انظر الطريقة رقم 1). قررت مجموعة صغيرة (ولكن فخور) من مجموعة المختبرين تجربة الأتمتة. بشكل عام ، أردنا أن ننظر إلى ما نتج عن كل ذلك. الآن ، بالطبع ، لن نفعل ذلك ، ولكن بعد ذلك لم تكن هناك خبرة ، وقررنا تجربته. 

المصدر

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

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

المحاولة الثانية


مصدر 

يومئ شيء مثل شطيرة للعض.

بعد فترة ، عدنا مرة أخرى إلى موضوع الأتمتة.

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

"نريد أتمتة هذا!"
- ربما سنفكر في الأمر.
- لا ، لا نريد أن نفكر بأي شيء ، نريد هذه الاختبارات الذاتية.

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

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

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

المحاولة الثالثة


المصدر 

للمحاولة الثالثة ، اقتربنا ، مثل ظبية خجولة إلى حفرة سقي. 

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

كانت المدمة بالفعل تكذب وتنتظرنا.

ضعف الغمر في الأتمتة الوظيفية


المصدر 

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

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

هيكل حالة الاختبار غير الأمثل


المصدر 

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

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

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

وثائق الإطار


المصدر

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

مشاكل الاتصال


المصدر  

1. عدم وجود لوائح بشأن التفاعل.

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

2. وجود لوائح للتفاعل

ثم تم كتابة اللوائح ، لكن الرجال عملوا لبعض الوقت دون بعضهم البعض ، وعندما تم كتابة اللوائح ، أخذوا ذلك كأداة للتفاعل. تم تجاهل كل ما تجاوز ذلك. 

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

شراء تراخيص البرامج المتخصصة في الوقت المناسب


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

خريطة الطريق


Istonik 

وبناءً عليه ، لدينا الآن خارطة طريق ، وكيفية إطلاق مثل هذه المشاريع ، وهي تتكون في الواقع من مراحل ، وتنقسم كل مرحلة إلى نقاط معينة.

المرحلة الأولية


مصدر 

نحتاج لقيادة فريق


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

يجب أن يكون هناك مجموعة تركيز


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

تقييم حالة أساس حالة الاختبار


لقد تحدثت بالفعل عن تقييم حالة قاعدة حالة الاختبار أعلاه ، على التوالي ، ويتم ذلك أيضًا في المرحلة الأولية للغاية.

نكتشف ما لا يخضع للأتمتة


غالبًا ما تكون هناك رغبة في أتمتة كل شيء يتحرك (وكل ما لا يتحرك ، يتحرك وأتمتة) ، في الواقع ، حوالي 40 ٪ من حالات الاختبار عادة ما تكون مكلفة للغاية لتنفيذها من حيث المبدأ لن تؤتي ثمارها أبدًا. لذلك ، هنا تحتاج إلى أن تكون واضحًا جدًا بشأن ما تريده: لأتمتة كل شيء والتحليق في الأنبوب ، أو تريد أتمتة جزء معين من الاختبار الوظيفي الذي سيساعدك.

تقييم مشروع تجريبي


نقوم بتقييم المشروع التجريبي في المرحلة الأولية (كم سيكلف) وننفذه في الحالات الأكثر صعوبة (ملاحظة).

طيار


مصدر 

تطبيع حالات الاختبار


تخضع مجموعة الحالات المجمعة للتطبيع. يتم التخلص من الغموض والشروط المسبقة غير الضرورية. 

إعداد الإطار


نكتب إطار عملنا ، أو نضيف الإطار الحالي أو نستخدم نوعًا من الإطار الذي تم شراؤه.

بنية تحتية


نحن نعد حلول البنية التحتية.

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

المجاميع الفرعية والتسويات


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

تلخيص الطيار


نلخص ونكتب تقريرًا ونتخذ قرارًا بشأن ما إذا كنا سنذهب إلى التشغيل الآلي أم لا.

لقد كتبت في وقت سابق أنه يمكن أن يحدث أننا لا نذهب. أي ، على سبيل المثال ، إذا كان الاسترداد 18 عامًا ، ومدة مشروعك 5 سنوات ، يجب أن تفكر في سبب حاجتك إليه.

مرحلة الإطلاق


 

يتم سرد عناصر المصدر بالتسلسل ، ولكن في الواقع يجب أن يتم كل ذلك بالتوازي.

  • نبدأ اختيار الفريق.
  • نحدد العملاء المحتملين.
  • دعونا نعطي الأولوية لدراسات الحالة.
  • نقوم بتطبيع حالات الاختبار.
  • نحل "صعوبات البنية التحتية".
  • نكتب اللوائح والتعليمات ، وننشئ اتصالات ، ونزيل الاختناقات.
  • نقوم بتحسين إطار العمل المتزامن للعديد من الاختبارات الذاتية والتوازي مع مجموعات الاختبارات الجارية.
  • نقوم بعمل وحدة إعداد التقارير والإحصائيات (لمرة واحدة وتراكمية).
  • نبدأ كتابة الاختبارات الذاتية.

المنصة الرئيسية


المصدر 

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

مرافقة المرحلة


المصدر 

تختلف مرحلة المرافقة قليلاً عن المرحلة الرئيسية. فرق كبير في مدته. بالإضافة إلى ذلك ، لديها نسبة أقل بكثير من الاختبارات الذاتية الجديدة التي يتم تطويرها. وفقًا لتقديراتنا ، 6-10 ٪ لكل إصدار ، وإلا فهي مشابهة جدًا للمرحلة الرئيسية.

ما هي النتيجة؟


قمنا بأتمتة حوالي 1500 حالة من البداية إلى النهاية. يحمل استقرار عمليات الإطلاق الناجحة العديد من الإصدارات عند حوالي 92-95٪.

انخفضت تكاليف اللجوء بنحو 2.5 مرة. تجري الجري نفسها في غضون 3-4 ساعات ، ويتم ذلك في الليل ، بحيث يكون في الصباح نتائج جاهزة.

تفاصيل التنفيذ الفني مبينة في سلسلة من المقالات من قبل زملائي:


إذا بدأنا الآن ، مع مراعاة كل ما كتبت عنه ، أعتقد أننا سنوفر أعصابنا ووقتنا وميزانيتنا بشكل كبير.

شكرا للانتباه. طرح الأسئلة ، سنناقش. 

مصدر 

وننتظر أيضًا فريقنا من المختبرين الشباب!
, , .

More articles:


All Articles