Nama saya Maria Snopok, saya manajer arah otomasi di Departemen Pengujian Departemen Pengembangan dan Dukungan Produk Data Besar Grup Ritel X5. Pada artikel ini, saya akan membagikan pengalaman kami dalam menerapkan tes otomatis dan mengurangi biaya terkait. Semoga informasi ini bermanfaat bagi tim yang kesulitan untuk beralih ke pengujian otomatis.
Bagaimana kami sampai pada tes otomatis
Sebelum munculnya otomatisasi, saya bekerja sebagai manajer pengujian di salah satu produk kami. Saat model pengujian yang cukup besar dibentuk di sana, kami mulai mendistribusikan kumpulan pengujian regresi ke seluruh tim pengembangan - jika dia bertanggung jawab atas rilis tersebut, dia juga sedang menguji. Regresi tim semacam itu menyelesaikan tugas-tugas berikut:
- pengembang yang sebelumnya menangani bagian fungsionalitas mereka yang terpisah dapat melihat keseluruhan produk;
- kami membuat regresi lebih cepat dan karena itu kami merilis lebih sering;
- kami tidak mengurangi recourse lagi - kualitasnya meningkat.
Tapi itu mahal, karena pengujian dilakukan oleh spesialis mahal - pengembang dan analis, dan kami mulai bergerak ke arah otomatisasi.
Tes asap adalah yang pertama dilakukan - pemeriksaan sederhana untuk memastikan bahwa halaman terbuka, dimuat, tidak macet, dan bahwa semua fungsionalitas dasar tersedia (sejauh ini tanpa memeriksa logika dan nilai).
Kami kemudian mengotomatiskan skrip ujung ke ujung yang positif. Langkah ini membawa manfaat maksimal: pengujian memungkinkan untuk memastikan bahwa proses bisnis utama produk berfungsi, bahkan jika ada kesalahan dalam skenario negatif, alternatif, dan sekunder.
Dan akhirnya kami sampai pada otomatisasi pemeriksaan regresi lanjutan dan skenario alternatif.
Pada setiap tahap ini, kami menghadapi sejumlah kesulitan yang sangat memperlambat dan memperumit seluruh proses. Solusi praktis apa yang telah membantu kami mempercepat dan memfasilitasi pekerjaan para otomat?
Empat cara untuk mengurangi biaya pada tes otomatis
1. Setuju dengan format atribut tes di pantai
Pengembang dan penguji otomatis harus menyetujui terlebih dahulu tentang aturan penamaan elemen HTML untuk penggunaan selanjutnya sebagai pencari lokasi dalam tes otomatis. Sebaiknya format yang sama untuk semua produk. Kami telah mengembangkan persyaratan untuk memahami cara memberi nama atribut, bahkan sebelum fitur ditransfer ke pengembangan; pemahaman ini ada baik di sisi pengembang maupun di sisi penguji. Kami setuju bahwa setiap elemen html yang terlihat diberi atribut data-qa khusus, yang akan digunakan penguji untuk mencarinya. Atribut diberi nama sesuai dengan pola berikut:
[nama layar] [nama bentuk / tabel / widget] [nama elemen]
Contoh:
data-qa = "plu-list_filter-popover_search-input"
data-qa = "common_toolbar_prev-state"
Sangat mudah untuk mengisolasi atribut seperti itu hanya dari dokumentasi dan tata letak, dan semua orang tahu apa artinya seharusnya. Saat pengembang mengambil tugas untuk bekerja, dia, sesuai dengan aturan ini, memberikan atribut data-qa ke semua elemen halaman yang terlihat - header, tombol, tautan, pemilih, baris dan kolom tabel, dll. Hasilnya, penguji dapat mulai menulis tes otomatis selama pengembangan fitur, berdasarkan hanya untuk layout dan dokumentasinya saja, karena sudah mengetahui bagaimana atribut tersebut akan dinamai.
Pengenalan atribut pengujian memungkinkan kami mengurangi biaya pengembangan dan dukungan autotests rata-rata 23% dibandingkan periode sebelumnya dengan mengurangi biaya pembaruan pengujian dan pelokalan elemen untuk autotests.
2. Kami menulis pengujian manual agar mudah diotomatisasi
Penguji manual dan insinyur otomatisasi tinggal di alam semesta yang berbeda. Yang manual ditujukan untuk memeriksa beberapa objek uji terdekat yang berbeda dengan satu skrip. Automator, di sisi lain, cenderung menyusun semuanya dan hanya memeriksa objek dengan jenis yang sama dalam satu pengujian. Untuk alasan ini, pengujian manual tidak selalu mudah untuk diotomatisasi. Ketika kami menerima kasing manual untuk otomatisasi, kami menghadapi sejumlah masalah yang tidak memungkinkan kami untuk mengotomatiskan skrip yang dihasilkan kata demi kata, karena skrip tersebut ditulis agar mudah dieksekusi oleh orang yang masih hidup.
Jika seorang automator sangat tenggelam dalam produk, dia tidak memerlukan kasing "manual", dia dapat menulis sendiri skrip untuk otomatisasi. Jika dia datang ke produk "dari luar" (di Departemen kami, selain penguji, tim juga memiliki pengujian sebagai layanan khusus), dan sudah ada model pengujian dan skrip yang disiapkan oleh penguji manual, Anda mungkin tergoda untuk menginstruksikannya untuk menulis autotests di dasar dari kasus uji "manual" ini.
Jangan menyerah pada hal ini: kemampuan maksimal yang dapat digunakan oleh seorang automator untuk menggunakan kasus uji manual hanyalah untuk memahami cara kerja sistem dari sudut pandang pengguna.
Oleh karena itu , pertama-tama perlu mempersiapkan pengujian manual agar dapat diotomatiskan , dan untuk menangani masalah umum.
Masalah 1: menyederhanakan kasus manual.
Solusi: merinci kasus.
Mari kita bayangkan deskripsi kasus manual:
- buka halaman daftar versi revisi
- klik tombol buat
- isi formulir
- klik tombol "buat"
- pastikan versi revisi dibuat
Ini adalah skenario yang buruk untuk otomatisasi, karena tidak menentukan apa yang sebenarnya perlu dibuka, dengan data apa yang harus diisi , apa sebenarnya yang kita harapkan untuk dilihat dan di bidang mana untuk melihatnya. Instruksi "pastikan versi berhasil dibuat" tidak cukup untuk otomatisasi - mesin memerlukan kriteria khusus yang dapat digunakan untuk meyakinkan keberhasilan tindakan.
Masalah 2: percabangan kasus.
Solusi: kasing seharusnya hanya memiliki skenario linier.
Konstruksi dengan "atau" sering muncul dalam casing genggam. Misalnya: "buka revisi 184 di bawah pengguna 1 atau 2". Ini tidak dapat diterima untuk otomatisasi, pengguna harus ditunjukkan dengan jelas. Konjungsi "atau" harus dihindari.
Masalah 3: ketidakrelevanan kasus.
Solusi: periksa kasus sebelum mengirimkannya ke otomatisasi.
Ini adalah masalah terbesar bagi kami: jika fungsionalitas sering berubah, penguji tidak punya waktu untuk memperbarui kasus pengujian. Tetapi jika penguji manual menemukan kasus yang tidak relevan, tidak akan sulit baginya untuk segera memperbaiki skrip. Seorang automator, terutama jika dia tidak tenggelam dalam produk, tidak akan dapat melakukan ini: dia tidak akan mengerti mengapa kasing tidak berfungsi dengan baik, dan akan menganggapnya sebagai bug uji. Akan menghabiskan banyak waktu untuk pengembangan, setelah itu ternyata fungsionalitas yang diuji telah lama dipotong, dan skrip tidak relevan. Oleh karena itu, semua skrip untuk otomatisasi harus diperiksa relevansinya.
Masalah 4: Prasyarat tidak cukup.
Keputusan:tumpukan penuh data tambahan untuk eksekusi kasus.
Penguji manual menjadi buram, dan akibatnya, saat menjelaskan prasyarat, mereka kehilangan beberapa nuansa yang jelas bagi mereka, tetapi tidak jelas bagi pembuat otomatis yang tidak begitu akrab dengan produk. Misalnya, mereka menulis: "buka halaman dengan konten yang dihitung." Mereka tahu bahwa untuk menghitung konten ini, Anda perlu menjalankan skrip kalkulasi, dan automator, yang melihat proyek untuk pertama kalinya, akan memutuskan bahwa perlu mengambil sesuatu yang sudah dihitung.
Kesimpulan: dalam prasyarat, perlu untuk menulis daftar lengkap tindakan yang harus dilakukan sebelum memulai pengujian.
Masalah 5: beberapa pemeriksaan dalam satu skenario.
Keputusan:tidak lebih dari tiga pemeriksaan per skenario (dengan pengecualian skenario yang mahal dan sulit untuk direproduksi).
Penguji manual sering kali memiliki keinginan untuk menghemat uang untuk kasus, terutama jika kasusnya berat, dan menguji sebanyak mungkin dalam satu skenario, menjejalkan lusinan tes ke dalamnya. Ini tidak boleh diizinkan, karena baik dalam pengujian manual dan otomatis, pendekatan ini menghasilkan masalah yang sama: pengujian pertama gagal, dan sisanya dianggap tidak lulus atau tidak dimulai sama sekali dalam kasus otomatisasi. Oleh karena itu, dalam skrip autotest, 1 hingga 3 pemeriksaan diperbolehkan. Pengecualian adalah skenario yang sangat sulit yang memerlukan penghitungan awal yang memakan waktu, serta skenario yang sulit untuk direproduksi. Di sini Anda dapat mengkompromikan aturan tersebut, meskipun lebih baik tidak melakukannya.
Masalah 6: pemeriksaan duplikat.
Solusi: Anda tidak perlu mengotomatiskan fungsi yang sama berulang kali.
Jika kita memiliki fungsi yang sama di beberapa halaman, misalnya, filter standar, maka tidak masuk akal untuk memeriksanya di mana-mana selama pengujian regresi, itu cukup untuk melihat di satu tempat (kecuali, tentu saja, kita berbicara tentang fitur baru). Penguji manual menulis skrip dan menguji hal-hal seperti ini di setiap halaman - hanya karena mereka melihat setiap halaman secara terpisah, tanpa masuk ke struktur internal. Tetapi para pembuat otomatis harus memahami bahwa pengujian berulang terhadap hal yang sama hanya membuang-buang waktu dan sumber daya, dan cukup mudah bagi mereka untuk mendeteksi situasi seperti itu.
Solusi dari masalah di atas memungkinkan kami mengurangi biaya pengembangan autotest sebesar 16%.
3. Sinkronisasi dengan tim produk tentang masalah refactoring, desain ulang, perubahan signifikan dalam fungsionalitas, agar tidak menulis tes "di atas meja"
Di departemen Big Data kami, di mana 13 produk dikembangkan, ada dua kelompok otomat:
- otomat langsung di tim produk;
- layanan aliran otomatisasi di luar tim produk, yang terlibat dalam pengembangan kerangka kerja dan komponen umum serta mengerjakan permintaan dari produk dengan uji fungsional yang sudah jadi.
Stream automators awalnya tidak terlalu mendalami produk, dan sebelumnya mereka tidak menghadiri rapat tim harian, karena akan menyita terlalu banyak waktu mereka. Setelah pendekatan ini mengecewakan kami: kami secara tidak sengaja mengetahui dari sumber pihak ketiga bahwa satu tim akan melakukan refaktorisasi produk mereka (memecah monolit menjadi layanan mikro), itulah sebabnya beberapa pengujian yang kami tulis dikirim ke arsip. Sangat menyakitkan.
Untuk mencegah hal ini terjadi di masa mendatang, diputuskan bahwa setidaknya seminggu sekali, seorang automator dari aliran akan datang ke rapat tim pengembangan untuk mengikuti apa yang terjadi dengan produk tersebut.
Kami juga setuju bahwa pengujian diotomatiskan hanya untuk fungsionalitas yang siap untuk produksi dan tidak sering mengalami perubahan (regresi). Kita harus yakin bahwa setidaknya dalam tiga bulan ke depan, pemfaktoran ulang atau pengerjaan ulang besar tidak akan terjadi padanya, jika tidak, para pembuat otomatis tidak akan punya waktu untuk melakukan tes.
Penghematan biaya yang dihasilkan dari penerapan langkah-langkah ini lebih sulit dihitung. Kami meluangkan waktu untuk mengembangkan pengujian otomatis sebagai dasar, yang telah kehilangan nilainya karena transisi yang direncanakan dari sebagian fungsi ke layanan mikro. Jika kita mengetahui tentang transisi ini sebelumnya, kita tidak akan menutupi fungsionalitas variabel dengan tes otomatis. Kerugian total (juga dikenal sebagai tabungan potensial) adalah 7%.
4. Mengupgrade penguji manual menjadi insinyur otomatisasi
Ada beberapa otomat uji coba di pasar tenaga kerja, terutama yang bagus, dan kami secara aktif mencari mereka. Kami juga secara aktif meningkatkan penguji manual yang ada yang memiliki keinginan dan pemahaman dasar tentang otomatisasi. Kami pertama-tama mengirim orang-orang seperti itu ke kursus dalam bahasa pemrograman, karena kami membutuhkan automator lengkap dan autotest lengkap, dan dari perekam, menurut kami, ada lebih banyak minus daripada plus.
Sejalan dengan mempelajari bahasa pemrograman, seseorang belajar menulis skrip yang benar dan terstruktur tanpa masalah dari poin 2, membaca dan menganalisis hasil laporan autotest, mengoreksi kesalahan kecil di pencari lokasi, metode sederhana, kemudian memelihara tes yang sudah jadi, dan baru kemudian menulis sendiri. Semua pengembangan berlangsung dengan dukungan kolega berpengalaman dari layanan streaming. Di masa depan, mereka dapat berpartisipasi dalam finalisasi kerangka kerja: kami memiliki perpustakaan kami sendiri, dapat diskalakan untuk semua proyek, dapat ditingkatkan dengan menambahkan sesuatu dari kami sendiri.
Arah pengurangan biaya ini masih dalam tahap awal, jadi masih terlalu dini untuk menghitung penghematan, tetapi ada banyak alasan untuk percaya bahwa pelatihan personel akan membantu mengurangi biaya operasi secara signifikan. Dan pada saat yang sama, ini akan memberikan kesempatan kepada penguji manual kami untuk berkembang.
Hasil
Sekarang kami telah mengotomatiskan sekitar 30% pengujian pada lima produk, yang telah menghasilkan pengurangan waktu pengujian regresi 2 kali lipat.
Ini adalah hasil yang baik, karena waktu sangat penting bagi kami: kami tidak dapat menguji tanpa batas waktu dan kami tidak dapat memberikan produk tanpa memeriksa; Otomatisasi, di sisi lain, memungkinkan kami untuk memberikan volume pemeriksaan produk yang diperlukan pada waktu yang optimal. Di masa mendatang, kami berencana untuk meningkatkan persentase autotest menjadi 80-90% untuk merilis rilis sesering mungkin, namun pada saat yang sama tidak mencakup project dengan autotest yang masih lebih menguntungkan untuk pengujian manual.