هكذا. في عام 2018 ، في Heisenbug (مؤتمر موسكو للاختبارات) ، قدم Baruch Sadogursky (مطور محامي في JFrog) كلمة رئيسية مثيرة للاهتمام ، تحدث فيها عن أفكاره الأساسية حول إلى أين يذهبون. في عام 2019 ، في نفس Heisenbug ، تم وضع تكملة لتقريره على HOW للذهاب لتحقيق هذا الهدف. من ناحية ، أود أن أؤيد نسخة حركة B. Sadogursky ، التي بثها ، لكن أولاً ما زلت لا أعرفها ، وثانيًا ، سأجرؤ على صياغة رؤيتي ووصف مساري الشخصي استنادًا إلى تجربتي الخاصة.
دانو
بالنسبة للسياق (إنه وهمي وأي مصادفة مع حالات حقيقية هي مصادفة بحتة) ، فسوف نقدم لبعض شركات تكنولوجيا المعلومات الإقليمية وحدة تطوير كبيرة إلى حد ما. توجد داخل هذه الوحدة وظيفة اختبار ، تتكون من 30 شخصًا مشروطًا من مختلف مستويات المعرفة والمهارات.
شركة
لدى الشركة المقدمة العديد من المنتجات التي تم إصدارها منذ فترة طويلة وتم الانتهاء من المرحلة الأولى من التطوير منذ أكثر من 7-8 سنوات. نظرًا لأن الشركة بائع ، فإنها تراقب منتجاتها وتقوم بتطويرها بانتظام ، ولكنها لا تعيد تشكيلها من الصفر. وهذا يعني أن المنتجات تحتوي على كمية كبيرة من الشفرة القديمة ، والحلول التكنولوجية والمعمارية "القديمة". لم يتم النظر في اختبار هذه المنتجات في المراحل الأولية ، قبل أن يتم تطويرها وفقًا لمبدأ "أسرع وأسرع وفي الإنتاج" ، ولكن يوجد اليوم قدر كبير من الاختبارات اليدوية - الانحدار واختبار وظائف جديدة. من الناحية الإيديولوجية ، يتم تطوير المنتج تحت ضغط احتياجات العمل بحيث لا يوجد وقت لإعادة التفكير في الأيديولوجيات وإعادة تشكيل المنتجات بنفسها. يتم ذلك فقط في الوقت الذي يفهم فيه الجميع أن هذا لن ينجح أكثر من كلمة "بالكامل".
بالإضافة إلى المنتجات القديمة ، تعمل الشركة على تطوير حلول جديدة تمامًا باستخدام أحدث التقنيات والمناهج المعمارية. ولكن هنا ، ليس كل شيء سلسًا ، حيث لا يهدأ الضغط العام من احتياجات العمل. إن اختبار هذه المشروعات موجود بالفعل في المراحل الأولى من التطوير ، ومع ذلك ، لا تزال "الحلول اليدوية" سائدة ، والتي تعطي أسرع النتائج وتتيح للمطورين كتابة رمز المنتج بشكل حصري دون التفكير في كيفية اختباره.
وظيفة الاختبار
الآن بضع كلمات حول الهيكل: كما قلت ، حوالي 30 شخصًا جزء من وظيفة الاختبار. من هؤلاء ، 17-19 هو رابط المبتدئين مع خبرة في هذا المجال لا تزيد عن سنة واحدة. غالبًا ما يكون هؤلاء الأشخاص بدون تعليم تقني ، لكنهم "ذوو عيون مشتعلة" ورغبة كبيرة في العمل في مجال تكنولوجيا المعلومات (لماذا يكون لديهم هذه الرغبة موضوع منفصل للمناقشة). ما تبقى من 11 إلى 13 شخصًا هم كبار المديرين والمتوسطة: يمثل 3-4 أشخاص كبار السن و7-10 أشخاص - المتوسط. يتم توزيع وظيفة الاختبار بأكملها عبر 13-15 منتجًا / مشروعًا مختلفًا بدرجات متفاوتة من المشاركة والتعقيد والمشاركة.
ثقافة
هذه هي المقدمة الأخيرة.
لسوء الحظ ، لا يزال هناك بعض سوء الفهم للقيمة التي يمكن أن تجلبها وظيفة الاختبار. ويرجع ذلك إلى أن نتيجة العمل في شكل (على سبيل المثال) لميزة جديدة تكون واضحة للجميع ، وهي مفهومة و "ملموسة" من الناحية العملية - عند تنفيذها ، ترتفع الجودة الإجمالية للمنتج ، وتصبح على الأقل غير محرجة بالنسبة لمنتجات الشركة. في الوقت نفسه ، هناك بعض الطوائف من المطورين حيث العبارات التالية صحيحة: "المطور هو اللاعب الرئيسي ، وإذا لم يكن هناك ، يمكن إطلاق الباقي" ، وكذلك "يعد المطورون موردًا باهظًا ويجب أن يكتبوا رمز المنتج فقط ولا يشتت انتباههم عن طريق الأنشطة غير المهمة. ". بناءً على هذه العبارات ، تشكلت "ثقافة" معينة في هذه الشركة.
بيان المشكلة
وكما يقولون ، ما هي المشكلة؟ لماذا تغيير شيء إذا كان كل شيء يعمل من هذا القبيل؟ لماذا تنتقل إلى مكان ما إذا كان هناك نموذج عمل ، وهو ما يحقق أرباحًا؟
يمكن أن تنشأ هذه الأسئلة بشكل منطقي في الشخص الذي يدفع مقابل التنمية بالكامل. ولكن هناك هؤلاء الأشخاص الذين تتراوح أعمارهم بين 3-4 أشخاص في وظيفة الاختبار والذين يعتبرون أنفسهم أقل من شأنهم ، والذين شاهدوا التقرير الأول لـ B. Sadogursky وليس فقط الذين يرون الجانب الآخر من الموقف ويرغبون في تغيير ما يحدث للأفضل وبالتالي ، حل عدد قليل المرضى "المشاكل.
التالي - الخيال الخالص والاقتراحات القائمة على مواد من مختلف المؤلفين والمتخصصين في مجال تكنولوجيا المعلومات.
الحل (ممكن)
لنبدأ بتحديد الأهداف والغايات في إطار التغيير. سنحذف الجانب التجاري بوعي ولن نرفعه ، هذا موضوع منفصل لل holivar ، خاصةً لأنه لعب دورًا مهمًا في الوضع الحالي لهذه الشركة.
نرسم صورة للمستقبل. ما الذي نسعى إليه؟
بادئ ذي بدء ، نريد في وقت قصير الحصول على مجموعة من المنتجات عالية الجودة (!) التي ستحقق ربحًا مرتفعًا إلى حد ما. عليك أن تفهم أن كلمة "مربحة" لا تعني "الجودة".
ما الذي يتعين علينا القيام به لتحقيق الهدف؟ بادئ ذي بدء ، أقترح النظر في المسار من وجهة نظر التكنولوجيا ، وليس التجارة. لتحقيق هذا الهدف ، من الضروري التركيز على حقيقة أن المنتجات يجب أن تلبي احتياجات المستخدمين النهائيين ، مع وجود تكاليف منخفضة لتطوير وظائف جديدة ولصيانة تلك الموجودة بالفعل في الإنتاج. أي أثناء التطوير ، يجب علينا: أ) فهم متجه الحركة بوضوح ، ب) جعل المنتجات موثوقة بدرجة كافية بحيث لا توجد مشاكل في تشغيلها ، بعبارات بسيطة ، تأكد من عدم وجود أخطاء عند العمل مع المنتج. بناءً على ذلك ، ينبغي أن يكون لدينا سياسة Zero Bug Policy لجميع المنتجات ، أي أن اختبارنا ، كعملية ، يجب أن يمنحنا ضمانًا بعدم وجود أخطاء في الإنتاج.
الجانب الثاني هو التركيز على النتيجة النهائية لعملية التطوير بأكملها ، مما سيتيح لنا عدم تطوير ما لا يمكن للمستخدم استخدامه أو عدم فهمه لكيفية استخدامه. نذكر الجزء الثاني فقط ، لأن الموضوع واسع للغاية ، لكنه لن يعمل دون لمسه.
لذلك ، هدفنا هو:
" بسرعة وكفاءة وبأموال معقولة " (بثمن بخس ، على الأرجح ، لا يمكنك القيام بذلك على الفور).
الآن دعنا نحاول ربط ما أعطيت مع الغرض المقصود.
سريع نعم ، هذا ممكن ، لكننا نعرض للخطر الجودة: عمليات ضمان الجودة اليدوية الحالية ستكون قادرة على إعطاء سرعة تنفيذ كافية فقط على المنتجات الصغيرة ذات قصص المستخدم البسيطة. علاوة على ذلك ، فإن ملف تعريف الشركة هو تطوير حلول معقدة إلى حد ما لأتمتة العمليات التجارية. الخلاصة - "سريع" لا يعمل ، لأن العمل اليدوي على كميات كبيرة سوف يفقد أمام أي حل آلي.
التركيز على النتيجة . هذا ممكن ، لكنه يتطلب من المشاركين إنشاء قيمة غمر عميق بما فيه الكفاية في مجال الموضوع ووقت كبير يقضونه في نقل هذه القيمة إلى المنفذ النهائي. في الوقت نفسه ، فإن فناني الأداء هم من المطورين الذين ، كجزء من أحد العبارات ، يجب عليهم قضاء الحد الأقصى من الوقت في كتابة التعليمات البرمجية دون تشتيت انتباه البيئة.
ويترتب على كل ذلك أنه من أجل حل المشكلة الرئيسية ، من الضروري إشراك خبراء ضمان الجودة ليس فقط ، ولكن أيضًا المطورين في عملية الاختبار. في الوقت نفسه ، لزيادة سرعة تسليم القيمة ، من الضروري النظر بعناية أكبر في عمليات أتمتة التسليم وأتمتة التحقق مما يتم تسليمه.
ما الذي يجب القيام به لحل المشكلة الرئيسية؟
في رأيي ، بناءً على الخبرة ، يتطلب الأمر:
- تزج المطورين أكثر في أهداف المنتج من منتجاتهم.
- لإقناع الشركات بأن تكاليف التشغيل الآلي مهمة وتوفر المزيد من الفوائد الاقتصادية لجميع التكاليف الاقتصادية.
- من الحكمة أتمتة كل ما يمكن أن يكون آليا ، لاستبعاد العمل اليدوي من عملية تسليم القيمة إلى الحد الأقصى.
- قم بتطبيق سياسة Zero Bug ، والتي بدونها سيواجه المستخدمون مشاكل تؤدي إلى صد منتجاتنا. بالمناسبة ، يشير مثال ناجح لـ "DoDo" إلى أن هذا ممكن التحقيق.
ما الذي يتعين علينا القيام به لإقناع المشاركين بضرورة تغيير المواقف ووجهات النظر العالمية؟
المطورون
كيف تجادل - لماذا يحتاجون إلى القيام بشيء آخر إلى جانب برمجة الكود الوظيفي المفضلة لديهم؟ أقترح التركيز مباشرة على المشاكل التي تنشأ مع مثل هذه المنظمة. هناك العديد منهم:
- تطوير ما لن يحتاجه أحد. IMHO ، هذه هي واحدة من المشاكل الأولى. يقوم المطورون بعمل شيء ما ، ويحافظون على الثقة في أنهم يقومون بذلك بشكل صحيح ، ولكن في النهاية يحصلون على النتيجة الخاطئة التي يريدها المستخدم النهائي. لماذا؟ لأن المهام والمشاكل لا تنتقل إليهم من قبل أولئك الذين يستخدمون المنتج في النهاية ، ولكن بواسطة المديرين أو العملاء الذين لا يستخدمون هذه المنتجات فيما بعد. لماذا يحدث هذا؟ كل الناس لديهم وجهات نظر مختلفة. إذا كان المطور لم يكن تقنيًا ، ولكن مهمة وظيفية مع وصف للنتيجة في المخرجات (والأفضل - مع وصف للمشكلة التي يجب أن تحلها هذه المهمة) ، سيكون هناك فهم أكبر للنتيجة ، ونتيجة لذلك ، عدد حالات تطوير شيء ما سيتم تخفيض لا لزوم لها. نعم ، هذه حقيقة معروفة ، لكن المشكلة لا تزال غير قائمة ، بل يجب حلها مع الشركة ، مع تبرير صياغة مهام التنمية بطريقة مختلفة قليلاً. حول كيفية نقل هذا إلى العمل - أبعد من ذلك.
- الحاجة إلى التبديل بين السياقات. غالبًا ما تكون نتائج الاختبار متأخرة ، في عملية التطوير مع وجود اختبار يدوي ، ونتيجة لذلك ، يجب أن يصرف المطور عن طريق حل المشكلات التي تظهر كنتيجة للاختبار. ما الذي يمنع المطورين من التحقق بعد تنفيذ النتيجة الخاصة بهم؟ هناك نقطتان. الأول هو الافتقار إلى المعرفة والمهارات في مجال ضمان الجودة. والثاني - غالبًا ما يعتقد المطورون أن هذه ليست وظيفتهم ، ونتيجة لذلك ، لا يريدون القيام بذلك. في أحد ملفات podcast المبكرة من RadioQA ، هناك مشكلة كاملة حول التطوير بدون اختبار ، والتي تصف بالتفصيل الكافي هذا التأثير وأسباب هذا "التردد".
كيف سيتم اختبار مساعدة المطورين أو كيفية مساعدتهم في حل المشكلات المشار إليها؟
- احصل على مزيد من المعلومات حول مجال الموضوع أو الغرض من المهام التي يتعين حلها. ما هي الأسئلة النموذجية التي يطرحها المطور عند تقديم المهمة؟ "كيف نفعل هذا؟" "وما الذي يجب القيام به هنا؟" "وكيف نفعل هذا على الرغم من حقيقة أن هذا معروف فقط؟" "وكيف سيؤثر هذا على هذه الوظيفة؟". كل هذه الأسئلة تهدف إلى توضيح تنفيذ المهمة ، و لا لفهم تقلب هذه المهمة. ماذا يفعل المختبر عندما يتعرف على وصف جديد لوظيفة جديدة؟ يسأل أيضًا أسئلة ، ولكن بطريقة مختلفة قليلاً: "ماذا سيحدث إذا؟" "لماذا يجب أن يكون هذا؟" "ماذا يجب أن أحصل عليه في النهاية؟" "ماذا لدي في البداية؟" "كيف يجب أن يكون هذا مرتبطًا؟" مع ذلك؟ " أي أن جميع الأسئلة تقريبًا تهدف إلى تحديد سيناريو المستخدم وفهم نتيجة هذه الوظيفة بالضبط .
ما هو المهم؟ من خلال طرح الأسئلة ليس فقط (كيفية التنفيذ) ، ولكن أيضًا الأسئلة التي تهدف إلى فهم النتيجة النهائية ، يمكنك الحصول على مزيد من المعلومات حول المهمة ، وجعل الطرق المتوقعة غير مألوفة فقط ، ولكن أيضًا أكثر بساطة وفعالية. في سيناريو إيجابي ، سيساعد هذا في عدم كتابة رمز إضافي أو إنشاء ما يحتاج إليه المستخدم النهائي بالضبط ، وهو ما نحتاجه.
سوف يسأل أحدهم: "لماذا يجب علي ، كمطور ، أن أكون مهتمًا ، أو يجب أن أفكر في الأمر؟" سنجيب - حتى لا تتطور "إلى الطاولة". تُظهر نتائج استطلاع للمطورين في بيئتي مدى إلغاء تنشيطه عندما تفعل شيئًا ما ، ولكن لا تطلقه (ضعه على الرف).
- سؤال آخر: "لماذا أحتاج ، كمطور ، لإجراء اختبار إذا كان لدينا اختبار؟" أو "لماذا أحتاج إلى تطوير بعض التعليمات البرمجية الإضافية التي لا تفي بمهام المنتج المحددة؟" . هنا يمكنك تقديم شيء آخر. الاختبارات الآلية هي في الأساس نفس الكود الذي يطيع قوانين البرمجة نفسها بفارق بسيط. عندما يعمل مطور في إطار منتج كبير ، فإنه يضطر إلى الانصياع لقواعد التطوير والتقنيات المحددة داخل المنتج ، والكتابة باللغة التي يكتب بها هذا المنتج لاستخدام الأطر المستخدمة في هذا المنتج. ليس من الضروري القيام بذلك عند كتابة اختبار: لا أحد يفرض عليك استخدام نفس اللغة أو النهج نفسها: عند تنفيذ اختبار تلقائي ، يمكنك بسهولة تجربة لغة جديدة تمامًا واكتساب الخبرة معها.
هناك قاعدة واحدة بسيطة تلتزم بها المطورين عند كتابة رمز المنتج - الحد الأقصى الأمثل لما تفعله ، والاستهلاك الأمثل للموارد ، والأداء الأمثل ، (ويفضل) الحد الأقصى لإعادة الاستخدام وما إلى ذلك. عند تطوير الاختبارات الآلية ، هناك أيضًا قواعد ، وهناك قوالب ، وهناك أطر عمل ، لكنها مختلفة. مهمتهم هي تمكينهم من جعل رمز الاختبار في أسرع وقت ممكن ، والتي ستنجح ... إنها ستعمل فقط.
التحسين وسرعة التنفيذ في الاختبارات الذاتية نقاط ثانوية ولا يتم تذكرها على الفور. لذلك ، إذا كنت تريد فجأة تجربة Kotlin أو Java أو أي لغة أخرى ، ولكن المشروع مكتوب بلغة مختلفة تمامًا عن ما تريده (على سبيل المثال ، في C #) ، يمكنك تغييره إلى لغتك المرغوبة عن طريق تطوير اختبارات تلقائية.
- "كيف يمكنني اختبار؟ أنا لا أفهم أي شيء عن هذا. أنا مجرد مطور. " هنا ، سيأتي المختبرون إلى عملية الإنقاذ ، أو بالأحرى مهندسي ضمان الجودة الذين يدركون جيدًا جميع التقنيات التي كتب عليها المنتج الرئيسي. بفضل معرفتهم ، يمكنهم المساعدة في تثقيف المطورين حول كيفية وما الذي يجب اختباره ، وكيفية اختيار البيانات المناسبة ، وما الذي ينبغي لمولد البيانات القيام به لتقليل المخاطر حسب نوعها وما لا يجب الانتباه إليه على الإطلاق. في مثل هذا الترادف ، يستفيد المختبرون من معرفتهم إلى أقصى حد ، ولا يقوم المطورون بعمل غير ضروري وغير ضروري.
- ولكن ماذا عن السرعة؟ إنها تعاني! " نعم ، سوف تعاني في المراحل الأولى من تطوير المشروع ، ونعم ، بالطبع ، من البداية إلى الانغماس في التشغيل الآلي الكامل يعد مكلفًا. ما يجب القيام به بحيث تكون التكاليف مثالية؟ كحد أدنى ، يجب أن نفهم بوضوح كيف وماذا لأتمتة. كما أنه من المنطقي عدم إغلاق كل شيء بدون تفكير مع الاختبارات والسعي لتحقيق تغطية 100 ٪ من الشفرة ، ولكن للقيام بذلك على أساس نموذج المخاطر. سوف المهندسين QA تفعل الشيء نفسه.
- "سرعة! نريد الحصول على شحنات كافية بسرعة. نريد أيضًا أن نكون موثوقين وأن منتجاتنا خالية من الأخطاء! " أنا هنا أقترح تغيير نهج التنمية. إذا كان من المألوف تشغيل كل شيء في وضع التصحيح محليًا ، فغالبًا ما يتطلب الأمر بعض التطبيقات الأساسية في بعض الأحيان للتطبيقات الخطيرة. هذا هو المكان المناسب لجميع الاتجاهات الجديدة حول الالتحام وتنفيذ المواقف المختلفة. شيء آخر مهم: حتى في مرحلة التطوير الأولى ، تحتاج إلى التفكير في كيفية تسليمها إلى منصات العمل ، أي ليس فقط نشر كل شيء يدويًا ، ولكن أيضًا إعداد عملية نشر آلية. ماذا سيعطينا؟ عندما يحين وقت التسليم إلى الإنتاج ، سيكون كافياً تغيير نقطة الحساب فقط ، وليس لتكوين العملية بأكملها من البداية. ما سوف يعطي هذا المطور؟ مزيد من الثقة بأنه يقوم بكل شيء بشكل صحيح ، لأنه تم فحص نصوص التسليم لأكثر من جولة ، ويجب ألا تكون هناك مشكلة في الإصدار.
عمل
ولكن ماذا عن العمل؟ لماذا يجب أن يكون مهتمًا بهذا التحول؟ لماذا يعقل أن يستثمر في هذا النهج؟ بناء التفسير ، سأذهب بنفس الطريقة. ما هي المشاكل التي تواجهها هذه الشركة الآن ، ما هي المشاكل التي يتعين عليك حلها عند العمل في مجال تكنولوجيا المعلومات وعند تطوير منتجات التكنولوجيا الفائقة؟ مرة أخرى ، سأعتمد هنا بالتحديد على رأيي:
- "ما الذي قد لا يناسب الأعمال أكثر؟" غالبًا ما ينسى التطوير أنه لا يجب تطوير المنتج فحسب ، بل أيضًا بيعه ، والذي يتطلب مجموعة كبيرة بما فيه الكفاية من التدابير ، بما في ذلك إعداده للدخول إلى السوق. يعد القيام بذلك بعد تطوير المنتج بمثابة فشل مضمون ، وهذا هو السبب في أن معظم العمل على إعداد قنوات البيع والترويج لمنتج جديد يبدأ تقريبًا في نفس اللحظة التي يبدأ فيها التطوير.
"ماذا يحدث إذا تأخر التطوير عن تاريخ الإصدار؟ أم أن التطوير سوف يجلب إلى السوق منتجًا عالي الجودة غير كافٍ؟ " ستكون هناك خسائر. وليس فقط المواد ، ولكن أيضا السمعة. من المهم أن تتأكد الأعمال من أنه بحلول وقت بدء المبيعات ، لن يكون المنتج جاهزًا فحسب ، بل سيكون أيضًا بجودة مناسبة. إذا كانت هناك مراحل للاختبار اليدوي في عملية التطوير ، فسيكون من الضروري حتما إما إعادة الجدولة أو مراعاة مخاطر الاضطرابات في هذه المراحل. من الممكن التنبؤ بالعامل البشري ، لكنه صعب و (رأيي) ليس أقل تكلفة.
- "ما الذي يهتم به النشاط التجاري أيضًا؟" بالطبع ، إنه قلق بشأن الاستثمارات الرأسمالية في التنمية. لكن الاستثمارات الرأسمالية ، في معظمها ، رغم كونها ضخمة ، يتم إجراؤها في المرحلة الأولية ، أي قبل الإصدار ، أو على الأقل قبل الإصدار ، لا يتم تعويض التكاليف عن طريق المبيعات. إلى جانب الاستثمارات الرأسمالية ، هناك أيضًا مصروفات تشغيلية ، والتي تبدأ في المساهمة في مرحلة التشغيل ومن المهم محاولة تقليلها إلى أقصى حد ممكن.
"لماذا الأتمتة باهظة الثمن (من حيث النفقات الرأسمالية) في هذه الحالة تفوز فيما يتعلق بالنهج اليدوي؟" رأيي عامل واضح. الأتمتة هي نفس التطور. , . , , , , . , . لماذا هذا مهم؟ . , , « , , , » , , .
- — . , . , , . , .
? , - . . , , , . , , , , , . , .
لنفترض أن الشركة توافق على الحاجة إلى إجراء تغييرات في العملية ومستعدة "لشرائها جميعًا مرة واحدة". كم ستكون التكلفة وما هي المصاريف التي يجب تضمينها؟- , , , , . : X Y , , , X Z , Z < Y. : , , ( ) .
- — QA-. , «» . , QA- , , , . : , , , , , .
— , . . , , , , , , , , , . .
- — . , , . , , , , . , QA-. , . , , «» — , , , . , , .
- , , — (, , - ). . , . , , , , , (), .
من المستحيل أن نقول أن هذا المسار هو بالتأكيد أكثر ربحية فيما يتعلق بالحل اليدوي ، ولكن يتم الكشف عن ميزته الكاملة في دلتا النفقات التشغيلية ورضا المستخدم النهائي. يمكننا مقارنة ذلك بشراء سيارة باهظة الثمن ولكن موثوقة لا تتطلب مصاريف ، باستثناء البنزين والصيانة الدورية ، وشراء سيارة مستعملة قديمة. نعم ، سعر سعر جديد أعلى في البداية ، ولكن تكاليف التشغيل أقل ، والراحة و "الشعور بالهدوء" أعلى. عند استخدام واحدة في البداية ، تكون التكاليف منخفضة ، ولكن أثناء العملية ، تزداد التكاليف ويمكن مقارنة فترة زمنية قصيرة بتكلفة الشراء الأولي.المضي قدما. لا تنسى سياقنا وتذكر تكوين وظيفة الاختبار.اختبار
ماذا سيحدث لميزة الاختبار الحالية؟ إذا نظرنا مرة أخرى إلى تكوين هذه الوظيفة ، فعندئذٍ بيقين 90٪ ، يمكننا القول إن 60٪ من الموظفين من الهيكل بأكمله لن يكونوا مفيدين في الشكل الجديد للوظيفة ، لكن هناك عدة وظائف.إذا كنت تتذكر أننا ذكرنا المنتجات الجديدة والقديمة لشركتنا. سيكون انتقال المنتجات الجديدة إلى نموذج التسليم الذي أصفه غير مؤلم نسبيًا ، حيث إنه لم يتم إصداره بعد ، أو تركه للتو. في الوقت نفسه ، لا تسمح المنتجات التي تم تشغيلها لفترة طويلة بتطبيق هذه المفاهيم على الفور. هذا لا يعني أنك بحاجة إلى وضع حد لها ، فهناك شيء ما يجب تغييره ، لكن لن يكون سريعًا - نقل العملية عن الأرض ، للحصول على عمليات تسليم أكثر موثوقية وأسرع.هذا هو السبب في أن طبقة وظيفة الاختبار "اليدوية" لن تتوقف عن الوجود بين عشية وضحاها ، لذلك سيكون عليك بذل الكثير من الجهد. سيكون لدى جزء من الفاحصين "اليدويين" الوقت الكافي للنمو إما إلى مهندسي الأتمتة أو مهندسي ضمان الجودة. من الواضح تمامًا أنه خلال هذه العملية الانتقالية ، سيتولى الرابط الأوسط والعلوي مهمة الدعم - فهم المرشحون الأكثر احتمالًا لدمجهم في مفاهيم جديدة مباشرة على مستويات مختلفة غدًا. فريق كبير من ذوي الخبرة والمعرفة ، على دراية أيضًا بمفاهيم الأتمتة واختبار ShiftLeft ، مستعد للعب دور مهندسي ضمان الجودة غدًا ، سيستغرق الرابط الأوسط بعض الوقت ، لكنهم سيكونون قادرين أيضًا على الاندماج بسرعة في أدوار مهندس ضمان الجودة أو مهندس الأتمتة.- . , . .