Mari kita mulai dengan yang manis dan memberikan contoh dari praktik pengujian.
Bayangkan sebuah toko online siap diluncurkan. Tidak ada yang menjadi masalah. Pemasar mengembangkan strategi promosi, artikel ditulis dalam sumber daya Internet khusus, dan iklan dibayar. Manajemen mengharapkan hingga 300 pembelian setiap minggu. Minggu pertama berlalu, manajer mencatat 53 pembayaran. Manajemen toko sangat marah ...
Manajer proyek berjalan mencari alasan: kurangnya pemikiran tentang kegunaan? lalu lintas yang tidak pantas? sesuatu yang lain? Kami mulai memahami, mempelajari sistem analisis data. Ternyata 247 orang mencapai kasir, dan hanya 53 yang membayar.
Analisis menunjukkan bahwa sisanya tidak dapat melakukan pembelian karena alamat email!
Pengujian formulir pemesanan diberikan kepada spesialis pemula. Dia mencoba yang terbaik, masuk ke bidang "Nama", "Email", "Telepon" semua opsi yang mungkin dan tidak mungkin yang memberinya generator online. Seminggu kemudian, semua bug ditemukan dan diperbaiki. Rilis telah terjadi. Tetapi di antara opsi yang dipertimbangkan tidak ada satu alamat email yang mengandung kurang dari 8 karakter setelah @.
Jadi pemilik email yang senang @ mail.ru, @ ya.ru (dan yang serupa) tidak dapat memasukkan email mereka dan meninggalkan situs tanpa berbelanja. Pemiliknya menerima kurang dari 600 ribu rubel, seluruh anggaran iklan dikosongkan, dan toko online itu sendiri menerima banyak ulasan negatif.
Apakah Anda pikir ini adalah kasus yang terisolasi? Maka di sini adalah kisah horor lain untuk pelanggan.
Setelah minat umum dalam pembayaran tanpa uang tunai, perusahaan pinjaman memutuskan untuk memperkenalkan cara baru mentransfer dana - ke kartu bank peminjam. Kami menerapkan formulir yang sesuai di akun pribadi manajer, menguji berbagai opsi kesalahan di bidang untuk memasukkan data kartu, memperbaikinya, dan mulai bekerja. Sebulan kemudian, manajemen mencapai informasi bahwa 24% calon peminjam yang telah menerima persetujuan tidak mengajukan pinjaman sampai akhir. Mengapa Mereka menyediakan kartu bank, yang jumlahnya terdiri dari 18 digit, bukan yang dijanjikan dan diuji 16. Baik sistem maupun manajer tidak dapat mendaftarkan kartu tersebut, dan pelanggan tidak memiliki apa pun.
Proyek percontohan dilaksanakan di 3 kantor kota. Jumlah rata-rata pinjaman bulanan di tiga kantor adalah 340. Hasil: organisasi kehilangan setidaknya 612 ribu rubel. pendapatan.
Ini hanya beberapa contoh di mana data sintetis dapat menyebabkan kerugian serius pada suatu proyek. Banyak penguji memasukkan data sintetis untuk menguji berbagai proyek - dari aplikasi seluler hingga perangkat lunak. Dalam hal ini, penguji sendiri menghasilkan situasi pengujian, mencoba memprediksi perilaku pengguna.
Namun, lebih sering daripada tidak mereka melihat pengguna tidak multidimensi, seperti di bioskop dengan kacamata 3D, tetapi samar, seolah-olah anak itu melukis seorang pria kecil di lembar album.
Ini mengarah pada fakta bahwa tester tidak mencakup semua situasi pengujian yang mungkin dan tidak dapat bekerja dengan sejumlah besar data. Dan, meskipun pengujian dapat dilakukan dengan baik, tidak ada jaminan bahwa sistem tidak akan crash ketika pengguna nyata (paling sering tidak logis dan bahkan tidak dapat diprediksi) mulai berinteraksi dengan produk.
Hari ini kita akan berbicara tentang data mana yang memberikan preferensi dalam proses pengujian: sintetis atau nyata.
Kami akan mengerti secara istilah
Setiap kali kami mengikuti tes, kami memutuskan data tes apa yang akan kami gunakan. Sumber mereka mungkin:
- Salinan database produksi di bangku tes.
- Basis data sistem klien pihak ketiga yang dapat digunakan saat ini.
- Uji generator data.
- Pembuatan data uji secara manual.
2 sumber pertama memberi kami data uji nyata. Mereka dibuat oleh proses yang ada oleh pengguna atau sistem.
Misalnya, ketika kami bergabung dengan proyek untuk mengembangkan produk web untuk perusahaan manufaktur, kami dapat menggunakan salinan database 1C yang ada untuk pengujian, yang selama beberapa tahun telah mengumpulkan dan memproses semua data tentang operasi dan pelanggan. Menggunakan modul untuk menghasilkan dan menampilkan laporan pada pesanan yang sudah selesai, kami mendapatkan informasi dari 1C dalam format yang diperlukan dan bekerja dengan data uji nyata.
Kami menyebut sumber dari poin 3 dan 4 "data uji sintetik" (istilah seperti itu dapat ditemukan dalam pengujian asing, tetapi jarang digunakan dalam segmen berbahasa Rusia). Kami membuat data sendiri untuk keperluan pengembangan dan pengujian.
Misalnya, kami menerima pesanan dari platform perdagangan elektronik baru untuk pengadaan oleh organisasi negara bagian dan kota di bawah 44 Hukum Federal. Di sini, aturan perlindungan informasi yang sangat ketat dipatuhi, sehingga tim tidak memiliki akses ke data nyata. Satu-satunya jalan keluar untuk pengujian adalah membuat seluruh set data uji dari awal. Bahkan tanda tangan digital fisik yang dimaksudkan hanya untuk pengujian.
Dalam praktik kami, satu jenis data jarang digunakan, biasanya kami bekerja dengan kombinasi dari mereka tergantung pada tugas.
Untuk memeriksa batasan dan pengecualian dalam sistem yang sama untuk perusahaan manufaktur, kami juga menggunakan data sintetis. Dengan bantuan mereka, kami memeriksa bagaimana laporan berperilaku jika tidak ada produk di salah satu pesanan. Pada platform perdagangan elektronik, kami menggabungkan data sintetis dengan buku referensi nyata OKPD2 dan OKVED2.
Kemampuan Data Sintetis
Dalam beberapa situasi, data sintetis tidak dapat disingkirkan! Mari kita lihat tugas apa yang dapat mereka gunakan dari gudang tester:
1. Penyederhanaan dan standarisasi
Seringkali data nyata adalah susunan data yang homogen: bayangkan bahwa ribuan individu dengan satu set atribut, badan hukum dari berbagai jenis, operasi standar dan banyak jenis entitas lain terdaftar dalam sistem. Lalu mengapa menghabiskan berjam-jam menguji input yang sama, jika Anda dapat menggabungkannya ke dalam grup dan menunjuk "perwakilan" untuk setiap grup?
Di salah satu proyek tahun lalu, pelanggan memutuskan untuk memperkuat tim penguji sebelum rilis berikutnya, yang melibatkan tim spesialis kami. Produk berisi formulir pendaftaran yang dimodifikasi dengan banyak bidang. Kami meletakkan formulir tes selama 30 menit dan menghabiskan jumlah waktu yang sama. Secara paralel, terungkap bahwa penguji lain sudah menguji formulir ini, setelah menghabiskan 7 jam di sana. Mengapa Dia hanya memutuskan untuk menjalankan tes sesuai dengan data nyata dari 12 karyawan dari daftar staf dan tidak memperhitungkan bahwa tes untuk satu karyawan mencakup semua atribut yang sama untuk setiap profil yang terdaftar.
Keuntungan: 6 jam 30 menit dan ini hanya pada satu tes.
2. Kombinatorik dan cakupan uji
Meskipun jumlah data nyata sering besar, mereka mungkin tidak mengandung sejumlah kemungkinan kasus. Untuk menjamin pengoperasian sistem dengan berbagai kombinasi data input, kita harus membuatnya sendiri.
Mari kita kembali ke contoh sebelumnya. Formulir pendaftaran dalam rilis baru diselesaikan karena suatu alasan. Tim pelanggan, berdasarkan norma-norma budaya perusahaan, memutuskan untuk membuat nama tengah menjadi wajib. Akibatnya, semua spesialis asing di negara bagian itu tiba-tiba memiliki satu ayah - Ivan (seseorang berkata untuk menulis Ivanovich sampai mereka memperbaikinya). Kasingnya lucu, tetapi jika Anda tidak memperhitungkan beberapa Daftar Keinginan atau parameter klien Anda dalam pengujian, maka jangan tersinggung jika orang-orang ini kemudian tidak memperhitungkan Anda dalam biaya / ulasan mereka.
3. Otomatisasi
Dalam pengujian otomatis, data sintetis sangat diperlukan. Bahkan perubahan yang tampaknya tidak signifikan dalam data dapat mempengaruhi operasi seluruh rangkaian uji coba.
Contoh dari sektor perbankan akan menjadi ilustrasi di sini. Untuk memeriksa apakah aplikasi dengan benar mencatat nomor rekening bank dalam dokumen yang dihasilkannya, kami menghabiskan 120 orang / jam menulis autotest. Tidak ada akses ke database, karena nomor akun ditunjukkan dalam autotest itu sendiri. Tes menunjukkan hasil yang sangat baik dan kami siap untuk menarik 180% + ROI dari otomatisasi dalam laporan. Namun seminggu kemudian database diperbarui dengan perubahan nomor akun. Semua autotest, serta upaya otomatisasi kami, berakhir dengan aman. Setelah merevisi autotest, ROI akhir turun menjadi 106%. Dengan kesuksesan yang sama, kami dapat segera mulai menguji dengan tangan kami.
4. Meningkatkan pengelolaan
Dengan menggunakan data sintetik, kita tahu (dalam kasus terburuk, kita mengasumsikan) respons seperti apa yang diharapkan dari sistem. Jika perubahan dilakukan pada fungsionalitas, kami memahami bagaimana respons terhadap data yang sama akan berubah. Atau kita dapat menyesuaikan data untuk mendapatkan hasil yang diinginkan.
Di salah satu proyek, tim kami mulai menguji menggunakan data nyata dari basis data rekanan pelanggan. Basis data secara aktif disempurnakan, tetapi pada saat itu disusun dengan sangat ceroboh. Kami kehilangan waktu mencoba memahami di mana kesalahannya, dalam fungsi atau dalam database. Solusinya sederhana, untuk menyusun basis data sintetis, yang menjadi lebih pendek, tetapi lebih memadai dan lebih informatif. Pengujian fungsi ini selesai dalam 12 orang / jam.
Jadi apa kerugiannya?
Data sintetis mungkin tampak mahakuasa. Begitulah, sampai Anda menemukan faktor manusia. Data sintetis sengaja dibuat oleh orang-orang dan ini adalah kelemahan utama mereka. Kami secara fisik tidak dapat memikirkan semua skenario dan kombinasi faktor input yang mungkin (dan tidak ada yang membatalkan force majeure). Dan di sini keuntungannya tetap untuk data nyata.
Manfaat bekerja dengan data nyata
Apa keuntungan yang kita lihat dalam bekerja dengan data nyata? 4 bukti dari pengalaman kami:
1. Bekerja dengan banyak informasi
Operasi sebenarnya dari sistem memberi kita jutaan operasi. Ulangi pekerjaan simultan dari ribuan pengguna atau pembuatan data otomatis tidak akan dapat dilakukan oleh tim spesialis mana pun.
Bukti: kami membuat basis data mini sintetis, yang, menurut kami, memenuhi semua kriteria basis pelanggan yang ada. Dengan basis sintetis, semuanya bekerja dengan baik, tetapi segera setelah Anda menjalankan tes dengan basis nyata, semuanya jatuh. Intinya: jika Anda tidak dapat memperhitungkan semua nuansa sampel data nyata, jangan buang waktu untuk menghasilkan data sintetis.
2. Menggunakan berbagai format data
Teks, suara, video, gambar, file yang dapat dieksekusi, arsip - tidak mungkin memprediksi apa yang diputuskan pengguna untuk diunggah ke bidang formulir. Kiat tentang format yang diterima mungkin diabaikan, dan larangan mengunduh mungkin tidak diterapkan oleh tim pengembang. Akibatnya, skenario yang diinginkan diuji. Misalnya, bahwa dalam bidang pengunduhan suara, memang mungkin untuk mengunduh file mp3 dan bahwa mengunduh file yang dapat dieksekusi tidak akan membahayakan sistem. Data nyata membantu kami melacak pengecualian.
Bukti: kami menguji bidang unggahan foto di profil pengguna. Kami mencoba format grafik yang paling umum dari database, ditambah beberapa file video dan teks. Kompilasi sintetis dimuat dengan sempurna. Dalam penggunaan aktual, ternyata setiap upaya untuk mengunduh file suara menyebabkan kesalahan. Seluruh formulir pendaftaran macet tanpa kemampuan untuk mengganti file. Bahkan penyegaran halaman tidak menyimpan.
3. Perilaku pengguna yang tidak dapat diprediksi
Meskipun banyak spesialis QA telah berhasil menciptakan dan menganalisis situasi luar biasa, mari kita jujur - kita tidak akan pernah dapat secara akurat memprediksi bagaimana seseorang akan berperilaku dan faktor-faktor di sekitarnya. Dan Anda dapat mulai dengan mematikan Internet pada saat operasi, dan diakhiri dengan operasi dengan kode program dan file internal.
Bukti: di perusahaan kami setiap tahun karyawan menjalani sertifikasi, di mana, antara lain, mereka mengevaluasi keterampilan mereka dalam kuesioner khusus. Perkiraan disetujui dengan kepala, dan berdasarkan pada mereka, tingkat (level) spesialis dihitung. Sebelum rilis, modul telah diuji sepenuhnya, semuanya bekerja seperti jam. Tetapi sekali, pada saat menyimpan hasil, serangan DDoS dilakukan pada sistem, sebagai hasilnya hanya sebagian data yang disimpan, dan upaya selanjutnya untuk menyimpan hanya menggandakan kesalahan. Tanpa situasi nyata, kita tidak akan melacak kesalahan serius seperti itu.
4. Pembaruan sistem
Sangat penting untuk memahami bagaimana sistem akan berperilaku selama upgrade, apa risiko yang mungkin terjadi, apa yang “tidak lepas landas”. Dalam program seperti 1C, di mana sejumlah besar direktori dan tautan, masalah pembaruan sangat akut. Dan di sini pilihan terbaik adalah memiliki salinan baru dari versi produksi, menguji pembaruan di atasnya, dan baru kemudian dirilis.
Bukti: kasusnya cukup umum. Proyek di bidang layanan anjak piutang. Kekritisan kehilangan dan distorsi data sangat besar, dan setiap kecurigaan tentang relevansi data yang direproduksi oleh sistem dapat menghentikan seluruh kantor. Dan di sini khusus kami bengkok meluncurkan pembaruan berikutnya segera ke prod, tanpa menangkap 10 versi terakhir dari build.
Mereka diluncurkan pada 18-00 tetap di pagi hari, pukul 11. Karena penyelesaian gagal dan tidak memahami dengan versi, pekerjaan divisi perusahaan benar-benar beku selama 2 jam. Manajer tidak dapat memproses kontrak saat ini dan mendaftarkan yang baru.
Sejak itu, kami telah bekerja dengan tiga stan tanpa gagal:- Berkembang. Perbaikan diletakkan di sini, terjadi anarki dan pelanggaran hukum, yang disebut pengujian pengecualian. Insinyur QA bekerja terutama dengan data sintetis, yang nyata jarang diinfuskan.
- Pra-rilis. Ketika semua perbaikan diimplementasikan dan diuji, mereka pergi ke cabang ini. Versi dengan penjualan juga sebelumnya digulirkan di sini. Dengan demikian, kami menguji pembaruan dan pengoperasian fungsi-fungsi baru dalam kondisi pertempuran yang kondisional.
- Produksi. Ini adalah versi tempur yang berfungsi dari sistem yang digunakan pengguna akhir.
Jadi apa data dan kapan harus bekerja?
Kami membagikan 3 wawasan pekerjaan kami dengan data nyata dan sintetis:
1. Ingat bahwa pilihan tipe data tergantung pada tujuan dan tahap pengujian. Jadi, mengembangkan sistem baru, kita hanya bisa beroperasi dengan data sintetis. Untuk mencakup berbagai kombinasi kondisi input, juga, paling sering, kita beralih ke mereka. Tetapi reproduksi beberapa pengecualian rumit terkait dengan perilaku pengguna akan membutuhkan log nyata. Hal yang sama berlaku untuk bekerja dengan direktori dan pendaftar yang diterima secara umum.
2. Jangan lupa untuk mengoptimalkan pekerjaan Anda dengan data uji. Jika memungkinkan, gunakan generator, buat register umum dari entitas utama, simpan dan gunakan cadangan sistem tepat waktu, gunakan di waktu yang tepat. Maka persiapan untuk proyek selanjutnya tidak akan menjadi sumber kemurungan dan kesuraman bagi Anda, tetapi salah satu tahap pekerjaan.
3. Jangan pergi ke sisi sintetis padat, tetapi jangan fokus pada data nyata. Gunakan pendekatan gabungan untuk menguji data agar tidak ketinggalan kesalahan, menghemat waktu dan menunjukkan hasil maksimal dalam pekerjaan Anda.
Terlepas dari kenyataan bahwa sintetik meramalkan masa depan yang hebat, dan para ilmuwan telah melihat dalam data sintetis harapan baru untuk kecerdasan buatan, sintetis bukanlah obat mujarab untuk pengujian. Ini hanyalah pendekatan lain untuk menghasilkan data uji yang dapat membantu memecahkan masalah Anda, dan dapat mengarah pada yang baru. Mengetahui kekuatan dan kelemahan data nyata / sintetis, serta kemampuan untuk menerapkannya pada waktu yang tepat, adalah apa yang melindungi Anda dari kerugian, downtime, atau tindakan hukum. Saya harap hari ini kami membantu Anda menjadi sedikit lebih aman. Atau tidak?
Mari kita bahas. Beri tahu kami di komentar tentang kasus Anda bekerja dengan data uji sintetis dan nyata. Mari kita lihat siapa di antara kita yang lebih: realis atau sintetis? ;)
Victoria Sokovikova.
Analis Uji di Laboratorium Kualitas