كيفية تنظيم عمل ضمان الجودة. طريقة عملية واحدة

الخلفية

في الآونة الأخيرة ، قام أحد معارفي QA Engineer ، الذي عمل لفترة طويلة في مشروع بطيئ ، حيث تم تحديد مسؤولياتها بدقة ، بتغيير وظيفتها ودخلت في مشروع تم إطلاقه حديثًا. بعد قضاء يومين بدون المهام المشار إليها أعلاه ، وبالملل بصراحة ، ذهبت إلى الإدارة مع سؤال "ماذا علي أن أفعل؟" التي تلقت استجابة ذات مغزى "تنظيم عملك". ثم سقطت في ذهول "وكيف هذا؟" و حقا كيف؟

قبل بضعة أشهر ، غيرت وظيفتي بنفسي ودخلت في مشروع اللغة الإنجليزية الذي لم يكن لديه أي ضمان الجودة من قبل. المشروع نفسه موجود منذ فترة طويلة. كما يحدث غالبًا ، اشترت شركة بها أموال كثيرة شركة تقل فيها الأموال ، ولكن هناك عملاء. نتيجةً لذلك ، استقبلت شركة كبيرة عملاء جدد وناقصًا منافسًا واحدًا في السوق. تلقى مشروعي تغييرًا في مبادئ الإدارة والإدارة.

في الأيام الأولى لمقابلة فريق جديد ، سمعت سؤالًا محيرًا وصادقًا من أحد مطوري مكتب لندن ، "ماذا ستفعل هنا؟"

في الحقيقة ، بعد أن أتيت إلى هذا المشروع ونظرت حولي لعدة أيام ، وقعت في البداية ، مثل زميلي ، في ذهول. ليس لأنني لم أعرف ماذا أفعل. بدلاً من ذلك ، لم أكن أعرف كيف أقحم نفسي بشكل صحيح في الأسس التي تطورت هنا. كان لفريق التطوير وجود رائع بدون اختبار. استخدموا kanban ، ومبادئ التسليم المستمر ، دون خوف ، بهدوء وثقة نشرها في الإنتاج كل يوم تقريبا ، حتى يوم الجمعة. وكل ذلك لأن لديهم تغطية ممتازة مع autotests. ربما أفضل ما قابلت. عند مراجعة طلبات بعضهم البعض ، لم يترددوا في إخبار بعضهم البعض عن الاختبارات التلقائية الأخرى التي يجب إضافتها. قام مؤلف التغيير الحالي بنفسه بنشر أعماله على الإنتاج ، مما يعني أنه كان مسؤولاً مسؤولية كاملة عن عمله. لقد حمله ، على الرغم من حقيقة أنني ظهرت في المشروع ... وقبل النشر ، سيكون من الجيد سماع رأيي.

لكن مع ذلك ، بالطبع ، لم تكن العملية مثالية: لقد حدث أن المطورين لم يفهموا المتطلبات ، والأخطاء التي فُقدت ، وغالبًا ما كانت هناك بعض المشكلات التي تتطلب اتخاذ إجراءات من جانب العملاء.

في مواجهة الحاجة إلى تحديد موقفي في الفريق ، ذهبت أيضًا إلى القيادة. تم بناء حوارنا فقط بشكل مختلف تمامًا ، وليس مثل حوار صديقي.

تنظيم أعمال مهندس ضمان الجودة

اسأل الأسئلة الصحيحة.

هكذا للحوار ، دعوت إلى قيادة والمطورين الرئيسيين للمشروع. هناك قاعدة رائعة للإدارة ، لا يمكنني بالطبع نسيانها: التعبير عن المشكلة ، والتعبير عن خيار حلها ، على الأقل.

ومع ذلك ، كان لدي سؤالان ، الإجابات التي لم أكن أعرفها. أسهل طريقة للبدء معهم.

السؤال الاول ما هو هيكل المنظمة ، أي من يقف على من ومن المسؤول عن ماذا؟

من الناحية المثالية ، ينبغي أن يكون لدى الشركات مخطط مقدم هرميًا يوضح هيكل الشركة. لكنني لست مثاليًا ، لذلك كان من المهم معرفة من لديه الأسئلة والاقتراحات التي يمكنك طرحها.

