Perbedaan antara tes penerimaan dan tes fungsional?


Jawaban:


172

Di dunia saya, kami menggunakan istilah sebagai berikut:

pengujian fungsional : Ini adalah kegiatan verifikasi ; Apakah kami membuat produk yang berfungsi dengan baik? Apakah perangkat lunak memenuhi persyaratan bisnis?

Untuk jenis pengujian ini, kami memiliki kasus pengujian yang mencakup semua skenario yang dapat kami pikirkan, bahkan jika skenario itu tidak mungkin ada "di dunia nyata". Saat melakukan pengujian jenis ini, kami bertujuan untuk cakupan kode maksimum. Kami menggunakan lingkungan pengujian apa pun yang dapat kami ambil saat itu, tidak harus kaliber "produksi", asalkan dapat digunakan.

pengujian penerimaan : Ini adalah kegiatan validasi ; apakah kita membangun hal yang benar? Apakah ini yang benar-benar dibutuhkan pelanggan?

Ini biasanya dilakukan bekerja sama dengan pelanggan, atau dengan proxy pelanggan internal (pemilik produk). Untuk jenis pengujian ini, kami menggunakan kasus pengujian yang mencakup skenario umum yang kami harapkan digunakan perangkat lunak. Tes ini harus dilakukan dalam lingkungan "seperti produksi", pada perangkat keras yang sama dengan, atau dekat dengan, apa yang akan digunakan pelanggan. Inilah saat kami menguji "kemampuan" kami:

  • Keandalan, Ketersediaan : Divalidasi melalui stress test.

  • Skalabilitas : Divalidasi melalui uji beban.

  • Kegunaan : Divalidasi melalui inspeksi dan demonstrasi kepada pelanggan. Apakah UI dikonfigurasi sesuai dengan keinginan mereka? Apakah kami menempatkan branding pelanggan di semua tempat yang tepat? Apakah kita memiliki semua bidang / layar yang mereka minta?

  • Keamanan (alias, Keamanan, hanya untuk menyesuaikan) : Divalidasi melalui demonstrasi. Terkadang seorang pelanggan akan menyewa perusahaan luar untuk melakukan audit keamanan dan / atau pengujian intrusi.

  • Maintainability : Divalidasi melalui demonstrasi bagaimana kami akan mengirimkan pembaruan / patch perangkat lunak.

  • Konfigurasi : Divalidasi melalui demonstrasi bagaimana pelanggan dapat memodifikasi sistem agar sesuai dengan kebutuhan mereka.

Ini tidak berarti standar, dan saya tidak berpikir ada definisi "standar", seperti yang ditunjukkan oleh jawaban yang bertentangan di sini. Hal terpenting bagi organisasi Anda adalah Anda mendefinisikan istilah-istilah ini secara tepat, dan berpegang teguh pada mereka.


plus 1 untuk jawaban yang bagus dan "alias, Keamanan, hanya untuk menyesuaikan" :). Lucunya :) Tim SO tidak mempertimbangkan fakta bahwa di dunia nyata seseorang dapat mengganti tanda + dengan kata asli seperti yang saya lakukan. Jadi mereka tidak mengizinkan untuk mengetik +1 sebagai kata pertama dalam komentar tetapi mereka mengizinkan "plus 1" :). Jadi secara fungsional, mereka gagal menguji ini dengan benar :). Myabe mereka baru saja mencoba tes penerimaan :)
Geo C.

71

Saya suka jawaban Patrick Cuff. Yang ingin saya tambahkan adalah perbedaan antara tingkat tes dan jenis tes yang bagi saya pembuka mata.

tingkat tes

Level tes mudah dijelaskan dengan menggunakan model-V , contoh: masukkan deskripsi gambar di sini Setiap level tes memiliki level pengembangan yang sesuai . Ini memiliki karakteristik waktu yang khas, mereka dieksekusi pada fase tertentu dalam siklus hidup pengembangan.

  1. pengujian komponen / unit => memverifikasi desain terperinci
  2. pengujian integrasi komponen / unit => memverifikasi desain global
  3. pengujian sistem => memverifikasi persyaratan sistem
  4. pengujian integrasi sistem => memverifikasi persyaratan sistem
  5. pengujian penerimaan => memvalidasi persyaratan pengguna

