من النادر أن تجد مشروعًا تحبه أثناء المقابلة وتفخر به عندما يغزو أسواقًا جديدة. إنه لأمر ممتع أكثر عندما تكون الكفاءة المهنية للزملاء في أفضل حالاتهم ، وفي فريقك تشعر وكأنك مع عائلتك. كنت محظوظًا ليس فقط لأنني وجدت مثل هذا المشروع ، ولكن أيضًا منذ بعض الوقت بدأت في التأثير على عملية الاختبار فيه. سأخبرك بما يتضمنه فهمنا للعملية المثلى ؛ كيف توصلنا إلى الإصدارات الشهرية وكيف تعمل لدينا ؛ وكيف تكيفنا مع ظروف الحجر الصحي.
مشروعنا هو نظام التعلم عن بعد (LMS ، نظام إدارة التعلم) ، والذي يستخدمه أكثر من 7 ملايين شخص في مختلف دول العالم. يحتوي النظام على أكثر من 1000 صفحة ويب وحوالي 10000 حالة اختبار.
يعمل في المشروع الآن حوالي 15 فريق تطوير - من جانب العميل في النرويج ومن جانب Arcadia في روسيا. انضممت إلى المشروع منذ 8 سنوات بصفتي مسؤول ضمان الجودة ؛ على مدار العامين الماضيين ، كنت أعمل كقائد لضمان الجودة ، وشاركت في تحسين عملية الاختبار.
ما هو مدرج في مفهوم العملية المثلى
مهمتنا الرئيسية هي تلبية احتياجات المستخدمين النهائيين ، والتي تشمل إنشاء وظائف جديدة ودعم النظام. يتم إيلاء اهتمام خاص لسرعة النظام واستقرار العمل في ظل ظروف الحمل الثقيل.
يجب أن تسمح عملية التطوير في المقام الأول بتحقيق أهداف العمل بشكل مستدام ، مثل إنجاز العمل في الوقت المحدد وبمستوى متفق عليه من الجودة. ولكن يجب أن تكون العملية مريحة أيضًا لفريق التطوير ، بحيث يشعر كل من يشارك في العملية بالرضا. لقد أنشأنا في فرقنا عملية مثالية لنا ، وإليك الوسائل التي يتم من خلالها تحقيق ذلك.
عملية التطوير بشكل عام:
أ) نهج التطوير الذي يلبي احتياجات الفريق.
نعمل باستخدام سكرم وسباق السرعة لمدة 3 أسابيع. قبل السباق ، يتم تقديم عرض لأهدافه ويتم تشكيل مجموعة من المتطلبات لهذا العدو. يأتي بعد ذلك التخطيط ، حيث نقوم بتقييم جميع المهام وتحديد مجموعة المهام التي سيتم تضمينها في العدو. في نهاية السباق ، يتم إجراء مراجعة Sprint ، حيث نعرض جميع المهام المكتملة ونعلن عن الأهداف التي تم تحقيقها. هذا النهج هو الأمثل بالنسبة لنا: خلال السباق ، نتمكن من إنشاء قدر كافٍ من الوظائف الجديدة وفي نفس الوقت إصلاح واختبار عدد معين من الأخطاء من المستخدمين النهائيين - يتم تخصيص 10 ٪ من وقت الركض لمثل هذه الأخطاء.
اصطفوا: قائد الفريق ، المطورين ، المختبرين. نسبة المطورين إلى المختبرين في فرقنا هي 3: 1. تتيح هذه النسبة تحقيق هدف العدو بشكل متساوٍ - لا توجد فترات يكون فيها أحد المشاركين في العملية خاملاً: بينما يقوم المطورون بإجراء أي تغيير ، يقوم المختبرين بإنشاء أو تحديث حالات الاختبار المتعلقة بهذا التغيير ؛ عند اكتمال التطوير ، يتحقق المختبرين من التغييرات ، وينتقل المطورون إلى المهام التالية في السباق أو يساعدون في الاختبار (هذا ضروري عند اختبار التغييرات واسعة النطاق).
يضع مالك المنتج الأهداف والمتطلبات في بداية كل سباق ويقبلها في النهاية. أيضًا ، كل فريق لديه Scrum Master للمساعدة في حل المشكلات الناشئة.
لكي تتاح للفريق الفرصة للقيام بأنشطة مختلفة لا تتعلق مباشرة بمهام العدو ، وكذلك مراعاة المخاطر المختلفة ، فإن الوقت المحسوب لإكمال مهام العدو هو 80٪ من إجمالي وقت العمل للفريق. أي ، يتم تخصيص ساعتين يوميًا خلال العدو العادي للاتصالات والاجتماعات والندوات المختلفة ، بالإضافة إلى إصلاح الأخطاء الموجودة في العدو.
ب) متطلبات واضحة والتخطيط الجيد
حتى لا يستمر التخطيط ولا يصبح العدو فاشلاً بسبب التفاصيل غير المعروفة سابقًا والتغييرات الإضافية الشاقة التي تمت إضافتها بالفعل أثناء العدو ، نحاول أن نأخذ في السباق التغييرات فقط بمتطلبات واضحة ودقيقة بشكل كاف. إذا كانت منطقة المشروع التي تتعلق بالتغييرات غير معروفة للفريق ، أو أثناء التخطيط ظهرت العديد من الأسئلة التي يتعذر على مالك المنتج الإجابة عليها ، فيمكن للفريق تنفيذ مهمة لدراسة هذا المجال أو مهمة بحث ، مما يؤدي إلى متطلبات واضحة أو نوع من النموذج الأولي.
ج) استعادية
تصحيح الخلل مهم أيضا. هذا ينطبق على كل من سباقات السرعة والإصدارات. يحدث أنه ليس لدينا وقت لشيء ما ، أو يتعين علينا العمل ساعات إضافية لنكون في الوقت المحدد - على سبيل المثال ، إذا كان من الضروري إجراء اختبار مسبق للإصدار (وهذه تكاليف إضافية تود الشركة تجنبها في المستقبل). لذلك ، نجري استطلاعات للماضي حيث نناقش ما كان جيدًا وسيئًا في العدو أو الإطلاق ، ونضع تدابير لتجنب مثل هذه الأخطاء في المستقبل.
د) دعم الإدارة
في بعض الأحيان تظهر أسئلة أو مواقف لا يمكن حلها على مستوى الفريق - تحتاج إلى تغيير العملية أو إشراك إدارة الشركة في القرار. من المهم جدًا أن ترى أنهم يريدون مساعدتك ومستعدون لدعمك في مثل هذه الحالة. في شركتنا ، كل شيء على ما يرام مع هذا - وهذا ينطبق على كل من Arcadia والإدارة من جانب العميل. تتم مناقشة جميع القضايا ويتم دائمًا إيجاد حل يرضي جميع الأطراف.
هـ) وفي رأيي ، الأساسي هو التواصل الجيد. وما لدينا في الشركة ، بالنسبة لي ، هو أحد المزايا الرئيسية للعمل المريح - الإحسان ، والرغبة في التسوية.
ينطبق هذا على الجميع: كل عضو في الفريق ، ومالك المنتج ، و Scrum Master ، وإدارة الشركة ، والعديد من المشاركين الآخرين في العملية. الجميع منفتح على الأسئلة والمناقشات ، والمطورين يتشاورون مع المختبرين بشأن المتطلبات ويقررون معًا أفضل السبل (من وجهة نظر التطوير ومن وجهة نظر الاختبار) لإجراء هذا التغيير أو ذاك. مالك المنتج ، بدوره ، على اتصال دائم بالفريق ، ويحل جميع المشكلات بسرعة ويحاول دائمًا الاجتماع في منتصف الطريق في تحقيق أهداف العدو. إن Scrum Master جاهز دائمًا للمساعدة: ابحث عن موارد إضافية (مختبرين / مطورين إذا كانت مطلوبة للعدو السريع أو للإصدار) أو اقترح أفضل السبل لتنظيم العدو في الوقت المناسب.
عملية الاختبار:
أ) معايير ضمان الجودة (المبادئ التوجيهية) المتعلقة بكتابة حالات الاختبار.
في مشروعنا ، تعد حالات الاختبار هي التوثيق التفصيلي الرئيسي لوظيفة النظام ، لذا نوليها الكثير من الاهتمام. لكل تغيير يقوم به الفريق ، تتم كتابة حالة اختبار جديدة أو تحديث حالة اختبار موجودة.
في السابق ، عندما لم يكن النظام ضخمًا بعد ، تمت كتابة حالات الاختبار بالتفصيل تمامًا ، مع خطوات محددة مختلفة ، ولكن الآن أصبح هذا النهج غير مقبول - يستغرق الأمر وقتًا طويلاً لتحديث حالات الاختبار هذه. لذلك ، قمنا (خبراء ضمان الجودة) بتطوير معايير ، والمتطلب الرئيسي منها هو كتابة نصوص اختبار بالنتائج المتوقعة بدلاً من الخطوات التفصيلية في حالات الاختبار.
ب) معايير ضمان الجودة المتعلقة بالاختبار في سباقات السرعة.
تم تطوير معايير اختبار Sprint لضمان قيام كل فريق بإجراء تغييرات جيدة على الجودة.
تعتمد هذه المعايير على أقصى تغطية للاختبار ، والتي تشمل:
- اختبار التغييرات التي أجراها الفريق مباشرة (الوظيفة ، وإذا لزم الأمر ، واجهة المستخدم) ؛
- اختبار النظام بعد هذا التغيير باستخدام قائمة تحقق: هذه فحوصات إلزامية ، والتي تشمل اختبار إمكانية الوصول للأشخاص ذوي الإعاقة ، والتحقق من الترجمات ، والتحقق من البيانات الموجودة ، والاختبار باستخدام أحرف خاصة ، وفحوصات الأمان ، واختبار التغييرات في تطبيق الهاتف المحمول ، وفحوصات أخرى ...
ج) معايير ضمان الجودة المتعلقة باختبار الإطلاق.
تتم مناقشة عملية الإصدار والمعايير المستخدمة فيها بمزيد من التفصيل أدناه.
د) استخدام اختبار الانحدار الآلي.
لقد أدى إنشاء الاختبارات الآلية لاختبار الانحدار إلى تبسيط حياة الفرق إلى حد كبير - الآن ، إذا كنت بحاجة إلى التحقق من بعض المناطق بعد تغييرات الأمر ، يمكنك ببساطة إجراء اختبارات الانحدار التلقائية للمنطقة المطلوبة من النظام (إذا كانت هذه المنطقة مغطاة بالاختبارات التلقائية). أيضًا ، إذا تم كسر جزء من النظام من خلال تغييرات الفريق ، فستكشف الاختبارات التلقائية للارتداد ذلك.
هـ) المساعدة المتبادلة للمختبرين ، مساعدة المطورين.
ليس لدينا عدد كبير جدًا من المختبرين (في المتوسط ، مُختبِر واحد لثلاثة مطورين) ، بالإضافة إلى ذلك ، من وقت لآخر يصرفون انتباههم عن مهام العدو لاختبار الإصدارات ، وقد لا يكون هناك وقت كافٍ لكل شيء.
في هذه الحالة ، هناك دائمًا شخص من مختبري الفرق الأخرى لديه عبء عمل أقل في الوقت الحالي يمكنه المساعدة. يساعد قائد QA أو Scrum Master في العثور على مثل هذا الاختبار. بالإضافة إلى ذلك ، يمكن للمطورين المساعدة في اختبار التغييرات في العدو إذا تم بالفعل كتابة حالات الاختبار لهم.
و) التواصل بين المختبرين.
للتواصل ، يتم استخدام الدردشة في Microsoft Teams ، حيث يمكن للجميع طرح الأسئلة وتلقي الإجابات على الفور ، بينما سيكتشف باقي المختبرين أحدث المعلومات. نعقد أيضًا اجتماعات شهرية لضمان الجودة ، حيث يشارك المختبرين مع بعضهم البعض المهام الحالية لفريقهم ويمكنهم مناقشة أي مشكلات - نهج الاختبار و / أو موقع حالات الاختبار المتعلقة بمنطقة غير مألوفة للمختبر ؛ أسئلة حول الإصدار (تكوين فريق الإصدار المستقبلي ، تغيير الجدول الزمني للاختبار) ؛ تمت إضافة فحوصات إلزامية إضافية بعد فقد خطأ فادح في الإصدار ، وما إلى ذلك).
تتيح لك الأساليب المذكورة أعلاه ضمان اختبار جودة جيد في وضع التشغيل الهادئ.
:
اعتدنا أن يكون لدينا إصدارات ربع سنوية . مع هذا الإطار الزمني ، كان هناك الكثير من التغييرات التي أجرتها الفرق لكل إصدار. يتطلب هذا القدر من التغيير بالتأكيد انحدارًا قبل الإصدار ، لذلك كان هناك إطار زمني منفصل للانحدار وكانت جميع الفرق مرتبطة به. استغرق هذا عادةً حوالي أسبوعين ، وشارك كل من المختبرين ومطوري الفريق في الانحدار.
بعد مرور بعض الوقت ، بدأ استخدام الاختبارات التلقائية للتراجع في عملية اختبار الإصدار. لم تتم تغطية جميع اختبارات الانحدار بالاختبارات التلقائية ، فقد تم اختبار بعضها يدويًا. بشكل عام ، أدى ذلك إلى تقليل وقت اختبار الانحدار ، ولكن نظرًا لحجم النظام ، كان الانحدار الكامل يستغرق وقتًا طويلاً.
بدت دورة التطوير بأكملها كما يلي:
أصبح من الواضح أن هذا النهج في الإصدارات ليس هو الأمثل ، وهو كثيف العمالة بشكل مفرط ، ولا يسمح بالرضا السريع والمرن لطلبات المستخدم النهائي. تطلب نهج عملية الإصدار تغييرات ، وتقرر الإصدار أكثر من مرة - مرة واحدة في الشهر.
عندما انتقلنا إلى الإصدارات الشهرية ، أصبح من الواضح أنه لم يكن هناك وقت لإجراء الانحدار أثناء مرحلة اختبار الإصدار - حتى مع اختبارات الانحدار المؤتمتة جزئيًا. الآن تستغرق فترة التحضير الإجمالية للإصدار أسبوعين فقط. لذلك ، يتم الآن الانحدار في سباقات السرعة وفقط عند الضرورة (إذا أبلغ المطورون أن تراجع جزء معين من النظام مطلوب).
ولكن نظرًا لأنه في مرحلة اختبار الإصدار ، من الضروري التحقق ليس فقط من الوظيفة الجديدة ، ولكن أيضًا من الحالة العامة للنظام ، فقد بدأنا في استخدام التثبيت بدلاً من الانحدار.
يتضمن التثبيت:
أ) اختبار الوظائف الجديدة المضمنة في هذا الإصدار من قبل كل فريق ؛
ب) اختبار المجالات الحرجة هو اختبار للوظائف الأساسية للمجالات الرئيسية للنظام (والتي من الواضح أنها تستغرق وقتًا أقل بكثير من دورة الانحدار الكاملة) ؛
ج) اختبار الأخطاء الموجودة في تغييرات الفريق لهذا الإصدار.
تبدو دورة التطوير بأكملها الآن
على النحو التالي : لنفكر في الأمور الأخرى اللازمة للتحضير للإصدار.
عند اكتمال التثبيت وحزمة الإصدار بجودة جيدة ، قبل طرحها في الإنتاج ، يتم اختبار التكوين في بيئة ما قبل الإنتاج. وبالتالي ، تمارس العمليات تحديث البيئة ، ويقوم المختبرين بفحص التكوين باستخدام حزمة الإصدار الحالية قبل الإصدار الحقيقي.
قد تعتقد أن أسبوعين من التحضير للإصدار أكثر من اللازم ، ولم يتبق سوى القليل من الوقت للاختبار في العدو. ولكن عادة ما يستغرق المختبِر 4-6 أيام للتحضير للإفراج. ان ذلك يعتمد على:
- تعقيد ونطاق الوظائف التي سيطلقها فريقه ،
- مشاركة المختبرين في فريق تحرير الإصدار الحالي.
يشارك جميع مختبري المشروع (بما في ذلك فريق الإصدار) في اختبار التثبيت ؛ يتم اختبار التكوين والإصدار نفسه بواسطة فريق الإصدار فقط.
يبدو الجدول العام لاختبار الإصدار على النحو التالي:
نظرًا لأن المناطق الحرجة والتكوين يحتويان على اختبارات ثابتة ، فقد قمنا بأتمتة حالات الاختبار هذه جزئيًا. أدى هذا إلى تقليل وقت الاختبار بشكل كبير استعدادًا للإصدار ، لذلك نخطط في المستقبل لتوسيع استخدام الاختبارات التلقائية.
من وجهة نظر تنظيم الاختبار ، يتم اختيار منسق ضمان الجودة (شخص من عملاء ضمان الجودة) لكل إصدار. عادةً ما يتم التخطيط لمهلة الإصدار لمنسق ضمان الجودة أكثر من المختبرين العاديين ، نظرًا لأن منسق ضمان الجودة لديه المزيد من المسؤوليات. وتشمل هذه:
- تحديد فريق التحرير والتحقق من توافر جميع أعضائه وقت الإصدار ؛
- إعداد خطط الاختبار للإفراج ؛
- إطلاق الاختبارات التلقائية في مرحلة التثبيت واختبار التكوين ؛
- تنسيق عمل المختبرين أثناء اختبار الإطلاق ؛
- مساعدة المختبرين في حل جميع أنواع المشكلات المتعلقة بالإصدار ؛
- التحكم في تنفيذ الاختبار ، وإذا لزم الأمر ، إعادة توزيع الحمولة للمساعدة في اختبار الفرق المثقلة بالأعباء (يمكن أن يكونوا إما مختبرين للفرق الأخرى التي أكملت بالفعل اختبار الإصدار ، أو مطوري الفريق ، أو منسق ضمان الجودة نفسه).
وبالطبع ، لا يكتمل أي إصدار بدون مشاكل. نحلها ونضع خطة حول كيفية تجنبها في المستقبل. في ما يلي القليل الذي رأيناه مؤخرًا:
- : , - , , - .
: . - : pre-production . — .
: . - : , .
:
a) - ( , ),
b) ,
c) ,
d) , . , , .
الحل: في مثل هذه الحالات ، نحاول إتاحة الوقت لاختبار كل ما هو ضروري للإصدار ، حتى لو تطلب الأمر المشاركة في الإصدار لمدة أسبوعين أو العمل الإضافي ، نظرًا لأن الإصدار مهمة ذات أولوية أعلى من مهام العدو السريع.
ولكن بغض النظر عن المشكلات التي تنشأ ، يمكننا دائمًا حلها بواسطة قوى فريق التحرير أو من خلال إشراك الأشخاص الأكفاء في منطقة معينة - الشيء الرئيسي هو أن هذا دائمًا عمل جماعي جيد التنسيق يؤدي إلى نتيجة جيدة.
العمل في الحجر الصحي: كيفية ضمان عمل المختبرين
في مشروعنا ، العمل من المكتب هو شرط أساسي. يتم ذلك حتى يمكن العثور على أي مشارك في العملية أثناء ساعات العمل - إذا لم يرد فجأة في المحادثات ، فيمكن للأشخاص الذين يعملون معه إبلاغه بحاجته إلى بعض زملائه. هذا مهم لأن بعض الفرق موجودة في النرويج والبعض الآخر في سان بطرسبرج.
أثناء الوباء ، عندما أرسلت كل من النرويج وروسيا غالبية السكان إلى العزلة الذاتية ، كان علينا التحول إلى العمل عن بعد.
واصلنا العمل كالمعتاد: لا تزال الفرق تنهي سباقات السرعة بإنتاجية جيدة ، وتم إصدار الإصدارات في الوقت المحدد.
ظلت الاتصالات على مستوى جيد - غطى تطبيق Teams جميع الاحتياجات: كانت هناك محادثات نشطة في الدردشة ، وعقدت الاجتماعات دون مشاكل ؛ إذا كانت هناك أي أسئلة تحتاج إلى مناقشتها بشكل عاجل ، فقد قاموا باستدعاء أي مشارك في المشروع.
من وجهة نظر تنظيم الاختبار ، لم تكن هناك مشاكل: خلال ساعات العمل ، أجاب جميع المختبرين في الدردشات وشاركوا على الفور في اختبار الإصدار. في حال أردنا العثور على شخص ما ، لكنه لم يرد في الدردشة ، فقد أعددنا قائمة بأرقام الهواتف المحمولة ، لكننا لم نضطر أبدًا إلى استخدامها.
المشكلة الوحيدة التي واجهناها أثناء جلوسنا في المنزل في عمل عن بُعد - نظرًا لخصائص VPN ، كان من المستحيل اختبار النظام في بيئة جماعية من الهواتف / الأجهزة اللوحية. ولكن تم التحايل على هذه المشكلة - بفضل مدير المشروع وخدمة تكنولوجيا المعلومات ، الذين وجدوا حلاً. بدأنا في استخدام الوكلاء عند الاتصال عبر شبكة منزلية ، والآن يمكننا الاختبار على الأجهزة المحمولة من المنزل.
الآن نعود جزئيًا إلى العمل في المكتب ، لكن جزءًا من الشركة يواصل العمل من المنزل. وحتى في أجزاء مختلفة من المدينة ، ما زلنا شركة واحدة متماسكة تواصل العمل في مثل هذه الأوقات الصعبة ، في ظل ظروف غير عمل كهذه ، عندما يطلب الأطفال والحيوانات الأليفة الاهتمام ، يتباطأ الإنترنت ويختفي بشكل دوري ، وتنطفئ الأنوار ، وهناك الكثير من الانحرافات. عوامل لم تفهمها إطلاقا كيف استطعت العمل من جديد؟!
لكننا سننجو معًا من كل هذا ، وأخيراً ، بعد أن عدنا إلى حياة مكتبية كاملة ، سنبتسم لبعضنا البعض على نطاق أوسع من المعتاد.
خاتمة
تلخيصًا لما ورد أعلاه ، أود أن أشير إلى بعض النقاط:
- , , . — .
- , , .
- , , , — . , .