Pengujian Agile - Panduan Cepat

Agileadalah metodologi pengembangan berulang, di mana aktivitas pengembangan dan pengujian dilakukan secara bersamaan. Pengujian bukanlah fase terpisah; Pengkodean dan Pengujian dilakukan secara interaktif dan bertahap, menghasilkan produk akhir yang berkualitas, yang memenuhi persyaratan pelanggan. Selanjutnya, hasil integrasi berkelanjutan dalam penghapusan cacat awal dan karenanya penghematan waktu, tenaga dan biaya.

Manifesto Agile

Agile Manifesto diterbitkan oleh tim pengembang perangkat lunak pada tahun 2001, menyoroti pentingnya tim pengembangan, mengakomodasi perubahan persyaratan dan keterlibatan pelanggan.

The Agile Manifesto is −

Kami menemukan cara yang lebih baik untuk mengembangkan perangkat lunak dengan melakukannya dan membantu orang lain melakukannya. Melalui pekerjaan ini, kami menjadi menghargai -

  • Individu dan interaksi atas proses dan alat.
  • Bekerja perangkat lunak di atas dokumentasi yang komprehensif.
  • Kolaborasi pelanggan melalui negosiasi kontrak.
  • Menanggapi perubahan mengikuti rencana.

Artinya, meskipun ada nilai di item di sebelah kanan, kami lebih menghargai item di sebelah kiri.

Apa itu Pengujian Agile?

Agile Testing adalah praktik pengujian perangkat lunak yang mengikuti prinsip pengembangan perangkat lunak tangkas.

Agile Testing melibatkan semua anggota tim proyek, dengan keahlian khusus yang dikontribusikan oleh penguji. Pengujian bukanlah fase terpisah dan terjalin dengan semua fase pengembangan seperti persyaratan, desain dan pengkodean, serta pembuatan kasus uji. Pengujian dilakukan secara bersamaan melalui Development Life Cycle.

Selain itu, dengan penguji berpartisipasi dalam seluruh Siklus Hidup Pengembangan dalam hubungannya dengan anggota tim lintas fungsi, kontribusi penguji untuk membangun perangkat lunak sesuai kebutuhan pelanggan, dengan desain dan kode yang lebih baik akan menjadi mungkin.

Pengujian Agile mencakup semua level pengujian dan semua jenis pengujian.

Pengujian Agile Vs. Pengujian Air Terjun

Dalam metodologi Pengembangan Waterfall, aktivitas Development Life Cycle terjadi dalam fase-fase yang berurutan. Jadi, pengujian adalah fase terpisah dan dimulai hanya setelah tahap pengembangan selesai.

Berikut ini adalah perbedaan utama antara Pengujian Agile dan Pengujian Air Terjun -

Pengujian Tangkas Pengujian Air Terjun
Pengujian bukanlah fase terpisah dan terjadi bersamaan dengan pengembangan. Pengujian adalah fase terpisah. Semua level dan jenis pengujian hanya dapat dimulai setelah pengembangan selesai.
Penguji dan pengembang bekerja sama. Penguji bekerja secara terpisah dari pengembang.
Penguji terlibat dalam menghasilkan persyaratan. Ini membantu dalam pemetaan persyaratan untuk perilaku dalam skenario dunia nyata dan juga membingkai kriteria penerimaan. Juga, Kasus Uji Penerimaan logis akan siap bersama dengan persyaratan. Penguji mungkin tidak terlibat dalam fase persyaratan.
Pengujian Penerimaan dilakukan setelah setiap iterasi dan umpan balik pelanggan dicari. Pengujian Penerimaan dilakukan hanya di akhir proyek.
Setiap iterasi menyelesaikan pengujiannya sendiri sehingga memungkinkan pengujian regresi untuk diterapkan setiap kali fungsi atau logika baru dirilis. Pengujian Regresi dapat dilaksanakan hanya setelah pembangunan selesai.
Tidak ada penundaan waktu antara pengkodean dan pengujian. Penundaan waktu biasa antara pengkodean dan pengujian.
Pengujian berkelanjutan dengan level pengujian yang tumpang tindih. Pengujian adalah aktivitas berjangka waktu dan level pengujian tidak boleh tumpang tindih.
Pengujian adalah praktik terbaik. Pengujian sering diabaikan.

Prinsip Pengujian Agile

Prinsip pengujian Agile adalah -

  • Testing moves the project forward- Pengujian berkelanjutan adalah satu-satunya cara untuk memastikan kemajuan berkelanjutan. Agile Testing memberikan umpan balik secara berkelanjutan dan produk akhir memenuhi tuntutan bisnis.

  • Testing is not a phase- Tes tim Agile bersama tim pengembangan untuk memastikan bahwa fitur yang diterapkan selama iterasi tertentu benar-benar selesai. Pengujian tidak disimpan untuk fase selanjutnya.

  • Everyone tests- Dalam pengujian tangkas, seluruh tim termasuk analis, pengembang, dan penguji menguji aplikasi. Setelah setiap iterasi, bahkan pelanggan melakukan Pengujian Penerimaan Pengguna.

  • Shortening Feedback Loops- Dalam Agile Testing, tim bisnis mengetahui pengembangan produk untuk setiap iterasi. Mereka terlibat dalam setiap iterasi. Umpan balik berkelanjutan mempersingkat waktu respons umpan balik dan dengan demikian biaya yang diperlukan untuk memperbaikinya lebih sedikit.

  • Keep the Code Clean- Cacat diperbaiki saat dibesarkan dalam iterasi yang sama. Ini memastikan kode yang bersih di setiap tonggak perkembangan.

  • Lightweight Documentation - Alih-alih dokumentasi uji komprehensif, penguji Agile -

    • Gunakan daftar periksa yang dapat digunakan kembali untuk menyarankan tes.

    • Fokus pada esensi tes daripada detail insidental.

    • Gunakan gaya / alat dokumentasi yang ringan.

    • Tangkap ide-ide uji dalam piagam untuk pengujian eksplorasi.

    • Manfaatkan dokumen untuk berbagai tujuan.

  • Leveraging one test artifact for manual and automated tests- Artefak skrip pengujian yang sama dapat digunakan untuk pengujian manual dan sebagai masukan untuk pengujian otomatis. Ini menghilangkan persyaratan Dokumentasi Tes Manual dan kemudian Skrip Tes Otomasi yang setara.

  • “Done Done,” not just done - Dalam Agile, suatu fitur dikatakan dilakukan bukan setelah pengembangan tetapi setelah pengembangan dan pengujian.

  • Test-Last vs. Test Driven- Kasus Uji ditulis bersama dengan persyaratan. Oleh karena itu, pengembangan dapat didorong oleh pengujian. Pendekatan ini disebut Test Driven Development (TDD) dan Acceptance Test Driven Development (ATDD). Ini berbeda dengan pengujian sebagai fase terakhir dalam Pengujian Air Terjun.

Aktivitas Pengujian Agile

Aktivitas Pengujian Agile di Tingkat Proyek adalah -

  • Perencanaan Rilis (Rencana Tes)

    • Untuk setiap Iterasi,

    • Aktivitas Pengujian Agile selama Iterasi

  • Pengujian Regresi

  • Aktivitas Rilis (Terkait Pengujian)

Aktivitas Pengujian Agile selama iterasi meliputi -

  • Berpartisipasi dalam perencanaan iterasi
  • Memperkirakan tugas dari tampilan pengujian
  • Menulis kasus uji menggunakan deskripsi fitur
  • Pengujian Unit
  • Tes integrasi
  • Pengujian Fitur
  • Memperbaiki Cacat
  • Tes integrasi
  • Ujian penerimaan
  • Pelaporan Status tentang Kemajuan Pengujian
  • Pelacakan Cacat

Agile adalah metodologi pengembangan berulang, di mana seluruh tim proyek berpartisipasi dalam semua aktivitas. Persyaratan berkembang seiring dengan kemajuan iterasi, melalui kolaborasi antara pelanggan dan tim yang mengatur dirinya sendiri. Karena Coding dan Pengujian dilakukan secara interaktif dan bertahap, selama pengembangan, produk akhir akan berkualitas dan memastikan persyaratan pelanggan.

Setiap iterasi menghasilkan peningkatan produk kerja yang terintegrasi dan dikirimkan untuk Pengujian Penerimaan Pengguna. Umpan balik pelanggan yang diperoleh akan menjadi masukan untuk Iterasi berikutnya / berikutnya.

Integrasi Berkelanjutan, Kualitas Berkelanjutan

Integrasi Berkelanjutan adalah kunci keberhasilan Pengembangan Agile. Integrasikan sesering mungkin, setidaknya setiap hari sehingga Anda siap untuk rilis jika diperlukan. Pengujian di Agile menjadi komponen penting dari semua fase pengembangan, memastikan kualitas produk yang berkelanjutan. Umpan balik yang konstan dari semua orang yang terlibat dalam proyek menambah kualitas produk.

Dalam Agile, komunikasi sangat penting dan permintaan pelanggan diterima jika diperlukan. Ini memberikan kepuasan kepada pelanggan bahwa semua masukan dipertimbangkan dan produk berkualitas kerja tersedia sepanjang pengembangan.

Metodologi Agile

Ada beberapa Metodologi Agile yang mendukung Agile Development. Metodologi Agile meliputi -

Scrum

Scrum adalah metode pengembangan Agile yang menekankan pada pendekatan yang berpusat pada tim. Ini menganjurkan partisipasi seluruh tim dalam semua kegiatan pengembangan proyek.

XP

Pemrograman eXtreme berpusat pada pelanggan dan berfokus pada persyaratan yang terus berubah. Dengan rilis yang sering dan umpan balik pelanggan, produk akhir akan memenuhi persyaratan pelanggan yang berkualitas yang dibuat lebih jelas selama proses.

Kristal

