Berapa tes unit?

Sekarang, di puncak siklus ekonomi dalam industri yang panas seperti pengembangan perangkat lunak, tidak lazim untuk menghitung uang. Seringkali proses ini, pada prinsipnya, diposisikan sebagai kegiatan kreatif, di mana tidak perlu membenarkan apa pun, dan seniman lebih tahu apa dan bagaimana menulis. Secara khusus, ada banyak perdebatan tentang tes unit dan TDD, tetapi, sayangnya, mereka semua tergelincir ke dalam pernyataan yang tidak terbukti dan serangan emosional, dikonfirmasi oleh bukti untuk artikel dan buku yang dipilih dengan sukses oleh para ahli metodologi yang mendapatkan konsultasi dan penjualan pelatihan, yang, dalam pada gilirannya, mereka sama sekali tidak mengandung statistik atau perhitungan, atau, sebaliknya, untuk tuduhan besar-besaran smushylebstvo dan dosa remaja lainnya.

Tidak seperti argumen kosong serupa, artikel ini tidak hanya akan memberi Anda makanan untuk dipikirkan, tetapi juga metodologi untuk menilai kelayakan ekonomi dari memperkenalkan unit test pada proyek tertentu. Saya akan segera menekankan bahwa, seperti penilaian apa pun, penilaian kami untuk proyek implementasi unit test akan didasarkan pada asumsi tentang masa depan produk, tim, dan berbagai indikator, yang hanya dapat dinilai secara subyektif. Namun demikian, situasi ketika seorang programmer memberikan penilaian ahli indikator yang setidaknya entah bagaimana terkait dengan bidang kegiatannya jauh lebih baik daripada langsung bertanya kepadanya apakah menguntungkan bagi perusahaan untuk menggunakan unit test atau tidak. Pada akhirnya, programmer biasanya tidak cenderung untuk berpikir tentang indikator keuangan dasar, tetapi tidak hanya pengembang, tetapi juga penguji dan manajer dapat mengevaluasi waktu yang dihabiskan untuk menulis tes atau kemungkinan bug kritis dalam ketidakhadiran mereka.

Berapa biayanya

Pertama-tama, jika kita akan menghitung biaya apa pun, kita harus terlebih dahulu setidaknya secara umum memahami apa nilainya. Ketika kita membeli roti sosis, pertanyaan ini tidak muncul, karena label harga tergantung di bawahnya. Tetapi dalam kasus proyek, kami tidak berurusan dengan pembayaran satu kali, tetapi dengan arus kas yang berlangsung lama, dan kami menginvestasikannya terlebih dahulu, kemudian membayar kami. Untuk mengevaluasinya dengan benar, Anda perlu mempertimbangkan bahwa uang yang diterima besok lebih murah dari hari ini. Jika sosis dijual dengan berlangganan, tidak akan sulit untuk melakukannya, biaya berlangganan dapat dihitung dengan mendiskontokan pembayaran di masa depan untuk itu dengan jumlah inflasi. Namun, dalam kasus proyek, kita perlu memperhitungkan bahwa perusahaan, berinvestasi di dalamnya, mengharapkan tidak hanya untuk mengkompensasi biaya, tetapi juga untuk mendapatkan, sedemikian rupa sehingga dapat menutupi risikonya. Ada sejumlah besar risiko, tetapi pada akhirnya semuanya bermuara pada kenyataan bahwa pengembalian uang yang diinvestasikan dalam pelaksanaan proyek tidak dijamin dan diprediksi dengan buruk. Uang dapat dibawa ke bank atau dipinjamkan ke peminjam tangguh dan dijamin membayar bunga secara teratur, tetapi Anda tidak dapat berinvestasi dalam suatu proyek sehingga Anda berakhir dengan alur pembayaran sesuai jadwal yang dapat diprediksi. Oleh karena itu, dari sudut pandang investor, dalam hal ini, perusahaan, arus kas didiskontokan pada tingkat pengembalian yang diperlukan yang dihasilkan oleh proyek, juga disebut net present value, harus positif:

$$

Untuk menghitungnya, kita perlu tahu berapa banyak uang yang akan dibawa atau dimakan proyek pada tahun pertama, kedua, ketiga, dll., Serta tingkat diskonto, yang seharusnya tidak hanya lebih menguntungkan daripada di bank, tetapi juga mencakup risiko .

