لضمان جودة منتج المعلومات في الطب والتأمين والمصارف وغيرها من الصناعات ، إلى جانب طرق الاختبار الأخرى ، من المهم استخدام الاختبارات القائمة على المخاطر. للتحقق ، يتم تحديد المناطق الأكثر خطورة في البرنامج الذي يتم إنشاؤه. يتيح لنا ذلك توقع السيناريوهات السلبية وتنفيذ أهداف العمل الخاصة بالعميل بنجاح.
في المقال ، سوف نوضح كيف عملنا في SimbirSoft مع المخاطر (باستخدام نظام اقتناء الإنترنت والمشاريع الأخرى كمثال) وما هي طرق تقييم المخاطر وإدارتها التي نستخدمها في مشاريع العملاء.
المخاطر في بداية المشروع
للبدء ، نقدم مثالاً من ممارستنا في تطوير القطاع المصرفي.
اقتراح العميل: التركيز على إصدار البنك الإلكتروني للأفراد.
المخاطرة التي حددناها: احتمال فقد الجمهور بسبب انخفاض الطلب على إصدار الويب للأفراد ، على عكس بنك العميل المتنقل.
حججنا: إحصائيات تفضيلات المستخدم استنادًا إلى المراجعات وتوزيع الجمهور من خلال إصدارات الجوال والويب.
الاستنتاجات: بالنسبة للأفراد ، فإن إصدار الهاتف المحمول أكثر ملاءمة ، حيث أن الهاتف دائمًا في متناول اليد. العمليات سريعة ، نظام الترخيص يسمح لك بالوصول إلى جميع الخدمات المناسبة. في هذه الحالة ، من المهم الوصول السريع إلى مجموعة محدودة من الوظائف الأكثر شعبية.
بالنسبة إلى الكيانات القانونية ، من الأهمية بمكان اكتمال الوظائف المتوفرة ، والقدرة على التحميل والطباعة والعمل مع كمية كبيرة من المعلومات. لهذا ، فإن إصدار الويب أكثر ملاءمة.
حلنا: التركيز على بنك العميل المتنقل للأفراد.
في بداية العمل مع مشروع ، من المهم اختيار استراتيجية الاختبار بشكل صحيح. دعونا نلقي نظرة على أمثلة لماذا هو مهم وكيفية اختياره.
يجب أن تفي استراتيجية الاختبار بأهداف العمل
عاجلاً أم آجلاً ، تواجه جميع الشركات الحاجة إلى تنظيم عملية الاختبار وتفهم أن بناء استراتيجيتها يمثل مرحلة مهمة في تطوير البرمجيات. في بعض الأحيان - من خلال تجربتهم المريرة. من الخطير بشكل خاص التقليل من أهمية دور الاختبار واختيار الاستراتيجية في تطوير المشروعات الكبيرة. يجب اختيار عملية الاختبار وفقًا لأهداف العمل وخصائص المشروع ، وإلا فلن تؤدي إلى نتائج إيجابية سواء في غضون شهر أو سنة.
على سبيل المثال ، ضع في اعتبارك اختبار تطبيقات الجوال والويب للبنك. في بداية المشروع ، اخترنا استراتيجية تعتمد على متطلبات بمستوى منخفض من التفاصيل. استخدمنا قوائم المراجعة لتقليل وقت الاختبار ودعم أساس الاختبار. مع نمو الأداء الوظيفي ، إضافة أنظمة الحصول على الرسائل القصيرة والإذن بها والإخطار بها ، وأنظمة أكثر تعقيدًا ، لم تعد قوائم المراجعة قادرة على التعامل مع مهمتها. مع مرور الوقت ، انضم المزيد والمزيد من المتخصصين في ضمان الجودة إلى الفريق ، كان من الضروري نقل المعلومات وتنسيق أعمالهم. مع تعقيد المنتج ، يمكن أن يؤثر أي تغيير على الوظائف ذات الصلة ، أي زيادة خطر الانحدار. كانت الحاجة إلى أتمتة اختبارات الانحدار تختمر ، لذلك تحولنا إلى حالات الاختبار.
الخلاصة: اعتمادا على المشروع ، تفاصيله أو مرحلة التطوير ، تتغير استراتيجية الاختبار.
يجب اختيار الاستراتيجية لأهداف المشروع لضمان أفضل جودة للمنتجات. إنها تجيب على أسئلة "ماذا" ، "أين" و "متى" سيتم اختبارها. في أي لحظة من الزمن ، أنت تعرف في أي نقطة أنت وأين ستأتي في المستقبل - وفقًا للاستراتيجية.
قد يتمثل هدف العمل في ضمان أمان بيانات العميل ، وكذلك البرنامج نفسه في مرحلة الإنتاج. يبدأ الأمن بعملية التطوير ويستمر خلال مرحلة الاختبار.
على سبيل المثال ، في أحد المشروعات ، أنشأنا بيئة آمنة للتطوير والاختبار ، ونشرنا بنية أساسية تفي بجميع المتطلبات وساعدت في حماية البيانات. لقد طلبنا الرموز المميزة ومحركات الأقراص المحمولة المعتمدة على الأسماء لكل متخصص في ضمان الجودة للوصول إلى البنية الأساسية للاختبار. وبالتالي ، قمنا بضمان هدف العمل للمشروع في أمان البرنامج وحافظنا على سرية بيانات العميل والمستخدم.
نظرًا لاستراتيجية الاختبار ، يمكن التركيز على الجوانب المهمة حقًا لمشروع معين. من المنطقي أن يتطلب إصدار لعبة محمولة أو نظام CRM مصرفيًا معقدًا طرقًا مختلفة للاختبار.
استراتيجية اختبار المصرفية
في ممارستنا ، استخدمنا في SimbirSoft مجموعة كاملة من منهجيات التطوير ، ولكن التقنيات المرنة تبقى دائمًا على رأس أولوياتنا. وحتى إذا كان من غير الممكن ، لعدة أسباب ، استخدامها ، يعتمد الفريق أفضل الممارسات ويطبقها في العمل اليومي. يصبح الاختبار جزءًا لا يتجزأ من العملية بأكملها ويدمج في سير العمل الكلي. في هذه الحالة ، لا يكون مسؤولًا عن جودة المنتج فحسب ، بل عن جودة عملية العمل بأكملها.
ما التقنيات التي نستخدمها:
- تخطيط مرن وإعداد الإصدارات الداخلية ؛
- إعداد قصة المستخدم.
- عقد المسيرات.
- إجراء استعادية.
بكامل قوتها ، تكشف استراتيجية الاختبار عن نفسها في المشروعات ذات المنطق التجاري المعقد. على سبيل المثال ، برنامج لدعم المعلومات من البنوك ، وبناء نظام اقتناء الإنترنت ، منصة التداول الآلي. في مثل هذه المشروعات ، من المهم تطبيق استراتيجية اختبار مناسبة ، لأن سعر بعض الأخطاء قد يؤدي إلى خسائر حقيقية ويؤثر بشكل كبير على سمعة الشركة نحو الأسوأ.
أيضًا ، يمكن إضافة الأهداف الرئيسية للاختبار - البحث عن عيب والتحقق من صحة البرنامج للتأكد من توافقه - إضافية. على سبيل المثال ، من المهم للبنوك أن تنفذ بسرعة المتطلبات الجديدة للبنك المركزي. هذا يعني أنه سيتم إضافة الاختبار في الوقت المناسب مع الجودة المطلوبة للمهام الحرجة إلى الهدف الرئيسي.
في الآونة الأخيرة ، في مشروع مصرفي ، واجهنا تغييرًا في القانون الفيدرالي - زيادة في ضريبة القيمة المضافة من 18٪ إلى 20٪. تم القيام بالكثير من العمل التمهيدي للتكيف مع تغيير التشريع ، حيث أن التغيير لا يتعلق فقط باستبدال النماذج ، والواجهات ، ولكن أيضًا تغيير منطق العديد من صيغ الحساب. كان من الضروري ضمان العرض الصحيح على العديد من المنصات. أيضا ، في وظيفة الدفع المؤجل ، كان من الضروري مراعاة الفترة الانتقالية بمعدلات 18 ٪ و 20 ٪.
الآن سنتحدث بمزيد من التفاصيل حول كيفية بناء استراتيجيتنا ولماذا نختار غالبًا الاختبار القائم على المخاطر.
إيجابيات الاختبار القائم على المخاطر
هناك العديد من استراتيجيات الاختبار التي تم اختيارها لأغراض محددة:
- بناء على المتطلبات
- منهجي
- استراتيجيات رد الفعل.
- الاستراتيجيات الاستشارية.
في حالة العمل مع المشاريع ذات المنطق التجاري المعقد ، من الضروري تحديد متطلبات صارمة في تصميم الأنظمة التي يعتمد عليها الاختبار. الأداة المناسبة هي الاختبار القائم على المتطلبات.
أحد أنواع الاستراتيجيات القائمة على المتطلبات هو الاختبار القائم على المخاطر. علاوة على ذلك ، يتم اختبار الأجزاء الأولى من وظائف النظام الأكثر تعرضًا للمخاطر أولاً. الخطر هو نتيجة سلبية محتملة لنظام خلل. والنتيجة هي خطر في وجود عنصرين ، مثل الفرصة والسلبية.
هناك نوعان من المخاطر:
1. مخاطر المنتجيمكن أن تدار وغير المدارة. في المثال أعلاه ، واجهنا خطرًا يمكن التحكم فيه: النمو السريع وتعقيد الوظائف ، مما زاد من احتمال الانحدار. نحن هنا حل المشكلة من خلال وجود قاعدة اختبار مفهومة والأتمتة اللاحقة. الخطر الذي لا يمكننا التأثير عليه هو الاعتماد على الأنظمة الخارجية وفشلها في عملية التكامل. نحن هنا نضع التدابير التي تقلل من تأثيرها على نظامنا. على سبيل المثال ، استخدام النسخ الاحتياطي ، والتعامل مع الحالات الاستثنائية ، وعرض التحذيرات للمستخدم.
2. مخاطر المشروععلى سبيل المثال ، في أحد المشروعات ، واجهنا حقيقة أن العميل لم يعمل من قبل مع فريق موزع ، وبالتالي فإن سير العمل المستخدم لم يستوف المتطلبات وخلق مشاكل اتصال إضافية: عدم الفهم ، ازدواجية المهام ، أداء المهام الحصرية المتبادلة ، وهلم جرا. اتفقنا على إعادة هيكلة العملية وتحسينها - راجعنا سير العمل ، وقدمنا جميع أعضاء الفريق ، وعقدوا اجتماعات حاشدة ، وعروض استعادية. نتيجة لذلك ، ذهب العمل في الاتجاه الصحيح.
يسمح لك النهج القائم على المخاطر بتكوين عدد معين من المخاطر ، لفترة قصيرة لاختبار المخاطر ذات الأولوية العالية وتزويد العميل بمقاييس حول مدى اختبارهم جيدًا ، مع توضيح عدد الحالات المخطط لها والمكتملة وعدد العيوب.
يتم تنفيذ النهج القائم على المخاطر في المشروع على أربع مراحل:
تحديد المخاطر - في هذه المرحلة ، تحتاج إلى تحديد المخاطر والحصول على قائمة بها.
تقييم المخاطر - هنا نقوم بتحليل القائمة وتصنيفها حسب الأولوية.
تخفيف المخاطر - في هذه المرحلة ، نحدد مدى عمق اختبارنا للمخاطر.
إدارة المخاطر - هنا نقرر كيف سنستمر في العمل معهم ونستعرضها ونحدد المخاطر الجديدة.
يتم تحديد المخاطر وتقييمها بواسطة مجموعة من أصحاب المصلحة خلال جلسات العصف الذهني. يجب أن يضم الفريق محللي الأعمال أو أصحاب المعرفة بالنظام من العملاء أو المطورين أو مدير المشروع أو مدير المشروع أو المهندسين المعماريين أو متخصصي ضمان الجودة. نحن نشرك متخصصين في أمن المعلومات ، والموظفين الذين يعملون مباشرة مع النظام الحالي ، ومحللي الأعمال المنغمسين في عمليات لتحديد المخاطر وتقييمها.
النظر في النهج القائم على المخاطر من خلال مثال اختبار نظام الحصول على الإنترنت.
التعامل مع المخاطر (على سبيل المثال نظام الحصول على الإنترنت)
نحن واحد من المتطلبات التالية:
D1.Provide 1000 الاتصالات المتزامنة للنظام في الثانية الواحدة.
D2. أمن المعاملات.
D3. يجب أن يكون الوصول إلى المعاملة متاحًا فقط للشخص الذي يجري المعاملة.
D4. توفير ودعم معيار SET (المعاملات الإلكترونية الآمنة).
كمخاطر للمنتج ، يمكننا التمييز بين:
RP1. تعطل النظام مع الاتصالات المتزامنة.
RP2. باستخدام حقن SQL أثناء المعاملة.
RP3. الوصول إلى معاملة شخص آخر عند تغيير المعلمات في URL.
RP4. فقدان البيانات عند فقد الاتصال بالبنك في وقت المعاملة.
RP5. استخدام شهادات غير صالحة عند توفير نظام SET (Secure Electronic Transaction).
كمخاطر تنظيمية:
RO1. سقوط النظام المتطور بسبب عدم إمكانية الوصول إلى الأنظمة الخارجية.
RO2. وجود حالات يصعب إعادة إنتاجها ولا يمكن اكتشافها في بيئة اختبار.
وبالتالي ، فإن كل خطر يتبع منطقيا المتطلبات الموجودة في النظام ، ولكن لا يقتصر عليها. تكمل المخاطر المتطلبات وتحدد الحالات الإضافية التي قد تنشأ عند العمل مع النظام.
يمكن تقليل المخاطر أو تعويضها وفقًا لأهداف المشروع ومتطلبات النظام. من المقبول أن يتم تغطية المخاطر من قبل حالة الاختبار مرة واحدة على الأقل:
1. لكل خطر منتج ، يتم إعداد مجموعة من حالات الاختبار RP1-RP4 بشرط أن يكون كل متطلب وكل مخاطرة مغطاة بحالة اختبار واحدة على الأقل. اعتمادًا على أغراض الاختبار ، يتم توسيع مجموعة حالات الاختبار إلى مستوى معين من التفاصيل.
2. لكل مخاطرة تنظيمية ، يتم إعداد قائمة بالأنشطة التي يمكن أن تقلل من تأثير المخاطر على المنتج الجاري تطويره.
تقييم المخاطر وتقنيات الإدارة
هناك عدة طرق لتقييم وإدارة المخاطر: طرق خفيفة الوزن (PRAM ، PRISMA) وأكثر رسمية (FMEA ، FTA).
باستخدام نموذج FMEA ، يقوم فريق المشروع بتحديد جميع العمليات والمكونات والوحدات النمطية للنظام التي يمكن أن يحدث بها فشل أو خطأ في النظام يمكن أن يؤدي إلى تدهور جودة المنتج. خلال العصف الذهني ، يتم تحديد مخاطر النظام من خلال ثلاثة مؤشرات: الشدة والأولوية والاحتمال. ثم يتم احتساب رقم أولوية المخاطرة لكل مخاطرة ، ووفقًا للمؤشرات ، يتم وضع عمق الاختبار.
مع نموذج اتفاقية التجارة الحرة ، يتم تحديد جميع الأسباب التي يمكن أن تؤدي إلى عيوب في العمليات التجارية للنظام على مراحل. ينتقل التحليل من أعلى إلى أدنى مستوى. الفرق بين FMEA و FTA هو أن النهج الأول يركز على وظائف النظام ، والثاني على العمليات التجارية.
بالإضافة إلى هذه الأساليب الرسمية والثقيلة ، هناك طرق أكثر مرونة وغير رسمية. على سبيل المثال ، أساليب PRAM (التحليل العملي وإدارة المخاطر) و PRISMA (إدارة مخاطر المنتج). إنها تجمع بسهولة وبسهولة بين الاستراتيجيات القائمة على المخاطر والمتطلبات. في الأساس ، تستخدم هذه الأساليب مواصفات المتطلبات كمدخلات ، ولكن يمكن أيضًا إشراك أصحاب المصلحة.
طرق تحليل المخاطر خفيفة الوزن تشبه إلى حد كبير الطرق الرسمية. وهي تركز على المخاطر التقنية أو التجارية ، وتزن احتمال حدوث الخطر والعوامل التي تؤثر على هذا الاحتمال.
ومع ذلك ، فإن اثنين فقط من العوامل التي تستخدمها هذه الأساليب هي احتمال المخاطرة وتأثيرها. بالإضافة إلى ذلك ، تستخدم هذه الأساليب الأحكام والمقاييس النوعية المبسطة لاتخاذ القرارات.
تستخدم فرقنا طرقًا مرنة وخفيفة الوزن وتتكيف مع أساليب PRAM و PRISMA مع أهدافها.
كيف نعمل مع الاختبارات القائمة على المخاطر
على سبيل المثال ، في أحد المشروعات ، نحدد مخاطر المشروع والمنتج التي قد تنجح. للقيام بذلك ، يشارك المحللون والمطورون و QA في التحليل - ممثل واحد من الفريق.
يتم تشكيل جدول المخاطر مع المنتجات. وهي تحدد تقييم احتمال حدوث خطر وتأثيره المحتمل على النظام على مقياس من خمس نقاط. في الجدول 1 - أقوى تأثير ، 5 - الأضعف. أيضا للاحتمال 1 - احتمال كبير ، 5 - احتمال منخفض.
كيف نستمر في العمل مع مخاطر المنتج
علاوة على ذلك ، لكل منها ، يتم تتبع تغطية المخاطر للمنتج مع حالات الاختبار.
نختار الشيكات التالية:
TC1. تحقق من التحميل مع أكثر من 1000 اتصال للنظام
TC2. اختبار الحمل مع 1000 نظام الاتصالات
TC3. أدخل حقن SQL أثناء المعاملة
TC4. أدخل SQL injection في صفحة المعاملة الناجحة ، عن طريق استبدال البيانات الأخرى
TC5. إدخال البرامج النصية XSS (البرامج النصية للمواقع المشتركة) في الحقول المتاحة للإدخال عند إجراء معاملة
TC6. محاكاة اتصال إنترنت غير متصل أثناء المعاملة
TC7. الخروج من جلسة المعاملات في خطوة التحقق
TC8. التحقق من صحة الشهادات منتهية الصلاحية أثناء المعاملة
وبالتالي ، فإن عمليات التحقق من الأولوية هي TC2 و TC4 و TC5.
TC6 و TC8 لهما تأثير كبير ، لكنهما أقل احتمالًا ، لذلك تكون أولوية التحقق منهما أقل ، لكن الفحوصات مطلوبة أيضًا.
لا ينطبق TC7 على أي من المتطلبات ، ولكنه يمد الاختبار لسيناريو سلبي ، وهو أمر ممكن مع التشغيل المستقر للنظام.
كيف نواصل العمل مع مخاطر المشروع
نحدد أيضًا الإجراءات الخاصة بمخاطر المشروع ، والتي نخصص بها تدابير وقرارات إضافية.
في خطر "RO2. وجود حالات يصعب إعادة إنتاجها ولا يمكن اكتشافها في بيئة الاختبار "، يمكنك اتخاذ ما يلي:
- قم بإعداد حامل ما قبل الإنتاج ، وهو أقرب ما يمكن من بيئة التطبيق الحقيقية ، بالاقتران مع جميع الأنظمة الخارجية ؛
- كتابة نصوص اختبار نهاية إلى نهاية تمر عبر جميع الأنظمة المجاورة وتوفر التحقق من المعاملة ؛
- بعد إجراء جميع عمليات التحقق من الأولوية ، استخدم أساليب تخمين الأخطاء وفقًا للمتطلبات الأساسية للنظام والبرامج النصية لإجراء فحوصات إضافية في دور "قرصنة النظام".
خطة الطوارئ
من المهم أن يكون لديك خطة عمل في حالة نجاح أحد مخاطر المنتج أو المشروع. في بعض الأحيان قد حفظ إعداد نظام النسخ الاحتياطي للمشروع. ليس من الممكن دائمًا تقليل الخطر إلى الحد الأدنى ، ولكن يجب أن يكون من الممكن تقليل عواقبه على الأقل. كان موضوعنا
"قصة عيد الميلاد" حول هذا الموضوع: كيف يمكن للمخاطرة أن تنجح ، والاحتمال الذي يميل إلى الصفر.
على سبيل المثال ، يجب أن نتخلص تمامًا من فقد البيانات أثناء إحدى المعاملات ، ولكن يجب اعتبار جميع الحالات شاقة للغاية. لذلك ، يجب أن يكون لديك طرق للتعامل مع مثل هذه الحالات. أحد خيارات الأمان هو تطوير تسجيل أكثر تفصيلاً. سيوفر ذلك نقطة تراجع دائمة للإجراء السابق إذا حدث خطأ ما أثناء المعاملة.
استنتاج
يتيح لك الاختبار المستند إلى المخاطر تغطية أكثر المناطق خطورة من خلال حالات الاختبار ، مما يقلل من تأثيرها واحتمال حدوثها. هذه هي الاستراتيجية الأكثر ربحًا للأنظمة ذات المنطق التجاري المعقد وتكلفة الخطأ العالية. الحل مناسب للقطاع المصرفي وشركات التأمين وأنظمة إدارة علاقات العملاء الداخلية المعقدة ذات المظهر الطبي. من خلال نهج قائم على المخاطر ، نعمل أيضًا مع مخاطر المشروع ، مما يحسن العملية الكلية للاختبار وإدارة المشروع.