Crystal didasarkan pada pencarteran, pengiriman siklik dan pembungkus.

  • Pemborongan melibatkan pembentukan tim pengembangan, melakukan analisis kelayakan awal, sampai pada rencana awal dan metodologi pengembangan.

  • Pengiriman Cyclic dengan dua atau lebih siklus pengiriman berfokus pada fase pengembangan dan pengiriman produk akhir terintegrasi.

  • Selama Rangkuman, penerapan ke lingkungan pengguna, tinjauan dan refleksi pasca-penerapan dilakukan.

FDD

Feature Driven Development (FDD) melibatkan perancangan dan pembangunan fitur. Perbedaan antara FDD dan Metodologi Pengembangan Agile lainnya adalah bahwa fitur-fiturnya dikembangkan dalam fase spesifik dan pendek secara terpisah.

DSDM

Metode Pengembangan Perangkat Lunak Dinamis (DSDM) didasarkan pada Pengembangan Aplikasi Cepat (RAD) dan selaras dengan Kerangka Agile. DSDM berfokus pada pengiriman produk yang sering, melibatkan pengguna secara aktif dan memberdayakan tim untuk membuat keputusan cepat.

Pengembangan Perangkat Lunak Lean

Dalam Lean Software Development, fokusnya adalah menghilangkan pemborosan dan memberi nilai kepada pelanggan. Ini menghasilkan perkembangan pesat dan produk yang bernilai.

Pemborosan termasuk pekerjaan yang sudah selesai sebagian, pekerjaan yang tidak relevan, fitur yang tidak digunakan oleh pelanggan, cacat, dll. Yang menambah keterlambatan pengiriman.

Itu Lean Principles adalah -

  • Menghilangkan limbah
  • Perkuat Pembelajaran
  • Komitmen Tunda
  • Berdayakan Tim
  • Kirim dengan Cepat
  • Bangun Integritas dalam
  • Lihat Keseluruhan

Kanban

Kanban berfokus pada pengelolaan pekerjaan dengan penekanan pada pengiriman just-in-time (JIT), sementara tidak membebani anggota tim. Tugas ditampilkan untuk dilihat semua peserta dan Anggota Tim menarik pekerjaan dari antrian.

Kanban didasarkan pada -

  • Papan Kanban (Visual dan Persisten di Seluruh Pengembangan)
  • Batas Work-in-progress (WIP)
  • Waktu Pimpin

Metodologi Pengujian Tangkas

Praktik pengujian didefinisikan dengan baik untuk setiap proyek, apakah Agile atau tidak, untuk menghasilkan produk berkualitas. Prinsip Pengujian Tradisional cukup sering digunakan dalam Pengujian Agile. Salah satunya adalah Pengujian Awal yang berfokus pada -

  • Menulis Uji Kasus untuk mengekspresikan perilaku sistem.

  • Pencegahan, Deteksi dan Penghapusan Cacat Dini.

  • Memastikan bahwa jenis pengujian yang tepat dijalankan pada waktu yang tepat dan sebagai bagian dari level pengujian yang tepat.

Dalam semua Metodologi Agile yang kita diskusikan, Pengujian Agile itu sendiri adalah Metodologi. Dalam semua pendekatan, Kasus Uji ditulis sebelum Coding.

Dalam tutorial ini, kami akan fokus pada Scrum sebagai Metodologi Pengujian Agile.

Metodologi Pengujian Agile lainnya yang umum digunakan adalah -

  • Test-Driven Development (TDD) - Test-Driven Development (TDD) didasarkan pada pengkodean yang dipandu oleh tes.

  • Acceptance Test-Driven Development (ATDD) - Pengembangan Berbasis Tes Penerimaan (ATDD) didasarkan pada komunikasi antara pelanggan, pengembang dan penguji dan didorong oleh Kriteria Penerimaan dan Kasus Uji Penerimaan yang telah ditentukan sebelumnya.

  • Behavior-Driven Development (BDD) - Dalam pengujian Behavior-Driven Development (BDD) didasarkan pada perilaku yang diharapkan dari perangkat lunak yang sedang dikembangkan.

Siklus Hidup Pengujian Agile

Di Scrum, aktivitas Pengujian meliputi -

  • Berkontribusi ke Kisah Pengguna berdasarkan perilaku yang diharapkan dari Sistem yang digambarkan sebagai Kasus Uji

  • Perencanaan Rilis berdasarkan Upaya Uji dan Cacat

  • Perencanaan Sprint berdasarkan Kisah Pengguna dan Cacat

  • Eksekusi Sprint dengan Pengujian Berkelanjutan

  • Pengujian Regresi setelah Sprint selesai

  • Melaporkan Hasil Tes

  • Pengujian Otomasi

Pengujian itu berulang dan berdasarkan sprint seperti yang digambarkan dalam diagram yang diberikan di bawah ini -

Agile Development berpusat pada tim dan pengembang serta penguji ambil bagian dalam semua proyek dan aktivitas pengembangan. Kerja tim memaksimalkan keberhasilan pengujian dalam proyek Agile.

Tim Penguji dalam Agile harus berpartisipasi dan berkontribusi pada semua aktivitas proyek dan pada saat yang sama harus memanfaatkan keahlian dalam pengujian.

Penguji Agile harus memiliki keterampilan pengujian tradisional. Selain itu, penguji Agile membutuhkan -

  • Keterampilan interpersonal yang baik.

  • Kemampuan untuk bertindak positif dan berorientasi pada solusi dengan anggota tim dan pemangku kepentingan.

  • Kemampuan untuk menampilkan pemikiran kritis, berorientasi kualitas, dan skeptis tentang produk.

  • Bersikap proaktif untuk secara aktif memperoleh informasi dari para pemangku kepentingan.

  • Keterampilan untuk bekerja secara efektif dengan pelanggan dan pemangku kepentingan dalam menentukan Kisah Pengguna yang dapat diuji, Kriteria Penerimaan.

  • Bakat menjadi anggota tim yang baik bekerja dengan pengembang dalam menghasilkan kode kualitas.

  • Kegunaan uji keterampilan untuk memiliki kasus uji yang tepat pada waktu yang tepat dan pada tingkat yang tepat serta melaksanakannya dengan baik dalam durasi sprint.

  • Kemampuan untuk mengevaluasi dan melaporkan hasil tes, kemajuan tes dan kualitas produk.

  • Keterbukaan untuk merespons perubahan dengan cepat, termasuk mengubah, menambah, atau meningkatkan kasus uji.

  • Potensi untuk mengatur pekerjaan sendiri.

  • Antusiasme untuk terus mengembangkan keterampilan.

  • Kompetensi dalam Otomasi Tes, Pengembangan Berbasis Tes (TDD), Pengembangan Didorong Tes Penerimaan (ATDD), Pengembangan Berbasis Perilaku (BDD) dan Pengujian berbasis pengalaman.

Peran Penguji dalam Tim Agile

Penguji di Agile Team berpartisipasi dalam semua proyek dan aktivitas pengembangan untuk memberikan kontribusi terbaik dari keahlian pengujian.

Aktivitas Agile Tester meliputi -

  • Memastikan penggunaan alat pengujian yang tepat.

  • Mengonfigurasi, menggunakan, dan mengelola lingkungan pengujian dan data pengujian.

  • Mendampingi anggota tim lainnya dalam aspek pengujian yang relevan.

  • Memastikan bahwa tugas pengujian yang sesuai dijadwalkan selama rilis dan perencanaan sprint.

  • Memahami, menerapkan, dan memperbarui strategi pengujian.

  • Berkolaborasi dengan pengembang, pelanggan, dan pemangku kepentingan dalam mengklarifikasi persyaratan, dalam hal kemampuan untuk diuji, konsistensi, dan kelengkapan.

  • Melakukan pengujian yang tepat pada waktu yang tepat dan pada level pengujian yang tepat.

  • Melaporkan kerusakan dan bekerja dengan tim untuk mengatasinya.

  • Mengukur dan melaporkan cakupan pengujian di semua dimensi cakupan yang berlaku.

  • Berpartisipasi dalam retrospektif sprint, secara proaktif menyarankan dan menerapkan perbaikan.

Dalam Siklus Hidup Agile, penguji memainkan Peran penting dalam -

  • Teamwork
  • Perencanaan Tes
  • Sprint Zero
  • Integration
  • Praktik Pengujian Agile

Kerja tim

Dalam Agile Development, kerja tim sangat penting dan karenanya membutuhkan hal-hal berikut -

  • Collaborative Approach- Bekerja dengan anggota tim lintas fungsi pada Strategi Tes, Perencanaan Tes, Spesifikasi Tes, Eksekusi Tes, Evaluasi Tes, dan Pelaporan Hasil Tes. Kontribusi keahlian pengujian dalam hubungannya dengan aktivitas tim lainnya.

  • Self-organizing - Merencanakan dan mengatur dengan baik dalam sprint untuk mencapai target pengujian dengan menggabungkan keahlian dari anggota tim lainnya juga.

  • Empowerment - Membuat keputusan teknis yang tepat dalam mencapai tujuan tim.

  • Commitment - Berkomitmen untuk memahami dan mengevaluasi perilaku dan karakteristik produk sesuai kebutuhan pelanggan dan pemangku kepentingan.

  • Transparent - Terbuka, Berkomunikasi dan Bertanggung Jawab.

  • Credibility- Memastikan kredibilitas strategi pengujian, penerapannya, dan pelaksanaannya. Menjaga pelanggan dan pemangku kepentingan mendapat informasi tentang strategi pengujian.

  • Open to Feedback- Berpartisipasi dalam retrospektif sprint untuk belajar dari kesuksesan dan kegagalan. Mencari umpan balik pelanggan dan bertindak cepat dan tepat untuk memastikan hasil yang berkualitas.

  • Resilient - Menanggapi perubahan.

Perencanaan Tes

