Kerangka Otomatisasi Tes Agile

Oleh: Thomas Hamilton Thomas Hamilton
Hours Updated

⚡ Ringkasan Cerdas

Otomatisasi pengujian Agile menerapkan pemeriksaan otomatis di dalam sprint pendek, di mana persyaratan berubah setiap minggu dan rangkaian pengujian yang dibangun untuk rilis waterfall yang stabil dengan cepat menjadi beban pemeliharaan daripada jaring pengaman.

  • 🔘 Ketegangan inti: Otomatisasi memberikan penghargaan pada stabilitas sementara Agile memberikan penghargaan pada perubahan, jadi pemilihan pengujian lebih penting daripada cakupan pengujian.
  • ☑️ Kontras air terjun: Otomatisasi tradisional mengasumsikan aplikasi yang stabil, pembuat skrip ahli, dan biaya pengaturan yang tinggi.
  • ✅ Sprint realitas: Proyek jangka pendek selama satu hingga empat minggu jarang cocok untuk mendesain, membuat kode, dan memvalidasi skrip yang besar.
  • 🧪 Tidak bersifat eksploratif: Pengujian otomatis mengkonfirmasi perilaku yang sudah diketahui; pengujian tersebut tidak menemukan cacat baru dan inovatif.
  • ️ Pilihan alat: Perangkat lunak berlisensi yang bersifat restriktif bertentangan dengan kolaborasi terbuka yang menjadi andalan tim Agile.
  • 📈 Paling cocok: Pemeriksaan regresi berulang dan padat data dengan hasil lulus atau gagal yang jelas dapat diotomatisasi dengan baik.
Baca Selengkapnya

Kerangka Otomatisasi Tes Agile

Pengujian Otomatisasi Agile

Pengujian otomatisasi Agile Automasi pengujian adalah praktik penggunaan automasi pengujian dalam proses pengiriman Agile. Tujuannya adalah untuk membuat pengembangan perangkat lunak lebih efektif dan efisien sekaligus melindungi kualitas dan mengendalikan waktu serta sumber daya yang dikonsumsi oleh sebuah rilis. Karena pengujian ditulis bersamaan dengan pengerjaan fitur, praktik ini sangat bergantung pada koordinasi antara pengembang dan penguji.

Sejak metodologi Agile berupaya menghilangkan realitas melelahkan dari model waterfall, pengaruhnya telah terasa di berbagai bidang. pengujian otomasi juga. Kedua disiplin ilmu tersebut harus digabungkan secara sengaja:

Agile ditambah otomatisasi digabungkan menjadi otomatisasi dalam Agile.

Otomatisasi dalam Waterfall vs Otomatisasi dalam Agile

Dalam siklus hidup pengujian perangkat lunak tradisional, pengujian otomatis menjadi mungkin dilakukan setelah aplikasi tersebut stabil dan persyaratannya telah ditetapkanIni mengasumsikan sebuah waktu yang cukup lama, spesialis otomatisasi yang sangat terampil, dan biaya pengaturan yang cukup besar. Tujuan utamanya adalah untuk mengurangi biaya dalam jangka panjang dan untuk memastikan bahwa tidak ada cacat baru yang muncul di sekitar kasus uji yang ada.

Pengujian otomatisasi pada dasarnya bukanlah pengujian eksploratif.Karena peran utamanya adalah menghemat waktu dan mengurangi biaya. Pengujian otomatis tidak dirancang untuk mengungkap cacat baru dan inovatif. Pengujian otomatis sebagian besar hanya mengkonfirmasi perilaku yang sudah ada.

Oleh karena itu, kedua pengaturan tersebut memberikan tuntutan yang sangat berbeda pada rangkaian pengujian:

Faktor Otomatisasi dalam model air terjun Otomatisasi dalam Agile
Status aplikasi Stabil dan disetujui sebelum penulisan skrip dimulai. Berubah setiap sprint, seringkali saat membuat skrip.
Waktu tersedia Fase otomatisasi khusus Apa pun yang sesuai dalam jangka waktu satu hingga empat minggu.
Siapa yang menulis naskah? Tim spesialis otomatisasi yang terpisah Tim pengiriman, penguji, dan pengembang bersama-sama
Tujuan utama Pengurangan biaya jangka panjang di seluruh rangkaian regresi yang besar. Umpan balik cepat pada peningkatan yang baru saja dibuat.
Risiko pemeliharaan Rendah, karena persyaratannya bergerak lambat. Tinggi, karena persyaratan terus berubah.

