Apakah verifikasi dan validasi merupakan bagian dari proses pengujian?

9

Berdasarkan banyak sumber saya tidak percaya definisi sederhana bahwa tujuan pengujian adalah untuk menemukan bug sebanyak mungkin - kami menguji untuk memastikan bahwa itu berfungsi atau tidak. Misalnya followint adalah tujuan dari formulir pengujian ISTQB:

  1. Tentukan bahwa (produk perangkat lunak) memenuhi persyaratan yang ditentukan (saya pikir verifikasinya)

  2. Tunjukkan bahwa (produk perangkat lunak) cocok untuk tujuan (saya pikir itu validasi)

  3. Deteksi cacat

    Saya setuju bahwa pengujian adalah verifikasi, validasi dan deteksi cacat. Apakah itu benar?

John V
sumber
1
Hal pertama yang dikatakan buku tentang pengujian adalah bahwa "pengujian bukanlah proses menunjukkan bahwa perangkat lunak bekerja dengan benar. Ini adalah proses menemukan cacat". Dan daripada buku-buku itu membawa banyak alasan untuk mendefinisikan pengujian seperti itu. Jadi verifikasi bahwa itu adalah proses menemukan di mana perangkat lunak tidak memenuhi persyaratan.
superM
Menurut definisi, verifikasi memastikan bahwa persyaratan dipenuhi. Sebenarnya, buku mendefinisikan pengujian sebagai proses mengukur kualitas perangkat lunak. Jadi, jika Anda memeriksa bahwa sistem itu berfungsi (positif) dengan maksud untuk melihat apakah ia berfungsi, itu bukan pengujian karena Anda tidak mencari bug? :) Di Wikipedia: Teknik pengujian mencakup, tetapi tidak terbatas pada, proses menjalankan program atau aplikasi dengan tujuan menemukan bug perangkat lunak
John V
Saya pikir cara terbaik untuk mengidentifikasi batasan-batasan kata pengujian adalah dengan berpikir menguji hipotesis, dalam hal ini Anda mencoba menguji bahwa tidak ada kesalahan atau ketidaktepatan dalam hipotesis, ini tidak sama dengan memverifikasi kegunaannya. atau memvalidasi penerapannya, ini hanyalah kasus mengidentifikasi seluruh lingkup perilaku, terlepas dari tujuan.
Jimmy Hoffa
Dapatkan bonus "pertanyaan bagus" :)
Andrew

Jawaban:

1

Saya pikir Anda sudah benar.

  1. Verifikasi dan Validasi adalah hal-hal yang berbeda dan pada kenyataannya cukup jelas. Walaupun saya tidak terlalu menyukai dokumen tersebut, ISO 9000ff sangat relevan untuk QA dan mendefinisikan Verifikasi sebagai membandingkan produk dengan persyaratan dan Validasi sebagai pengecekan apakah itu benar-benar sesuai dengan kebutuhan pelanggan / pengguna dan kita semua tahu ini dapat berbeda. .

  2. Keduanya bisa dilakukan melalui pengujian. Verifikasi akan mengarah pada tes persyaratan formulir yang dihasilkan. Validasi mengarah ke pengujian yang dilakukan oleh Tes tanpa merujuk langsung ke persyaratan. Saya pikir ini sering disebut pengujian eksploratif. Jelas itu harus dilakukan oleh orang-orang dengan pemahaman nyata tentang kebutuhan nyata pengguna, sehingga pengujian alpha dan beta oleh pengguna nyata adalah pilihan yang jelas.

  3. Secara teori saya kira orang bisa berdebat apa pun yang dicakup oleh dua yang pertama bukanlah bug dan karenanya menemukan bug sebagai tujuan terpisah tidak masuk akal. Tetapi saya pikir ada hal-hal yang Anda tidak dapat benar-benar memverifikasi atau memvalidasi. Misalnya keamanan: Bagaimana Anda memvalidasi atau memverifikasi bahwa sistem perangkat lunak aman terhadap serangan? Sebaliknya Anda mencoba menemukan kerentanan. Pencarian ini tidak memverifikasi atau memvalidasi apa pun jika gagal menemukan masalah, tetapi ia menemukan bug jika berhasil.

Jens Schauder
sumber
Masalahnya adalah bahwa banyak sumber menyebutkan bahwa verifikasi hanya statis, sementara validasi bersifat dinamis. Sangat membingungkan. Apa yang akan menjadi tes fungsional? Saya akan mengatakan verifikasi dinamisnya ..
John V
1
Sumber apa yang menggunakan definisi verifikasi dan validasi ini? Di sisi lain saya tidak tahu dengan jelas dan secara umum menyetujui definisi apa pun yang berakhir dengan -test. Jadi saya tidak benar-benar tahu apa tes fungsional untuk Anda.
Jens Schauder
Yah misalnya ISO 12207 membatasi pengujian hanya sebagai proses validasi.
John V
3

