V&V ليس للثأر

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

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

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

FDA

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

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

ما هي ادارة الاغذية والعقاقير فيما يتعلق بما نقوم به وكيف تؤثر على عملية التطوير ودورة الإصدار؟

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

في الواقع ، لا تهتم إدارة الأغذية والعقاقير (FDA) عمليًا بعملية التطوير نفسها ، فنحن نعمل وفقًا لـ SCRUM المعتاد (أن نكون صادقين ، إنه ليس SCRUM تمامًا - يقولون أنه من المألوف الآن تسمية هذه العملية بـ "SCRUM معدلة") مع دورة إطلاق العدو. نحن لا نوفر الإنتاج في نهاية كل سباق (وحتى في نهاية ثلاثة سباق ، وحتى عشرة إذا كان الخط الزمني يتضمن 15 سباقًا) ، أي من وجهة نظر التسليم إلى المستخدم النهائي ، لدينا منهجية تشبه الشلال.

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

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

V & V

ما هو V&V ، وكيف يؤثر هذا على عملية القبول.

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

بمعنى آخر:
التحقق: هل نفعل المنتج بشكل صحيح؟
التحقق من الصحة: ​​هل نصنع المنتج المناسب؟

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

• SIT - اختبار تكامل النظام
• UAT - اختبار قبول المستخدم

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

عندما لا تكون التغطية المطلوبة مطلوبة؟

على سبيل المثال ، يحتوي CFR Part 11 ( قواعد FDA للسجلات الإلكترونية والتوقيعات الإلكترونية ) على الكثير من المتطلبات التي تمت تغطيتها بالفعل في Microsoft ، لذلك إذا استخدمنا Windows AD للمصادقة ، فلن نحتاج إلى تغطية هذه المتطلبات مرة أخرى.

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

الأدوار

يشارك عدد كبير جدًا من الأدوار في هذه العملية ، وهي مألوفة بشكل أو بآخر لجميع المشاركين في تطوير البرمجيات: مطور (مبتدئ ، متوسط ​​، كبير ، رصاصي) ، وحدة اختبار ، SIT Tester ، مالك منتج فني ، منتج أعمال مالك ، ماجستير سكروم ، مدير مشروع ، محلل أعمال ، قائد تقني ، قائد اختبار SIT ، قائد اختبار UAT ، مراقبة الجودة العالمية ، الدعم ، مهندس النشر وغيرهم.

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

وثائق القبول

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

خطة التحقق من الصحة وقائمة الفريق - مسؤول عن إنشاء المستندات والموافقة عليها. تتضمن الوثيقة عادةً وصف النظام وقائمة الأدوات الفنية للتطوير والاختبار واستراتيجية التحقق وقائمة الأدوار والمسؤوليات.

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

تتضمن خطة الاختبار - الشائعة لفرق UAT و SIT ، وصفًا موجزًا ​​لكائن الاختبار والقيود المحتملة ومتطلبات البيئة والتوقيت ومجموعات الاختبار وما إلى ذلك.

مجموعة الاختبارات - مجموعة من الاختبارات أو قوائم المراجعة التي شكلتها المنطقة الوظيفية أو نوع الاختبار أو أي خصائص أخرى.

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

PDS - مواصفات تصميم المنتج أو Tech Lead أو System Architect هي المسؤولة عن إنشاء المستندات. في الواقع ، إنه نوع من مزيج من مستندات الهندسة العالية والمنخفضة المستوى (HLA و LLA).

FRS و URS أو BRS - المتطلبات الوظيفية ومتطلبات المستخدم. عادة ، هناك وثيقتان منفصلتان ولكن في بعض الأحيان توجد مواصفات متطلبات العمل والتي تتضمن كلا المواصفات.

سجل العيوب - سجل الأخطاء المحددة في التطبيق و / أو المتطلبات خلال SIT الرسمي.

سجل المشكلات الثانوية - سجل التغييرات الطفيفة في البرامج النصية للاختبار (الأخطاء المطبعية ، متطلبات اليسار أو الزائدة ، أي أخطاء).

تقرير ملخص الاختبار - تقرير عن نتائج مرحلة الاختبار ، والذي يتضمن ما يلي:

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

تتضمن خطة النشر - وهي الوثيقة التي يتم استخدامها للنشر إلى الإنتاج ، وصفًا لنسخ الاستعادة.

تقرير ملخص التحقق من الصحة - المستند الختامي لخطة التحقق من الصحة.

الموافقة على الوثائق

