Apakah membuat sistem duplikat penuh untuk jaminan kualitas (QA) dari yang lain merupakan praktik buruk?

10

Di tempat kerja kami memiliki sistem yang cukup rumit. Sebut saja sistem ini, System_A. Tim QA kami telah membuat sistem lain, panggil sistem ini, System_B, untuk menguji System_A.

Cara System_B digunakan adalah sebagai berikut. Kami menghasilkan input (menggunakan System_B sendiri), IN, memproses input tersebut kembali melalui System_B dan menghasilkan output, O_B. Jadi prosesnya adalah sebagai berikut:

System_B(IN) -> O_B.

Kami kemudian melakukan hal yang sama untuk System_A untuk menghasilkan output sendiri, O_A:

System_A(IN) -> O_A.

Kapan saja, diasumsikan bahwa O_B adalah output yang diharapkan, dan O_A adalah output yang diamati / aktual. Tersirat adalah bahwa O_B adalah sumber "emas" (kebenaran). Namun, kami telah mengalami kombinasi masalah.

  • O_A salah, O_B benar
  • O_A benar, O_B benar
  • O_A salah, O_B salah
  • O_A benar, O_B salah

Siapa yang menentukan apa yang benar jika O_B diasumsikan selalu benar (atau apa yang diharapkan)? Ya, ternyata O_B kadang-kadang (atau sering) salah dengan inspeksi dan analisis manusia. Banyak hal akan berlalu QA menggunakan proses ini, dan pengguna nyata akan mengeluh, dan kami kembali menemukan bahwa O_B salah.

Pertanyaannya adalah ini: apakah ini praktik yang buruk untuk membuat "sistem pengujian" untuk menguji sistem yang sebenarnya?

  • Bagaimana dengan lereng yang licin? Lalu, tidak bisakah kita berdebat bahwa kita membutuhkan sistem lain untuk menguji "sistem pengujian"?
  • Biayanya tentu saja mahal, karena pengembang sekarang perlu mempelajari setidaknya 2 basis kode, dengan kompleksitas System_B mungkin lebih besar daripada System_A. Bagaimana kita mengukur seberapa baik atau buruk memiliki System_B di sekitar untuk organisasi?
  • Salah satu alasan "menarik" asli untuk membuat System_B adalah untuk "mengotomatisasi" pengujian. Sekarang kami sangat bangga bahwa kami sepenuhnya otomatis (karena System_B menghasilkan input untuk mem-bootstrap proses menggunakan sendiri untuk juga menghasilkan output). Tetapi saya pikir kami telah melakukan lebih banyak kerusakan dan memperkenalkan lebih banyak kerumitan, dengan cara yang tidak dapat dikenali. Apakah pekerjaan QA sepenuhnya otomatis? Apakah alasan itu cukup untuk membenarkan membuat sistem paralel?
  • Kekhawatiran saya yang sebenarnya adalah ini, meskipun kita semua tahu bahwa System_B salah (cukup sering). Jika System_B sangat bagus dalam memproses input dan outputnya adalah sumber emas, mengapa tidak mengganti System_A dengan System_B? Untuk itu, tidak ada seorang pun di tempat kerja yang mampu memberikan respons yang memuaskan.

Setiap panduan tentang masalah ini dihargai.