السؤال الثاني. أدخلت الشركة QA Engineer في المشروع ، ما هي توقعاتهم بالنسبة لي ، ما هي أهدافهم في فتح هذا المنصب؟

عندما تكون الإجابة محددة للغاية ، فإنها تحدد إلى حد كبير واجهة العمل. في حالتي ، احتوت الإجابة على الكثير من العبارات الضبابية العامة ، والتي اعتبرتها "تفعل ما تريد ، ولكن كل شيء على ما يرام معنا".

على هذا ، انتهى الجزء الأول من المناقشة.

نناقش خطة العمل

الجزء الثاني من المناقشات ، وربما الأهم ، كان تقديم خطة عملي وأساسها المنطقي. كنت بحاجة للحصول على نعمة رؤسائي لإدخال نفسي دون عوائق وأنشطتي في المشروع.

من الواضح أن الكتب والنظريات الذكية لا وجود لها من الصفر ، لذا سلّمت نفسي بالمعرفة المكتسبة في التحضير لشهادة ISTQB ، وبمجرد بدافع الفضول ، قرأت كتبًا عن نظرية الاختبار وسكروم ، وأترك ​​هذا كله يمر عبر غربال من عشر سنوات من الخبرة وأعد طيارًا مشروع لاستراتيجية ضمان الجودة.

بعد التفاوض مع الإدارة ودعمه الكامل له ، حصل لاحقًا على تنسيق المستند الرسمي للشركة. بعد ذلك ، أود أن أشارككم أفكارًا حول كيفية إعداد مثل هذا المستند. لقد شكلوا جوهر التجربة السابقة والمسار الذي سافر في المشروع الحالي. وربما ، في شكل علامات اقتباس ، سأعيد طباعة بعض الأجزاء هنا في شكلها الأصلي: باللغة الإنجليزية. أنا متأكد من أنه بالنسبة لكل مهندس ضمان الجودة ، سيكون إعداد مثل هذه الخطة هو الإجابة الرئيسية على السؤال "كيفية تنظيم عملك"

نحن تشكيل استراتيجية ضمان الجودة

1. مقدمة لضمان الجودة

ذكر / قدم مصطلح ضمان الجودة لأول مرة. صدقوني ، فريقك مليء بالأشخاص الذين يتخيلون غامضة للغاية ما هو عليه. يمكن استعارة التعريفات العامة تمامًا من ويكيبيديا . تشير تكتيكياً إلى أن وجود فريق ضمان الجودة في المشروع لا يعني أن كل المسؤولية عن جودة العمل يتم نقلها الآن فقط إليهم:

الاختبار جزء من ضمان الجودة. يسمح لنا بتحديد مستوى جودة الميزة (الميزات) التي نقوم بتقييمها.

ليس من مسؤولية المختبرين وحدهم تنفيذ ضمان الجودة. يمكن للفريق بأكمله ويجب عليه المساهمة في ضمان مستوى عالٍ من جودة المنتجات والخدمات التي يتم تقديمها.

2. مقدمة لاستراتيجية ضمان الجودة

الاستعداد لما سيقرأ المزيد من الناس.

استراتيجية الاختبار هي وثيقة متطورة تفصل العمليات والطريقة التي سنعمل بها لضمان جودة منتجاتنا في المستقبل.

صوت المحتوى. يمكن أن يكون إما مجرد جدول محتويات أو جمل أكثر تجريدية. أذكر هنا وجود منهج الاختبار ، وعملية الاختبار ، واستراتيجية أتمتة الاختبار ، والحاجة إلى خطة اختبار.

هذا مهم. حدد الفاصل الزمني لمراجعة هذا المستند. ويتطور المشروع والعمليات في الشركة ، يجب ألا تتحول هذه الوثيقة إلى ديناصور. لذلك ، ضع خطة لتاريخ مراجعة استراتيجيتك وتغييرها. في رأيي ، ستة أشهر تكفي للعودة بأفكار جديدة.

3. اختبار النهج

ما هو نهج الاختبار؟ بالابتعاد قليلاً عن الصياغة الرسمية الضخمة لهذا التعريف ، أسمح لنفسي بتبسيطه على فرضية أن هذه "أفكار أساسية نبدأ العمل بها كل يوم". اكتب هنا: ما هو محرك تقدمك؟

كلاسيكيات النوع والنهج الجيدة تعمل "استباقية" و "قائمة على المخاطر".