Perencanaan Tes harus dimulai selama perencanaan rilis dan pembaruan selama setiap sprint. Perencanaan tes harus mencakup tugas-tugas berikut -

  • Menentukan ruang lingkup pengujian, tingkat pengujian, pengujian, dan tujuan sprint.

  • Menentukan lingkungan pengujian, alat pengujian, data pengujian, dan konfigurasi.

  • Menetapkan pengujian fitur dan karakteristik.

  • Menjadwalkan tugas pengujian dan menentukan frekuensi pengujian.

  • Mengidentifikasi metode pengujian, teknik, alat dan data pengujian.

  • Memastikan prasyarat seperti tugas pendahulu, keahlian, dan pelatihan.

  • Mengidentifikasi ketergantungan seperti fungsi, kode, komponen sistem, vendor, teknologi, alat, aktivitas, tugas, tim, jenis pengujian, level pengujian, dan batasan.

  • Menetapkan prioritas dengan mempertimbangkan kepentingan dan ketergantungan pelanggan / pengguna.

  • Tiba pada waktu yang lama dan tenaga yang dibutuhkan untuk tes.

  • Mengidentifikasi tugas di setiap perencanaan sprint.

Sprint Zero

Sprint Zero melibatkan aktivitas persiapan sebelum sprint pertama. Penguji perlu berkolaborasi dengan tim dalam aktivitas berikut -

  • Mengidentifikasi ruang lingkup
  • Membagi cerita pengguna menjadi sprint
  • Membuat arsitektur sistem
  • Merencanakan, memperoleh, dan memasang alat (termasuk alat pengujian)
  • Membuat strategi pengujian awal untuk semua level pengujian
  • Mendefinisikan metrik pengujian
  • Menentukan kriteria penerimaan, juga disebut definisi "Selesai"
  • Mendefinisikan kriteria keluar
  • Membuat papan Scrum
  • Menetapkan arah pengujian selama sprint

Integrasi

Di Agile, produk yang berfungsi dengan baik harus siap dirilis kapan saja dalam siklus pengembangan. Ini menyiratkan integrasi berkelanjutan sebagai bagian dari pembangunan. Penguji Agile perlu mendukung integrasi berkelanjutan dengan pengujian berkelanjutan.

Untuk mencapai ini, penguji perlu -

  • Pahami strategi integrasi.
  • Identifikasi semua ketergantungan antara fungsi dan fitur.

Praktik Pengujian Agile

Penguji Agile perlu mengadaptasi praktik Agile untuk pengujian dalam proyek agile.

  • Pairing- Dua anggota tim bekerja bersama di keyboard yang sama. Sebagai salah satu dari mereka tes, review / analisis pengujian lainnya. Bisa jadi dua anggota tim

    • Satu penguji dan satu pengembang

    • Satu penguji dan satu analis bisnis

    • Dua penguji

  • Incremental Test Design - Kasus pengujian dibuat dari cerita pengguna, dimulai dengan pengujian sederhana dan beralih ke pengujian yang lebih kompleks.

  • Mind Mapping- Peta pikiran adalah diagram untuk mengatur informasi secara visual. Pemetaan pikiran dapat digunakan sebagai alat yang efektif dalam pengujian Agile, yang menggunakan informasi tentang sesi pengujian yang diperlukan, strategi pengujian, dan data pengujian yang dapat diatur.

Status Tes dapat dikomunikasikan -

  • Selama rapat stand-up harian
  • Menggunakan alat manajemen pengujian standar
  • Melalui utusan

Status tes ditentukan oleh status kelulusan tes sangat penting dalam memutuskan apakah tugas tersebut “Selesai”. Selesai berarti semua tes untuk tugas lulus.

Kemajuan Tes

Kemajuan Tes dapat dilacak menggunakan -

  • Scrum Boards (Papan Tugas Agile)
  • Grafik Burndown
  • Hasil Tes Otomatis

Kemajuan Tes juga berdampak langsung pada kemajuan pembangunan. Ini karena Kisah Pengguna dapat dipindahkan keDonestatus hanya setelah Kriteria Penerimaan tercapai. Ini, pada gilirannya, ditentukan oleh Status Tes karena Kriteria Penerimaan dinilai oleh Status Tes.

Jika ada penundaan atau penyumbatan dalam kemajuan pengujian, seluruh tim mendiskusikan dan bekerja sama untuk menyelesaikan masalah yang sama.

Dalam Agile Projects, perubahan cukup sering terjadi. Ketika banyak perubahan terjadi, kita dapat berharap bahwa Status Tes, Kemajuan Tes dan Kualitas Produk terus berkembang. Penguji Agile perlu menyampaikan informasi tersebut kepada tim sehingga keputusan yang tepat dapat dibuat pada waktu yang tepat untuk tetap berada di jalur agar berhasil menyelesaikan setiap iterasi.

Saat terjadi perubahan, perubahan tersebut dapat memengaruhi fitur yang ada dari iterasi sebelumnya. Dalam kasus seperti itu, pengujian manual dan otomatis harus diperbarui untuk menangani risiko regresi secara efektif. Pengujian regresi juga diperlukan.

Kualitas produk

Metrik Kualitas Produk meliputi -

  • Tes Lulus / Gagal
  • Cacat Ditemukan / Diperbaiki
  • Cakupan Tes
  • Tingkat Lulus / Gagal Tes
  • Tingkat Penemuan Cacat
  • Kerapatan Cacat

Mengotomatiskan pengumpulan dan pelaporan metrik kualitas produk membantu dalam -

  • Menjaga transparansi.
  • Mengumpulkan semua metrik yang relevan dan diperlukan pada waktu yang tepat.
  • Pelaporan langsung tanpa penundaan komunikasi.
  • Memungkinkan penguji untuk fokus pada pengujian.
  • Memfilter penyalahgunaan metrik.

Untuk mengamankan kualitas produk secara keseluruhan, tim Agile perlu mendapatkan umpan balik pelanggan tentang apakah produk tersebut memenuhi harapan pelanggan. Hal ini perlu dilakukan pada akhir setiap iterasi, dan umpan balik tersebut akan menjadi masukan untuk iterasi selanjutnya.

Faktor Kunci Sukses

Dalam proyek Agile, produk berkualitas dapat dikirimkan jika pengujian Agile berhasil.

Poin-poin berikut perlu dipertimbangkan untuk keberhasilan pengujian Agile -

  • Pengujian tangkas didasarkan pada pengujian pertama dan pendekatan pengujian berkelanjutan. Oleh karena itu, alat pengujian tradisional, yang dibangun dengan pendekatan uji-terakhir, mungkin tidak cocok. Oleh karena itu, saat memilih Alat Pengujian dalam proyek Agile, keselarasan dengan pengujian Agile perlu diverifikasi.

  • Kurangi total waktu pengujian dengan mengotomatiskan pengujian lebih awal dalam siklus hidup pengembangan.

  • Penguji yang gesit perlu mempertahankan kecepatan mereka agar sesuai dengan jadwal rilis pengembangan. Oleh karena itu, perencanaan yang tepat, pelacakan, dan perencanaan ulang kegiatan pengujian perlu dilakukan dengan cepat dengan kualitas produk sebagai tujuan.

  • Pengujian manual menyumbang 80% dari pengujian dalam proyek. Oleh karena itu, penguji dengan keahlian harus menjadi bagian dari tim Agile.

  • Partisipasi para penguji ini dengan keahlian selama siklus hidup pengembangan membuat seluruh tim fokus pada kualitas produk yang memenuhi harapan pelanggan.

    • Mendefinisikan cerita pengguna yang menekankan perilaku produk yang diharapkan oleh pengguna akhir.

    • Mengidentifikasi Kriteria Penerimaan di tingkat cerita / tugas pengguna sesuai harapan pelanggan.

    • Estimasi usaha dan durasi untuk kegiatan pengujian.

    • Merencanakan kegiatan pengujian.

    • Selaras dengan tim pengembangan untuk memastikan produksi kode yang memenuhi persyaratan dengan desain pengujian di muka.

    • Uji pertama dan pengujian berkelanjutan untuk memastikan bahwa status selesai tercapai memenuhi kriteria penerimaan pada waktu yang diharapkan.

    • Memastikan pengujian di semua level dalam sprint.

    • Pengujian regresi di akhir setiap sprint.

    • Mengumpulkan dan menganalisis metrik produk yang berguna untuk keberhasilan proyek.

    • Menganalisis cacat untuk mengidentifikasi mana yang perlu diperbaiki dalam Sprint saat ini dan mana yang dapat ditunda ke Sprint berikutnya.

    • Berfokus pada apa yang penting dari sudut pandang Pelanggan.

Lisa Crispin telah menetapkan tujuh Faktor kunci untuk Keberhasilan Pengujian Agile -

  • Whole Team approach- Dalam pendekatan semacam ini, pengembang melatih penguji dan penguji melatih anggota tim lainnya. Ini membantu setiap orang untuk memahami setiap tugas dalam proyek, dengan demikian kolaborasi dan kontribusi akan memberikan manfaat yang maksimal. Kolaborasi penguji dengan pelanggan juga merupakan faktor penting untuk menetapkan ekspektasi mereka sejak awal dan menerjemahkan kriteria penerimaan menjadi persyaratan untuk lulus ujian.

  • Agile Testing Mindset - Penguji proaktif dalam terus meningkatkan kualitas dan terus berkolaborasi dengan anggota tim lainnya.

  • Automate Regression Testing- Desain untuk kemampuan pengujian dan pengembangan penggerak dengan pengujian. Mulailah dengan sederhana dan biarkan tim memilih alat. Bersiaplah untuk memberikan nasihat.

  • Provide and Obtain Feedback- Karena ini adalah nilai inti Agile, seluruh tim harus terbuka untuk menerima umpan balik. Karena penguji adalah penyedia umpan balik ahli, perlu fokus pada informasi yang relevan dan diperlukan. Sebagai imbalannya, untuk mendapatkan umpan balik harus mengakomodasi perubahan kasus uji dan pengujian.

  • Build a Foundation of Core Agile Practices - Fokus pada pengujian bersama pengkodean, integrasi berkelanjutan, lingkungan pengujian kolaboratif, bekerja secara bertahap, penerimaan perubahan, menjaga sinergi.

  • Collaborate with Customers - Memperoleh contoh, memahami, dan memeriksa pemetaan persyaratan untuk perilaku produk, menyiapkan Kriteria Penerimaan, mendapatkan umpan balik.

  • Look at the Big Picture - Mendorong pengembangan dengan pengujian dan contoh yang dihadapi bisnis menggunakan data pengujian dunia nyata dan memikirkan dampaknya pada area lain.

