Baru-baru ini saya berkesempatan mengobrol dengan Alexei Nelyubov, Direktur QA dari Datcroft Games. Sekarang mereka sedang mengerjakan MMO Action Pixel Wars mobile, proyek ini sedang dalam tahap soft-launching. Departemen pengujian menemani permainan di setiap tahap perkembangannya, dan saya memutuskan bahwa artikel yang bagus tentang hub akan keluar dari cerita Alexey.
Berikutnya adalah pidato langsung.
Pixel Wars memiliki sejarah panjang dan sulit. Dipandu oleh tujuan bisnis, kami mulai merakit prototipe pertama game pada tahun 2016. Di masa depan, konsep itu sepenuhnya dirancang ulang dengan mempertimbangkan realitas pasar yang berubah, dan "Pixels" memasuki soft-game pada akhir 2018. Dalam waktu dekat, rilis komersial proyek direncanakan.
Siapa yang ada di tim?
Pemimpin departemen mendistribusikan tugas, hadir di semua pertemuan, membuat rencana pengujian, menetapkan prioritas untuk tugas, dan juga bertindak sebagai analis pengujian.
Berikutnya, ada tiga karyawan berpengalaman yang telah berjaga-jaga atas kualitas permainan selama lebih dari setahun. Salah satunya baru-baru ini duduk dengan ketat di autotests - itu membuat skrip pada kasus pada alat yang ditulis sendiri.
Baru-baru ini, seorang spesialis muda dan menjanjikan bergabung dengan tim kami (pertama dia datang kepada kami untuk kursus pelatihan, kemudian mendapat magang - dan sekarang ia ada di staf), yang sudah memecahkan banyak masalah menarik, dari memeriksa peta hingga menulis skrip otomatis sederhana. Dan segera kami menunggu yang lain.
Kami memiliki armada besar alat uji, mulai dari ponsel lama hingga perangkat ultra modern dengan OS dan fungsi terbaru. Terkadang menarik untuk menangkap bug hanya pada satu tablet, karena memiliki hard drive khusus, dan kemudian mencoba untuk menciptakan kembali kondisi yang sesuai di studio pengembangan.
Tugas apa yang dipecahkan oleh spesialis QA?
Seperti yang Anda ketahui, dalam model berulang, pengujian dimulai dengan penyelesaian pembentukan spesifikasi teknis dan desain tingkat tinggi. Jadi itu bekerja dengan kita. Kami membaca spesifikasi teknis sebelum mereka mulai mengimplementasikannya, melihat tata letak antarmuka baru, memeriksa kotak abu-abu kartu, melihat perhitungan matematika dalam dokumen perancang permainan.
Pada saat implementasi, kami tidak menunggu sampai semua pengeditan diunggah untuk dikuasai, tetapi kami secara aktif menguji masing-masing bagian fungsi di cabang yang berbeda. Mereka mungkin tidak memiliki grafik yang indah, kerucut merah muda mungkin berjalan bukan karakter, dan barel abu-abu akan berdiri di peta, bukan pohon dan semak-semak. Tetapi kita sudah dapat memeriksa fungsionalitasnya.
Sering ada kasus pengujian pasangan dengan pengembang di komputernya - ini sangat menghemat waktu perakitan. Jika seorang programmer biasanya hanya mencari fungsionalitas yang ia buat atau koreksi, dan hanya case positif, maka tester dapat langsung menemukan bug dalam case negatif, ditambah dari pengalaman, tahu persis apa yang bisa dipecahkan oleh programmer ini dalam modul ini. Analisis pengaruh juga membantu: misalnya, setiap kali kode guild berkuasa, sesuatu terjadi pada fungsionalitas teman. Mengapa tidak langsung memeriksa momen ini?
Ketika semua bagian kode, grafik, efek, suara, dan lokalisasi digabungkan menjadi master, saatnya untuk integrasi dan pengujian sistem. Kami melihat bagaimana fitur-fitur baru bekerja satu sama lain, dan melakukan tes massal dengan seluruh tim. Seringkali, bug seperti "Saya tidak nyaman" atau "Saya tidak merasa tertarik" keluar dari sini, yang juga dicatat dan diproses. Kami melihat tidak hanya pada karakteristik fungsional, tetapi juga pada bagaimana permainan berperilaku di bawah beban berat, "buruk" Internet dan di berbagai lingkungan yang tidak ideal, seperti naik bus melalui kota atau ruang bawah tanah pusat bisnis.
Bagaimana versi diterima?
Dan sekarang, semua bug jelas sudah diperbaiki, semua hal baru siap untuk melihat cahaya. Bisakah saya mengunggah ke prod? Tentu saja tidak. Perlu pendapat perwakilan dari semua departemen dan beberapa pemain sungguhan. Pada saat yang sama, regresi dimulai (saat autotest besar) dan pengujian penerimaan. Jika semuanya jelas dengan yang pertama (kami memeriksa semua fungsi permainan, menambahkan kasus yang sudah ketinggalan zaman, menambahkan yang baru, memeriksa juga), maka beberapa orang berbicara tentang penerimaan. Tetapi hal itu bermanfaat. Kami mengirimkan bangunan ke saluran umum proyek dan mendesak semua orang untuk bermain dan mengevaluasi permainan "dari menara lonceng mereka" selama beberapa hari. Mungkin ternyata perancang permainan tidak mewakili fitur lubang dengan taruhan sama sekali, walaupun semuanya dilakukan sesuai dengan deskripsi dan tata letak, dan pemasaran diperlukan kulit karakter pejuang lain untuk aksi di jejaring sosial. Ketika semua keinginan diperhitungkan, kita pergi ke produser, orang utama di proyek, dia memberikan lampu hijau, dan kemudian proses mengunggah versi ke prod dimulai. Saat ini, kita hanya di Google Play. aksi membutuhkan waktu setengah jam untuk sekitar satu jam.
Ketika semuanya sudah siap, kami tidak segera menghapus piring kerja profesional. Pertama, Anda perlu memastikan diri Anda bahwa peringkat diambil, pembayaran melalui, permainan diluncurkan, dan fitur baru telah sampai ke para pemain.
Selanjutnya, proses dimulai lagi.
Beberapa fakta lagi
Seringkali, untuk menguji permainan, itu tidak perlu diluncurkan. Ada mekanisme yang ada di mana beberapa parameter diubah. Hebat, unduh repositori baru, lihat file xml yang sesuai dan tutup tugas. Terkadang bug tidak ingin diulang. Misalnya, salah satu mitra bermain di proyek kami di kereta bawah tanah, saat ini teleponnya berdering, dan Internet dari 3g beralih ke wifi tanpa akses ke jaringan global. Pada saat yang sama, perangkat kehabisan ruang dan baterai terlalu panas. Tapi kami tidak memiliki bug yang tidak dapat diproduksi kembali, ada yang belum terjangkau oleh tangan.
Tentu saja, ada bug yang keluar dari prod. Dan jika pengguna menemukan satu, maka kemungkinan besar kami juga menemukannya. Itu hanya memiliki prioritas rendah atau reproduktifitas, jadi perbaikannya ditunda selama dua bulan.
Jarang, tetapi kebetulan membuktikan kepada programmer atau PM bahwa bug adalah bug dan perlu diperbaiki sekarang. Misalnya, pada kartu Anda bisa masuk ke zona aman musuh. Ya, Anda tidak dapat menyerang di sana, tetapi ini adalah cara yang bagus untuk memulihkan kesehatan dan menyerang musuh. Dia membuktikan - mereka memperbaikinya. Tidak - cari argumen yang lebih menarik. Argumen dalam gaya "keren" atau "Saya tidak suka" tidak diterima, diperlukan contoh nyata dengan konsekuensi nyata.
Kadang-kadang kami harus menguji terputusnya, berlari ke balkon di kantor, sampai ada pengaturan Internet "buruk" pada router.
Untuk mensimulasikan jaringan penuh dan menguji aplikasi dalam kondisi seperti itu, tester secara khusus berjalan di sekitar pusat perbelanjaan yang ramai dengan telepon.
Banyak bug ditangkap saat Anda memutuskan koneksi dan dengan cepat mengganti sesuatu. Di sini kecepatan kaset di layar sangat penting. Sebagai contoh, mereka menemukan kesalahan yang sama sekali tidak jelas: ketika Anda dengan cepat beralih kelas dan kulit karakter, pada akhirnya Anda memiliki pemanah memegang perisai atau prajurit dengan tongkat sihir.
Terima kasih atas perhatian anda! Saya harap Anda tertarik mempelajari lebih lanjut tentang proses pengujian game.