Sebenarnya, ini adalah formula yang agak disederhanakan. Sebenarnya, nilainya akan berubah dari tahun ke tahun, jadi WACC1 * WACC2 * WACC3, dll., Harus digunakan dalam penyebut, tetapi dalam praktiknya bahkan penilai profesional mengabaikan hal ini, karena Berdasarkan metodologi perhitungan WACC, ekspektasi pasar mengenai kurs di masa depan telah dimasukkan ke dalam kurs hari ini dan tidak produktif untuk membuat asumsi tentang hal ini.

Ada berbagai jenis arus kas, tetapi saya mengambil aliran kas yang paling nyaman untuk keperluan kami bagi perusahaan, yang memperhitungkan tidak hanya uang yang terutang kepada pemilik, tetapi juga kepada para kreditor. Tentu saja, sebagian besar perusahaan IT tidak memiliki hutang yang nyata hanya karena tidak ada yang meminjamkan kepada mereka tanpa agunan, dan mereka tidak punya apa-apa untuk dijanjikan, tetapi masih ada pengecualian, misalnya, pendekatan ini bisa nyaman ketika mengevaluasi proyek dalam pengembangan in-house dari perusahaan manufaktur yang dipinjamkan . Alasan kedua mengapa FCFF sangat menarik bagi kami adalah kesederhanaan perhitungannya, FCFF hanya laba operasi dikurangi pajak, biaya modal bersih dan perubahan modal kerja.

Karena FCFF adalah arus kas baik untuk pemilik maupun pemberi pinjaman pada saat yang sama, FCFF didiskon pada tingkat tertimbang dari biaya modal, baik dimiliki maupun dipinjam.

Di perusahaan besar, biaya modal dipantau oleh departemen keuangan, jadi Anda bisa menanyakannya, tetapi untuk kasus umum, kami masih membutuhkan formula untuk menghitung WACC:

$$

Di sini Re adalah biaya ekuitas, Rd adalah biaya modal pinjaman (yaitu, tingkat efektif hutang perusahaan), P adalah nilai pasar ekuitas, EV adalah total biaya perusahaan (EV = P + D, di mana D adalah utang).

Selanjutnya kita perlu menentukan Re, untuk ini ada model yang berbeda, tetapi cara termudah adalah dengan mengambil model CAPM, di mana Re = Rb + β * Premium, di mana Rb adalah tingkat bebas risiko, Premium adalah premi atas pengembalian investasi dalam ekuitas, dan bukan dalam dipinjam, dan β adalah faktor risiko yang menunjukkan betapa jauh lebih riskannya proyek kami sehubungan dengan bisnis rata-rata perusahaan tertentu.

Bagaimana kualitas terjamin dan unit test apa

Sekarang kita perlu memutuskan unit test apa. Cukup aneh, banyak orang, bahkan yang dekat dengan pengembangan, sering menyebut tes unit tes otomatis, tetapi ini, tentu saja, tidak demikian.

Pengujian dibagi menjadi fungsional dan non-fungsional. Non-fungsional mencakup hal-hal yang tidak terkait langsung dengan fungsionalitas perangkat lunak, misalnya, memuat pengujian atau pengujian yang terkait dengan keamanan. Fungsional, bagaimanapun, hanya berarti memeriksa kepatuhan dengan persyaratan dan tidak adanya kesalahan dalam pelaksanaannya, itu akan dibahas secara khusus.

Hal pertama yang perlu dilakukan untuk memastikan kualitas adalah mengambil fungsi kontrol dari pengembang dan merekrut orang yang akan bertanggung jawab untuk itu. Jadi tester muncul di tim, yang terlibat dalam pengujian manual. Tidak ada proyek serius yang tidak dapat dibayangkan tanpa pengujian manual, itu adalah fondasi bahwa proyek sangat membutuhkan dan sebagian besar masalah yang akan ditemukan dan diperbaiki dalam waktu akan menjadi manfaat dari penguji. Pada tahap ini, semuanya terlihat sederhana: jika Anda menginginkan kualitas, pekerjakan spesialis yang berkualitas.

Seiring dengan pertumbuhan proyek, waktu untuk pengujian manual akan semakin sedikit, sehingga penguji akan semakin sibuk bekerja dengan kemampuan sistem baru dan semakin sedikit akan memeriksa bagian-bagian dari sistem yang seharusnya tidak berubah. Namun, ketika kompleksitas sistem tumbuh dan ada kemungkinan bahwa dependensi eksplisit dan implisit akan muncul di antara komponen-komponennya, yang secara teoritis dapat dilupakan oleh para pengembang, masih disarankan untuk memeriksa beberapa hal setiap kali sebelum rilis. Masalah ini sangat akut dalam metodologi fleksibel dengan iterasi singkat dan rilis yang sering. Ini secara logis menyiratkan perlunya mengotomatiskan pekerjaan penguji, misalnya, menulis skrip yang akan mengklik tombol dan memeriksa hasilnya sendiri, atau menggunakan alat yang lebih kuat dan mengubah tester biasa menjadi spesialis pengujian otomatis yang mampu mengotomatisasi bagian rutin dari karyanya.

Langkah-langkah ini dapat memberikan tingkat kualitas yang layak, tetapi tidak ada batasan untuk kesempurnaan. Apa yang dilakukan penguji disebut pengujian kotak hitam, tanggung jawab mereka adalah tidak mengetahui semua fitur implementasi, jadi pengujian biasanya difokuskan pada skenario tipikal dan tidak menetapkan sendiri tujuan untuk merusak sistem atau memeriksa perilakunya dalam beberapa kondisi atipikal. Selain itu, beberapa hal tidak mudah diverifikasi hanya karena kurangnya antarmuka, misalnya, jika tujuan dari iterasi adalah untuk mengembangkan perpustakaan untuk mengakses data atau API tertentu, untuk mengujinya Anda perlu menulis beberapa aplikasi atau setidaknya sesuatu yang akan menggunakan komponen ini. Dalam kasus tersebut, Anda harus mengembalikan sebagian fungsi kontrol kualitas kepada pengembang dan meminta mereka untuk menulis tes integrasi. Ini adalah jenis tes otomatis kedua yang digunakan pada proyek. Tujuan mereka adalah untuk menguji kebenaran interaksi komponen sistem yang ditulis oleh orang yang berbeda, menguji perilaku komponen ini dalam kondisi batas, serta kebenaran reaksi terhadap kegagalan di lingkungan.

Nah, kami memiliki penguji yang menguji seluruh proyek untuk kepatuhan terhadap persyaratan, ada tes untuk mengotomatiskan pekerjaan mereka, dan ada tes yang menguji bagian-bagian proyek yang ditulis oleh pengembang yang berbeda, apa lagi yang bisa dilakukan? Tes unit mengklaim sebagai kontrol kualitas tingkat keempat. Mereka memeriksa kode yang ditulis oleh satu programmer, dan, sebagai aturan, mereka menguji bagian minimum dari kode, yang pada dasarnya cocok untuk pengujian, misalnya, kelas yang terpisah. Dalam praktiknya, paling sering pengembang sendiri menulis unit test untuk kodenya sendiri, dan jumlah serta kebutuhannya tidak terkontrol. Menurut pengamatan saya, sekitar 40% dari waktu untuk mengembangkan fitur itu sendiri dapat disebut jumlah waktu pengembang yang dihabiskan untuk pengujian unit, meskipun rasio ini dapat sangat bervariasi. Studi kasus open source dari proyek SQLite dikenal secara luas, di mana karena kelebihan tenaga kerja gratis berketerampilan rendah yang disediakan oleh sejumlah besar orang yang ingin bekerja pada proyek terkenal, tenaga kerja ini digunakan dengan cara militer, yaitu, dengan menulis tes unit yang tidak berguna, yang volumenya pada beberapa titik di 100 kali volume kode DBMS itu sendiri. Kasus terbalik ketika tes unit tidak ditulis atau ditulis ke volume minimum juga tidak mengejutkan. Pada akhirnya, hampir semua perangkat lunak dikembangkan hingga akhir nol, yaitu, sebelum era outsourcing dan Agile, diciptakan tanpa unit test.

Biaya, penyesuaian kompleksitas, dan mitos orang-bulan

Tentu saja, jika Anda perlu menulis unit test atau yang lainnya, Anda harus mencurahkan lebih banyak waktu untuk proyek, atau menyewa pengembang tambahan. Pertanyaan utama yang muncul dalam kasus ini adalah apakah ketergantungan waktu pengembangan dan biaya pada jumlah kode adalah linier, atau apakah itu mematuhi hukum lain.

Sekali waktu saya memiliki repositori SVN gratis di layanan Assembla yang terkenal jahat, yang menyediakan layanan hosting sumber dan alat kolaborasi, yaitu pelacak, statistik, dan omong kosong lainnya. Kemudian freebie berakhir, tetapi mereka tidak berhenti mengirim nawala dan pemberitahuan. Jadi, pada 2015, karyawan mereka menerbitkan sebuah pos pendek berjudul "Berapa banyak orang yang harus mendiskusikan tugas?" Sekarang hanya disimpan di Web Archive . Inti dari posting tersebut adalah sebagai berikut: karyawan mengumpulkan statistik pada pelanggan, merencanakan ketergantungan durasi tugas pada jumlah orang yang membahasnya, hasilnya adalah sebagai berikut:



Dapat dilihat bahwa ketergantungannya adalah nonlinier. Dua orang biasanya terlibat dalam menyelesaikan masalah yang berlangsung dua hari, tiga orang - empat hari, dan empat orang - sudah enam hari. Apa yang mereka lakukan disana Dapat diasumsikan bahwa tugas tersebut memerlukan beberapa tahap pekerjaan, misalnya, dalam kasus dua orang, Vasya melakukan bagian tugasnya, dan kemudian mentransfernya ke Petya, sehingga berlangsung dua hari. Tiga orang sudah dapat bertengkar dan sekali lagi berbagi tanggung jawab, mencari tahu siapa yang harus disalahkan dan apa yang harus dilakukan, dan sekelompok tujuh orang akan menghabiskan enam hari tambahan untuk membahas, bernegosiasi dan saling bertukar pikiran.

Tentu saja, kita juga dapat berasumsi bahwa tim tujuh orang yang bersahabat memiliki tugas yang sulit untuk dilakukan, dan semakin banyak orang terlibat dalam suatu tugas, semakin muluk, karena persahabatan adalah sihir! Oleh karena itu, pertimbangan seperti itu mungkin tampak jauh dari kenyataan, dan saya tidak akan memasukkannya dalam perhitungan selanjutnya, namun, jika Anda ingin mendapatkan perkiraan yang lebih konservatif, itu tidak akan salah untuk membuat beberapa koreksi untuk nonlinearitas pertumbuhan biaya dengan pertumbuhan basis kode proyek, yang, tentu saja, Tes unit juga disertakan, atau untuk memberikan batas keselamatan tertentu dalam persyaratan untuk level NPV.

Jika kami menjelaskan nonlinier dari jadwal ini semata-mata oleh pertumbuhan ukuran tim, maka biaya yang terkait dengannya dapat diperkirakan dari tabel berikut tentang ketergantungan pangsa waktu yang hilang pada komunikasi pada ukuran kelompok kerja:



Misalnya, jika ada lima pengembang dalam sebuah tim, dan Anda percaya bahwa Anda perlu merekrut dua sehingga setiap orang dapat menghabiskan 40% tambahan waktu mereka untuk unit test, bersiaplah untuk kenyataan bahwa biaya pengembangan dapat meningkat lebih dari 40%. Tim akan tumbuh dan menjadi kurang efektif, bukannya 5 * 0,625 = 3,125 unit produktivitas konvensional, itu akan memiliki 7 * 0,539 = 3,77 unit, dan jumlah pekerjaan akan meningkat dari 1 menjadi 1,4 unit kerja konvensional, masing-masing, waktu yang dibutuhkan untuk pengembangan akan meningkat sebesar 16%.

Kesimpulan menarik yang dapat ditarik dari grafik adalah bahwa ketika jumlah orang lebih dari sepuluh, nilai setiap peserta baru menjadi kurang dari biaya komunikasi tambahan dan hukum Brooks mulai bekerja. Tetap hanya mencoba untuk membagi tugas menjadi yang lebih kecil, atau untuk melibatkan karyawan yang lebih berpengalaman dan efisien dalam pelaksanaannya.

Tentu saja, sulit untuk mengatakan bahwa non-linearitas grafik dari Assembla hanya terkait dengan penurunan efisiensi sebagai hasil dari pertumbuhan tim, tetapi itu adalah perjanjian yang baik dengan pemahaman intuitif kompleksitas dan hukum Brooks, jadi jika Anda tidak ingin mengambil risiko dan Anda memerlukan perkiraan konservatif, data ini dapat Menjadi bantuan yang baik.

Manfaat unit test

Selain biaya, unit test juga membawa manfaat. Tentu saja, dalam sebagian besar kasus, bug yang dapat ditangkap oleh unit test akan ditangkap pada level lain dari kontrol kualitas, tetapi selalu ada kemungkinan kegagalan teknis dan secara teoritis unit test dapat menguranginya. Secara pribadi, saya tidak tahu kasus-kasus seperti itu, untungnya, semua penguji yang bekerja dengan saya adalah orang-orang yang sangat bertanggung jawab, tetapi ketika sampai pada probabilitas rendah seperti itu, pengalaman pribadi bisa tidak representatif. Kegagalan dapat memiliki konsekuensi yang berbeda, misalnya, perusahaan mungkin memiliki SLA, pelanggaran yang akan mengakibatkan kerugian keuangan tertentu, misalnya, perusahaan akan dipaksa untuk memberikan pelanggan satu bulan penggunaan gratis layanannya sebagai kompensasi, kehilangan 1/12 dari pendapatan. Dalam hal ini, pengetatan kontrol kualitas, yang mengurangi kemungkinan pelanggaran SLA selama tahun ini dari 10% menjadi 8%, akan mengurangi kerugian tahunan rata-rata sekitar 0,17% dari pendapatan. Uang ini akan menjadi komponen positif dari arus kas yang perlu ditambahkan ke model.

Harap dicatat bahwa perhitungan sederhana tersebut hanya berlaku ketika probabilitas kerugian rendah, jika probabilitas lebih tinggi dari 15-20% dan dapat menyebabkan kebangkrutan atau likuidasi perusahaan, disarankan untuk menggunakan model penilaian opsional, misalnya, seperti pohon keputusan. Untungnya, dalam banyak kasus, beberapa jenis bug bodoh bukanlah sesuatu yang dapat membuat perusahaan bangkrut dan kami tidak perlu terjun ke dalam kengerian dalam menghitung biaya opsi.

Contoh Satu: Bison

Bison adalah toko online besar, mereka menyebut diri mereka pengecer online No. 1 di Rusia. Perusahaan ini tidak publik, dalam transaksi rekapitalisasi baru-baru ini, total kapitalisasi diperkirakan mencapai 50 miliar rubel, yang merupakan dua kali lipat pendapatan tahunan. Kapitalisasi tambahan diperlukan karena kerugian operasional, tetapi pemegang saham berharap untuk mencapai margin laba operasi 10% setelah perusahaan berhasil mendapatkan pangsa pasar yang lebih tinggi dan menggandakan pendapatan dalam setahun, setelah itu harus mulai mendapatkan penghasilan, dan pertumbuhan pendapatan akan melambat hingga 30% di tahun kedua, 20% di tahun ketiga, dan akhirnya ditetapkan 10% di tahun keempat dan selanjutnya. Namun, bank tidak terlalu yakin akan hal ini dan memberi Bizon peringatan panjang, total hutang perusahaan hanya 10 miliar rubel pada tingkat 11%. Bison adalah perusahaan yang agak ceroboh dan tidak dikelola dengan baik di tingkat operasional, perekrutan karyawan yang tidak terkendali telah mengarah pada fakta bahwa ia mempekerjakan 600 programmer, yang total anggaran penggajiannya adalah 1,5 miliar rubel per tahun dan yang menghabiskan sekitar 30% dari waktu kerja mereka untuk pengujian unit. Perusahaan tidak memiliki kewajiban kepada pelanggan dan kegagalan teknis hanya dapat menyebabkan penghentian sementara dalam penjualan, dan jika terjadi kegagalan, kemunduran ke versi lama situs membutuhkan waktu sekitar satu jam.

Apa NPV dari menggunakan unit test dalam bison?

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):

$$

WACC

$$

, , , , 10% .

$$ , $$ , $$ .

10% , $$ , : $$ .
$$ .

:

– . , , . , , , 50 . . .
: « ! , . - , , . , , . ». , 8 .
: -?
, : . , ( 50, - 10, ), , . , , - , , 100 10% * 8 = 800 .

: XSoft

XSoft – , . 7 , 15 , XSoft 3 . – . XSoft, ?

! , , -, , - . , , , .

Kata penutup

, , . , . , , NPV / IRR. , IT. Excel .