سوف نعتمد نهج اختبار استباقي وقائم على المخاطر.

استباقي - وهذا يعني أن عملية تصميم الاختبار قد بدأت في أقرب وقت ممكن من أجل إيجاد وإصلاح العيوب قبل إنشاء الإنشاء.

قائم على المخاطر - وهذا يعني أننا سنقوم بتنظيم جهود الاختبار الخاصة بنا بطريقة تقلل من مستوى مخاطر المنتج عندما يشحن النظام. وفقًا لمناهج ISTQB ، "الاختبار القائم على المخاطر هو فكرة أنه يمكننا تنظيم جهود الاختبار لدينا بطريقة تقلل من المستوى المتبقي لمخاطر المنتج عندما يشحن النظام. يستخدم الاختبار المستند إلى المخاطر تحديد الأولويات والتأكيد على الاختبارات المناسبة أثناء تنفيذ الاختبار ، ولكنه يتعلق أكثر من ذلك. يبدأ الاختبار المستند إلى المخاطر في وقت مبكر من المشروع ، وتحديد المخاطر على جودة النظام واستخدام تلك المعرفة بالمخاطر لتوجيه تخطيط الاختبار والمواصفات والتحضير والتنفيذ. يشتمل الاختبار المستند إلى المخاطر على كل من التخفيفين - الاختبار لتوفير فرص لتقليل احتمالية حدوث العيوب ، خاصة العيوب عالية التأثير - والطوارئ - لتحديد الحلول البديلة لجعل العيوب التي تجعلنا نتجاوز الألم. يتضمن الاختبار القائم على المخاطر أيضًا قياس مدى نجاحنا في العثور على العيوب وإزالتها في المناطق الحرجة »

عندما نتحدث عن أن تكون استباقية ، يجب علينا أولاً وقبل كل شيء التحدث عن مواصفات متطلبات مراقبة الجودة. إن المديرين الذين يقومون بتجميع مواصفات عناصر دورة التطوير التالية ، بالنسبة للجزء الأكبر ، يفكرون كمستخدمين عاديين للنظام ، بينما يوجد منطق أفكار المطورين في بعد آخر. أولاً ، لقد رأيت أكثر من مرة أن مطورًا ، يقرأ أحد المواصفات ، لا يمكنه ترجمته إلى لغة برمجة. على سبيل المثال ، لا يمكن أن يطابق المستخدم المذكور في المواصفات مع الأدوار / حقوق الوصول الموجودة في النظام. نتيجة لذلك ، يمكنه اختيار الدور الأنسب ، في رأيه الشخصي ، والذي سيتحول إلى خطأ وسيضطر إلى العودة إلى العمل في وقت لاحق وفقدان الوقت ؛ أو طرح سؤال على المدير ، الذي ربما ذهب في إجازة ويفقد مرة أخرى تحسباً. QA Engineer هي تلك الطبقة الرائعة بين المدير الذي يركز على المستخدم والمطور ذي التفكير الفني ، خاصةً إذا لم يهمل QA Engineer اختبار الصندوق الأبيض. نحن قادرون على فهم المديرين وترجمة أفكارهم للمطورين. في الوقت المحدد

الاختبار القائم على المخاطر له طرق رسمية مثيرة للاهتمام لتقييم مخاطر المشروع ومخاطر المنتج. من الرائع أن تكون قادرًا على تطبيقها. لكن شخصياً ، ليس لدي وقت كافٍ لرسم احتمالات حدوثها ، وشدة عواقبها ، إلخ. وحساب المخاطر وفقا لجميع القواعد. أنا هنا أعتمد بشكل كامل على غرائزاتي وحسابي السليم. عند اختبار أو تغطية الاختبارات التلقائية مع وجود منطقة خطر (ما ينبغي إيلاء الاهتمام الأول والأهم) بالنسبة للجزء الأكبر:

• وظيفة مصممة مباشرة
• المناطق المجاورة والتفاعلية
• وظيفة مهمة تجاريا
• ما يكسر في معظم الأحيان
• التوافق مع الإصدارات السابقة (على سبيل المثال ، إذا تم تغيير تنسيق البيانات الأولية ، فهل ستنجح وظيفة البيانات الحالية)

4. عملية الاختبار

