بادئ ذي بدء ، من بين الناس ، يطلق على جميع مهندسي ضمان الجودة ("بطريقتنا الخاصة" ، مهندسي قسم الجودة) اختبار. هذا ليس صحيحًا تمامًا ، في اختبار الواقع ليس سوى جزء من مهام ضمان الجودة ، ولكن من يهتم. لذلك ، دعنا نذهب في الاتجاه العام وسوف نستخدم محرك المعتاد للجميع.
فما الذي يحدد اختبار جيد؟ لن ننحدر إلى التفاهات ونقول: الانتباه والمثابرة والصبر والفضول والموهبة ، وكل شيء يكسر وغيرها من الهراء. هذا كل شيء ، بالطبع ، مهم ، لكنه ليس الشيء الرئيسي. بادئ ذي بدء ، ينبغي أن يكون لدى الشخص إحساس الحس السليم والمسؤولية.
على سبيل المثال ، يقولون ، الشيء الرئيسي هو امتلاك الموهبة لكسر كل شيء. في كثير من الأحيان يمكن أن تسمع ، يقولون أنه لن يلتقط ، سوف يكسر كل شيء. هذا ، بالطبع ، أمر يستحق الثناء ، لكن وظيفة الفاحص ليست هي الشيء الرئيسي لكسر شيء ما. هنا ، سوف يأتي تعريف لمساعدتنا ، والتي ليس من الصعب العثور على ويكيبيديا.
اختبار البرمجيات هو عملية البحث ، واختبار منتج البرنامج ، بهدف التحقق من المراسلات بين السلوك الحقيقي للبرنامج والسلوك المتوقع له في مجموعة محددة من الاختبارات المحددة بطريقة معينة.
يوضح أن هناك متطلبات محددة للبرنامج ، وأنه من الضروري الوفاء بها. إذا كسر المختبر البرنامج بدلاً من التحقق مما إذا كان يؤدي الوظائف المعينة له على الإطلاق ، ونتيجة لذلك ، يمكن أن يحصل على زبالة مستقرة ، ولكن ليس من الضروري ، للعميل.
أنا أفهم أن كل شخص يحب القصص ، وكيف قام شخص ما بالثغرات ، لديهم. بالنسبة لعملي ، عملت في أماكن مختلفة وفي مشاريع مختلفة ، لذلك كنت شاهدًا بنفسي أو سمعت العديد من القصص من زملائي. البعض منهم على استعداد لنقول. حسنًا ونعم ، المانترا اللازمة: كل الصدف عشوائية ، ويتم اختراع الأسماء.
اختبار وأكثر من ذلك
لنبدأ بالترتيب. كما قلت في البداية ، فإن الاختبار ليس فقط الاختبار. كيف تحب لعبة الكلمات هذه؟ في الشركات الكبيرة ذات السمعة الطيبة ، يحاولون ربط فريق الاختبار بالمشروع في مرحلة مبكرة ، أي في مرحلة جمع المتطلبات ، ولكن هذا لا يتم في كل مكان وليس دائمًا.
مرة واحدة أثناء اختبار القبول ، بدأ المستخدم خطأ حرج ، ل أحد المتطلبات لم يتم الوفاء به. كان جوهر الادعاء أن المستخدم على الشاشة لم يجد السمة التي يحتاجها (لأولئك في الخزان - حقل ذو قيمة). بالطبع ، صعد المختبر إلى المواصفات ، وتحقق من أن هذه السمة كانت موجودة في التطبيق ، وانطلق البهجة لإخبار المستخدم بأن كل شيء على ما يرام.
أنت تفهم بالفعل أن التاريخ لا ينتهي هناك.
حاول الفاحص أن يشرح للمستخدم ما كان مخطئًا فيه ، حيث واجه جزءًا من السلبية والسخط. جلسه المستخدم واكتشف المتطلبات التي تم على أساسها كتابة المواصفات. اقرأ أحد هذه المتطلبات تقريبًا حرفيًا كما يلي: "يجب عرض السمة على كل شاشة." جملة واحدة ، ولكن كم معنى! ثم فتح التطبيق وبدأ التنقل بشكل عشوائي على شاشات مختلفة ، قائلا: "وأين هذه السمة؟" من الواضح أن المستخدم سخر علنا ، ولكن من الناحية الرسمية كان لديه الحق في القيام بذلك. المشكلة هي أن التصعيد استمر ، وشارك المزيد والمزيد من الناس في مناقشة المشكلة. في نهاية المستخدم ، إلى جانب الفاحص نفسه ، أقنعه العديد من مديري المشتريات وحشد من المحللين ، وكان مصرا وطالب المستحيل.
ونتيجة لذلك ، تم العثور على حل وسط ، وفي الطلب ظهرت قائمة بالشاشات اللازمة التي يجب أن توجد عليها السمة ، ولكن هذا تطلب تغييرات كبيرة في رمز البرنامج ، وبالتالي ، كان لا بد من إعادة تشغيل دورة التطوير بأكملها ، ولكن بوتيرة متسارعة. أنفقت الشركة أموالاً إضافية ، ناهيك عن تكاليف السمعة ، لضغوط العاملين ومعالجتهم. كان يمكن تجنب كل هذا إذا كان المختبر متصلاً في بداية المشروع ويمكنه رؤية متطلبات الغموض - على الأقل ، أو لاحقًا ، للتحقق من المواصفات للتأكد من الامتثال للمتطلبات. ونعم ، غالبًا ما يعمل المختبرون مع مستخدمين حقيقيين بشكل مباشر ، الأمر الذي يتطلب منهم التعامل مع الحد من التوتر والتحليل النفسي والإدراك الخارجي.
لا التعصب
نذهب إلى أبعد من ذلك ، ومن المفارقات للغاية ، تتميز عملية الاختبار نفسها بحكاية ملتحية:
مرة واحدة يدخل اختبار شريط.
يركض في الشريط.
تزحف إلى البار.
الرقص ، تخترق الشريط.
التسلل إلى البار.
اقتحام العارضة.
يقفز إلى البار.
أوامر:
قدح من البيرة
2 كوب من البيرة
0 أكواب من البيرة
أكواب 999999999 من البيرة ،
سحلية في كوب
-1 كوب من البيرة
أكواب البيرة qwerty.
يأتي العميل الحقيقي الأول إلى الحانة ويسأل عن مكان المرحاض. ينفجر البار في النيران ، يموت الجميع.
ليس الجميع يفهم أنه يمكنك اختبار ما لا نهاية. لا يمكن تحقيق المثل الأعلى ، وللمشاريع مواعيد نهائية محددة للغاية تناسبها. لذلك ، كان هناك اختبار واحد ، عند اجتيازه لحالة الاختبار ، يفشل باستمرار. مع مرور الوقت ، بدأ المشروع بالفعل في نهايته ، وتغلب المطور على جميع المشكلات التي تم العثور عليها. وهنا يعلن المختبر أن الوظيفة الأساسية الضرورية لا تعمل. الجميع يفهم: لن يعمل على إصلاحها في الوقت المحدد.
خلال الإجراءات ، اتضح أنه: أثناء الاختبار ، لم يتم إكمال البرنامج النصي بالكامل حتى اللحظة المشؤومة. عثر المختبر على عيب في بداية العملية ، التي اختبرت ، وبدأت تذكرة وألقيت في منتصف الطريق. في الوقت نفسه ، كان من الممكن مواصلة الاختبار ، لأنه كل الأخطاء التي عثر عليها لم تمنعه. في وقت لاحق ، الفريق بأكمله لديه الإجهاد والمعالجة التقليدية.
بالمناسبة ، يلتزم بعض المستخدمين بهذا عند اختبار القبول ، ويعلنون أن الخطأ حرج وإنهاء العمل. هذا يعقد العمل إلى حد كبير ، لأنه في الدفق العام للمشاكل ، والتي قد لا تكون مشكلة بشكل عام ، يتم فقد الأخطاء الهامة بالفعل.
المعنوي هو: اختبار جيد لن يتوقف أبدًا عن العثور على الخطأ الأول الذي يصادفه. سيتم تشغيل البرنامج النصي بأكمله من البداية إلى النهاية ، مع تسجيل جميع الأخطاء التي تم العثور عليها في وقت واحد ، وإذا حدث خطأ أثناء حظر الممر ، فسيبحث عن الحل البديل ، أي الحل. وعندما يقتنع بأنه لا توجد حلول ، سيتوقف.
هناك تحذير واحد. في معظم الأحيان ، يتم تنفيذ المشروعات في إطار مواعيد نهائية ضيقة ، أو ليست ضيقة للغاية ، ولكن محددة تمامًا. يحدث أن يتم رش الشخص على الاختبارات التي لا تنتهي من حقل واحد ، وإدخال كل المتغيرات الممكنة والمستحيلة من القيم. في الوقت نفسه ، وفقًا لمتطلبات العملاء ، من الضروري التحقق من الوظيفة التي يؤديها التطبيق ، وإن كان ذلك باستخدام القيمة من هذا الحقل. نتيجة لذلك ، يواجه خطر تضييع الوقت وعدم التحقق من الشيء الرئيسي. يجب أن يكون المختبر قادرًا على تقييم نقاط القوة والأماكن الحرجة للتطبيق بشكل صحيح. لا حاجة لاختبار تلك الأماكن التي لا تتطلب اختبار. الشيء الرئيسي هو أن التطبيق يجب أن يحقق الوظيفة المعينة له. تحتاج أولاً إلى تحقيق تنفيذ سيناريو مباشر ، ثم تحسين جودة التنفيذ إلى المستوى المطلوب.
لساني عدوي
علاوة على ذلك ... يمكن أن تكون مشاكل الوثائق ليست فقط للمحللين ، ولكن أيضًا للمختبرين. لوحظ مرارًا وتكرارًا أن المطورين ليسوا وحدهم قادرين على وصف محتويات التذكرة بوضوح في الحقل المقابل لها ، ولكن المختبرين أنفسهم لا يمكنهم كتابة ترتيب الإجراءات التي تسبب الخطأ بشكل صحيح. هذه مشكلة كبيرة شخص ما ببساطة لا يفهم لماذا يحدث الخطأ ، ولا يكلف نفسه عناء معرفة الخطوات. شخص ما لديه مشاكل في القراءة والكتابة على الإطلاق.
ماذا يعني كل هذا؟ هنا الجواب والقنفذ مفهوم ، ولكن مع الأمثلة ، بالطبع ، أكثر إثارة للاهتمام.
هناك مجموعة من المختبرين ، الذين يرون خطأً أمامهم ، يسجلون ببساطة تلك المليون خطوة ، بما في ذلك الزبالة التي أدت إلى الخطأ. إنهم لا ينتجون الخطأ ولا يكتشفون بالضبط ما الذي يسببه. في الوقت نفسه ، يمكنهم كتابة مجموعة من الخطوات غير المرتبطة بهذا الخطأ على الإطلاق. سيحاول المطور التكاثر ، وسيغلي رأسه في مرحلة ما ، وسيذهب شخصياً للتعامل مع المختبر. سوف يفهمون معًا وسوف يقضي كلاهما كثيرًا من الوقت على الاتصالات غير الضرورية. لحسن الحظ ، يتم علاج كل هذا بسرعة من خلال الوقت والخبرة ، على الرغم من وجود حالات سريرية.
محو الأمية يزداد صعوبة. في ممارستي ، كانت هناك حالة عندما احتاج فريق ضمان الجودة إلى تصحيح وصف عشرات التذاكر ، لأنه يجب أن يتم إرسالها إلى العميل في تقرير مرحلي. حدث هذا لأن معظم الفريق لم يتمكن من صياغة أفكارهم بشكل صحيح باللغة الإنجليزية.
ولكن هناك أيضا مشاكل مع الروسي ، والحمد لله ، في كثير من الأحيان أقل. كل شيء هو نفسه هنا ، وصف مكتوب بشكل سيء يؤدي إلى حقيقة أن التذكرة ، مثل كرة القدم ، تبدأ في الركض بين الناس دون الدخول في المرمى. من الجيد أن يكون الفريق في نفس الغرفة ويمكنه التحدث دون الاستيقاظ من الشاشة. أكثر صعوبة - إذا تم توزيع الفريق. سيء للغاية ، إذا كان متعدد اللغات. أسوأ شيء يمكن أن يحدث في النهاية هو أن التذكرة سوف تتم بشكل غير صحيح بسبب سوء الفهم وسيتم إعادة فتحها ألف مرة. وحتى بالنسبة للعميل سوف يطير بعيدا في واحدة من الإصدارات مع المنطق المقلوب.
مساحة شخصية
مشكلة أخرى هي مقاعد الاختبار وبيانات الاختبار. في الشركات المختلفة ، يحدث هذا بطرق مختلفة ، لكن غالبًا ما يحدث أن يمنح الموظف حقوقًا لخادم العميل العامل أو يتم منح قاعدة بياناته للاختبار. يبدو أن ما يمكن أن يحدث الخطأ؟
ولكن dofiga لما ... إذا كان شخص ما لديه حق الوصول إلى خادم العميل ، فمن ناحية ، يمكنك النظر في المشاكل من الرتب الأولى وعدم ارتكاب خطأ حول الصورة. ولكن هناك خطر إفساد بيانات العميل ، مما قد يؤدي إلى عواقب وخيمة. أنا صامت بالفعل بشأن الحالات التي يكون فيها هذا الوصول محظورًا بشكل عام بموجب القانون.
كانت هناك حالة عندما سقط عميل عن الخادم لمدة 3 أيام. لم يتمكن المطور طوال هذا الوقت من فهم سبب حدوث ذلك ، وبحث بشكل محموم عن خطأ ، وتعرضت الشركة لخسائر. ونتيجة لذلك ، اتضح أن الشركة قد عينت الهنود للاستعانة بمصادر خارجية ، حيث أعطى الأشخاص ، دون مزيد من اللغط ، جميع حقوق المسؤول. للجميع - وهذا يعني حتى تلك الفتاة التي كانت تعمل لمدة 3 أيام في الشركة ، ولم يكن هناك جهاز كمبيوتر في قريتها ، لذلك لديهم فترة مواعدة أقصر. لكن تبين أن الفتاة كانت موهوبة بشكل رهيب ، تمكنت من العثور على الجوهر الأساسي في لوحة المشرف وتغيير نوعها ، وبعد ذلك سقط كل شيء بشكل طبيعي وتوقف عن العمل. من السهل تخمين كيف أنشأت سلم السلم الوظيفي بعد ذلك.
نفس الهراء ومع البيانات من العميل. مرة أخرى ، أنا لا أتحدث عن الحالات التي يحظرها القانون. إذا كان من الممكن العمل على بيانات حقيقية ، فهذا أمر جيد ، ولكن يجب على المرء أن يكون حذراً في ذلك. ربما سمع الجميع قصصًا حول إرسال رسائل أو رسائل عشوائية من خادم اختبار إلى مستخدمين حقيقيين. هذه ليست نكات. يحدث هذا بالفعل ، وفي كثير من الأحيان. حسنًا ، إذا كانت هذه الرسائل مؤهلة كرسائل اختبار ولديها محتوى عاقل ، لكن يحدث أن ينتفخ الأشخاص ويكتبوا ما يندم عليه فريق تطوير التطبيق بأكمله.
لحظات تنظيمية
لقد بدأت بالفعل في تحمل نفسي مع وفرة من النص ، لذلك الأخير. يجب أن يزود المختبر رئيسه باستمرار بمعلومات حديثة عن عمله. وفقا لمثل هذه التقارير ، إذا تم القيام به بشكل صحيح ، فإن الرئيس يجعل استنتاج حول حالة المشروع ككل. ليس فقط حول عمل أحد الفاحصين أو فريق الاختبار بأكمله ، ولكن أيضًا حول عمل فريق التطوير والمرحلة التي يوجد فيها المشروع. كما أن هذه التقارير تسمح بالتخطيط للتحليل للإصدارات المستقبلية ، إلخ ، إلخ.
هناك العديد من الأمثلة التي لم يتم فيها هذا العمل أو تم القيام به بطريقة غير ملائمة ، والتي شعرت السلطات من خلالها بعدم اليقين بكل ما يترتب على ذلك من عواقب. سأخبرك ألمع.
مرة واحدة وضعت اختبار على مشروع جديد. لأنه لم يعرفه جيدًا ، تم تكليفه بمهمة فرز الملاحظات وتسجيلها. نظرًا لأنه كان شيئًا غير رسمي ، فقد اتفقنا على أن نكتب باللغة Googledock. بدأ الرجل في تنفيذ المهمة ، وبعد أسبوع من هذه المهمة تم فحصها ، وتم اختبار المختبر على الكتف واستمر في العمل. بعد مرور أشهر ، بدأت السلطات تقلق سبب عدم وجود تذاكر في bugtracker ولا يتم عمل أي شيء في المشروع. لقد بدأنا في معرفة ذلك ، واتضح أن الشخص ما زال يكتب في ذلك غوغلدوك ذاته. لم يقل أحد "قعادة ، لا تطبخ" ولم يتوقف عن الاختبار ، واستمر بانتظام في فهم وتسجيل الملاحظات ، بينما لم يخبر نفسه. هناك أخطاء ، ووجدها ، لكنه لم يخبر أحداً ، لكنه كتبها فقط في ملف ، وقد نسيها الجميع بعد أسبوع.
في الواقع ، كان التوقع هو أن الشخص سوف يستمر في العمل بشكل رسمي بالفعل ، أي في تعقب الأخطاء ، منح مطوري التذاكر تذاكرهم ، ولكن هذا لم يحدث. يبدو أن الرجل لم يفعل أي شيء ، على الرغم من أنه يعمل. من الواضح أن المشكلة لم تكن من جانب الفاحص فقط ، ولكن إذا قام بتقرير منتظم عن أنشطته ، فيمكن تجنب سوء التفاهم.
غالبًا ما يؤدي الافتقار إلى المعلومات إلى الشعور بسوء اختبار المنتج ، وهذا الجزء أو ذاك من الوظيفة لم يتم اختباره. لمنع حدوث ذلك ، تحتاج إلى تقديم تقارير مفصلة ، وهذا مهم بشكل خاص للمشروعات الكبيرة.
استنتاج
عليك أن تفهم أن ضمان الجودة هو ، في الواقع ، محامي المستخدم. في أي موقف غير مفهوم يتعلق بالتطبيق ، يجب على الفاحص وضع نفسه في مكانه. إذا ، من خلال هذا التلاعب البسيط بالوعي ، اتضح أن التطبيق غير راض عن شيء ما ، فأنت بحاجة إلى بدء تذكرة. وقد يكون هذا زرًا في المكان الخطأ أو تافهًا آخر من وجهة نظر المطور ، ولكن غالبًا ما يحدث أن يتحول هذا التافه للمستخدم إلى جحيم ونقطة تهيج. كمثال ، يمكنك أن تأخذ عددًا كبيرًا من النوافذ المنبثقة في التطبيق. نعم ، يؤدي البرنامج وظيفته ، لكن من الصعب استخدامه ، لأنه يستغرق تنفيذ هذه الوظيفة الكثير من الوقت والجهد من قبل مستخدم مضطر للضغط على مجموعة من الإطارات الإضافية مع التنزيلات والمزيد ، بدلاً من القيام بكل العمل على شاشة واحدة.
وإذا اقترب شخص من المسؤولية وبصورة جيدة من عمله ، فسيكون قادرًا على تجنب معظم المشكلات في طريقه ، وليس فقط في مهنة ضمان الجودة.