Saya menulis sebagian besar Pengujian Perangkat Lunak Komputer lebih dari 25 tahun yang lalu. Sejak itu saya menunjuk beberapa bagian buku yang saya anggap ketinggalan jaman, atau hanya salah. Lihat http://www.kaner.com/pdfs/TheOngoingRevolution.pdf
Anda dapat melihat lebih banyak (tampilan saat ini, tetapi tanpa penunjuk eksplisit kembali ke TCS) di situs saya untuk Kursus Pengujian Perangkat Lunak Black Box (video dan slide tersedia secara gratis), www.testingeducation.org/BBST
Budaya pengujian saat itu sebagian besar konfirmasi.
Dalam pengujian modern, pendekatan pengujian unit sebagian besar bersifat konfirmasi - kami menulis koleksi besar pengujian otomatis yang hanya memverifikasi bahwa perangkat lunak terus berkinerja sebagaimana dimaksud. Tes berfungsi sebagai detektor perubahan - jika ada sesuatu di bagian lain dari kode dan bagian ini sekarang memiliki masalah, atau jika nilai data yang sebelumnya tidak mungkin di dunia nyata sekarang mencapai aplikasi, maka detektor perubahan akan menyala, memperingatkan programmer ke masalah pemeliharaan.
Saya pikir pola pikir konfirmasi sesuai untuk pengujian unit, tetapi bayangkan sebuah dunia di mana semua pengujian sistem adalah konfirmasi (untuk orang-orang yang membuat perbedaan, silakan tafsirkan "pengujian integrasi sistem" dan "pengujian penerimaan" sebagaimana tercantum dalam komentar saya pada sistem pengujian.) Maksud pengujian adalah untuk mengonfirmasi bahwa program memenuhi spesifikasinya dan pendekatan yang dominan adalah untuk membangun satu juta (atau setidaknya beberapa ratus) tes regresi tingkat sistem yang memetakan bagian-bagian spesifikasi untuk perilaku program. (Saya pikir konfirmasi spec-to-behavior berguna, tetapi saya pikir itu adalah sebagian kecil dari tujuan yang lebih besar.)
Masih ada kelompok uji yang beroperasi dengan cara ini, tetapi ini bukan lagi pandangan dominan. Saat itu, dulu. Saya menulis dengan tegas dan membuat perbedaan yang tajam untuk menunjukkan kepada orang-orang yang secara konsisten dilatih dalam pola pikir ini. Hari ini, beberapa kontras yang tajam (termasuk yang dikutip di sini) sudah usang. Mereka disalahartikan sebagai serangan terhadap pandangan yang salah.
Seperti yang saya lihat, pengujian perangkat lunak adalah proses empiris untuk mempelajari informasi terkait kualitas tentang produk atau layanan perangkat lunak.
Tes harus dirancang untuk mengungkapkan informasi yang bermanfaat.
Ngomong-ngomong, tidak ada yang berbicara tentang pengujian sebagai metode untuk mengungkapkan "informasi". Saat itu, pengujian adalah untuk (beberapa versi ...) menemukan bug atau untuk (beberapa versi ...) memverifikasi (memeriksa) program terhadap spesifikasi. Saya tidak berpikir bahwa pernyataan bahwa tes adalah untuk mengungkapkan informasi yang berguna masuk ke dalam kosa kata pengujian sampai abad ini.
Bayangkan uji peringkat dalam hal nilai informasinya. Tes yang sangat mungkin untuk mengajarkan kita sesuatu yang tidak kita ketahui tentang perangkat lunak akan memiliki nilai informasi yang sangat tinggi. Tes yang sangat mungkin untuk mengkonfirmasi sesuatu yang sudah kita harapkan dan yang telah ditunjukkan berkali-kali sebelumnya, akan memiliki nilai informasi yang rendah. Salah satu cara untuk memprioritaskan tes adalah menjalankan tes nilai informasi yang lebih tinggi sebelum tes nilai informasi yang lebih rendah.
Jika saya terlalu menyederhanakan prioritas ini sehingga akan menarik perhatian seorang programmer, manajer proyek, atau manajer proses yang tidak mengerti tentang pengujian perangkat lunak, saya akan mengatakan "UJI YANG TIDAK DIRANCANG UNTUK MENGUNGKAPKAN BUG ADALAH BUANG-BUANG ADALAH BUANG-BUANG WAKTU . " Ini bukan terjemahan yang sempurna, tetapi bagi pembaca yang tidak bisa atau tidak akan mengerti seluk beluk atau kualifikasi, itu sedekat yang akan didapat.
Saat itu, dan saya melihatnya lagi di sini, beberapa orang yang tidak memahami pengujian akan menjawab bahwa tes yang dirancang untuk menemukan kasus sudut adalah buang-buang waktu dibandingkan dengan tes penggunaan utama fungsi utama. Mereka tidak mengerti dua hal. Pertama, saat penguji menemukan waktu untuk memeriksa nilai batas, penggunaan utama dari fungsi utama telah dilakukan beberapa kali. (Ya, ada pengecualian, dan sebagian besar kelompok uji akan memperhatikan dengan hati-hati pengecualian itu.) Kedua, alasan untuk menguji dengan nilai ekstrem adalah bahwa program lebih cenderung gagal dengan nilai ekstrem. Jika tidak gagal secara ekstrim, Anda menguji sesuatu yang lain. Ini adalah aturan yang efisien. Di sisi lain, jika itu TIDAK gagal pada nilai ekstrim, tester mungkin berhenti dan melaporkan bug atau tester mungkin memecahkan masalah lebih lanjut, untuk melihat apakah program gagal dengan cara yang sama pada nilai yang lebih normal. Siapa yang melakukan pemecahan masalah (penguji atau pemrogram) adalah masalah budaya perusahaan. Beberapa perusahaan menganggarkan waktu penguji untuk ini, beberapa menganggarkan programmer, dan beberapa mengharapkan programmer memperbaiki bug sudut apakah bisa digeneralisasikan atau tidak sehingga pemecahan masalah tidak relevan. Kesalahpahaman umum - bahwa penguji membuang-buang waktu (daripada memaksimalkan efisiensi) dengan menguji nilai-nilai ekstrim adalah alasan lain bahwa "Tes yang tidak dirancang untuk mengungkapkan bug adalah buang-buang waktu" adalah pesan yang sesuai untuk penguji. Ini berlawanan dengan dorongan dari beberapa programmer untuk (pada dasarnya) tidak pernah menjalankan tes yang mungkin menantang program. Pesannya terlalu disederhanakan, tetapi seluruh diskusi disederhanakan.
Omong-omong, "nilai informasi" tidak bisa menjadi satu-satunya sistem prioritas. Itu bukan aturan saya ketika saya merancang suite tes unit. Ini bukan aturan saya ketika saya merancang tes verifikasi bangunan (alias cek kewarasan). Dalam kedua kasus tersebut, saya lebih tertarik pada jenis cakupan daripada pada kekuatan tes individu. Ada kasus-kasus lain (mis. Tes otomatis bervolume tinggi yang murah untuk dipasang, dijalankan, dan dipantau) di mana kekuatan tes individu tidak relevan dengan desain saya. Saya yakin Anda dapat memikirkan contoh tambahan.
Tetapi sebagai aturan umum, jika saya bisa menyatakan hanya satu aturan (misalnya berbicara dengan seorang eksekutif yang kepalanya meledak jika dia mencoba memproses lebih dari satu kalimat), itu akan berarti bahwa tes nilai-informasi yang rendah biasanya hanya membuang-buang waktu.