تحية للجميع!

أقود قطاع الاختبار في قسم تحليل النظم واختبارها في قسم أنظمة الشركات LANIT. أنا في هذا المجال منذ 14 عامًا. في عام 2009 ، واجهت لأول مرة اختبار نظام معلومات الدولة. وبالنسبة لـ LANIT وللعميل - كان مشروعًا ضخمًا ومهمًا. لقد كانت في العمليات التجارية لأكثر من تسع سنوات.

مصدر

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

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

الفصل 1. بداية مشروع اختبار GIS الأول

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

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

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

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

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

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

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

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

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

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

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

مع تطور المشروع ، بدأت ملامح نظم معلومات الدولة في الظهور.

الفصل 2. ملامح نظم المعلومات الجغرافية. كيف يعيش المختبرون ويعملون معهم

بادئ ذي بدء ، يخضع GIS الكبير لمتطلبات متزايدة من الموثوقية والحمل ، والنظام في وضع 24/7 ، وأعطال النظام لا يجب أن تؤدي إلى فقدان البيانات ، ويجب ألا يزيد وقت استرداد النظام عن ساعة واحدة ، ويجب ألا يزيد وقت الاستجابة عن ثانيتين ، و أكثر بكثير.

نظرًا لأنها كانت بوابة ويب ، كان على المختبرين أن يغرقوا في عملية اختبار بوابات الويب متعددة المستخدمين وبناء نهج لاختبار التصميم وعملية الاختبار ، مع مراعاة خصائص واجهة الويب.

يمكن استخدام تطبيق ويب من قبل عدد كبير من المستخدمين في وقت واحد. كان مطلوبًا توفير اختبار الحمل للجزء المفتوح من GIS المستخدم من قبل جميع المستخدمين ، للتنبؤ بنموذج الحمل وإجراء اختبار الحمل.

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

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

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

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

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

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

عندما سألوني: "كيف يتصرف النظام في جميع الإصدارات المعروفة من المتصفحات؟" - كنت في حالة من الذعر ، بشكل معتدل ، لأن حجم نموذج الاختبار كان ضخمًا (حوالي 4000 حالة اختبار) ، وكانت مجموعة اختبار الانحدار حوالي 1500 حالة اختبار ، وفحص فريق الاختبار الحشد بأكمله حصريًا على متصفح واحد تم تحديده افتراضيًا. كان يجب حل هذه الحالة بسرعة كبيرة واستخدام البراعة من أجل تحديد المواعيد النهائية للإصدار الأول وتغطية إصدارات المتصفح الرئيسية بالاختبارات.

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

بعد وضع نظام المعلومات الجغرافية في وضع التشغيل التجريبي ، ثم في الصناعة ، ظهرت مهمة جديدة - التعامل مع حوادث المستخدمين.

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

لم يواجه فريق الاختبار مثل هذه المهمة من قبل. يجب معالجة تدفق الحوادث وتنظيمها وترجمتها وتصحيحها والتحقق منها وإدماجها في دورة الإصدار الجديدة.

نما مستوى فهم ونضج عملية التشغيل وتحسن مع نمو النظام نفسه.

لقد أدرجت جزءًا فقط من الميزات التي واجهها فريق الاختبار أثناء العمل مع نظم المعلومات الجغرافية.

الفصل 3. مشاكل اختبار نظم المعلومات الجغرافية وطرق حلها. توصيات لاختبار مديري الفرق.

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

ماذا تفعل عندما يكون هناك الكثير من الوظائف؟

لا داعي للذعر وكسر الوظيفة إلى كتل / وحدات / وظائف ، قم بتوصيل المحلل بمراجعة النتيجة ، تأكد من أن رؤية الكتل الوظيفية صحيحة.

نوصي بإجراء ما يلي:

.

, , , , production. , .
//.

, , — , ///. , , , - , , , / // , , « » , .

ماذا تفعل بمصفوفات المعرفة وتغطية المتطلبات الوظيفية؟

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

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

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

ماذا تفعل عندما لا تدعم المتطلبات التاريخ ، مشوشة ، مكررة ، كيف يعمل المختبرون مع هذا؟

