Apakah pengujian perangkat lunak benar-benar dilakukan pada proyek profesional?


25

Saya telah terlibat dengan banyak proyek di beberapa perusahaan karena saya telah lama menjadi pengembang dan saya seorang kontraktor.

Saya memperkirakan bahwa kurang dari 20% proyek diuji secara metodis. Dengan diuji secara metodis, saya maksudkan setiap pengujian di luar ad-hoc tidak ada pengujian rencana.

Saya juga memperkirakan bahwa kurang dari 10% proyek diuji secara metodis di mana mereka telah mendedikasikan penguji sebagai bagian dari tim, dokumen rencana pengujian, di mana pengembang menulis tes otomatis dan kemudian mereka juga melacak cakupan pengujian dan mengukur hasil.

Dua pertanyaan

  1. Berapa perkiraan persentase Anda tentang masalah ini?
  2. Apa pengalaman profesional Anda tentang pengujian perangkat lunak?

Catatan tambahan

Karena pertanyaan pengujian metodis mungkin mendapatkan jawaban yang cukup bias (orang-orang suka membual tentang menjadi lebih unggul dari yang lain), saya mendorong pengembang lain (yang tidak terkena pengujian metodis) untuk memberikan jawaban mereka juga, karena jika tidak maka akan terlihat seperti pengujian. dilakukan di mana-mana ... kecuali di perusahaan Anda.


Pertanyaan bagus, terima kasih telah meluangkan waktu untuk merumuskan kembali!

@ Mark Trapp: Terima kasih. Saya kira saya pikir itu cukup mendasar tetapi saya dapat mengajukan beberapa pertanyaan lagi (berdasarkan serangkaian pertanyaan sebelumnya)
Robert Koritnik

Jawaban:


8

Pola yang saya lihat dengan pengujian selama karier saya menunjukkan korespondensi yang kuat dengan risiko kegagalan dalam suatu proyek. Proyek-proyek besar lebih mungkin diuji daripada yang kecil, aplikasi misi kritis lebih mungkin untuk diuji daripada satu dari situs pemasaran web, sistem in-house lebih kecil kemungkinannya untuk diuji daripada yang dihadapi publik.

Yang mengatakan masih ada proyek yang telah diuji secara berlebihan dan yang belum cukup diuji, tetapi ini adalah minoritas.


Saya sedikit mengedit pertanyaan saya. Bisakah Anda memberikan perkiraan Anda juga?
Robert Koritnik

Hampir semua proyek (80% +) saya telah terlibat dengan telah diuji secara metodis, tapi kemudian saya hampir secara eksklusif melakukan aplikasi kritis misi perusahaan.
Martin Brown

Saya bekerja untuk perusahaan farmasi. Saya akan mengatakan bahwa 80% aplikasi diuji oleh penguji dan pengembang profesional. 20% itu adalah aplikasi berisiko rendah seperti presentasi promosi di iPad. tetapi bahkan yang satu ini ad-hoc diperiksa oleh seseorang.
yoosiba

5

Semua yang kami hasilkan diuji sepenuhnya. Jika tim QA internal kami kelebihan beban, kami memiliki tim lepas pantai yang menguji proyek. Mereka tidak sebagus tim internal kami tetapi itu topik yang berbeda.


Saya sedikit mengedit pertanyaan saya. Bisakah Anda memberikan perkiraan pasar pengembangan profesional Anda. Karena proyek Anda diteliti dengan cermat. Dan apakah tes Anda otomatis atau tidak?
Robert Koritnik

Siapa tim lepas pantai ini? Apakah Anda akan memberi mereka rekomendasi?
Martin Brown

Biasanya perusahaan besar memiliki Pusat Litbang di negara lain (Sebagian besar di Asia). Di mana pengembangan lepas pantai dilakukan. Tujuan pengembangan lepas pantai adalah untuk mengurangi biaya pengembangan (sebagian darinya).
Nipuna

2

Tiga perusahaan tempat saya bekerja selama 15 tahun terakhir semuanya memiliki unit test yang dijalankan secara otomatis.

Di dua perusahaan itu saya mendorong untuk memperkenalkan mereka.


Saya sedikit mengedit pertanyaan saya. Bisakah Anda memberikan perkiraan Anda tentang pengujian perangkat lunak di pasar profesional juga?
Robert Koritnik

@ Robert: Saya belum cukup banyak bekerja untuk memberikan perkiraan umum. Dari sedikit yang saya tahu, segalanya menjadi lebih baik. Tapi kemudian, sayalah yang mendorong untuk tes unit otomatis dalam dua dari tiga kasus yang saya katakan tentang ...
sbi

