Benarkah Sistem Pengembangan Windows 10 Cacat?

Kasus bug yang beberapa kali ini terus menghantui update terbaru Windows 10 menjadikan banyak pengguna dan blogger tekno mempertanyakan sistem pengembangan Windows 10. Benarkah sistem pengembangan Windows 10 cacat?

 

Perubahan dalam sistem pengembangan Windows

Arstechnica, sebuah blog teknologi yang jadi panutan banyak penggemar tekno menulis sebuah artikel yang bagus tentang ini. Semua permasalahan tersebut berawal dari ambisi Microsoft dengan Windows 10 yang ternyata malah mengubah caranya mengembangkan Windows 10. Perusahaan yang bermarkas di Redmond ini ingin menanggapi pelanggan dan kebutuhan pasar lebih baik, serta tentu saja meletakkan fitur-fitur baru ke tangan pelanggan lebih cepat. Inti semua ini adalah bagaimana Windows 10 dirancang sebagai ‘versi Windows terakhir’, sehingga semua pengembangan dikirimkan kepada pengguna sebagai update terhadap Windows 10 dengan beberapa update besar yang dikirimkan beberapa kali setahun (umumnya dua kali setahun). Model pengembangan ini diberi brand sebagai “Windows as a Service”.

Microsoft menggunakan model baru untuk mengirimkan fitur-fitur baru yang bermanfaat kepada pengguna tanpa harus menjadikan pengguna menunggu selama dua-tiga tahun seperti era Windows sebelum Windows 10. Keuntungan model ini memang cukup besar. Konsumen bahagia karena mendapatkan jadwal tetap untuk memperoleh fitur-fitur baru dari Microsoft. Tapi ada masalah dengan model pengembangan ini: Kualitas!

Begitu banyak penggemar yang mengeluhkan kualitas Windows 10 setelah penambahan fitur-fitur baru secara rutin tersebut. Ini tentu saja cukup mengguncangkan Redmond.

 

Bukan masalah seberapa sering, tapi cara pengembangannya

Jika kita berkaca pada sistem pengembangan OS lain, dua update besar setahun ini sebenarnya lebih sering dibandingkan MacOS, iOS, dan Android. Jadi jelas bahwa memang Microsoft sudah bertindak berlebihan untuk mencapai hal tersebut.

Secara teknis, setiap update yang dibuat pada sistem akan secara otomatis disebarkan ke server produksi begitu sukses melewati pengujian otomatis. Namun Windows berisi banyak komponen individu yang sangat besar dan terintegrasi. Ini menjadikan pengembangan Windows menjadi sangat menantang. Dengan target memberikan dua update besar setiap tahun, pengembangannya menjadi cukup berat bagi developer.

Microsoft memang tidak secara detail mengungkap proses pengembangan Windows 10, akan tetapi karakteristik prosesnya bisa kita amati, yaitu melalui cara fitur-fitur ini dikirimkan kepada insider, kemudian bagaimana laporan insider mengenai bug yang terdapat pada build, digabungkan dengan informasi dari sumber-sumber lain, tentu saja bukan merupakan cara memadai untuk mengembangkan sebuah software penting.

Pada masa sebelum Windows 10, saat siklus rilis produk adalah dua hingga tiga tahun, Microsoft memecah proses menjadi beberapa fase: desain dan perencanaan, pengembangan fitur, integrasi, stabilisasi. Perkiraannya 4-6 bulan perencanaan dan desain, 6-8 minggu koding intensif, dan kemudian 4 bulan integrasi (setiap fitur akan dikembangkan ke cabangnya masing-masing sehingga semuanya bisa dikonsolidasikan dan digabungkan bersamaan), dilanjutkan dengan stabilisasi (yaitu pengujian dan perbaikan bug). Siklus ini bahkan diulangi tiga atau empat kali untuk mendapatkan kualitas terbaik. Namun di era Windows 10, hal tersebut harus dilakukan hanya dalam enam bulan!