Dari Wikipedia: "... Dengan kata lain, validasi memastikan bahwa produk benar-benar memenuhi kebutuhan pengguna , dan bahwa spesifikasi itu benar sejak awal , sementara verifikasi memastikan bahwa produk telah dibangun sesuai dengan persyaratan dan spesifikasi desain Validasi memastikan bahwa "Anda membuat hal yang benar". Verifikasi memastikan bahwa "Anda membangunnya dengan benar". Validasi mengonfirmasi bahwa produk, sebagaimana ditentukan, akan memenuhi penggunaan yang dimaksudkan. "

Anda tidak dapat menguji kebutuhan pengguna dan memeriksa apakah spesifikasinya sesuai dengan kode. Jadi validasi tidak dilakukan dengan pengujian.

Verifikasi mengandaikan bahwa persyaratan dan desain Anda benar, sehingga Anda dapat mengujinya dengan menulis kode (pengujian).

Mert Akcakaya
sumber
Saya tidak akan setuju - pengujian bukan hanya pengujian kode, ada juga pengujian dokumentasi dll. BTW, wikipedia juga mengatakan: Pengujian perangkat lunak dapat dinyatakan sebagai proses memvalidasi dan memverifikasi bahwa program perangkat lunak / aplikasi / produk .. Anda memvalidasi program oleh eksekutifnya dan investigasi apakah ini yang diinginkan pengguna atau tidak.
John V
Sebenarnya kamu benar. Proses pengujian juga termasuk Menerima Pengujian tetapi saya berbicara tentang Unit, Integrasi dan pengujian Sistem. Jika kita berpikir tentang proses pengujian secara keseluruhan, verifikasi dan validasi dilakukan dengan pengujian.
Mert Akcakaya
1

Untuk dunia nyata, pengujian adalah verifikasi dan validasi perangkat lunak yang memenuhi persyaratan perangkat lunak (bisnis / fungsional / non-fungsional). Tujuannya adalah untuk menentukan apakah perangkat lunak cocok untuk tujuan. Perilaku apa pun yang tidak memenuhi persyaratan aplikasi adalah cacat - keparahan yang perlu dipertimbangkan sebelum menentukan apakah perangkat lunak tersebut sesuai untuk tujuan.

Cacat keparahan rendah mungkin bukan penghalang untuk meneruskan perangkat lunak ke penggunaan jenis produksi, Keparahan tinggi mungkin memerlukan perbaikan untuk diproduksi. Di dunia nyata semua perangkat lunak memiliki cacat, beberapa masalah pengkodean dan yang lainnya dari persyaratan yang hilang - yang mungkin tidak diuji karena Anda tidak dapat menguji persyaratan yang tidak diketahui.

adam f
sumber
1

Ada banyak definisi verifikasi dan validasi. Banyak orang bahkan menggunakan tag V&V untuk mengelompokkan keduanya dalam satu aktivitas. Tujuannya adalah untuk memastikan bahwa perangkat lunak membuat hal yang benar dan membuat hal yang benar. Apakah itu untuk memeriksa kepatuhan terhadap persyaratan atau mencoba menemukan bug tidak penting pada tingkat ini.

Pengujian adalah satu dari banyak teknik untuk verifikasi dan validasi, bukan sebaliknya. Tinjauan kode adalah satu lagi, dan verifikasi formal, dengan bukti matematis satu lagi.

Meskipun demikian, pengujian harus dilakukan dengan tujuan untuk menemukan bug, bukan dengan tujuan untuk memeriksa kepatuhan terhadap persyaratan.

Perbedaan utama ada di pikiran penguji. Jauh lebih mudah untuk membuat case uji yang menunjukkan bahwa perangkat lunak berfungsi sebagaimana mestinya (memeriksa kepatuhan), daripada membuat case test yang menunjukkan bahwa perangkat lunak gagal (menemukan bug).

Seorang penguji yang hebat bersemangat untuk memecahkan perangkat lunak, bukan tentang melakukannya dengan cara yang aman.