Dalam bab ini, kita akan melihat beberapa atribut penting dari Pengujian Agile.

Manfaat Pengujian Agile

Manfaat pengujian Agile adalah -

  • Kepuasan pelanggan dengan produk yang cepat, terus menerus diuji sepenuhnya dan mencari umpan balik pelanggan.

  • Pelanggan, pengembang, dan penguji terus berinteraksi satu sama lain, sehingga mengurangi waktu siklus.

  • Penguji yang tangkas berpartisipasi dalam menentukan persyaratan yang berkontribusi pada keahlian pengujian mereka untuk fokus pada apa yang bisa diterapkan.

  • Penguji tangkas berpartisipasi dalam estimasi menilai upaya dan waktu pengujian.

  • Desain tes awal yang mencerminkan Kriteria Penerimaan.

  • Persyaratan pengujian dikonsolidasikan oleh seluruh tim, menghindari kekurangan.

  • Fokus konstan pada kualitas produk oleh seluruh tim.

  • Definisi Done status yang mencerminkan tes lulus memastikan bahwa persyaratan terpenuhi.

  • Umpan balik yang berkelanjutan tentang penundaan atau penyumbatan sehingga penyelesaian dapat segera dilakukan dengan upaya dari seluruh tim.

  • Respon cepat untuk mengubah persyaratan dan segera mengakomodasi mereka.

  • Pengujian regresi yang didorong integrasi berkelanjutan.

  • Tidak ada penundaan waktu antara pengembangan dan pengujian. uji pertama, pendekatan pengujian berkelanjutan diikuti.

  • Pengujian otomatisasi diterapkan di awal siklus hidup pengembangan, sehingga mengurangi total waktu dan upaya pengujian.

Praktik Terbaik dalam Pengujian Agile

Ikuti praktik terbaik yang diberikan di bawah ini -

  • Penyertaan penguji dengan keahlian dalam semua jenis pengujian di semua tingkatan.

  • Penguji berpartisipasi dalam definisi persyaratan, berkolaborasi dengan pelanggan tentang perilaku produk yang diharapkan.

  • Penguji terus berbagi umpan balik dengan pengembang dan pelanggan.

  • Uji pendekatan pengujian pertama dan berkelanjutan untuk menyelaraskan dengan pekerjaan pengembangan.

  • Melacak status pengujian dan kemajuan pengujian dengan cepat dan konstan dengan fokus pada menghasilkan produk berkualitas.

  • Pengujian otomatisasi di awal siklus hidup pengembangan untuk mengurangi waktu siklus.

  • Untuk melakukan Pengujian Regresi memanfaatkan Pengujian Otomasi sebagai cara yang efektif.

Tantangan dalam Pengujian Agile

Tantangan berikut ada dalam pengujian Agile -

  • Kegagalan untuk memahami pendekatan Agile dan batasannya oleh Bisnis dan Manajemen dapat menyebabkan ekspektasi yang tidak dapat dicapai.

  • Agile mengikuti pendekatan seluruh Tim, tetapi tidak semua orang mengetahui inti dari Praktik Pengujian. Penguji disarankan untuk melatih yang lain, tetapi dalam skenario nyata dapat menjadi tidak praktis dengan Sprint yang dibatasi waktu (Iterasi).

  • Uji Pendekatan Pertama mengharuskan Pengembang untuk mendasarkan pengkodean pada Umpan Balik Penguji, tetapi dalam skenario nyata, Pengembang lebih terbiasa mendasarkan pengkodean pada Persyaratan yang berasal dari Pelanggan atau Bisnis.

  • Akuntabilitas untuk Kualitas Produk ada pada seluruh Tim Tangkas, tetapi pada tahap awal Pengembang tidak boleh Fokus pada Kualitas karena mereka lebih ke mode implementasi.

  • Integrasi Berkelanjutan memerlukan Pengujian Regresi yang memerlukan banyak upaya, bahkan jika harus otomatis.

  • Penguji dapat beradaptasi dengan perubahan dengan pola pikir Agile, tetapi mengakomodasi Perubahan dan Pengujian Tes yang dihasilkan dapat menjadi tidak praktis untuk menargetkan untuk diselesaikan selama Sprint.

  • Otomatisasi Awal disarankan agar Upaya dan Waktu Pengujian Manual dapat dikurangi. Namun, dalam skenario nyata, mencapai Tes yang dapat diotomatiskan dan mengotomatiskannya membutuhkan Waktu dan Upaya.

Pedoman Pengujian Tangkas

Gunakan panduan berikut saat melakukan Pengujian Agile.

  • Berpartisipasi dalam Perencanaan Rilis untuk mengidentifikasi aktivitas Pengujian yang diperlukan dan menghasilkan versi awal rencana pengujian.

  • Berpartisipasi dalam sesi estimasi untuk sampai pada upaya dan durasi pengujian sehingga aktivitas pengujian diakomodasi dalam iterasi.

  • Berpartisipasi dalam Definisi Cerita Pengguna untuk sampai pada Kasus Uji Penerimaan.

  • Berpartisipasi dalam setiap Rapat Perencanaan Sprint untuk memahami ruang lingkup dan memperbarui Rencana Tes.

  • Berkolaborasi secara terus menerus dengan Tim Pengembang selama Sprint untuk membuat Pengujian dan Pengkodean sukses dalam Sprint.

  • Berpartisipasilah dalam Stand-up Meeting Harian dan sampaikan Penundaan Tes atau Pemblokiran jika ada, untuk mendapatkan penyelesaian segera.

  • Lacak dan Laporkan Status Uji, Kemajuan Uji, dan Kualitas Produk secara teratur.

  • Bersiaplah untuk mengakomodasi perubahan, menanggapi dengan modifikasi Kasus Uji, Data Uji.

  • Berpartisipasilah dalam Sprint Retrospectives untuk memahami dan menyumbangkan Praktik Terbaik dan Pelajaran yang Dipetik.

  • Berkolaborasi untuk mendapatkan Umpan Balik Pelanggan di setiap Sprint.

Seperti dalam kasus Pengujian Tradisional, Pengujian Agile juga harus mencakup semua Level Pengujian.

  • Pengujian Unit
  • Tes integrasi
  • Pengujian Sistem
  • Pengujian Penerimaan Pengguna

Pengujian Unit

  • Selesai bersama dengan Coding, oleh Pengembang
  • Didukung oleh Penguji yang menulis Kasus Uji memastikan Cakupan Desain 100%
  • Kasus Uji Unit dan hasil Uji Unit perlu ditinjau
  • Cacat besar yang tidak terselesaikan (sesuai prioritas dan tingkat keparahan) tidak tersisa
  • Semua Tes Unit otomatis

Tes integrasi

  • Dilakukan bersamaan dengan Integrasi Berkelanjutan seiring kemajuan Sprint
  • Selesai di akhir setelah semua Sprint selesai
  • Semua Persyaratan Fungsional diuji
  • Semua Antarmuka antar Unit diuji
  • Semua Cacat Dilaporkan
  • Tes diotomatiskan jika memungkinkan

Pengujian Sistem

  • Selesai saat Pengembangan berlangsung
  • Kisah Pengguna, Fitur, dan Fungsi Diuji
  • Pengujian dilakukan di Lingkungan Produksi
  • Uji Kualitas dijalankan (Kinerja, Keandalan, dll.)
  • Cacat dilaporkan
  • Tes diotomatiskan jika memungkinkan

Pengujian Penerimaan Pengguna

  • Selesai di akhir setiap Sprint dan di akhir proyek

  • Dilakukan oleh Pelanggan. Umpan balik diambil oleh Tim

  • Umpan balik akan menjadi masukan untuk Sprint berikutnya

  • Kisah Pengguna dalam Sprint telah diverifikasi sebelumnya agar dapat diuji dan dengan Kriteria Penerimaan yang ditentukan

Jenis Tes

  • Tes Komponen (Tes Unit)
  • Tes Fungsional (Tes Cerita Pengguna)
  • Tes Non-fungsional (Performa, Beban, Stres, dll.)
  • Tes Penerimaan

Tes dapat sepenuhnya Manual, Otomatis penuh, Kombinasi Manual dan Otomatis atau Manual didukung oleh Alat.

Mendukung Tes Produk Pemrograman dan Kritik

Tes bisa untuk -

  • Supporting Development (Support Programming) - Tes Pemrograman Dukungan digunakan oleh Pemrogram.

    • Untuk memutuskan kode apa yang perlu mereka tulis untuk mencapai perilaku tertentu dari Sistem

    • Tes apa yang perlu dijalankan setelah Coding untuk memastikan Kode baru tidak menghambat perilaku Sistem lainnya

  • Verification only (Critique Product) - Tes Produk Kritik digunakan untuk menemukan kekurangan dalam Produk jadi

Menghadapi Bisnis dan Tes Menghadapi Teknologi

Untuk memutuskan tes apa yang akan dilakukan kapan, Anda perlu menentukan apakah tes itu -

  • Menghadapi Bisnis, atau
  • Menghadapi Teknologi

Tes Menghadapi Bisnis

Tes adalah tes bisnis jika menjawab pertanyaan yang dibingkai dengan kata-kata dari domain bisnis. Ini dipahami oleh pakar bisnis dan akan menarik minat mereka sehingga perilaku sistem dapat dijelaskan dalam skenario waktu nyata.

Teknologi Menghadapi Tes

Tes adalah tes yang berhubungan dengan teknologi jika menjawab pertanyaan yang dibingkai dengan kata-kata dari domain teknologi. Pemrogram memahami apa yang perlu diterapkan berdasarkan klarifikasi tentang teknologi.

Kedua aspek jenis pengujian ini dapat dilihat dengan menggunakan Agile Testing Quadrants yang ditentukan oleh Brian Marick.

Kuadran Pengujian Agile

