Apakah pengujian perangkat lunak berbeda ketika kita berhadapan dengan pengembangan game?

Saya membaca makalah ini tentang perbedaan antara pengembangan perangkat lunak secara umum dan pengembangan game dan penulis membuat beberapa poin bagus mengenai pengujian perangkat lunak, menunjukkan, misalnya, bahwa

... pengembang game ragu-ragu untuk menggunakan pengujian otomatis karena keusangan cepat tes ini dalam menghadapi keinginan kreatif bergeser dari desainer game.

Jadi, bacaan ini membuat saya berpikir, aspek apa lagi dalam pengujian perangkat lunak yang harus kita anggap berbeda atau khusus ketika kita berhadapan dengan / menguji suatu permainan? Adakah yang punya pengalaman dengan ini atau ada yang mendengar sesuatu tentang itu?

Game modern sebenarnya adalah satu ton konten seni kreatif yang dikembangkan menggunakan mesin game in-house atau proprietary. Mesin itu sendiri adalah unit yang dapat diuji untuk sebagian besar (rendering, geometri, fisika, modul AI dll). Demikian pula, tes sederhana juga dapat dilampirkan ke setiap bagian dari konten yang dikembangkan. Ini berarti pengujian unit dan kotak putih memang layak dan berhasil.

Sejauh "produk secara keseluruhan" yang bersangkutan, game adalah simulasi. Mungkin memiliki kompleksitas yang lebih generatif daripada program bisnis sederhana. Pikirkan dunia yang dihasilkan tanpa akhir, unik, prosedural versus perencana sumber daya perusahaan dengan perilaku yang terencana dengan baik. Sederhananya, jumlah cara unik yang mungkin untuk melakukan sesuatu dalam konteks game, bisa secara matematis, sangat sangat besar. Bahkan itu dianggap sebagai nilai jual untuk game.

Tambahkan ke fakta bahwa output akhir adalah murni audio visual dan tidak ada standar deterministik dari kebenaran absolut dari output tersebut. Chip GPU benar-benar tidak perlu melakukan perhitungan yang akurat, cukup banyak perhitungan, bahkan jika ada yang tidak tepat.

Dan akhirnya, tujuan utamanya adalah Hiburan . Gamer baik-baik saja dengan gangguan jika menjalankan 60+ FPS, terlihat luar biasa, dan memiliki konten menghibur selama berjam-jam.

Ini hanya menempatkan ide pengujian kotak hitam otomatis tradisional di wilayah "tidak begitu nyata dan sepadan" saat diterapkan ke permainan.

Namun, ada upaya baru-baru ini untuk melatih NNs untuk bermain game , yang secara efektif merupakan bentuk pengujian monyet belajar mandiri yang bersifat eksplorasi.

Sudah bertahun-tahun sejak saya melakukan gamedev tetapi di atas jawaban yang bagus, ada beberapa hal yang ingin saya tambahkan dan detail.

Pertama yang telah disebutkan adalah bahwa outputnya hanya visual dan auditori terhadap kendala "FPS-critical" yang ketat dan anggaran komputasi / memori. Gagasan kebenaran menjadi buram ketika pertanyaannya lebih seperti, "Apakah itu terlihat bagus? Apakah itu berjalan lancar tanpa gagap? Apakah itu terdengar hebat?" sementara pengembang mengutak-atik dan menyetel dan mendekati sementara kolaborasi desainer / pengembang mengarah ke hal-hal yang tampak dan terdengar sedikit berbeda dengan setiap iterasi cepat.

Satu lagi adalah bahwa penguji bisa luar biasa! Saya tidak pernah menemukan kelompok penguji yang lebih berdedikasi di domain lain, karena mereka mauuntuk menguji perangkat lunak. Mereka bersenang-senang. Mereka kecanduan dan tidur di samping komputer sambil menjelajahi setiap sudut dan celah permainan Anda. Menjadi sangat mudah untuk menemukan bahkan gangguan yang tidak jelas ketika orang benar-benar terhibur dengan saksama menguji setiap sudut perangkat lunak sementara secara praktis kecanduan. Dalam industri saya saat ini, para penguji sedikit lebih sulit untuk dikerjakan karena banyak dari mereka adalah para profesional yang mengaitkan mata pencaharian mereka dengan perangkat lunak, dan karenanya mereka mengandalkan beberapa fitur untuk menyelesaikan pekerjaan mereka dan tidak selalu tertarik untuk melelahkan. setiap sudut dan celah sepanjang waktu. Tentu saja ketika kita tidak bisa terlalu bergantung pada penguji manusia, kita membutuhkan lebih banyak pengujian otomatis.

