مهندس اختبار الحل: من هو ومتى هو مطلوب

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

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

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

وصف موجز للمشروع

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

ما أدوار الاختبار كانت في المشروع؟

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

• 1 قائد اختبار أو اختبار الرصاص
• 40 اختبار يدوي الذين عملوا مع فرق سكروم (7 فرق)
• مطوران (هذا هو بالأحرى استثناء ، لأن المطورين لا يحبون العمل في مهام التشغيل الآلي) و 2 اختبار أتمتة
• 2 اختبار الذين فعلوا اختبار الإجهاد
• 1 اختبار وظيفي لاختبار المنتجات التي تم تطويرها من قبل المطورين واختبار التشغيل الآلي

الاختبار اليدوي

كان الهدف الرئيسي للاختبار الوظيفي هو اختبار التطبيق وتحديد ما إذا كان يفي بمتطلبات العميل. لهذا ، عادة اختبار:

1. إنشاء خطط الاختبار.
2. إنشاء استراتيجية الاختبار.
3. إنشاء حالات اختبار مع الخطوات المجدولة (مع النتيجة المتوقعة والحالية).
4. إجراء حالات الاختبار والاستنتاج بشأن جودة التطبيق.

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

في هذه المرحلة ، بدأت الأسئلة تثار:

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

هذه ليست سوى قمة جبل الجليد لقائمة الأسئلة المتشابهة التي ظهرت في المشروع أثناء الاختبار الوظيفي / اليدوي.

اختبار التشغيل الآلي

كان الهدف من اختبار مهندسي التشغيل الآلي (والمطورين) هو كتابة التطبيقات التي يمكنها اختبار و / أو تسهيل عمل المختبرين الوظيفيين تلقائيًا:

• الاختبارات الذاتية التي سيتم دمجها مع CI / CD ؛
• التطبيقات التي ساعدت في اختبار الاختبارات الوظيفية ؛
• وغيرها من التطورات التي كانت ضرورية لتلبية الاحتياجات الداخلية للمشروع.

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

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

وهذا أبعد ما يكون عن كل المشكلات التي تطرأ على المشروع من حيث التشغيل الآلي للاختبار.

قائد الاختبار ، الملقب اختبار الرصاص

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

إذا كنا نتحدث عن الاختبار التقني لـ Lead ، فكان مسؤولاً عن الحلول التقنية: تنظيم تطوير التطبيقات للاختبار كعملية لإنشاء منتج برمجي منفصل يتوافق مع جميع قواعد التطوير ، على سبيل المثال ، إنشاء اختبارات وحدة ، والتكامل مع عمليات CI / CD و ر. د.

في مشروعنا ، لعبت هذه الأدوار من قبل شخصين ، وكان كل جدول يشبه هذا:


في كلتا الحالتين ، ينشغل Test Lead بالعمل على استراتيجية الاختبار التي تم اختيارها بالفعل ، ولكن لا يوجد أحد مسؤول عن اختيار الاستراتيجية نفسها ، وتبرير هذا الخيار للعميل ، وتكييفها مع التغييرات وغيرها من المشكلات. على سبيل المثال:

1. وضع خطة مع العميل للدخول في مرحلة اختبار القبول من قبل العميل (UAT).
2. دراسة المتطلبات مع العميل عند اعتبار إمكانية نقل الوظيفة إلى UAT.
3. ادرس مع عميل افتراضات الاختبار على أنواع مختلفة من البيئات (نقطة حساسة للغاية). نظرًا لأن بيئة الاختبار عادةً لا تتوافق مع الإنتاج ، يجب وضع جميع الأسئلة المتعلقة بالاختبار في بيئة أخرى مع العميل.
4. ادرس مع العميل وجود تباين مقبول في المقاييس في أنواع مختلفة من الاختبارات. على سبيل المثال ، ما النتيجة التي يتوقع العميل رؤيتها أثناء اختبار الأداء؟ ربما سيكون كافيا بالنسبة له أن النظام لا يعمل أسوأ.
5. لا يجوز جمع أكثر من 10 في المائة من المقاييس الممكنة بالأرقام ، على سبيل المثال ، فإن تباينات البيانات في هذا الجدول ، أو يجب ألا يعمل البرنامج النصي أكثر من ثماني ساعات.

ما هو الخطأ هنا؟

عادة ما يتم وضع الأسئلة أعلاه على أكتاف اختبار الرصاص ، ولكن هناك نهج معيب:

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

وهذه ليست كل المشاكل التي تقع على "اختبار الرصاص" عند عدم وجود TSA.

فمن هو هذا TSA ولماذا هو مطلوب؟

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

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

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

عندما لا تكون هناك حاجة TSA؟

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

النوع الأول من المشروع - يقدم العميل إعداد عمليات الاختبار وفقًا لتقدير الشركة التي استأجرها.

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

النوع الثاني من المشروع - العميل لديه فهمه الخاص للاختبار ، صورة واضحة وعمليات مبسطة.

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

النوع الثالث من المشروع - العميل لا يحتاج إلى خدمات TSA.

قد تكون الأسباب مختلفة:

1. مشروع صغير وقصير الأجل مع وظائف بسيطة.
2. العميل لديه TSA الخاصة به.
3. رفض العميل الاختبار ، إلخ.

مهارات TSA

تم تطبيق تطبيق Solution Engineer بنجاح لفترة طويلة جدًا. بناءً على هذه التجربة الناجحة ، ومع الأخذ في الاعتبار حجم وتعقيد المشروعات ، وهي القضايا التي تتجاوز مجال مسؤولية اختبار القيادة ، يمكننا القول أن تخصيص دور TSA هو تطور طبيعي للأحداث. علاوة على ذلك ، يجب تدريب TSA على نفس العمليات والتقنيات والمناهج مثل SA.

باختصار ، في رأيي ، يجب أن يكون لدى TSA:

1. من خلال المعرفة التقنية ، بشكل عام وفي مجال المجال الذي يعمل فيه ، لمعرفة مشاكل هذا المجال ، والأخطاء النموذجية ، والمشاكل وطرق التحقق منها.
2. مهارات الاتصال الجيدة ، تكون قادرة على لفت انتباه العملاء إلى قضايا الاختبار ، والعمل على متطلبات الاختبار ، وطرق الاختبار ، والإبلاغ عن الاختبار والعديد من القضايا ذات الصلة ، مثل بيئة الاختبار.
3. مهارات القيادة وتكون استباقية ل الاختبار في كثير من الأحيان محاولة لمغادرة في وقت لاحق.
4. معرفة جيدة للاختبار بشكل عام ، وثائق الاختبار ، عمليات الاختبار ، اختبار التقارير ، النهج ، وما إلى ذلك ؛
5. معرفة جيدة بقواعد تطوير البرمجيات: سياسات النشر ، سياسات الإصدار ، فهم عمليات CI / CD ، إلخ.

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

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

استنتاج

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