jenis tes

Sebuah jenis tes adalah karakteristik, berfokus pada tujuan tes khusus. Jenis uji menekankan aspek kualitas Anda, juga dikenal sebagai aspek teknis atau non-fungsional. Jenis tes dapat dieksekusi di tingkat tes apa pun . Saya suka menggunakan sebagai tipe uji karakteristik kualitas yang disebutkan dalam ISO / IEC 25010: 2011.

  1. pengujian fungsional
  2. pengujian reliabilitas
  3. pengujian kinerja
  4. pengujian operabilitas
  5. pengujian keamanan
  6. pengujian kompatibilitas
  7. pengujian rawatan
  8. pengujian transferabilitas

Untuk membuatnya lengkap. Ada juga sesuatu yang disebut pengujian regresi . Ini klasifikasi tambahan di sebelah level tes dan tipe tes . Sebuah uji regresi adalah tes yang ingin Anda ulangi karena menyentuh sesuatu yang penting dalam produk Anda. Ini sebenarnya adalah bagian dari tes yang Anda tetapkan untuk setiap level tes . Jika ada perbaikan bug kecil di produk Anda, orang tidak selalu punya waktu untuk mengulang semua tes. Pengujian regresi adalah jawaban untuk itu.


2
Ini adalah jawaban terbaik untuk pertanyaan ini dan "perbedaan antara tingkat tes dan jenis tes" adalah sesuatu yang sebagian besar jawaban terlewatkan di sini dan Anda benar itu adalah "pembuka mata"
zmilan

23

Perbedaannya adalah antara menguji masalah dan solusinya. Perangkat lunak adalah solusi untuk suatu masalah, keduanya dapat diuji.

Tes fungsional mengonfirmasi perangkat lunak melakukan fungsi dalam batas-batas cara Anda menyelesaikan masalah. Ini merupakan bagian integral dari pengembangan perangkat lunak, sebanding dengan pengujian yang dilakukan pada produk yang diproduksi secara massal sebelum meninggalkan pabrik. Tes fungsional memverifikasi bahwa produk benar-benar berfungsi seperti yang Anda (pengembang) pikirkan.

Tes penerimaan memverifikasi bahwa produk benar-benar memecahkan masalah yang dibuat untuk dipecahkan. Ini bisa dilakukan oleh pengguna (pelanggan), misalnya melakukan tugasnya yang dibantu oleh perangkat lunak. Jika perangkat lunak lulus tes dunia nyata ini, itu diterima untuk menggantikan solusi sebelumnya. Tes penerimaan ini kadang-kadang hanya dapat dilakukan dengan benar dalam produksi, terutama jika Anda memiliki pelanggan anonim (misalnya situs web). Dengan demikian fitur baru hanya akan diterima setelah beberapa hari atau minggu penggunaan.

Pengujian fungsional - menguji produk, memverifikasi bahwa ia memiliki kualitas yang Anda rancang atau bangun (fungsi, kecepatan, kesalahan, konsistensi, dll.)

Pengujian penerimaan - menguji produk dalam konteksnya, ini memerlukan (simulasi) interaksi manusia, mengujinya memiliki efek yang diinginkan pada masalah asli.


9

Jawabannya adalah opini. Saya bekerja di banyak proyek dan menjadi testmanager dan penerbit dan semua peran yang berbeda dan deskripsi dalam berbagai buku berbeda jadi inilah variasi saya:

pengujian fungsional: mengambil persyaratan bisnis dan menguji semuanya dengan baik dan sepenuhnya dari sudut pandang fungsional.

pengujian penerimaan: pelanggan "yang membayar" melakukan pengujian yang ia sukai sehingga ia dapat menerima produk yang dikirim. Itu tergantung pada pelanggan tetapi biasanya tes tidak selengkap pengujian fungsional terutama jika itu adalah proyek in-house karena pemangku kepentingan meninjau dan mempercayai hasil pengujian yang dilakukan pada fase pengujian sebelumnya.

Seperti yang saya katakan ini adalah sudut pandang dan pengalaman saya. Pengujian fungsional adalah sistematik dan pengujian penerimaan agaknya adalah departemen bisnis yang menguji hal itu.


Saya suka jawaban ini :) Mereka hampir sama.
anbanm