يمكن تقسيم أي عملية موافقة على الوثائق إلى 3 مراحل:

• إعداد المستند.
• الاستعراض.
• موافقة عليها.

لنلقِ نظرة على مثال مجموعة الاختبارات.

لكتابة نصوص اختبار ودمجها في مجموعات اختبار ، نستخدم قالبًا قياسيًا معتمدًا من جانب العميل.

فقرات مجموعة الاختبار:

• اسم المشروع والتطبيق.
• نسخة الإصدار.
• اسم المعرف الفريد للجناح.
• الوصف (ماذا نختبر وأنواع الاختبارات التي نستخدمها).
• اختبار البرامج النصية.
• قائمة بالموافقين.

بدوره ، يتكون كل اختبار من:

• الاسم والمعرف الفريد للبرنامج النصي للاختبار.
• الوصف.
• شروط مسبقة.
• Postconditions.
• مراجع التتبع.
• تعليمات التنفيذ (مثل تعليمات كيفية إخفاء البيانات الحساسة).
• خطوات (الإجراء ، النتائج المتوقعة والملاحظة).
• نتيجة اختبار البرنامج النصي.
• اختبار.
• المعلقين.

تشبه دورة الحياة الطبيعية للاختبار شلال وتبدو كما يلي:

1. كتابة
   تحليل الاحتياجات. تعريف وتطبيق تقنيات تصميم الاختبار للحصول على تغطية مناسبة للوظائف. خطوات الكتابة.
2. يعمل الجاف على بيئة ديف
   في هذه المرحلة ، نحاول العثور على كيفية تلبية التطبيق للمتطلبات ، والعثور على معظم الأخطاء المحتملة ، بما في ذلك أخطاء المتطلبات.
3. مراجعة الشخص المسؤول (قائد فريق SIT)
   مراجعة الأسلوبية والمنطقية.
4. يعمل الجاف على بيئة الجلوس
   في هذه المرحلة ، يتم اكتشاف الأخطاء المرتبطة بالتثبيت والبيئة وتكوين البيئة (بشكل افتراضي ، نفترض أن بيئة SIT تكرر تمامًا أو تقريبًا بالكامل PROD). الإكمال الناجح لهذه المرحلة يعني أن النسخة التي تم نشرها مستقرة ويمكن اعتبار الإصدار مرشحًا.
5. مراجعة العملاء (مراقبة الجودة العالمية)
   تتحقق Global QC من تلبية المتطلبات وأن الاختبارات التحريرية تتوافق مع إجراءات التشغيل الموحدة للشركة.
6. الموافقة (مراقبة الجودة العالمية ، البريد الفني ، صندوق بريد الأعمال).
7. التنفيذ الرسمي للاختبار النصي على بيئة SIT (إصدار مرشح الإصدار)
   بعد الموافقة على اختبارات التنفيذ (الصفحة 6) والانتهاء الناجح للعمليات الجافة على بيئة SIT (الصفحة 4) ، يتم تنفيذ الاختبار رسميًا على بيئة SIT مع التثبيت الرسمي للنتيجة. إذا كانت الأخطاء الموجودة في ممرات التشغيل الجاف غير رسمية وتم إدخالها ببساطة في Jira على غرار ما يحدث أثناء عملية التطوير ، يتم إنشاء نموذج خلل منفصل لكل خطأ موجود في التنفيذ الرسمي ، والذي يتم تضمينه في وثائق الإخراج حزمة للمنتج.
8. اختبار مراجعة تنفيذ البرنامج النصي (SIT Team Lead).
   نفس الشيء إلى النقطة 3.
9. مراجعة العملاء (مراقبة الجودة العالمية)
   يتحقق Global QC من صحة واكتمال ملء النتائج والأخطاء المحتملة ووجود الأدلة (على سبيل المثال ، لقطات الشاشة). نقطة مهمة ، لأنها Global QC هي المسؤولة عن توفير حزمة من المستندات للتدقيق الخارجي (بواسطة إدارة الأغذية والعقاقير أو العملاء).

العمل مع البيانات الشخصية

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

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

ولكن حقيقة أن هذا هو أقل مشاكلنا لا يعني أنه لا يمكن أن يسبب المتاعب. إليك بضع مكابس (لا نخطو مرتين) حصلنا عليها في مشاريعنا:

قد تكون ممتعة (ليس لنا في تلك اللحظة): "The Globe"

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



الأخلاقية: لا تلمس البيانات قبل ساعتين من العرض.

قصة رقم اثنين: "حول إخفاء الهوية"

