Baunya seperti pekerjaan rumah.
Apakah pengujian di bidang perangkat lunak diperlukan?
Iya nih. Benar. Di semua tingkatan. Di luar beberapa domain khusus, kami belum pada tahap di mana kami dapat membuktikan secara matematis kode kami benar terhadap bug tertentu (setidaknya tidak dalam jangka waktu yang masuk akal), jadi kami harus melempar batu ke sana untuk melihat apakah dan dimana itu rusak.
Jika kita membuat perangkat lunak dengan sangat hati-hati, mengapa kita harus menguji?
Pengujian bukan hanya tentang menemukan kesalahan pengkodean. Ini juga tentang memastikan bahwa Anda telah memenuhi semua persyaratan Anda, dan bahwa keseluruhan sistem berkinerja seperti yang diharapkan. Jika saya memiliki persyaratan bahwa transaksi yang gagal harus mengembalikan kode kesalahan tertentu, maka saya perlu menulis tes untuk memverifikasi bahwa fungsionalitasnya ada dan berfungsi dengan benar.
Dan semua itu mengasumsikan bahwa spesifikasi dan desainnya lengkap, benar, dan konsisten secara internal, yang seringkali tidak demikian. Bahkan jika Anda memenuhi spesifikasi untuk surat itu dan mengikuti desain ke titik dan titik koma terakhir, jika spesifikasi atau desain buruk, maka akan ada masalah pada waktu integrasi. Seringkali, pengujian sistem atau integrasi adalah ketika Anda mengetahui bahwa spesifikasi itu sendiri bermasalah dan perlu direvisi (lihat kisah perang di bawah).
Setelah pengujian, dapatkah kami yakin bahwa kami telah mencapai tujuan ini (produk / perangkat lunak berfungsi sebagaimana dimaksud) karena kami telah melakukan pengujian untuknya? Apa itu mungkin?
Tidak, tidak sampai 100%. Kami tidak dapat menguji setiap kombinasi input atau jalur eksekusi yang dimungkinkan dalam kode apa pun kecuali yang paling sederhana. Kami tidak dapat menjelaskan semua faktor lingkungan. Kami tidak dapat membayangkan semua mode kegagalan yang memungkinkan.
Kami dapat menguji ke titik di mana kami cukup yakin tidak ada masalah besar. Sekali lagi, inilah mengapa kita perlu menguji di semua tingkatan. Tulis serangkaian tes untuk memastikan kode Anda menangani kondisi tepi dengan benar (input buruk, hasil yang tidak terduga, pengecualian, dll.). Uji unit untuk memverifikasi bahwa kode Anda memenuhi persyaratannya. Tes sistem untuk memverifikasi pemrosesan end-to-end. Tes integrasi untuk memverifikasi bahwa semua komponen saling berbicara dengan benar. Lakukan pengujian kegunaan untuk memastikan bahwa semuanya berfungsi sedemikian rupa sehingga pelanggan tidak ingin menembak Anda.
Skenario dunia nyata - Saya sedang mengerjakan sistem back-end yang sesekali mengirim pembaruan ke layanan GUI untuk ditampilkan dalam tabel di layar. Selama proyek, persyaratan ditambahkan untuk menambahkan pemfilteran pada tampilan (misalnya, operator dapat memilih untuk menampilkan subset dari entri dalam tabel). Kesalahan desain # 1 - pemfilteran seharusnya dilakukan oleh layanan GUI (Saya memiliki gagasan kuno dan kuno bahwa fungsi manajemen tampilan harus menjadi tanggung jawab perangkat lunak manajemen display), tetapi karena politik dan ketidakmampuan saya untuk mengenali masalah sebelum menjadi masalah , persyaratan itu ditempatkan pada layanan back-end. Baiklah, oke, tidak masalah, saya bisa melakukannya. Filter menyatakan perubahan, saya menerima pesan, dan kemudian saya mengirim pesan buat atau hapussetiap baris dalam tabel , karena itulah cara kerja antarmuka (kesalahan desain # 2 - tidak ada cara untuk mengirim pembaruan ke beberapa baris dalam satu pesan; kami bahkan tidak bisa mengirim satu pesan "jelas" atau "hapus" untuk menghapus seluruh tabel).
Ya, semua berjalan baik selama pengembangan; pengujian unit, sistem, dan integrasi menunjukkan bahwa saya mengirim informasi yang benar dan menangani perubahan filter dengan benar. Kemudian kita sampai ke pengujian kegunaan, dan semuanya jatuh dengan keras , karena volume data luar biasa. Latensi jaringan antara layanan backend saya dan GUI berada di urutan .15 hingga .25 detik. Tidak buruk jika Anda hanya perlu mengirim pembaruan untuk selusin baris atau lebih. Mematikan ketika Anda harus mengirim pembaruan untuk beberapa ratus. Kami mulai mendapatkan laporan bug bahwa GUI membeku setelah mengubah status filter; yah, tidak, yang terjadi adalah mengambil beberapa menit untuk memperbarui tampilan karena protokol pesan update-satu-baris-pada-waktu-berkepala tulang tidak bisa menangani skenario dunia nyata.
Perhatikan bahwa semua itu dapat dan seharusnya telah diantisipasi oleh semua orang dari kontraktor utama hingga saya yang kecil jika kita repot-repot melakukan bahkan analisis yang paling mendasar sebelumnya. Satu-satunya pembelaan yang akan saya tawarkan adalah bahwa kami menutup tahun kedua dari proyek enam bulan yang akan segera dibuang setelah melahirkan, dan kami semua hanya ingin melihat bagian belakangnya.
Yang membawa kita pada alasan terakhir untuk menguji - CYA. Proyek dunia nyata gagal karena berbagai alasan, banyak di antaranya bersifat politis, dan tidak semua orang bertindak dengan itikad baik ketika ada yang salah. Jari diarahkan, tuduhan dibuat, dan pada akhirnya Anda harus dapat menunjuk ke sebuah catatan yang menunjukkan bahwa setidaknya barang - barang Anda bekerja sebagaimana mestinya.
If we create a software with care in during its development period then why should we go for Test?- karena bagaimanapun caranya, bahkan programmer yang paling ahli pun membuat kesalahan.