Scrum dalam Pengujian Perangkat Lunak
Scrum dalam Pengujian Perangkat Lunak adalah metodologi untuk membangun aplikasi perangkat lunak yang kompleks. Ini memberikan solusi mudah untuk menjalankan tugas yang rumit. Scrum membantu tim pengembangan untuk fokus pada semua aspek pengembangan produk perangkat lunak seperti kualitas, kinerja, kegunaan, dan sebagainya. Ini memberikan transparansi, inspeksi dan adaptasi selama pengembangan perangkat lunak untuk menghindari kerumitan.
Pengujian Scrum
Scrum Testing adalah pengujian yang dilakukan dalam metodologi scrum untuk memverifikasi persyaratan aplikasi perangkat lunak terpenuhi. Ini melibatkan pemeriksaan parameter non-fungsional seperti keamanan, kegunaan, kinerja, dll. Tidak ada peran aktif penguji dalam proses sehingga biasanya dilakukan oleh pengembang dengan Uji Unit. Terkadang tim penguji yang berdedikasi diperlukan tergantung pada sifat & kompleksitas proyek.
Dalam tutorial ini, Anda akan belajar-
- Apa itu Scrum?
- Fitur Utama Metodologi Scrum
- Peran di Scrum
- Artefak Scrum
- Upacara (Proses) di Scrum
- Peran Penguji di Scrum
- Menguji Aktivitas di Scrum
- Pelaporan Uji
Fitur Utama Metodologi Scrum
Berikut adalah Fitur Utama Scrum-
- Scrum memiliki jadwal siklus rilis tetap yang pendek dengan cakupan yang dapat disesuaikan yang disebut sprint untuk memenuhi kebutuhan pengembangan yang berubah dengan cepat. Setiap rilis dapat memiliki beberapa sprint. Setiap Proyek Scrum dapat memiliki beberapa Siklus Rilis.
- Urutan pertemuan, acara, dan pencapaian yang berulang
- Praktik menguji dan menerapkan persyaratan baru, yang dikenal sebagai cerita , untuk memastikan beberapa pekerjaan siap dirilis setelah setiap sprint
Scrum didasarkan pada 3 Pilar berikut-
Mari kita simak satu per satu
1. Peran dalam Scrum
Ada tiga peran utama dalam Pengujian Scrum - Pemilik Produk, Master Scrum, dan Tim Pengembang. Mari kita pelajari secara detail
|
Pemilik produk |
Scrum Master |
Tim |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2. Artefak Scrum
Proses scrum termasuk
- Kisah pengguna: Ini adalah penjelasan singkat tentang fungsionalitas sistem yang diuji. Contoh untuk Penyedia Asuransi adalah - "Premi dapat dibayarkan menggunakan sistem online."
- Product Backlog: Ini adalah kumpulan cerita pengguna yang diambil untuk produk scrum. Pemilik produk mempersiapkan dan memelihara jaminan simpanan produk. Ini diprioritaskan oleh pemilik produk, dan siapa pun dapat menambahkannya dengan persetujuan dari pemilik produk.
- Release Backlog: Rilis adalah kerangka waktu di mana jumlah iterasi diselesaikan. Pemilik produk berkoordinasi dengan scrum master untuk memutuskan cerita mana yang harus ditargetkan untuk rilis. Cerita di backlog rilis ditargetkan untuk diselesaikan dalam rilis.
- Sprint: Ini adalah periode waktu yang ditetapkan untuk menyelesaikan cerita pengguna, diputuskan oleh pemilik produk dan tim pengembang, biasanya 2-4 minggu.
- Sprint Backlog: Ini adalah sekumpulan cerita pengguna yang harus diselesaikan dalam sprint. Selama sprint backlog, pekerjaan tidak pernah ditugaskan, dan tim mendaftar untuk mengerjakannya sendiri. Itu dimiliki dan dikelola oleh tim sementara perkiraan pekerjaan yang tersisa diperbarui setiap hari. Ini adalah daftar tugas yang harus dilakukan di Sprint
- Daftar Blok: Ini adalah daftar blok dan keputusan yang belum diambil yang dimiliki oleh scrum master dan diperbarui setiap hari
- Bagan burndown: Bagan burn-down mewakili kemajuan keseluruhan dari pekerjaan yang sedang berlangsung dan pekerjaan yang diselesaikan selama proses. Ini mewakili dalam format grafik cerita dan fitur yang belum selesai
3. Upacara (Proses) di Scrum
- Perencanaan Sprint: Sprint dimulai dengan tim mengimpor cerita dari rilis backlog ke dalam sprint backlog; itu di-host oleh scrum master. Penguji memperkirakan upaya untuk menguji berbagai cerita di Sprint Backlog.
- Daily Scrum: Diposting oleh scrum master, berlangsung sekitar 15 menit. Dalam Daily Scrum, para anggota akan mendiskusikan pekerjaan yang diselesaikan pada hari sebelumnya, pekerjaan yang direncanakan untuk hari berikutnya dan masalah yang dihadapi selama sprint. Selama kemajuan tim rapat stand-up harian dilacak.
- Ulasan Sprint / Retrospektif: Ini juga diselenggarakan oleh scrum master, berlangsung sekitar 2-4 jam dan mendiskusikan apa yang telah dicapai tim di sprint terakhir dan pelajaran apa yang dipetik.
Peran Penguji di Scrum
Tidak ada peran aktif Penguji dalam Proses Scrum . Biasanya pengujian dilakukan oleh developer dengan Unit Test. Sedangkan product owner juga sering dilibatkan dalam proses pengujian pada setiap sprint. Beberapa proyek Scrum memang memiliki tim penguji khusus tergantung pada sifat & kompleksitas proyek .
Pertanyaan selanjutnya adalah, apa yang dilakukan tester dalam scrum? Catatan berikut akan menjawabnya
Menguji Aktivitas di Scrum
Penguji melakukan aktivitas berikut selama berbagai tahapan Scrum-
Perencanaan Sprint
- Dalam perencanaan sprint, penguji harus memilih cerita pengguna dari product backlog yang harus diuji.
- Sebagai penguji, dia harus memutuskan berapa jam (Estimasi Upaya) yang diperlukan untuk menyelesaikan pengujian untuk setiap cerita pengguna yang dipilih.
- Sebagai penguji, dia harus tahu apa itu sprint goal.
- Sebagai penguji, berkontribusi pada proses pembuatan prioritas
Sprint
- Mendukung pengembang dalam pengujian unit
- Uji cerita pengguna setelah selesai. Eksekusi pengujian dilakukan di lab tempat penguji dan developer bekerja sama. Cacat dicatat dalam alat Manajemen Cacat yang dilacak setiap hari. Cacat dapat diberikan dan dianalisis selama rapat scrum. Cacat diuji ulang segera setelah diatasi dan diterapkan untuk pengujian
- Sebagai penguji, dia menghadiri semua rapat standup harian untuk berbicara
- Sebagai penguji, dia dapat membawa item backlog apa pun yang tidak dapat diselesaikan di sprint saat ini dan dimasukkan ke sprint berikutnya.
- Penguji bertanggung jawab untuk mengembangkan skrip otomasi. Dia menjadwalkan pengujian otomasi dengan sistem Continuous Integration (CI). Otomasi menerima pentingnya karena waktu pengiriman yang singkat. Otomasi Tes dapat dilakukan dengan memanfaatkan berbagai alat open source atau berbayar yang tersedia di pasar. Ini terbukti efektif dalam memastikan bahwa semua yang perlu diuji tercakup. Cakupan Tes yang memadai dapat dicapai dengan komunikasi yang erat dengan tim.
- Tinjau hasil otomatisasi CI dan kirim Laporan ke pemangku kepentingan
- Menjalankan pengujian non-fungsional untuk cerita pengguna yang disetujui
- Berkoordinasi dengan pelanggan dan pemilik produk untuk menentukan kriteria penerimaan untuk Tes Penerimaan
- Di akhir sprint, penguji juga melakukan pengujian penerimaan (UAT) dalam beberapa kasus dan mengonfirmasi kelengkapan pengujian untuk sprint saat ini
Sprint Retrospective
- Sebagai penguji, dia akan mencari tahu apa yang salah dan apa yang benar dalam sprint saat ini
- Sebagai penguji, dia mengidentifikasi pelajaran yang dipelajari dan praktik terbaik
Pelaporan Uji
Pelaporan metrik Uji Scrum memberikan transparansi dan visibilitas kepada pemangku kepentingan tentang proyek. Metrik yang dilaporkan memungkinkan tim untuk menganalisis kemajuan mereka dan merencanakan strategi masa depan mereka untuk meningkatkan produk. Ada dua metrik yang sering digunakan untuk melaporkan.
Grafik burn down: Setiap hari, Scrum Master mencatat perkiraan sisa pekerjaan untuk sprint. Ini tidak lain adalah Burn Down Chart. Itu diperbarui setiap hari.
Bagan burndown memberikan gambaran singkat tentang kemajuan proyek, bagan ini berisi informasi seperti jumlah total pekerjaan dalam proyek yang harus diselesaikan, jumlah pekerjaan yang diselesaikan selama setiap sprint dan sebagainya.
Grafik riwayat kecepatan: Grafik riwayat kecepatan memprediksi kecepatan tim yang dicapai di setiap sprint. Ini adalah grafik batang dan menunjukkan bagaimana hasil tim berubah dari waktu ke waktu.
Metrik tambahan yang mungkin berguna adalah pembakaran jadwal, pembakaran anggaran, persentase tema selesai, cerita selesai - cerita tersisa, dan sebagainya.
Apakah Anda memiliki tip atau pengalaman untuk dibagikan untuk Pengujian Scrum? Tinggalkan komentar di bawah-