Tetapi Anda berbicara dengan pengembang lain di perusahaan lain, bukan?
Robert Koritnik

2

Dalam 9 tahun terakhir, saya pada dasarnya hanya memenuhi tes penerimaan / regresi. Hanya ada beberapa unit tes.


Saya sedikit mengedit pertanyaan saya. Bisakah Anda memberikan perkiraan pengujian perangkat lunak di pasar profesional juga?
Robert Koritnik

2

Iya nih.

Jumlah pengujian sebanding dengan keandalan yang dibutuhkan aplikasi, serta kematangan budaya programmer.

Situs web cukup sering berjalan di lubang bug (tautan rusak adalah cacat).

Video game sering bermasalah.

Windows (akhirnya) cukup dapat diandalkan.

Router sangat andal

Monitor rumah sakit "jangan rusak"

Perhatikan bahwa biaya kegagalan fiskal juga berkorelasi dengan keandalan.


2
Saya sangat tidak setuju dengan Anda - Anda belum pernah melihat router gagal? Apakah game Xbox, Playstation, dan Wii terkunci? Pernah memiliki layar biru atau 'Aplikasi tidak merespons' di Windows?
JBRWilkinson

@ JBRWilkinson Saya pikir Anda kehilangan pengubah tingkat keparahannya dan juga mungkin memasukkan sebagian besar game PC yang, seperti yang dikatakan Paul, sering bermasalah. Lagi pula, daftar itu mungkin bisa menggunakan beberapa perbaikan, tetapi sentimennya benar: keandalan sering kali berkorelasi dengan kerugian fiskal yang terkait dengan kegagalan.
Jay Carr

1

Dalam 10 tahun saya tidak pernah mengerjakan proyek dengan pengujian kode formal.

Dalam pekerjaan saya saat ini, kami hanya memiliki pengujian fungsional.

Masalahnya adalah bahwa tidak ada seorang pun di manajemen yang tahu tentang pengujian kode. Departemen pengujian bahkan tidak tahu tentang pengujian kode, mereka hanya mengikuti spesifikasi tingkat tinggi dan memverifikasi jika kita mematuhi dari sudut pandang perilaku / fungsional.

Kami tidak memiliki pemimpin perangkat lunak yang memenuhi syarat yang memaksa kami untuk membuat kode dengan baik. Hasilnya adalah kode spageti, banyak regresi, jadwal yang terlewat, dan sebagainya ...


Terima kasih atas jawaban jujur ​​Anda. Apa perkiraan Anda (lihat pertanyaan saya yang diedit)?
Robert Koritnik

Perkiraan saya untuk Italia adalah di bawah 10% dari pengujian kode formal. Mungkin hampir hanya kode misi-kritis.
Wizard79

Saya pernah bekerja di Irlandia, Inggris, Skotlandia, dan Slovenia dan sepertinya Italia tidak tampak berbeda.
Robert Koritnik

1

Kami adalah perusahaan lepas pantai berukuran menengah di Asia Selatan. Namun, kami selalu melakukan proyek berbasis di Amerika Serikat dan langsung bekerja dengan persyaratan yang dikirim dari perusahaan Amerika Serikat.

Kami menerapkan pengujian metodis pada setiap aplikasi yang kami buat. Mungkin, kualitas pengujian tidak memenuhi standar, tetapi kami mempekerjakan mereka.


Apakah tes-tes itu otomatis atau terutama manual? Saya sedikit mengedit pertanyaan saya. Bisakah Anda memberikan perkiraan pengujian perangkat lunak di pasar profesional juga?
Robert Koritnik

Sebagian besar pengujian kami dilakukan secara manual.
Shamim Hafiz

1

Sebanyak purist di dalam saya tidak mau menerima bahwa harus ada manajemen risiko yang dibangun ke dalam keputusan untuk seberapa keras Anda menguji atau apakah Anda melakukan pengujian formal sama sekali. Untuk aplikasi internal, yang saya duga adalah% besar dari proyek pemrograman, biaya untuk merilis bug kemudian dengan cepat menambalnya setelah diketahui terkadang dapat melebihi biaya dari tim pengujian penuh. Tentu saja itu tergantung pada aplikasi dan potensi biaya kegagalan.

Yang mengatakan, saya tidak berpikir perencanaan manajemen risiko adalah alasan kurangnya pengujian formal. Saya pikir ini lebih merupakan hasil dari manajer non-teknis yang tidak memahami nilai yang diberikannya dan hanya melihat biayanya.


