Nama saya Sasha Zubarchuk. Saya bergabung dengan Solid tiga tahun lalu sebagai Junior Manual QA. Sejak saat itu, saya menjadi insinyur otomasi, meluluskan siswa dari Sekolah QA pertama tempat kami bekerja, dan pindah ke posisi Manajer Produk.
Pada artikel ini, saya akan berbicara tentang fitur-fitur pengujian sistem pembayaran dan berbagi pengalaman tim kami: apa yang kami uji, bagaimana, tantangan apa yang kami hadapi dan bagaimana kami menanggapinya. Pengalaman ini akan berguna bagi mereka yang membangun proses pengujian pada proyek - baik insinyur QA dan manajer Produk / Proyek.
Saya tidak akan mempelajari teknik dan alat khusus, tetapi saya akan berbicara tentang gagasan utama: bagaimana membuat proses pengujian layanan yang secara teknis kompleks menjadi transparan dan setenang mungkin.
Terdiri dari apa layanan pembayaran dan cara kerjanya
Solid adalah gerbang yang memungkinkan bisnis di seluruh dunia untuk menerima pembayaran pelanggan online dalam berbagai cara, dari kartu bank dan dompet elektronik hingga PayPal dan Alipay.
Ada empat pemain utama dalam keseluruhan cerita ini:
- pengguna (dia juga pembeli);
- pedagang - bisnis apa pun yang menjual barang / jasanya di Internet dan ingin menerima uang untuk itu;
- gateway pembayaran - Solid;
- bank (acquirer) - lembaga keuangan yang melakukan transaksi dengan uang sungguhan.
Secara sederhana, tampilannya seperti ini: Sederhananya, kami membantu pedagang memonetisasi dan menghasilkan uang.
Anda mungkin memiliki pertanyaan: mengapa merchant memilih Solid, jika mereka dapat bekerja langsung dengan bank? Sederhana saja: 1) ada banyak bank, dan masing-masing memiliki kekhususannya sendiri - dengan menggabungkan bank yang berbeda dari berbagai negara ke dalam satu infrastruktur, kami mencapai konversi dan pendapatan maksimum; 2) kami memiliki keahlian yang luas dalam logika pembayaran dan antipenipuan; 3) selain pembayaran bank, kami menerima semua metode pembayaran alternatif yang populer di wilayah tertentu, dan 4) kami lebih murah.
Mari kita mulai dengan poin pertama - apa saja fitur melakukan pembayaran di berbagai negara? Misalnya, di AS, anehnya, Anda tidak akan dapat melakukan pembayaran semudah di Ukraina - hanya menggunakan detail kartu. Di sana, bank diharuskan memeriksa detail pembayar tambahan seperti alamat penagihan dan kode pos.
Ada banyak nuansa serupa. Serta alternatif pembayaran kartu. Di Belanda dan Jerman misalnya, orang suka menggunakan dompet internet lokal. Metode pembayaran paling populer di Tiongkok adalah Alipay, WeChat Pay, dan UnionPay. Dan di Nigeria , untuk membayar barang di Internet, pengguna pergi ke bank dengan uang tunai!
Kami menerima semua pembayaran populer, tanpa pengecualian - dari kartu bank hingga PayPal, dompet elektronik, Google Pay, Apple Pay, atau SMS. Dengan bantuan Solid, pedagang mendapat akses untuk bekerja dengan semua jenis pembayaran dalam satu integrasi. Selain itu, gateway memiliki perlindungannya sendiri terhadap penipuan, sistem perutean pembayaran, alat untuk mencegah tolak bayar yang tidak wajar, dan banyak lagi.
Mengapa menguji sistem pembayaran dan risiko tidak menguji
Banyak pedagang terhubung ke Solid. Oleh karena itu, kami bertanggung jawab tidak hanya untuk bisnis kami, tetapi juga untuk monetisasi semua klien yang terhubung dengan kami. Jika ada yang salah di pihak kami, kami membuat banyak perusahaan gagal. Dan sebaliknya - dengan menguji dan meningkatkan layanan pembayaran kami, kami meningkatkan produk bisnis lain.
Sayangnya, selain pembayaran yang berhasil, kesalahan dapat terjadi - baik sistem maupun pengguna. Penting untuk dipahami bahwa 100% pembayaran tidak akan pernah berhasil lulus di lokasi mana pun. Tetapi untuk bagian kami, kami berkewajiban untuk melakukan segalanya untuk membuat konversi pembayaran sebaik mungkin.
Menguji gateway pembayaran bukanlah tugas rutin, karena ini adalah mekanisme yang agak rumit dari lusinan layanan mikro dan interkoneksi. Kami menguji semuanya dalam tiga tahap. Pertama, kami memeriksa setiap tugas di lingkungan yang terisolasi, lalu kami menggabungkannya dan memeriksanya di kandidat rilis pada tahap tersebut, kami melihat bagaimana semuanya bekerja dalam integrasi, lalu kami merilis dan menguji semuanya lagi dalam produksi.
Mari kita lihat lebih dekat apa yang secara spesifik harus kita uji.
Fitur pengujian sistem pembayaran
Sistem pembayaran terdiri dari API dan antarmuka web. Tidak ada perbedaan utama dalam pengujian API dan web untuk sistem pembayaran, tidak seperti produk lainnya. Fitur utamanya adalah menguji pembayaran khusus untuk berbagai wilayah, serta semua layanan tambahan.
Tampaknya mudah untuk menguji pembayaran: Anda perlu melakukan pembayaran, memeriksa apakah uang itu didebit dari satu akun, dan dikreditkan ke akun lain. Tapi ada nuansa. Penguji perlu mengetahui secara spesifik pembayaran di berbagai negara, dan terkadang nuansa hukum dan peraturan perbankan setempat.
Poin kedua adalah jenis pembayaran yang berbeda: langganan, pembayaran pertama, otorisasi (pembekuan uang di akun), pembayaran melalui dompet elektronik. Masing-masing memiliki spesifikasi pengujiannya sendiri.
Perhatian khusus harus diberikan untuk bekerja dengan mata uang: tidak semuanya memiliki bagian pecahan. Misalnya, hryvnia memiliki satu sen, tetapi peso Chili tidak. Jika Anda mentransfer jumlah pembayaran 100 di Ukraina, bank akan menghapus 1 UAH, yaitu 100 kopeck. Dan di Chili itu berarti 100 peso. Seperti yang Anda lihat, momen seperti itu tidak boleh dilewatkan.
Apa yang perlu diuji dalam sistem pembayaran
Semua klien kami (web, aplikasi seluler, serta layanan back-end) berkomunikasi dengan kami menggunakan Solid API . Gateway itu sendiri terletak di cluster terpisah dan berkomunikasi dengan berbagai sistem (antifraud, tokenizer, bank, dll.).
Pengembang yang solid terlibat dalam menyelesaikan beberapa jenis masalah (dan semua tugas ini berakhir pada pembuangan tim QA):
- ( , , , , );
- (PayPal, Alipay Visa Mastercard);
- : API, ;
- ( , );
- , (, , -);
- .
Selain tugas yang datang langsung dari pengembang, kami menerima tugas lain: memeriksa semua data dan UAT saat menghubungkan pedagang baru, memeriksa tugas dari tim DevOps, menyiapkan aturan anti-penipuan.
Untuk meringkas, semua yang kami uji dapat dipecah menjadi kategori berikut:
Layanan backend yang solid:
- anti penipuan;
- layanan berlangganan;
- perutean pembayaran;
- sistem akuntansi dan pengendalian keuangan;
- integrasi dengan layanan eksternal.
Integrasi dengan bank:
- memeriksa kebenaran pekerjaan dengan mata uang;
- verifikasi berbagai jenis pembayaran (pembayaran pertama dengan data kartu, pembayaran dengan token, pengembalian uang, pembekuan uang, dll.);
- pemrosesan pemberitahuan.
Metode pembayaran alternatif (non-kartu):
- verifikasi pembayaran;
- memeriksa fitur lokasi.
Admin:
- panel admin internal (semua yang membantu analis Solid menjalankan pengujian A / B untuk konversi formulir pembayaran, menyiapkan aturan untuk antipenipuan);
- panel admin untuk pedagang.
Antarmuka pengguna:
- tampilan formulir dan halaman pembayaran;
- apakah formulir tersebut ditampilkan dalam bahasa di wilayah tertentu (Formulir pembayaran yang solid tersedia dalam semua bahasa di dunia);
- tampilan yang benar dari jumlah dan mata uang;
- melacak tindakan pengguna pada formulir;
- status halaman.
Lain:
- UAT saat menghubungkan pedagang baru ke Solid;
- tugas dari departemen risiko untuk memeriksa konfigurasi baru;
- studi kesehatan fungsional (misalnya, apakah Apple Pay berfungsi di WKWebView).
Langkah-langkah untuk Menguji Kesuksesan
Otomatisasi
Saat bekerja dengan solusi TI skala besar, seperti penyedia pembayaran, Anda perlu terus menguji tidak hanya pengoperasian elemen fungsionalitas individu, tetapi juga interaksinya. Ini tidak akan berfungsi tanpa otomatisasi. Jika beberapa layanan tidak dicakup oleh tes otomatis, kegagalan tidak dapat dihindari. Jalankan autotests jika memungkinkan. Menuangkan tugas ke lingkungan - jalankan pengujian. Menggabungkan beberapa tugas menjadi kandidat rilis - jalankan pengujian.
Dalam kasus kami, ini berjalan seperti ini:
- pengembang secara mandiri menjalankan pengujian saat mengimplementasikan tugas;
- penguji menjalankan pengujian saat menguji tugas di lingkungan yang terisolasi;
- pengujian secara otomatis diluncurkan saat versi baru dari build dibuat;
- autotests terus berjalan di lingkungan Prod.
Menjalankan tes otomatis membutuhkan waktu, oleh karena itu kami selalu berusaha untuk mengoptimalkan proses ini semaksimal mungkin. Pengujian dijalankan dengan cara multithread, dan juga dibagi menjadi tugas berdasarkan kepentingan.
Kami memiliki serangkaian pengujian minimal yang memvalidasi fungsionalitas pemrosesan pembayaran inti Solid - ini berjalan dalam waktu kurang dari satu menit. Semua pengujian Solid API dan layanan mikro lainnya membutuhkan waktu sekitar 3-4 menit. Tes UI, tentu saja, sedikit lebih lambat. Tetapi bahkan di sini kami tidak berhenti mengerjakan peningkatan dan pengoptimalan.
Mengapa pengujian terisolasi bukanlah pilihan terbaik saat menguji pembayaran? Saya akan memberi tahu Anda tentang kasus anti penipuan kami.
Setiap pedagang Solid memiliki akun anti-penipuan yang terkait dengan pengaturan aturan, bagaimana mereka harus bekerja. Misalnya, jika pengguna melakukan lebih dari tiga pembayaran per hari dengan pedagang, kami memblokir pembayaran keempat. Atau jika lebih dari lima pengguna melakukan pembayaran dengan kartu yang sama, kami juga memblokir dan menambah daftar hitam. Kami menutupinya dengan tes otomatis, tetapi mengalami masalah.
Awalnya, kami menggandakan semua aturan untuk akun pengujian, menyimulasikan tindakan penipuan, dan pengujian tersebut tampaknya berfungsi. Tapi ternyata pedagang sendiri sering mengalami situasi ketika aturan anti penipuan digabungkan, misalnya, tiga di antaranya berhasil.
Dengan mengisolasi setiap pembayaran untuk setiap aturan tertentu, kami menyingkirkan kemungkinan kombinasi aturan dan pengaruh layanan lain pada proses pembayaran.
Cara kami melakukan setiap pembayaran: kami menghapus data pengujian, membuat semua ketentuan agar pembayaran berada di bawah aturan tertentu, lalu berhasil. Tetapi bukanlah fakta bahwa hal itu akan terjadi dalam lingkungan kerja, karena tidak akan pernah ada situasi yang ideal untuk pembayaran yang jatuh di bawah satu aturan.
Kami memutuskan untuk menghubungkan aturan anti-penipuan nyata dari klien kami ke pedagang uji. Kemudian mereka mulai berolahraga dengan lebih jelas. Artinya, perlu untuk membuat aturan yang tidak terisolasi, tetapi untuk mengujinya secara agregat sebagaimana adanya untuk klien tertentu.
Sekarang pelanggan Solid dapat menyesuaikan aturan anti-penipuan untuk diri mereka sendiri. Karena transaksi yang tampak seperti penipuan untuk satu pedagang mungkin menjadi norma bagi pedagang lainnya.
Jika seseorang melakukan lima pembelian per hari di toko online, maka ini adalah normanya: pertama dia menyukai casing ponsel, kemudian notebook, dll. Namun untuk aplikasi fitnes, hal ini sudah menjadi anomali. Seseorang tidak mungkin membeli lima program latihan sehari.
Otomatisasi sangat membantu membangun keseimbangan: hanya fitur baru dan skenario yang memerlukan perhatian manusia yang diperiksa secara manual, yang lainnya otomatis. Otomatisasi dapat membantu mengurangi biaya pengujian dan risiko manusia.
Pengujian pada tahap spesifikasi teknis
Selain memeriksa langsung fungsionalitas fungsionalitas, kami mencurahkan banyak waktu untuk memastikan bahwa pengembang dan manajer memahami fungsionalitas yang diimplementasikan dengan cara yang sama. Tampaknya sudah jelas, tetapi banyak yang mengabaikannya.
Semua layanan konfigurasi cukup kompleks, mereka memiliki berbagai kemungkinan dan bahkan detail terkecil dapat menyebabkan layanan tidak berfungsi seperti yang diharapkan.
Teknik "pengujian awal" memiliki beberapa keuntungan sekaligus:
- tim pengembangan akan memahami tugas dengan benar, dan kami tidak akan membuang waktu untuk perbaikan;
- spesifikasi teknis yang tertulis dengan baik adalah 70% dari dokumentasi yang baik;
- Karena tim penguji telah mengenal TOR sebelumnya, skenario pengujian juga dipikirkan sebelumnya, dan pada saat tugas yang diimplementasikan sampai pada pengujian, prosesnya berjalan lebih cepat.
Dokumentasi tes yang bagus
Dokumentasi internal yang benar-benar bagus dan terstruktur adalah setengah dari pertempuran saat pengujian. Terlepas dari kenyataan bahwa hampir semua fungsi harus diotomatisasi, pekerjaan manual tidak akan pernah sia-sia.
Deskripsi proses pengujian untuk berbagai fungsi, artikel dengan solusi untuk masalah yang mungkin terjadi, dan berbagai manual mempercepat kerja tim pengujian.
Kami di Solid telah menciptakan basis pengetahuan kami sendiri. Ini menjelaskan cara kerja setiap bank dan metode pembayaran alternatif di lokasi yang berbeda, jenis pembayaran apa yang didukung bank, dan bagaimana, pada prinsipnya, pembayaran dilakukan di wilayah tertentu.
Basis seperti itu adalah tugas yang luas dan kompleks yang telah menjadi tantangan bagi kami. Penting untuk menyatukan semua dokumentasi dan mendeskripsikan proses dengan cara yang dapat diakses. Tapi sekarang, saat ada karyawan baru yang mendatangi kami, tidak ada masalah. Sulit untuk mengingat bagaimana sesuatu harus bekerja pertama kali, dan jika Anda memiliki dokumentasi pengujian, pilihan untuk membuat kesalahan minimal. Dokumentasi yang jelas memungkinkan penguji untuk menentukan dengan tepat mengapa pembayaran tidak berhasil: ini adalah kesalahan atau jenis pembayaran ini seharusnya tidak berfungsi di bank ini.
Izinkan saya memberi Anda contoh lain. Setelah kami mengubah logo sistem pembayaran internasional pada bentuk pembayaran. Kami memiliki lebih dari 200 desain berbeda untuk klien kami.Untuk setiap desain dapat ada beberapa konfigurasi bidang pada formulir. Misalnya, untuk Brasil, bidang CPF tambahan ditambahkan - analog dari kode identifikasi kami.
Karena ukuran logo yang baru, beberapa bidang di formulir bisa berpindah, hilang, atau tidak bisa diklik. Tak seorang pun di tim penguji Solid yang secara fisik tahu bagaimana 200 bentuk seharusnya terlihat.
Menguji tugas ini sangat menegangkan, tetapi sebagai hasilnya, kami membuat basis pengetahuan dengan formulir referensi untuk masing-masing pedagang kami, menutupinya dengan tes otomatis dan sekarang kami tidak takut dengan perubahan apa pun terkait desain.
***
Akhirnya, saya akan memberi tahu Anda sedikit fakta menarik dari dunia pemrosesan: pangsa penurunan Kartu Terbatas di Ukraina cukup rendah - 1-2%. Entah bank Ukraina begitu pandai dalam pencegahan penipuan, atau tidak ada yang mau mencuri data kartu pengguna Ukraina ...
Namun demikian, tidak ada produk dengan proses pengembangan dan pengujian yang ideal, tetapi kami dapat memperbaikinya. Toh, tugas setiap bisnis adalah mengeluarkan produk yang berkualitas. Siapa lagi, jika bukan teknisi QA, yang akan membantu dalam hal ini?
Saya akan senang jika Anda membagikan prinsip Anda tentang proses pengujian yang baik di komentar.