Kode Sumber QA: Ini Bukan Hanya untuk Pengembang Lagi

Dua puluh tahun yang lalu, ketika saya bekerja di industri otomotif, direktur salah satu pabrik sering berkata, "Kami memiliki satu hari untuk membuat mobil, tetapi pelanggan kami memiliki waktu seumur hidup untuk memeriksanya." Kualitas adalah yang paling penting. Memang, di sektor yang lebih matang seperti industri otomotif dan konstruksi, jaminan kualitas merupakan pertimbangan utama yang secara sistematis diintegrasikan ke dalam proses pengembangan produk. Meskipun hal ini tentu saja didorong oleh tekanan dari perusahaan asuransi, hal ini juga ditentukan—seperti yang dicatat oleh direktur pabrik itu—oleh masa pakai produk yang dihasilkan.

Namun, ketika menyangkut perangkat lunak, siklus hidup yang lebih pendek dan peningkatan berkelanjutan berarti bahwa integritas kode sumber sering diabaikan demi fitur baru, fungsionalitas canggih, dan kecepatan masuk ke pasar. Manajer produk sering mengabaikan jaminan kualitas kode sumber atau menyerahkannya kepada pengembang untuk ditangani, meskipun faktanya itu adalah salah satu faktor yang lebih penting dalam menentukan nasib suatu produk. Untuk manajer produk yang peduli tentang membangun dasar yang kuat untuk pengembangan produk dan menghilangkan risiko, mendefinisikan dan menerapkan penilaian sistematis kualitas kode sumber sangat penting.

Mendefinisikan “Kualitas”

Sebelum menjelajahi cara untuk mengevaluasi dan memberlakukan proses QA kode sumber dengan benar, penting untuk menentukan apa arti "kualitas" dalam konteks pengembangan perangkat lunak. Ini adalah masalah yang kompleks dan beragam, tetapi demi kesederhanaan, kita dapat mengatakan bahwa kualitas mengacu pada kode sumber yang mendukung proposisi nilai produk tanpa mengorbankan kepuasan konsumen atau membahayakan model bisnis perusahaan yang sedang berkembang.

Dengan kata lain, kode sumber kualitas secara akurat mengimplementasikan spesifikasi fungsional produk, memenuhi persyaratan non-fungsional, memastikan kepuasan konsumen, meminimalkan risiko keamanan dan hukum, dan dapat dipelihara dan diperluas dengan harga terjangkau.

Mengingat seberapa luas dan cepat perangkat lunak didistribusikan, dampak cacat perangkat lunak dapat menjadi signifikan. Masalah seperti bug dan kompleksitas kode dapat merugikan perusahaan dengan menghambat adopsi produk dan meningkatkan biaya manajemen aset perangkat lunak (SAM), sementara pelanggaran keamanan dan pelanggaran kepatuhan lisensi dapat memengaruhi reputasi perusahaan dan menimbulkan masalah hukum. Bahkan ketika cacat perangkat lunak tidak menyebabkan bencana, mereka memiliki biaya yang tidak dapat disangkal. Dalam laporan tahun 2018, perusahaan perangkat lunak Tricentis menemukan bahwa 606 kegagalan perangkat lunak dari 314 perusahaan menyebabkan hilangnya pendapatan sebesar $1,7 triliun pada tahun sebelumnya. Dalam laporan 2020 yang baru saja dirilis, CISQ menyebutkan biaya perangkat lunak berkualitas buruk di AS sebesar $2,08 triliun, dengan perkiraan $1,31 triliun lainnya dalam biaya masa depan yang dikeluarkan melalui utang teknis. Angka-angka ini dapat dikurangi dengan intervensi sebelumnya; biaya rata-rata untuk menyelesaikan masalah selama desain produk secara signifikan lebih rendah daripada menyelesaikan masalah yang sama selama pengujian, yang pada gilirannya secara eksponensial lebih sedikit daripada menyelesaikan masalah setelah penerapan.

Menangani Kentang Panas

