مرحبا يا هبر!
لدينا موضوع مهم جديد - التطوير عالي الجودة لمنتجات تكنولوجيا المعلومات. نتحدث غالبًا في HighLoad ++ حول كيفية جعل الخدمات المزدحمة سريعة ، وعلى Frontend Conf - واجهة مستخدم رائعة لا تبطئ. لدينا بانتظام موضوعات حول الاختبار ، و DevOpsConf حول الجمع بين العمليات المختلفة ، بما في ذلك الاختبار. ولكن حول نوعية ما يمكن أن يسمى ككل ، وكيفية العمل عليها بشكل شامل ، لا.
دعونا إصلاحه على
QualityConf - سنقوم بتطوير ثقافة التفكير حول جودة المنتج النهائي للمستخدم في كل مرحلة من مراحل التطوير. عادة عدم الوقوع في مجال مسؤوليتك ، وربط الجودة ليس فقط بالمختبرين.
في النهاية ، سنتحدث مع رئيس لجنة البرنامج ، ورئيس الاختبار في Tinkoff
Business ، مبتكر مجتمع ضمان الجودة الناطق باللغة الروسية ،
Anastasia Aseeva-Nguyen ، عن حالة صناعة ضمان الجودة ومهمة المؤتمر الجديد.
- ناستيا ، مرحبا. من فضلك قل عن نفسك.
أناستازيا : أقود الاختبار في البنك ، وأنا مسؤول عن فريق كبير جدًا - هناك أكثر من 90 منا. لدينا خط أعمال مهم ، نحن مسؤولون عن النظام البيئي للكيانات القانونية.
درست في مهمت وأردت في البداية أن أصبح مبرمجًا. ولكن عندما كان لدي عرض مثير للاهتمام ، قررت أن أجرب نفسي كاختبار. الغريب في الأمر أن هذا هو اتصالي. الآن أرى كل عملي في هذه الصناعة.
أنا من أشد المتحمسين للالتزام بضمان الجودة. لا يهمني المنتجات التي يتم إنشاؤها ، وكيف ترتبط بالجودة في الشركة ، في الفريق ، ومن حيث المبدأ ، في عملية التطوير.
من الواضح لي أن
المجتمع في هذا الاتجاه ليس ناضجًا بدرجة كافية ، على الأقل في روسيا. نحن لا نفهم دائمًا أن ضمان الجودة لا يقتصر فقط على اختبار تطبيق للامتثال للمتطلبات. أود تغيير هذا الوضع.
- تستخدم كلمات ضمان الجودة والاختبار. في نظر الرجل العادي ، تتقاطع هاتان المصطلحتان في كثير من الأحيان. كيف تختلف إذا كنت حفر عميقة؟أناستازيا: إنها ليست مختلفة. الاختبار جزء من نظام ضمان الجودة ؛ إنه نشاط مباشر - حقيقة أنني أختبر شيئًا ما. يوجد بالفعل الكثير من أنواع الاختبارات ، والأشخاص المختلفون مسؤولون عن أنواع مختلفة من الاختبارات. ولكن في روسيا ، عندما كانت هناك موجة من المتعاقدين الخارجيين الذين يقومون بتزويد الشركة بالمختبرين ، تم تقليل الاختبار إلى وجهة نظر واحدة.
في معظم الحالات ، تكون مقصورة فقط على الاختبارات الوظيفية: فهي تتحقق من أن ما قام المطورون بتجميعه يتوافق مع المواصفات وهذا كل شيء.
- قل لي ، من فضلك ، ما هي التخصصات الأخرى لضمان الجودة الموجودة؟ ماذا بالإضافة إلى الاختبار لا يشمل؟Anastasia : ضمان الجودة هو ، أولاً وقبل كل شيء ، عن إنشاء منتج عالي الجودة. أي أننا نتساءل عن سمات الجودة التي يجب أن يمتلكها منتجنا. وفقًا لذلك ، إذا فهمنا ذلك ، يمكننا مقارنة من يؤثر على سمات الجودة هذه. لا يهم ،
المطور أو مدير المشروع أو مدير المنتج هو الشخص الذي يؤثر على تطوير المنتج أو تراكمه أو استراتيجيته.
الفاحص يدرك دوره بشكل أفضل. إنه يدرك أن مهمته ليست فقط اختبار الامتثال للمتطلبات ، ولكن أيضًا اختبار المتطلبات ، والتشكيك في اللغة التي تأتي من تقني المنتج ، وكشف جميع المتطلبات والتوقعات الضمنية للعميل. عندما نقدم وظائف جديدة لعملائنا ، يجب أن نلبي توقعاته حقًا ونحل آلامه. إذا فكرنا في جميع سمات الجودة ، فسيكون العميل راضيًا وسيفهم أن الشركة التي يستخدمها منتجه تهتم حقًا بمصالحه ، ولا تعمل على مبدأ "مجرد إطلاق ميزة".
- يبدو أن ما وصفته للتو هو مهمة تقني المنتج. هذا ، من حيث المبدأ ، لا يتعلق بالاختبار وليس بالجودة - إنه يتعلق عمومًا بإدارة المنتج ، أليس كذلك؟اناستازيا : بما في ذلك. ضمان الجودة ليس هو الانضباط الذي يتحمله شخص معين. الآن هناك اتجاه شائع في الاختبار ، وهو نهج يسمى
اختبار رشيق . في تعريفه ، يبدو من الواضح أن هذا هو نهج فريق للاختبار ، والذي يتضمن مجموعة معينة من الممارسات. الفريق بأكمله مسؤول عن تنفيذ هذا النهج ، فليس من الضروري أن يكون المختبر في الفريق. يركز الفريق بأكمله على تقديم القيمة للعميل ، وبذلك تلبي هذه القيمة توقعاته.
- اتضح أن الجودة تتقاطع مع جميع التخصصات المحيطة بها تقريبًا ، مما يفرض إطارًا على كل شيء موجود؟أناستازيا : صحيح. عندما نفكر في ما نريده لإنشاء منتج عالي الجودة ، نبدأ في التفكير في السمات المختلفة للجودة. على سبيل المثال ، كيفية التحقق من أننا صنعنا بالفعل ميزة يحتاجها عميلنا.
هذا النوع من الاختبارات ينبثق مثل
UAT (اختبار قبول المستخدم). لسوء الحظ ، نادراً ما تمارس هذه الممارسة في روسيا ، لكن في بعض الأحيان تكون موجودة في فرق SCRUM ، كعرض تجريبي للعميل النهائي. في الشركات الأجنبية ، هذا نوع شائع إلى حد ما من الاختبارات. قبل فتح الوظيفة لجميع العملاء ، نقوم أولاً بإنشاء UAT ، أي أننا ندعو المستخدم النهائي الذي يجري الاختبار ويعطي ردود الفعل على الفور - هل يلبي المنتج بالفعل التوقعات ويحل الألم. فقط بعد هذا هو التحجيم لجميع العملاء الآخرين.
وهذا هو ، نحن نركز على الأعمال التجارية ، وعلى العميل النهائي ، ولكن في الوقت نفسه
لا تنس التكنولوجيا . جودة المنتج تعتمد بشكل كبير على التكنولوجيا. إذا كانت لدينا بنية ضعيفة ، فلن نتمكن من إصدار الميزات بسرعة وتلبية توقعات العملاء. قد يكون هناك العديد من الأخطاء عند محاولة التوسع ، أو عند محاولة إعادة تكوين رد الفعل ، يمكننا كسر شيء ما. سيؤثر هذا جميعًا على رضا العملاء.
من وجهة النظر هذه ، يجب أن تكون البنية بحيث يمكننا كتابة تعليمات برمجية نظيفة تتيح لنا إجراء تغييرات بسرعة وعدم الخوف من كسر كل شيء. بحيث لا يتم تمديد عمليات التكرار لعدة أشهر لمجرد أن لدينا الكثير من الإرث ونحتاج إلى القيام بخطوات اختبار طويلة.
- في المجموع ، تشارك بالفعل المطورين والمهندسين المعماريين وخبراء المنتج ومديري المنتجات والمختبرين أنفسهم. من آخر يشارك في عملية ضمان الجودة؟أناستازيا : الآن تخيل أننا قد قمنا بالفعل بتسليم ميزة إلى عميل. من الواضح أنك تحتاج إلى مراقبة جودة المنتج ، وعندما يكون بالفعل في الإنتاج. في هذه المرحلة ، قد تظهر مواقف مع سيناريوهات غير واضحة ، ما يسمى الأخطاء.
السؤال الأول هو كيف نعمل مع هذه الأخطاء بعد أن أصدرنا المنتج بالفعل؟ كيف يمكننا ، على سبيل المثال ، الرد على الحمل؟ لن يكون العميل راضيًا جدًا إذا تم تحميل الصفحة لأكثر من 30 ثانية.
هذا هو
المكان الذي يحدث
فيه الاستغلال ، أو كما يطلق عليه الآن ،
DevOps . في الواقع ، هؤلاء هم الأشخاص المسؤولون عن تشغيل المنتج عندما يكون معروضًا للبيع بالفعل. وهذا يشمل أنواع مختلفة من الرصد. يوجد حتى نوع فرعي من الاختبارات - الاختبار على المنتج ، عندما نسمح لأنفسنا بعدم اختبار شيء قبل طرحه واختباره فورًا على المنتج. هذه سلسلة من التدابير من وجهة نظر تنظيم البنية التحتية التي تسمح لك بالاستجابة السريعة لحادث ما والتأثير عليه وتصحيحه.
البنية التحتية مهمة أيضا. غالبًا ما تكون هناك مواقف عندما يكون من المستحيل أثناء الاختبار التأكد من أن لدينا حقًا كل ما نود تقديمه للعميل. نحن نخرج إلى همز - ونبدأ في اللحاق بمواقف غير واضحة. وكل ذلك لأن البنية التحتية في الاختبار لا تتطابق مع البنية التحتية على المنتج. هذا يؤدي إلى نوع جديد من الاختبارات -
اختبار البنية التحتية . هذه هي التكوينات والإعدادات المختلفة وترحيل قاعدة البيانات ، إلخ.
هذا يطرح السؤال - ربما يحتاج الفريق إلى استخدام البنية التحتية كرمز.
أعتقد أن البنية التحتية تؤثر بشكل مباشر على جودة المنتج.
آمل أن يكون للمؤتمر تقرير به قضية حقيقية. اكتب لنا إذا كنت على استعداد لنقول من تجربتك الخاصة كيف تؤثر البنية الأساسية كرمز على الجودة. تسهل البنية التحتية كرمز من فحص جميع الإعدادات واختبار شيء مستحيل بكل بساطة. لذلك ، يشارك الاستغلال أيضًا في عملية تطوير منتج عالي الجودة.
- ماذا عن التحليلات والوثائق؟أناستازيا : هذا ينطبق أكثر على أنظمة المؤسسة. عندما نتحدث عن المؤسسة ، يتبادر الناس إلى الذهن على الفور مثل المحللين ومحللي النظام. وتسمى أحيانا الكتاب التقني. يتلقون مهمة لكتابة المواصفات وإكمالها ، على سبيل المثال ، شهر واحد.
لقد ثبت مرارًا وتكرارًا أن كتابة مثل هذه الوثائق تؤدي إلى تكرارات طويلة جدًا من التطوير وتكرارات طويلة من التحسين ، لأنه أثناء اكتشاف أخطاء عملية الاختبار ، تبدأ عمليات الإرجاع. نتيجة لذلك ، هناك الكثير من الحلقات التي تزيد من تكلفة التطوير. بالإضافة إلى ذلك ، يمكن أن يعرض هذا نقاط الضعف. يبدو أننا قد كتبنا الرمز المرجعي ، ولكن بعد ذلك قمنا بإجراء تغييرات تفسد البنية المدروسة تمامًا.
والنتيجة هي منتج ليس بجودة عالية ، نظرًا لأن التصحيحات ظهرت بالفعل في الهيكل ، ولا تتم تغطية الشفرة في بعض الأماكن بما فيه الكفاية من الاختبارات ، لأن المواعيد النهائية تنفد ، تحتاج إلى إغلاق جميع الأخطاء بشكل أسرع. وكل ذلك لأنه في المواصفات الأصلية لم يتم أخذ جميع النقاط التي يجب تنفيذها في الاعتبار.
المطورون ليسوا آفات ولا يكتبون على وجه التحديد رمزًا به أخطاء.
إذا فكرنا في البداية في تحديد المواصفات التي سيتم فيها تغطية جميع النقاط الضرورية ، فسيتم تنفيذ كل شيء كما ينبغي. ولكن هذا هو اليوتوبيا.
ربما يكون من المستحيل كتابة مواصفات مثالية من 100 صفحة. لذلك ،
نحن بحاجة إلى التفكير في طرق بديلة لكتابة الوثائق وتحديد وتحديد المهام التي من شأنها أن تقربنا من حقيقة أن المطور يفعل بالضبط ما نحتاج إليه.
هنا يأتي نهج رشيق - قصص المستخدم مع معايير القبول. هذا ينطبق أكثر على الفرق التي تتطور بتكرار صغير.
- ماذا عن اختبار قابليتها للاستخدام ، قابليتها للاستخدام المنتج ، التصميم؟أناستازيا : هذه نقطة مهمة للغاية ، لأن هناك مصممين في الفريق. في أغلب الأحيان ، يستخدمه المصممون كخدمة - إما قسم التصميم أو مصمم الاستعانة بمصادر خارجية. غالبًا ما تكون هناك مواقف يبدو أن المصمم قد استمع فيها إلى تقني المنتج وفعل ما فهمه. ولكن عندما نبدأ التكرار ، اتضح أن الأمر لم يكن متوقعًا فعليًا: لقد نسي المصمم شيئًا ما ، ولم يفكر في السلوك لأنه لم يكن في الفريق أو في السياق ، أو أن المطوّر الأمامي لم يفهمه تمامًا. تخطيط. قد يستغرق الأمر عدة تكرارات فقط بسبب وجود مشكلة في فهم التصميم بواسطة المطور الأمامي.
بالإضافة إلى أن هناك مشكلة أخرى. أنظمة التصميم تكتسب شعبية. هم على الضجيج ، ولكن فوائدها ليست واضحة تماما.
رأيت أن أنظمة التصميم ، من ناحية ، تبسط التطوير ، ومن ناحية أخرى ، تفرض الكثير من القيود على الواجهة.
نتيجةً لذلك ، لا نصنع مثل هذه الميزة التي يرغب العميل في الحصول عليها ، ولكنها ميزة ملائمة لنا ، لأن لدينا بالفعل مكعبات معينة يمكننا صنعها منها.
يبدو لي أنه يجب عليك الانتباه إلى هذا الموضوع والتفكير فيما إذا كنا نحل آلام العميل حقًا في محاولة لتبسيط العمل على التصميم.
- اتضح بشكل مدهش العديد من الموضوعات المتعلقة بضمان الجودة. هل هناك مؤتمر في روسيا حيث يمكن مناقشة كل منهم؟Anastasia : يوجد أقدم مؤتمر للاختبار ، والذي سيعقد للمرة الخامسة والعشرين هذا العام ويطلق عليه مؤتمر ضمان جودة أيام SQA. يناقش بشكل أساسي الأدوات وطرق الاختبار المحددة للمختبرين الوظيفيين. وكقاعدة عامة ، تدرس التقارير عن أيام SQA بعمق مجالات محددة في مجال مسؤولية المختبرين أنفسهم ، ولكن ليس الأحداث المعقدة.
يساعد كثيرًا على فهم الأدوات والأساليب المختلفة ، وكيفية اختبار قواعد البيانات ، واجهات برمجة التطبيقات ، إلخ. ولكن في الوقت نفسه ، من ناحية ، لا يحفز ذلك على عدم اختبار فقط في إنشاء منتج أفضل. من ناحية أخرى ، لا يشارك المختبرون أكثر في العملية من أجل التفكير في الهدف العالمي للمنتج ومكون أعماله.
أقود قسمًا كبيرًا وأجري الكثير من المقابلات ، مما يسمح لنا في الواقع بتخيل حالة الصناعة ككل. كقاعدة عامة ، يعمل رجالنا في المؤسسة ، ولديهم مجال مسؤولية واضح. يستخدم الزملاء الذين يعملون في مشاريع أجنبية أنواعًا مختلفة من الاختبارات: يمكنهم أن يقوموا هم أنفسهم باختبار الإجهاد ، واختبار الأداء ، وأحيانًا اختبار الأمان ، لأنهم يساعدون الفريق حقًا على تزويد المنتج بالجودة.
أود أن يبدأ رجالنا في روسيا أيضًا في التفكير في أن الصناعة لا تنتهي باختبارات وظيفية.
- لهذا نقوم بتنظيم مؤتمر جديد QualityConf ، مكرس للجودة كنظام شامل. أخبرنا المزيد عن الفكرة ، ما هو الهدف الرئيسي للمؤتمر؟أناستازيا : نريد إنشاء مجتمع من الأشخاص المهتمين بصنع منتجات عالية الجودة. قدم منصة تتيح لهم الحضور والاستماع إلى التقارير والمغادرة بعد المؤتمر بفهم ملموس لما يجب تغييره في مكانهم لتحسين الجودة.
غالبًا ما أسمع طلبًا من استشارة ما يجب فعله عندما تكون هناك مشكلات في الاختبار ، مع الجودة. عندما تبدأ التحدث مع الفرق ، فإنك ترى أن المشكلة ليست مع المختبرين أنفسهم ، ولكن مع الطريقة التي يتم بها بناء العملية. على سبيل المثال ، عندما يعتقد المطورون أنهم مسؤولون فقط عن كتابة التعليمات البرمجية ، تنتهي مسؤوليتهم تمامًا في الوقت الذي يقومون فيه بنقل المهمة إلى الاختبار.
لا يعتقد الجميع أن رمزًا سيئًا ذو جودة رديئة بهندسة معمارية فقيرة يطرح مشكلات كبيرة للمشروع. لا تفكر في تكلفة الأخطاء ، حيث إن الأخطاء التي تم إدخالها في الإنتاج يمكن أن تؤدي إلى تكاليف كبيرة للشركة والفريق. لا ثقافة للتفكير في الأمر. أريدنا أن نبدأ في توزيعها في المؤتمر.
أفهم أن هذا ليس ابتكارًا ، فقد كتب إدوارد ديمينج ، مؤلف 14 كتابًا عن الجودة ، عن تكلفة الخطأ في القرن الماضي. يعتمد هذا الكتاب على "ضمان الجودة" باعتباره تخصصًا ، ولكن لسوء الحظ ، ينسى التطوير الحديث ذلك.
- هل تخطط للتطرق إلى الموضوعات مباشرةً حول الاختبارات والأدوات؟أناستازيا : أعترف أنه ستكون هناك تقارير حول الأدوات. هناك أدوات عالمية تمامًا يمكن للشركات والفرق من خلالها التأثير على المنتج.
سيتم توحيد جميع التقارير على مستوى العالم من خلال مهمة واحدة مشتركة: أن تنقل إلى الجمهور أنه من خلال هذا النهج ، والأداة ، والطريقة ، والعملية ، ونوع الاختبار ، فقد أثرنا في جودة المنتج وحسّننا حياة العميل.
بالتأكيد لن يكون لدينا تقارير حول الأداة من أجل الأداة. سيتم توحيد جميع التقارير التي تدخل في البرنامج بهدف مشترك.
- من سيكون مهتمًا بما تتحدث عنه ، ومن ترى أنه ضيف على المؤتمر؟أناستازيا : سيكون لدينا تقارير للمطورين الذين لا يهتمون بمصير مشروعهم أو منتجهم أو نظامهم. سيكون الأمر مثيراً للاهتمام بالنسبة للمختبرين ، ويبدو لي ، خاصة بالنسبة للمديرين. أعني بواسطة المديرين الأشخاص الذين يتخذون القرارات ويمكنهم التأثير على مصير وتطوير منتج أو نظام أو فريق أيضًا.
هؤلاء هم الأشخاص الذين يتساءلون عن كيفية تحسين جودة المنتج أو النظام. في مؤتمرنا ، سيتعرفون على مجموعة متنوعة من الأحداث وسيكونون قادرين على فهم ما هو غير صحيح مع ما يجب تغييره.
أعتقد أن المعيار الرئيسي هو أن نفهم أن هناك خطأ ما في الجودة ، وأن نريد التأثير عليه. ربما ، لن ننجح في المرة الأولى التي تصل فيها إلى الناس الذين يعتقدون أن ذلك سينجح.
- هل تعتقد أن الصناعة ككل قد نضجت من أجل التحدث ليس فقط عن الاختبار ، ولكن عن ثقافة الجودة؟أناستازيا : أعتقد أنني قد نضجت. الآن العديد من الشركات تتحرك بعيدا عن نهج الشلال التقليدي نحو أجيل. هناك تركيز على العملاء ، وبدأ الأشخاص في الفرق بالفعل في التفكير في كيفية إنشاء منتج عالي الجودة. حتى في الشركات ، هناك إعادة توجيه لتحسين الجودة.
انطلاقًا من عدد الاستفسارات التي تظهر في المجتمع ، أعتقد أن الوقت قد حان. لست متأكداً ، بالطبع ، أن هذه ستكون ثورة واسعة النطاق ، لكنني أود أن يحدث هذا التغيير في الوعي.
- متفق عليه! سنزرع ثقافة ونفكر في العقل.سيعقد مؤتمر حول تطوير جودة منتجات QualityConf IT في موسكو يوم 7 يونيو . كما تعلمون ، من المراحل التي يتكون فيها منتج عالي الجودة ، هناك حالات في المخزون للتعامل بنجاح مع الأخطاء على المنتج ، لقد اختبرنا التقنيات الشائعة في ممارستنا - نحن بحاجة إلى تجربتك. أرسل طلباتك بحلول 1 أيار (مايو) ، وستساعد لجنة البرنامج في تركيز الموضوع على السلامة العامة للمؤتمر.
اتصل بمحادثة نناقش فيها مشكلات الجودة ومؤتمر ، والاشتراك في قناة Telegram لمواكبة أخبار البرنامج.