Siapa yang bertanggung jawab atas matriks ketertelusuran persyaratan?

Tanggung jawab utama untuk memelihara RTM biasanya berada di tangan tim QA atau penguji. Namun, analis bisnis mendefinisikan persyaratan, pengembang menghubungkan kode dengan persyaratan tersebut, dan manajer proyek mengawasi keakuratannya. Dalam praktiknya, RTM merupakan tanggung jawab bersama di seluruh tim, memastikan persyaratan dilacak dan divalidasi di setiap tahap.

Apa itu Matriks Ketertelusuran Persyaratan (RTM) dalam Pengujian?

⚡ Ringkasan Cerdas

Matriks Ketertelusuran Persyaratan (RTM) adalah dokumen terstruktur yang menghubungkan persyaratan proyek dengan kasus uji terkait, memastikan cakupan dan validasi yang menyeluruh. Matriks ini memainkan peran penting dalam pengujian perangkat lunak dengan mencegah fungsionalitas yang terlewat, mendukung kepatuhan, dan memberikan visibilitas di antara para pemangku kepentingan.

Mulailah RTM di awal siklus hidup proyek untuk memastikan keselarasan penuh dengan persyaratan.
Selalu perbarui matriks setiap kali persyaratan atau kasus pengujian berubah.
Gunakan ID yang jelas dan unik untuk memetakan persyaratan, skenario, dan kasus uji secara efektif.
Berkolaborasilah antar penguji, pengembang, analis, dan manajer untuk akuntabilitas bersama.
Memanfaatkan alat otomatisasi (misalnya, Jira, Zephyr) untuk mengurangi upaya manual dan meningkatkan skalabilitas.

Baca Selengkapnya

Apa itu Matriks Ketertelusuran (TM)?

Matriks Ketertelusuran adalah dokumen yang menghubungkan dua dokumen dasar yang memerlukan hubungan banyak ke banyak untuk memeriksa kelengkapan hubungan.

Digunakan untuk melacak persyaratan dan memeriksa apakah persyaratan proyek saat ini terpenuhi.

Apa itu Matriks Ketertelusuran Persyaratan?

Matriks Ketertelusuran Persyaratan (RTM) adalah dokumen yang memetakan dan melacak kebutuhan pengguna dengan kasus uji. Dokumen ini menangkap semua persyaratan yang diajukan oleh klien dan ketertelusuran persyaratan dalam satu dokumen, yang dikirimkan pada akhir pengujian. Siklus hidup pengembangan perangkat lunakTujuan utama Matriks Ketertelusuran Persyaratan adalah untuk memvalidasi bahwa semua persyaratan telah diperiksa melalui kasus uji, sehingga tidak ada fungsionalitas yang tidak diperiksa selama pengujian Perangkat Lunak.

Mengapa RTM penting?

Agenda utama setiap penguji adalah memahami persyaratan klien dan memastikan produk keluaran bebas cacat. Untuk mencapai tujuan ini, setiap QA harus memahami persyaratan secara menyeluruh dan membuat kasus uji positif dan negatif.

Ini berarti persyaratan perangkat lunak yang disediakan oleh klien harus dipecah lebih lanjut ke dalam beberapa skenario dan kasus uji. Setiap kasus ini harus dijalankan secara individual.

Pertanyaan yang muncul di sini adalah bagaimana memastikan persyaratan tersebut teruji, dengan mempertimbangkan semua kemungkinan skenario/kasus? Bagaimana memastikan tidak ada persyaratan yang terlewat dari siklus pengujian?

Cara sederhananya adalah dengan menelusuri persyaratan dengan skenario pengujian yang sesuai dan kasus ujiIni disebut sebagai 'Matriks Ketertelusuran Persyaratan.'

Matriks ketertelusuran biasanya berupa lembar kerja yang berisi persyaratan dengan semua kemungkinan skenario pengujian dan kasus-kasus serta statusnya saat ini, misalnya, apakah telah lulus atau tidak. Hal ini akan membantu tim pengujian untuk memahami tingkat aktivitas pengujian yang dilakukan untuk produk tertentu.

Siapa yang butuh RTM?

A Matriks Ketertelusuran Persyaratan (RTM) tidak hanya untuk penguji — ini berharga bagi siapa saja yang terlibat dalam pengiriman perangkat lunak atau proyek berkualitas tinggi.