Terlepas dari risikonya, jaminan kualitas dalam pengembangan perangkat lunak diperlakukan sedikit demi sedikit dan dicirikan oleh pendekatan reaktif daripada pendekatan proaktif yang diambil di industri lain. Kepemilikan kualitas kode sumber diperebutkan, ketika itu harus dilihat sebagai tanggung jawab kolektif dari fungsi yang berbeda. Manajer produk harus melihat kualitas sebagai fitur yang berdampak daripada overhead, eksekutif harus memperhatikan status kualitas dan berinvestasi di dalamnya, dan fungsi rekayasa harus menolak memperlakukan pembersihan kode sebagai "kentang panas."

Yang menambah tantangan delegasi ini adalah kenyataan bahwa metodologi dan alat yang ada gagal untuk mengatasi masalah kualitas kode secara keseluruhan. Penggunaan metodologi continuous integration/continuous delivery mengurangi dampak kode berkualitas rendah, tetapi kecuali CI/CD didasarkan pada analisis kualitas yang menyeluruh dan holistik, ia tidak dapat secara efektif mengantisipasi dan mengatasi sebagian besar bahaya. Tim yang bertanggung jawab untuk pengujian QA, keamanan aplikasi, dan kepatuhan lisensi bekerja dalam silo menggunakan alat yang telah dirancang untuk memecahkan hanya satu bagian dari masalah dan mengevaluasi hanya beberapa persyaratan non-fungsional atau fungsional.

Mempertimbangkan Peran Manajer Produk

Kualitas kode sumber memainkan banyak dilema yang dihadapi manajer produk selama desain produk dan sepanjang siklus hidup pengembangan perangkat lunak. utang teknis adalah overhead yang berat. Lebih sulit dan lebih mahal untuk menambah dan memodifikasi fitur pada basis kode berkualitas rendah, dan mendukung kompleksitas kode yang ada memerlukan investasi waktu dan sumber daya yang signifikan yang dapat dihabiskan untuk pengembangan produk baru. Karena manajer produk terus-menerus menyeimbangkan risiko dengan kecepatan masuk ke pasar, mereka harus mempertimbangkan pertanyaan seperti:

• Haruskah saya menggunakan perpustakaan OSS (perangkat lunak sumber terbuka) atau membangun fungsionalitas dari awal? Lisensi dan kewajiban potensial apa yang terkait dengan perpustakaan yang dipilih?
• Tumpukan teknologi mana yang paling aman? Mana yang memastikan siklus pengembangan yang cepat dan berbiaya rendah?
• Haruskah saya memprioritaskan konfigurasi aplikasi (biaya tinggi/penundaan waktu) atau menerapkan versi yang disesuaikan (biaya pemeliharaan tinggi/kurangnya skalabilitas)?
• Seberapa layak untuk mengintegrasikan produk digital yang baru diperoleh sambil mempertahankan kualitas kode yang tinggi, meminimalkan risiko, dan menjaga biaya rekayasa tetap rendah?

Jawaban atas pertanyaan-pertanyaan ini dapat berdampak serius pada hasil bisnis dan reputasi manajer produk itu sendiri, namun keputusan sering kali dibuat berdasarkan intuisi atau pengalaman masa lalu daripada penyelidikan yang ketat dan metrik yang solid. Proses evaluasi kualitas perangkat lunak yang menyeluruh tidak hanya menyediakan data yang dibutuhkan untuk pengambilan keputusan, tetapi juga menyelaraskan pemangku kepentingan, membangun kepercayaan, dan berkontribusi pada budaya transparansi, di mana prioritasnya jelas dan disepakati.

Menerapkan Proses 7 Langkah

Proses evaluasi kualitas kode sumber yang lengkap menghasilkan diagnosis yang mempertimbangkan set lengkap penentuan kualitas daripada beberapa gejala terisolasi dari masalah yang lebih besar. Metode tujuh langkah yang disajikan di bawah ini selaras dengan rekomendasi CISQ untuk perbaikan proses dan dimaksudkan untuk memfasilitasi tujuan berikut:

