لقد حددت 7 مراحل رئيسية في تطور الاختبار لتوضيح كيف تتغير أساليب ضمان الجودة في الشركات. أثناء قراءة المقال ، ستتمكن من تتبع تطور الاختبار وتحديد المرحلة الحالية ومعرفة ما يجب القيام به لتحسين العملية وجودة الاختبار.
كُتب المقال في الأصل لمجلة CIS ، لكنني أعتقد أنه سيكون مثيراً للاهتمام لمستخدمي Habr أيضًا.
لذلك ، المراحل.
- لا يوجد اختبار. يتم تنفيذ وظائفها من قبل المطور أو المدير.
- تظهر الفاحصات ، ولكن فقط مشاريع الاختبار في مرحلة الإنجاز.
- يتحقق المختبرون من جميع مهام المطورين للتأكد من توافقهم مع البيان الأصلي للمشكلة.
- يشارك المختبرون في تصميم الاختبار.
- ويجري تقديم نظام إدارة الاختبار.
- اختبار الأتمتة يظهر.
- يصبح التسلسل الهرمي أكثر تعقيدًا ، وتظهر أدوار جديدة في فريق الاختبار.
الآن عن كل مرحلة بمزيد من التفصيل.
المرحلة 1. يتم إجراء الاختبار بواسطة المطور و / أو المدير
"هل - تحقق من نفسك" - أبسط طريقة "غريزية" للاختبار. شيء شائع في الشركات الصغيرة. عندما لا يكون من الممكن توظيف اختبار احترافي أو لا يوجد فهم للحاجة للاختبار ، فإن واجهة العمل هذه تتم من تلقاء نفسها. اختبار نفسك هو النهج الأكثر عقلانية وإشكالية. هذا هو السبب.
- يقوم المطور نفسه باختبار تلك السيناريوهات التي قام بتطبيقها فقط باستخدام البيانات التي استخدمها في عملية التطوير. مع مثل هذا الاختبار "في فراغ ،" يتم حذف سيناريوهات بديلة. نتيجة لذلك ، تقوم الحياة بإجراء تعديلات وكقاعدة عامة ، تحدث أخطاء للمستخدمين النهائيين.
- إذا كان المدير يختبر ، فحينها يقوم بذلك كعبء إضافي ، دون امتلاك الخبرة وعدم وجود الوقت والقوة المعنوية للانخراط عن كثب في الاختبار. حتى تتمكن من العثور على أخطاء جسيمة ، ولكن يتم التغاضي عن العديد من الفروق الدقيقة.
- الموقف الذاتي للمشروع ، والرغبة في تمريره بسرعة تؤدي إلى إغراء إغلاق أعيننا بعدد من المشكلات التي تبدو "غير مهمة".
حالة متطرفة عندما لا تقوم الشركة بإجراء الاختبارات على الإطلاق ، ويؤدي تقرير الأخطاء إلى ... العميل. تلقى المطور الإصدار ، كل شيء موجود بالفعل في ساحة المعركة ، حسبما ذكر المطور. يفتح العميل المشروع ويرى بعض الأخطاء الشائعة أو خطأ في قاعدة البيانات. ثم المزيد والمزيد من الأخطاء. يصبح العميل اختبار لأمواله الخاصة.
المرحلة 2. يتحقق المختبر من المشروع في النهاية
يعد فحص المشروع بالكامل في مرحلة ما قبل النشر طريقة كلاسيكية عند العمل على نموذج الشلال. ينقسم المشروع إلى مراحل عالمية (في بعض الأحيان يكون المشروع بأكمله عبارة عن مرحلة واحدة). في كل مرحلة ، يتم تصنيع البرامج لأول مرة ، ثم يتم اختبارها فقط. الاختبار موجود بالفعل ، وهذا جيد. ولكن هناك أيضا مشاكل ، ومشاكل محددة للغاية.
أولاً ، عندما نختبر في النهاية ، سيتم العثور على أخطاء خطيرة على مستوى البنية متأخرة جدًا. سيكون من الضروري إعادة جزء كبير ، أو حتى المشروع بأكمله. هذا ليس مفيدًا لأحد.
ثانياً ، في حالة عدم وجود وثائق ، يمكننا فقط إجراء الاختبارات السطحية باستخدام طريقة البحث المجانية. هذا على الفور إيقاف بعض السيناريوهات البديلة. يحدث أن هناك وثائق ، ولكن في هذه العملية ، تتغير المهام ويختلف المنتج النهائي عن الصورة على الورق. مرة أخرى ، هناك صعوبات في اختبار وتحليل تقارير الأخطاء.
ثالثًا ، يتم وضع مشروع تقريبًا في كل وقت تقريبًا كمهمة ذات أولوية. اترك بعض الوقت للتحقق. ولكن لا يوجد وقت لإصلاح الأخطاء ، ونتيجة لذلك ، تؤدي التحسينات المثيرة للإعجاب في بعض الأحيان إلى إبطاء المشروع وتعطيل المواعيد النهائية.
اختبار منفصل للخطوات يثير مشكلة أخرى. بين المراحل ، ينسى المختبر تفاصيل المشروع ، وفي كل مرة يتعين عليه البحث في ما يجري. هذا هو أيضا مضيعة لساعات العمل.
بشكل عام ، يعد التحقق من المشروع في النهاية أمرًا منطقيًا وصحيحًا على ما يبدو ، ولكن هذه الطريقة لا تأخذ في الاعتبار مخاطر اكتشاف الأخطاء العالمية. لذلك ، الاختبار يتطور أكثر.
المرحلة 3. يتم فحص جميع المهام للتأكد من توافقها مع المهمة الأصلية.
علاوة على ذلك ، تدرك الشركة أنه من الأفضل اكتشاف الأخطاء عند تراكمها. لذلك ، نحن ننتقل من نموذج الشلال إلى منهجية Agile. عند هذه النقطة ، يتم دمج المختبرين بشكل أوثق في عملية التطوير. تبدأ جميع المهام في الاختبار المتكرر بشكل متتابع: بشكل منفصل ، كجزء من الإصدار ، في بيئة قتالية.
في هذه المرحلة ، يتم فحص المهام للتأكد من مطابقتها للمتطلبات المحددة. تساعد Agile على العمل بشكل أفضل ، ولكن ليس كل المختبرين ، وخاصة قادتهم ، على استعداد للتواصل مع الاختبار بطريقة جديدة.
يتوقع الرأس السرعة والجودة من المختبرين ، ولكن لا يوجد فهم للحاجة إلى توثيق الاختبار وإجراء اختبار الانحدار. ومن هنا المشاكل النموذجية لهذه المرحلة من التطور.
الاختبار هو أكثر سهولة من منظم. يهيمن مبدأ "ما أراه هو ما أختبره". في كل تكرار ، يتم إجراء اختبارات مختلفة وفي تسلسل مختلف. ونتيجة لذلك ، يمكنك على الأقل تخطي الخطأ في إحدى مراحل الاختبار أو عدم رؤيته على الإطلاق. السيناريوهات البديلة والتغييرات في الوظائف ذات الصلة قد تسقط أيضًا عن الأنظار.
بالإضافة إلى ذلك ، تكمن المشكلة في اختبار الانحدار ، والذي إذا تم تنفيذه ، فهو غير نظامي. في الواقع ، يقوم المحقق بفحص ما يراه ضروريًا أو ما نصحه المطور / المدير بالتحقق منه.
المرحلة 4. ويشارك اختبار في تصميم الاختبار.
في هذه المرحلة ، يدخل تصميم الاختبار إلى المشهد. اختبار تبدأ في إيلاء الاهتمام بوعي لتحليل الاحتياجات. يتم تقسيم الوظيفة إلى كتل منطقية ، والتي تغطيها قوائم الاختيار أو حالات الاختبار.
قائمة التحقق - قائمة الشيكات المطلوبة لاختبار وظيفة. تعد قوائم المراجعة أكثر شيوعًا حيث يسهل تحديثها ، لا سيما كجزء من مشروع ديناميكي كبير.
حالة الاختبار هي سلسلة من الخطوات التي يجب اتخاذها للتحقق من الوظيفة. يرافق وصف كل خطوة مؤشر على السلوك المتوقع للنظام.
تظهر
وثائق اختبار كاملة ، والتي بموجبها يمكنك تتبع كيفية فحص وظيفة معينة. وثائق الاختبار مفيدة ليس فقط للاختبار الأولي ، ولكن أيضًا في اختبارات الانحدار.
كل هذا يسمى تصميم الاختبار. يمكن القول أن الاختبارات المهنية ذات مغزى تبدأ في هذه المرحلة. هذا أكثر من مجرد مجموعة من المهام التي يجب التحقق منها ، ولكنها عملية منظمة لتحليل المتطلبات ، وإنشاء وثائق الاختبار والاختبار المباشر. بما في ذلك تغيير النهج لاختبار البيانات. لم يعد يتم اختراع البيانات تلقائيًا في العملية ، ولكن يتم أخذها من مجموعات معدة مسبقًا.
لا توجد سلبيات واضحة في مرحلة تصميم الاختبار. بشكل عام ، هذا مستوى لائق من الاختبار. لتصميم مواقع الإنتاج أو المشاريع المماثلة ، تصميم الاختبار أكثر من كاف. الشيء الرئيسي هو التعامل مع عملية الاختبار بشكل صحيح: تحليل المنتج ، وإعداد الوثائق وإجراء الاختبارات عليه.
المرحلة 5. يتم تقديم نظام إدارة الاختبار
علاوة على ذلك ، تنمو الشركة إلى الحاجة إلى استخدام أنظمة متخصصة لتخزين حالات الاختبار (قوائم المراجعة) وإجراء عمليات الاختبار.
مثل هذا النظام يسمح:
- متطلبات المتجر وحالات الاختبار ؛
- ربط المتطلبات مع حالات الاختبار
- تحليل تغطية الاختبار ؛
- تخزين إصدارات مختلفة من حالات الاختبار ؛
- أداء الاختبار يعمل
- إجراء تحليل مقارن لتشغيل الاختبار ؛
- الحفاظ على تقارير الاختبار ؛
- تتبع أحمال عمل الفريق لضبط المهام والموارد.
النظام هو دائما خطوة جديدة في التطور. في حالتنا ، أولاً وقبل كل شيء ، يتم تحسين التحكم في عملية الاختبار. نحن ندير الاختبارات بشكل أفضل ونحصل على مستوى جديد من جودة المنتج.
في المراحل الأخيرة من تطوير المشروع ، يساعد مثل هذا النظام جميع المشاركين على تذكر كيفية عمل شيء ما وكيفية التحقق منه. يسرع النظام إدخال مشاركين جدد في المشروع.
المرحلة 6. تتم عمليات الفحص المنتظمة تلقائيًا
في عملية التطوير طويل الأجل للمشاريع ، هناك حاجة لأتمتة عمليات التفتيش الفردية. لهذا ، يكتب المطورون والمختبرون اختبارات تلقائية. عادة ما يقوم المطورون بإجراء اختبارات وحدة ، بينما يقوم الباحثون بإجراء اختبارات واجهة المستخدم. يبدأون بتغطية سيناريوهات إيجابية باستخدام autotests لاستخدام الوظيفة الأساسية: الترخيص والتسجيل ونشر السجلات وما شابه.
يتم تضمين الاختبارات التلقائية المتقدمة في عملية التكامل المستمر (
CI / CD ) ، والتي تسمح للفريق لمعرفة الأخطاء على الفور في وقت الالتزام.
الاختبارات التلقائية تقلل إلى حد كبير تكاليف اختبار الانحدار وتحسين جودة المنتج النهائي. ولكن للقيام بذلك ، تحتاج إلى مستوى معين من اختبار. تجدر الإشارة أيضًا إلى أن الاختبارات الذاتية لا معنى لها في المراحل الأولى من المشروع. يتغير النظام بسرعة ، وبالتالي لتجنب الأخطاء الوهمية ، من الضروري أيضًا تغيير الاختبارات التلقائية التي تستغرق وقتًا طويلاً.
المرحلة 7. يصبح التسلسل الهرمي أكثر تعقيدًا ، وتظهر أدوار جديدة
لقد وصلنا إلى أعلى مراحل التطور ، عندما يكون التسلسل الهرمي في قسم الاختبار معقدًا إلى حد كبير ويظهر اختصاصيون ضيقون: مدير اختبار ، قائد اختبار ، محلل اختبار ، مصمم اختبار ، وما إلى ذلك.
الفريق ينمو ، أصبحت المهام أكثر تعقيدًا. على سبيل المثال ، يعرف
مدير الاختبار أكثر المعلومات عن منتج وينظم الاختبار على مستوى أعلى. يتواصل بشكل متكرر أكثر مع العملاء والتطوير أكثر من التواصل مع فريق الاختبار.
يؤدي اختبار القيادة إلى تنظيم الاختبار على المشروع وتوزيع المهام داخل الفريق.
يشارك محلل الاختبار في تحليل المتطلبات ، وتحللها وتحديد أولوياتها ، وإعداد المواد لتصميم الاختبار والاختبار اللاحق. ويقوم
مصمم الاختبار بتحويل المتطلبات إلى قوائم تدقيق وحالات اختبار.
هناك حاجة إلى أدوار جديدة في المشاريع الكبيرة حيث يعمل فريق كامل من المختبرين. يؤدي ظهور هذه الأدوار إلى عملية اختبار أكثر تنظيماً ، والتي بدونها يستحيل العمل على مشاريع تكنولوجيا المعلومات الكبيرة والمعقدة.
النتائج
درسنا المراحل الرئيسية في تطور الاختبار في الشركة. تبدأ الاختبارات المهنية الواعية من مرحلة تصميم الاختبار. يوفر تصميم الاختبار تحسنا مطردا في جودة المنتج.
عملية تطوير الاختبار ليست دائماً خطية. يمكنك تخطي مراحل معينة أو دمجها أو مزجها أو الانتقال الفوري إلى مستوى أعلى. على سبيل المثال ، في Qualitica لدينا نظام إدارة اختبار ، أي أننا في المرحلة 5. الآن ، في وقت واحد تقريبًا ، لدينا متخصصون ضيقون (أدوار جديدة ، المرحلة 7) والأتمتة (المرحلة 6).
لا يحتاج الجميع إلى نظام إدارة الاختبار ، و autotests ، وحتى أكثر من ذلك مصمم اختبار. ولكن ، في مرحلة الاختبار الغريزي أو حصر أنفسنا في الاختبارات النهائية ، من غير المحتمل القيام بمشاريع معقدة طويلة الأجل. لذلك ، أتمنى لك أن تجد النقطة المناسبة في تطوير الاختبار والوصول إليه من أجل تحسين جودة الاختبار ومنح العملاء منتجًا عالي الجودة.