ARTIKEL TERKAIT

Cara Melakukan Otomatisasi dalam Metodologi Agile

Sesuai definisinya sendiri, metodologi Agile menghilangkan dokumentasi yang membosankan sehingga ide-ide baru dapat diimplementasikan dengan cepat dan orang-orang dapat berinteraksi secara bebas. Metodologi ini lebih mengutamakan pekerjaan eksploratif daripada pekerjaan administrasi:

Agile menolak dokumentasi yang membosankan dan lebih menyukai pengujian eksploratif.

Terdapat kontradiksi nyata antara filosofi dasar metodologi Agile dan pengujian otomatisasi. Tim Agile menyelesaikannya dengan mempersempit apa yang mereka otomatisasi, bukan dengan mengurangi otomatisasi: pemeriksaan ditulis dalam sprint yang sama dengan fitur, didorong ke tingkat unit dan API di mana biaya pemeliharaannya paling murah, dan dijalankan pada setiap build.

Poin Dasar untuk Otomatisasi Tes Agile

Sebelum mengalokasikan kapasitas sprint untuk otomatisasi, pertimbangkan poin-poin yang menentukan apakah sebuah skrip dapat diselesaikan sama sekali:

  • Waktu desain dan pengkodean: Setiap skrip harus dirancang, dikodekan, dan ditinjau seperti kode produksi.
  • Validasi terhadap data uji: Skrip yang sudah selesai harus divalidasi dengan data uji yang ada sebelum dapat dipercaya oleh siapa pun.
  • Tujuan tes ini: Pengujian fungsional dan regresi memiliki biaya perawatan dan masa pakai yang berbeda.
  • Sprint panjang: Satu sprint berlangsung selama satu hingga empat minggu, paling sering dua minggu, yang jarang menyisakan ruang untuk upaya penulisan skrip yang besar.

Faktor kedua adalah perubahan persyaratan. Agile, menurut definisinya, adalah teknik untuk menanggapi perubahan yang didorong oleh pelanggan, sehingga memungkinkan penyesuaian yang sering dilakukan selama pengembangan.

Sebaliknya, pengujian otomatis paling berguna untuk persyaratan yang stabil. Metode ini kurang cocok untuk perubahan konstan dalam metodologi Agile, oleh karena itu pilihan tentang apa yang akan diotomatisasi memiliki bobot lebih besar daripada jumlah yang diotomatisasi.

Alat Otomatisasi Agile

Pemilihan yang relevan alat otomatisasi Faktor penting lainnya dalam mengadopsi pengujian otomatis dalam metodologi Agile adalah penggunaan perangkat lunak otomatisasi berlisensi. Misalnya, perangkat lunak otomatisasi berlisensi memberlakukan kriteria akses keamanan yang ketat pada berbagai jenis dan tingkatan pengguna, yang membatasi siapa yang dapat mengakses sumber daya yang dimiliki oleh kerangka kerja otomatisasi pengujian tersebut.

Perangkat otomatisasi berlisensi membatasi sumber daya, sementara metodologi Agile tetap tidak terlalu membatasi.

Sebaliknya, metodologi Agile menekankan kolaborasi terbuka dan interaksi tanpa batas antar anggota tim. Kebijakan akses yang membatasi justru menghambat kohesi tersebut dan dapat menghasilkan hasil yang tidak bermanfaat atau kondusif bagi keberhasilan proyek.

Prioritasnya adalah menghasilkan skrip otomatisasi berkualitas dalam waktu yang diizinkan oleh proses Agile. Pilih kasus uji yang tepat dengan cermat, sehingga skrip yang dihasilkan dapat digunakan kembali di kemudian hari dan tetap selesai dalam waktu yang telah ditentukan.

Bahkan dalam lingkungan Agile, beberapa pengujian tetap harus dilakukan — terutama pengujian regresi. Bagian selanjutnya akan membahas situasi di mana pengujian otomatisasi cocok dan bagaimana masing-masing situasi tersebut dipetakan ke dalam pengujian Agile.

Pengujian Otomatisasi Concepts Ketika Diterapkan pada Agile

Tabel di bawah ini menyajikan tujuh kondisi klasik yang membenarkan otomatisasi pengujian dan memberikan jawaban Agile untuk masing-masing kondisi. Hanya tiga kondisi yang dapat diterjemahkan dengan jelas ke dalam sprint Agile, dan ketiganya berbentuk regresi:

