Halo pembaca yang budiman. Hari ini kami ingin bertepatan dengan peluncuran kursus "Python QA Engineer" . Mengantisipasi kemungkinan pertanyaan, kami memperingatkan bahwa artikel tersebut tidak menyebutkan sepatah kata pun tentang Python, namun demikian kami menemukan bahan ini berguna untuk penguji, dan karenanya memutuskan untuk membagikannya kepada Anda.
Pengujian setiap detail terkecil dari kode tidak layak, oleh karena itu, pengujian regresi harus melakukan pemeriksaan komprehensif dan fokus pada area spesifik secara keseluruhan. Tujuan utamanya adalah untuk memastikan bahwa tidak satu kesalahan regresi tunggal akan membahayakan proses bisnis yang kritis. Upaya inilah yang memungkinkan untuk memanfaatkan otomatisasi. Pendekatan pengujian otomatis yang bertujuan mengurangi kesalahan regresi akan membantu mengembangkan hubungan pelanggan yang baik dan meningkatkan nilai merek.
Tim saya bertanggung jawab untuk menguji aplikasi akuntansi yang menggunakan perhitungan canggih dan mencatat entri buku dalam sistem akuntansi. Semua ini adalah alur kerja, dan menutup buku setiap bulan di dalamnya adalah yang paling penting.
Dengan setiap rilis, ada beberapa perubahan dalam perhitungan, misalnya, untuk akun mungkin perlu untuk meningkatkan debit atau kredit, atau nilai yang ada dapat dibagi antara dua akun. Perubahan dalam aplikasi yang kompleks seperti itu, yang memiliki banyak dependensi internal dan eksternal, sering menyebabkan perilaku yang tidak terduga, termasuk kesalahan regresi, di tempat-tempat yang tak terduga dan tampaknya tidak terkait.
Mari kita berurusan dengan kesalahan regresi, kadang-kadang disebut insiden kritis atau masalah produksi. Setelah bekerja selama beberapa tahun di industri perangkat lunak, Anda menyadari bahwa kesalahan regresi bocor ke produksi jauh lebih penting daripada fungsi baru yang tidak berfungsi dengan baik. Faktanya adalah bahwa fungsi baru masih tersembunyi, oleh karena itu, ketika rusak, dampaknya pada komponen bisnis minimal, sementara dengan kesalahan regresi, pengguna bergantung pada fungsi kerja dan kemungkinan besar tidak memiliki versi cadangan dari sistem kerja.
Kesalahan regresi disebabkan oleh perubahan yang tidak diperhitungkan oleh manajer proyek atau pemilik produk selama tes penerimaan; arsitek, pengembang selama tinjauan kode pada tahap desain atau implementasi; atau oleh seorang analis-QA dan penguji dalam kasus uji. Semua jaringan keamanan melewatkan kesalahan dan pengguna menemukannya. Jika kesalahan dalam pembaruan terbaru terdeteksi di salah satu dari tahap di atas, mis. tim, pihak yang berkepentingan, atau tautan lain apa pun yang ada di organisasi Anda, lalu ditinjau sebelum dirilis, atau setidaknya dievaluasi kritikalitasnya.
Kesalahan regresi memerlukan beberapa biaya: koreksi mendesak, hukuman untuk potensi pelanggaran perjanjian tingkat layanan dan, yang paling penting, mereka merusak kepercayaan pengguna Anda pada produk Anda. Mereka mungkin memutuskan bahwa rilis baru akan merusak sesuatu yang sudah berfungsi.
Menjadi penting bagi tim saya untuk benar-benar memeriksa semuanya.
Namun, diketahui bahwa hal ini tidak mungkin, atau setidaknya terlalu mahal dan memakan waktu. Oleh karena itu, "menguji semuanya" berfokus pada dua hal berikut: proses bisnis kritis dan keyakinan bahwa perilaku dalam proses bisnis utama kritis akan sama dengan rilis terbaru, sebelum perubahan. Secara umum, kami ingin memastikan bahwa dalam rilis terbaru, kesalahan regresi tidak muncul dalam proses bisnis yang kritis.
Kami mengevaluasi pendekatan khas kami untuk pengujian otomatis untuk memverifikasi perhitungan dan untuk memverifikasi bahwa semua logika dijelaskan dalam kode untuk pengujian otomatisasi. Pendekatan ini menimbulkan pertanyaan klasik: "Siapa yang menguji kode tester?" Jika test case tidak berhasil, ada kemungkinan yang sama bahwa masalahnya ada pada kode tester. Selain itu, dengan setiap perubahan dalam aplikasi, kode pengujian juga perlu diperbarui, dan perubahan seperti itu sering terjadi.
Selain itu, berkat pengujian otomatis, kami memastikan bahwa kami memiliki set input yang tetap dan serangkaian output yang terkenal. Karena kerumitan aplikasi, tidak mungkin untuk mengirim semua set data input yang mungkin sekaligus. Berbagai set data juga dibutuhkan untuk akhir bulan, kuartal, tahun. Jadwal itu adalah masalah serius, karena butuh banyak waktu untuk menghasilkan set besar input data dan skrip yang sesuai.
Ada variabel lain: data pengguna. Kami memiliki hak istimewa: kami menerima salinan cadangan data pengguna setiap bulan. Kualitas pengujian secara langsung tergantung pada data yang digunakan untuk pengujian, dan data dari produksi selalu lebih baik daripada data yang dihasilkan, jadi hak istimewa kami adalah keuntungan besar yang tidak ingin kami lewatkan.
Identifikasi dan implementasi tes regresi
Gagasan kami adalah menggunakan pengujian otomatis, yang membutuhkan perawatan minimum yang diperlukan, dan yang memperkuat kepercayaan para pemangku kepentingan bahwa rilis akan memiliki kualitas yang tepat.
Jadi, kami membutuhkan strategi pengujian untuk kasus-kasus bisnis kritis yang akan menjamin tidak adanya kesalahan regresi dan, tentu saja, bahwa kami dapat segera dipraktikkan.
Proses persiapan kami terlihat seperti ini:
- Database cadangan dari produksi, dipulihkan dua kali;
- Dua sistem uji dipasang yang bekerja secara paralel:
- Satu dengan kode produksi;
- Lain dengan versi aplikasi saat ini sedang diuji.
Pendekatan ini memberikan dua sistem yang identik dengan perbedaan kode hanya dalam satu versi:
Memiliki dua sistem cukup penting, karena membantu untuk memahami bahwa masalah apa pun muncul hanya karena perubahan kode terbaru.
Tes dipisahkan, jadi dari proses standar "melakukan tindakan dan mendapatkan reaksi", kami melanjutkan ke fakta bahwa tindakan dilakukan dari satu titik ke titik lainnya sambil mempertahankan alur kerja, setelah itu laporan kesalahan dibandingkan. Ini adalah kunci untuk mendeteksi kesalahan tak terduga.
Ketika tester fokus pada fungsi baru atau semacam perubahan, tes ternyata difokuskan khusus untuk itu, mis. relevansi perubahan tertentu diperiksa. Pengujian regresi berbeda karena harus memverifikasi bahwa tidak ada yang lain yang berubah. Perbedaan ini tercermin dalam skenario otomatisasi. Itu membuat skrip pengujian fungsi khusus tidak cocok untuk mencari kesalahan regresi, sehingga pendekatan yang berbeda diperlukan di sini.
Misalnya, jika Anda bekerja dengan sistem manajemen pesanan, Anda akan memerlukan skrip untuk melakukan pemesanan dengan banyak data input untuk menempatkan pesanan untuk dua sistem pengujian yang terinstal (lebih disukai bekerja secara paralel), maka Anda mendapatkan laporan pesanan untuk hari terakhir dan membandingkan masing-masing nilai. Kemudian semua pesanan dikonfirmasi atau disetujui (tindakan ini), dan laporan, seperti pesanan harian yang dikonfirmasi, pesanan stok, laporan gudang, pesanan dari masing-masing operator, jenis pengiriman, jenis pembayaran, dll. akan dibandingkan dalam dua sistem. Ini berlanjut di seluruh alur kerja. Anda dapat menggabungkan tindakan, seperti menempatkan dan mengonfirmasi pesanan, lalu membandingkan laporan pada tahap yang berbeda.
Contoh lain adalah sistem manajemen hotel, di mana tindakan individu didefinisikan sebagai proses bisnis penting, seperti check-in, penagihan di restoran, dan menerima inventaris. Semua proses ini akan diberikan tindakan dan laporan mereka sendiri. Perbedaan dalam sistem ini dibandingkan dengan contoh sebelumnya adalah bahwa suite tes dapat berjalan secara paralel, dan tidak perlu menyelesaikan langkah sebelum memulai yang berikutnya.
Perbandingan kedua laporan itu adalah momen kebenaran, dan harus sempurna, dalam arti bahwa tidak ada pihak yang berkepentingan yang harus meragukan kebenarannya. Perbedaan dalam laporan adalah perbedaan nyata.
Untuk operasi ini, kami menggunakan antarmuka layanan web. Semua laporan dikirim secara paralel pada dua sistem, akibatnya, respons yang diterima dalam format JSON dibandingkan.
Perbandingan dilakukan pada tiga bidang:
- Sumber (produksi) dikurangi target (aplikasi yang diuji);
- Target dikurangi sumber;
- Perbandingan nilai untuk mendapatkan persimpangan.
Metode ini akan berfungsi untuk XML, XLS, CSV lebar tetap atau format lainnya. Kita perlu memastikan bahwa tidak ada catatan yang tidak perlu, tidak ada catatan yang hilang, dan semua nilai catatan cocok.
Ini adalah inti dari pendekatan yang sedang kita bicarakan. Semua ini dapat dibaca dalam aplikasi, yang dikeluarkan sebagai laporan atau, dalam beberapa kasus, berfungsi sebagai antarmuka ke aplikasi lain.
Keberhasilan pendekatan ini terletak pada alat perbandingan atau utilitas yang memproses kasus yang terkait dengan aplikasi Anda. Anda dapat menganggap diri Anda beruntung jika Anda menemukan sesuatu yang cocok "di luar kotak", jika tidak, penting untuk memahami bahwa berinvestasi dalam instrumen seperti itu sepadan karena akan membawa hasil yang baik.
Setelah semua pembicaraan tentang otomatisasi, Anda perlu memasukkan komentar. Karena beberapa perbedaan dalam laporan diharapkan, karena mereka harus ada seperti yang dipersyaratkan, semua hasil juga harus dianalisis secara manual. Harus ada hasil yang jelas dari keberhasilan dalam melewati kasus uji, namun, hasil yang gagal juga harus dianalisis dan validitasnya harus dikonfirmasi. Karena kita berbicara tentang kesalahan pengujian regresi, mereka harus diperbaiki sebelum dirilis. Tentu saja, ada beberapa pengecualian yang ditangani sesuai dengan aplikasi.
Pengaturan program
Semua aplikasi berbeda, dan menginstal serta mengonfigurasinya juga terjadi dengan cara yang berbeda. Untuk menyiapkan aplikasi untuk pengujian, beberapa langkah tambahan mungkin diperlukan, oleh karena itu, mereka harus diperhitungkan pada waktu yang tepat dan di tempat yang tepat untuk menjalankan tes. Berikut adalah serangkaian langkah-langkah khas:
"Membingungkan" data dari produksi dengan menghapus pengidentifikasi email atau informasi rahasia lainnya, atau menggantinya dengan data fiktif;
Dapatkan data dalam bentuk yang tepat untuk menjalankan tes;
Menyesuaikan pengaturan untuk lingkungan QA, misalnya, dengan mengubah hubungan integrasi.
Satu-satunya hal yang patut diingat adalah bahwa langkah-langkah di atas harus dilakukan untuk kedua instalasi. Ingat bahwa sebelum memulai test suite, pengaturan harus identik.
Seringkali, tindakan selain meminta laporan dapat mengembalikan objek, misalnya, tindakan, seperti membuat atau memodifikasi pesanan, dapat mengembalikan objek pesanan baru. Dalam hal ini, Anda perlu membandingkan dua objek dan tidak menunggu perbandingan laporan. Ini dapat membantu mengidentifikasi kesalahan pada tahap awal di root.
Anda juga disarankan untuk membagi seluruh set menjadi set yang lebih kecil, misalnya dengan mengelompokkan transaksi dan laporan terkait secara bersamaan. Set dapat dijalankan secara paralel untuk menghemat runtime. Namun, untuk aplikasi dengan alur kerja yang khas, ini hanya berfungsi jika Anda dapat membagi case secara vertikal dan horizontal, atau sebaliknya.
Variasi dapat dimulai dengan teknologi - JSON, XML atau scaler (int / string / float), dan berkembang hingga aplikasi yang sedang diuji dan produksi akan merespons dengan struktur yang berbeda, tetapi tetap mematuhi arsitektur. Misalnya, versi produksi dapat menggunakan file JAR lama, yang beroperasi dalam format tertentu, dan dalam versi baru file JAR diperbarui dan sekarang format respons telah berubah, sehingga perbandingan mereka akan menunjukkan ketidakkonsistenan. Untuk membandingkannya dengan benar, Anda memerlukan plug-in sementara.
Mungkin akan ada beberapa situasi seperti itu. Dalam kasus seperti itu, kadang-kadang lebih mudah untuk mengubah desain atau mempertimbangkannya dalam konteks solusi.
Ada beberapa opsi untuk menangani perbandingan seperti ini:
Abaikan beberapa bidang, seperti pengidentifikasi dan tanggal;
Abaikan perbedaan angka kurang dari 0,0001;
Abaikan sensitivitas case;
Struktur berubah dalam dua jawaban.
Meningkatkan Pengujian Regresi
Pengujian regresi harus holistik dan fokus pada keseluruhan area. Saldo ini akan membantu memanfaatkan otomatisasi. Pendekatan pengujian otomatis akan membantu mengurangi jumlah kesalahan regresi dan akan membantu dalam perjalanan menuju hubungan pelanggan yang baik dan meningkatkan nilai merek.
Sekarang, dalam ritme gerakan maju terus-menerus, tim kami ingin mencoba untuk meninggalkan dua instalasi sistem yang sama yang kami gunakan sekarang dan menerapkan strategi yang sama pada satu instalasi. Kami ingin menyimpan jawaban dari prestasi masa lalu dan menggunakannya untuk perbandingan. Pendekatan pengujian selalu dapat ditingkatkan. Doakan yang terbaik untuk kita!
Terjemahan disiapkan khusus untuk siswa kursus "Insinyur Python QA" .