1
UAT pada akhirnya dilakukan oleh pelanggan "yang membayar". Namun, sebagian besar waktu pertama kali dilakukan oleh orang QA yang "baik" dengan pengujian dan "mencoba" untuk merusak sistem dan mencari semua hal "kecil" SEBELUM pelanggan "membayar" mengambil tangan mereka di atasnya. Otomatisasi selenium untuk mengulangi hal-hal yang membosankan juga dapat digunakan bersama dengan pengujian UAT yang sebenarnya oleh tester QA, tetapi tidak pernah mengulangi pengujian yang benar untuk menguji semua fungsionalitas yang diharapkan dengan semua browser yang diharapkan. UAT cukup jelas. Saya pikir sebagian besar deskripsi pengujian fungsional tampaknya robot dan kamus.
Tom Stickel

Seperti yang saya katakan ini adalah pengalaman saya bagaimana istilah tersebut diartikan.
hol

Ini baik saja. Ketika saya perhatikan definisi yang tidak jelas ini ... Saya hanya perlu berkomentar "pengujian fungsional: ambil persyaratan bisnis dan uji semuanya dengan baik dan sepenuhnya dari sudut pandang fungsional."
Tom Stickel

Haha, ya, sekarang saya mengerti Anda. Oke, ini adalah sesuatu yang bisa Anda tulis di seluruh buku tentangnya. Saya tidak ingin membahas ini terlalu banyak saat saya menulisnya.
hol

8
  1. Hadirin. Pengujian fungsional adalah untuk memastikan anggota tim yang memproduksi perangkat lunak melakukan apa yang mereka harapkan. Pengujian penerimaan adalah untuk meyakinkan konsumen bahwa memenuhi kebutuhan mereka.

  2. Cakupan. Pengujian fungsional hanya menguji fungsionalitas satu komponen pada satu waktu. Pengujian penerimaan mencakup segala aspek produk yang penting bagi konsumen untuk diuji sebelum menerima perangkat lunak (yaitu, apa pun yang sepadan dengan waktu atau uang yang diperlukan untuk mengujinya untuk menentukan penerimaannya).

Perangkat lunak dapat lulus pengujian fungsional, pengujian integrasi, dan pengujian sistem; hanya gagal dalam tes penerimaan ketika pelanggan menemukan bahwa fitur tidak memenuhi kebutuhan mereka. Ini biasanya menyiratkan bahwa seseorang mengacaukan spesifikasi. Perangkat lunak juga dapat gagal beberapa tes fungsional, tetapi lulus pengujian penerimaan karena pelanggan bersedia untuk berurusan dengan beberapa bug fungsional selama perangkat lunak melakukan hal-hal inti yang mereka butuhkan dengan baik (perangkat lunak beta akan sering diterima oleh sekelompok pengguna sebelumnya sepenuhnya fungsional).


2

Pengujian fungsional: Penerapan data uji yang berasal dari persyaratan fungsional yang ditentukan tanpa memperhatikan struktur program akhir. Juga dikenal sebagai pengujian kotak hitam.

Pengujian Penerimaan: Pengujian formal dilakukan untuk menentukan apakah suatu sistem memenuhi kriteria penerimaannya atau tidak — memungkinkan pengguna akhir menentukan apakah menerima sistem atau tidak.


1

Dalam pandangan saya perbedaan utama adalah siapa yang mengatakan apakah tes berhasil atau gagal.

Tes fungsional menguji bahwa sistem memenuhi persyaratan yang telah ditentukan. Itu dilakukan dan diperiksa oleh orang yang bertanggung jawab untuk mengembangkan sistem.

Tes penerimaan ditandatangani oleh pengguna. Idealnya para pengguna akan mengatakan apa yang ingin mereka uji tetapi dalam praktiknya kemungkinan akan menjadi matahari terbenam dari tes fungsional karena pengguna tidak menginvestasikan waktu yang cukup. Perhatikan bahwa pandangan ini berasal dari pengguna bisnis yang saya tangani dengan kelompok pengguna lain misalnya penerbangan dan masalah keselamatan lainnya mungkin tidak memiliki perbedaan ini,