Menggabungkan dua aspek Jenis Pengujian, Kuadran Pengujian Agile berikut ini diturunkan oleh Brian Marick -

Agile Testing Quadrants memberikan taksonomi yang berguna untuk membantu tim mengidentifikasi, merencanakan, dan melaksanakan pengujian yang diperlukan.

  • Quadrant Q1- Tingkat Unit, Menghadapi Teknologi, dan mendukung pengembang. Tes unit termasuk dalam Kuadran ini. Tes ini dapat berupa tes Otomatis.

  • Quadrant Q2- Tingkat sistem, bisnis yang dihadapi, dan perilaku produk yang sesuai. Tes fungsional termasuk dalam kuadran ini. Tes ini dapat dilakukan secara manual atau otomatis.

  • Quadrant Q3- Sistem atau Tingkat Penerimaan Pengguna, Menghadapi Bisnis dan fokus pada skenario waktu nyata. Tes Penerimaan Pengguna termasuk dalam kuadran ini. Tes ini manual.

  • Quadrant Q4- Sistem atau Tingkat Penerimaan Operasional, Teknologi Menghadapi dan Fokus pada Kinerja, Beban, Stres, Pemeliharaan, Tes Skalabilitas. Alat khusus dapat digunakan untuk pengujian ini bersama dengan pengujian otomatisasi.

Menggabungkan ini, Kuadran Pengujian Agile yang mencerminkan What-Testing-When dapat divisualisasikan sebagai berikut -

Pendukung Scrum Whole Team Approach, dalam arti setiap anggota tim harus mengikuti setiap kegiatan proyek. Tim scrum mengatur dirinya sendiri dengan akuntabilitas terhadap hasil proyek. Pengambilan keputusan diserahkan kepada tim yang menghasilkan tindakan yang tepat diambil pada waktu yang tepat tanpa penundaan waktu. Pendekatan ini juga mendorong penggunaan bakat tim secara tepat alih-alih membatasi pada satu aktivitas. Penguji juga berpartisipasi dalam semua proyek dan kegiatan pengembangan yang memberikan kontribusi keahlian mereka dalam pengujian.

Seluruh tim bekerja sama dalam Strategi Tes, Perencanaan Tes, Spesifikasi Tes, Pelaksanaan Tes, Evaluasi Tes, dan Pelaporan Hasil Tes.

Pembuatan Cerita Pengguna Kolaboratif

Penguji berpartisipasi dalam Pembuatan Cerita Pengguna. Penguji menyumbangkan ide mereka tentang kemungkinan perilaku sistem. Hal ini membantu pelanggan dan / atau pengguna akhir memahami sistem di lingkungan nyata dan dengan demikian mendapatkan kejelasan tentang apa yang sebenarnya mereka inginkan sebagai hasil. Hal ini menghasilkan pembekuan persyaratan yang lebih cepat dan juga mengurangi kemungkinan perubahan persyaratan di kemudian hari.

Penguji juga menghasilkan Kriteria Penerimaan untuk setiap skenario yang disepakati oleh pelanggan.

Penguji berkontribusi pada pembuatan cerita pengguna yang dapat diuji.

Perencanaan Rilis

Perencanaan Rilis dilakukan untuk seluruh proyek. Namun, kerangka kerja Scrum melibatkan pengambilan keputusan yang berulang karena lebih banyak informasi yang diperoleh seiring dengan pelaksanaan sprint. Oleh karena itu, sesi Perencanaan Rilis di awal proyek tidak perlu menghasilkan rencana rilis terperinci untuk keseluruhan proyek. Itu dapat diperbarui terus menerus, karena informasi yang relevan tersedia.

Setiap sprint-end tidak perlu memiliki rilis. Sebuah rilis bisa dilakukan setelah sekelompok sprint. Kriteria utama sebuah rilis adalah menyampaikan nilai bisnis kepada pelanggan. Tim memutuskan panjang sprint dengan masukan perencanaan rilis.

Perencanaan Rilis adalah dasar dari pendekatan pengujian dan rencana pengujian untuk rilis. Penguji memperkirakan Upaya Uji dan merencanakan Pengujian untuk rilis. Ketika rencana rilis berubah, penguji harus menangani perubahan, mendapatkan dasar pengujian yang memadai dengan mempertimbangkan konteks rilis yang lebih luas. Penguji juga memberikan upaya pengujian yang diperlukan di akhir semua sprint.

Perencanaan Sprint

Perencanaan sprint dilakukan di awal setiap sprint. Sprint backlog dibuat dengan cerita pengguna yang diambil dari product backlog untuk diterapkan di sprint tersebut.

Penguji harus -

  • Tentukan testabilitas cerita pengguna yang dipilih untuk sprint
  • Buat tes penerimaan
  • Tentukan level tes
  • Identifikasi otomatisasi pengujian

Penguji memperbarui rencana pengujian dengan perkiraan upaya pengujian dan durasi dalam sprint. Hal ini memastikan penyediaan waktu untuk pengujian yang diperlukan selama sprint yang dibatasi waktu dan juga akuntabilitas upaya pengujian.

Analisis Tes

Saat sprint dimulai, saat pengembang melakukan analisis cerita untuk desain dan implementasi, penguji melakukan analisis uji untuk cerita di sprint backlog. Penguji membuat kasus pengujian yang diperlukan - baik pengujian manual maupun otomatis.

Menguji

Semua anggota tim Scrum harus berpartisipasi dalam pengujian.

  • Pengembang menjalankan pengujian unit saat mereka mengembangkan kode untuk cerita pengguna. Tes Unit dibuat di setiap sprint, sebelum kode ditulis. Kasus uji unit berasal dari spesifikasi desain tingkat rendah.

  • Penguji melakukan fitur fungsional dan non-fungsional dari cerita pengguna.

  • Penguji mendampingi anggota tim scrum lainnya dengan keahliannya dalam melakukan pengujian sehingga seluruh tim memiliki akuntabilitas kolektif atas kualitas produk.

  • Di akhir sprint, pelanggan dan / atau pengguna akhir melakukan Pengujian Penerimaan Pengguna dan memberikan umpan balik kepada tim scrum. Bentuk ini sebagai masukan untuk sprint berikutnya.

  • Hasil tes dikumpulkan dan dipelihara.

Pengujian Otomasi

Pengujian otomasi sangat penting dalam tim Scrum. Penguji mencurahkan waktu dalam membuat, menjalankan, memantau, dan memelihara pengujian dan hasil otomatis. Karena perubahan dapat terjadi kapan saja dalam proyek scrum, penguji perlu mengakomodasi pengujian fitur yang diubah dan juga pengujian regresi yang terlibat. Pengujian otomatisasi memfasilitasi pengelolaan upaya pengujian yang terkait dengan perubahan. Tes otomatis di semua tingkatan memfasilitasi pencapaian integrasi berkelanjutan. Pengujian otomatis berjalan jauh lebih cepat daripada pengujian manual tanpa upaya tambahan.

Pengujian manual lebih berfokus pada pengujian eksplorasi, kerentanan produk, memprediksi cacat.

Otomatisasi Aktivitas Pengujian

Otomatisasi aktivitas pengujian mengurangi beban pekerjaan berulang dan menghasilkan penghematan biaya. Mengotomatisasikan

  • Uji Pembuatan Data
  • Uji Pemuatan Data
  • Bangun Deployment ke dalam Lingkungan Pengujian
  • Uji Manajemen Lingkungan
  • Perbandingan Output Data

Pengujian Regresi

Dalam sprint, penguji menguji kode yang baru / dimodifikasi dalam sprint tersebut. Namun, penguji juga perlu memastikan bahwa kode yang dikembangkan dan diuji di sprint sebelumnya juga berfungsi bersama dengan kode baru. Oleh karena itu, pengujian Regresi sangat penting dalam scrum. Uji regresi otomatis dijalankan dalam integrasi berkelanjutan.

Manajemen konfigurasi

Sistem manajemen konfigurasi yang menggunakan kerangka kerja uji dan build otomatis digunakan dalam proyek Scrum. Hal ini memungkinkan untuk menjalankan analisis statis dan pengujian unit berulang kali saat kode baru diperiksa ke Sistem Manajemen Konfigurasi. Itu juga mengelola integrasi berkelanjutan dari kode baru dengan sistem. Tes Regresi Otomatis dijalankan selama Integrasi Berkelanjutan.

Kasus Uji Manual, Pengujian Otomatis, Data Uji, Rencana Uji, Strategi Uji, dan Artefak Pengujian lainnya perlu Dikontrol Versi dan memerlukan Izin Akses yang relevan untuk dipastikan. Ini dapat dilakukan dengan mempertahankan Artefak Pengujian di Sistem Manajemen Konfigurasi.

Praktik Pengujian Agile

Penguji dalam Tim Scrum dapat mengikuti Praktik Agile berikut -

  • Pairing- Dua Anggota Tim duduk bersama dan bekerja sama. Kedua orang tersebut dapat menjadi dua Penguji atau satu Penguji dan satu Pengembang.

  • Incremental Test Design - Test Case dikembangkan saat Sprint berkembang secara bertahap dan User Stories ditambahkan.

Metrik Agile

Selama pengembangan perangkat lunak, pengumpulan dan analisis metrik membantu meningkatkan proses dan dengan demikian mencapai produktivitas yang lebih baik, hasil yang berkualitas, dan kepuasan pelanggan. Dalam pengembangan berbasis Scrum, hal ini dimungkinkan dan penguji harus memperhatikan metrik yang mereka perlukan.