Sebagaimana yang dijelaskan karyawan Microsoft, beberapa bulan pengembangan akan dibagi ke fase “tell“, disusul satu bulan fase “ask“. Dalam fase “ask“, hanya modifikasi penting yang diizinkan dengan mengabaikan banyak bug kecil. Contohnya, build pertama October Update (kode nama RS5) diperkenalkan kepada insider pada tanggal 14 Februari. Kemudian build stabil untuk April Update muncul dua bulan kemudian pada tanggal 16 April. RS5 tidak akan menerima fitur yang signifikan hingga 7 Maret. Banyak fitur baru kemudian ditambahkan pada bulan Mei hingga Juli, sebelum diluncurkan (untuk pengujian insider) pada bulan Agustus dan September. Microsoft kemudian hanya melakukan sedikit modifikasi pada hal-hal yang paling penting. Dengan cara ini maka build tersebut akan siap pada September untuk dirilis bulan Oktober.

Selama fase integrasi dan perbaikan bug, Microsoft mengirimkan preview build kepada insider dengan peringatan bahwa “dalam siklus pengembangan awal, build ini mungkin berisi bug yang akan menyusahkan untuk beberapa orang, jika Anda merasa tidak nyaman dengan ini, mungkin Anda ingin beralih ke Slow Ring yang memiliki kualitas build lebih tinggi”.

Dari sini kita tahu hal mendasar terkait pengembangan Windows: Tidak dilakukan tes terhadap semua kode ini secara memadai. Microsoft langsung meneruskannya kepada insider dan berharap bahwa kelompok Enthusiast ini akan bersedia dengan gratis menyelesaikan pekerjaan Microsoft menguji dan memeriksa bug apa saja yang terdapat pada build yang dikirimkan. Tentu saja karena diserahkan pada pengguna, maka Microsoft tidak dapat mengharapkan kualitas pengujian yang tinggi.

Pengujian yang tidak memadai ini menjadikan developer Windows tidak yakin terhadap arah pengembangan software tersebut. Mereka tidak yakin dengan situasi bug, dan tentu saja tidak mendapatkan laporan dengan kualitas memadai terkait bug tersebut. Ini menyebabkan upaya perbaikan bug menjadi tambal sulam jika tidak dapat dibilang menebak-nebak arah perbaikan dengan analogi yang sama seperti menembak dalam gelap.

Meskipun demikian, Microsoft mempertahankan metode ini dengan alasan, sistem ini memungkinkan Microsoft memiliki ribuan penguji yang menggunakan OS tersebut dalam situasi dunia nyata. Namun tentu saja Micorosft mengabaikan satu detail penting: kualitas pengujian. Jarang insider yang memberikan kualitas pengujian sesuai dengan yang diharapkan. Pendekatan Microsoft terhadap bug yang muncul adalah: “gabungkan bug sekarang, perbaiki nanti”. Namun pada praktiknya, Microsoft tidak pernah dapat menemukan bug dalam build rilisannya secara lengkap sehingga proses ini menjadi sebuah proses yang terus menerus.

Dibandingkan dengan era pengembangan Windows 7 dan Windows 8, Microsoft dulu memiliki sejumlah besar tester khusus, bahkan saking besar jumlahnya, Microsoft dapat menugaskan tester khusus untuk menguji setiap fitur kecil. Kebanyakan tester ini tidak dipekerjakan lagi pada tahun 2014 setelah Microsoft mendapati bahwa mengirimkan build pengujian kepada pengguna ternyata menghemat waktu dan biaya. Sayangnya, penghematan ini memakan korban yang lebih besar: kualitas!

 

Kesimpulan

Microsoft memiliki celah besar dalam proses pengembangan Windows, dan ini seharusnya menjadi perhatian Microsoft jika mereka memang ingin menjamin agar konsumen mendapatkan OS dengan kualitas terbaik. Argumen di atas menunjukkan bahwa ada yang salah dengan cara Microsoft mengembangkan OS-nya, utamanya pada bagian pengujian dan perbaikan. Jika ini berlanjut, maka kita dapat ‘berharap’ untuk terus melihat bug yang menyebalkan seperti ‘ketidaksengajaan’ Windows 10 menghapus file pengguna setelah October 2018 Update yang dirilis kemarin.

Bagaimana pendapat kamu mengenai hal ini? Mungkinkah ada cara lain untuk mengatasi permasalahan dalam pengembangan Windows 10 milik Microsoft?

 

Sumber https://indoint.com/