نوصي بتنفيذ عملية اختبار المتطلبات على المشروع. كلما تم اكتشاف عيب مبكرًا ، انخفضت تكلفته.

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

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

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

ماذا تفعل عندما يكون من الضروري إجراء اختبار الحمل؟

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

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

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

يجب إجراء عملية التحميل بانتظام قبل إصدار كل إصدار ، وتغيير نموذج الحمل بشكل دوري من أجل تحديد الاختناقات الجديدة.

ماذا تفعل عندما يكون من الضروري إجراء اختبار التكامل الذي لا توجد فيه خبرة؟

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

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

توصلنا إلى مهام الاختبار التي أتيحت لكل شخص الفرصة لممارستها وانغماس نفسه في هذه العملية. الآن المواد التي تم تطويرها بالفعل على مر السنين تتحسن فقط ، وعملية التعلم والغوص في اختبار Rest API تستغرق 1-2 أسابيع ، بينما استغرقت في وقت سابق شهرًا أو أكثر للغوص ، اعتمادًا على مدى تعقيد المشروع وحجم نموذج الاختبار.

مصدر

كيف لا تحصل على الخلط في الفروع ، المدرجات ، النشرات واختبار الكود الضروري؟

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

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

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

نبدأ الاختبار ونتفهم ما يلي:

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

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

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

ما فعلناه لتجنب المواقف المماثلة في المستقبل:

يقوم المطور بإعداد تعليمات لأخصائي البنية التحتية يشير إلى مكان النشر ، يتم تمرير التعليمات من خلال المهمة إلى jira ؛
أخصائي البنية التحتية غير مرتبك ويفعل ما أعطاه ؛
GIT, , jira ;
jira :
Gitflow , , hotfixes develop, .

, , ?

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

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

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

بالطبع ، لم يمنح هذا تغطية اختبارية بنسبة 100٪ لجميع الوظائف ، ولكنه سمح بتقليل مخاطر العيوب عبر المتصفح بشكل كبير في الإنتاج وفقًا لسيناريوهات العمل الرئيسية في النظام.

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

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

ما حصلنا عليه:

تكاليف الاختبار المحسنة ، المالية والوقت على حد سواء ، لفاصل زمني واحد قمنا بفحص كل من اختبار الانحدار وعبر المتصفح ؛
, Severity;
, , .

?

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

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

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

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

دخان - يستخدم في حالات الاختبار المدرجة في اختبار الدخان ( إجراء الحد الأدنى من مجموعة الاختبارات لاكتشاف العيوب الواضحة للوظيفة الحرجة ) ؛
الاختبار الذاتي - يستخدم في حالات الاختبار التي يتم من خلالها تطوير الاختبارات الذاتية ؛
الأولوية 1 - تُستخدم في حالات الاختبار المتعلقة بوظائف الأعمال المسماة الأولوية 1.

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

كيف يكون لديك دائمًا نموذج حالة انحدار فعلي لإصدار مخطط له و HotFix مفاجئ عند الإنتاج؟

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

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

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

فيما يلي مجموعة من حالات الاختبار في TestLink:

تم اختراع عملية تحديث الحالات في TestLink

يقوم مدير الاختبار بنسخ المجلد بحالات "Test Project 1.0.0" ويقوم بإنشاء مجموعة اختبار جديدة ، والتي تحمل رقم الإصدار المخطط التالي. اتضح المجلد مع حالات "اختبار المشروع 2.0.0".
بعد دراسة التحسينات لإصدار مستقبلي ، يتم تحليل حالات الاختبار من المجلد "Test Project 2.0.0" بحثًا عن الحاجة إلى تحديثها لإدخال تحسينات جديدة.

عند الضرورة ، قم بتحديث الحالات:

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

وبالتالي ، لدينا دائمًا مجموعة اختبار فعلية من الحالات المقابلة لإصدار الإصدار السابق من النظام ونستخدمها لاختبار HotFix ، بالإضافة إلى العمل على تحديث مجموعة الاختبار الجديدة ، والتحضير لاختبار الانحدار وعملية تثبيت الإصدار الجديد المخطط. في وقت ما ، في نفس الوقت ، يمكن الحصول على 3-4 فروع اختبار (اقرأ "مجلدات") من TestLink ، تتوافق مع الإصدارات المختلفة من النظام ، في وقت واحد ، وهو أمر مهم بشكل خاص عند اختبار التحسينات في فروع الميزات.

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

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

