المقاييس - مؤشرات صحة المشروع

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



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


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

عندما تكون الجودة والعمل ليسوا أصدقاء

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

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

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

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

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

كيف نفهم ما إذا كنت تقوم بتطوير ذات جودة عالية أم لا؟


يتطلب التقييم الموضوعي مقاييس تظهر:

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

كيفية اختيار المقاييس

يمكنك اختيار المقاييس وفقًا لثلاثة مبادئ.

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


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


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


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

المقاييس في مراحل مختلفة من المشروع

سوف أخبرك بالمقاييس التي قمنا بقياسها عندما كنا شركة ناشئة ، ثم بدأنا في النمو والتوسع.

بدء التشغيل

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


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

في قسم ضمان الجودة ، كان لدينا فقط 3-5 مقاييس:

• عدد الحشرات من المعركة ؛
• عدد الأخطاء التي تصل إلى الإصدار ؛
• أهمية الحشرات.

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

تنمو

في المرحلة التالية ، تعلمنا بالفعل الوقوف على أقدامنا ، نسير قليلاً.


احتياجات العمل تتطور ، يصبح من المهم قياس:

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

QA أصبحت بالفعل أكبر: 10-15 مقاييس. إذا أنشأنا منتجًا بدءًا وفقًا لمشاعرنا ، على سبيل المثال ، قال المؤسس: "أريد زرًا أزرق" ، وقد فعل الجميع ذلك ، والآن هناك أول إحصاء. يمكنك تخطي الميزات من خلال اختبارات A / B وتذكر قياس النتائج.

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

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

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

• مدير النظام ، على سبيل المثال ، TestRail ؛
• تحليلات جوجل لجمع بيانات المستخدم ؛
• تقرير البوابة ، جاذبية للأتمتة.

يبني النظام داخل نفسه مقاييس وتقارير إضافية.

متضخمة مع الدهون

نحن ننمو أكثر من ذلك ، "فرط الدهون" - لا ندخل في المكاتب التي كنا نجلس فيها ، ونبدأ في التحرك بشكل دوري.


ما هو المهم لرجال الأعمال؟

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

يشمل ضمان الجودة بالفعل ما يقرب من 30-50 مقاييس. نقيس:

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

نقوم بجمع البيانات كما كان من قبل ، ولكن هناك المزيد من الأنظمة المستخدمة.

الصعوبات

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


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

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

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

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

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

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

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

علاج الحزن

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


الحل المنطقي هو تجميع كل شيء من حيث البيانات وتحويلها إلى مقاييس.

قمنا بصياغة المعايير التالية:

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

لوحات

لدينا الكثير من لوحات المعلومات ، والتقنيات النشطة فقط هي الآن حوالي 30 ، وحوالي 100 في المجموع.



يتم جمع بيانات لوحة المعلومات بشكل عام من كل مكان. اتضح قماشًا كبيرًا يمكنك من خلاله إنشاء التقارير اللازمة. فيما يلي بعض الأمثلة.

علة علة الانهيار



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

انهيار الأخطاء عن طريق الحقول الخاصة

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



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

نسبة الأخطاء الجديدة والمغلقة

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



علة الاتجاه لهذه الفترة

النظام المريح الذي قدمناه هو أننا قمنا بتحميل جميع البيانات التاريخية ويمكننا رؤية الديناميات.



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

مراحل البحث عن الأخطاء

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



لوحة التحكم الآلي

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



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

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

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



بالإضافة إلى ذلك ، تنعكس البيانات الخاصة بخفض الحالة هنا:

• وظائف جديدة - جديدة.
• تحتاج تصحيح - تحتاج إلى تحديث القضية.
• لا حاجة - لا ترغب في تغطية التشغيل الآلي.
• انتهى - المغطاة.

الحرجية لديها أيضا قطع الخاصة بها.

أداء لوحة القيادة

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



كل ذلك يتداخل مع وظائف مختلفة ، صفحات مختلفة من الموقع.

يطير على

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

ولكن هناك مشاكل جديدة على طول الطريق. هناك الكثير من الرسوم البيانية ، وبالتالي فهي في كثير من الأحيان أقل مشاهدة. عندما يكون هناك 5 جداول ، من السهل التحقق منها كل يوم. مع زيادة عددهم ، يتم الحصول على نظام مرة واحدة في الأسبوع - جيد أيضًا. ثم فجأة منذ 3 أيام كان هناك fakap ، والتي لم يلاحظها أحد. وبالتالي ، يصبح رد الفعل طويلًا ، وتمكّن المقاييس ولوحات المعلومات من أن تصبح قديمة. هناك عدة أسباب لذلك ، والتي تحتاج أيضًا إلى أن تكون قادرًا على القتال.

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

نشارك: مقاييس العمل ، مقاييس العمليات ، مقاييس ضمان الجودة (الويب / الجوال ، دليل / أتمتة ، أداء).

هذه هي الطريقة التي يظهر بها الرسم البياني المجمع (NPS ، CSAT).



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

أيضا ، الرسومات لديها القدرة على الهبوط إلى مستوى أقل ، دون الذهاب إلى أي مكان.



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

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

تحذير

نحن نستخدم الكثير من التنبيهات. سأقدم أمثلة على الفئات والمواقف المحددة:

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

أمثلة تنبيه

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



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



إنه يشير إلى الحالات التي تم تعيينها لمن ، وما هي الحالة ومن الذي يجب مراقبته.

مثال آخر هو بوت Yabeda ، الذي يراقب العمليات.



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

كم عدد التنبيهات التي تحتاجها وكم مرة؟

إذا كان هناك الكثير من التنبيهات ، فسيكون هناك الكثير من الضغط عليهم. لذلك ، وضعنا قواعد إدارة التنبيه لأنفسنا.

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

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

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

عادةً ما يتم ضبط التنبيه على قيمة العتبة للقياس: إذا عبر المقياس العتبة ، يصل تنبيه. , , - , . , :

• — , .
• — , , . , , . .
• — , , , , .

, :

• — , , .
• / . , , .
• . , .
• . , . , . , , .

. , . . , , , , . , , : , .


, :

• . , , , . .

• . , , , . , 10 — .
• . , .

, , . . -, , , , , 15 , . -, , . . -, . , , , , , .

Online

. , . , . , .

QA

, QA .

: , , .

: , , .

:



— , X ( ), () (). , - , ( ) : , . , . , , . , , .

: — , , ( , , ).

: « ». , , , , . - . .

, , . , , . .

-

: , , . , .

: , , , .

, 10 , 500, . , .

. , , .



, , , . , , . «5 », .

, , , .

النتائج

— , . , . , . , , , — , .


:

• ;
• , ;
• , .

. , , , . .

— . , . , , - .

. , .

:

• ~ 50 QA 100 .
• ~ 30 .
• — , .
• .
• .
• QA must have.

, , , - ++ TechLead Conf. telegram- , , – , , , .