QA dan Penguji → Pastikan cakupan persyaratan 100% dengan kasus uji yang dipetakan dengan baik.
Analis Bisnis → Melacak persyaratan dari SRS/User Stories hingga eksekusi.
Manajer Proyek → Dapatkan visibilitas ke dalam cakupan, kemajuan, dan persyaratan yang terlewat.
Pengembang → Memahami bagaimana fitur dipetakan kembali ke tujuan bisnis.
Industri yang Diatur (Kesehatan, Otomotif, Dirgantara, Keuangan) → Buktikan kepatuhan dan lulus audit dengan ketertelusuran yang jelas.
Klien dan Pemangku Kepentingan → Dapatkan kepastian bahwa persyaratan mereka telah diterapkan dan diuji.

👉 Singkatnya, siapa pun yang bertanggung jawab atas membangun, memvalidasi, atau menyetujui persyaratan perangkat lunak manfaat dari RTM.

Parameter apa saja yang harus disertakan dalam Matriks Ketertelusuran Persyaratan?

ID Persyaratan
Jenis Persyaratan dan Description
Uji Kasus dengan Status

Di atas adalah contoh matriks ketertelusuran kebutuhan.

Namun secara tipikal pengujian perangkat lunak proyek, matriks ketertelusuran akan memiliki lebih dari parameter ini.

Seperti yang diilustrasikan di atas, matriks ketertelusuran persyaratan dapat:

Tunjukkan cakupan persyaratan dalam jumlah kasus uji
Status desain serta status eksekusi untuk kasus uji tertentu
Jika ada pengujian Penerimaan Pengguna yang harus dilakukan oleh pengguna, maka status UAT juga dapat ditangkap dalam matriks yang sama.
Cacat terkait dan keadaan saat ini juga dapat disebutkan dalam matriks yang sama.

Matriks jenis ini akan menyediakan Toko serba ada untuk semua kegiatan pengujian.

Selain mengelola Excel secara terpisah, tim pengujian juga dapat memilih pelacakan persyaratan yang tersedia di Alat Manajemen Pengujian.

Jenis Matriks Uji Ketertelusuran

Dalam Rekayasa Perangkat Lunak, matriks ketertelusuran dapat dibagi menjadi tiga komponen utama seperti yang disebutkan di bawah ini:

Ketertelusuran ke depan: Matriks ini digunakan untuk memeriksa apakah proyek berjalan ke arah yang diinginkan dan untuk produk yang tepat. Hal ini memastikan bahwa setiap persyaratan diterapkan pada produk dan setiap persyaratan diuji secara menyeluruh. Ini memetakan persyaratan untuk menguji kasus.
Ketertelusuran ke belakang atau ke belakang: Ketertelusuran ini digunakan untuk memastikan bahwa produk yang ada tetap berada di jalur yang benar. Tujuan dari jenis ketertelusuran ini adalah untuk memastikan bahwa kita tidak memperluas cakupan proyek dengan menambahkan kode, elemen desain, pengujian, atau pekerjaan lain yang tidak ditentukan dalam persyaratan. Ketertelusuran ini memetakan kasus uji ke persyaratan.
Ketertelusuran dua arah (Maju+Mundur): Matriks ketertelusuran ini memastikan bahwa kasus uji mencakup semua persyaratan. Matriks ini menganalisis dampak perubahan persyaratan yang dipengaruhi oleh Cacat dalam suatu produk kerja dan sebaliknya.

Cara membuat Matriks Ketertelusuran Persyaratan

Mari kita pahami konsep Matriks Penelusuran Persyaratan melalui proyek perbankan Guru99.

Atas dasar Dokumen Persyaratan Bisnis (BRD) dan Dokumen Persyaratan Teknis (TRD), penguji mulai menulis kasus uji.

Misalkan tabel berikut adalah Dokumen Persyaratan Bisnis kita atau BRD untuk Proyek perbankan Guru99.

Di sini, skenarionya adalah bahwa nasabah harus dapat masuk ke situs web perbankan Guru99 dengan kata sandi dan ID pengguna yang benar, sementara manajer harus dapat masuk ke situs web melalui halaman login nasabah.

Tabel di bawah ini adalah milik kami Dokumen Persyaratan Teknis (TRD).

Catatan: Tim QA tidak mendokumentasikan BRD dan TRD. Juga, beberapa perusahaan menggunakan Dokumen Persyaratan Fungsi (FRD), yang mirip dengan Dokumen Persyaratan Teknis, tetapi proses pembuatan Matriks Ketertelusuran tetap sama.