كيف يمكن تحسين نموذج اختبار الانحدار؟

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

لقد حان الوقت لتنفيذ أتمتة الاختبار ، وكان الغرض منها:

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

تم تطوير إطار عمل لأتمتة اختبارات واجهة المستخدم الرسومية في جافا (تم استخدام GIT كنظام إصدار للتحكم في المصدر).

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

من جانب الاختبار اليدوي الوظيفي ، تم تحسين نموذج الانحدار أيضًا.

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

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

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

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

يمكن أن تكون جولة الاختبار معقدة ، على سبيل المثال:

منح حقوق لإنشاء وتحرير وإلغاء ،
إنشاء كيان في "الحساب الشخصي" للمستخدم مع دور "متخصص" ،
,
,
,
« » «»,
, .

SLA?

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

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

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

لتحسين الوقت الذي يقضيه المختبرون ، يمكنك:

الحفاظ على قاعدة معرفية للمشروع مع استعلامات SQL النموذجية أو التي يتم مواجهتها بشكل متكرر ؛
تنظيم عملية ترتيب المهام الواردة في أداة تتبع الأخطاء بحيث يرى المختبر على لوحة المؤشر على الفور حادثًا ساقطًا ويأخذه للعمل في الأولوية الأولى ؛
إضافة عدادات وقت العد التنازلي في JIRA للمهام التي تحتوي على اتفاقيات مستوى الخدمة ؛
إنشاء نظام تنبيه للحوادث ؛
production ( — ), , , , , , production;
« » « ». .

حول "مصفوفة المعرفة" كتب أعلاه. بالنسبة إلى "مصفوفة المسؤولية" ، هذا جدول يتم من خلال القياس مع "مصفوفة المعرفة" ، كتابة كتل / وحدات / أنظمة فرعية وظيفية وأي مجموعة اختبار مسؤولة عن اختبار الوظيفة ، كقاعدة عامة ، هذا هو قائد الفريق أو كبير / اختبار الرصاص في مجموعة.

ماذا لو لم يستوعب مُختبِر كتلة / وحدة / نظام فرعي واحد الصورة الكاملة للعمل التجاري في المشروع؟

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

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

في هذه الحالة تم القيام بما يلي:

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

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

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

قبل تقديم مجموعة المقاييس في المشروع ، سألنا أنفسنا: "لماذا يجب علينا القيام بذلك؟" كانت الأهداف الرئيسية هي مراقبة جودة فريق الاختبار ، وجودة الإصدار المنتج في الإنتاج ، ومراقبة مؤشرات أداء المشاركين في مجموعة الاختبار من أجل فهم كيفية تطوير الفريق.

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

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

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

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

مثال على كيف تبدو مجموعة المقاييس والأهداف في أحد المشاريع المكتملة:

منهجية تقييم تكاليف العمالة للاختبار

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

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

المقاييس المستخدمة لإجراء تقييم تفصيلي لتكاليف الاختبار

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