2
Saya mendengar apa yang Anda katakan, tetapi sulit untuk dibenarkan. Penelitian telah menunjukkan bahwa semakin lama bug berjalan tanpa disadari semakin banyak biayanya, secara eksponensial. Biaya pembuatan bug untuk pelanggan sangat besar, dan menambalnya sering menyebabkan bug baru, jika kerangka pengujian unit tidak ada (skenario yang mungkin terjadi ketika mentalitas "tempel dan perbaiki" seperti ini ada). Konsekuensinya, penggunaan alat dan metodologi pengujian secara bijaksana dapat terbukti jauh lebih murah daripada memperbaiki dan memperbaiki.
Robert Harvey

3
Saya semakin skeptis terhadap dogma itu, terutama bagaimana itu diterapkan secara universal. Saya yakin memang benar beberapa waktu, tetapi tidak semua bug dibuat sama, juga tidak semua aplikasi. Saya merasa sangat sulit untuk menelan bahwa bug dalam aplikasi internal yang digunakan oleh 10 orang secara signifikan lebih mahal untuk diperbaiki jika ditemukan selama pengujian unit dibandingkan dalam rilis patch. Mungkin secara eksponensial lebih memalukan, tetapi tidak lebih mahal kecuali Anda mengabaikan biaya sebenarnya dari waktu yang dihabiskan seorang tester menemukan bug.
JohnFx

2
Saya juga bertanya-tanya apakah statistik itu tidak lebih berlaku untuk proyek-proyek besar (misalnya Sistem Operasi) dari mana mereka dibuat dan tidak diterjemahkan ke aplikasi jenis CRUD yang kebanyakan kita bangun untuk mencari nafkah.
JohnFx

Saya setuju dengan kalian berdua dan telah melihat kedua kasus. Tapi saya sudah pasti merasa bagian saya dari biaya eksponensial yang dijelaskan oleh Robert, terutama ketika bug telah ada dalam perangkat lunak begitu lama sehingga fitur-fitur lain akan benar-benar mulai rusak jika diperbaiki. Dengan pengkodean panik yang cukup buruk dengan orang yang menangani masalah cukup lama dan bug yang bertahan dalam waktu yang cukup lama, 1 +1 tidak 2. Ini 7. Dan jika bukan 7, semuanya akan berantakan.

1

Sampel saya sangat kecil untuk menyimpulkan persentase, tetapi begini saja.

Salah satunya adalah perusahaan chip + firmware fabless, yang melakukan pengujian fanatik. 24/7 tes otomatis pada puluhan instalasi, masing-masing menguji puluhan unit secara paralel. Tim perangkat lunak yang didedikasikan untuk mengembangkan perangkat lunak pengujian. Tim perangkat keras yang didedikasikan untuk membangun rig uji. Pengujian kompatibilitas terhadap puluhan pesaing. Heck, mereka bahkan membeli instalasi chip tester multi-juta dolar untuk mengembangkan dan men-debug beberapa tes yang dijalankan fab ketika chip meninggalkan pengecoran.

Yang lain adalah bank. Lingkungan yang sangat berbeda: tidak ada rilis produk, tetapi banyak dan banyak perangkat lunak internal untuk terus berjalan terus menerus. Orang-orang ini menguji cr * p dari setiap perubahan yang mereka buat. Mereka memiliki pemisahan yang sangat ketat pada lingkungan DEV / QA / PROD, pengujian regresi otomatis, pengujian QA wajib yang ditandatangani oleh pengguna akhir sebelum dilepaskan ke dalam produksi, dll.

Jadi ya, orang melakukan pengujian metodis. Tapi seperti yang Anda tahu, saya tidak pernah bekerja di tempat yang mengirimkan perangkat lunak GUI khas Anda untuk pengguna komputer biasa.


1

Saat ini saya menulis firmware tertanam untuk perusahaan startup kecil yang membuat perangkat medis nirkabel. Kita diharuskan melakukan pengujian yang ketat, dan memiliki departemen kualitas yang sepenuhnya terpisah yang dipimpin oleh seseorang yang melapor langsung kepada CEO. Saya belum pernah kode saya diuji secara menyeluruh sebelumnya oleh penguji yang terpisah (satu-satunya waktu yang membandingkan, adalah ketika saya bekerja pada sistem TV satelit sekitar 15 tahun yang lalu.)

Hasil pengujian kami diserahkan ke FDA (sejauh ini kami mendapat dua izin FDA - masing-masing pengiriman sepanjang 500 halaman). Metodologi pengembangan dan pengujian kami keduanya harus diaudit secara berkala.

Jadi bukan hanya perusahaan besar yang melakukan banyak pengujian formal.

Catatan - dalam 25+ tahun pemrograman kontrak / konsultasi, saya juga telah bekerja untuk banyak perusahaan yang tidak melakukan pengujian formal. Sebagian besar dari mereka sudah tidak ada lagi.