Beberapa metrik disarankan untuk pengembangan Scrum. Metrik penting adalah -

  • Ratio of Successful Sprints - (Number of successful Sprints / Total number of Sprints) * 100. Sprint yang Berhasil adalah yang membuat Tim dapat memenuhi komitmennya.

  • Velocity- Kecepatan tim didasarkan pada jumlah Poin Cerita yang diperoleh tim selama sprint. Poin Cerita adalah ukuran Cerita Pengguna yang dihitung selama estimasi.

  • Focus Factor - (Velocity / Team’s Work Capacity) / 100. Faktor Fokus adalah persentase usaha tim yang menghasilkan cerita yang sudah selesai.

  • Estimation Accuracy - (Estimated effort / Actual effort) / 100. Akurasi Estimasi adalah kemampuan Tim dalam memperkirakan upaya secara akurat.

  • Sprint Burndown- Pekerjaan (dalam Poin Cerita atau dalam jam) yaitu Sisa Vs. Pekerjaan yang perlu Tersisa idealnya (sesuai Estimasi).

    • Jika lebih, maka itu berarti bahwa Tim telah melakukan lebih banyak Pekerjaan daripada yang dapat mereka lakukan.

    • Jika kurang, berarti Tim tidak melakukan Estimasi secara akurat.

  • Defect Count- Jumlah cacat dalam Sprint. Jumlah kerusakan adalah jumlah kerusakan dalam perangkat lunak dibandingkan dengan backlog.

  • Severity of Defects- Cacat dapat dikategorikan sebagai minor, mayor dan kritis sesuai dengan tingkat keparahannya. Penguji dapat menentukan kategorisasi.

Sprint Retrospective

Dalam Sprint Retrospectives, semua anggota tim akan berpartisipasi. Mereka berbagi -

  • Hal-hal yang berjalan dengan baik
  • Metrics
  • Ruang lingkup untuk perbaikan
  • Item tindakan untuk diterapkan

Dalam Pengujian Agile, metode Pengujian yang umum digunakan berasal dari praktik tradisional dan sejalan dengan prinsip - Uji Awal. Kasus Uji ditulis sebelum kode ditulis. Penekanannya adalah pada pencegahan cacat, deteksi, dan penghapusan dengan menjalankan jenis pengujian yang tepat pada waktu dan tingkat yang tepat.

Dalam bab ini, Anda akan mendapatkan pemahaman tentang metode -

  • Test Driven Development (TDD)
  • Pengembangan Didorong Tes Penerimaan (ATDD)
  • Behavior Driven Development (BDD)

Pengembangan Berbasis Tes

Dalam metode Test Driven Development (TDD), kode dikembangkan berdasarkan pendekatan Testfirst yang diarahkan oleh Kasus Uji Otomatis. Kasus uji ditulis pertama kali gagal, kode dikembangkan berdasarkan itu untuk memastikan bahwa uji lulus. Metode diulangi, refactoring dilakukan melalui pengembangan kode.

TDD dapat dipahami dengan bantuan langkah-langkah berikut -

  • Step 1 - Tulis kasus Uji untuk mencerminkan perilaku yang diharapkan dari fungsionalitas kode yang perlu ditulis.

  • Step 2- Jalankan tesnya. Tes gagal karena kodenya masih belum dikembangkan.

  • Step 3 - Kembangkan kode berdasarkan kasus uji.

  • Step 4- Jalankan tes lagi. Kali ini, pengujian harus lulus karena fungsionalitasnya dikodekan. Ulangi Langkah (3) dan Langkah (4) hingga tes berhasil.

  • Step 5 - Refactor kodenya.

  • Step 6 - Jalankan tes lagi untuk memastikan lulus.

Ulang Step 1 – Step 6menambahkan kasus uji untuk menambahkan fungsionalitas. Tes tambahan dan tes sebelumnya dijalankan setiap saat untuk memastikan kode berjalan seperti yang diharapkan. Untuk mempercepat proses ini, pengujian dilakukan secara otomatis.

Pengujian dapat dilakukan pada unit, integrasi, atau tingkat sistem. Komunikasi yang konstan antara penguji dan pengembang perlu dipastikan.

Pengembangan Didorong Uji Penerimaan

Dalam metode Acceptance Test Driven Development (ATDD), kode dikembangkan berdasarkan pendekatan uji pertama yang diarahkan oleh Kasus Uji Penerimaan. Fokusnya adalah pada kriteria penerimaan dan Kasus Uji Penerimaan yang ditulis oleh penguji selama Pembuatan Cerita Pengguna bekerja sama dengan pelanggan, pengguna akhir, dan pemangku kepentingan terkait.

  • Step 1 - Menulis Uji Penerimaan Kasus bersama dengan cerita pengguna bekerja sama dengan pelanggan dan pengguna.

  • Step 2 - Tentukan kriteria penerimaan terkait.

  • Step 3 - Kembangkan kode berdasarkan tes penerimaan dan kriteria penerimaan.

  • Step 4 - Jalankan tes penerimaan untuk memastikan bahwa kode berjalan seperti yang diharapkan.

  • Step 5- Mengotomatiskan tes penerimaan. UlangStep 3 – Step 5 hingga semua cerita pengguna dalam iterasi diterapkan.

  • Step 6 - Otomatiskan uji regresi.

  • Step 7 - Jalankan Tes Regresi otomatis untuk memastikan Regresi Berkelanjutan.

Behavior Driven Development (BDD)

Behavior Driven Development (BDD) mirip dengan Test Driven Development (TDD), dan fokusnya adalah pada pengujian kode untuk memastikan perilaku yang diharapkan dari sistem.

Dalam BDD, bahasa seperti bahasa Inggris digunakan sehingga masuk akal bagi pengguna, penguji, dan pengembang. Ini memastikan -

  • Komunikasi berkelanjutan antara pengguna, penguji, dan pengembang.
  • Transparansi tentang apa yang sedang dikembangkan dan diuji.

Teknik Pengujian dari pengujian tradisional juga dapat digunakan dalam pengujian Agile. Selain itu, teknik dan terminologi pengujian spesifik Agile digunakan dalam proyek Agile.

Dasar Tes

Dalam proyek agile, backlog produk menggantikan dokumen spesifikasi persyaratan. Isi product backlog biasanya adalah cerita pengguna. Persyaratan non-fungsional juga diperhatikan dalam cerita pengguna. Jadi, dasar pengujian dalam proyek Agile adalah cerita pengguna.

Untuk memastikan pengujian kualitas, berikut ini juga dapat dianggap sebagai dasar pengujian -

  • Pengalaman dari iterasi sebelumnya dari proyek yang sama atau proyek sebelumnya.
  • Fungsi, arsitektur, desain, kode, dan karakteristik kualitas sistem yang ada.
  • Cacat data dari proyek saat ini dan masa lalu.
  • Timbal balik pelanggan.
  • Dokumentasi pengguna.

Definisi Selesai

Definisi Selesai (DoD) adalah kriteria yang digunakan dalam proyek Agile untuk memastikan penyelesaian suatu aktivitas di sprint backlog. DoD dapat bervariasi dari satu tim Scrum ke yang lain, tetapi harus konsisten dalam satu tim.

DoD adalah daftar periksa aktivitas yang diperlukan yang memastikan implementasi fungsi dan fitur dalam cerita pengguna bersama dengan persyaratan non-fungsional yang merupakan bagian dari cerita pengguna. Kisah pengguna mencapai tahap Selesai setelah semua item di daftar periksa DoD diselesaikan. DoD dibagikan ke seluruh tim.

DoD khas untuk cerita pengguna dapat berisi -

  • Kriteria Penerimaan Terperinci yang Dapat Diuji
  • Kriteria untuk memastikan konsistensi Kisah Pengguna dengan yang lain di Iterasi
  • Kriteria Khusus terkait Produk
  • Aspek Perilaku Fungsional
  • Karakteristik non-fungsional
  • Interfaces
  • Uji Persyaratan Data
  • Cakupan Tes
  • Refactoring
  • Persyaratan Review dan Persetujuan

Selain DoD untuk Kisah Pengguna, DoD juga diperlukan -

  • di setiap Tingkat Pengujian
  • untuk setiap Fitur
  • untuk setiap Iterasi
  • untuk Rilis

Informasi Tes

Seorang penguji harus memiliki informasi Tes berikut -

  • Kisah Pengguna yang perlu diuji
  • Kriteria Penerimaan Terkait
  • Antarmuka Sistem
  • Lingkungan dimana Sistem diharapkan untuk Bekerja
  • Ketersediaan alat
  • Cakupan Tes
  • DoD

Dalam proyek Agile, karena pengujian bukanlah aktivitas berurutan dan penguji diharapkan bekerja dalam mode kolaboratif, itu adalah tanggung jawab penguji untuk -

  • Dapatkan informasi pengujian yang diperlukan secara berkelanjutan.
  • Identifikasi celah informasi yang mempengaruhi pengujian.
  • Selesaikan kesenjangan secara kolaboratif dengan anggota tim lainnya.
  • Tentukan kapan level tes tercapai.
  • Pastikan pengujian yang sesuai dilaksanakan pada waktu yang relevan.

Desain Uji Fungsional dan Non Fungsional

Dalam proyek Agile, teknik pengujian tradisional dapat digunakan, tetapi fokusnya adalah pada pengujian awal. Kasus pengujian harus ada sebelum implementasi dimulai.

Untuk desain pengujian Fungsional, penguji dan pengembang dapat menggunakan teknik desain pengujian Kotak Hitam tradisional seperti -

  • Partisi Ekuivalensi
  • Analisis Nilai Batas
  • Tabel Keputusan
  • Transisi Negara
  • Pohon Kelas

Untuk desain pengujian non-fungsional, karena persyaratan non-fungsional juga merupakan bagian dari setiap kisah pengguna, teknik desain pengujian kotak hitam hanya dapat digunakan untuk merancang kasus pengujian yang relevan.

Pengujian Eksplorasi

Dalam proyek Agile, waktu sering menjadi faktor pembatas untuk Analisis Uji dan Desain Uji. Dalam kasus seperti itu, teknik pengujian Eksplorasi dapat digabungkan dengan teknik pengujian tradisional.

Exploratory Testing (ET) didefinisikan sebagai pembelajaran simultan, desain tes dan eksekusi tes. Dalam Pengujian Eksplorasi, penguji secara aktif mengontrol desain pengujian saat dilakukan dan menggunakan informasi yang diperoleh saat pengujian untuk merancang pengujian baru dan lebih baik.

Pengujian Eksplorasi berguna untuk mengakomodasi perubahan dalam proyek Agile.

