يا هبر!
لدينا موضوع مهم جديد - تطوير عالي الجودة لمنتجات تكنولوجيا المعلومات. في HighLoad++، نتحدث غالبًا عن كيفية جعل الخدمات المزدحمة سريعة، وفي Frontend Conf نتحدث عن واجهة مستخدم رائعة لا تبطئ. لدينا بانتظام موضوعات حول الاختبار، وDevOpsConf حول الجمع بين العمليات المختلفة، بما في ذلك الاختبار. ولكن حول ما يمكن تسميته بالجودة بشكل عام، وكيفية العمل عليها بشكل شامل - لا.
دعونا نصلح هذا من خلال — سنقوم بتطوير ثقافة التفكير في جودة المنتج النهائي للمستخدم في كل مرحلة من مراحل التطوير. عادة عدم التركيز على مجال مسؤوليتك، وربط الجودة ليس فقط بالمختبرين.
سنتحدث أسفل المقطع مع رئيس لجنة البرنامج، ورئيس الاختبار في Tinkoff.Business، ومنشئ مجتمع ضمان الجودة الناطق باللغة الروسية أناستاسيا أسيفا نجوين حول حالة صناعة ضمان الجودة ومهمة المؤتمر الجديد.
- ناستيا مرحبا. من فضلك أخبرنا عن نفسك.
اناستازيا: أدير الاختبارات في أحد البنوك، وأنا مسؤول عن فريق كبير جدًا - نحن أكثر من 90 شخصًا. لدينا خط عمل مهم، فنحن مسؤولون عن النظام البيئي للكيانات القانونية.
لقد درست الميكانيكا والرياضيات وأردت في البداية أن أصبح مبرمجًا. ولكن عندما تلقيت عرضًا مثيرًا للاهتمام، قررت أن أجرب نفسي كمختبر. ومن الغريب أن هذه كانت مكالمتي. الآن أرى كل أعمالي في هذه الصناعة.
أنا من أشد المتحمسين لنظام ضمان الجودة. أنا لست غير مبال بالمنتجات التي يتم إنشاؤها، وكيف يتم التعامل مع الجودة في الشركة، وفي الفريق، ومن حيث المبدأ، في عملية التطوير.
من الواضح بالنسبة لي ذلك والمجتمع في هذا الاتجاه ليس ناضجا بما فيه الكفايةعلى الأقل في روسيا. نحن لا نفهم دائمًا أن ضمان الجودة لا يقتصر فقط على اختبار التطبيق للتأكد من امتثاله للمتطلبات. أود تغيير هذا الوضع.
— يمكنك استخدام الكلمات ضمان الجودة والاختبار. في نظر الشخص العادي، غالبًا ما يتداخل هذان المصطلحان. كيف تختلف إذا قمت بالحفر العميق؟
اناستازيا: بل لا يختلفون. يعد الاختبار جزءًا من نظام ضمان الجودة؛ وهو نشاط مباشر - حقيقة أنني أقوم باختبار شيء ما. هناك في الواقع أنواع كثيرة من الاختبارات، ويتحمل مجموعة متنوعة من الأشخاص مسؤولية أنواع مختلفة من الاختبارات. ولكن هنا في روسيا، عندما ظهرت موجة من المتعاقدين الخارجيين الذين يزودون الشركات باختبارات، تم تخفيض الاختبار إلى نوع واحد.
في معظم الحالات، يقتصر الأمر على الاختبار الوظيفي فقط: حيث يتحققون من أن ما قام المطورون بترميزه يتوافق مع المواصفات وهذا كل شيء.
— من فضلك أخبرنا ما هي التخصصات الأخرى لضمان الجودة؟ ما الذي تم تضمينه هنا إلى جانب الاختبار؟
اناستازيا: ضمان الجودة يتعلق في المقام الأول بإنشاء منتج عالي الجودة. أي أننا نسأل أنفسنا ما هي سمات الجودة التي يجب أن يتمتع بها منتجنا. وبناء على ذلك، إذا فهمنا ذلك، يمكننا مقارنة من يؤثر على سمات الجودة هذه. لا يهم، مطور أو مدير مشروع أو متخصص منتج هو الشخص الذي يؤثر على تطوير المنتج وتراكمه واستراتيجيته.
يصبح المختبر أكثر وعيا بدوره. وهو يدرك أن مهمته لا تقتصر فقط على اختبار الامتثال للمتطلبات، ولكن أيضًا اختبار المتطلبات، والتشكيك في التركيبات التي تأتي من متخصص المنتج، والكشف عن جميع المتطلبات والتوقعات الضمنية للعميل. عندما نقدم وظائف جديدة لعملائنا، يجب علينا حقًا تلبية توقعاتهم وحل مشاكلهم. إذا فكرنا في كل سمات الجودة، سيكون العميل راضيًا وسيفهم أن الشركة التي يستخدم منتجها تهتم حقًا بمصالحه، ولا تعمل على مبدأ "فقط لإصدار ميزة".
— يبدو أن ما وصفته للتو هو مهمة أخصائي المنتج. هذا، من حيث المبدأ، لا يتعلق بالاختبار ولا يتعلق بالجودة - بل يتعلق بشكل عام بإدارة المنتج، أليس كذلك؟
اناستازيا: مشتمل. إن ضمان الجودة ليس مجالًا يكون مسؤولاً عنه شخص محدد. يوجد الآن اتجاه شائع في الاختبار، وهو نهج يسمى اختبار رشيق. ينص تعريفه بوضوح على أن هذا هو نهج جماعي للاختبار، والذي يتضمن مجموعة معينة من الممارسات. الفريق بأكمله مسؤول عن تنفيذ هذا النهج، وليس من الضروري حتى أن يكون هناك مختبر في الفريق. يركز الفريق بأكمله على تقديم القيمة للعميل والتأكد من أن القيمة تلبي توقعات العملاء.
— اتضح أن الجودة تتقاطع مع جميع التخصصات المحيطة تقريبًا، وتفرض إطارًا على كل ما حولها؟
اناستازيا: يمين. عندما نفكر في الطريقة التي نريد بها إنشاء منتج عالي الجودة، فإننا نبدأ بالتفكير في السمات المختلفة للجودة. على سبيل المثال، كيفية التحقق من أننا صنعنا بالفعل الميزة التي يحتاجها عميلنا.
وهنا يأتي دور هذا النوع من الاختبارات: UAT (اختبار قبول المستخدم). لسوء الحظ، نادرًا ما يتم تطبيقه في روسيا، ولكنه موجود أحيانًا في فرق SCRUM كعرض توضيحي للعميل النهائي. هذا نوع شائع إلى حد ما من الاختبار في الشركات الأجنبية. قبل فتح الوظيفة لجميع العملاء، نقوم أولاً بإجراء اختبار UAT، أي أننا ندعو المستخدم النهائي الذي يقوم بالاختبار وتقديم التعليقات على الفور - ما إذا كان المنتج يلبي التوقعات حقًا ويحل المشكلة. فقط بعد ذلك يحدث القياس لجميع العملاء الآخرين.
وهذا هو، نحن نركز على الأعمال التجارية، على العميل النهائي، ولكن في نفس الوقت لا تنسى التكنولوجيا. تعتمد جودة المنتج أيضًا بشكل كبير على التكنولوجيا. إذا كانت لدينا بنية سيئة، فلن نتمكن من إصدار الميزات بسرعة وتلبية توقعات العملاء. قد يكون هناك الكثير من الأخطاء عند محاولة التوسع، أو عند محاولة إعادة البناء قد نتعطل شيئًا ما. كل هذا سيؤثر على رضا العملاء.
من وجهة النظر هذه، يجب أن تكون البنية بحيث يمكننا كتابة تعليمات برمجية نظيفة تسمح لنا بإجراء تغييرات بسرعة وعدم الخوف من كسر كل شيء. بحيث لا تمتد تكرارات المراجعة على مدار عدة أشهر، وذلك ببساطة لأننا نمتلك الكثير من الإرث، ونحن بحاجة إلى إجراء مراحل اختبار طويلة.
- في المجمل، يشارك بالفعل المطورون والمهندسون المعماريون وعلماء المنتجات ومديرو المنتجات والمختبرون أنفسهم. من يشارك أيضًا في عملية ضمان الجودة؟
اناستازيا: لنتخيل الآن أننا قمنا بالفعل بتسليم الميزة للعميل. من الواضح أنه يجب مراقبة جودة المنتج حتى عندما يكون قيد الإنتاج بالفعل. في هذه المرحلة، قد تظهر مواقف ذات سيناريوهات غير واضحة، تسمى الأخطاء.
السؤال الأول هو كيف نتعامل مع هذه الأخطاء بعد أن قمنا بالفعل بإصدار المنتج؟ كيف نتفاعل، على سبيل المثال، مع التوتر؟ لن يكون العميل سعيدًا جدًا إذا استغرق تحميل الصفحة أكثر من 30 ثانية.
وهنا يأتي دور الاستغلال، أو كما يسمونه الآن، DevOps. في الواقع، هؤلاء هم الأشخاص المسؤولون عن تشغيل المنتج عندما يكون في مرحلة الإنتاج بالفعل. وهذا يشمل أنواعًا مختلفة من المراقبة. حتى أن هناك نوعًا فرعيًا من الاختبار - الاختبار على الإنتاج، عندما نسمح لأنفسنا بعدم اختبار شيء ما قبل طرحه واختباره فورًا عند الإنتاج. هذه سلسلة من الإجراءات من وجهة نظر البنية التحتية التنظيمية التي تسمح لك بالاستجابة السريعة لحادث ما والتأثير عليه وتصحيحه.
البنية التحتية مهمة أيضا. غالبًا ما تكون هناك مواقف يكون من المستحيل فيها، أثناء الاختبار، التأكد من أن لدينا حقًا كل ما نود تقديمه للعميل. نطرحه في مرحلة الإنتاج ونبدأ في اكتشاف المواقف غير الواضحة. وكل ذلك لأن البنية التحتية في الاختبار لا تتوافق مع البنية التحتية في الإنتاج. وهذا يؤدي إلى نوع جديد من الاختبارات - اختبار البنية التحتية. هذه هي التكوينات والإعدادات المختلفة وترحيل قاعدة البيانات وما إلى ذلك.
وهذا يثير السؤال - ربما يحتاج الفريق إلى استخدام البنية التحتية كرمز.
أعتقد أن البنية التحتية تؤثر بشكل مباشر على جودة المنتج.
آمل أن يكون هناك تقرير في المؤتمر يتضمن حالة حقيقية. اكتب إلينا إذا كنت على استعداد لإخبارنا من خلال تجربتك الخاصة بكيفية تأثير البنية التحتية كرمز على الجودة. تعمل البنية التحتية كرمز على تسهيل التحقق من جميع الإعدادات واختبار الأشياء التي لا يمكن تحقيقها بأي طريقة أخرى. لذلك، تشارك العملية أيضًا في عملية تطوير منتج عالي الجودة.
– ماذا عن التحليلات والتوثيق؟
اناستازيا: وهذا ينطبق أكثر على أنظمة المؤسسات. عندما نتحدث عن المؤسسات، يتبادر إلى ذهننا على الفور أشخاص مثل المحللين ومحللي الأنظمة. ويطلق عليهم أحيانًا اسم الكتاب التقنيين. ويتلقون مهمة لكتابة مواصفات وإكمالها، على سبيل المثال، لمدة شهر.
لقد ثبت مرارًا وتكرارًا أن كتابة مثل هذه الوثائق تؤدي إلى تكرارات تطوير طويلة جدًا وتكرارات طويلة للتحسين، لأنه أثناء عملية الاختبار يتم تحديد الأخطاء وتبدأ عمليات الإرجاع. ونتيجة لذلك، هناك الكثير من الحلقات التي تزيد من تكاليف التطوير. بالإضافة إلى ذلك، قد يؤدي هذا إلى ظهور نقاط الضعف. يبدو أننا قد كتبنا رمزًا مرجعيًا، ولكن بعد ذلك قمنا بإجراء تغييرات تكسر البنية المدروسة تمامًا.
والنتيجة النهائية هي منتج ليس عالي الجودة تمامًا، لأن التصحيحات قد ظهرت بالفعل في البنية، ولم تتم تغطية الكود في بعض الأماكن بشكل كافٍ بالاختبارات، لأن المواعيد النهائية تنفد، ويجب إغلاق جميع الأخطاء بسرعة. وكل ذلك لأن المواصفات الأصلية لم تأخذ في الاعتبار جميع النقاط التي يجب تنفيذها.
المطورون ليسوا آفات ولا يكتبون تعليمات برمجية تحتوي على أخطاء عن قصد.
إذا فكرنا في البداية في المواصفات التي ستغطي جميع النقاط الضرورية، فسيتم تنفيذ كل شيء تمامًا حسب الحاجة. ولكن هذه هي المدينة الفاضلة.
ربما يكون من المستحيل كتابة مواصفات مثالية مكونة من 100 صفحة. لهذا بحاجة إلى التفكير في طرق بديلة لكتابة الوثائقوالمواصفات وتحديد المهام التي من شأنها أن تقربنا من ضمان قيام المطور بما هو مطلوب بالضبط.
هنا تتبادر إلى الذهن أساليب Agile - قصص المستخدم مع معايير القبول. ينطبق هذا بشكل أكبر على الفرق التي تتطور في تكرارات صغيرة.
- ماذا عن اختبار قابلية الاستخدام، وسهولة استخدام المنتج، والتصميم؟
اناستازيا: هذه نقطة مهمة جدًا، لأن هناك مصممين في الفريق. في أغلب الأحيان، يتم استخدام المصممين كخدمة - إما عن طريق قسم التصميم أو عن طريق مصمم خارجي. غالبًا ما تكون هناك مواقف يبدو فيها أن المصمم استمع إلى أخصائي المنتج وفعل ما فهمه. ولكن عندما نبدأ التكرار، يتبين أن ما تم فعله بالفعل لم يكن ما كان متوقعًا: لقد نسي المصمم شيئًا ما، ولم يفكر بشكل كامل في السلوك، لأنه ليس في الفريق وليس في السياق، أو في المقدمة لم يفهم المطور النهائي تخطيطه بالكامل. قد يستغرق الأمر عدة تكرارات لمجرد وجود مشكلة في فهم مطور الواجهة الأمامية للتصميم.
بالإضافة إلى أن هناك مشكلة أخرى. تكتسب أنظمة التصميم شعبية الآن. إنهم في حالة من الضجيج، لكن فوائدهم ليست واضحة تماما.
أجد أن أنظمة التصميم، من ناحية، تبسط التطوير، ولكن من ناحية أخرى، فإنها تفرض الكثير من القيود على الواجهة.
ونتيجة لذلك، فإننا لا نصنع الميزة التي يريدها العميل، بل الميزة التي تناسبنا، لأن لدينا بالفعل مكعبات معينة يمكننا صنعها منها.
أعتقد أن هذا موضوع يستحق إلقاء نظرة عليه والتساؤل عما إذا كنا في محاولتنا لجعل التصميم أسهل، فإننا في الواقع نحل مشكلة العميل.
- هناك عدد مذهل من المواضيع المتعلقة بضمان الجودة. هل هناك مؤتمر في روسيا حيث يمكن مناقشة كل هذه الأمور؟
اناستازيا: هناك أقدم مؤتمر للاختبارات والذي سيقام للمرة الـ 25 هذا العام ويسمى مؤتمر ضمان الجودة SQA Days. ويناقش بشكل أساسي الأدوات وأساليب الاختبار المحددة للمختبرين الوظيفيين. كقاعدة عامة، تفحص التقارير في SQA Days بعمق مجالات محددة في مجال مسؤولية المختبرين أنفسهم، ولكن ليس الأنشطة المعقدة.
يساعد هذا كثيرًا في فهم الأدوات والأساليب المختلفة، وكيفية اختبار قواعد البيانات، وواجهات برمجة التطبيقات، وما إلى ذلك. لكن في الوقت نفسه، من ناحية، لا يحفز ذلك على إشراك أكثر من مجرد الاختبار في إنشاء منتج أفضل. ومن ناحية أخرى، لا يصبح القائمون على الاختبار أكثر انخراطًا في العملية للتفكير في الهدف العالمي للمنتج وعنصر الأعمال الخاص به.
أدير قسمًا كبيرًا وأجري الكثير من المقابلات التي توفر نظرة ثاقبة لحالة الصناعة ككل. كقاعدة عامة، يعمل رجالنا في المؤسسات، ولديهم مجال واضح للمسؤولية. يستخدم الزملاء الذين يعملون في مشاريع أجنبية أنواعًا مختلفة من الاختبارات: يمكنهم بأنفسهم إجراء اختبار التحميل، واختبار الأداء، وحتى في بعض الأحيان اختبار الأمان، لأنهم يساعدون الفريق حقًا في ضمان جودة المنتج.
أود أن يبدأ الرجال في روسيا أيضًا في الاعتقاد بأن الصناعة لا تنتهي بالاختبارات الوظيفية.
— لهذا الغرض، نقوم بتنظيم مؤتمر جديد، QualityConf، المخصص للجودة كنظام متكامل. حدثينا أكثر عن الفكرة، ما هو الهدف الرئيسي للمؤتمر؟
اناستازيا: نريد إنشاء مجتمع من الأشخاص المهتمين بصنع منتجات عالية الجودة. قم بتوفير منصة يمكنهم من خلالها القدوم والاستماع إلى التقارير والمغادرة بعد المؤتمر مع فهم محدد لما يجب تغييره لتحسين الجودة.
في الوقت الحاضر، كثيرًا ما أسمع طلبًا من الاستشارة حول ما يجب فعله عندما تكون هناك مشاكل في الاختبار والجودة. عندما تبدأ في التواصل مع الفرق، ترى أن المشكلة ليست في المختبرين أنفسهم، ولكن في كيفية تنظيم العملية. على سبيل المثال، عندما يعتقد المطورون أنهم مسؤولون فقط عن كتابة التعليمات البرمجية، فإن مسؤوليتهم تنتهي تمامًا في اللحظة التي يسلمون فيها المهمة للاختبار.
لا يفكر الجميع في حقيقة أن التعليمات البرمجية ذات الجودة الرديئة وذات البنية الرديئة تهدد بمشاكل كبيرة للمشروع. إنهم لا يفكرون في تكلفة الأخطاء، حيث أن الأخطاء التي تنتهي في الإنتاج يمكن أن تؤدي إلى تكاليف كبيرة للشركة والفريق. لا توجد ثقافة للتفكير في هذا. أريد أن نبدأ بتوزيعها في المؤتمر.
وأنا أفهم أن هذا ليس ابتكاراً. فقد كتب إدوارد ديمينج، مؤلف كتاب "المبادئ الأربعة عشر للجودة"، عن تكلفة الخطأ في القرن الماضي. يعتمد ضمان الجودة كنظام على هذا الكتاب، ولكن لسوء الحظ، ينسى التطور الحديث ذلك.
- هل تخطط للتطرق مباشرة إلى مواضيع تتعلق بالاختبار والأدوات؟
اناستازيا: أعترف أنه ستكون هناك تقارير حول الأدوات. هناك أدوات عالمية تمامًا يمكن للشركات والفرق من خلالها التأثير على المنتج.
سيتم توحيد جميع التقارير عالميًا من خلال مهمة واحدة مشتركة: أن ننقل للجمهور أنه بمساعدة هذا النهج والأداة والطريقة والعملية ونوع الاختبار، فقد أثرنا على جودة المنتج وقمنا بتحسين حياة العميل.
بالتأكيد لن يكون لدينا تقارير عن أداة من أجل أداة. سيتم توحيد جميع التقارير المدرجة في البرنامج من خلال هدف مشترك.
— من سيكون مهتمًا بما تتحدث عنه، ومن تراه ضيوفًا على المؤتمر؟
اناستازيا: سيكون لدينا تقارير للمطورين الذين يهتمون بمصير مشروعهم أو منتجهم أو نظامهم. وبالمثل، فإنه سيكون موضع اهتمام المختبرين، ويبدو لي، وخاصة المديرين. وأعني بالمديرين الأشخاص الذين يتخذون القرارات ويمكنهم التأثير على مصير وتطوير منتج أو نظام أو فريق أيضًا.
هؤلاء هم الأشخاص الذين يتساءلون عن كيفية تحسين جودة المنتج أو النظام. وفي مؤتمرنا، سوف يتعرفون على مجموعات مختلفة من التدابير وسيكونون قادرين على فهم ما هو الخطأ معهم الآن وما الذي يجب تغييره.
أعتقد أن المعيار الرئيسي هو فهم أن هناك خطأ ما في الجودة والرغبة في التأثير عليه. ربما لن نتمكن من الوصول إلى الأشخاص الذين يعتقدون أن هذا سيفي بالغرض في المرة الأولى فقط.
— هل تعتقد أن الصناعة ككل قد أصبحت جاهزة للحديث ليس فقط عن الاختبار، بل عن ثقافة الجودة؟
اناستازيا: أعتقد أنني نضجت. الآن تبتعد العديد من الشركات عن نهج الشلال التقليدي نحو Agile. هناك تركيز على العملاء، وقد بدأ الأشخاص في الفرق يفكرون حقًا في كيفية إنشاء منتج عالي الجودة. حتى شركات المشاريع تعيد التركيز على تحسين الجودة.
وبالحكم على عدد الطلبات التي تنشأ في المجتمع، أعتقد أن الوقت قد حان. لست متأكدًا بالطبع من أن هذه ستكون ثورة واسعة النطاق، لكنني أود أن تحدث هذه الثورة في الوعي.
- متفق! سنغرس الثقافة ونغير الوعي.
مؤتمر حول التطوير عالي الجودة لمنتجات تكنولوجيا المعلومات عقد في موسكو في 7 يونيو. أنت تعرف ما هي المراحل التي تشكل منتجًا عالي الجودة، ولدينا حالات ناجحة في مكافحة الأخطاء في الإنتاج، وقد اختبرنا الأساليب الشائعة في ممارستنا - نحن بحاجة إلى تجربتك. هم الطلبات قبل 1 مايووستساعد لجنة البرنامج في التركيز على موضوع نزاهة المؤتمر بشكل عام.
اتصل بـ ، الذي نناقش فيه قضايا الجودة والمؤتمر، اشترك فيه لتبقى على اطلاع بأخبار البرنامج.
المصدر: www.habr.com