Ayo Maju dan buat RTM dalam Pengujian

Langkah 1) Mitra contoh Kasus Uji is

“Verifikasi Login: Jika ID dan Kata Sandi yang benar telah dimasukkan, login akan berhasil.”

Langkah 2) Identifikasi Persyaratan Teknis yang sedang diverifikasi oleh kasus uji ini. Untuk kasus uji kami, persyaratan teknis T94 sedang diverifikasi.

Langkah 3) Catat Persyaratan Teknis ini (T94) dalam Test Case.

Langkah 4) Identifikasi Persyaratan Bisnis yang menentukan TR (Persyaratan Teknis-T94) ini

Langkah 5) Perhatikan BR (Persyaratan Bisnis) dalam Kasus Uji

Langkah 6) Lakukan hal di atas untuk semua Kasus Uji. LaterEkstrak 3 Kolom Pertama dari Rangkaian Pengujian Anda. RTM dalam pengujian sudah Siap!

Keuntungan dari Matriks Ketertelusuran Persyaratan

Ini menegaskan cakupan tes 100%.
Ini menyoroti setiap persyaratan yang hilang atau ketidakkonsistenan dokumen
Ini menunjukkan keseluruhan cacat atau status eksekusi dengan fokus pada kebutuhan bisnis
Ini membantu dalam menganalisis atau memperkirakan dampak pada pekerjaan tim QA sehubungan dengan meninjau kembali atau mengerjakan ulang kasus pengujian.

Praktik Terbaik dan Tips Menggunakan RTM

Matriks Ketertelusuran Persyaratan (RTM) paling efektif ketika tetap sederhana, konsisten, dan diperbarui secara berkalaBerikut adalah praktik terbaik yang akan memungkinkan tim untuk memastikan cakupan penuh, pengerjaan ulang minimal, dan peningkatan kepercayaan dalam penyampaian proyek:

Mulai Dini → Buat RTM Anda di awal proyek.
Tetap Perbarui → Perbarui matriks setiap kali persyaratan atau kasus pengujian berubah.
Gunakan ID yang Jelas → Tetapkan ID unik untuk persyaratan dan kasus uji untuk memudahkan penelusuran.
Mencakup Kasus Positif & Negatif → Pastikan setiap persyaratan divalidasi dari berbagai sudut pengujian.
Berkolaborasi Lintas Tim → Libatkan penguji, pengembang, BA, dan manajer proyek dalam memelihara RTM.
Manfaatkan Alat → Daripada spreadsheet, pertimbangkan alat manajemen pengujian (seperti Jira, HP ALM, atau Zephyr) untuk skalabilitas.
Kontrol Versi → Simpan versi historis untuk melacak perubahan dan menjaga kepatuhan.
Fokus pada Kesederhanaan → Hindari membebani matriks secara berlebihan; sorot hanya parameter yang penting saja.
Audit Secara Teratur → Tinjau RTM secara berkala untuk mengetahui kesenjangan sebelum menguji tenggat waktu.
Tautan ke Nilai Bisnis → Petakan kembali persyaratan ke tujuan bisnis untuk menunjukkan ROI.

Tantangan dan Solusi Umum RTM

Tantangan: Menjaga RTM Tetap Terkini
Persyaratan dan kasus pengujian sering berubah, membuat RTM cepat usang.
Larutan: Gunakan alat manajemen pengujian otomatis yang menyinkronkan persyaratan, kasus uji, dan cacat secara real-time.
Tantangan: Kompleksitas yang Berlebihan
Menambahkan terlalu banyak parameter membuat RTM sulit dipelihara dan ditafsirkan.
Larutan: Jaga RTM tetap ramping dengan hanya berfokus pada bidang penting seperti ID, deskripsi, dan status.
Tantangan: Kolaborasi Tim yang Buruk
Tim yang berbeda mungkin tidak sepakat dalam hal kepemilikan atau pembaruan.
Larutan: Tetapkan peran yang jelas, libatkan penguji, pengembang, dan analis, serta jadwalkan tinjauan RTM secara berkala.
Tantangan: Cakupan Persyaratan Tidak Lengkap
Beberapa persyaratan mungkin kekurangan kasus pengujian, sehingga mengakibatkan hilangnya fungsionalitas.
Larutan: Validasi cakupan secara berkala, gunakan ketertelusuran dua arah, dan jalankan audit sebelum rilis utama.
Tantangan: Upaya Manual dalam Proyek Besar
Mengelola RTM dalam spreadsheet menjadi memakan waktu untuk sistem yang kompleks.
Larutan: Gunakan alat RTM seperti Jira, HP ALM, atau Zephyr untuk mengotomatiskan pemetaan dan pelaporan.