Namun yang lain adalah bahwa basis kode untuk game biasanya tidak dipelihara dan dimodifikasi dan diperpanjang selama bertahun-tahun. Ini tidak seperti para pengembang Super Mario yang awalnya mengembangkannya di 6502 perakitan harus mempertahankan apa pun yang menyerupai kode asli lama setelah game dikirim. Doom 3 mungkin menggunakan nol baris kode (atau tutup) dari Doom 1. Jika ada waralaba yang berkelanjutan, game yang lebih baru lebih mirip "sekuel" daripada "peningkatan". Sebagian besar game hanya mengirim dan mungkin merilis beberapa tambalan, DLC, dan kemudian kode selesai. Itu sangat kontras dari industri VFX saya di mana saya telah bekerja pada pemeliharaan kode sejak Amiga hari yang telah diangkut dan dirawat selama beberapa dekade. Game biasanya tidak

Salah satu alasan sifat pendek basis permainan ini adalah karena mereka terikat dengan perangkat keras. Ketika dikombinasikan dengan sifat mutakhir dan persyaratan kritis FPS, mereka seringkali tidak dapat dikembangkan sedemikian rupa sehingga meringkas detail perangkat keras, bahkan tidak menutup. Mereka sering ditulis sangat spesifik untuk generasi target perangkat keras, dan biasanya tidak lama sebelum PS3 digantikan oleh PS4 yang kemudian menjadi usang dan digantikan oleh PS5, dan sebagainya, dan semuanya sangat cepat. Kemampuan perangkat keras memainkan peran sangat penting dalam desain dan pengembangan game sehingga umumnya tidak pantas untuk mempertahankan banyak kode yang sama yang ditulis untuk PSX seperti untuk PS4, misalnya. Kebanyakan waralaba game yang bertahan selama beberapa generasi masih menulis mesin generasi berikutnya. sebagian besar dari ground-up untuk perangkat keras terbaru.

Dengan basis kode berumur pendek datang waktu pemeliharaan terbatas (yaitu, waktu terbatas di mana kode harus dimodifikasi). Dengan waktu yang terbatas untuk mengubah kode yang tidak mencakup tahun dengan ruang lingkup mesin yang semakin besar dan lebih besar dengan setiap peningkatan, dan dikombinasikan dengan kenyataan bahwa permainan tidak dekat dengan mission-critical, tidak ada yang benar-benar seperti itu. kebutuhan kritis untuk menerapkan unit yang paling lengkap dan pengujian integrasi. Tidak ada untungnya melakukan hal itu dalam memastikan integritas perubahan di masa depan jika perubahan di masa depan tidak akan dilakukan, dan aspek pengujian dan refactoring dari basis kode warisan secara alami tidak relevan jika tidak ada "warisan" di tempat pertama.

Hal kecil lainnya yang tidak selalu relevan adalah bahwa gim mungkin hanya menargetkan jajaran perangkat yang sangat sempit tanpa porta desktop. Dalam kasus tersebut sumber besar gangguan yang tidak dapat diprediksi dalam konteks ini, yaitu pengguna yang menjalankan perangkat lunak dengan perangkat keras dan driver yang sangat berbeda, dihilangkan.

Yang mengatakan, pengujian integrasi pada level tertinggi / kasar cenderung lebih bermanfaat segera. Sebagai contoh, banyak game mungkin menggunakan cara untuk merekam bagaimana kondisi game berubah seiring waktu untuk "replay". Fitur replay semacam itu dapat memastikan bahwa game bersifat deterministik dan juga dapat digunakan sebagai bentuk alat pengujian sendiri untuk memutar ulang kembali sesi game yang direkam sebelumnya oleh orang lain.

Saya juga menemukan gamedevs yang bekerja di studio kecil yang melakukan hal-hal seperti menulis bot untuk permainan mereka dan meminta bot memainkan permainan mereka dengan kecepatan maksimal dan menjalankan simulasi itu, awalnya menemui crash yang tidak jelas setelah satu atau dua hari, kemudian memperbaikinya, lalu jalankan simulasi lagi, dan ulangi sampai tidak ada lagi crash yang berhenti bahkan setelah menjalankannya selama berminggu-minggu. Jadi ada beberapa jenis pendekatan pragmatis yang menarik seperti yang saya lihat dari gamedevs untuk menguji perangkat lunak mereka, tetapi seringkali dengan cara yang menyerupai tingkat pengujian integrasi yang paling kasar dan mensimulasikan hal-hal yang sangat dekat dengan bagaimana para pemain benar-benar berinteraksi dengan permainan.

Akhirnya mesin-mesin permainan AAA besar ini mulai menyerupai jenis binatang yang sama sekali berbeda: berumur panjang, berhasil mengabstraksikan perangkat keras sedikit lebih baik, dengan basis kode yang lebih besar dan rentang perawatan yang lebih lama sementara editor level mereka mulai menyerupai lingkungan pengembangan yang penuh. Saya membayangkan mesin-mesin besar itu mungkin akan meminta prosedur pengujian yang lebih menyeluruh, terutama jika waktu kode mereka dipertahankan meluas. Masih banyak studio game yang tidak menulis mesin game AAA besar: mereka melisensikannya atau mengembangkan mesin berpemilik kecil yang cakupannya jauh lebih kecil dan tidak akan dipertahankan selama bertahun-tahun.