يمكنك بالتأكيد الاستغناء عن استراتيجية الاختبار إذا كان لديك عدد لا نهائي من الموظفين المؤهلين والوقت والمال. في كلمة واحدة ، القدرة على قطع إصدار واحد على مر السنين. في مثل هذه الظروف المثالية الافتراضية ، ليست هناك حاجة إلى استراتيجية ، لأنه يمكنك اختبار المنتج الخاص بك بكل الطرق الحالية طالما تريد ، وتطبيق التقنيات بأي ترتيب ، لعدة دوائر ، وعاجلاً أم آجلاً بطريقة ما ستصل إلى جودة جاهزة للإنتاج.
في الواقع ، يحرق المشروع دائمًا الموعد النهائي ، ولا تعد قدرات / مهارات عمل الفريق من المطاط ، وتتطور متطلبات المنتج باستمرار - وهنا لا يمكنك الاستغناء عن خطة جيدة. لذلك ، تأتي استراتيجية الاختبار للإنقاذ.
في هذه المقالة ، سوف نقدم أسئلة تحتاج إلى مناقشتها من أجل رسم استراتيجية اختبار ، ونوضح مع أمثلة كيفية اتخاذ القرارات بشأن أدوات الاختبار في حالة معينة.
0. دعنا نكتشف ذلك على الشاطئ
لماذا نحتاج إلى استراتيجية اختبار؟
- لتنظيم العملية في ظروف الموارد المحدودة. لذلك ، بادئ ذي بدء ، سيكون من الجيد أن ندرك ما لدينا من موارد.
- لكي يفهم جميع المشاركين في المشروع دور الاختبار ، وما يمكن أن يقدمه ، وما هي الأرباح التي سنحصل عليها من هذا. بحيث يكون لدى الجميع توقعات وفهم متساوين لما يحدث في مجال مراقبة الجودة. وأيضًا لتحديد المشاكل المحتملة التي ستصبح حتمًا واضحة في عملية المناقشة.
من يصنع الاستراتيجية؟
أولاً وقبل كل شيء ، بالطبع ، سؤال وجواب ومدير مشروع بالضرورة.
لذا ، خذ مدير مشروع الاختبار أو مدير المختبر باليد ، وصب القهوة ، وأخذ الورق ، والعلامات ، وأجهزة الكمبيوتر المحمولة ، و ... دعنا نذهب!
1. ما أنواع الاختبارات التي سنستخدمها في المشروع ولماذا
في البداية ، نعرض تذكير
جميع أنواع الاختبارات الحالية والبت في كل منها: هل سنستخدمها ولماذا. دعونا نلقي نظرة على بعض الأمثلة لكيفية اتخاذ قرار بشأن الحاجة إلى نوع معين من الاختبار.
اختبار تثبيت الإصدار
على أي حال ، حتى إذا كان التطبيق جديدًا تمامًا ويتم تثبيته (نشره) للمرة الأولى ، فأنت بحاجة إلى التحقق من كيفية انطلاقه: ما إذا كان يبدأ ، وما إذا كان من الممكن البدء في العمل معه. سواء كان تطبيق جوال أو سطح مكتب أو ويب.
بالنسبة لتطبيقات الويب ، من المفيد مناقشة كيفية التحقق من عدم فقدان البيانات بعد التحديث. ما نوع السلوك الذي نتوقعه من جلسة نشطة.
بالنسبة لتطبيقات سطح المكتب والجوّال ، تحتاج إلى التفكير في طريقة لتقديم التوزيع الجديد للمستخدم وعملية التحديث ، التي يتم إطلاقها من قبل المستخدم.
بالنسبة لجميع المشاريع ، من المفيد مناقشة أشياء مثل تدفئة النظام: تثبيت الدلائل ، وإعداد المستخدمين والبيانات الأخرى التي يحتاجها المستخدم لبدء استخدام النظام.
اختبار الأداء
ستؤثر هذه العوامل على القرار: كم عدد المستخدمين الذين سيعملون في النظام ، وكم البيانات التي ستتم معالجتها.
| تعطى | الحل |
|---|
| نحن نعلم أن 10 أشخاص سيستخدمون المنتج. ونحن نعلم أنهم سوف يسلمون جداول عدة آلاف من السجلات. | من المنطقي التخطيط لاختبار الحجم بكميات كبيرة من البيانات. |
| نحن نعلم أنه أثناء استخدام المنتج ، سيقوم المستخدمون بتحميل العديد من ملفات الوسائط على خادم العميل. | تحتاج إلى معرفة نوع التحميل الذي تم تصميم هذا الخادم له ، ووضع هذه البيانات في الاعتبار. |
| يتم استخدام التطبيق من قبل عدة أشخاص في الأسبوع ، وكمية البيانات ضئيلة. | اختبار الأداء غير مطلوب. |
اختبار الانحدار
يستغرق الفحص الكامل للنظام بأكمله دائمًا الكثير من الوقت. لذلك ، لاتخاذ قرار ، من الضروري تقييم مدى الملاءمة: كم من الوقت مطلوب للانحدار الكامل ، والمخاطر التي قد تحدث إذا لم نقم بذلك.
| تعطى | الحل |
|---|
| نطرح الإصدار الأول من وحدة منتج أو برنامج. | اختبار الانحدار غير مطلوب. |
| المشروع كبير جدًا ، ويستغرق التراجع الكامل قبل إصدار الميزات الجديدة وقتًا مشابهًا لفترة التطوير. معدل العرض المطلوب لا يسمح بذلك. | نقرر أننا لا نجري اختبار الانحدار ، ولكن نولي المزيد من الاهتمام لأنواع أخرى من الاختبار والرصد.
|
| يتم تغطية التفاعل بين الخدمات الدقيقة من خلال اختبارات العقد. | الانحدار الكامل غير عملي. في إطار الاختبار اليدوي ، نجري انحدارًا للوظائف بناءً على توصية المطور. |
اختبار التكامل
لتحديد الحاجة إلى اختبار التكامل ، من المفيد سرد جميع الأنظمة الخارجية التي يتفاعل معها المنتج والإشارة إلى البيانات التي نتلقاها ونرسلها.
| تعطى | الحل |
|---|
| يتم نقل بيانات المبيعات من البوابة إلى النظام التحليلي. | من المهم ليس فقط التحقق من أن المبيعات قد اختفت ، ذهبت بالتنسيق الصحيح ، ولكن أيضًا أنها جاءت بالتنسيق الصحيح - لم يتم فقدان أي شيء على طول الطريق. |
اختبار التوطين
من المهم الإجابة عن أسئلة حول المشروع:
- اللغات التي يجب دعمها
- هل نوفر توصيلات توطين إضافية أثناء تشغيل الحل ،
- في أي البلدان سيعمل مستخدمونا ،
- سيكون هناك مبيعات وبأي عملات
- هل تحتاج للعمل مع المناطق الزمنية؟
| تعطى | الحل |
|---|
| يحتوي النظام على لغتين: الروسية والإنجليزية. | من المنطقي مناقشة الكيفية التي سنفهم بها الواجهة التي تعرض بها اللغة للمستخدم. |
| يطلب العميل جعل التطبيق متعدد اللغات. | يجدر الإجابة على الأسئلة حول كيفية التحقق من النصوص ، ومن أين سنحصل على النصوص باللغة العربية ، وكيف سيتم تكييف الشاشة للنص المكتوب من اليمين إلى اليسار. |
عبر المتصفح ومنصات مختلفة
لا يمكننا التحقق من التشغيل الصحيح لتطبيق الهاتف المحمول على جميع الأجهزة بشكل عام. في حالة تطبيق ويب ، يطرح السؤال على الفور: هل سندعم IE9؟ قبل إدخال هذا النوع من الاختبارات في الإستراتيجية ، نقوم بتحليل (إذا كان الحل يعمل بالفعل) أو نفترض (إذا لم يعمل بالفعل) ما الذي سيستخدمونه من أجله.
| تعطى | الحل |
|---|
| مستخدمو تطبيق الجوّال هم موظفون في جميع أنحاء البلاد. | نحن ننظر إلى الإحصائيات الموجودة حول استخدام منصات تطبيقنا ونتخذ قرارًا بشأن أي منها سنختبره. |
| تطبيقنا لديه مستخدمين من الشركات على الآلات الثابتة. | على الأرجح ، يمكننا أن نوصي باستخدام متصفح واحد فقط. وبالتالي تقليل وقت الاختبار والدعم للتوافق بين المتصفحات. |
وبالمثل ، تحتاج إلى تحليل جميع أنواع الاختبارات الأخرى:
- وظيفية (أجريت أم لا) ،
- القبول (من يقوم بها وكيف) ،
- UX / UI (ما هي المعايير الموضوعية لواجهة جيدة)
- وحدات ووحدة (من يكتب اختبارات العقد ، ومن يكتب اختبارات الوحدة وما إذا كنا نكتبها على الإطلاق) ،
- اختبار الأمان (الذي يضمن أمن البيانات ومدى مقاومة النظام للقرصنة) ،
- الفشل والاسترداد (كيف سيتصرف النظام في حالة الطوارئ)
وغيرهم.
2. أولويات الاختبار
تحدث القوة القاهرة في جميع المشاريع ، لذا من المفيد أن يكون لديك ورقة غش مع خطة مدروسة جيدًا ، بدلاً من الإمساك بأزرار عشوائية.
في الوضع العادي ، تكون الأولويات ذات المغزى مهمة أيضًا. على سبيل المثال ، يجب التخطيط لتطوير الاختبارات الذاتية مع مراعاة الأولويات: أولاً وقبل كل شيء ، فإن السيناريوهات الأكثر أهمية هي آلية (اختبار الدخان).
| تعطى | الحل |
|---|
| يستخدم برنامجنا في المطارات لبيع الخدمات للمسافرين عند ركوب الطائرة. وإذا حدث خطأ ما في هذه اللحظة ، فلن يكون لدينا الوقت لإصلاح المشكلة. لذلك ، لا ينبغي أن تكون هناك أخطاء! | نتحقق من سيناريو الاستخدام في المطار في المقام الأول. |
3. بيئة العمل
من الضروري التفكير والتنسيق مع الفريق حول البيئات المطلوبة للعمل ومن سيستخدمها. كقاعدة ، يكفي 2-3 محيط ومبيعات.
| تعطى | الحل |
|---|
| في مشروع CD / CI ، تمت كتابة اختبارات الدخان للاختبار الأولي للوظائف. | نحن بحاجة إلى بيئة للتجميع الأساسي للكود في فرع واحد ، وإجراء اختبارات الدخان ، حيث يتم إغلاق الأنظمة الخارجية بواسطة بذرة. تحتاج أيضًا إلى بيئة للاختبار اليدوي والتكامل مع خدمات العملاء (QA). |
| تُعقد جلسات اختبار بيتا بانتظام. | نحن بحاجة إلى بيئة تكون مرئية "بالخارج" ، أكثر استقرارًا من بيئة ضمان الجودة. |
4. عمل المختبر في المشروع
من المنطقي مناقشة جميع الأنشطة التي نتوقعها من المختبر في المشروع مسبقًا ، لأنها ليست بالضرورة نفسها في جميع المشاريع. قد يكون مفاجأة لشخص ما في الفريق أن المختبر يفعل شيئًا أو لا يفعل شيئًا.
سيساعد هذا البند المديرين على فهم درجة الكفاءة المطلوبة من المختبر ، وما هو الوقت المتوقع. بالنسبة للمشاريع القائمة ، من المهم أيضًا الإشارة إلى أننا (QA) قادرون حتى يفهم المدير ما يعنيه.
على سبيل المثال ، يمكن أن يكون:
- تقييم أهداف العدو للتأكد من اكتمالها واتساقها ،
- تقييم تكاليف العمالة للاختبار ،
- إعداد قوائم مرجعية للاختبار (أو حالات الاختبار) ،
- مراجعة البرنامج النصي autotest
- كتابة الاختبارات الذاتية الوظيفية ،
- الاختبار اليدوي المباشر ،
- نشر التغييرات على البيئة ،
- تحديث استراتيجيات الاختبار ، إلخ.
5. توثيق الاختبار على المشروع
من الضروري الاتفاق على الشاطئ ، وربما مراجعة نموذج وثائق الاختبار بشكل أكثر انتظامًا:
- ما وثائق الاختبار التي سنجريها في المشروع ،
- سنكتب حالات الاختبار
- هل قوائم مرجعية
- وكم مرة لتحديث هذه الوثائق.
| تعطى | الحل |
|---|
| تمت كتابة حوالي 300 حالة اختبار بالفعل لحوالي ثلث وظائف النظام. يجب ألا تتم مراجعتها بشكل دوري فحسب ، بل يجب أيضًا تحديثها من وقت لآخر. | في ظروف الموارد المحدودة ، قررنا عدم العمل مع حالات الاختبار ، ولكن لتقييد أنفسنا بفحص القوائم لكل مهمة محددة. ونتيجة لذلك ، فإننا نوفر الوقت على المستندات الداعمة دون فقدان جودة الاختبار. |
6. كيف يتم إنشاء حالات الاختبار
تعتمد ظروف التشغيل والسيناريوهات على الحل المحدد ، لذا تأكد من مناقشة:
- ما تقنيات تصميم الاختبار التي من المنطقي استخدامها. كجزء من هذه الفقرة ، من المفيد عمل قائمة بالكائنات التي يعمل معها التطبيق وفئات التكافؤ الخاصة بها.
- ما هي الاستدلال وتجربة الحياة المبتذلة التي تساعد على التوصل إلى نصوص اختبار لمشروع محدد. بالنسبة للتطبيقات المحمولة ، من الملائم استخدام الاستدلال القياسي ، على سبيل المثال ، "I SLICED UP FUN".
| تعطى | الحل |
|---|
| في مشروع التأمين ، يجب على المستخدم (الوكيل) فحص الجهاز ، حيث من الضروري التقاط الصور وتحميلها على الخادم. يفرض الحس السليم أنه لا يوجد wifi تقريبًا في المرائب. وأحيانًا ، لا يوجد اتصال محمول. | لذلك ، تحتاج إلى التحقق من التطبيق ليس فقط عند العمل مع 3G ، ولكن أيضًا في غياب الاتصال على هذا النحو. |
| يعد أي إجراء للمستخدم في تطبيق الهاتف المحمول لشركة الطيران جزءًا من السيناريو. على سبيل المثال ، لا يمكنك إصدار تذكرة دون إنشاء حجز أولاً. | لذلك ، فمن المنطقي استخدام تقنية "حالة الاستخدام". |
7. إجراء للعمل مع تعقب
في المتتبعات المختلفة ، تختلف إمكانيات وأنواع المهام. استنادًا إلى قدرات المتتبع ، ننصحك بالاتفاق على من وعلى أي مبدأ يحدد أولوية المهام ، في أي نوع من المهام لترتيب الأخطاء والمهام.
تحدث بالنقاط الرئيسية مع الفريق:
- كيف سنميز بين الأخطاء التي اكتشفناها والأخطاء التي اكتشفناها العملاء (وما إذا كنا بحاجة إلى التمييز بينها) ،
- كيفية إجراء التحسينات
- هل من الضروري التمييز بين التحسينات التي اخترعناها لأنفسنا عن تلك التي طلبها العميل. كيف؟
- ما هي الحالة التي يجب أن يرتكبها الخطأ إذا لم يحدث مرة أخرى ،
- ما هي الحالة التي تعتبر نهائية.
| تعطى | الحل |
|---|
| يخلق المختبر خطأ. لا يمكن للمطور إعادة إنتاجه ، وترجمته إلى الحالة المرفوضة. | يقوم المختبر بإعادة فحص المهمة وتعيين الحالة إلى مغلق (نهائي) إذا اختفى الخطأ حقًا ، أو تحسين الوصف وإعادته إلى جديد. |
| يعين العميل مهمة المراجعة. يفهم المطور أنه ليس لديه بيانات كافية للتنفيذ. | يضع المطور المهمة في حالة الملاحظات. |
(كتبنا المزيد حول طرق وصف الأخطاء وقصة المستخدم في
هذه المقالة ).
8. معايير بدء وإنهاء الاختبار
إذا أخذ المختبر أي مهمة في أي وقت ، فهذا ليس ترتيبًا ، بل فوضى. لأن المهمة قد لا تكون جاهزة. أو جاهز ، ولكن ليس مجانيًا. أو جاهز ، منشور ، ولكنه يعتمد على مهام أخرى غير جاهزة بعد. ونتيجة لذلك ، يقضي المختبر الوقت ويشد الأعصاب بحثًا عن الأخطاء وإصلاحها ، ولكن في الواقع عليك الانتظار فقط. لذلك ، نتفق في أي نقطة تبدأ وتنتهي منطقة مسؤولية ضمان الجودة حول المهمة.
في المراحل الأولى من تطوير المشروع ، يتم تحديد جاهزية المهمة / النسخة بالعين.
مع نمو الوعي الذاتي ، نتفهم أننا بحاجة إلى معايير واضحة بأن المهمة / النسخة جاهزة. بحيث يكون هذا القرار شفافًا للجميع ، وليس "يشعر المختبر بالغنائم بأن كل شيء طبيعي". على سبيل المثال ، في ظل ظروف قرص مضغوط مضبوط ، نعتقد أن المهمة جاهزة للاختبار بمجرد نشرها في بيئة ضمان الجودة وتتمتع بالحالة التي تم حلها.
| تعطى | الحل |
|---|
| تم إعداد عملية في المشروع يتم فيها تجميع قائمة مرجعية للاختبار لكل مراجعة. | نعتبر أن المهمة تم التحقق منها إذا تجاوزنا جميع النقاط في قائمة التحقق. |
| يعمل المشروع على العدو. | يعتبر Sprint جاهزًا إذا كانت جميع التحسينات في الحالة المغلقة ولم تكن هناك أخطاء في الأولوية عادي وأعلى. |
| قام المشروع بتجميع قائمة الوظائف حسب الأولوية. | نعتقد أن الإصدار جاهز للإصدار إذا كانت الوظيفة من النقاط الأولى في القائمة تعمل بنجاح. |
| قام المشروع بكتابة حالات اختبار وإجراء اختبار انحدار قبل الإصدار. | يعتبر الإصدار جاهزًا للإصدار إذا لم يتم العثور على أخطاء ذات أولوية عادية أو أعلى استنادًا إلى نتائج اختبار الانحدار (أو لم تكن النسبة المئوية للسيناريوهات غير الناجحة أعلى من 5). |
9. أدوات العمل
القسم مفيد بعد ذلك من أجل وضع المهام المسؤولة (للمدير والمدير) بالفعل في مرحلة التخطيط للاختبار والحصول على جميع الأدوات اللازمة في بداية العمل.
يجدر مناقشة مثل هذه القضايا:
- ما الأدوات التي نحتاجها لإجراء وثائق الاختبار ،
- ما هي الأدوات التي يمكن أن تعد بيانات الاختبار ،
- ما الأدوات اللازمة للأتمتة.
| تعطى | الحل |
|---|
| لوصف الوظائف المنفذة ، قررنا استخدام الخرائط الذهنية. | يعمل الأشخاص في الفريق على أنظمة أساسية مختلفة ، لذلك تحتاج إلى اختيار تنسيق ملف خريطة ذهنية يمكنك العمل معه في أنظمة التشغيل Windows و Linux و Mac. |
| اتفقنا على أننا بحاجة إلى أتمتة المشروع. | لذا ، نحتاج إلى أدوات تسمح لنا بإعداد بيانات الاختبار (على سبيل المثال ، لف البرامج النصية على قاعدة البيانات) ، وتتيح لنا البدء في خط الأنابيب (على سبيل المثال ، newman) ، وتتيح لنا إنشاء بذرة (على سبيل المثال ، WireMock). |
10. أدوات تقييم ومراقبة جودة المشروع
في هذا القسم ، نقترح الموافقة على ماهية مؤشرات الأداء الرئيسية لتقييم صحة التطبيق (بالإضافة إلى الحساب الواضح لتغطية الاختبار). يجب أن يكون هذا المؤشر قابلاً للقياس والتحقيق. على وجه الخصوص ، فهم والإجابة على الأسئلة التالية:
- كيف سنتتبع الأخطاء في همز
- كيف سنجمع التعليقات من المستخدمين ،
- كيف سنجمع إحصاءات حول استخدام ميزاتنا.
| تعطى | الحل |
|---|
| بعد إصدار ميزة جديدة للنظام ، يتم تكوين مراقبة الاستخدام (على سبيل المثال ، عدد مبيعات الخدمة). | الانخفاض هو سبب للتحقيق. ربما لا تعمل الميزة كما هو متوقع ، أو لم نقم بتنفيذ جزء من البرنامج النصي. |
| لقد قمنا بتكوين البرنامج لمراقبة سرعة أداء العمليات الأساسية. | سيكون معيار جودة العمل هو أنه مع تدفق المستخدمين ، لا تنخفض سرعة التنفيذ. |
الخلاصة
لا توجد استراتيجية اختبار واحدة وشاملة مناسبة للجميع. تم تصميمه بشكل فردي لكل مشروع.
- من المهم أن نفهم أن الاستراتيجية يجب ألا تكون غاية في حد ذاتها - إنها مجرد أداة تسمح لنا بتحقيق أهدافنا.
- من الطبيعي جدًا أنه ليس من الممكن دائمًا الإجابة فورًا على جميع الأسئلة المطروحة. هذه مناسبة للحديث مرة أخرى مع العميل أو مستخدمي المنتج.
- ينمو المشروع ، وإذا كان من السابق لأوانه أمس أن يزعجك الإنتاجية ، فمن المحتمل أن يكون الوقت قد حان غدًا. لذلك ، بعد وضع استراتيجية ، من المهم تحديثها وتجديدها بانتظام وإدخال التغييرات على الفريق.
- بعد كتابة استراتيجية ، يصبح من الواضح عادة أين الفشل في الاختبار وما يجب القيام به. هذه مناسبة لتحديد الأهداف ومشاهدة الديناميات و ... تحديث الاستراتيجية بعد مرور بعض الوقت.