Saya juga di perusahaan perangkat medis, dan pengantar GMP (Good Manufacturing Practices, FDA-speaking untuk proses desain / pengujian terkontrol) cukup membuka mata saya. Itu membuat saya seorang insinyur yang lebih baik (dan sayangnya ahli buku catatan)
Bill Gribble

0

Hampir setiap perusahaan saya telah melakukan pengujian metodis. Perusahaan saya saat ini memiliki beberapa tes gaya unit dasar dan itu tidak cukup. Kami memiliki beberapa masalah kualitas karena hal ini. Saya sangat merekomendasikan pengujian menyeluruh independen pada proyek apa pun yang akan digunakan oleh siapa pun selain Anda. Uang yang dihabiskan akan sangat berharga. Aplikasi yang tidak berfungsi jangan digunakan. Itu berlaku untuk menghadap ke dalam maupun ke luar.


Saya sedikit mengedit pertanyaan saya. Bisakah Anda memberikan perkiraan pengujian perangkat lunak di pasar profesional juga?
Robert Koritnik

@ Robert: Saya tidak mengerti pertanyaan Anda "perkiraan pengujian perangkat lunak". Apakah Anda bertanya pendapat saya tentang berapa banyak perusahaan menguji? Perkiraan saya mungkin 90% atau lebih berdasarkan apa yang saya lihat dengan mata kepala sendiri. Pengujian adalah bagian umum dari pengembangan profesional.
Bryan Oakley

0

Dalam dua puluh tahun terakhir karier saya melalui delapan atau lebih perusahaan, saya belum pernah mengerjakan proyek yang tidak melakukan pengujian. Jumlah pengujian berbeda di setiap perusahaan, tetapi setiap proyek pengembangan profesional yang pernah saya kerjakan melakukan pengujian formal. Ini berlaku untuk perusahaan kecil dan menengah (di mana "kecil" berarti kurang dari 10 karyawan, dan "menengah" berarti beberapa ribu karyawan atau kurang).

Beberapa perusahaan tidak memiliki banyak pengujian otomatis, beberapa tidak memiliki banyak pengujian manual, tetapi mereka memiliki setidaknya satu atau yang lain.


0

Itu tergantung pada kebutuhan pelanggan. Dalam situasi kontrak mungkin ada tes penerimaan. In-house biasanya adalah slapjob dengan sedikit tes. Barang-barang konsumen biasanya sangat tertutup dalam fungsionalitas yang sering tetapi kasar di sekitarnya.


0

Jawaban singkat: Ya

Jawaban panjang:

  1. Saya tidak memiliki perkiraan yang baik untuk kategori pertama (mungkin agak jauh dari nol, tapi berapa banyak?), Tetapi pengalaman saya sebenarnya menguatkan dengan perkiraan kedua Anda. Sulit untuk memberikan persentase yang berarti karena jumlah dan jenis pengujian tergantung pada jenis aplikasi yang sedang dikembangkan, dan jangka waktu yang tersedia dan juga keahlian dari pengembang dan bagaimana proyek dijalankan. Dalam praktiknya, rintangan paling penting bagi pengembang adalah tes penerimaan karena itu merupakan tonggak penting untuk tujuan penagihan. Tetapi ini juga merupakan waktu di mana hal-hal yang tidak terduga dapat terjadi (lebih banyak persyaratan) dan para pengembang mungkin ditekan untuk memberikan dan bertahan dengan pengujian adhoc apa pun yang mungkin dan tepat waktu (pada tahap ini), di atas waktu yang dibutuhkan untuk pemecahan masalah dan mengatasi yang tidak terduga.

  2. Saya telah melalui berbagai proyek dengan berbagai kombinasi faktor yang disebutkan di atas:

    • tidak ada tes unit formal, hanya tes integrasi dan sebagian besar tes adhoc

    • sangat formal mulai dari pengujian unit hingga rencana pengujian terperinci yang melibatkan sumber daya QA khusus, pengujian otomatis (seperti yang dilakukan oleh penguji dengan seperangkat alat mereka sendiri) dan laporan cakupan kode. Tapi ini tidak selalu berarti bagi para pengembang seperti halnya bagi para manajer

Pada tingkat individu saya berusaha untuk mempertahankan pemahaman tentang pilihan saya ketika datang untuk menulis tes yang tepat sesuai dengan teknologi yang saya hadapi, dan melatihnya dengan kebijaksanaan saya sendiri. Pada dasarnya hal-hal yang sebenarnya bermakna dan bermanfaat bagi pekerjaan saya, dan tidak begitu banyak angka keluar.

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.