الخلفية: يتم جمع البيانات في المستودع من عدد كبير من المصادر ، تنتمي البيانات إلى مجالات مختلفة ، ولكن يتم ربطها بواسطة معرفات.

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

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

سير العمل الإلكتروني مقابل الورق في الممارسة العملية

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

الفوائد:

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

سلبيات (خصيصا لـ HP ALM):

• كمية كبيرة من الوقت لتنسيق البرامج النصية.
• مشاكل دورية مع الأداة نفسها.
• ليس أفضل المدقق الإملائي.
• واجهة غير مريحة.
• الوقت الذي تقضيه في كتابة ومراجعة الاختبارات هو نفسه عملياً نفس الاختبارات في Word.
• التكلفة.

قصة حقيقية تتعلق بالأوراق والتوقيعات اليدوية: "كابوس قبل الإصدار"

في إحدى الأمسيات كتبت 450 مرة: "يتوافق لون النقاط على الرسم البياني مع اللون المذكور في المتطلبات. اللقب والاسم والتاريخ ووضع التوقيع - ببساطة لأننا طبعنا على طابعة أبيض / أسود ولون النقاط على الرسوم البيانية ذات أهمية.



الأخلاقية: يجب أن يكون اختيار الوسائل متسقًا مع الأهداف.

قصة أخرى: "ثقيلة جيدة ، ثقيلة موثوق بها." ©

يتعلق سير عمل الورق بالورقة (من يشك في ذلك). قد تكون مرحلة اختبار القبول لواحد بعيد عن أكبر تطبيق حوالي خمسة كيلوغرامات من الورق.



الاستنتاج الذي يقترح نفسه من القصص أعلاه (والعديد من القصص التي لم يتم سردها): على الرغم من عيوب سير العمل الإلكترونية المدرجة وغير المدرجة - إذا كان يمكنك الاختيار ، فبالتأكيد اختر إلكترونيًا ، حتى لو كان HP ALM (وليس HP بعد الآن).

أتمتة

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

كيف ولماذا توصلنا إلى أتمتة جزئية على الأقل؟

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

الشيء الثاني هو أن يشرح للعميل أنه سيكسب الوقت وأنه سيكون موثوقًا ومقبولًا بما فيه الكفاية من وجهة نظر رسمية. يتم التحكم في الصناعة وهناك أسباب لذلك.

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

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

قائمة الأسئلة في حالتنا:

1. هل من الممكن أتمتة الاختبار في هذه الحالة بالذات؟
2. هل هو عنصر * مستقر؟
3. كم مرة نحتاج إلى تنفيذ البرامج النصية للاختبار لهذا المكون؟
4. هل هي وظيفة مهمة للأعمال؟ **
5. ما مدى صعوبة أتمتة الاختبار؟

* مستقر = لم يتغير المكون لبعض الوقت ولم يتم تخطيط تغييرات المكون للإصدارات القادمة.
** يتم ملؤها اعتمادًا على قيمة الحقل المضافة إلى متطلبات محلل الأعمال.


بشكل عام ، عملية صنع القرار هي كما يلي:

1. في المدخلات ، لدينا متطلبات من FRS.
   ننشئ مصفوفة تصميم ، حيث يكون كل صف هو متطلبات FRS ، والأعمدة هي:
   
   • وصف الشرط
   • الأسئلة 1-5
   • قرار الفريق
   • تقدير تقريبي
   • موافقة
   • تعليقات
2. يضع الفريق إجابات على الأسئلة وعلى أساس البيانات المستلمة يحدد ما إذا كان الأمر يستحق أتمتة الاختبار لمتطلبات / مجموعة محددة من المتطلبات بالكامل أو جزئيًا.
3. يراجع العميل الحل المقترح ويوافق على الإصدار النهائي.
4. بعد الموافقة على مصفوفة التصميم ، تتم كتابة الاختبارات التلقائية. تتم كتابة البرامج النصية للاختبارات التلقائية في تدوين Gherkin وتخضع لمراجعة مماثلة لتلك الخاصة بالاختبارات اليدوية (Global QC ، المالك الفني ، مالك العمل). تتم مراجعة تعريفات الخطوات ، كائنات الصفحة ، وما إلى ذلك ، بناءً على طلبات السحب ، بما في ذلك من قِبل متخصص تقني من جانب العميل. تتم مراجعة نتائج Autotest والتقارير التي تم إنشاؤها واعتمادها على الجانب العالمي لمراقبة الجودة.

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

استنتاج

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