Kegagalan pengujian menimbulkan tantangan yang signifikan dalam pengujian otomatis. Dalam studi ini, kami mendalami definisi yang lebih tepat mengenai tes flaky dan mengusulkan solusi langsung namun efektif untuk menghilangkannya. Selain itu, kami menyajikan contoh nyata untuk mengilustrasikan dampak pendekatan kami.

Kegagalan pengujian dianggap sebagai salah satu tantangan utama pengujian otomatis [1]. Menurut Google, pengujian yang tidak stabil merupakan 16% dari seluruh kegagalan pengujian dalam sistem mereka [2]. Pengujian yang tidak stabil ini membutuhkan waktu 1,5 kali lebih lama untuk diperbaiki dibandingkan dengan pengujian yang tidak terkelupas.

Definisi tradisional pengujian tidak stabil mengatakan bahwa 'Pengujian tidak stabil mengacu pada pengujian yang menghasilkan hasil yang tidak konsisten, gagal atau lulus secara tidak terduga, tanpa modifikasi apa pun pada kode yang sedang diuji.' Sayangnya definisi ini kurang tepat, mari kita buat definisi yang lebih baik.

Biasanya, suatu ujian tidak stabil, terkadang lulus dan terkadang gagal. Namun, ada juga kasus lain. Mungkin saja suatu pengujian selalu gagal tetapi pada titik eksekusi yang berbeda. Jika pengujian tidak gagal, pengujian ini akan selalu gagal dan akan mendeteksi bug. Kasus lainnya adalah ketika hasilnya tidak konsisten bukan karena kasus pengujian otomatis, namun karena sistem itu sendiri yang tidak konsisten. Artinya jika pengujian dijalankan secara manual, sistem akan bekerja dengan benar atau salah. Jadi ini adalah masalah lain (sistem tidak stabil), tetapi bukan tes yang tidak stabil. Sekarang kita dapat mendefinisikan pengujian yang tidak stabil sebagai kasus pengujian yang eksekusinya menghasilkan hasil yang berbeda termasuk kasus kegagalan pada titik eksekusi yang berbeda, dengan asumsi bahwa kasus pengujian yang setara memiliki hasil yang sama setiap kali dijalankan secara manual.

Di sini kami tidak mempertimbangkan sistem yang tidak stabil (tidak konsisten), hanya pengujian yang tidak stabil. Terdapat perbedaan yang signifikan antara pengujian yang gagal dan pengujian yang tidak stabil, yaitu pengujian yang gagal akan selalu gagal pada titik eksekusi yang sama, namun pengujian yang tidak stabil dapat lolos. Jika tes yang gagal lolos, maka (sebagian) persyaratan yang dicakup oleh tes tersebut sudah benar. (Perhatikan bahwa kami tidak mempertimbangkan kasus sistem yang tidak stabil.) Jika ya, lalu mengapa kita menghabiskan banyak waktu dan uang untuk memperbaiki pengujian yang tidak stabil? Cukup dengan mengeksekusinya kembali agar bisa lulus. Lagi pula, kasus uji yang tidak stabil mungkin lolos pada eksekusi pertama dan kita bahkan tidak tahu apakah kasus tersebut tidak stabil.

Oleh karena itu, alih-alih memperbaiki pengujian yang tidak stabil, jalankan pengujian tersebut lebih sering, dan jika pengujian tersebut lulus, maka pengujian tersebut dapat dianggap sebagai pengujian yang baik yang menunjukkan kebenaran persyaratan terkait. Di Harmony Anda dapat mengatur jumlah eksekusi ulang:

Di sini, pengujian yang gagal dijalankan kembali dua kali. Menerima saran kami sebelumnya tentang membuat semua kasus pengujian lulus, hanya kesalahan baru yang menyebabkan kegagalan pengujian, ditambah pengujian yang tidak stabil. Artinya, hanya sebagian kecil pengujian yang harus dilakukan ulang.

Penyebab umum kegagalan adalah lingkungan bersama untuk pelaksanaan pengujian paralel. Sekalipun semua kasus pengujian bersifat independen dan dapat dijalankan dalam urutan apa pun, menjalankannya secara paralel dapat menyebabkan keadaan dalam yang tidak diharapkan, sehingga mengakibatkan pengujian gagal. Oleh karena itu, kasus uji yang gagal tidak dapat dijalankan kembali secara paralel.

Untuk kasus pengujian yang tidak stabil dan mendeteksi bug, eksekusi ulang saja tidak cukup karena akan selalu gagal. Dalam hal ini, kita harus menyimpan semua laporan dan memilih kegagalan titik eksekusi terbaru. Mudah-mudahan, ini adalah cacat yang dapat dideteksi oleh pengujian manual yang sama.

Tentu saja, kita harus menganalisis pengujian yang gagal setelah eksekusi ulang terakhir dan mungkin masih ada beberapa pengujian yang gagal. Ini dapat diperbaiki atau diubah dengan uji kasus yang lebih baik. Namun, jumlah pengujian flaky yang tersisa jauh lebih sedikit (atau nol) sehingga kami dapat mengurangi biaya perbaikan pengujian flaky secara signifikan dan mempersingkat waktu perbaikan bug.

Kami menguji Harmoni dengan Harmoni. Dengan menghilangkan kasus uji yang disertakan dalam kasus uji lainnya, kami memiliki 70 pengujian e2e. Eksekusi lima kasus gagal, dan setelah eksekusi ulang, semua kasus uji lulus. Hanya lima pengujian yang harus dijalankan ulang oleh sistem, yaitu 7%. Memang bukan angka yang besar, waktu pelaksanaan tes tidak bertambah secara signifikan. Berikut adalah beberapa kasus pengujian untuk suatu fitur:

Dua kasus uji lulus hanya untuk kedua kalinya (untuk percobaan ulang pertama), yaitu pengujian yang tidak stabil.