Cara menguji sistem POS tanpa perangkat keras sungguhan

Apa yang bisa diuji tanpa perangkat keras

Jauh lebih banyak daripada yang orang kira. Anda bisa memvalidasi pencarian produk, penambahan ke keranjang, perubahan jumlah, aturan diskon, penugasan pelanggan, pemulihan fokus, penanganan kesalahan, dan banyak kasus tepi yang dihadapi kasir tanpa menyentuh pemindai sungguhan.

Kuncinya adalah memisahkan logika alur kerja dari validasi perangkat keras. Jika masalahnya tentang bagaimana POS bereaksi terhadap masukan, perubahan keadaan, atau hasil pencarian, pengujian berbasis perangkat lunak biasanya cukup untuk menemukannya. Jika masalahnya tentang pemindai, printer, terminal, atau pembatasan USB, di situlah putaran perangkat keras menjadi perlu.

Mulai dari alur kerja pemindai

Di sebagian besar sistem POS, pemindai adalah ketergantungan pertama yang dikhawatirkan orang. Untungnya, ia juga salah satu yang paling mudah ditiru dengan baik karena banyak pemindai berperilaku seperti keyboard.

Karena itu alat emulator pemindai barcode adalah titik awal yang kuat untuk pengujian POS. Anda bisa menggerakkan bidang pencarian atau masukan item yang sama seperti di kasir dan memeriksa bagaimana layar bereaksi saat nilai barcode datang dengan cepat, dengan atau tanpa Enter di akhir.

Bangun matriks uji yang kecil tetapi realistis

Cara termudah mendapat cakupan yang dangkal adalah menguji satu produk jalur bahagia. Pendekatan yang lebih baik adalah membuat matriks kecil jenis item yang mencerminkan bagaimana POS berperilaku dalam alur ritel yang nyata.

Biasanya saya ingin setidaknya:

• satu produk normal yang ada stoknya
• satu barcode yang tidak dikenal
• satu item dengan nol di depan
• satu item terbatas atau berbatas usia
• satu produk dengan promosi atau aturan harga

Ini penting karena bug POS sering bersembunyi di aturan bisnis, bukan di pindaian itu sendiri. Jika set uji terlalu sederhana, layar bisa terlihat stabil sementara alur kerja sungguhan tidak.

Tirukan perilaku operator, bukan hanya perilaku sistem

Sesi POS bukan uji unit yang rapi. Kasir bergerak cepat, mengklik bidang yang salah, memindai ulang item, menutup permintaan terlalu awal, dan bekerja di bawah tekanan waktu. Jika kasus uji tanpa perangkat keras Anda tidak memodelkan kenyataan itu, cakupan akan terlihat lebih baik daripada yang sebenarnya.

Coba skenario seperti ini:

1. pindai item yang sama dua kali dengan cepat
2. pindai saat modal terbuka
3. hapus item lalu pindai lagi
4. picu penggantian manajer lalu pindai lagi
5. sengaja kehilangan fokus dan pastikan antarmuka pulih

Ini kegagalan yang realistis, dan persis jenis kasus yang emulator barcode bantu Anda ulang tanpa lelah.

Pakai lingkungan berlapis dengan sengaja

Untuk pengujian POS, saya suka tiga lapisan:

• pengembangan lokal dengan data yang disemai dan emulator barcode
• staging dengan logika harga, pajak, dan inventaris yang sungguhan
• validasi perangkat keras di terminal nyata sebelum rilis

Ini menjaga waktu perangkat keras yang mahal tetap terfokus pada kumpulan kecil bug yang benar-benar membutuhkan perangkat. Pengembang bisa membereskan sebagian besar cacat alur kerja secara lokal, QA bisa memeriksa skenario yang lebih luas di staging, dan spesialis perangkat keras bisa berkonsentrasi pada masalah tingkat perangkat.

Ketahui apa yang masih membutuhkan perangkat keras sungguhan

Pengujian tanpa perangkat keras kuat, tetapi ada batasnya. Anda tetap butuh perangkat sungguhan untuk:

• pemasangan pemindai dan perilaku driver
• keluaran printer struk dan penanganan kertas
• komunikasi terminal pembayaran
• pembatasan hub USB dan kios
• kendala jaringan dan terminal yang khas toko

Jujur tentang batas ini membuat sisa proses lebih kuat. Tujuannya bukan berpura-pura perangkat keras tidak penting. Tujuannya berhenti membuang waktu perangkat keras untuk masalah yang bisa tertangkap lebih awal.

Di mana tim biasanya keliru

Kesalahan paling umum adalah menunggu jalur perangkat keras yang lengkap sebelum menguji apa pun yang berarti. Itu terdengar hati-hati, tetapi biasanya menunda bug alih-alih mencegahnya. Jika pencarian produk gagal karena bidang pencarian kehilangan fokus setelah permintaan diskon, perangkat keras tidak akan membuat bug itu secara ajaib lebih mudah dipahami.

Masalah umum lain adalah hanya menguji satu jalur bahagia yang tenang. Sesi kasir sungguhan berisik. Operator memindai dengan cepat, mengulang item, mundur dari permintaan, dan berpindah alur kerja. Pengujian POS tanpa perangkat keras Anda harus mencerminkan kenyataan itu, atau ia akan melewatkan persis masalah yang akan pertama kali diperhatikan staf.

Contoh praktis

Bayangkan layar kasir di mana memindai produk harus menambah item, memperbarui keranjang, dan langsung mengembalikan fokus ke bidang pencarian produk. Sebagian besar itu bisa divalidasi tanpa perangkat keras:

• tirukan masukan pemindai barcode ke bidang pencarian
• pastikan item ditambahkan dengan benar
• pastikan promosi dan aturan harga berlaku
• pastikan pindaian berikutnya jatuh di bidang yang sama

Baru setelah itu lulus Anda membutuhkan pemindai fisik untuk keyakinan akhir. Urutan ini menghemat waktu dan biasanya membuat sesi perangkat keras lebih berguna.

Pemeriksaan kenyataan yang singkat

Anda bisa menguji sistem POS tanpa perangkat keras sungguhan jauh lebih efektif daripada yang banyak tim kira. Mulai dengan simulasi pemindai yang realistis, pasangkan dengan data uji yang stabil, dan dahulukan perilaku alur kerja. Lalu pakai perangkat keras sungguhan untuk kumpulan masalah yang lebih sempit, yang hanya bisa diungkap perangkat. Pendekatan itu lebih cepat, lebih murah, dan biasanya lebih disiplin daripada mengandalkan perangkat keras sejak awal.