• Temukan, ukur, dan perbaiki masalah yang dekat dengan akar masalahnya.
• Berinvestasi secara cerdas dalam peningkatan kualitas perangkat lunak berdasarkan pengukuran kualitas secara keseluruhan.
• Serang masalah dengan menganalisis rangkaian pengukuran yang lengkap dan mengidentifikasi perbaikan terbaik dan paling hemat biaya.
• Pertimbangkan biaya lengkap produk perangkat lunak, termasuk biaya kepemilikan, pemeliharaan, dan penyelarasan peraturan lisensi/keamanan.
• Pantau kualitas kode di seluruh SDLC untuk mencegah kejutan yang tidak menyenangkan.

1. Pemetaan produk-ke-kode: Menelusuri fitur produk kembali ke basis kode mereka mungkin tampak seperti langkah pertama yang jelas, tetapi mengingat tingkat peningkatan kompleksitas pengembangan, itu tidak selalu sederhana. Dalam beberapa situasi, kode produk dibagi di antara beberapa repositori, sementara di lain, beberapa produk berbagi repositori yang sama. Mengidentifikasi berbagai lokasi yang menampung bagian-bagian tertentu dari kode produk diperlukan sebelum evaluasi lebih lanjut dapat dilakukan.

2. Analisis tumpukan teknologi: Langkah ini memperhitungkan berbagai bahasa pemrograman dan alat pengembangan yang digunakan, persentase komentar per file, persentase kode yang dibuat secara otomatis, biaya pengembangan rata-rata, dan banyak lagi.

Alat yang disarankan: jam

Alternatif: Tokei, scc, sloccount

3. Analisis versi: Berdasarkan hasil bagian audit ini, yang melibatkan pengidentifikasian semua versi basis kode dan menghitung kesamaan, versi dapat digabungkan dan duplikasi dihilangkan. Langkah ini dapat dikombinasikan dengan analisis bugspots (hot spot), yang mengidentifikasi bagian-bagian rumit dari kode yang paling sering direvisi dan cenderung menghasilkan biaya pemeliharaan yang lebih tinggi.

Alat yang disarankan: cloc, scc, sloccount

4. Peninjauan kode otomatis: Inspeksi ini memeriksa kode untuk cacat, pelanggaran praktik pemrograman, dan elemen berisiko seperti token berkode keras, metode panjang, dan duplikasi. Alat yang dipilih untuk proses ini akan bergantung pada hasil tumpukan teknologi dan analisis versi di atas.

Alat yang disarankan: SonarQube, Codacy

Alternatif: RIPS, Veracode, Micro Focus, Parasoft, dan banyak lainnya. Pilihan lainnya adalah Sourcegraph, solusi pencarian kode universal.

5. Analisis keamanan statis: Langkah ini, juga dikenal sebagai pengujian keamanan aplikasi statis (SAST), mengeksplorasi dan mengidentifikasi potensi kerentanan keamanan aplikasi. Sebagian besar alat yang tersedia memindai kode terhadap masalah keamanan yang sering terjadi yang diidentifikasi oleh organisasi seperti OWASP dan SANS.

Alat yang disarankan: WhiteSource, Snyk, Coverity

Alternatif: SonarQube, Reshift, Kiuwan, Veracode

6. Analisis komponen perangkat lunak (SCA)/Analisis kepatuhan lisensi: Tinjauan ini melibatkan identifikasi pustaka sumber terbuka yang terhubung langsung atau tidak langsung ke kode, lisensi yang melindungi setiap pustaka ini, dan izin yang terkait dengan masing-masing lisensi ini.

Alat yang disarankan: Snyk, WhiteSource, Black Duck

Alternatif: FOSSA, Sonatype, dan lainnya

7. Analisis risiko bisnis: Langkah terakhir ini melibatkan konsolidasi informasi yang dikumpulkan dari langkah-langkah sebelumnya untuk memahami dampak penuh dari status kualitas kode sumber pada bisnis. Analisis harus menghasilkan laporan komprehensif yang memberikan para pemangku kepentingan, termasuk manajer produk, manajer proyek, tim teknik, dan eksekutif C-suite, dengan perincian yang mereka butuhkan untuk mempertimbangkan risiko dan membuat keputusan produk yang terinformasi.