mouviciel
sumber
terima kasih, tapi bukankah kami juga menguji untuk menunjukkan bahwa persyaratan terpenuhi? Kami memastikan perangkat lunak berfungsi (memenuhi spesifikasi) dan kemudian kami mencoba menemukan cacat. Jadi ini bukan hanya tentang menemukan bug. Saya ingat sebuah buku yang mengatakan bahwa tujuan utama pengujian adalah untuk mengukur kualitas, bukan mencari bug. Adapun poin pertama Anda, review kode, bukti matematika dll sedang menguji juga dan itu disebut statis.
John V
Cacat atau bug ada berbeda dengan persyaratan. Sifat pekerjaan itu identik. Hanya ada perbedaan dalam cara berpikir tester untuk meningkatkan efisiensinya. Adapun poin pertama saya, ada banyak definisi dari semua istilah yang digunakan dalam validasi perangkat lunak (dan langkah pertama ketika bergabung dengan sebuah tim adalah untuk mendapatkan dialek lokal di tim itu), tetapi mayoritas orang setuju bahwa pengujian hanya dinamis teknik. pengujian statis adalah oxymoron, atau merujuk pada teknik yang berbeda, tidak jauh dari ulasan, di mana kode dieksekusi dalam pikiran "tester" dan bukan oleh komputer.
mouviciel
mouviciel: oxymoron? Saya rasa tidak, pengujian statis berarti memeriksa kemungkinan cacat tanpa eksekusi, yang sepenuhnya mungkin (masalah persyaratan, cacat desain ..). Ini tidak sama untuk memverifikasi persyaratan dan memeriksa bug: Anda harus menguji bahwa suatu bidang dapat memiliki nilai int32. Thats menguji bahwa itu berhasil. Kemudian Anda dapat mencoba memasukkan nilai yang lebih tinggi, yaitu menguji bug ..
John V
1

Mari kita lihat ini dari sudut pandang praktis. Untuk pengujian, Anda perlu menentukan kasus uji. Biasanya, Anda mendefinisikan kasus uji di sepanjang persyaratan yang ditentukan, dan mereka harus mencakup kasus "hari bahagia" serta "kasus tepi" - terutama yang terakhir sering didefinisikan dengan maksud merusak perangkat lunak. Ketika beberapa tes Anda gagal, mereka menunjukkan bug / cacat. Ketika Anda memiliki jumlah kasus uji yang masuk akal untuk setiap persyaratan, dan semua tes lulus, Anda mungkin tidak sepenuhnya membuktikan bahwa semua persyaratan dipenuhi, tetapi Anda telah meningkatkan kemungkinan untuk itu, dengan demikian melakukan beberapa verifikasi.

Jadi untuk bagian pertanyaan itu, menemukan bug dan verifikasi mungkin hanya dua sisi dari proses yang sama:

  • tes gagal: cacat ditemukan

  • tes lulus: verifikasi dilakukan (setidaknya, pada tingkat tertentu, jika Anda memberikan tes yang cukup dan tepat)

Mengenai validasi: seperti yang ditunjukkan @Mert, validasi dapat dilakukan dengan pengujian penerimaan, tetapi tidak dengan bentuk pengujian lainnya. Dengan demikian pengujian secara umum tidak menyebabkan validasi, hanya ketika dilakukan sebagai pengujian penerimaan, oleh beberapa pengguna potensial.

Doc Brown
sumber
0

Itu semua tergantung pada definisi "verifikasi" Anda. Sebagai contoh, verifikasi formal biasanya bukan sesuatu yang dilakukan oleh tim QA, tetapi merupakan tanggung jawab pengembang. Hampir tidak ada yang melakukan verifikasi formal karena tingginya biaya yang terkait dengannya (kesenjangan pengetahuan dan sumber daya yang diperlukan).

Joeri Sebrechts
sumber
0

Pengujian perangkat lunak tidak sama dengan QA. Anda punya hak itu. Pengujian perangkat lunak secara keseluruhan mencakup banyak tahapan (asap, unit, regresi, integrasi, penerimaan pengguna, dll.) Dengan sendirinya.

Dengan demikian, untuk memastikan bahwa perangkat lunak bekerja sesuai dengan persyaratan adalah tujuan utama QA (spesialis jaminan kualitas - dahulu hanya disebut penguji tahun lalu). Namun, ini bukan hanya pengujian . QA memastikan bahwa serangkaian proses yang tepat untuk melakukan pemeriksaan kualitas produk yang bersangkutan sudah ada, atau setidaknya dimasukkan ke dalam fase desain proyek.

Dengan demikian, idealnya Anda akan mengharapkan QA Anda memverifikasi aplikasi terhadap serangkaian persyaratan dan tidak hanya mencoba mengujinya dengan merusak perangkat lunak dan menemukan cacat.

Yusubov
sumber
QA BUKAN hanya pengujian. QA berkaitan dengan kualitas proses pengembangan ..
John V
QA memverifikasi aplikasi terhadap serangkaian persyaratan.
Yusubov