Pengujian Berbasis Risiko

Pengujian berbasis risiko adalah pengujian berdasarkan risiko kegagalan dan memitigasi risiko menggunakan teknik desain pengujian.

Risiko kualitas produk dapat didefinisikan sebagai potensi masalah dengan kualitas produk. Risiko kualitas produk meliputi -

  • Resiko fungsional
  • Risiko kinerja non-fungsional
  • Risiko kegunaan non-fungsional

Analisis risiko dilakukan untuk mengevaluasi probabilitas (likelihood) dan dampak dari setiap risiko. Kemudian, risikonya diprioritaskan -

  • Risiko Tinggi membutuhkan Pengujian Ekstensif
  • Risiko Rendah hanya membutuhkan Pengujian Sepintas

Tes dirancang dengan menggunakan Teknik Tes yang sesuai berdasarkan Tingkat Risiko dan Karakteristik Risiko dari masing-masing Risiko. Pengujian kemudian dilakukan untuk mengurangi Risiko.

Tes Kecocokan

Tes Kecocokan adalah Tes Penerimaan otomatis. Tools Fit dan FitNesse dapat digunakan untuk mengotomatiskan tes penerimaan.

FIT menggunakan JUnit, tetapi memperluas fungsionalitas pengujian. Tabel HTML digunakan untuk menampilkan kasus Uji. Fixture adalah kelas Java di belakang tabel HTML. Fixture mengambil konten dari tabel HTML dan menjalankan kasus uji pada proyek yang sedang diuji.

Rencana Tes disiapkan pada saat Perencanaan Rilis dan direvisi pada setiap Perencanaan Sprint. Rencana Tes bertindak sebagai panduan untuk proses pengujian agar memiliki cakupan tes yang lengkap.

Isi Khas dari Rencana Tes adalah -

  • Strategi Tes
  • Lingkungan Uji
  • Cakupan Tes
  • Ruang Lingkup Pengujian
  • Uji Upaya dan Jadwal
  • Alat Pengujian

Dalam Agile Projects, semua Anggota Tim bertanggung jawab atas kualitas produk. Oleh karena itu, setiap orang juga berpartisipasi dalam perencanaan ujian.

Tanggung jawab penguji adalah untuk memberikan arahan yang diperlukan dan membimbing seluruh tim dengan keahlian pengujian mereka.

Kisah Pengguna

Kisah Pengguna pada prinsipnya tidak menguji produk kerja. Namun, di Agile Projects, penguji berpartisipasi dalam Pembuatan Cerita Pengguna. Penguji menulis Kisah Pengguna yang memberikan nilai bagi pelanggan dan mencakup berbagai kemungkinan perilaku sistem.

Penguji juga memastikan bahwa semua Kisah Pengguna dapat diuji dan memastikan Kriteria Penerimaan.

Tes Manual dan Otomatis

Selama menjalankan Pengujian pertama, Pengujian Manual digunakan. Mereka termasuk -

  • Tes Unit
  • Tes Integrasi
  • Tes Fungsional
  • Tes Non Fungsional
  • Tes Penerimaan

Tes kemudian otomatis untuk proses selanjutnya.

Di Test Driven Development, Tes Unit ditulis pertama kali gagal, Kode dikembangkan dan diuji untuk memastikan Tes lulus.

Di Acceptance Test Driven Development, Tes Penerimaan ditulis terlebih dahulu untuk gagal, Kode dikembangkan dan diuji untuk memastikan Tes lulus.

Dalam metode Pengembangan lainnya, Penguji berkolaborasi dengan seluruh Tim untuk memastikan Cakupan Tes.

Di semua jenis metode, integrasi berkelanjutan terjadi, yang mencakup pengujian integrasi berkelanjutan.

Tim dapat memutuskan kapan dan tes apa yang akan diotomatiskan. Meskipun otomatisasi pengujian memerlukan upaya dan waktu, pengujian otomatis yang dihasilkan secara signifikan mengurangi upaya dan waktu pengujian berulang selama pengulangan Proyek Agile. Ini pada gilirannya memfasilitasi tim untuk lebih memperhatikan aktivitas lain yang dibutuhkan, seperti Kisah Pengguna baru, Perubahan, dll.

Di Scrum, iterasinya dibatasi waktu. Oleh karena itu, jika pengujian Kisah Pengguna tidak dapat diselesaikan dalam Sprint tertentu, penguji dapat melaporkan dalam rapat standup harian bahwa kisah pengguna tidak dapat mencapai Status Selesai dalam Sprint tersebut dan karenanya harus tetap menunggu hingga Sprint berikutnya.

Hasil tes

Karena sebagian besar Pengujian di Proyek Agile dilakukan secara otomatis, Alat menghasilkan Log Hasil Uji yang diperlukan. Penguji meninjau Log Hasil Tes. Hasil tes perlu dipertahankan untuk setiap sprint / rilis.

Ringkasan Tes juga dapat disiapkan yang berisi -

  • Ruang Lingkup Pengujian (Apa yang diuji dan apa yang tidak diuji)
  • Analisis Cacat bersama dengan Analisis Penyebab Akar jika memungkinkan
  • Status Pengujian Regresi setelah Perbaikan Cacat
  • Masalah dan Resolusi yang sesuai
  • Masalah Tertunda, jika ada
  • Modifikasi apa pun yang diperlukan dalam Strategi Tes
  • Metrik Uji

Laporan Metrik Uji

Dalam Agile Projects, Metrik Pengujian mencakup hal-hal berikut untuk setiap Sprint -

  • Upaya Uji
  • Uji Akurasi Estimasi
  • Cakupan Tes
  • Cakupan Tes Otomatis
  • Jumlah Cacat
  • Tingkat Cacat (Jumlah Cacat per Poin Cerita Pengguna)
  • Tingkat Keparahan Cacat
  • Saatnya Memperbaiki Cacat dalam Sprint yang sama (Biayanya 24x lebih mahal untuk memperbaiki bug yang lolos dari sprint saat ini)
  • Jumlah Cacat yang diperbaiki dalam Sprint yang sama
  • Penyelesaian Pengujian Penerimaan oleh Pelanggan dalam Sprint

Ulasan Sprint dan Laporan Retrospektif

Penguji juga berkontribusi pada Tinjauan Sprint dan Laporan Retrospektif. Konten khasnya adalah -

  • Metrik Uji
  • Hasil pemeriksaan Log Hasil Tes
  • Apa yang berjalan dengan benar dan apa yang dapat ditingkatkan dari Titik Pandang Pengujian
  • Praktik terbaik
  • Pelajaran yang Dipetik
  • Issues
  • Timbal balik pelanggan

Kegiatan Agile Testing dapat dikelola secara efektif menggunakan konsep Kanban. Berikut ini memastikan pengujian selesai tepat waktu dalam iterasi / sprint dan dengan demikian fokus pada pengiriman produk berkualitas.

  • Kisah Pengguna yang dapat diuji dan berukuran efektif menghasilkan pengembangan dan pengujian dalam batas waktu yang ditentukan.

  • Batas WIP (Work-In-Progress) memungkinkan Anda untuk fokus pada cerita pengguna dalam jumlah terbatas pada satu waktu.

  • Papan Kanban yang mewakili alur kerja secara visual, membantu melacak aktivitas pengujian dan hambatan, jika ada.

  • Konsep kolaborasi tim Kanban memungkinkan resolusi kemacetan seperti yang diidentifikasi, tanpa waktu tunggu.

  • Persiapan Kasus Uji di muka, mempertahankan rangkaian uji saat pengembangan berlangsung dan mendapatkan Umpan Balik Pelanggan membantu menghilangkan Cacat dalam iterasi / sprint.

  • Definition of Done (DoD) dikatakan Done-Done dalam artian Story mencapai status penyelesaian hanya setelah pengujian juga selesai.

Kegiatan Pengujian dalam Pengembangan Produk

Dalam pengembangan Produk, rilis dapat dilacak dengan fitur papan Kanban. Fitur untuk rilis tertentu ditetapkan ke papan Kanban Fitur yang melacak status pengembangan fitur secara visual.

Fitur dalam rilis dipecah menjadi cerita dan dikembangkan dalam rilis menggunakan pendekatan tangkas.

Aktivitas Pengujian Agile berikut memastikan pengiriman berkualitas di setiap rilis dan juga di akhir semua rilis -

  • Penguji berpartisipasi dalam Pembuatan Cerita Pengguna dan dengan demikian memastikan -

    • Semua kemungkinan Perilaku Sistem ditangkap melalui Kisah Pengguna dan Persyaratan Non-fungsional yang merupakan bagian dari Kisah Pengguna.

    • Kisah Pengguna Dapat Diuji.

    • Ukuran Kisah Pengguna memungkinkan Pengembangan dan Pengujian selesai (Selesai) dalam Iterasi.

  • Papan Kanban Tugas Visual -

    • Menggambarkan status dan kemajuan Tugas

    • Kemacetan diidentifikasi segera setelah terjadi

    • Memfasilitasi untuk mengukur waktu siklus yang kemudian dapat dioptimalkan

  • Kolaborasi Tim membantu dalam -

    • Akuntabilitas seluruh Tim untuk Kualitas produk

    • Resolusi kemacetan saat dan saat terjadi, menghemat waktu tunggu

    • Kontribusi setiap keahlian dalam semua kegiatan

  • Integrasi Berkelanjutan yang berfokus pada Pengujian Integrasi Berkelanjutan

  • Otomatisasi Pengujian untuk menghemat Upaya dan Waktu Pengujian

  • Pencegahan Cacat dengan Uji Kasus yang ditulis sebelumnya untuk Pengembangan dan membimbing Pengembang tentang apa yang diantisipasi oleh berbagai perilaku Sistem -

    • Batas WIP untuk fokus pada Cerita Pengguna dalam jumlah terbatas

  • Pengujian Berkelanjutan saat Pengembangan berlangsung, untuk memastikan Perbaikan Cacat dalam Iterasi -

    • Pastikan Cakupan Tes

    • Jaga Jumlah Cacat Terbuka Tetap Rendah