وقت تسجيل الخطأ هو 10 دقائق (وقت تسجيل خطأ واحد في أداة تتبع الأخطاء).
الوقت للتحقق من الخطأ / التحسين هو 15 دقيقة (الوقت للتحقق من صحة تصحيح خطأ واحد / التحسين).
الوقت لكتابة 1 TC (حالة اختبار) - 20 دقيقة (الوقت لتطوير حالة اختبار في نظام TestLink).
الوقت لإكمال 1 TC - 15 دقيقة (الوقت لإكمال الفحوصات على حالة اختبار في نظام TestLink).
حان وقت الاختبار. إجمالي الوقت الذي تم الحصول عليه عن طريق إضافة التكاليف في قائمة التحقق للعمود "المهلة ، دقيقة".
وقت تقرير الاختبار - 20 دقيقة (وقت كتابة تقرير حسب القالب).
حان وقت الأخطاء . الوقت المخطط لتسجيل جميع الأخطاء / التوضيحات ، (وقت تسجيل خطأ / توضيح واحد * عدد الأخطاء / التوضيحات المحتمل (10 أخطاء للمراجعة - العدد المقدر للأخطاء في المراجعة)).
إجمالي الوقت على DV (التحقق من العيب) . الوقت المخطط للتحقق من جميع الأخطاء / التحسينات التي تم العثور عليها وتصحيحها (الوقت للتحقق من خطأ / تنقيح واحد * العدد المقدر للأخطاء / التحسينات).
إعداد بيانات الاختبار. يتم حساب وقت إعداد بيانات الاختبار بشكل شخصي بناءً على تجربة اختبار المهام المماثلة في المشروع الحالي اعتمادًا على معلمات مختلفة (نطاق المهمة من وجهة نظر محلل الاختبار ، وكفاءات فريق تطوير الكود (فريق غير معروف جديد أو فريق مثبت له إحصاءات عن جودة العمل) ، والتكامل بين الوحدات المختلفة ، وما إلى ذلك).

من خلال قياس التكاليف الفعلية لأحد المشاريع تم احتساب ما يلي:

ما لا يزيد عن ساعة واحدة لكل مهمة حتى 60 ساعة من التطوير ،
ما لا يزيد عن 3 ساعات لكل مهمة حتى 150 ساعة من التطوير ،
ما لا يزيد عن 4 ساعات لكل مهمة تصل إلى 300 ساعة من التطوير.

في حالات خاصة ، يمكن أن تتغير التكاليف المخططة لإعداد بيانات الاختبار بالاتفاق مع مدير الاختبار.

حان الوقت لكتابة TC . الوقت اللازم لكتابة المساهمين الأساسيين ، والذي يتم تقديره بعد أن تكون قائمة المراجعة جاهزة للتفتيش وتحديد أولويات الاختبار. بالنسبة لاختبار الانحدار ، تم وضع علامة على المساهمين الأساسيين بالأولوية 0 (عدد اختبارات الأولوية 0 * 20 دقيقة (وقت الكتابة لـ 1 مساهم بارز)).
حان وقت التراجع وفقًا لـ TC. الوقت اللازم لإكمال تكرار واحد من اختبارات الانحدار وفقًا لـ TC في نظام TestLink (عدد متوسط وقت تنفيذ TC * 1 TC (15 دقيقة)).
المخاطر تم وضع 15٪ من وقت الاختبار (تعني المخاطر جميع العمليات اليدوية ، وسقوط الحامل ، ومشكلات الحظر ، وما إلى ذلك).
إجمالي الوقت للاختبار.التكلفة الإجمالية لاختبار HL واحد (إعداد بيانات الاختبار + تنفيذ الاختبار + وقت تسجيل الأخطاء / التوضيحات + التحقق من الأخطاء / التحسينات + وقت التراجع وفقًا للمخاطر ذات الأولوية TC 0 +)) في h / h.
إجمالي الوقت للمهمة. إجمالي التكاليف لمهمة الاختبار بالكامل ، الشكل بالساعة (إجمالي وقت الاختبار + وقت التقرير + وقت كتابة TC).

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

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

الفصل 5. وصفة لعملية اختبار نظم المعلومات الجغرافية الناجحة

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

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

من عملية التحليلات:

تنفيذ قوالب المتطلبات الفنية
تنفيذ قواعد تطوير المتطلبات الفنية في مجموعة من المحللين ؛
لوضع لائحة بشأن إخطار الاستعداد للمتطلبات الفنية لفريق المشروع

- ;
;
;
:

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

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

مفاجأة للقراء المرضى.

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

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

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

إذا كنت ترغب في الانضمام إلى فريق اختبار LANIT والمشاركة في اختبار GIS ، أنصحك بمراجعة الوظائف الشاغرة في شركتنا.

تعال إلى مدارس الاختبار لدينا!

, , .

أتمنى لكم كل المشاريع الشيقة وحظا سعيدا!

ملحوظة: من الضروري إجراء مسح صغير.

ما تعلمناه من اختبار نظام معلومات الدولة