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

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.

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.

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.

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.

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

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.

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 ...

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.

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.

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.

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.

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.

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.

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.

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.