Pengujian penerimaan akan menentukan apakah suatu sistem memenuhi kriteria penerimaan kasus penggunaan yang diberikan atau semua kasus penggunaan yang dapat dibayangkan. Biasanya dilakukan oleh pengguna ahli untuk menentukan apakah sistem dapat diterima atau tidak. Dalam aeronautika pilot uji adalah penerbang yang menguji pesawat baru dengan melemparkan manuver tertentu. Pilot, navigator dan insinyur terbaik melakukan uji terbang dan pada akhir misi uji mereka akan memberikan data evaluasi dan sertifikasi.
jjpcondor

1

Pengujian penerimaan :

... adalah pengujian black-box yang dilakukan pada suatu sistem (mis. perangkat lunak, banyak komponen mekanis yang diproduksi, atau kumpulan produk kimia) sebelum dikirim.

Meskipun demikian selanjutnya dikatakan:

Ia juga dikenal sebagai pengujian fungsional, pengujian kotak hitam, penerimaan rilis, pengujian QA, pengujian aplikasi, pengujian kepercayaan, pengujian akhir, pengujian validasi, atau pengujian penerimaan pabrik

dengan tanda "rujukan?"

Pengujian fungsional (yang sebenarnya diarahkan ke Pengujian Sistem):

dilakukan pada sistem yang lengkap dan terintegrasi untuk mengevaluasi kepatuhan sistem dengan persyaratan yang ditentukan. Pengujian sistem berada dalam ruang lingkup pengujian kotak hitam, dan karenanya, seharusnya tidak memerlukan pengetahuan tentang desain bagian dalam kode atau logika.

Jadi dari definisi ini mereka hampir sama.

Dalam pengalaman saya, tes penerimaan biasanya merupakan bagian dari tes fungsional dan digunakan dalam proses keluar resmi oleh pelanggan sedangkan tes fungsional / sistem akan dilakukan oleh departemen pengembang / QA.


0

Hubungan antara keduanya: Tes penerimaan biasanya mencakup pengujian fungsional, tetapi mungkin mencakup tes tambahan. Misalnya memeriksa persyaratan pelabelan / dokumentasi.

Pengujian fungsional adalah ketika produk yang diuji ditempatkan ke dalam lingkungan pengujian yang dapat menghasilkan beragam stimulasi (dalam lingkup pengujian) apa yang biasanya dihasilkan atau bahkan dilampaui oleh lingkungan target, sambil memeriksa respons perangkat yang sedang diuji.

Untuk produk fisik (bukan perangkat lunak) ada dua jenis utama tes Penerimaan : tes desain dan tes manufaktur. Tes desain biasanya menggunakan sejumlah besar sampel produk, yang telah lulus uji manufaktur. Konsumen yang berbeda dapat menguji desain dengan cara yang berbeda.

Tes penerimaan disebut sebagai verifikasi ketika desain diuji terhadap spesifikasi produk, dan tes penerimaan disebut sebagai validasi, ketika produk ditempatkan di lingkungan nyata konsumen.


0

Pengujian penerimaan hanyalah pengujian yang dilakukan oleh klien, dan mencakup jenis pengujian lain:

  • Pengujian fungsional: "tombol ini tidak berfungsi"
  • Pengujian non-fungsional: "halaman ini berfungsi tetapi terlalu lambat"

Untuk pengujian fungsional vs pengujian non-fungsional (subtipe mereka) - lihat jawaban saya untuk pertanyaan SO ini .


-1

Mereka adalah hal yang sama.

Pengujian penerimaan dilakukan pada sistem yang telah selesai seidentik mungkin dengan lingkungan produksi / penempatan yang sebenarnya sebelum sistem tersebut digunakan atau dikirim.

Anda dapat melakukan pengujian penerimaan dengan cara otomatis, atau secara manual.


1
Sementara otomatisasi dengan Selenium dan Watin (atau Watir) dll ... adalah garis pertahanan pertama yang sangat berharga, tidak ada yang mengalahkan orang QA terlatih yang ditetapkan untuk "melanggar sistem. Otomasi itu hebat, tetapi dengan pengembangan modern AJAX dan kerangka kerja javascript dan perubahan output pada halaman, untuk mengotomatisasi semuanya adalah mimpi buruk memperbarui skrip. Mereka BUKAN hal yang sama
Tom Stickel
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.