Dalam bidang pengujian otomatis, kasus pengujian yang sudah ketinggalan zaman dapat menjadi kendala yang tidak praktis. Artikel ini mengeksplorasi pendekatan proaktif di mana, daripada mempelajari proses debugging untuk menentukan apakah kasus pengujian sudah usang atau gagal karena bug, kami mengadaptasi dan memperbaruinya untuk memastikan fungsionalitas yang berkelanjutan. Dengan melakukan hal ini, kami tidak hanya menghemat waktu yang berharga namun juga meningkatkan efektivitas rangkaian pengujian secara keseluruhan.

Kasus uji yang sudah ketinggalan zaman adalah masalah nyata. Artikel menyebutkan bahwa Anda tidak dapat secara otomatis membedakan pengujian usang dan kasus pengujian yang mendeteksi bug karena keduanya akan gagal. Menurut a studi kasus sekitar 80% kegagalan dalam pengujian regresi disebabkan oleh bug pada perangkat lunak yang diuji dan 20% kegagalan lainnya disebabkan oleh pengujian yang sudah usang. Oleh karena itu, Anda harus men-debug 25% lebih banyak kasus pengujian untuk menghilangkan juga kasus pengujian yang sudah usang. Untungnya (seperti yang hampir selalu terjadi) ada cara yang lebih cepat dan mudah.

Pertama, kita harus menekankan bahwa tes tidak pernah habis paradoks pestisida adalah salah. Kenyataannya adalah bahwa test case hanya bisa menjadi usang, namun sangat berbeda dengan usang. Jika tidak ada perubahan dalam spesifikasi persyaratan, maka pengujian tersebut tidak akan aus atau menjadi usang. Jika suatu persyaratan diubah, maka beberapa kasus uji yang mencakup persyaratan tersebut dapat menjadi usang.

Saran kami untuk men-debug kasus pengujian agar dianggap usang sama dengan men-debug pengujian – jangan pernah melakukan ini. Solusinya adalah ketertelusuran kebutuhan. Metode aslinya adalah matriks yang memetakan persyaratan dan kasus uji. Berikut ini contohnya:

Ketika suatu persyaratan berubah, kasus uji terkait dapat dianggap usang. Kita dapat berasumsi bahwa spesifikasi yang dimodifikasi memerlukan kasus uji baru, sehingga kasus uji lama dapat dihapus. Artinya jika R3b dimodifikasi maka kasus uji TC02 – TC05 harus dihapus dan kasus uji baru untuk R3b harus dirancang.

Namun, jika suatu persyaratan dapat dipenuhi dengan lebih banyak kasus uji, kemungkinan besar satu kasus uji hanya mencakup sebagian dari persyaratan tersebut. Dalam hal ini, Anda dapat menyempurnakan persyaratan sehingga, jika sebagian persyaratan berubah, maka hanya satu atau maksimal dua kasus uji yang menjadi usang saat subpersyaratan diubah.

Namun, kasus uji dapat mencakup lebih banyak persyaratan. Jika salah satunya berubah dan yang lainnya tidak, maka test case yang baik mungkin dihapus. Untungnya, solusi yang lebih baik dapat digunakan dalam pengujian berbasis model. Daripada memetakan persyaratan untuk menguji kasus, mari kita buat ketertelusuran antara persyaratan dan serangkaian langkah model.

Ini sebuah contoh. Garis hijau adalah label yang menjelaskan persyaratan atau sub-persyaratan:

Disini R1, R3b, dan R5 terdiri dari semua langkah di bawahnya, sehingga R1 terdiri dari semua langkah pada gambar. Mari kita asumsikan bahwa R5 diubah sehingga 'R5 menghapus sepeda gratis, diberikan diskon uang yang sama', maka kita harus mempertimbangkan hanya tiga langkah di bawah label ini. Membaca langkah-langkahnya, mudah untuk mengetahui bahwa kita harus menerapkan kembali respons saja, yaitu keluaran seperti harga total tetap ada. Model tetapnya adalah sebagai berikut:

Dengan cara ini Anda dapat memperbaiki submodel yang sudah usang dan dengan demikian kasus uji terkait menjadi valid dengan hanya memodifikasi beberapa elemen model.

Oke, tapi bagaimana jika perubahan R1 dicakup oleh 8 kasus uji yang melibatkan beberapa langkah? Untungnya, persyaratan ini merupakan dasar dari persyaratan lainnya sehingga tidak akan berubah sehingga persyaratan lainnya tetap ada. Misalnya jika berubah sehingga hanya mobil yang dapat ditambahkan, maka dua persyaratan lainnya juga menjadi tidak valid. Sebaliknya jika sepeda motor juga dapat ditambahkan, maka model dan test case yang ada tetap valid hanya beberapa test case (elemen model) baru yang harus ditambahkan.

Kesimpulannya adalah dengan menerapkan pengujian berbasis model khususnya Harmony, kasus pengujian yang sudah usang dapat dengan mudah diperbaiki agar berfungsi atau harus dihapus. Tidak diperlukan proses debug, Anda dapat mengubah kasus pengujian pada tingkat model.