Mari pelajari RTM dengan contoh di Video

Klik di sini jika video tidak dapat diakses

Templat Matriks Penelusuran Persyaratan (RTM).

Klik di bawah ini untuk mengunduh File Excel Template RTM

Unduh Templat RTM Excel(.xlsx)

Tanya Jawab:

RTM digunakan untuk memastikan setiap persyaratan proyek terhubung dengan kasus uji yang sesuai. RTM membantu memverifikasi cakupan penuh, melacak perubahan, mengurangi cacat, dan memberikan bukti validasi. Dengan memetakan persyaratan ke pengujian, RTM meningkatkan jaminan kualitas, kepatuhan, dan kepercayaan pemangku kepentingan di seluruh siklus hidup pengembangan.

Ada tiga jenis utama RTM: Ketertelusuran Maju (persyaratan peta untuk kasus uji), Ketertelusuran Mundur (memetakan kasus uji kembali ke persyaratan), dan Ketertelusuran dua arah (menggabungkan kedua arah). Bersama-sama, pendekatan ini memastikan cakupan yang lengkap, mencegah perluasan cakupan yang tidak perlu, dan memvalidasi bahwa semua persyaratan telah diuji secara menyeluruh.

Matriks ketertelusuran persyaratan biasanya disiapkan di awal proyek, setelah persyaratan didokumentasikan dalam SRS, BRD, atau backlog. Matriks ini berkembang sepanjang siklus hidup, diperbarui setiap kali persyaratan atau kasus uji berubah. Mempersiapkan RTM sejak dini memastikan keselarasan, meminimalkan fungsionalitas yang terlewat, dan mendukung perencanaan pengujian serta analisis cakupan yang efektif.

Tanggung jawab utama untuk memelihara RTM biasanya terletak pada tim QA or penguji. Namun, analis bisnis mendefinisikan persyaratan, pengembang menghubungkan kode ke persyaratan tersebut, dan manajer proyek mengawasi akurasi. Dalam praktiknya, RTM merupakan tanggung jawab bersama di seluruh tim, memastikan persyaratan dilacak dan divalidasi di setiap tahap.

Untuk menggunakan RTM, daftarkan persyaratan proyek beserta kasus ujinya. Lacak status eksekusi, cacat, dan cakupannya. Tim menggunakannya untuk memverifikasi bahwa persyaratan telah diuji, mengidentifikasi celah, dan menilai dampak perubahan. RTM menjadi dokumen hidup yang memberikan visibilitas dan kontrol di seluruh siklus hidup pengujian dan proyek.

Ya, RTM banyak digunakan dalam proyek Agile. Alih-alih dokumen SRS formal, persyaratan seringkali berasal dari cerita pengguna or tumpukan produkTim Agile memetakan cerita-cerita ini ke kasus uji dalam RTM, memastikan setiap cerita tervalidasi. Hal ini beradaptasi dengan baik dengan sifat iteratif Agile sekaligus mempertahankan cakupan penuh.

Ya, RTM dapat diotomatisasi menggunakan alat manajemen pengujian seperti Jira, HP ALM, atau ZephyrOtomatisasi mengurangi upaya manual, memastikan pembaruan waktu nyata, dan memberikan ketertelusuran yang lebih baik di seluruh persyaratan, kasus uji, dan cacat. RTM otomatis sangat berguna dalam proyek-proyek besar atau yang diatur di mana kepatuhan dan kesiapan audit sangat penting.

RTM dan RACI memiliki tujuan yang berbeda. RTM melacak persyaratan dan kasus pengujian untuk memastikan cakupan dan validasi. RACI adalah matriks penugasan tanggung jawab yang menunjukkan siapa yang Bertanggung Jawab, Akuntabel, Dikonsultasikan, dan Diinformasikan dalam suatu proyek. RTM berfokus pada persyaratan dan pengujian, sementara RACI memperjelas peran dan tanggung jawab tim.