Mengoptimalkan Pengujian Perangkat Lunak: Menguji Realitas

Seberapa penting pengujian perangkat lunak dan jaminan kualitas perangkat lunak dalam dunia pengembangan perangkat lunak saat ini? Artikel ini membahas masalah ini dan bagaimana organisasi dapat memanfaatkan pengujian perangkat lunak secara maksimal.

sang penulis: Peter Fogel

Jika kita tidak memahami fakta-fakta yang mendasarinya, kita tidak dapat memperoleh hasil maksimal dari eksperimen tersebut.

Intinya adalah kami selalu memprioritaskan aktivitas kami, termasuk pengujian. Jika saya membuat aplikasi web untuk digunakan oleh staf internal perusahaan saya, saya memiliki pendekatan yang berbeda terhadap desain dan estetika web dibandingkan saat saya menguji aplikasi yang akan digunakan oleh pelanggan perusahaan saya. Dengan aplikasi internal, saya memastikannya berfungsi dan dapat digunakan, tetapi saya tidak terlalu khawatir tentang tampilan aplikasi seperti pada aplikasi eksternal.

Bukannya saya tidak peduli halaman jelek apa yang saya berikan kepada karyawan saya, tetapi jika halaman itu adalah bagian dari pekerjaan karyawan perusahaan saya, mereka mungkin tidak peduli bagaimana penampilan mereka. Bahkan, mereka mungkin lebih suka halaman terlihat sebagus halaman jelek lainnya yang saya buat, dan bekerja sedekat mungkin dengan tiga hal yang paling disukai pengguna: stabilitas, stabilitas, stabilitas.

Namun, jika saya khawatir pelanggan perusahaan saya akan pergi ke tempat lain (dan saya), saya menghabiskan banyak waktu untuk memastikan bahwa aplikasi eksternal seperti situs tempat pengguna ingin menghabiskan waktu mereka.

Dan jika kami ingin jujur ​​​​tentang hal ini, kami membuat keputusan yang sama terkait dengan pengujian perangkat lunak.

Kenyataannya adalah ini bukan “jaminan kualitas”.

Faktanya, proses kami saat ini bahkan tidak boleh disebut “jaminan kualitas”. Memanggil pengujian/debugging “jaminan kualitas” tampaknya menunjukkan orang-orang melakukan percakapan seperti ini:
Orang 1: Saya baru saja membeli perangkat lunak ini dan tidak hanya tidak berguna, tetapi juga memakan waktu lama dan sulit digunakan.
Orang 2: Apakah Anda punya masalah?
Orang 1: Yah…tidak.
Orang 2: Yah, itu perangkat lunak yang berkualitas, bukan?

Menghilangkan cacat bukanlah “kualitas” – menghilangkan semua cacat berarti mencapai tingkat penerimaan minimum (dan jangan salah – ini adalah sesuatu yang layak dilakukan). Namun alih-alih menyebut proses ini “jaminan kualitas”, lebih baik disebut “manajemen risiko”. Izinkan saya menjelaskan alasannya.

Batasan realitas

Realitas pengujian adalah bahwa tidak akan pernah ada cukup waktu/orang/uang untuk menghasilkan perangkat lunak bebas bug.

Aspirasi penting di sini: jika kami menulis program yang lebih sederhana, kami dapat memberikan program bebas bug. Tapi kami tidak. Prinsip SOLID dan arsitektur layanan mikro sebenarnya adalah upaya untuk membangun aplikasi kompleks dari bagian sederhana. Masalahnya adalah kami menggunakannya untuk membangun aplikasi yang kompleks: kami belum banyak menyelesaikan masalah melainkan menggantikannya.

Dengan program yang sederhana dan kompleks, sangat mudah untuk menemukan bug pada tahap awal pengembangan program. Namun, dalam aplikasi yang kompleks, saat kami menangani setiap bug ini, dibutuhkan waktu lebih lama untuk menemukan “bug berikutnya”. Terakhir, dengan sumber daya yang kami miliki, waktu untuk menemukan “bug berikutnya” sangat lama sehingga menemukannya berarti tidak merilis perangkat lunak.

Alat pengujian otomatis (seperti Telerik Test Studio) membantu di sini dengan sangat meningkatkan kemampuan kami untuk menjalankan pengujian regresi apa pun yang dapat kami lakukan secara otomatis. Pengujian otomatis juga membantu kami selama pengujian eksplorasi untuk membuat pengujian otomatis yang melacak kemajuan kami saat kami memperbaiki bug yang kami temukan (dan kemudian pengujian tersebut menjadi bagian dari pengujian regresi kami untuk memastikan bug tidak pernah terbuka tidak berfungsi). Masih ada lagi: Dikombinasikan dengan sistem pelaporan yang efektif, pengujian otomatis mengurangi waktu yang diperlukan untuk menentukan penyebab bug dan memberi tahu manajemen tentang kemajuan perangkat lunak menuju rilis. Lihat aksinya di posting blog ini.

Judul: Pengujian otomatis dengan sistem pelaporan yang efektif

Tetapi pengujian otomatis tidak dapat membantu kami menemukan “bug berikutnya”. Untuk itu, kami membutuhkan penguji yang kreatif dan berpengalaman yang dapat memprioritaskan pengujian yang mereka jalankan untuk menemukan “bug kritis”. Namun, ini hanya masalah waktu sampai beberapa bug ditemukan dan merugikan perusahaan Anda dengan “batuk” nyata Pentium bug “batuk”… atau Anda akhirnya mengganti cerita horor pilihan Anda.

Jadi, seperti yang saya katakan, yang kami lakukan adalah manajemen risiko. Memikirkan pengujian sebagai manajemen risiko memberi Anda dasar yang lebih baik untuk memutuskan bagaimana menghabiskan waktu Anda: Anda tidak melakukan pengujian yang tidak mengurangi risiko Anda atau di mana Anda dapat mengurangi risiko dengan biaya rendah. kurang dari biaya untuk menemukan “bug berikutnya”.

Faktanya layak untuk diuji

Lalu ada kenyataan menjalankan tes: itu satu-satunya alat yang kami percayai untuk menemukan bug. Sementara proses lain telah disarankan, desain berdasarkan kontrak atau perangkat lunak yang terbukti benar, kami tidak percaya pada alat tersebut seperti yang kami yakini dalam menjalankan pengujian. Dan tidak masalah jika kita berbicara tentang pengujian eksplorasi, pengujian regresi, pengujian penerimaan pengguna atau bagian lain dari metodologi pengujian: kami percaya dalam menjalankan pengujian.

yang menyebabkan tes A itu perlu Aktivitas, bukan a Nilai ditambahkan Aktivitas. Anda bisa membuktikannya. Kunjungi pengguna Anda dan tanyakan kepada mereka, “Jika kami dapat memproduksi perangkat lunak tanpa bug dan tanpa pengujian, apakah Anda tidak senang?” Saya jamin tidak ada dari mereka yang akan berkata: “Tapi saya akan sangat ketinggalan ujian!”

Setiap menit yang kita habiskan untuk tugas-tugas penting menyita waktu dari tugas-tugas bernilai tambah. Ini berarti Anda harus menghabiskan waktu pengujian sebanyak yang seharusnya… dan tidak lebih dari satu menit. Dan seperti investasi, Anda perlu memastikan bahwa setiap menit yang Anda habiskan untuk pengujian menghasilkan keuntungan yang besar.

Judul: Perekam uji visual – alat penting untuk otomatisasi QA apa pun

Jadi, kami perlu mengotomatiskan sebanyak mungkin untuk mengeluarkan sumber daya (orang) kami yang paling mahal dari proses tersebut. Di mana pun itu mengurangi biaya pengujian kami, kami harus mengalihkan pengujian ke tahap awal pengembangan. Kita perlu mengintegrasikan orang-orang yang akan mendapat manfaat dari pengujian (misalnya pengguna akhir) ke dalam proses sehingga mereka menghargainya, atau jika kita tidak dapat membuat pengguna menghargai pengujian, setidaknya libatkan mereka saat bug dibuat. Produksi

Realitas perencanaan

Intinya adalah Anda tidak dapat memulai pengujian cukup awal. Untuk memastikan bahwa developer membangun dan menguji hal yang benar, mulailah dengan menguji/memvalidasi persyaratan ini. Uji kode lebih awal untuk memastikannya memenuhi persyaratan dan untuk memastikan bahwa kode di masa mendatang dibuat berdasarkan dan terintegrasi dengan kode yang berfungsi.

Mulai pengujian lebih awal, prioritaskan pengujian Anda untuk mengelola risiko, dan pikirkan waktu dan uang pengujian Anda sebagai investasi: Di ​​mana saya membelanjakan paling sedikit untuk mendapatkan pengembalian terbanyak? Jika Anda melakukan hal-hal ini, Anda akan mendapatkan kenyataan yang dapat Anda (dan perusahaan Anda) jalani.

Tentang Penulis

Peter Vogel adalah Arsitek Sistem dan Direktur Layanan Informasi di PH&V. PH&V menawarkan konsultasi lengkap dari desain UX melalui pemodelan objek hingga desain basis data. Peter juga menulis kursus dan mengajar untuk Learning Tree International.