# Konsep pengujian otomatisasi Jawaban metodologi Agile
1 Tes tersebut harus diulang berkali-kali. Di sinilah konsep pengujian regresi berperan.
2 Alur kerja pengujian dan validasinya berkembang dan berubah secara perlahan seiring waktu. Tidak berguna untuk pengujian Agile, karena pengujian Agile berarti seringnya perubahan persyaratan.
3 Tes ini memvalidasi proses bisnis atau alur kerja, bukan tampilan dan nuansa, warna, atau tata letak tabel. Skenario ini dapat dianggap sebagai terkait dengan pengujian manual.
4 Tes tersebut menghasilkan hasil untuk badan pengatur yang menuntut agar hasil tersebut dicatat dan diarsipkan secara elektronik sebagai bukti formal kepatuhan. Tidak cocok untuk metodologi Agile, karena dokumentasi yang lengkap bukanlah bagian dari metodologi Agile.
5 Tes tersebut sangat berulang atau memiliki banyak langkah yang harus dilakukan persis sama setiap kali, sehingga kelelahan penguji manual harus dihindari. Tidak cocok untuk metodologi Agile.
6 Hasil lulus atau gagal dari pengujian relatif mudah ditentukan dan dicatat dengan alat otomatisasi yang dipilih. Cocok untuk pengujian regresi selama pengujian Agile yang membutuhkan kemampuan berulang dan melelahkan.
7 Pengujian tersebut perlu memasukkan sejumlah besar data ke dalam aplikasi. Dapat diintegrasikan sebagai pengujian regresi.

Tujuh konsep pengujian otomatisasi yang dipasangkan dengan jawaban metodologi Agile yang sesuai.

Pertanyaan Umum Demo Slot

Aturan penataan lapisan: banyak pengujian unit cepat di bagian dasar, lebih sedikit pengujian integrasi dan API di tengah, dan lapisan tipis pengujian UI ujung-ke-ujung di atasnya. Ini menjaga agar rangkaian pengujian seukuran sprint tetap cepat dan murah untuk dipelihara.

Pemeriksaan otomatis untuk sebuah story ditulis dalam sprint yang sama dengan story tersebut. Tim biasanya memulai pengujian unit di sprint pertama, karena menunggu hingga produk cukup stabil akan menumpuk tumpukan pengujian manual yang belum selesai.

Urutkan tahapannya agar sesuai dengan piramida. Pengujian unit dijalankan terlebih dahulu karena paling cepat, kemudian pengujian integrasi dan API, lalu serangkaian pengujian end-to-end yang kecil. Kegagalan muncul pada tingkat termurah terlebih dahulu. Guru99 mencakup mekanisme dalam integrasi berkelanjutan.

Penyebab paling umum adalah piramida yang terbalik — investasi besar pada pengujian UI yang lambat dan rapuh, dan hampir tidak ada pada tingkat unit. Penyebab lainnya adalah otomatisasi yang tidak dimasukkan dalam estimasi cerita dan rangkaian pengujian yang tidak cukup dipercaya untuk menghalangi rilis.

Seluruh tim pengiriman. Pengembang bertanggung jawab atas pengujian unit, penguji bertanggung jawab atas API dan lapisan ujung-ke-ujung, dan keduanya saling meninjau pekerjaan satu sama lain. Tim otomatisasi hilir yang terpisah memperkenalkan kembali penundaan serah terima yang seharusnya dihilangkan oleh Scrum.

Pisahkan dari alur kerja yang menghambat, laporkan sebagai cacat, dan perbaiki atau hapus dalam sprint yang sama. Membiarkan pengujian yang tidak stabil dalam proses utama akan mengajarkan tim untuk mengabaikan build yang gagal, yang biayanya lebih besar daripada hilangnya cakupan pengujian.

Locator yang dapat memperbaiki diri sendiri mengidentifikasi ulang elemen yang dipindahkan dari konteksnya alih-alih gagal, yang mengurangi kegagalan yang dipicu oleh pemeliharaan. Model juga menghasilkan data uji, memprioritaskan pengujian mana yang akan dijalankan terhadap perbedaan, dan mengelompokkan kegagalan duplikat sehingga tim sprint hanya perlu melakukan triase sekali.

Sistem ini merekrut mereka dengan cepat. Kopilot GitHub Membuat kerangka objek halaman, perlengkapan, dan pernyataan dari kode yang ada, yang menghilangkan sebagian besar kerumitan.ping. RevTinjau setiap draf, karena pengujian yang dihasilkan dapat menegaskan perilaku saat ini, bukan perilaku yang dibutuhkan.

Ringkaslah postingan ini dengan: