Halo, Habr! Setelah kami menggunakan metrik "Tampaknya lebih baik" untuk menilai kualitas rilis kami. Tapi kemudian kami memutuskan untuk mempercayai sesuatu yang lebih bisa diandalkan. Pada artikel ini, saya akan berbicara tentang bagaimana saya mencari panduan metrik, tidak menemukannya dan membuat panduan saya sendiri.

Apakah itu terjadi bahwa Anda melakukan pekerjaan yang tampaknya bermanfaat untuk suatu proyek, tetapi tidak mengerti apakah ini membawa manfaat? Jadi kami pernah menulis autotests, tetapi tidak bisa mengatakan secara objektif apakah rilis monolit dan layanan lain di mana pengembangan aktif lebih baik telah menjadi lebih baik.
Mencari metrik
Saya mencari di internet dan karena alasan tertentu tidak menemukan artikel atau panduan siap pakai tentang cara memilih metrik yang tepat, cara mengumpulkannya, dan apa yang harus dilakukan selanjutnya. Tetapi ketika saya sedang mencari informasi, saya menemukan video dan artikel yang berguna yang membantu saya mengatasi tugas yang sulit ini. Tautan ke sana akan muncul di artikel.
Saya harap artikel ini akan bermanfaat bagi mereka yang berpikir untuk mengukur apa pun pada proyek mereka, tetapi tidak tahu harus mulai dari mana. Artikel ini berisi pengalaman pribadi, informasi dari artikel, video, dan kursus berbayar.
Satu detik sebelum membuat sistem pengukuran kualitasSebelum kami memutuskan untuk membuat sistem metrik kualitas, kami telah mengukur secara berkelanjutan:
- Waktu yang dihabiskan untuk pelepasan monolith (dari saat penciptaan cabang rilis ke penggabungan cabang ini di master).
- Jumlah rollback rilis monolit ke master karena bug.
- Waktu yang dihabiskan di Stop the Line .
- Jumlah peluncuran tahap pipa monolit di TeamCity dengan semua autotest hingga berubah menjadi hijau.
Seperti yang Anda lihat, kami mengukur hanya apa yang terhubung dengan monolith. Untuk layanan lain, mereka tidak mengukur apa pun.
Kami menerapkan sistem pengukuran kualitas dalam 11 langkah
Berikut adalah daftar 11 langkah yang akan membantu Anda menerapkan semuanya dan tidak ketinggalan apa pun.
Langkah 1. Tentukan tujuan pengukuran Anda
Pahami mengapa Anda ingin mulai mengukur sesuatu. Mengukur begitu saja, demi pengukuran, tidak masuk akal.
Sebagai contoh, kami ingin tahu bagaimana kami bergerak menuju sasaran kualitas yang telah kami tentukan sebelumnya. Kami juga ingin melihat dinamika indikator setelah upaya. Dengan sendirinya, angka-angka dari keadaan saat ini tidak berarti apa-apa. Ini hanya angka. Tetapi, mengamati angka-angka dalam dinamika, kita bisa melihat pengaruh tindakan kita.
Langkah 2. Tentukan Target
Anda perlu memahami apa yang Anda perjuangkan. Mengurangi waktu pengujian? Kurangi jumlah bug penting dalam produk? Meningkatkan cakupan tes?
Dalam kasus saya, tidak ada masalah dengan menetapkan indikator target, karena perusahaan kami memiliki sasaran kualitas. Sasaran ini menjadi dasar untuk metrik masa depan. Tujuan kami:
- Rilis monolit tidak lebih dari 4 jam.
- 0 hotfix dan rollback di aplikasi monolith, situs dan seluler.
Langkah 3. Tentukan metrik
Pikirkan bagaimana Anda menyadari bahwa Anda sedang bergerak menuju tujuan Anda.
Pada tahap pekerjaan ini, artikel "
Metrik QA Paling Penting " membantu saya.
Untuk sistem kami, saya memilih indikator seperti itu- Waktunya untuk rilis . Indikator ini mengukur waktu (dalam jam kerja) antara penggabungan cabang rilis sebelumnya di master dan gabungan dari rilis saat ini di master.
Kami membagi waktu ini menjadi 4 tahap: persiapan tegakan, lansekap tahap pipa, pengujian regresi manual, penyebaran ke prod.
Kami membagi waktu ini menjadi beberapa tahapan untuk melihat secara rinci konsekuensi dari tindakan kami dan untuk dapat secara akurat menentukan hambatan dalam proses kami.
Tahapan metrik waktu rilis - Koefisien "Masalah rilis" untuk semua layanan . Ini adalah rasio "rilis masalah" dengan jumlah total rilis, semua ini dikalikan dengan 100%. "Rilis bermasalah" adalah rilis di mana ada rollback dari rilis, perbaikan terbaru atau perbaikan data.

