Pemeriksaan Sebelum Rilis Baru Selesai di Perangkat Orang Lain

Baru Satu Orang yang Memakai Produk Ini Sampai Habis

Tanggal rilis tinggal beberapa hari lagi. Fiturnya lengkap, desainnya sudah disetujui, dan buildnya sudah duduk di server. Kelihatannya tinggal dibuka. Padahal satu-satunya orang yang pernah bergerak dari layar pertama sampai layar terakhir adalah orang yang membuatnya.

Pembuat selalu menyusuri jalannya sendiri. Nilai yang diketik di formulir pendaftaran adalah nilai yang selalu ia ketik. Rute menuju halaman pembayaran adalah rute yang ia rangkai sendiri. Jalan itu sudah dilewati puluhan kali, jadi tentu saja tidak tersendat. Masalahnya, pengguna pertama tidak datang lewat jalan itu. Mereka mendarat di halaman detail langsung dari hasil pencarian, meninggalkan pendaftaran di tengah jalan lalu kembali satu jam kemudian, dan menekan tombol kembali di browser saat proses pembayaran berjalan.

Karena itu pemeriksaan sebelum rilis lebih dekat ke pertanyaan siapa sudah melewati jalur mana, bukan berapa kotak yang sudah dicentang. Menyusuri satu jalur yang tidak pernah ada di daftar biasanya menemukan lebih banyak daripada memanjangkan daftarnya.

Susuri Satu Garis Penuh Tanpa Berhenti

Kalau layar diperiksa satu per satu, yang Anda dapat adalah produk dengan semua layar beres tetapi layanannya tidak jalan. Yang benar-benar dilakukan pengguna bukan satu layar, melainkan satu garis utuh sejak masuk sampai mendapatkan apa yang ia cari. Susuri garis itu tanpa memotongnya: daftar, terima email verifikasi, masuk, tambahkan barang, bayar, lalu cari catatan transaksi yang baru saja terjadi.

Kerusakan menumpuk setelah kegagalan, bukan setelah keberhasilan. Kartu ditolak. Email verifikasi tidak pernah muncul. Tombol kembali ditekan di tengah pembayaran. Tombol yang sama diketuk dua kali beruntun. Jalur mulus sudah dilatih puluhan kali selama pembangunan, sementara jalur gagal sering kali dirilis tanpa pernah dilewati sekali pun. Pesanan ganda, atau pembayaran yang tidak menempel ke pesanan mana pun, lahir persis dari sini.

Buat juga akun baru. Akun yang dipakai selama pengembangan sudah membawa izin dan data, sehingga tidak ada satu pun anggota tim yang pernah melihat kondisi kosong. Apa yang dilihat orang yang mendaftar pagi ini hanya terlihat dari akun yang baru dibuat.

Yang Dikirim Keluar Baru Terbukti Setelah Mendarat

Pesan konfirmasi di layar dan email yang duduk di kotak masuk seseorang adalah dua fakta berbeda. Formulir kontak, verifikasi pendaftaran, atur ulang kata sandi, konfirmasi pesanan, notifikasi. Semuanya belum terkonfirmasi sampai benar-benar dikirim ke alamat asli dan dibuka di sana.

Selama pembangunan, tim biasanya memvalidasi bagian ini dengan alat penangkap email, dan alat semacam itu tidak pernah melempar apa pun ke luar. Begitu berpindah ke pengiriman sungguhan, autentikasi domain pengirim menjadi gerbangnya. Penyedia kotak surat besar sudah beberapa tahun ini bergerak seragam menuntut catatan SPF, DKIM, dan DMARC pada domain pengirim, dan email tanpa itu mendarat di folder spam atau ditolak langsung. Catatan tersebut ada di tangan siapa pun yang memegang DNS, bukan di tangan yang menulis kode, dan itulah sebabnya urusan ini lebih sering ditemukan sesudah rilis alih-alih sebelumnya.

Periksa juga sisi penerimanya sekali. Kalau email yang dihasilkan formulir kontak diam-diam menumpuk di folder spam penanggung jawab, formulirnya bekerja sempurna dan pertanyaan dari calon pelanggan sekadar tidak pernah sampai.

Ponsel Lama, Koneksi Lambat, Jendela Tanpa Sesi