unit-testing testing qa acceptance-testing integration-testing Jane Wayne
sumber
1
Anda lupa Sistem C: yang memutuskan mana yang benar, jika A dan B tidak setuju.
Robert Harvey
1
Pada catatan yang lebih serius, Space Shuttle memiliki lima komputer onboard: 3 menjalankan perangkat lunak penerbangan, satu yang memeriksa untuk memastikan mereka semua setuju, dan yang kelima menjalankan perangkat lunak yang ditulis menggunakan spesifikasi yang sama tetapi vendor yang berbeda, untuk berjaga-jaga jika tak terpikirkan terjadi. Apakah Anda memutuskan untuk pergi ke tingkat kekakuan ini sepenuhnya terserah Anda, tetapi ada preseden untuk itu.
Robert Harvey
3
Anda tahu satu hal, yaitu setiap kali System_A dan System_B tidak setuju satu sama lain, salah satunya memiliki bug. Itu akan membantu Anda menemukan beberapa bug di kedua sistem. Jika System_A adalah satu-satunya "penting" maka itu membantu Anda menemukan beberapa bug di System_A, hanya saja tidak semuanya. Ini semacam ide yang sama di balik verifikasi formal.
user253751
1
Sesuatu yang tidak jelas dari pertanyaan Anda: apakah sistem A dan B menjalankan basis kode yang sama atau basis kode yang berbeda? Jika yang terakhir, maka ketika mereka tidak setuju Anda harus menganggap keduanya salah, dan mengidentifikasi alasan bahwa mereka memberikan jawaban yang berbeda.
kdgregory
1
Dan untuk pertanyaan Anda yang sebenarnya ("apakah ini praktik yang buruk"): hanya jika tidak ada alasan untuk memeriksa ulang operasi Anda. Dan dalam penggunaan bisnis biasa, tidak ada. Jika Anda menjalankan Space Shuttle, seperti yang dicatat oleh Robert Harvey, ada. Dan ada beberapa aplikasi, seperti perdagangan saham atau ramalan cuaca, di mana Anda dapat memiliki dua sistem yang tidak setuju dan keduanya valid (jika tidak harus "benar").
kdgregory

Jawaban:

5
  • O_A salah, O_B benar

Perbaiki A

  • O_A benar, O_B salah

Perbaiki B

  • O_A benar, O_B benar

Semoga mereka juga setuju.

  • O_A salah, O_B salah

Mudah-mudahan, mereka tidak setuju sehingga Anda akan tahu untuk melakukan sesuatu tentang itu.

Tidak ada proses yang menangkap semuanya. Tentu, Anda telah menggandakan kode Anda tetapi menganggapnya seperti 2 di O (2n). QA otomatis sampai ke tes integrasi adalah hal yang luar biasa. Pengujian manual adalah hambatan pada inovasi. Terutama pada perubahan lintas sektoral yang menuntut pengujian penuh. Juga, karena Anda akan membuat programmer yang berbeda mengimplementasikan hal yang sama, Anda dapat membuat mereka berlomba.

Seharusnya orang yang berbeda untuk meningkatkan peluang mendapatkan bug yang berbeda. Saya tidak menyarankan membuat sistem B dengan mengatasi dari sistem A. Semua yang memberi Anda adalah tes regresi. Anda bisa mendapatkan hal yang sama hanya dengan menyimpan salinan O_A lama untuk dibandingkan dengan yang baru.

Pertanyaannya adalah ini: apakah ini praktik yang buruk untuk membuat "sistem pengujian" untuk menguji sistem yang sebenarnya?

Jika ya, maka semua pengujian buruk.

  • Bagaimana dengan lereng yang licin? Lalu, tidak bisakah kita berdebat bahwa kita membutuhkan sistem lain untuk menguji "sistem pengujian"?

Ya, kita bisa membantahnya. Kami akan memanggil sistem ke-3 ini, system_A. : P

  • Biayanya tentu saja mahal, karena pengembang sekarang perlu mempelajari setidaknya 2 basis kode, dengan kompleksitas System_B mungkin lebih besar daripada System_A. Bagaimana kita mengukur seberapa baik atau buruk memiliki System_B di sekitar untuk organisasi?

Dengan jumlah pelanggan yang bahagia yang membayar kami untuk bermain dengan senjata nerf. Anda telah membebaskan diri Anda dari biaya pengujian manual. Anda telah membuat sesuatu yang kegunaannya akan terbukti setiap kali bug ditangkap olehnya. Bug yang ditangkap lebih awal harganya jauh lebih murah daripada bug yang dilaporkan terlambat.

  • Salah satu alasan "menarik" asli untuk membuat System_B adalah untuk "mengotomatisasi" pengujian. Sekarang kami sangat bangga bahwa kami sepenuhnya otomatis (karena System_B menghasilkan input untuk mem-bootstrap proses menggunakan sendiri untuk juga menghasilkan output). Tetapi saya pikir kami telah melakukan lebih banyak kerusakan dan memperkenalkan lebih banyak kerumitan, dengan cara yang tidak dapat dikenali. Apakah pekerjaan QA sepenuhnya otomatis? Apakah alasan itu cukup untuk membenarkan membuat sistem paralel?

