◽️ 👨‍🍳 💊 كم هي وحدة الاختبارات؟ 🙋🏽 👌🏿 🤲🏻

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

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

ما هي التكلفة

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

$display$

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

في الواقع ، هذه صيغة مبسطة إلى حد ما. بالمعنى الدقيق للكلمة ، سيتغير المعدل من سنة إلى أخرى ، لذلك يجب استخدام WACC1 * WACC2 * WACC3 ، وما إلى ذلك ، في المقام ، ولكن في الممارسة العملية حتى المهتمون بالمهنية يتجاهلون ذلك ، لأن بحكم منهجية حساب WACC ، تم بالفعل إدراج توقعات السوق فيما يتعلق بالمعدلات المستقبلية في أسعار اليوم ، ومن غير المجدي وضع افتراضات حول هذا.

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

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

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

$display$

هنا Re هي تكلفة الأسهم ، Rd هي تكلفة رأس المال المقترض (أي ، السعر الفعلي على ديون الشركة) ، P هي القيمة السوقية للأسهم ، EV هي التكلفة الإجمالية للمؤسسة (EV = P + D ، حيث D هي الدين).

بعد ذلك ، نحتاج إلى تحديد Re ، لذلك توجد نماذج مختلفة ، ولكن أسهل طريقة هي أخذ نموذج CAPM ، حيث Re = Rb + β * Premium ، حيث Rb هو معدل خالي من المخاطر ، Premium هو علاوة على العائد على الاستثمار في الأسهم ، وليس في المقترضة ، و β عامل مخاطرة يوضح مدى خطورة مشروعنا فيما يتعلق بأعمال شركة متوسطة معينة.

كيف يتم ضمان الجودة وما هي اختبارات الوحدة

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

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

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

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

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

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

التكاليف ، وتعديل التعقيد ، والشخصية الأسطورية الشهر

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

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

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

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

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

على سبيل المثال ، إذا كان هناك خمسة مطورين في الفريق ، وتعتقد أنك بحاجة إلى توظيف اثنين حتى يتمكن الجميع من قضاء 40٪ إضافية من وقتهم في اختبارات الوحدات ، فاستعد لحقيقة أن تكاليف التطوير يمكن أن تزيد بأكثر من 40٪. سينمو الفريق وسيصبح أقل كفاءة ، بدلاً من 5 * 0.625 = 3.125 وحدة إنتاجية تقليدية ، سيكون له 7 * 0.539 = 3.77 وحدة ، وسيزيد حجم العمل من 1 إلى 1.4 وحدة عمل تقليدية ، على التوالي ، الوقت اللازم للتطوير سوف تزيد بنسبة 16 ٪.

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

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

فوائد اختبارات الوحدة

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

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

مثال واحد: بيسون

بيسون هو متجر كبير على الإنترنت ، يطلقون على أنفسهم رقم 1 على الإنترنت لمتاجر التجزئة في روسيا. الشركة ليست عامة ، ولكن في عملية إعادة الرسملة الأخيرة ، تم تقدير الرسملة الإجمالية بحوالي 50 مليار روبل ، وهو ضعف الإيرادات السنوية. كانت هناك حاجة إلى رسملة إضافية بسبب خسائر التشغيل ، لكن المساهمين يأملون في تحقيق هامش ربح تشغيلي بنسبة 10 ٪ بعد نجاح الشركة في الحصول على حصة سوقية أعلى ومضاعفة الإيرادات في غضون عام ، وبعد ذلك سوف تضطر إلى البدء في الكسب ، وسيتباطأ نمو الإيرادات يصل إلى 30 ٪ في السنة الثانية ، 20 ٪ في السنة الثالثة ، وأخيرا حددت في 10 ٪ في السنة الرابعة واللاحقة. ومع ذلك ، فإن البنوك غير متأكدة جدًا من هذا الأمر وتعطي Bizon حذرًا طويلًا ، حيث يبلغ إجمالي الدين للشركة 10 مليارات روبل فقط بمعدل 11٪. Bison هي شركة غير متقنة وذات إدارة سيئة على المستوى التشغيلي ، وقد أدى التوظيف غير المنضبط للموظفين بالفعل إلى حقيقة أنها توظف 600 مبرمج تبلغ ميزانيتهم الإجمالية 1.5 مليار روبل في السنة ويقضون حوالي 30 ٪ من وقت عملهم في اختبارات الوحدة. لا تتحمل الشركة أي التزامات تجاه العملاء ، ويمكن أن يؤدي الفشل الفني فقط إلى توقف مؤقت في المبيعات ، وفي حالة حدوث عطل ، يستغرق التراجع إلى الإصدار القديم من الموقع حوالي ساعة.

ما هو NPV من استخدام اختبارات الوحدة في البيسون؟

50, 65, 78 86 , , . 33%, , , . , 25% , DDOS . , 0,023% , 12 . , 11,5 , 14,8 , 17,8 19,6 .

, 450 .

, , , . , ! , - , , .

, , 10% , , -438, -480, -527 -579 , , , 10% . , , 20% , , 0.8: -351, -384, -421 -463 .

EV 50 + 10 = 60 , P 83% , D 17%, , 11% , WACC . , , 7,6%. , 4-6% , 5%, β (unlevered beta) 1,3. , , (levered beta):

$display$