أخبرنا بالتسلسل المنهجي للعمل الذي تخطط للانضمام إليه. لم أخترع أي شيء معقد ، لكنني أخذت الفكرة من ISTQB واستخدمها .

إذا ذهبت في طريقي ، تعرف على تسلسل العمل الموصى به من قبل مؤلفي ISTQB ، وكن على دراية بالخطوات التي ستتخذها وكيف. نبدأ مع التخطيط والسيطرة. هذان يعيشان معا لأن على أساس مراقبة أنشطتها الخاصة ، يمكن إعادة رسم الخطط بانتظام. بعد ذلك ، يمكنك العمل مع الوثائق وكتابة حالات الاختبار ، وتشغيلها (باستخدام بيانات الاختبار المخططة وبيئة مناسبة) ، واستكمال الاختبار والتنظيف بعده (حذف الملفات المؤقتة ، وما إلى ذلك)

سوف نستخدم عملية الاختبار الموضحة في منهج ISTQB على مستوى المؤسسة: تخطيط الاختبار والتحكم ، تحليل الاختبار وتصميمه ، تنفيذ الاختبار وتنفيذه ، تقييم معايير الخروج والإبلاغ ، وأنشطة إغلاق الاختبار.

5. المسؤوليات

حدد مسؤولياتك ومسؤوليات الآخرين في مجال تحسين جودة المنتج. تقرير مهمتك.

أولاً ، التأكيد مرة أخرى على أن كل عضو في الفريق هو اختبار في حد ذاته ، حيث يقوم الجميع باختبار ما يتعلق بهم . كتب الكود - اختبره.

ثانياً ، قم بتوضيح وفهم اتجاه التطوير المستمر لديك. QA Engineer هو الخبير الرئيسي في وظائف المنتج : فهو يعرف كيف وماذا يعمل ، وهو قادر على شرح كيف وما الذي يجب اختباره. إنه شخص يتنبأ بالسلوك التشغيلي للعميل ، مما يعني أنه لن يسمح بتطور المشكلات الخطيرة.

ثالثًا ، حدد كيفية تفاعلك مع المديرين والمطورين . على سبيل المثال ، توقف عند نهج amigos الثلاثة الرشيق

التعاون بين الأعمال والتطوير وضمان الجودة
أ. الأعمال - ما المشكلة التي نحاول حلها؟
ب. التنمية - كيف يمكننا بناء حل لحل هذه المشكلة؟
ج. اختبار - ماذا عن هذا ، ما يمكن أن يحدث

6. مستويات الاختبار واستراتيجية أتمتة ضمان الجودة

اليوم ، أصبح هذا القسم وثيقة منفصلة مكتفية ذاتيا بالنسبة لي. ولكن على المستوى التنظيمي لعملية ضمان الجودة الوليدة في الفريق ، أشر إلى أنواع الاختبارات التي سيتم تنفيذها من قبل من. ما الذي سيتم القيام به يدويًا ، وما الذي سيتم تشغيله تلقائيًا ، وبأي مبدأ. من هو المسؤول عن أي autotests.

على سبيل المثال ، في المشروع الحالي ، أكتب الاختبارات الشاملة فقط ، والتي يعد التشغيل السلس لها ذا أهمية استراتيجية من وجهة نظر العمل. في الوقت نفسه ، ألق نظرة على طلب السحب من المطور ، وإذا لزم الأمر ، أقدم توصيات بشأن تغطية الاختبار. كل ما تبقى (الوحدة ، التكامل ، الحمل ، إلخ) هو عمل للمطورين. في المشروع السابق ، كان اختبار الحمل على عاتقي وكتبت اختبارات التكامل مع المطورين.

7. ميزة سير العمل

اليوم ، يعمل مشروعي على Scrum باستخدام سباق لمدة أسبوعين. لذلك ، لدي وثيقة دورة حياة مكتوبة خطوة بخطوة لكل قصة.

أياً كانت المنهجية التي يلتزم بها المشروع ، صف كيفية القيام بالعمل اليومي خطوة بخطوة. إذا تحدثنا أعلاه عن تكتيكات العمل ، فيجب أن تكون هناك مؤشرات واضحة لما يأتي أولاً ، ثم ماذا.

على سبيل المثال ، روايتي هي

