Get best of the week

Tes penilaian: bagaimana cara menghitung waktu yang tepat untuk menguji sistem atau "Kapan tes akan siap?!"

gambar

Hari baik untuk semua! Nama saya Denis, saya adalah kepala layanan pengujian di BARS Group. Ini adalah posting pertama saya di Habré.

Setelah membaca banyak artikel menarik dan mendapat banyak informasi berguna dari sana, saya ingin memberikan sesuatu sebagai balasannya. Kemudian saya mulai menganalisis topik: beberapa sudah disuarakan, yang lain terlalu sederhana ("bagaimana cara masuk TI?"). PS Saya tidak ingin melukai perasaan siapa pun :)

Cara menghitung waktu untuk tes - masalah dan solusi


Sebagai kepala layanan, saya terus-menerus menemukan pertanyaan dari manajer: "Kapan akan siap?" atau "Berapa lama untuk menguji?" Tampaknya ini rumit, ambil penilaian dari proyek sebelumnya dan plus atau minus hal yang sama ... tetapi tidak. Saya menyadari bahwa tugas itu tidak sepele dan memerlukan studi rinci. Dan saya ingin membagikan keputusannya.

Perusahaan kami memiliki banyak pusat bisnis dan masing-masing memiliki pendekatan pengembangan sendiri - terutama Kanban dan Scrum. Oleh karena itu, tim penguji otomatis telah dipilih, yang disinkronkan dengan tim pengembangan dengan metodologi mereka.

Karena pendekatan yang berbeda untuk manajemen pembangunan, kesulitan muncul dalam keseragaman pembentukan tugas dan perencanaan. Penggunaan Kanban dan Scrum dalam bentuknya yang murni tidak memberikan jawaban berapa lama waktu yang dibutuhkan untuk menguji. Dalam keputusan desain, setiap kali perlu untuk mengevaluasi fungsionalitas baru dan menutupinya dengan tes. Saya butuh banyak waktu untuk menghitung. Oleh karena itu, saya memutuskan untuk mengambil metode untuk memperkirakan biaya waktu untuk pengembangan perangkat lunak (untuk pengujian otomasi) sebagai dasar dan memodifikasinya agar sesuai dengan kenyataan saya. Prinsip penilaian rata-rata tertimbang dan perhitungan berdasarkan pengetikan membentuk dasar. Estimasi akan menjadi indikator sementara untuk otomatisasi elemen khas sistem, dan tingkat pelatihan spesialis akan digunakan sebagai bobot. Saat membentuk nilai bobot, saya memilih keakuratan penilaian saat melakukan tugas, yaitu, semakin berpengalaman spesialis,semakin kecil kesalahan estimasi. Nilai-nilai berikut diperoleh:

  • "Senior" - Akurasi 95%, faktor 1,05
  • "Tengah +" - Akurasi 80%, faktor 1.2
  • "Tengah" - akurasi 70%, koefisien 1.3
  • "Junior +" - 60% akurasi, koefisien 1.4
  • Junior - akurasi 50%, faktor 1.5

Selanjutnya, kita perlu melipatgandakan estimasi waktu t n dengan koefisien W n yang sesuai . Metode perhitungan kami dilakukan sesuai dengan rumus, di mana jumlah bobot tidak sama dengan 1 (100%).

gambar

W rata-rata = (w 1 * t 1 + w 2 * t 2 ... + w n * t n ) / (w 1 + w 2 + ... + w n )

Untuk perhitungan, saya mengambil dua tes - pengujian fungsional dan UI, karena mereka total sekitar 85%.

Untuk mendapatkan hasil akhir, kita perlu mengumpulkan skor rata-rata tertimbang untuk setiap elemen menjadi objek yang lebih besar untuk perhitungan - kategori.

Pengujian UI


Saat menguji UI, Anda harus meniru pekerjaan pengguna melalui kerangka Selenium.Webdriver. Saat menggunakan pendekatan ini, ada kesulitan untuk membangun elemen pada formulir: tab, dokumen dengan pengeditan online, kisi besar dengan garis, struktur pohon, dll. Selain elemen-elemen ini, ada juga faktor yang mempengaruhi waktu pengembangan pengujian:

  • Struktur bentuk (konstruktor atau kebiasaan khusus)
  • Permintaan AJAX (nomor mereka)

Berdasarkan hal ini, 3 kategori formulir UI dibedakan oleh kesulitannya dalam melaksanakan tes:

1 kategori



2 kategori



3 kategori



Sebagai hasilnya, saya menerima hasil berikut, yang disajikan dalam tabel:



Pengujian fungsional


Untuk tes fungsional, situasinya mirip dengan UI - kategori untuk sistematisasi kasus disorot. Selain layanan REST, ada baiknya menyebutkan tentang SOAP, itu akan mirip dengan 3 kategori REST.

Pengujian integrasi melibatkan pengujian beberapa metode dalam satu layanan, untuk penilaian perkiraan kami mengambil keberadaan 5 metode per 1 layanan.

1 kategori



2 kategori



3 kategori



Mirip dengan tabel UI:



Pengujian integrasi memeriksa operasi layanan yang dibangun pada REST dan SOAP. Saat mendesain layanan, jumlah metode yang digunakan di dalamnya dapat bervariasi. Untuk perhitungan, kami mengambil rata-rata 5 metode.



Dengan perhitungan waktu yang dihabiskan untuk proyek ini, persentase untuk masuk ke perkiraan ini adalah 81.

Alih-alih sebuah kesimpulan


Butuh satu minggu kerja keras untuk menghitung pertama kalinya. Oleh karena itu, saya melakukan evaluasi setelah pengujian dan kemudian membandingkan hasilnya dengan biaya waktu nyata.

Cukup melakukan pekerjaan utama satu kali dan kemudian mempertimbangkannya sesuai dengan “formula” yang sudah jadi. Tetapi Anda perlu memperhitungkan fakta bahwa tingkat karyawan meningkat, jadi Anda perlu memahami bobot setiap karyawan untuk mengetahui apakah akan menghitung ulang indikator.
Semua hal di atas adalah pengalaman saya dan tidak mengaku benar.

More articles:


All Articles