كيف يمكنك دمج اختبار النظام في عملية رشيقة؟[مغلق]

Question

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

Answer 1

ما الذي يمنعك من إجراء العملية الخاصة بك؟إذا وجدت شيئا يمكن أن يكون أفضل.افعل ذلك.فإذا نجحت فثابر عليها..إن لم يكن حاول شيئا آخر.لا توجد عملية ثابتة إذا كنت تريد خفة الحركة.
المصطلح الأكثر استخدامًا هو "قابل للشحن"الكود في نهاية كل تكرار.مما يعني أنه يمكنك منحها للمستخدم النهائي (كمجموعة من ملفات DLL لنسخ مشاركة أو تسليم قرص مضغوط/قرص DVD شخصيًا) وسيحصل على قيمة من استخدامه.مثل هذا الرمز اجتاز جميع اختبارات الوحدة (المطورين) واختبارات القبول (العملاء/ضمان الجودة/المحللين) التي اعتبرت ضرورية حتى يتم "القيام بها!" اختبارات القبول هي محاكاة سيناريو العميل من طرف إلى طرف.

لست متأكدًا مما تقصده بـ "مزيد من الاختبار والتحقق من الصحة".يمكنني التفكير في أنشطة "ما قبل الإصدار" الأخرى

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

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

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

Answer 2

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

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

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

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

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

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

Answer 3

الاختبار الآلي بعد كل بناء آلي يوصلك إلى جزء من الطريق على الأقل.

Answer 4

أضف اختبار النظام إلى تراكم Sprint الخاص بك (في Scrum) أو ما يعادله.

كما سبق وثائق المستخدم.

Answer 5

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

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