Kompleksitas System_B sangat terisolasi dari System_A. Tidak sulit untuk menambahkan fitur ke System_A karena System_B ada. Infact lebih mudah karena System_B memberi mereka kepercayaan diri untuk bergerak cepat.

  • Kekhawatiran saya yang sebenarnya adalah ini, meskipun kita semua tahu bahwa System_B salah (cukup sering). Jika System_B sangat bagus dalam memproses input dan outputnya adalah sumber emas, mengapa tidak mengganti System_A dengan System_B? Untuk itu, tidak ada seorang pun di tempat kerja yang mampu memberikan respons yang memuaskan.

Apakah ini salah cetak? System_B cukup sering salah sehingga itu adalah standar emas yang ingin Anda gunakan untuk mengganti System_A?

Saya akan menganggap Anda berarti System_A sering salah. Tidak masalah yang mana yang paling sering salah. Mana pun yang salah adalah yang perlu bekerja. Sistem ini tidak memutuskan benar atau salah, pengembang melakukannya. Apa yang dilakukan pengujian adalah menghasilkan disagrement yang berarti ada sesuatu yang tidak benar. Pengembang mencari tahu apa itu. Ingat, tidak ada standar emas yang diproduksi di sini. Hanya ada kesepakatan atau ketidaksepakatan. Ketidaksepakatan menuntut bahwa pekerjaan harus dilakukan. Bagian dari pekerjaan itu adalah mencari tahu di mana.

candied_orange
sumber
3

Ketika Anda memiliki sistem dalam produksi yang benar-benar digunakan oleh pelanggan, memiliki sistem QA untuk memverifikasi perbaikan bug dan fungsionalitas baru adalah keharusan mutlak. Dari sudut pandang kualitas, harus sedekat mungkin replika sistem produksi. Dengan begitu, jika Anda memastikan bahwa sistem produksi dan sistem QA-nya identik, yang berfungsi pada satu, harus bekerja pada yang lain. Jika bukan itu masalahnya, maka sistemnya tidak identik, inputnya tidak identik, dan / atau outputnya disalahtafsirkan.

Ini berjalan dua kali lipat jadi jika sistem Anda sangat penting dan harus tersedia 24/7. Maka Anda tidak dapat membuat kemewahan untuk tidak memiliki sistem QA, karena Anda harus benar-benar meminimalkan waktu henti pada sistem produksi. Dan jika itu adalah sistem 24/7, maka replika yang tepat dari sistem produksi adalah rekomendasi yang sangat, sangat kuat.

Sekarang, kelemahan nyata dari pendekatan ini adalah biaya. Ini menggandakan biaya perangkat keras, dan meningkatkan biaya pemasangan dan pemeliharaan. Plus, replikasi data yang berkesinambungan dari sistem produksi ke QA harus diimplementasikan, sehingga kami akan meminimalkan kemungkinan hasil yang berbeda karena perbedaan dalam data yang bekerja dengan sistem.

Beberapa keseimbangan biasanya dapat ditemukan dengan memperkecil beberapa komponen sistem QA relatif terhadap sistem produksi, sehingga sebagian besar fungsi dapat diuji dengan baik. Itu biasanya server yang berlebihan, ukuran server atau jumlah workstation. Namun, menurut pengalaman saya, beberapa bug selalu ditemukan tepat di bagian yang dirampingkan, dan kemudian menjadi mimpi buruk untuk mereproduksi masalah dan menerapkan perbaikan sambil mempertahankan waktu henti minimum yang diizinkan dalam sistem produksi.

Vladimir Stokic
sumber
2

Setiap kali Anda menguji suatu sistem Anda harus tahu apa hasil yang Anda harapkan.

Masalah dengan memiliki sistem menghasilkan hasil yang diharapkan ini jelas 'bagaimana saya menguji sistem itu'

Meski begitu tidak biasa melihat orang menggunakan spreadsheet misalnya untuk menghasilkan set hasil yang diharapkan.

Pada akhirnya, meskipun Anda benar-benar membutuhkan manusia untuk menafsirkan persyaratan sistem dan secara manual menghasilkan hasil yang diharapkan. Jika Anda memiliki sistem lakukan itu dan hanya memeriksa perbedaannya maka Anda melewatkan pengujian Anda.

Ewan
sumber