Ketika persyaratan pada suatu proyek berubah "dengan cepat" dan Anda tidak memiliki sarana untuk memantau pelaksanaan setiap persyaratan individu dengan fitur atau modul, muncul pertanyaan: bagaimana menganalisis cakupan? Salah satu alat yang digunakan tim QA kami pada proyek tersebut adalah matriks keterlacakan.
Saat ini, kami telah menggunakan matriks selama lebih dari 2,5 tahun. Selama waktu ini, kami dapat mengevaluasi kelebihan alat ini, serta menyesuaikannya dengan proyek kami.
Apa itu matriks keterlacakan?
Menurut definisi, matriks keterlacakan adalah tabel dua dimensi yang berisi korespondensi persyaratan fungsional produk (persyaratan fungsional) dan kasus uji yang disiapkan (kasus uji).
Di persimpangan baris dan kolom yang sesuai, tanda ditempatkan menunjukkan bahwa persyaratan ini dicakup oleh kasing uji ini.
Dengan demikian, tabel memberikan tampilan visual dari dua parameter:
- keberadaan dalam sistem persyaratan yang belum tercakup (jika persyaratan tidak memiliki persimpangan tunggal dengan kasus uji (kondisi yang memadai);
- Apakah ada pengujian berlebihan dalam sistem - jika persyaratan memiliki beberapa persimpangan (kondisi yang diperlukan).
Dalam proyek kami, kami menggunakan matriks keterlacakan tidak hanya untuk mengevaluasi cakupan, tetapi juga untuk menentukan hubungan antara tugas pengembangan, persyaratan, dan artefak uji.
Oleh karena itu, matriks memiliki bentuk tabel, setiap barisnya berisi:
- nomor dan deskripsi tugas pengembangan dari tugas pelacak;
- blok logis tempat tugas (opsional);
- persyaratan atom atau kriteria penerimaan;
- prioritas;
- nomor dan deskripsi artefak tes yang sesuai.
Karena kami menggunakan pelacak tugas Jira, Zephyr oleh Jira untuk dokumentasi pengujian dan sistem manajemen persyaratan pertemuan, semua entitas disinkronkan dan penelusuran ini memungkinkan kami untuk:
- memvisualisasikan kondisi implementasi saat ini;
- memecah persyaratan menjadi lebih banyak atom dan menyusunnya;
- untuk memantau apakah ada persyaratan yang pengembangannya belum direncanakan (pass implementasi);
- memantau apakah persyaratan saat ini diterapkan;
- memantau apakah persyaratan dicakup oleh uji kasus (skipping testing);
- Visualisasikan prioritisasi persyaratan.
Opsi hubungan dalam matriks keterlacakan
Persyaratan pengikatan dan kasus uji dapat:
- 1 banding 1 (persyaratan atom, yang dicakup oleh satu test case, test case ini hanya mencakup persyaratan ini);
- 1 to n (persyaratan yang dicakup oleh beberapa kasus uji, kasus uji ini hanya mencakup persyaratan ini);
- n ke n (persyaratan yang dicakup oleh beberapa kasus uji, kasus uji ini mencakup persyaratan ini dan lainnya).
Mengenai poin terakhir, saya ingin mencatat itu
- ketika satu persyaratan dalam matriks keterlacakan dicakup oleh beberapa tes, ini mungkin mengindikasikan redundansi pengujian. Dalam hal ini, perlu untuk menganalisis seberapa atom persyaratannya.
- jika dengan melakukan semua kasus uji kami memastikan kelengkapan cakupan, dan kasus uji itu sendiri tidak saling menduplikasi, ini tidak akan menjadi pengujian yang berlebihan.
Kami memiliki kasus pada proyek di mana satu persyaratan dicakup oleh beberapa tes dan satu tes dapat mencakup beberapa persyaratan ("1 ke n" dan koneksi "n ke n").
Spesifisitas estimasi cakupan menggunakan matriks keterlacakan
Jika kita menggunakan metrik “rasio jumlah persyaratan dengan jumlah artefak uji” untuk mengevaluasi cakupan, maka hubungan dalam matriks harus “1 banding 1” dan persyaratan harus didekomposisi secara maksimal.
Sebuah contoh Kami memiliki persyaratan non-atom: "Pengguna harus dapat mengubah dan memformat surat dalam editor teks." Satu test case jelas tidak akan cukup, tetapi jika hanya satu artefak yang terhubung dalam matriks, secara visual akan ada ide bahwa persyaratan tersebut tercakup.
Karena itu lebih baik:
- bagilah persyaratan ini dalam matriks menjadi fungsi atom yang terpisah dari editor teks;
- tulis kriteria penerimaan untuk setiap fungsi;
- buat artefak uji untuk setiap kriteria;
- jika beberapa persyaratan atom dapat dicakup oleh satu daftar periksa, Anda tidak dapat melakukan fragmentasi berlebihan, menghemat sumber daya.
Dengan kekurangan sumber daya untuk dekomposisi maksimum, Anda dapat menggunakan persyaratan non-atom, tetapi untuk memenuhi masing-masingnya, Anda perlu membuat beberapa artefak uji.
Dalam hal ini, kasus uji dan daftar periksa untuk setiap persyaratan non-atomik dikompilasi pada suatu waktu, yaitu, setiap persyaratan dalam matriks dapat sepenuhnya ditutupi oleh artefak atau tidak tercakup sama sekali.
Ketika menyusun matriks, disarankan untuk mematuhi rekomendasi bahwa dekomposisi setiap persyaratan dalam matriks tunggal harus kira-kira sama, yaitu, satu tabel tidak boleh berisi persyaratan, beberapa di antaranya memerlukan 5 kasus uji, dan sebagian - kasus uji sebagian.
Skor cakupan dalam kasus ini dihitung secara terpisah untuk setiap matriks.
Karena dokumentasi proyek kami mungkin memiliki tampilan yang berbeda untuk setiap fitur, dan bahkan deskripsi satu fitur dapat berisi UML, diagram, diagram kasus pengguna dan transisi, dan proyek tersebut berisi lebih dari 40 fungsi produktif, kami memutuskan untuk mengembangkan matriks terpisah untuk setiap modul atau fitur sehingga Jangan kehilangan kelebihan alat ini.
Skor cakupan juga dihitung secara terpisah untuk setiap modul atau fitur.
Dengan pendekatan ini, kita dapat menggunakan metrik yang dijelaskan di atas: "jumlah persyaratan untuk jumlah artefak uji". Bahkan jika kita memiliki koneksi 1 ke n, n ke n, kita memiliki beberapa komponen, yang masing-masingnya dapat digunakan dalam beberapa modul. Persyaratan dan kriteria penerimaan dijelaskan dalam setiap matriks, dan satu artefak uji digunakan.
Matriks kami juga disimpan dalam sistem manajemen persyaratan Confluence - setiap matriks terletak dengan struktur sebagai halaman anak dari fitur yang dikembangkannya. Juga, semua matriks dikumpulkan pada satu halaman untuk memudahkan dalam menilai cakupan seluruh aplikasi.
Membuat dan memelihara matriks
Membuat matriks termasuk dalam alur kerja kami pada tugas analitik.
Ketika kami menerima informasi tentang fitur baru, analis tim kami membuat tugas di pelacak tugas dan, bersama dengan pemilik produk, berfungsi sebagai bagian dari tugas ini di pihak pelanggan. Dalam proses mengumpulkan dan menyusun persyaratan, seluruh tim melakukan peninjauan dan mengajukan pertanyaan tambahan. Ketika persyaratan dirumuskan, didokumentasikan dan dikonfirmasi oleh pelanggan, pemimpin tim pengembangan membuat tugas untuk pengembangan fitur ini, dan tim pengujian dapat mulai membuat matriks jejak.
Dan di sini kita dapat membedakan tahap-tahap berikut dalam menyusun Matriks Traceability:
- Pada awalnya, persyaratan diuraikan dan diprioritaskan oleh perintah QA dan / atau pemilik produk. Hasil dari langkah ini adalah daftar semua persyaratan untuk fungsi ini yang terstruktur dan diprioritaskan.
- Tahap kedua adalah komunikasi dengan tim pengembangan dan menugaskan tugas dari tugas pelacak untuk pengembangan dalam matriks dengan persyaratan yang relevan. Sebagai hasilnya, kami dapat melacak keterlacakan persyaratan dan tugas pengembangan.
- Tahap ketiga adalah pengembangan kasus uji dan daftar periksa.
Tahap ini dilakukan baik sebelum pengujian atau selama pengujian tugas tertentu.
Jika fungsionalitasnya baru, dan antarmuka akan berubah, maka mungkin ada kasus di mana langkah-langkah terbaik dijelaskan segera sebelum menguji tugas.
Jika fungsionalitas implementasi mirip dengan salah satu fitur yang ada, maka kita dapat mulai mendeskripsikan kasus pengujian dengan langkah-langkah segera setelah meninjau dan mendekomposisi persyaratan. - Tahap 4 - mengisi matriks dengan kasus uji.
Berdasarkan hasil seluruh proses, kami mendapatkan tugas pengembangan, uji kasus untuk pengujian dan matriks keterlacakan yang menggabungkan mereka dan persyaratan.
Tugas mengembangkan persyaratan sedang ditutup. - Tahap 5 - mempertahankan matriks dalam kondisi saat ini. Perubahan harus dilakukan untuk setiap modifikasi pada persyaratan. Anda juga harus mempertimbangkan hubungan integrasi antara dua matriks yang menggambarkan berbagai fitur atau modul, dan ketika mengubahnya, pastikan untuk memeriksa apakah ada kebutuhan untuk mengedit yang kedua.
Kesulitan dalam bekerja dengan matriks keterlacakan
- Aktualisasi
Matriks akan berguna hanya dengan syarat bahwa ia akan selalu diperbarui. Pada proyek kami dengan persyaratan yang sering berubah, memperbarui membutuhkan banyak waktu, tetapi jika matriks tidak diperbarui, itu tidak hanya menjadi tidak berguna, tetapi juga membingungkan.
Cara memutuskan :
Sebagian memecahkan masalah dengan perubahan yang sering pada persyaratan dan mengalihkan tahap pembuatan matriks ke saat ketika persyaratan telah ditinjau oleh tim dan dikonfirmasi oleh pelanggan.
Tim memutuskan bahwa analis akan memperbarui persyaratan tidak hanya pada halaman dengan deskripsi fitur, tetapi juga menemukan dan memperbaruinya dalam matriks, menyoroti dalam warna yang berbeda. Ini membantu seluruh tim untuk tidak kehilangan perubahan, dan khususnya tim QA - untuk melihat kasus uji mana yang perlu diperbarui. - Sumber daya sementara
Proyek mungkin memiliki rilis mendesak dan bekerja dengan persyaratan baru pada saat yang sama, dan semua sumber daya QA dikirim untuk pengujian, dan tidak bekerja dengan persyaratan. Dengan demikian, utang bertambah menurut dokumentasi uji.
Cara memutuskan :
Jika semua spesialis QA sibuk menguji tugas-tugas prioritas, kami mentransfer pembuatan matriks untuk fitur tertentu. Sebanyak mungkin, itu ditransfer ke saat pengujian tugas pertama untuk fitur ini, dan dalam hal ini matriks diisi dengan kasus uji saat Anda menguji tugas di mana fitur tersebut diimplementasikan.
Spesialis QA menetapkan waktu penilaian tidak hanya untuk menulis kasus uji sendiri, tetapi juga waktu untuk mengembangkan matriks. - Efisiensi
Jika proyek ini kecil dan semua persyaratan dibingkai dalam bentuk Kerangka Acuan yang terstruktur, dan uji kasus dibuat untuk setiap persyaratan sekaligus, matriks keterlacakan dalam formulir kami hanya akan menggandakan informasi dan akan menjadi pemborosan sumber daya.
Oleh karena itu, Anda perlu menggunakan matriks standar yang dijelaskan dalam definisi untuk mengevaluasi cakupan.
Fasilitas
- Matriks ini memungkinkan Anda untuk memantau implementasi persyaratan, melacak bahwa semua persyaratan dikembangkan dan diuji dan tidak ada yang hilang.
- Matriks membantu tim QA melacak apakah ada hutang pada dokumentasi pengujian, dan persyaratan spesifik apa yang belum tercakup oleh kasus uji.
- Alat ini digunakan oleh analis dan tim QA untuk memantau persyaratan yang diubah.
- Pada proyek tersebut, matriks keterlacakan tidak hanya digunakan oleh kami, tetapi juga oleh pemilik produk di pihak pelanggan. Jadi mereka memastikan bahwa semua persyaratan ada di sana dan mereka benar, dan dilacak menggunakan matriks, yang telah diterapkan. Matriks memungkinkan kami untuk membuat proses pengembangan dan pengujian agak transparan.