Kami menghabiskan lebih banyak waktu untuk mengimplementasikan tes fungsional daripada mengimplementasikan sistem itu sendiri, apakah ini normal?

12

Pada dasarnya, kami memiliki tiga proyek utama, dua di antaranya adalah layanan web, dan yang lainnya adalah aplikasi web. Sementara saya puas dengan mencakup sebanyak mungkin layanan web kami dengan tes fungsional (ketiga proyek memiliki tes unit yang tepat), tes fungsional untuk aplikasi web membutuhkan banyak waktu pengembang untuk diimplementasikan. Maksud saya dua kali, atau kadang-kadang lebih, waktu yang diperlukan untuk mengimplementasikan fungsionalitas yang sedang diuji dengan unit test.

Kebijakan manajer adalah untuk menguji setiap fungsionalitas tunggal yang kami tambahkan, meskipun tidak penting untuk bisnis (yaitu CRUD baru).

Saya setuju dengan pengujian semua fungsionalitas layanan web, karena sulit untuk mengujinya secara manual, dan juga, tes ini berjalan cepat dan tidak perlu terlalu banyak untuk diterapkan.

Jadi, apa nilai menghabiskan lebih banyak waktu untuk menulis tes fungsional, daripada menulis kode sistem, unit test dan memperbaiki QA tikets? Apakah ini normal? Bukankah kita seharusnya menulis tes fungsional hanya untuk fungsionalitas kritis dan membiarkan QA melakukan tes regresi tanpa fungsionalitas kritis?

Catatan: kami tidak mengembangkan perangkat lunak medis atau perangkat lunak NASA atau tidak ada yang kritis.

project-management testing functional-testing Pablo Lascano
sumber
14
Kami tidak memiliki tes. Kami menghabiskan banyak waktu untuk memperbaiki keadaan setelah fakta. "Kamu bisa membayar saya sekarang, atau kamu bisa membayar saya nanti." Nanti dan tidak cantik.
MetalMikester
3
Ya - bagian dari gambar jelas bahwa test suite yang terawat baik mengurangi waktu yang dibutuhkan untuk implementasi yang sebenarnya.
Michael Borgwardt
kemungkinan rangkap dari Haruskah seorang pengembang juga bertindak sebagai penguji?
nyamuk
Kemungkinan rangkap dari Apakah biasa menghabiskan waktu sebanyak, jika tidak lebih, tes menulis waktu daripada kode yang sebenarnya?
Agak

Jawaban:

16

Tes fungsional sangat penting. Ya, mereka membutuhkan waktu untuk menulis tetapi jika Anda menulis tes fungsional yang tepat, mereka akan lebih berharga.

Ada beberapa alasan bagus untuk melakukan tes fungsional otomatis pada aplikasi.

  • Ketika fitur baru ditambahkan ke situs web Anda, Anda akan langsung tahu jika perubahan yang dilakukan untuk fitur baru itu merusak fungsionalitas lain di situs Anda.
  • Ini mendokumentasikan pengetahuan tentang bagaimana aplikasi berjalan dan bekerja bersama untuk mencapai persyaratan bisnis.
  • Ketika tiba waktunya untuk memperbarui perpustakaan pihak ke-3, Anda dapat memperbaruinya dan menjalankan suite uji fungsional Anda untuk melihat apakah ada yang rusak. Alih-alih harus melalui setiap halaman sendiri, Anda dapat memiliki komputer melakukannya untuk Anda dan memberi Anda daftar semua tes yang rusak.
  • Uji beban! Anda dapat mensimulasikan ribuan pengguna secara bersamaan semua mengenai situs Anda sekaligus dan Anda dapat melihat di mana situs Anda melambat dan tertekuk di bawah tekanan. Anda dapat melihat bagaimana situs web Anda berperilaku lama sebelum Anda menerima panggilan tengah malam bahwa situs tersebut telah mogok.
  • Pengujian fungsional membutuhkan waktu untuk dilakukan secara manual. Ya, butuh waktu lama untuk menulis kasing, tetapi jika Anda harus duduk dengan map dengan 500 halaman tes yang harus Anda selesaikan sebelum Anda bisa mengirimkan produk Anda ingin memiliki tes otomatis!
  • Dokumen pengujian keluar dari tanggal dengan cepat. Ketika fitur baru ditambahkan, Anda harus memastikan untuk memperbarui dokumen pengujian master. Jika seseorang melewatkan beberapa tes, Anda tiba-tiba mendapatkan bug yang merayap ke halaman yang "selesai dan diuji". Saat ini saya bekerja di lingkungan seperti itu, dan saya dapat meyakinkan Anda, itu adalah mimpi buruk.

