على مدار السنوات الست الماضية ، قمت بتطوير وقبول اختبار مجموعة متنوعة من التطبيقات من حيث التعقيد والحجم لإجراء التجارب السريرية والحفاظ عليها. البيانات الضخمة ، وعدد كبير من التصورات والآراء ، وتخزين البيانات ، ETL وما شابه ذلك. يتم استخدام المنتج من قبل الأطباء والإدارة والأشخاص الذين يشاركون في مراقبة ومراقبة البحوث.
بالنسبة للتطبيقات التي لها أو قد يكون لها تأثير مباشر على حياة وصحة المرضى ، يلزم إجراء عملية اختبار قبول رسمية. يتم تقديم نتائج اختبار القبول إلى جانب بقية حزمة الوثائق للمراجعة إلى إدارة الأغذية والعقاقير (إدارة الغذاء والدواء ، الولايات المتحدة الأمريكية). إدارة الغذاء والدواء الأمريكية تسمح باستخدام التطبيق كأداة لرصد وإجراء التجارب السريرية. في المجموع ، طور فريقي واختبر وأرسل إلى الإنتاج أكثر من ثلاثين تطبيقًا. في هذه المقالة ، سأتحدث باختصار عن اختبار القبول وتطوير الأدوات في مجموعة صغيرة واحدة.
ملاحظة: أنا لا أدعي أنها الحقيقة المطلقة وأتفهم أن معظم ما أكتب عنه هو دليل الكابتن مونولوج. لكن آمل أن يثبت الموصوف أنه مفيد لكل من مستوى الدخول والفرق التي تواجه هذا في عملهم اليومي ، أو على الأقل إرضاء أولئك الذين لديهم عمليات أكثر بساطة.
FDA
تُعد الدراسات السريرية حول العالم خطوة أساسية في تطوير الأدوية ، والتي تسبق تسجيلها واستخدامها الطبي على نطاق واسع. في التجارب السريرية ، تتم دراسة عقار جديد للحصول على بيانات حول فعاليته وسلامته. ويكيبيديا
وبعبارة أخرى ، من أجل الوصول إلى حبة "من الرأس" إلى صيدلية في مكان ما في برايتون بيتش ، يمر عبر ثلاث مراحل من التجارب البشرية ، يتم خلالها تحديد مقدار المادة الفعالة التي يجب احتواؤها في الجهاز اللوحي ، ومدى أمانها ، وما إذا كانت تلتئم على الإطلاق الصداع.
ما هي إدارة الأغذية والعقاقير بالنسبة لنا وكيف تؤثر على عملية التطوير ودورة الإصدار؟
إدارة الغذاء والدواء (FDA ، USFDA ، رسالة. "إدارة الغذاء والدواء") هي وكالة تابعة لوزارة الصحة والخدمات الإنسانية الأمريكية ، وهي إحدى الإدارات التنفيذية الفيدرالية. يتمثل القسم في مراقبة جودة المنتجات الغذائية ، والمستحضرات الصيدلانية ، ومستحضرات التجميل ، ومنتجات التبغ وبعض فئات السلع الأخرى ، كما يراقب الامتثال للتشريعات والمعايير في هذا المجال. ويكيبيديا
لا تتعلق إدارة الأغذية والعقاقير (FDA) عمليًا بعملية التطوير نفسها ، فنحن نعمل على SCRUM المعتادة (أو بالأحرى ، لا SCRUM تمامًا - يقولون إنه من المألوف الآن تسمية مثل "SCRUM المعدلة") مع دورة إطلاق غير سباق. لا نذهب إلى المنتج في نهاية سباق العدو (وحتى في نهاية ثلاثة سباق ، وحتى عشرة إذا كان الخط الزمني يتضمن 15 سباقًا) ، أي من وجهة نظر التسليم إلى المستخدم النهائي ، لدينا شيء يشبه الشلال.
ينقسم الاختبار في حالتنا إلى جزأين مستقلين ، بهما جداول زمنية مختلفة وتقديرات مختلفة وعمليات مختلفة. الجزء الأول هو الاختبار المألوف في التطبيق ، حيث يكون المختبر جزءًا لا يتجزأ من فريق التطوير وينتهي من سباق السرعة مع التطوير. الجزء الثاني هو اختبار القبول الفعلي والصيانة (عند الحاجة). تم بناء العملية وفقًا لمنهجية V&V: متطلبات المستخدم والمتطلبات الوظيفية عند المدخلات والاختبارات ومجموعة من الوثائق الداعمة في المخرجات.
تعتمد دورة الإصدار على حجم العمل ، والإصدارات بشكل عام لا تمر بالتكرار. بعد الإصدار ، يمكن أن يظل التطبيق بدون تغيير لفترة طويلة ، أي فاصل بين الإصدارات - من شهرين إلى سنة أو أكثر.
V & V
أي نوع من الحيوانات هذا ، V&V ، وكيف ينعكس هذا في عملية القبول.
في إدارة مشاريع البرامج ، يعد اختبار البرمجيات وهندسة البرامج والتحقق من صحتها (V&V) بمثابة عملية للتحقق من أن نظام البرنامج يفي بالمواصفات وأنه يفي بالغرض المقصود منه. قد تتم إحالتها أيضًا إلى مراقبة جودة البرنامج. عادة ما تكون مسؤولية اختبار البرامج كجزء من دورة حياة تطوير البرمجيات. بعبارات بسيطة ، التحقق من البرنامج هو: "على افتراض أننا يجب أن نبني X ، هل يحقق برنامجنا أهدافه دون أي أخطاء أو ثغرات؟" من ناحية أخرى ، فإن التحقق من صحة البرنامج هو: "هل كان X ما يجب أن نبنيه؟ هل يلبي X المتطلبات عالية المستوى؟ » ويكيبيديا
ترجمة مجانية:
"في إدارة المشاريع ، يعد الاختبار وتطوير البرامج والتحقق من صحتها (V&V) عملية التحقق من أن البرنامج المطوّر يلبي المواصفات ويؤدي وظيفته المقصودة. ويمكن أيضا أن يعزى إلى مراقبة الجودة بشكل عام. عادةً ما يكون مهندسو الاختبار مسؤولين عن التحقق من دورة حياة تطوير البرامج والتحقق من صحتها. بعبارة بسيطة ، يمكن وصف التحقق من البرنامج على النحو التالي: "لنفترض أنه يتعين علينا تطوير النظام X. هل حققنا الهدف دون أي أخطاء أو افتراضات؟" من ناحية أخرى ، فإن التحقق من صحة البرنامج هو "النظام المطور X هو حقًا شيء ماذا نريد أن نحصل عليه؟ هل يلبي النظام X المتطلبات عالية المستوى؟ "
بمعنى آخر:
التحقق: هل نفعل المنتج بشكل صحيح؟
التحقق من الصحة: هل نصنع المنتج المناسب؟
هذا يعني أنه يجب علينا اختبار المواصفات الوظيفية ومواصفات المستخدم مع الاكتمال اللازم والكافي. بالنسبة لنا ، يتحول الخامس الأول إلى اختبار القبول (SIT) ، والثاني إلى صيانة (UAT) ، حيث:
- SIT - اختبار تكامل النظام
- UAT - اختبار قبول المستخدم
يتم تنفيذ تغطية المتطلبات في مصفوفة التتبع (جدول منتظم في Excel أو Word ، وسأتناولها لاحقًا) ، مما يسمح بالتتبع من المتطلبات إلى الاختبار والعكس. في حالة استخدام الإدارة الإلكترونية للوثائق ، تم تصميم المصفوفة تلقائيًا ، وترتبط الاختبارات بالمتطلبات التي يتم تخزينها مع الاختبارات (معًا = HP ALM ، وبطبيعة الحال لا يتم تخزين مجموعة منها). في حالة عدم تغطية الشرط ولن يتم تغطيته ، سنشرح لك السبب.
متى تكون متطلبات التغطية غير ضرورية؟
على سبيل المثال ، يحتوي CFR Part 11 (
القواعد التي وضعتها FDA فيما يتعلق بالسجلات الإلكترونية والتوقيعات الإلكترونية ) على عدد كبير من المتطلبات التي تغطيها بالفعل Microsoft وإذا استخدمنا Windows AD للمصادقة ، فلن نحتاج إلى تغطيتها مرة أخرى.
في نهاية المطاف ، يكمن جوهر اختبار القبول في اختبار المنتج للتأكد من توافقه مع متطلبات ومتطلبات توافق المنتج.
دور
يشارك عدد كبير جدًا من الأدوار في هذه العملية ، وهي مألوفة بشكل أو بآخر لجميع المشاركين في تطوير البرمجيات: مطور (مبتدئ ، متوسط ، كبير ، رصاصي) ، وحدة اختبار ، SIT Tester ، مالك منتج فني ، مالك منتج أعمال ، Scrum Master ، مدير المشروع ، محلل الأعمال ، قائد فني ، قائد اختبار SIT ، قائد اختبار UAT ، مراقبة الجودة العالمية ، الدعم ، مهندس النشر وغيرهم.
دورنا المحدد هو
مراقبة الجودة العالمية . هذا هو الشخص من جانب العميل ، المسؤول عن الامتثال لمتطلبات العملية - دورة حياة البرنامج وجميع أنواع الإجراءات التشغيلية الموحدة (SOP) من جانب العميل - أثناء التطوير والقبول ، ويوفر كذلك مجموعة من الوثائق للمراجعة الخارجية.
وثائق القبول
كجزء من إصدار المنتج ، يتم إنشاء حزمة وثائق تحتوي على عدد كبير من مستويات التعشيش ، بما في ذلك الوثائق المتعلقة بكيفية اختبار المنتج ولماذا تم اختباره بهذه الطريقة وليس بخلاف ذلك ، وما تم اختباره على وجه التحديد وما تم استبعاده:
خطة المصادقة وقائمة الفريق - مسؤول عن كتابة المستند والموافقة عليه. تتضمن الوثيقة عادةً وصفًا للنظام ، وقائمة من القطع الأثرية التي سيتم إنشاؤها أثناء التطوير والاختبار ، واستراتيجية التحقق من الصحة ، وقائمة بالأدوار ذات المسؤوليات.
اختبار الاستراتيجية - مستند لا ينطبق على تطبيق معين ، ولكن يتم إنشاؤه لفرع منتج منفصل أو لفرع اختبار منفصل. على سبيل المثال ، كيف ولماذا نقرر ما الذي سنقوم تلقائيًا به وما الذي لن نقوم به ؛ ما التقنيات ؛ كيف سنرتب اختبارًا يدويًا (فحص القوائم أو البرامج النصية للاختبار ، أو كليهما معًا ، أو أي شيء مختلف تمامًا) ؛ كيف نقرر ما إذا كنا سنقود الحمل أم لا ؛ وهلم جرا وهكذا دواليك.
تتضمن خطة الاختبار - الشائعة لفرق UAT و SIT ، وصفًا موجزًا لكائن الاختبار والقيود المحتملة ومتطلبات البيئة والتوقيت ومجموعات الاختبار وما إلى ذلك.
مجموعة الاختبارات - مجموعة من الاختبارات أو قوائم المراجعة التي شكلتها المنطقة الوظيفية أو نوع الاختبار أو أي ميزة أخرى.
مصفوفة التتبع - مصفوفة التتبع من المتطلبات إلى الاختبار. تتبع كدليل على التغطية هو جزء مهم من العملية. من خلال تحديد أي شرط ، يمكنك العثور على خطوة محددة يتم فيها تأكيد هذا المطلب وتقديم دليل للمراجع (لقطة شاشة ، ملف ، وما إلى ذلك) لإصدار معين من التطبيق (أو لكل إصدار تمت تغطيته فيه بشكل رسمي). لذلك ، قم بربط الاختبارات وربطها مرة أخرى وربطها بالمتطلبات (المهام) ، والتي تحصل على أساسها على النتيجة المتوقعة ، حتى إذا لم يكن ذلك مطلوبًا منك. إذا كان ذلك مستحيلًا بسبب استخدام أدوات مختلفة غير متكاملة ، فيمكنك دائمًا ترك التعليقات في مهمة / اختبارات ، أو إنشاء مصفوفة (ذكر Excel أعلاه) ، أو تقديم قاعدة بيانات أولية من ثلاثة جداول.
PDS - مواصفات تصميم المنتج ، وهي وثيقة تم تطويرها بواسطة مستشار تقني أو مهندس مشروع ، وهي في الأساس مزيج من بنية التطبيق عالية المستوى ومنخفضة المستوى (HLA و LLA).
FRS و
URS أو
BRS هي متطلبات وظيفية ومتطلبات المستخدم ، وعادة ما تكون في شكل وثيقتين منفصلتين ، ولكن يتم دمجها في بعض الأحيان في مواصفات متطلبات الأعمال.
سجل العيوب - سجل العيوب المكتشفة أثناء الاختبار (عيوب ومتطلبات التطبيق).
سجل المشكلات الثانوية - سجل للأخطاء البسيطة في الاختبارات (الأخطاء المطبعية ، المتطلبات المفقودة / غير الضرورية ، وهكذا - أي أخطاء لا تغير معنى الاختبار بشكل أساسي).
تقرير ملخص الاختبار - تقرير عن نتائج الاختبار. TSR هي الوثيقة الختامية لخطة الاختبار وتحتوي على:
- معلومات حول التجميعات التي تم اختبارها (بما في ذلك أرقام الإنشاء وتواريخ النشر) ، وعدد دورات الاختبار ونتائج الاختبار.
- وصف الانتهاكات المرتكبة فيما يتعلق بخطة الاختبار وإجراءات الاختبار (SOP) المعتمدة للتنفيذ من قبل الشركة.
- قائمة العيوب المفتوحة التي تشرح أسباب النقل إلى الإصدار التالي.
- رابط إلى سجل العيوب أو السجل نفسه.
- رابط إلى سجل خطأ الاختبار أو السجل نفسه.
- توصية لقرار التثبيت في الإنتاج.
خطة النشر - هي وثيقة يتحمل مسؤولية الدعم والتكامل ، ويتم تجميعها أثناء عمليات التثبيت على بيئة SIT ، ويتم استخدامها لاحقًا لنشر الإصدار على الإنتاج.
تقرير ملخص التحقق من الصحة - الوثيقة الختامية لخطة التحقق من الصحة.
الموافقة على المستندات
تنقسم أي عملية للموافقة على الوثائق إلى ثلاث مراحل:
- إعداد المستند.
- الاستعراض.
- موافقة عليها.
النظر في مثال اختبار جناح.
لكتابة نصوص اختبار ودمجها في مجموعات اختبار ، نستخدم قالبًا قياسيًا معتمدًا من جانب العميل.
مكونات طقم الاختبار:
- اسم المشروع والتطبيق.
- نسخة الإصدار.
- اسم المعرف الفريد للمجموعة.
- الوصف (ما الذي نختبره ، وما أنواع الاختبارات التي نستخدمها).
- الاختبارات.
- قائمة بالموافقين.
بدوره ، يتضمن كل اختبار:
- الاسم والمعرف الفريد ضمن المجموعة.
- الوصف.
- شروط مسبقة.
- Postconditions.
- تتبع (أرقام المتطلبات المشمولة في الاختبار).
- ميزات التنفيذ (على سبيل المثال ، تعليمات لإخفاء البيانات الحساسة).
- الخطوات (الإجراءات المطلوبة ، النتائج المتوقعة والفعلية).
- نتيجة الاختبار.
- تشغيل.
- Revyuver.
تشبه دورة الحياة الطبيعية للاختبار شلال التغذية المرتدة ويبدو كما يلي:
- كتابة
تحليل الاحتياجات. تعريف وتطبيق تقنيات تصميم الاختبار للحصول على تغطية مناسبة للوظائف. خطوات الكتابة. - اختبار مرور / مقاطع على العذارى
في هذه المرحلة ، يتم تقييم مقدار تلبية التطبيق للمتطلبات ، ويتم تفريغ الجزء الأكبر من الأخطاء المحتملة ، بما في ذلك أخطاء المتطلبات. - مراجعة مدير المشروع (قائد فريق SIT)
مراجعة الأسلوبية والمنطقية. - اختبار مرور / يمر على بيئة SIT
في هذه المرحلة ، يتم اكتشاف الأخطاء المرتبطة بالتثبيت والبيئة وتكوين البيئة (بشكل افتراضي ، يُعتقد أن بيئة SIT تكرّر PROD بالكامل أو تقريبًا بالكامل). الانتهاء بنجاح من هذه المرحلة يعني أن النسخة المحاطة مستقرة وأن الإصدار يمكن اعتباره مرشحًا. - مراجعة العملاء (مراقبة الجودة العالمية)
تتحقق Global QC من تلبية المتطلبات وأن اختبارات SOP المكتوبة موجودة لدى الشركة. - الموافقة (مراقبة الجودة العالمية ، البريد الفني ، صندوق بريد الأعمال).
- تنفيذ اختبار رسمي على بيئة SIT (إصدار مرشح الإصدار)
بعد الموافقة على اختبارات المرور (الصفحة 6) والإكمال الناجح للاختبار يمر على بيئة SIT (الصفحة 4) ، يتم إجراء الاختبار رسميًا على بيئة SIT مع التثبيت الرسمي للنتيجة. إذا لم يتم إضفاء الطابع الرسمي على الأخطاء الموجودة في التمريرات التجريبية وأدخلت ببساطة في Jira على غرار ما يحدث أثناء عملية التطوير ، فسيتم إنشاء نموذج عيب منفصل لكل خطأ موجود في الممر الرسمي ، والذي يتم تضمينه في حزمة إخراج وثائق المنتج. - مراجعة نتائج المقطع المسؤول عن المشروع (قائد فريق SIT).
على غرار النقطة 3 ، يتم فحص أسلوب التعبئة ويتم تحليل النتائج. - مراجعة العملاء (مراقبة الجودة العالمية)
يتحقق QC العالمي من صحة واكتمال ملء النتائج والأخطاء المحتملة ووجود التأكيدات (على سبيل المثال ، لقطات الشاشة). نقطة مهمة ، لأنها Global QC هي المسؤولة عن توفير حزمة من المستندات للتدقيق الخارجي (بواسطة إدارة الأغذية والعقاقير أو العملاء).
العمل مع البيانات الشخصية
نظرًا لأن البحث يتم باستخدام منهجية مزدوجة التعمية ، فهذا هو أقل مشاكلنا. لكن يجب تغيير بيانات الأطباء وأسماء الشركات وأرقام بروتوكول البحث وما إلى ذلك. من وجهة نظر رسمية ، إذا لم نتمكن من التخلص من البيانات الحساسة ، فيجب أن نخفيها على لقطات الشاشة ، لكن هذا موقف قياسي إلى حد ما ويمكن فهمه.
* أعمى مزدوج - طريقة أعمى مزدوجة. يتم تقسيم المرضى بشكل عشوائي إلى مجموعتين ، واحدة منها تتلقى دراسة المخدرات ، والثانية دواء وهمي أو دواء مع فعالية مثبتة. في الوقت نفسه ، لا يعرف الطبيب ولا المريض المجموعة التي تم تكليف المريض بها. هذا يلغي تحيز الطبيب وتأثير الدواء الوهمي. في سياق التعامل مع البيانات الشخصية ، هذا يعني أنه في معظم الحالات لا يمكن تحديد هوية المريض على أساس البيانات المخزنة في قاعدة البيانات أو يمكن للمستخدم الوصول إليها.ولكن حقيقة أن هذا هو أقل مشاكلنا لا يعني أنه لا يمكن أن يسبب المتاعب. في ما يلي بعض أشعل النار التي اعتدنا أن نخطو على مشاريعنا:
ادعاء من المرح: غلوب
في أحد التطبيقات لإنشاء تأثير رائع ، ليس فقط نحن في حاجة فعليًا لإنشاء كرة تفاعلية يمكنك تدويرها بالماوس والتبديل نهارًا / ليلًا وما إلى ذلك. على الكرة الأرضية توجد علامات على العناوين ، والتي تكون ملونة بناءً على القيم والنطاقات التي تسقط فيها هذه القيم (مثل الترميز اللوني). بعد إخفاء هوية قاعدة البيانات على بيئة العرض التوضيحي ، قبل ساعتين من العرض التوضيحي ، وذلك بفضل البرنامج النصي لإخفاء الهوية ، فقد تركنا بدون رموز بريدية مع كل العواقب.
الأخلاقية: لا تلمس البيانات قبل ساعتين من العرض.
القصة الثانية: "حول إخفاء الهوية"
الخلفية: يتم جمع البيانات في المستودع من عدد كبير من المصادر ، تنتمي البيانات إلى مجالات مختلفة ، ولكن يتم ربطها بواسطة معرفات.
المحفوظات: تم تحميل البيانات إلى المستودع وتم الكشف عن هويته قبل استخدامه لأغراض الاختبار. اتضح أنه لم يتم تنزيل البيانات من جميع المصادر اللازمة. ثم قاموا بتحميل الجزء المفقود. لم يكن من الممكن ربط الجزء الثاني من البيانات (لم يتم الكشف عن هويته بعد) بالجزء الأول المجهول بالفعل. نتيجة لذلك ، تم تأجيل بدء العمل في بيئة SIT لمدة أسبوعين ، حيث قامت فرق النشر والدعم بتصحيح البيانات.
الأخلاقية: قبل الكشف عن هويتك ، يجب أن تتأكد من أن قاعدة البيانات تحتوي على كل ما يجب أن تكون فيه ، أو التفكير مقدمًا في إمكانية تطبيق آلية إخفاء الهوية والتشويش.
سير العمل الإلكتروني مقابل الورق في الممارسة العملية
الشخص الذي عمل مع HP ALM لا يضحك على السيرك.تعمل الإدارة الإلكترونية للوثائق على تبسيط الاتصالات وعملية المراجعة والمرور إلى حد ما من وجهة نظر العمل اليدوي ، ولكن من الناحية العملية لا تعطي استنفادًا في الوقت المناسب في سياق وقت الإعداد للاختبار وتنفيذه. المدرجة أدناه هي إيجابيات وسلبيات سير العمل الإلكتروني مقابل الورق بناءً على مثال HP ALM.
الايجابيات:
- من السهل تحديث أحدث إصدار.
- أقل اليدوية.
- يمكن لجميع أعضاء الفريق في أي وقت الوصول إلى الحالة الحالية لاختبار معين.
- تغيير التاريخ.
- تاريخ مرور.
- يمكنك تتبع الوقت المستغرق لإكمال الاختبار.
- من الأسهل تخطيط الوقت لمزيد من التمريرات.
- يجب أن نحاول استخدام الإصدار الخاطئ من الاختبار للمرور.
- التوقيع الالكتروني.
سلبيات (خصيصا لـ HP ALM):
- يقضي الكثير من الوقت في اختبارات التنسيق.
- مشاكل دورية مع الأداة نفسها.
- عدم وجود المدقق الإملائي العادي.
- واجهة غير مريحة.
- الوقت الذي تقضيه في كتابة ومراجعة الاختبارات هو نفسه عملياً نفس الاختبارات في Word.
- التكلفة.
دراسة حالة متعلقة بالأوراق والتوقيعات اليدوية: "الكابوس قبل الإصدار"
في إحدى الليالي ، كتبت 450 مرة ، "يتوافق لون النقاط على الرسم البياني مع اللون المذكور في المتطلبات ، اللقب هو اسم التاريخ" ، ووضع توقيعًا - ببساطة لأننا طبعنا على طابعة b / w ، ولون النقاط على الرسوم البيانية المهمة.
الأخلاقية: يجب أن يكون اختيار الوسائل متسقًا مع الأهداف.القصة الثانية: "الجاذبية جيدة ، الشدة موثوق بها"
ورقة سير العمل هي ورقة (من سيشك). لاستقبال واحد بعيدا عن أكبر تطبيق ، يمكن أن تتحول في المنطقة من خمسة كيلوغرامات.
الاستنتاج الذي يقترح نفسه من القصص أعلاه (والعديد من القصص التي لم يتم سردها): على الرغم من العيوب المدرجة وغير المدرجة في قائمة الإدارة الإلكترونية للوثائق - إذا كان يمكنك الاختيار ، فاختر بالتأكيد إلكترونيًا ، حتى لو كان HP ALM (وليس HP بعد الآن).أتمتة
لا يسمح عدد كبير من المرئيات بالتشغيل التلقائي للتطبيقات ، وبالتالي ، كجزء من النهج الأولي ، حددنا اختبارات الوحدة (بما في ذلك على الجانب الأساسي) واختبارات واجهة برمجة التطبيقات (API) ، دون أي محاولات للتحرك نحو E2E.كيف ولماذا توصلنا إلى أتمتة جزئية على الأقل؟كانت المهمة الأولى هي أن نوضح لأنفسنا أننا في بعض الحالات سنكسب حقًا وقتًا. نعم ، هذا أمر مفهوم: لا يؤمن كل شخص بالأتمتة وغالبًا ما لا يبرر استخدامه - لأنه يستخدم بطريقة خاطئة ، وليس هناك ، وليس لذلك ، ولكن هذا موضوع لتقرير منفصل ، يوجد منه أقل قليلاً من "الأتمتة يجب أن يكون لها !!!" "، ولكن لا يزال في الكمية.والثاني هو أن يشرح للعميل أنه سيكسب الوقت وأنه سيكون موثوقًا ومقبولًا بما فيه الكفاية من وجهة نظر رسمية. يتم التحكم في الصناعة لسبب ما.ثالثًا ، والرئيسي: تحديد الخوارزمية التي يمكننا من خلالها اتخاذ قرار بوعي بشأن أتمتة اختبار تطبيق معين أو جزء من التطبيق ، والحصول على موافقة للتشغيل الآلي. هذا أمر مهم ، لأنه في ضوء عملية الموافقة على الوثائق الموصوفة أعلاه باستخدام Test Suite اليدوي كمثال ، يصبح من الواضح أن عملية التشغيل الآلي يجب ألا تكون أقل تحكمًا.بعد أن شرحنا وتبررنا النقطتين الأوليين لأنفسنا ولعملائنا ، قمنا بكتابة استراتيجية اختبار ، وطلبنا من محللي الأعمال إضافة حقول إضافية إلى المتطلبات ، وقمنا بتكوين مجموعة من الأسئلة ، بناءً على الإجابات التي يمكنك تشكيل مجموعة للتشغيل الآلي لها.قائمة الأسئلة في حالتنا:- هل من الممكن أتمتة الاختبار في هذه الحالة بالذات؟
- هل يكون المكون * للاختبار آليًا ليكون ثابتًا؟
- كم مرة يجب أن نجري اختبارات مكتوبة لمكون؟
- هل هذه الوظيفة مهمة للأعمال؟ **
- ما مدى صعوبة أتمتة الاختبار؟
* مستقر = لم يتغير المكون لبعض الوقت ولم يتم تخطيط تغييرات المكون للإصدارات القادمة.
** يتم تثبيته اعتمادًا على قيمة الحقل المضافة إلى متطلبات محلل الأعمال.
بشكل عام ، عملية صنع القرار هي كما يلي:- يتلقى الإدخال متطلبات FRS.
يتم تصنيف مصفوفة التصميم ، حيث يكون كل صف مطلبًا من FRS. كأعمدة:
- وصف الشرط
- الأسئلة 1-5
- قرار الفريق
- يقدر وقت الكتابة
- موافقة
- تعليقات
- يضع الفريق إجابات على الأسئلة وعلى أساس البيانات المستلمة يحدد ما إذا كان الأمر يستحق أتمتة الاختبار لمتطلبات / مجموعة محددة من المتطلبات كليًا أو جزئيًا.
- يراجع العميل الحل المقترح ويوافق على الإصدار النهائي.
- بعد موافقة مصفوفة التصميم ، تتم كتابة الاختبارات التلقائية. يتم وصف البرامج النصية للاختبارات التلقائية على Gherkin وتخضع لمراجعة مماثلة لتلك الخاصة بالاختبارات اليدوية (Global QC ، المالك الفني ، مالك العمل). تتم مراجعة تعريفات الخطوة وكائنات الصفحة وما إلى ذلك في مجموعة الطلبات ، بما في ذلك من قِبل أحد المتخصصين التقنيين من جانب العميل. يتم توقع نتائج Autotest والتقارير التي تم إنشاؤها على جانب مراقبة الجودة العالمية.
على مدار العامين منذ بدء المقدمة ، تحولنا إلى أتمتة جزئية لاختبار القبول لتطبيقين يتعلقان بتنزيل البيانات وتهيئتها وعرضها في مستودع البيانات ، وفي المستقبل القريب نخطط لمواصلة استخدام النهج المشترك على المنتجات الأخرى المطورة للعميل ، إن أمكن ذلك.استنتاج
في الختام ، أود أن أشير إلى أن اختبار القبول الرسمي ليس شيئًا مخيفًا أو عديم الفائدة ، كما يبدو للكثيرين. وهو يتيح ، مع الاستفادة الكاملة من النهج القائم على السيناريو في الاختبار ، تسهيل اختبار الإصدارات المستقبلية ، وتأكيد المستوى الضروري والكافي لجودة البرنامج ، وطمأنة العميل في النهاية. وما هو ، إن لم يكن راحة العملاء ، مهم في تطوير العرف؟