تفاصيل سير العمل أدناه العملية التي سنعتمدها داخليًا.
1. الحصول على قصة قبل جلسة التخطيط
2. إنشاء قائمة مرجعية وفقا لمعايير القبول والوصف
3. لاحظ تفاصيل / أسئلة غير واضحة
4. توضيح الأسئلة حول التخطيط
5. تحديث المرجعية
6. تسليط الضوء على أي التبعيات وكيفية التغلب عليها
7. عندما تكون القصة قيد المراجعة ، تحقق مما إذا كانت معايير القبول مغطاة بواسطة اختبارات تلقائية
8. شجع المطور على تغطية جميع معايير القبول باستخدام الاختبارات التلقائية أو القيام بذلك بنفسك
9. عندما تكون القصة جاهزة للاختبار ، قم بإجراء اختبار يدوي باستخدام قائمة المراجعة
10. إنشاء أخطاء للقصة إذا كانت موجودة وإعادة العنصر إلى التطوير
11. عندما يتم إصلاح الأخطاء ، قم بإجراء اختبار يدوي باستخدام قائمة التحقق مرة أخرى
12. تحقق مما إذا تم تمرير جميع autotests
13. إنشاء مهمة لتنفيذ autotests التكامل إضافية إذا لزم الأمر
14. نقل قصة في ولاية مرت QA

8. خطة الاختبار

اختر نوع خطة الاختبار ، والنظام الأساسي الذي ستقوم بتخزينه عليه والغرض من وجوده. توفير وسيلة لأي شخص للنظر هناك.

في هذا المشروع ، خطة الاختبار الخاصة بي عبارة عن مجموعة من قوائم المراجعة لكل قصة. مع المستوى الحالي للأتمتة ، هذا يكفي الآن.

في المشروع السابق ، تم استخدام خطة الاختبار للاختبار اليدوي الشامل وكقاعدة أيديولوجية للاختبارات الذاتية المستقبلية.

إذا كان لديك الكثير من الاختبارات اليدوية ، فاكتب حالات الاختبار بالتفصيل ، حتى يتمكن أي مهندس جديد لضمان الجودة ، بعد قدومه إلى المشروع ، من القيام بها بشكل مستقل.

كيفية العمل مع وثيقة

كتابة هذه الخطة بأكملها والكلمات الفعالة رائعة جدًا. السلطات سوف نقدر ، ليس لدي شك. ولكن هناك نقطة واحدة مهمة في وجود هذه الوثيقة. هذه إجابات صادقة على أسئلة لمن ولماذا كل هذا مكتوب؟

عند كتابة كل جملة ، سيكون من الجيد التفكير في الأسئلة: "هل أريد حقًا العمل مثل هذا؟" ، "هل سأحضر هذا المشروع إلى الحياة؟"

إذا كانت كلا الإجابات إيجابية ، فقم بالطباعة بثقة.

إذا كان أحد الإجابات هو "لا" ، في رأيي ، هذه علامة أكيدة على عدم تعليق الواجبات غير الضرورية.

إذا كانت إحدى الإجابات من سلسلة "لا أعرف حتى الآن" ، فدعها تعيش على صفحاتك الآن.
بقيت مثل هذه اللحظات على قائمة ما سيتم مراجعته أولاً في غضون بضعة أشهر.

بادئ ذي بدء ، كتبت وثيقتي بنفسي. لدي لحظات عندما أتراجع عن العمليات الموصوفة وأذهب ضدهم قليلاً. التكيف مع الموقف من أجل استخدام الموارد بكفاءة هنا والآن أمر طبيعي. لكن الغالبية العظمى ، مع العمل الروتيني المعتاد ، المستند الخاص بي هو كتابي الإرشادي. لقد كنت مقتنعًا أكثر من مرة أن الخطة / الاستراتيجية الحالية في أي مجال تقرب دائمًا من النتائج المرجوة بشكل أسرع وبألم أقل من افتقارها التام. أتمنى لك أن تبني عملك بسهولة وكفاءة!

قبل النشر نفسه ، تم تقليص المقالة إلى حد كبير ، بدا لي أنها كبيرة بالنسبة لـ Sandbox. سأكون سعيدًا بمتابعة هذا الموضوع لاحقًا. ومع ذلك ، يسعدني دائمًا التطوير ، إذا كان هناك شيء نسيته تمامًا ، فيرجى كتابة تعليق.

شكرا لك