Pada akhirnya, ya butuh waktu untuk menulis kasus ini, tetapi Anda harus bangga menulisnya. Ini cara Anda membuktikan, di luar bayangan keraguan bahwa kode Anda berfungsi dan berfungsi dengan semua fitur lain di luar sana. Ketika QA mendatangi Anda dan mengatakan ada bug, Anda memperbaikinya, lalu menambahkannya ke ruang uji untuk menunjukkan bahwa itu diperbaiki dan memastikan tidak pernah terjadi lagi.

Ini adalah jaring pengaman Anda. Ketika seseorang masuk dan membajak proc yang disimpan dan membuat perubahan kecil sehingga itu akan bekerja dengan kode mereka, Anda akan mengetahui bahwa itu telah merusak 3 fitur lainnya dalam proses. Anda akan menangkapnya malam itu dan bukan malam sebelum batas waktu!

Sedangkan untuk menulis tes fungsional hanya untuk fungsi kritis sistem. Itu tidak akan memberi Anda seluruh gambar dan itu akan memungkinkan bug untuk menyelinap. Yang diperlukan hanyalah menambahkan satu fitur kecil yang tidak kritis terhadap sistem, tetapi berinteraksi secara tidak langsung dengan fungsi kritis sistem dan Anda memiliki potensi untuk memperkenalkan bug.

Tyanna
sumber
Terima kasih atas jawaban anda. Saya sadar tentang pentingnya dan manfaat dari tes fungsional, kekhawatiran saya adalah tentang biaya-manfaat dari pengujian SEMUA. Kami mengembangkan tes fungsional selama tiga tahun terakhir, tetapi sekarang dalam proyek ini, saya merasa bahwa biaya pelaksanaan uji ALL jauh lebih banyak daripada menemukan bug dalam produksi, menaikkan tiket, dan memperbaikinya ... Saya ingin tahu apakah ada beberapa keadaan di mana TIDAK membuat tes fungsional lebih baik (dalam hal manfaat-biaya) daripada tidak membuatnya, dan saya bertanya-tanya apakah kita berada dalam keadaan seperti itu, di mana lebih baik untuk memilih dengan bijak apa yang akan diuji.
Pablo Lascano
@diorenior ~ jika Anda merasa terlalu lama untuk menguji, maka lihat alat yang Anda gunakan. Apakah Anda menggunakannya dengan benar? Apakah Anda bahkan menggunakan alat hemat waktu? Tes menulis memang lebih lama daripada menulis kode b / c Anda memiliki lebih banyak kode untuk ditulis. Itulah sifat pengujian. Jika Anda mulai memilih dan memilih untuk apa tes ditulis, maka akan sampai pada titik bahwa tidak ada yang akan menulis tes, atau tes itu akan ceroboh.
Tyanna
ide saya untuk memilih apa yang akan diuji, bukan pilihan acak, tetapi memilih fungsi bisnis yang paling penting (dan ini bukan keputusan pengembang, tetapi manajer). Dan saya pikir justru sebaliknya, pengembang cenderung menulis tes ceroboh sekarang karena mereka harus menguji semua, bahkan fungsionalitas yang membutuhkan lima menit untuk menguji QA dan dua hari bagi pengembang untuk mengotomatisasi. Saya setuju bahwa mungkin alat yang kami gunakan bukan yang terbaik untuk menguji aplikasi web kami (fitnesse dan java). Saya khawatir kita mendekati titik penulisan dan mempertahankan tes fungsional lebih dari sistem
Pablo Lascano
@diorenior ~ Tentu, dibutuhkan QA 5 menit untuk menguji suatu kasus, tetapi dibutuhkan komputer kurang dari satu detik untuk mengujinya. Anda harus bertanya, "Mengapa perlu 2 hari untuk menulis sesuatu yang membutuhkan 5 menit untuk diuji dengan tangan"? Sekali lagi, lihat alat Anda. Mungkin QA harus menulis beberapa test case juga? Masalahnya bukan menulis kasus uji untuk sistem Anda, melainkan bagaimana kasus uji tersebut ditulis.
Tyanna
baik tes ini membutuhkan lebih dari satu detik untuk berjalan (ingat ini adalah tes fungsional, bukan tes unit). Tapi itu bukan masalah, mereka lari di malam hari. Saya pikir Anda benar bahwa QA harus menulis beberapa kasus tes juga, tapi sayangnya itu bukan keputusan yang bisa saya buat. Terima kasih banyak atas jawaban Anda, saya telah menandai yang ini diterima!
Pablo Lascano
7

Lebih dari 2 kali ... sepertinya agak banyak bagi saya. Anda mungkin ingin menganalisis alasan untuk ini, mereka dapat mencakup:

  • dukungan alat buruk untuk pembuatan dan pemeliharaan tes

  • kontrak layanan web tidak dijelaskan secara memadai dalam desain. Pengembang perlu mengerjakan kontrak saat pengujian, yang biasanya merupakan proses penyelarasan yang memakan waktu.