Rasio rilis yang bermasalah terhadap total rilis - Kepadatan perbaikan terbaru untuk layanan untuk monolith adalah rasio jumlah perbaikan terbaru untuk layanan dengan jumlah total perbaikan terbaru.
- Waktu regresi manual untuk aplikasi seluler . Ini adalah waktu dari awal regresi manual hingga penyelesaiannya.
Penting! Jangan mengambil banyak metrik sekaligus. Tiga atau empat sudah cukup untuk memulai. Ketika proses membaik, Anda dapat menambahkan lebih banyak jika perlu.
Banyak metrik sulit dikelola. Probabilitas berkembang bahwa sistem tidak akan lepas landas. Dan jika prosesnya tidak lepas landas pertama kali, maka pada saat berikutnya akan lebih sulit untuk memulai, karena Anda dan karyawan akan memiliki pengalaman negatif.
Langkah 4. Tentukan unit
Indikator yang berbeda dapat dibaca dalam unit yang berbeda. Segera Anda harus memilih sehingga semua metrik memiliki satu unit ukuran, jika tidak, Anda mungkin mengalami kesalahpahaman dan salah tafsir.
Kami memiliki masalah dengan item ini. Kami menghitung waktu rilis dalam jam, termasuk jam malam, tetapi tidak termasuk akhir pekan. Pada saat yang sama, nilai target dirilis dalam 4 jam. Cukup sering ada situasi ketika kami membuat cabang rilis-xxx pada pukul 16:00 hari ini, dan berakhir pada 10:00 hari berikutnya. Dalam metrik kami, itu dianggap 18 jam, tetapi pada kenyataannya, tindakan aktif dilakukan hanya 3 jam, jika tidak kurang.
Jika kami terus menghitung dengan cara ini, kami tidak akan pernah mencapai indikator "4 jam" dalam metrik kami. Setelah menghadapi pilihan, meningkatkan target menjadi 12 jam atau hanya memperhitungkan jam kerja, kami memilih yang kedua.
Langkah 5. Analisis metrik yang dipilih untuk kesesuaian
Dalam video “
Simple Practice Testing Metrics, ” pembicara menyarankan cara yang keren untuk menganalisis metrik kesesuaian. Anda perlu menjawab 9 pertanyaan untuk setiap metrik dan membuat keputusan.
Saatnya untuk Melepaskan analisis metrik pada kesesuaian- Tujuan pengukuran . Indikator ini harus terkait dengan tujuan bisnis. Metrik "Waktu untuk Rilis" terkait dengan sasaran bisnis - rilis dalam 4 jam.
- Untuk siapa metrik ini dimaksudkan . Siapa yang akan melihat metrik ini? Pengamat produk, pengembang, manajer, penguji, ahli scrum?
Pengatur produk (karena penting baginya untuk memahami berapa banyak rilis per sprint yang kami kelola untuk diluncurkan), pengembang (karena mereka ingin memahami kapan kode mereka akan ada di prod) dan penguji (karena waktu sudah aktif pengujian secara langsung memengaruhi metrik ini). - Pertanyaan apa yang dijawab oleh metrik pengguna . Rumuskan pertanyaan yang Anda jawab dengan metrik ini. Metrik "Waktu Rilis" menjawab pertanyaan, "Seberapa sering kita melepaskan?"
- Nyatakan ide metrik dan deskripsinya. Jelaskan metrik dengan singkat tapi jelas. Saya menggambarkan metrik "Waktu untuk Melepaskan" sebagai berikut: "Kami ingin dirilis sesering mungkin, metrik ini akan menunjukkan seberapa cepat kami merilis. Waktu rilis adalah waktu dalam jam kerja 9: 00-18: 00, tidak termasuk akhir pekan dan hari libur. Awal rilis dianggap sebagai penciptaan cabang rilis atau penggabungan rilis sebelumnya ke master, akhir rilis adalah injeksi dari cabang rilis ke master. Bagi waktu menjadi beberapa tahap terpisah, misalnya: persiapan untuk rilis, melewati autotest, pengujian manual, perhitungan untuk produk ”
- Kondisi yang diperlukan . Sebutkan ketentuan atau batasan untuk mengumpulkan metrik di sini. Siapa, kapan, dari mana data metrik akan berasal. Dalam kasus saya, saya tahu di mana harus menonton rilis semua bagian. Monolith - menggabungkan cabang release-xxx ke dalam master. Situs web - kentang di Kaiten.io di papan rilis. Aplikasi - Saya belum tahu, tetapi saya akan mengetahuinya "
- Pengukuran awal. Tetapi saya tidak mengerti poin ini dan tidak tahu bagaimana menggambarkannya. Siapa yang mengerti atau tahu apa yang bisa dibahas di sini, tulis di komentar.
- Tunjukkan rumus untuk menghitung metrik. Untuk metrik "Waktu untuk Melepaskan": berapa banyak waktu dalam jam kerja telah berlalu dari penggabungan rilis sebelumnya ke master ke gabungan rilis saat ini ke master (tidak termasuk akhir pekan dan hari libur). Hasilnya, kami mendapatkan jam kerja yang kami habiskan untuk rilis.
- Kriteria Keputusan. Tentukan apa yang akan Anda lakukan ketika Anda melihat perubahan pada metrik ini. Jelaskan reaksi Anda. Jawaban saya pada metrik adalah "Waktu untuk Melepaskan": "Anda perlu merespons metrik dengan mencari kemacetan dan menghilangkan kemacetan ini"
- Frekuensi. Seberapa sering kita akan mengumpulkan metrik. Kami akan memeriksa metrik kami setiap minggu, tetapi sebenarnya kami melakukannya lebih sering.
Setelah analisis sederhana seperti itu, segera menjadi jelas apakah Anda memerlukan metrik ini atau tidak. Ada pemahaman yang lebih dalam tentang metrik itu sendiri dan nilainya bagi perusahaan dan Anda.
Langkah 6. Sejajarkan metrik dengan pemangku kepentingan
Tampilkan metrik yang dipilih untuk yang akan mereka pengaruhi. Diskusikan keterbatasan yang Anda temukan selama fase analisis, serta cara untuk menghilangkannya, atau setidaknya menguranginya. Sangat penting untuk mendapatkan persetujuan dan persetujuan dari mereka yang akan mengumpulkan dan mengisi metrik ini.
Saya membahas metrik saya dalam 3 tahap: dengan penguji, pengembang, dan kelebihan produk. Hanya setelah semua orang setuju secara eksplisit bahwa metrik ini menunjukkan kualitas sistem, barulah saya dapat melanjutkan ke langkah berikutnya.
Langkah 7. Visualisasikan hasilnya
Orang tidak akan membaca tabel dan menonton dinamika sendiri. Karena itu, Anda perlu menjaga visibilitas.
Saya membuat tabel di Google Sheets, menulis formula, dan saya senang mempersembahkan tabel itu kepada kolega saya. CTO kami menyarankan memvisualisasikan metrik ini. Lebih tepatnya, untuk memastikan bahwa kondisi sistem saat ini jelas dalam 15 detik: menjadikannya lebih baik dibandingkan dengan sprint sebelumnya atau kualitasnya menurun.
Bersama-sama, kami memvisualisasikan indikator. Lalu saya meminta orang-orang untuk memberi tahu apa yang mereka lihat pada tabel ini. Menilai dari jawabannya, kami telah mencapai tujuan.

