تحية! اسمي ميشا وأنا كبير ضمان الجودة مع خبرة تجارية لأكثر من 6 سنوات. أنا الآن أعمل في Provectus ، لكنني بدأت مسار اختباري كطالب عندما شاركت في اختبارات ألفا وبيتا لمختلف الألعاب. في مرحلة ما فكرت: "لماذا لا نبدأ في القيام بذلك باحتراف؟" وقبالة نذهب. خلال هذا الوقت ، تمكنت من المشاركة في العديد من المشاريع: من الشركات الناشئة إلى الشركات ، من ألعاب الوحدات التعليمية الصغيرة إلى التطبيقات الضخمة ذات المنطق التجاري القوي.
لكن غالبًا ما تم تقديمي في فرق صغيرة ، حيث كان هناك 5 مطورين للاختبار 1-2 ، وكقاعدة عامة ، كان هناك الكثير من الحرارة في المشروع. في الواقع ، أريد أن أشاطركم كيفية معرفة كيفية فهم مكان وجودك وكيفية البدء في التقدم في صياغة عمليات ضمان الجودة.
بادئ ذي بدء ، يجب أن تفهم المشروع الذي أنت عليه.
بعد اكتساب خبرة من المشاركة في المشاريع ، أقسمها بشكل مشروط إلى ثلاثة أنواع:
- مشاريع دون اختبار.
- مشاريع مع اختبار غير عادل.
- مشاريع الاختبار.
في وقت مشاركتي ، كان كل واحد منهم في مرحلة تطوره. بدأت في مراقبة هذه المواقف وبدأت في تطوير رؤيتي - كيفية تعزيز عمليات الاختبار عليها. بعد بعض الوقت ، عثرت على نموذج النضج ، وألقيت واحدة على واحدة على أساس عملي. عزز هذا اعتقادي أن هذا هو المكان المناسب ليكون.
ما هو نموذج النضج
وهنا أقتبس بذكاء اقتباس من
ويكيبيديا :
تكامل نموذج نضج القدرة (CMMI) - مجموعة من النماذج (المنهجيات) لتحسين العمليات في المؤسسات ذات الأحجام والأنشطة المختلفة. يحتوي CMMI على مجموعة من التوصيات في شكل ممارسات ، يسمح لك تنفيذها وفقًا لمطوري النموذج بتحقيق الأهداف اللازمة للتنفيذ الكامل لمجالات معينة من النشاط.
باختصار وبسيط ، هذه مجموعة من النماذج التي توضح مدى تنظيم العمليات في المؤسسة وفقًا لمعايير معينة. بعد إجراء مثل هذا التقييم ، يمكن للمرء أن يقيّم ما إذا كان الأمر يستحق إعطاء طلب أو آخر لمقاول معين.
في الواقع ، من هذا بدأ تطوير نموذج النضج. في الثمانينات ، أدركت وزارة الدفاع الأمريكية أنها لا تستطيع تقييم جودة عمل مقاولي تطوير البرمجيات بدقة. وبما أن هذا الهيكل الحكومي هو أيضًا على هذا المستوى ، فهذا غير مقبول. هذه الأموال مملوكة للدولة ، والمواعيد النهائية محددة بوضوح ، وسيتيح البرنامج الموثوق للأسلحة الجميع النوم بشكل أكثر سلمية. بناءً على ذلك ، أصدرت الوزارة تعليماتها إلى معهد هندسة البرمجيات لإنشاء مثل هذا النظام التصنيفي وبعد عام من إنشاء الاستبيان الأول ، وبعد 4 سنوات تم إنشاء الإصدار الأول من النموذج.
مستويات نموذج الاستحقاق
هذه هي 5 مستويات ، يتم خلالها تقييم العمل / الموثوقية / استقرار المؤسسة.
حيث في نموذج الاستحقاق هو الاختبار
للمختبرين هناك MM خاص ، ويسمى TMMi. يحتوي أيضًا على 5 مستويات ، أود أن أتطرق إليها بمزيد من التفصيل والنظر في ما هو معتاد لكل منها.
المستوى الأول هو "المبتدئين"في المستوى الأول ، الاختبار ليس منظمًا وفوضويًا. لا توجد بيئة مستقرة لدعم عمليات الاختبار. لا يهتم الفريق بالتخطيط والمعايير.
الهدف الرئيسي هو تسليم المنتج في الوقت المحدد دون مشاكل حرجة ، لأنه يتم استخدام الاختبار هنا فقط لإظهار أن التطبيق يعمل دون أي أخطاء خطيرة. غالبًا ما يعتمد نجاح هذه المشروعات على بطولة ومهارات الأفراد فقط ، وليس على العمليات القائمة.
نتيجة لذلك:
- لا توجد وثائق اختبار ؛
- المنتج غير مستقر
- رفض العمليات أثناء مواقف المشاكل ؛
- الاختبار ليس أكثر من مساعدة تصحيح الأخطاء.
المستوى الثاني - "تكرار"في المستوى الثاني ، يصبح الاختبار عملية محكومة. الانضباط والتقدم المحرز ضمان الحفاظ على هذه الممارسات أثناء الإجهاد. لا يزال يعتبر الاختبار هو النشاط الذي يتبع التطور. يتم تطوير خطط الاختبار وتنفيذها ، والتي تساعد بوضوح في تحديد نوع الاختبار الضروري ومتى ومن قام به.
الهدف الرئيسي هو التأكد من أن المنتج يلبي المتطلبات المحددة.
نتيجة لذلك:
- هناك أنواع وأنواع الاختبار الرئيسية (التكامل ، وحدات ، الانحدار ، القبول) ؛
- تنفيذ خطط الاختبار ؛
- مراقبة أنشطة الاختبار والتحكم فيها ؛
- تم توثيق العملية ويمكن تكرارها.
المستوى الثالث - "محدد"في المستوى الثالث ، لم يعد الاختبار يعتبر نشاطًا يتبع البرمجة. تم دمج الاختبار بالكامل في المشروع. يتم تنفيذ التخطيط للاختبار في المراحل المبكرة ويتم إصلاحه في المخطط الرئيسي. يجري تقديم اختبار غير وظيفي (مثل قابلية الاستخدام).
نتيجة لذلك:
- الاختبار يبدأ مع مرحلة المتطلبات ؛
- إضافة أنشطة تتيح لك العمل بكفاءة أكبر (التدريبات الداخلية ، المراجعات الإضافية) ؛
- يجري اختبار غير وظيفي.
المستوى الرابع - "قابل للقياس"في المستوى الرابع ، يعد الاختبار عملية واضحة المعالم وراسخة وقابلة للقياس. يُنظر إلى الاختبار على أنه تقييم ويتألف من جميع عمليات دورة حياة تطوير البرمجيات. يتم تقديم ممارسة قياس جودة الاختبار. تستخدم هذه القياسات للتنبؤ بالأداء وتكلفة الاختبار.
نتيجة لذلك:
- الاختبار كعملية قابلة للقياس ؛
- تستخدم القياسات للتنبؤ.
- يبحث الفريق عن طرق لجعل عملية الاختبار أكثر كفاءة.
المستوى الخامس - "مبتكر"في المستوى الخامس ، جميع النهج والعمليات راسخة. لا يتوقف الفريق في هذه المرحلة ، لكنه يواصل تحسين العمليات بشكل منتظم ، ويحاول باستمرار تقليل وقت دورة الاختبار والوقت اللازم للسوق دون المساس بجودة المشروع. يركز الاختبار على الوقاية. تتم إضافة الأتمتة لاستخدام أكثر كفاءة للموارد.
نتيجة لذلك:
- تحسين عملية مستمرة ؛
- التركيز على الوقاية والتحسين.
كيف المعرفة بهذا الهيكل يساعد
القضية رقم 1. اختبار غير عادلةبمجرد وصولي إلى مشروع صغير حيث تم إجراء الاختبار بواسطة عميل أو أصدقائه أو قطة. بعد تقييم الموقف والنظر إلى النموذج ، يمكننا أن نفهم أننا في المستوى 1 وأننا يجب أن نركز على المستوى 2 أثناء تخطيط النشاط. بعد وضع ترتيب Jira ، حيث كان هناك عدد كبير من الأخطاء (معظمها مكررة أو غير قابلة للتكرار) ، بدأت في تجميع وثائق الاختبار في شكل قوائم تدقيق وترتيب عمليات الاختبار الأساسية. مثل اختبار الانحدار وفحص التعقل أثناء التغييرات الرئيسية.
القضية رقم 2. دون اختبارفي رأيي ، يمكن أن تكون المشاريع من هذا النوع في ثلاث حالات:
- المشروع بدأ للتو
- لم تكن هناك حاجة لاختبار في المشروع بينما كانت هناك وظائف قليلة ؛
- أغلق فريق مكدس كامل نقص اختبار مع مراجعة رمز الجودة واختبار ديف.
مرة واحدة في أي من هذه المشاريع ، يمكنك أن ترى في كثير من الأحيان فائدة حقيقة أنه في مستوى الصفر السري. يمكننا القفز فوق المستوى الأول وفعل كل شيء على الفور من الناحية النوعية مع شعور جيد ، والشعور ، والترتيب ، تسترشد أهداف الثاني. في كثير من الأحيان يمكننا تنفيذ خطط الاختبار ، على أساسها سيتم تنفيذ جميع أنواع الاختبارات اللازمة. يمكنك التعرف على نفس سير العمل على الفور مع فريق التطوير ، والذي هو مفقود في المشاريع من الحالة الأولى.
القضية رقم 3. كان الاختبارفي الحقيقة ، أندر الحالات: رجل ، بسبب أحداث معينة ، قرر تغيير فريقه / قسمه / عمله ويمنحك أفكاره الخاصة. في هذه الحالة ، لديك بالفعل نظام ثابت من التفاعل مع المطورين ، وهو قاعدة معينة من وثائق الاختبار. قد تتضمن مسارات التطوير الإضافية تحسين العملية المحددة ، أو الانتقال إلى المستوى الثالث - إدخال الاختبار في المراحل المبكرة أو إضافة اختبار غير وظيفي.
حالة رقم 4. ثلاثة في واحدعندما جئت إلى مشروعي في Provectus ، واجهت وضعا لم يكن فيه سوى القليل من الحالات الثلاث المذكورة أعلاه. كما في الحالة رقم 1 ، كان أول شيء فعله هو ترتيب جيرا بالترتيب. كما هو الحال في الحالة الثانية ، فقد تقرر القيام بكل شيء على الفور بجودة عالية من أجل الاسترشاد الفوري بالمستوى الثاني. لذلك ، بدأت على الفور تطوير وثائق الاختبار وتنفيذ أدوات إدارة الاختبار. كما حاولت الضغط أكثر من القطع الأثرية من التكرارات الماضية ، كما كان الحال في الحالة الثالثة.
بعد وقت قصير جدًا ، يمكنني القول بأمان أننا نذهب بالفعل إلى المستوى الثالث - حتى الاختبارات المتصلة في مرحلة متطلبات العمل :)
النتائج
في تجربتي ، يمكن بنجاح نقل معظم المشاريع الأوكرانية ، وكذلك المشاريع التي لم يتم تصميمها لفترة طويلة ، إلى العمل مباشرة في المستوى 3. ولكن إذا كان لديك مشروع طويل الأجل ، فإن إمكانيات تحسينه لا حصر لها ويمكنك أن تسترشد بأمان بإنجازات أعلى المستويات.
في الختام ، أود أن أقول إن الغرض من هذه المقالة هو إظهار ليس فقط كيفية التعامل مع MM الكلاسيكي أو TMM نفسه ، ولكن بمساعدته يمكنك أن تفهم بوضوح في المرحلة التي يشارك فيها المشروع ، و التي الحركات لاتخاذ ، والتي لا تستحق كل هذا العناء. علاوة على ذلك ، مع الأخذ بمبادئه كأساس ، يمكنك إنشاء النموذج الخاص بك ، والذي يمكن تطبيقه ليس فقط في التنمية ، ولكن أيضًا في مختلف مجالات الحياة. والأهم من ذلك - يتم اختباره ويعمل :)