Bicaralah dengan pengembang Anda.

Asumsikan Anda berkembang dalam sprint, lakukan tes fungsional ini jika hanya bagian dari sprint. Itu tidak dilakukan tanpa tes ini. Jika Anda tidak memilikinya, waktu Anda untuk pengujian integrasi setelah fase pengembangan mungkin berlipat ganda.

Andreas Huppert
sumber
Saya setuju, mungkin kita tidak menggunakan alat yang tepat untuk menguji aplikasi web. Tidak ada masalah dalam pengujian layanan web kami. Lagi pula, selain benar atau salah bagaimana kami melaksanakan tes, saya khawatir tentang biaya. Saya pikir pada titik ini, lebih baik (dalam hal biaya / manfaat) untuk membiarkan beberapa tes untuk departemen QA dan memperbaiki bug bahkan jika mereka ditemukan dalam produksi.
Pablo Lascano
Anda meninggalkan kelas yang dirancang dengan buruk sebagai alasan yang memungkinkan untuk mengambil terlalu lama untuk diuji. Sejauh ini inilah alasan paling umum yang saya lihat ketika orang-orang mengambil selamanya menguji kode mereka.
Dunk
4

Apakah menghabiskan lebih banyak waktu untuk melaksanakan tes fungsional daripada mengimplementasikan sistem itu sendiri normal?

Benar. Menulis tes yang sangat bagus kemungkinan akan menghabiskan sebagian besar waktu di banyak toko (bagus).
Jadi rasio 2-1 baik-baik saja. Pengembang yang kurang berpengalaman sendiri sering tidak meluangkan waktu untuk pengujian.

Michael Durrant
sumber
2

Ada hukum pengembalian yang semakin berkurang. Dengan asumsi Anda menulis tes untuk kode paling berisiko pertama, nilai yang dihasilkan oleh tes lebih lanjut berkurang dari waktu ke waktu.

Tes unit adalah kode, sehingga akan mengandung bug (seperti semua kode lainnya). Memperbaiki bug-bug itu membutuhkan waktu.

Dalam pengalaman saya, unit-test mengandung lebih banyak bug daripada sistem yang mereka uji, dan memperbaikinya adalah beban yang terus menerus.


sumber
1

Ini tentang kualitas.

Jika Anda perlu mendapatkan pasar - Anda akan mengembangkan aplikasi Anda secepat mungkin. Anda bahkan dapat tidak memiliki tes otomatis sama sekali =) tetapi Anda akan memberikan aplikasi Anda ke auditori Anda sebelum pesaing Anda.

Tetapi jika Anda tahu bahwa pendengaran Anda tidak akan hilang, Anda akan melakukan apa pun yang Anda tidak bisa mengecewakan mereka. Setiap tiket bug akan menurunkan reputasi Anda. Bayangkan bahwa satu bug akan menghapus 50 persen dari reputasi Anda, yang berikutnya - 25 persen dan seterusnya. Jadi, bisakah ada terlalu banyak tes?

Nikita U.
sumber
Yah, aku tidak begitu yakin apakah pada titik ini kita benar-benar mengurangi tiket. Mungkin kami telah mengurangi (tapi tidak banyak) tiket QA, tetapi tingkat bug yang ditemukan oleh tes ini tidak cukup besar (menurut sudut pandang saya) untuk membenarkan biaya seperti memiliki 2/3 dari perangkat lunak pembuat perangkat lunak waktu mengembangkan tes fungsional.
Pablo Lascano
0

Jika dengan "apakah ini normal" Anda bertanya apakah itu umum, tidak, tentu saja tidak. Banyak tim pengembang memiliki praktik pengujian yang buruk (saya milik salah satu) dan bahkan buku berkualitas yang saya baca saran untuk menghabiskan waktu sebanyak kira-kira pengkodean fungsi daripada tes. Jika secara normal Anda bertanya apakah itu sehat, itu tergantung, tetapi dua kali lebih banyak tes daripada yang dibutuhkan lebih baik daripada tidak ada tes.

Tidak harus kritis . Saat Anda menguji suatu fungsi, Anda menguji sesuatu yang berguna bagi pengguna akhir, dan Anda bertanggung jawab untuk mengetahui (dan tidak menebak), itu sepanjang waktu berfungsi dengan benar. Jika Anda membutuhkan dua kali lebih banyak untuk tujuan itu, maka itu harus dilakukan dengan cara itu - jika mungkin.

Mungkin juga kebijakan Anda terlalu ketat tentang tes otomatis, tetapi sulit untuk mengatakan tanpa mengetahui kualitas yang mereka tuju, sumber daya mereka, dan apa lagi yang dapat mereka alokasi.

Arthur Havlicek
sumber