Meskipun langkah-langkah sebelumnya dalam proses evaluasi ini dapat diotomatisasi dan difasilitasi melalui berbagai produk sumber terbuka dan komersial, tidak ada alat yang mendukung proses tujuh langkah penuh atau agregasi hasilnya. Karena kompilasi data ini adalah tugas yang membosankan dan memakan waktu, itu dilakukan secara sembarangan atau dilewati seluruhnya, berpotensi membahayakan proses pengembangan. Ini adalah titik di mana proses pemeriksaan perangkat lunak menyeluruh sering kali gagal, membuat langkah terakhir ini bisa dibilang yang paling kritis dalam proses evaluasi.

Memilih Alat yang Tepat

Meskipun kualitas perangkat lunak berdampak pada produk dan dengan demikian hasil bisnis, pemilihan alat umumnya didelegasikan ke departemen pengembangan dan hasilnya mungkin sulit untuk ditafsirkan oleh non-pengembang. Manajer produk harus terlibat secara aktif dalam memilih alat yang memastikan proses QA yang transparan dan dapat diakses. Meskipun alat khusus untuk berbagai langkah dalam evaluasi disarankan di atas, ada sejumlah pertimbangan umum yang harus diperhitungkan dalam setiap proses pemilihan alat:

• Tumpukan teknologi yang didukung: Perlu diingat bahwa sebagian besar penawaran yang tersedia hanya mendukung sekumpulan kecil alat pengembangan dan dapat menghasilkan pelaporan yang sebagian atau menyesatkan.
• Kesederhanaan instalasi: Alat yang proses instalasinya didasarkan pada skrip yang rumit mungkin memerlukan investasi teknik yang signifikan.
• Pelaporan: Preferensi harus diberikan pada alat yang mengekspor laporan terperinci dan terstruktur dengan baik yang mengidentifikasi masalah utama dan memberikan rekomendasi untuk perbaikan.
• Integrasi: Alat harus disaring untuk integrasi yang mudah dengan alat pengembangan dan manajemen lain yang digunakan.
• Harga: Alat jarang datang dengan daftar harga yang komprehensif, jadi penting untuk mempertimbangkan dengan cermat investasi yang terlibat. Berbagai model penetapan harga biasanya mempertimbangkan hal-hal seperti jumlah karyawan tim, ukuran kode, dan alat pengembangan yang terlibat.
• Penerapan: Saat menimbang penerapan di lokasi versus penerapan cloud, pertimbangkan faktor-faktor seperti keamanan. Misalnya, jika produk yang dievaluasi menangani data rahasia atau sensitif, alat dan alat lokal yang menggunakan pendekatan audit buta (FOSSID) mungkin lebih disukai.

Menjaganya

Setelah risiko diidentifikasi dan dianalisis secara metodis, manajer produk dapat membuat keputusan yang bijaksana seputar prioritas dan triase cacat dengan lebih akurat. Tim dapat direstrukturisasi dan sumber daya dialokasikan untuk mengatasi masalah yang paling muncul atau umum. "Showstoppers" seperti pelanggaran lisensi berisiko tinggi akan didahulukan daripada cacat dengan tingkat keparahan yang lebih rendah, dan lebih banyak penekanan akan ditempatkan pada aktivitas yang berkontribusi pada pengurangan ukuran dan kompleksitas basis kode.

Namun, ini bukan proses satu kali. Pengukuran dan pemantauan kualitas perangkat lunak harus dilakukan terus menerus di seluruh SDLC. Evaluasi tujuh langkah penuh harus dilakukan secara berkala, dengan upaya peningkatan kualitas dimulai segera setelah setiap analisis. Semakin cepat titik risiko baru diidentifikasi, semakin murah obatnya dan semakin terbatas dampaknya. Menjadikan evaluasi kualitas kode sumber sebagai pusat proses pengembangan produk memfokuskan tim, menyelaraskan pemangku kepentingan, mengurangi risiko, dan memberi produk peluang terbaik untuk sukses—dan itulah urusan setiap manajer produk.