Apa ukuran efisiensi pengujian / tester yang baik?

11

Saya akan berpartisipasi dalam diskusi dengan manajemen mengenai pengukuran efisiensi pengujian kami sebagai organisasi QA. Alasan utama di balik ini adalah bahwa setengah dari tim kami dikontrakkan dan bisnis kami ingin memberikan beberapa metrik seberapa efektif / efisien kami, sehingga kami memiliki data dasar untuk menegosiasikan parameter kontrak dengan perjanjian layanan dari kontraktor kami .

Saya telah menyodok sedikit dan sebagian besar pendapat yang saya temukan tentang hal ini berkisar pada efisiensi pengembang: baris kode, poin cerita yang disampaikan, cacat diperkenalkan, dll.

Tapi bagaimana dengan penguji? Pengujian kami sebagian besar berdasarkan persyaratan, dan campuran pengujian manual, semi-otomatis, dan otomatis (bukan karena kami belum sempat mengotomatisasi semuanya, tetapi karena beberapa hal tidak dapat diotomatiskan dalam sistem pengujian kami).

testing efficiency qa metrics

— Randy
sumber

1

stevemcconnell.com/ieeesoftware/bp09.htm mungkin berguna dalam beberapa cara.

Ini aneh. Jika Anda telah menguji gmail.com dan Anda gagal menemukan satu pun cacat, apakah Anda pikir Anda gagal? Jika Anda menulis sejuta uji untuk sesuatu yang sangat remeh, menurut Anda apakah itu membuat Anda sukses? Cari Kebocoran Cacat yang berarti cacat yang tidak dikenal selama SIT dan lolos dari UAT. Ada cara lain QA menambah nilai pada SDLC keseluruhan.

8

Jumlah tes yang ditulis tidak berguna, dan sejumlah besar bug yang ditemukan dapat menjadi ukuran perkembangan yang buruk daripada QA yang efisien.

Tindakan otomatisasi (cakupan kode, cakupan fitur ...) bisa bagus, tapi saya pikir mereka lebih membantu untuk pengembangan (sebagai pengembang, akankah saya tahu jika saya memecahkan sesuatu secara tidak sengaja) daripada pelanggan (saya ingin melakukan itu dan tidak berhasil).

Karena kualitas baik jika pelanggan tidak menemui masalah, maka ukuran efektivitas (bukan efisiensi) tim dan proses QA yang baik adalah ukuran bug yang ditemukan oleh pelanggan yang belum ditemukan oleh QA .

Masalah utama dengan metrik itu adalah bahwa mungkin ada penundaan yang cukup besar antara pekerjaan yang dilakukan dan ketika Anda mulai memiliki angka yang bermakna.

— ptyx
sumber

1

+1 pada akhirnya kepuasan pelanggan adalah metrik utama untuk seluruh tim

— jk.

Juga lihat programmers.stackexchange.com/questions/285097/…

— Pacerier

6

Ada beberapa metrik yang kami gunakan di pekerjaan terakhir saya untuk mengevaluasi QA:

Jumlah bug yang ditemukan. Aku benci yang ini. Ini seperti "Jumlah baris kode yang ditulis" untuk pengembang.
Jumlah kasus uji otomatis yang diproduksi.
Persentase dari total aplikasi yang tercakup dalam pengujian fungsional.
Jumlah bug yang ditemukan dalam pementasan vs produksi.

Pada akhirnya, tugas tim QA Anda adalah menemukan bug sebelum mereka keluar di alam liar. Metrik mereka harus didasarkan pada pencapaian tujuan tersebut. Jika ada cakupan kasus uji yang rendah, jumlah tes otomatis minimal, dan tingkat bug yang tinggi dalam produksi, maka mereka tidak melakukan pekerjaan dengan baik. Namun, jika mereka memiliki rekam jejak yang baik untuk menemukan bug jauh sebelum mereka mencapai target, metrik mereka harus cukup tinggi.

— Tyanna
sumber

3

Hanya komentar: tiga yang pertama adalah metrik manajemen, yang berarti bahwa manajer kontraktor harus mencoba mengoptimalkannya dalam waktu dekat (bulanan atau triwulanan). Namun, hanya yang ke-4 yang memiliki konsekuensi bisnis nyata, dan harus digunakan sebagai dasar tunggal untuk pembaruan kontrak. (Manajer yang buruk mungkin dapat mencetak skor sangat baik pada tiga metrik pertama dengan menggembungkan angka, tetapi masih membiarkan banyak bug bocor ke publik.) Sayangnya, ke-4 memiliki siklus pengumpulan data selama 2-3 tahun.

— rwong

pengujian fungsional harus pengujian kotak hitam , atau apakah saya salah?

— BЈовић

"Jumlah bug yang ditemukan": Ini harus menjadi ukuran yang diterapkan pada pengembang. Selain itu, Jika sebagai tester saya menjalani indikator ini, saya akan segera menjadi teman dengan pengembang yang bersedia memperkenalkan bug dalam kode yang saya uji.

— mouviciel

3

QA harus diukur dengan dua metrik utama: berapa banyak bug yang melewati QA untuk ditemukan di lapangan? Apa keparahan mereka?

Anda mungkin dapat memperbaiki QA karena menemukan bug yang parah lebih dekat untuk dilepaskan daripada dev-complete. Anda mungkin dapat melakukan QA karena tidak menyelesaikan pengujian dengan perkiraan tanggal penyelesaian (per fitur).

Meskipun pada akhirnya, saya khawatir Anda akan menghabiskan lebih banyak uang untuk mengukur efektivitas staf kontrak Anda daripada penghematan yang diperoleh dengan menggunakan staf kontrak ...

— Telastyn
sumber

0

Perusahaan tempat saya bekerja menggunakan sejumlah metrik QA.

Salah satu yang saya rasa paling relevan adalah cakupan kode. Alat seperti EMMA bekerja sangat baik ketika mereka menulis tes otomatis menyeluruh selain tes manual mereka.

Apa pun yang Anda lakukan, jangan fokus pada jumlah tes. Itu sama bermanfaatnya dengan LOC per hari.

— Christopher Lates
sumber

-1

Banyak cara untuk mengukur kinerja dalam fase pengembangan dan pengujian selama pelaksanaan proyek. Kami menggunakan langkah-langkah di bawah ini dalam proyek kami. Kinerja pengembangan diukur dengan 4 metrik Kode populer (indeks Maintainability, Kompleksitas sikometrik, Kedalaman pewarisan, Kopling kelas). Untuk C # akan mendapatkannya di Microsoft Visual Studio. Untuk cakupan tes Ncover / Ndepend sangat berguna. Menguji kinerja yang diukur dengan tidak ada bug pengembangan yang dikendalikan oleh 4 sprint terakhir Bug pengujian sistem berguling dari 4 sprint terakhir. Tidak ada uji otomatisasi yang lulus dalam rilis tertentu / Fitur yang dikirimkan.

— Balasubramanian.S
sumber