Keempat istilah ini sering dicampuradukkan, sehingga menimbulkan ekspektasi ruang lingkup dan perselisihan mengenai kata-kata yang berbeda. Menyepakati makna tim bersama lebih penting dalam praktiknya daripada memperdebatkan definisi buku teks yang benar.
Smoke testing
Smoke testing dengan cepat menentukan apakah sistem beroperasi secara luas dan cocok untuk pengujian atau penggunaan lebih lanjut. Biasanya mencakup jalur bahagia yang paling penting: startup, login, navigasi dasar, pembuatan entitas inti, dan ketersediaan API utama.
Sanity testing
Sanity testing adalah pemeriksaan yang sempit dan terarah terhadap perubahan atau area masalah tertentu. Setelah perubahan perhitungan diskon kecil, misalnya, tim memeriksa skenario terkait dan area sekitarnya, bukan keseluruhan produk.
Pengujian regresi
Pengujian regresi memeriksa ulang fungsionalitas yang ada untuk memastikan bahwa perubahan baru tidak merusak perilaku sebelumnya. Biasanya pengujian ini lebih luas daripada smoke testing atau sanity dan mengikuti risiko produk yang diketahui.
Pengujian ulang
Pengujian ulang, juga disebut pengujian konfirmasi, memeriksa defect tertentu yang telah diperbaiki: apakah bug teratasi dalam skenario penemuannya? Ini tidak menggantikan regresi karena tidak menentukan bagian lain yang mungkin terdampak.
Perbedaan praktis
- →Smoke: apakah build ini cocok untuk pengujian lanjutan?
- →Sanity: apakah area tertentu masih berperilaku seperti yang diharapkan setelah adanya perubahan lokal?
- →Pengujian ulang: apakah cacat khusus ini telah diperbaiki?
- →Regresi: apakah perubahan mempengaruhi fungsi lainnya?
Panduan praktis
- →Dokumentasikan kosakata tim bersama sehingga semua orang memahami ruang lingkup secara konsisten.
- →Bangun pengujian regresi berdasarkan risiko, bukan pemilihan kasus lama secara sewenang-wenang.
- →Jangan menganggap pengujian ulang saja sebagai bukti rilis yang cukup ketika perubahan berdampak pada area yang bergantung.
Pilih berdasarkan tujuan: rilis dengan perbaikan diskon
Persyaratan fiktif DISC-1: berikan diskon 10% ketika subtotal barang setidaknya 10000 sen. Defect yang dilaporkan menggunakan > alih-alih >=, sehingga keranjang 10000 sen tidak mendapat diskon. Semua jumlah di bawah menghasilkan sen bulat; jumlah lain memerlukan aturan pembulatan eksplisit. Rilis ini mengubah pembanding tersebut dalam fungsi perhitungan total bersama.
Pemeriksaan Tujuan Pemicu Cakupan Contoh
Smoke Apakah build layak untuk pengujian lanjutan? Deployment baru Kumpulan kecil fitur kritis Aplikasi terbuka, login berfungsi, katalog dimuat, checkout terbuka
Sanity (konvensi tim di sini) Apakah area yang diubah berperilaku masuk akal? Perbaikan kecil terarah Area terkait yang terbatas Subtotal 9900 / 10000 / 10100 menghasilkan 9900 / 9000 / 9090
Retest / konfirmasi Apakah defect yang dilaporkan sudah diperbaiki? Perbaikan masalah yang diketahui Reproduksi awal dan hasil yang diharapkan Keranjang 10000 sen yang sama kini menghasilkan 9000
Regresi Apakah perubahan merusak perilaku yang sudah ada? Perubahan dengan potensi dampak Fitur terkait dan bergantung yang dipilih berdasarkan risiko Pesanan tersimpan, faktur, dan perhitungan refund tetap sesuai harapan yang disetujuiSatu rilis, empat pertanyaan berbeda
Pertama jalankan lingkungan merokok. Jika checkout tidak dapat dibuka, catat pemblokir; penerapan yang gagal tidak membuktikan perbaikan komparator salah. Selanjutnya ulangi pengaturan cacat, akun, mata uang, dan masukan yang tepat pada build baru: 10000 harus menghasilkan 9000. Itu adalah konfirmasi. Kemudian selidiki nilai 9900 dan 10100 terdekat dengan kumpulan fokus; tim mungkin menyebutnya sebagai sanity testing.
Untuk regresi, periksa pemanggil perhitungan bersama sebelum memilih pengujian. Sertakan total pesanan tersimpan, total faktur, dan jalur refund yang benar-benar memanggil fungsi tersebut. Cocokkan masing-masing dengan hasil harapan tersimpan yang disepakati menurut aturannya sendiri; jangan menganggap refund otomatis 90% atau setiap pemakai mengikuti DISC-1. Tambahkan keranjang tanpa diskon yang sebelumnya valid sebagai kontrol. Luas cakupan mengikuti bukti ketergantungan dan risiko bisnis, bukan jumlah pengujian tetap.
Demonstrasi kecil yang dapat dijalankan
Simpan sebagai release_check_selection.py dan jalankan python3 release_check_selection.py. Keluaran yang diharapkan: Known defect reproduced; confirmation and three focused checks passed. Script hanya menunjukkan aritmetika dan logika pemilihan; tidak menjalankan smoke aplikasi atau regresi fitur bergantung.
def old_total(cents):
return cents * 9 // 10 if cents > 10000 else cents
def fixed_total(cents):
return cents * 9 // 10 if cents >= 10000 else cents
# Values below produce whole-cent results; no rounding rule is inferred.
assert old_total(10000) == 10000
assert fixed_total(10000) == 9000
for cents, expected in [(9900, 9900), (10000, 9000), (10100, 9090)]:
assert fixed_total(cents) == expected
print("Known defect reproduced; confirmation and three focused checks passed")Catat batas bukti
Satu kasus dapat masuk beberapa rangkaian: pemeriksaan 10000 sen merupakan bukti konfirmasi issue sekaligus pemeriksaan regresi masa depan yang berguna. Jangan menghitung eksekusi duplikat sebagai cakupan perilaku tambahan. Catat build, tujuan, hasil aktual, dan risiko belum dicakup agar pembaca memahami makna “lulus”.
Sanity memiliki arti berbeda antartim dan terkadang digunakan bergantian dengan smoke. Definisikan cakupannya secara lokal, bukan menganggap tabel ini klasifikasi wajib. Konfirmasi dan regresi menjawab pertanyaan berbeda; perbaikan reproduksi awal tidak membuktikan perilaku sekitarnya tetap sama.
Latihan: retest tepat 10000 sen lulus, tetapi faktur masih menampilkan 10000 setelah checkout menyimpan 9000. Bolehkah rilis dinyatakan bersih? Tidak. Defect awal mungkin diperbaiki sementara regresi fitur bergantung gagal. Catat kedua hasil dan selidiki ketidakkonsistenan; jangan jadikan retest sukses sebagai keputusan rilis.
Lanjutkan belajar
Susun strategi regresi berdasarkan risiko