Eksplorasi Cerita

Eksplorasi Cerita adalah komunikasi dalam tim Agile untuk mengeksplorasi pemahaman Cerita ketika pemilik produk meneruskan cerita untuk diterima untuk dikembangkan.

Pemilik produk membuat cerita berdasarkan fungsionalitas yang diharapkan oleh sistem. Pengembang melakukan lebih banyak eksplorasi pada setiap cerita sebelum mereka menandainya siap untuk diterima. Penguji juga berpartisipasi dalam komunikasi dari perspektif pengujian agar dapat diuji sebaik mungkin.

Finalisasi Cerita didasarkan pada komunikasi yang konstan dan berkelanjutan antara Pemilik Produk, Pengembang, dan Penguji.

Perkiraan

Estimasi terjadi dalam Perencanaan Rilis dan setiap Perencanaan Iterasi.

Dalam Perencanaan Rilis, penguji menyediakan -

  • Informasi tentang kegiatan pengujian apa yang diperlukan
  • Estimasi Usaha untuk hal yang sama

Dalam perencanaan iterasi, penguji berkontribusi untuk memutuskan apa dan berapa banyak story yang dapat dimasukkan dalam sebuah iterasi. Keputusannya tergantung pada Upaya Tes dan Estimasi Jadwal Tes. Estimasi Cerita mencerminkan estimasi tes juga.

Di Kanban, Selesai-Selesai hanya dilakukan ketika sebuah cerita dikembangkan dan diuji dan ditandai sebagai selesai tanpa cacat.

Oleh karena itu, Estimasi Tes memainkan Peran utama dalam estimasi cerita.

Perencanaan Cerita

Perencanaan Cerita dimulai setelah Cerita telah diperkirakan dan ditetapkan ke Iterasi saat ini.

Perencanaan Cerita mencakup tugas-tugas tes berikut -

  • Siapkan Data Uji
  • Perpanjang Tes Penerimaan
  • Jalankan Tes Manual
  • Lakukan sesi Pengujian Eksplorasi
  • Otomatiskan Tes Integrasi Berkelanjutan

Selain Tugas Pengujian ini, tugas lain juga mungkin diperlukan, seperti -

  • Pengujian Kinerja
  • Pengujian Regresi
  • Pembaruan Tes Integrasi Berkelanjutan terkait

Perkembangan Cerita

Perkembangan Cerita mengungkap tes tambahan yang diperlukan yang dihasilkan oleh komunikasi berkelanjutan antara pengembang dan penguji. Dalam situasi di mana pengembang membutuhkan lebih banyak kejelasan tentang implementasi, penguji melakukan pengujian eksplorasi.

Pengujian Berkelanjutan dilakukan selama Perkembangan Cerita dan mencakup Pengujian Integrasi Berkelanjutan. Seluruh tim berpartisipasi dalam kegiatan pengujian.

Penerimaan Cerita

Penerimaan Cerita terjadi ketika cerita mencapai status Selesai. yaitu, cerita dikembangkan dan diuji serta diberi isyarat sebagai lengkap.

Pengujian cerita dikatakan selesai jika semua pengujian yang relevan dengan kelulusan cerita atau tingkat otomatisasi pengujian terpenuhi.

Dalam Agile Projects, Penguji bertanggung jawab untuk tugas harian berikut -

  • Mendukung pengembang dalam pengkodean, dengan klarifikasi tentang perilaku yang diharapkan dari sistem.

  • Membantu pengembang dalam membuat pengujian unit yang efektif dan efisien.

  • Kembangkan skrip otomasi.

  • Integrasikan alat / skrip pengujian otomatisasi dengan integrasi berkelanjutan untuk pengujian regresi.

Untuk implementasi yang efektif dan cepat dari tugas-tugas ini, sistem Continuous Integration (CI) yang mendukung CI Kode dan komponen pengujian digunakan di sebagian besar proyek Agile.

Penguji dan pengembang dalam proyek tangkas dapat memanfaatkan berbagai alat untuk mengelola sesi pengujian dan untuk membuat serta mengirimkan laporan Cacat. Selain alat khusus untuk pengujian agile, tim agile juga dapat memanfaatkan otomatisasi pengujian dan alat manajemen pengujian.

Note - Record-and-Playback, Test-Last, Heavyweight, dan Test Automation Solutions tidak Agile karena -

  • Alur kerja uji terakhir yang didorong oleh alat tersebut tidak berfungsi untuk tim Agile.

  • Skrip yang tidak dapat dipertahankan yang dibuat dengan alat seperti itu menjadi penghalang untuk berubah

  • Alat khusus seperti itu menciptakan kebutuhan akan spesialis otomasi Tes dan dengan demikian mendorong silo

Alat yang banyak digunakan adalah -

S.No. Alat & Tujuan
1

Hudson

Kerangka CI

2

Selenium

Pengujian Fungsional - Terintegrasi dengan Hudson

3

CruiseControl

Kerangka CI

4

Junit

Uji Satuan Java

5

Nunit

Tes Unit Bersih

6

Cobertura / JavaCodeCoverage / JFeature / JCover /

Cakupan Tes Java

7

Jester

Java - Pengujian Mutasi / Pembibitan Kesalahan Otomatis

8

Gretel

Alat Pemantauan Cakupan Uji Java

9

TestCocoon

C / C ++ atau C # - mengurangi jumlah Tes dengan menemukan Tes yang berlebihan dan menemukan Kode Mati

10

JAZZ

Java - Branch, Node, dan Defuse Coverage dan mengimplementasikan GUI, Test Planner, Dynamic Instrumentation, dan Test Analyzer

11

Ant

Java - Pembuatan Otomasi

12

Nant

.Net - Pembuatan Otomasi

13

Bonfire

Pengaya Agile Testing untuk JIRA

Alat Otomasi Tes Agile

Dukungan alat otomatisasi pengujian Agile yang efektif -

  • Otomatisasi pengujian awal menggunakan pendekatan uji-pertama.

  • Menulis kode otomatisasi uji menggunakan bahasa nyata, bahasa khusus domain.

  • Berfokus pada perilaku yang diharapkan dari sistem.

  • Memisahkan esensi Tes dari detail implementasi, sehingga menjadikannya independen Teknologi.

  • Membina Kolaborasi.

Automated Unit Tests (menggunakan Junit atau NUnit) mendukung pendekatan test-first untuk pengkodean. Ini adalah pengujian kotak putih dan memastikan bahwa desainnya bagus, dan tidak ada cacat. Pengujian semacam itu dibuat oleh pengembang dengan dukungan dari penguji, dan dapat terlepas dari fungsionalitas yang diperlukan. Ini menghasilkan pengiriman produk yang mungkin tidak memenuhi persyaratan pelanggan dan karenanya tidak memiliki nilai bisnis.

Kekhawatiran ini diatasi dengan mengotomatiskan Tes Penerimaan yang ditulis dengan kolaborasi pelanggan, pemangku kepentingan lain, penguji, dan pengembang. Tes Penerimaan otomatis ditulis oleh pelanggan atau pemilik produk / analis bisnis yang mencerminkan perilaku produk yang diharapkan. Keterlibatan pengembang memastikan produksi kode sesuai kebutuhan. Namun, jika pengujian difokuskan hanya pada penerimaan, kode yang dihasilkan mungkin tetap tidak dapat diperpanjang.

Dengan demikian, Tes Unit Otomatis dan Tes Penerimaan Otomatis bersifat gratis dan keduanya diperlukan dalam Pengembangan Agile.

Alat dan Kerangka Agile yang mendukung Pengujian Penerimaan Otomatis adalah -

  • Fit
  • Fitnesse
  • Concordion
  • Ruby
  • Cucumber

Cocok

Ward Cunningham mengembangkan alat Fit yang dapat digunakan untuk Otomasi Tes Penerimaan. Fit memungkinkan -

  • Pelanggan atau Pemilik Produk memberikan contoh perilaku produk menggunakan Microsoft Word dan Microsoft Excel

  • Pemrogram untuk dengan mudah mengubah contoh tersebut menjadi pengujian otomatis.

Fit 1.1 mendukung Java dan .NET.

FitNesse

FitNesse adalah wiki, yang merupakan gaya server web yang memungkinkan setiap pengunjung untuk mengedit, termasuk mengubah halaman yang ada dan membuat halaman baru. Bahasa markup sederhana memungkinkan Anda membuat judul, membuat teks tebal, menggarisbawahi, dan miring, membuat daftar berpoin, dan melakukan jenis pemformatan sederhana lainnya dengan mudah.

Di FitNesse, Otomasi Tes Penerimaan adalah sebagai berikut -

  • Ekspresikan tes sebagai tabel data masukan dan data keluaran yang diharapkan.

  • Gunakan FitNesse untuk meletakkan tabel tes pada halaman yang dapat Anda edit.

    • Atau, letakkan tabel uji di Microsoft Excel, salin ke clipboard, lalu gunakan Spreadsheet to FitNesse perintah agar FitNesse memformat tabel Anda dengan benar

  • Jalankan pengujian

  • Anda mendapatkan hasil pengujian dengan kode warna sel di tabel pengujian

    • sel hijau menunjukkan bahwa nilai yang diharapkan diperoleh

    • sel darah merah menunjukkan bahwa nilai yang berbeda dari yang diharapkan diperoleh

    • sel kuning menunjukkan bahwa pengecualian telah dilemparkan

Timun

Mentimun adalah alat yang didasarkan pada kerangka Behavior Driven Development (BDD). Fitur utamanya adalah -

  • Digunakan untuk menulis tes penerimaan untuk aplikasi web.

  • Memungkinkan otomatisasi validasi fungsional dalam format yang mudah dibaca dan dipahami seperti bahasa Inggris biasa.

  • Diimplementasikan di Ruby dan kemudian diperluas ke framework Java. Keduanya mendukung Junit.

  • Mendukung bahasa lain seperti Perl, PHP, Python, .Net dll.

  • Dapat digunakan bersama dengan Selenium, Watir, Capybara, dll.