Beginilah visualisasi metrik kualitas rilis. Semuanya jelas, Anda bisa langsung melihat bagaimana sekarang dan bagaimana itu, apakah jumlah masalah melebihi jumlah rilis, sudah menjadi lebih baik atau lebih buruk dibandingkan dengan rilis sebelumnya. Dalam jadwal yang ideal, garis biru cenderung cenderung tanpa batas, dan garis merah harus ke 0.
Visualisasi hubungan "rilis bermasalah" dengan jumlah total rilisLangkah 8. Amati frekuensi pengumpulan metrik
Penting untuk menetapkan proses pengumpulan metrik, untuk bekerja pada frekuensi. Jika tidak ada proses, maka dasbor Anda akan kehilangan relevansinya dan mati. Penting bahwa ada pemangku kepentingan yang akan melakukan ini. Tetapi jika Anda khawatir tentang ini, maka orang yang bersangkutan sudah ada di sana.
Langkah 9. Beritahukan berulang kali kepada orang-orang tentang hasilnya.
Tidak peduli seberapa cantik dasbor Anda, orang tidak akan pergi ke sana dan melihat metriknya. Begitu semua orang akan melihat, karena ini adalah sesuatu yang baru, tetapi tidak secara berkelanjutan.
Kami memecahkan masalah ini dengan tiga cara.- Sebuah cerita tentang metrik pada bagian umum dari tinjauan sprint kami.
- Kesimpulan grafik pada monitor di koridor, yang setiap orang lihat setiap hari, sehingga angka dan grafik selalu ada di depan mata Anda.
- Publikasikan Ringkasan Dash Dash. Hal utama adalah menunjukkan dinamika saat menerbitkan laporan seperti itu: menjadi lebih baik atau lebih buruk dibandingkan dengan sprint sebelumnya. Dan jika Anda mempublikasikan ini sebelum tim retro, itu dapat memberikan topik diskusi untuk kalian.
Langkah 10. Analisis dan buat keputusan
Anda perlu melihat metrik, membuat keputusan berdasarkan pada metrik tersebut. Anda dapat menggunakan metrik sebagai argumen tambahan yang mendukung penulisan tes tambahan atau berfokus pada utang teknis, daripada fitur bisnis, dll.
Langkah 11. Otomatis
Mengotomatiskan koleksi metrik sebanyak mungkin. Jika Anda menggunakan sistem kontrol versi TaskMS dan TestMS, CI / CD yang populer, kemungkinan besar mereka semua memiliki API terbuka yang dengannya Anda dapat dengan mudah mengeluarkan informasi ini. Jika Anda tidak bisa melakukannya sendiri, minta bantuan pengembang. Anda mungkin perlu mengubah beberapa proses untuk ini. Ini normal. Dan ini adalah harga rendah untuk manfaat yang Anda dapatkan dengan mulai mengumpulkan metrik.
Sebagai contoh,
kami memiliki bot yang membantu melepaskan rilis roll dan mengurangi rutinitas mereka.
Ringkasan dan Kesimpulan
Membuat keputusan yang memengaruhi kualitas produk berdasarkan perasaan batin Anda adalah ide yang buruk. Perasaan dapat menipu dan mendorong Anda ke keputusan yang salah. Jadi, dapatkan metrik dan sistem penilaian kualitas.
Tetapi ingat bahwa pendirian metrik seperti pendirian hewan peliharaan. Selain keuntungan dari berkomunikasi dengan teman baru, Anda mendapatkan tanggung jawab dan kewajiban tertentu kepadanya. Karena itu, mulailah metrik secara sadar, dengan pemahaman tentang kebutuhan dan kesiapan mereka untuk mengatasi kesulitan yang menanti Anda di jalan.