Saya ingin berbagi pemikiran saya tentang salah satu kualitas perangkat lunak: pemeliharaan.
Proyek tidak selalu memperhatikan pemeliharaan. Akibatnya, dengan perubahan tim, kesulitan dimulai. Apalagi jika tim berubah secara tak terduga dan dengan komposisi besar.
Di proyek, saya memainkan peran QA. Di antara sifat-sifat lain, perlu untuk menjaga pendampingan. Dari sisi programmer, pertama-tama, tersirat bahwa kode harus disertai dengan komentar dan struktur yang baik. Sementara itu, iringan adalah sesuatu yang lebih. Pemeliharaan yang baik memungkinkan Anda memperoleh manfaat dari produsen produk perangkat lunak. Bukan tanpa alasan bahwa di perusahaan besar Anda dapat menemukan program kuno yang jauh dari antarmuka yang ramah, tetapi memiliki rawatan yang baik. Karena itu, mereka tidak terburu-buru untuk mengganti pengembangan perusahaan yang bersaing.
Anda bisa memberikan analogi dengan peletakan listrik di sebuah bangunan:
- Seorang tukang listrik yang baik akan memberi Anda sirkuitnya sebelum memasang kabel. Tidak perlu bahkan setelah bertahun-tahun untuk menoleh kepadanya untuk memahami apa yang mengarah ke mana dan bagaimana cara kerjanya. Tidak akan ada masalah selama operasi.
- Jika tukang listrik tidak membuat diagram pengkabelan, lain kali mereka hanya akan menghubunginya, karena kecuali dia, tidak ada yang tahu bagaimana semuanya diatur - maka Anda harus berpikir tentang apakah layak melakukan bisnis dengannya.
Sebagai seorang penguji, saya dapat menawarkan Anda untuk memperhatikan aspek-aspek berikut untuk meningkatkan perawatan.
Dokumentasi fungsi.
Dokumentasi diperlukan tidak hanya untuk “pengguna di suatu tempat di luar sana,” tetapi juga agar pada jam 12 siang siapa pun yang tidak terbiasa dengan produk dapat menggunakannya tanpa meminta bantuan orang lain. Sebagai contoh:
- seorang programmer yang disewa kemarin bisa men-debug fitur,
- dukungan teknis dapat menjawab pertanyaan pengguna
- tester dapat memeriksa apakah ada sesuatu dalam fitur yang tidak dikenal rusak.
Dokumentasi Infrastruktur
Banyak alat yang paling mungkin digunakan untuk membuat produk. Di antara mereka:
- sistem perakitan. Mungkin terdiri dari beberapa mesin, yang masing-masing memiliki banyak pengaturan;
- layanan infrastruktur lainnya, seperti server file, sistem penyimpanan kode (terutama jika ada ketergantungan perpustakaan pada sistem lain), dll.
- tempat ujian. Pengaturan dan deskripsi mereka harus ada dalam rencana pengujian.
Semua ini terkait dengan proyek. Dan alangkah baiknya jika memiliki deskripsi rinci tentang struktur, sehingga Anda dapat dengan mudah mengembalikannya jika hard drive dengan mesin struktur gagal. Atau agar Anda dapat dengan mudah melakukan perubahan pada infrastruktur tanpa menghabiskan waktu mempelajari setiap hal kecil.
Dokumentasi masalah dan risiko
Dalam proses menciptakan dan mengoperasikan produk, masalah pasti akan muncul. Mereka dapat diklasifikasikan dan dideskripsikan sebagai basis solusi.
Beberapa cacat mungkin memiliki solusi. Jika cacatnya serius, maka harus dimungkinkan untuk menemukan jalan keluarnya dalam database masalah. Misalnya, jika ada pengaturan yang hanya dapat diatur di browser tertentu.
Jika pengembangan mengungkapkan informasi bahwa masalah mungkin timbul di masa depan, maka informasi tersebut harus digambarkan sebagai risiko. Misalnya, jika sebuah modul digunakan dalam sistem dengan 100 pengguna, itu mungkin akan rusak dengan 500 pengguna.
Komentar dan deskripsi kode
Mungkin ada dokumen dengan deskripsi teknis semua modul, termasuk semua skema arsitektur.
Informasi tentang alat yang digunakan
Misalnya, alat apa dan bagaimana menggunakannya untuk debugging dan pengujian.
Terkadang seorang programmer mungkin membutuhkan alat penguji untuk men-debug fungsionalitas. Atau penguji mungkin memerlukan informasi tentang alat pengembang untuk mengumpulkan informasi ketika ditemukan cacat.
Termasuk patut memperhatikan prevalensi alat. Sekalipun beberapa alat sangat cocok untuk tugas yang dihadapi, tetapi sudah tua dan tidak didukung, itu bisa sulit.
Penyelesaian tugas
Seperti yang dikatakan prinsip Pareto: dibutuhkan 80% waktu untuk menyelesaikan 20% pekerjaan.
Dan jika sesuatu tidak selesai, maka pasti ada alasannya. Kemungkinan besar, itu mahal.