Mesin tempat produk ini dibangun selalu paling baru, layarnya lebar, koneksinya cepat, dan sesinya sudah masuk. Patahkan keempat kondisi itu sekali. Buka di ponsel yang umurnya sudah beberapa tahun, masuk dari halaman depan lewat jendela penyamaran tanpa sesi, dan perhatikan urutan kemunculan elemen ketika koneksinya lambat. Situs dengan banyak gambar memperlihatkan perilaku aslinya justru pada kondisi seperti ini dan tidak di tempat lain.

Pengaturan visibilitas masuk ke ronde yang sama. Lingkungan staging biasanya diblokir dari mesin pencari, dan ketika blokir itu ikut terbawa ke produksi, situsnya terbuka sempurna untuk manusia dan tidak pernah muncul di hasil pencarian. Kebalikannya juga terjadi: URL staging tetap bisa diakses sehingga konten yang sama hidup di dua tempat. Keduanya tidak kelihatan dari layar, dan keduanya kembali beberapa minggu kemudian sebagai pertanyaan kenapa tidak ada yang terindeks.

Bisakah Dikembalikan

Berapa pun banyaknya pemeriksaan, selalu ada yang baru muncul setelah rilis, jadi pertanyaan terakhirnya bukan apa yang sudah diverifikasi melainkan apakah ada tempat untuk mundur. Adakah orang yang tahu cara kembali ke versi sebelumnya, apakah pekerjaan itu selesai dalam hitungan menit dan bukan satu sore penuh, dan kalau perubahannya menyentuh basis data, cadangannya bertanggal kapan.

Tandai bagian yang tidak bisa diputar balik. Layar dan kode kembali dengan bersih. Data pengguna yang sudah dipindahkan atau dihapus, email yang sudah terkirim, dan pembayaran yang sudah ditagihkan tidak. Menjauhkan pekerjaan semacam itu dari hari rilis adalah bagian dari pemeriksaan.

Jam berapa Anda membukanya juga sebuah keputusan. Rilis Jumat sore berarti tidak ada yang tersisa untuk mengawasinya. Peringatan kesalahan dinyalakan sebelum rilis, bukan sesudahnya, karena perbedaan di hari pertama terletak pada apakah kabar kegagalan datang dari perkakas Anda sendiri atau dari pelanggan yang menelepon.

”Tidak Bisa Dipakai” Belum Termasuk Hasil Pengujian

Ketika laporannya datang sebagai satu baris yang berbunyi pembayaran rusak, orang yang memperbaiki harus menyusun ulang semuanya dari nol. Apa yang ditekan dan dalam urutan apa, perangkat serta browser mana, akun mana dan pukul berapa, dan apa yang muncul di layar. Dengan empat hal itu terlampir, penyebabnya biasanya menyempit saat itu juga. Tanpa keempatnya, sekadar mereproduksi sudah memakan satu hari penuh. Rekaman layar adalah versi tercepat dari keempatnya sekaligus.

Kalau yang memeriksa dan yang memperbaiki bukan orang yang sama, sepakati formatnya lebih dulu. Hari-hari terakhir menjelang rilis justru saat temuan menumpuk, dan laporan yang tidak tersusun mengubah waktu perbaikan menjadi waktu membaca.

Peran Orang Asing Biar Kami yang Ambil

Pemeriksaan kualitas pra rilis dari Weple adalah menyusuri jalur yang tidak pernah punya alasan untuk dilewati tim pembangun. Alur yang tidak boleh patah kami ubah menjadi pengujian otomatis yang dijalankan browser sungguhan, kami putar ulang pada kombinasi browser dan ukuran layar, lalu kami sisipkan dengan sengaja kondisi yang muncul di pemakaian nyata: nilai kosong, input yang sangat panjang, jaringan lambat, klik ganda, tombol kembali. Akses repositori tidak diperlukan, satu alamat yang bisa dibuka dan satu akun uji coba sudah cukup. Apa saja yang kami tangani dan dengan satuan apa pekerjaannya dihitung tertulis di halaman harga. Memanggil kami sebelum pengembangan selesai juga boleh dan biasanya lebih baik, karena masih tersisa waktu untuk membereskan apa yang ditemukan. Temuannya kami kembalikan lengkap dengan langkah reproduksi, rekaman layar, dan tingkat keparahan, sehingga bisa langsung Anda serahkan kepada siapa pun yang mengerjakan perbaikannya.