Temui penulis artikel Juli untuk "Kalender Penguji " Andrei Marchenko dan Marina Tretyakova, penguji dan analis Kontur. Bulan ini, orang-orang akan berbicara tentang model alur kerja untuk pengujian analitik, dan bagaimana mereka memulai pengujian analitik sebelum tahap pengembangan. Pengalaman para lelaki ini akan bermanfaat bagi para manajer, penguji, dan analis tim produk menengah yang tidak hidup dalam startup dan bagi siapa kualitas lebih penting daripada kecepatan .

Analisis Pengujian Model Alur Kerja

Model 1

Penguji bekerja dengan analitik setelah ia diberi tugas selesai. Dia memvalidasi tugas dengan membaca analitik sebagai dokumentasi dari apa yang dilakukan pengembang. Semuanya salah, terlepas dari tingkat profesionalisme. Cacat bisa dalam analitik atau dalam kode pengembang.

Cons:

• cacat dalam analitik tidak akan terdeteksi sebelum tahap pengujian,
• ada risiko bahwa tugas dari pengujian akan kembali ke analytics untuk revisi. Akibatnya, tugas TimeToMarket meningkat secara signifikan.

Kesalahan analisis yang diidentifikasi selama pengujian mahal atau sangat mahal.

Pro:

• waktu penguji berkurang untuk tugas-tugas di mana analis tidak diperlukan (infrastruktur, refactoring).

Model 2

Penguji terhubung ke tugas bahkan sebelum dipindahkan ke pengembangan. Dia melihat prototipe pada tugas atau hanya membaca dokumentasi. Penguji menanyakan analis semua pertanyaan pada tugas. Analis segera mengoreksi komentar. Penguji membuat tes penerimaan.

Cons:

• tester harus mempelajari bidang yang berdekatan (merancang analisis dan TK),
• beralih ke model ini, tester terlebih dahulu harus menghabiskan lebih banyak waktu pengujian, karena proses "tugas selesai tiba - saya membaca analitik - saya menguji" membentang ke "deskripsi tugas masa depan tiba - saya membaca analitik - saya pengujian analitik - tugas selesai tiba - saya pengujian".

Pro:

• probabilitas menemukan kesalahan analitik setelah tugas ditransfer ke pengembangan menjadi kurang
• tester sudah dalam konteks tugas, ketika sampai kepadanya untuk pengujian, oleh karena itu dia memeriksanya lebih cepat,
• pengujian analytics dengan sempurna memperluas cakrawala, memberikan kesempatan kepada spesialis untuk transisi ke analitik di masa depan,
• pengembang meningkatkan kualitas kode dan produknya secara keseluruhan, karena sebelum lulus solusi untuk pengujian, ia lulus tes penerimaan.

Jika tim pengembangan tidak memiliki tinjauan terhadap pekerjaan analis, pengujian analitik meningkatkan kualitas produk dan mengurangi risiko mentransfer tugas ke pengembangan dengan kesalahan dalam Kerangka Acuan.

Ketika kami merekomendasikan model kedua kepada penguji yang mengerjakan model pertama, kami sering mendengar:

• "Kami telah mengantri dan memiliki tugas saat ini yang cukup untuk mengambil lebih banyak."
• "Bicaralah dengan manajer."

Mendesain ulang proses pengembangan adalah tugas manajerial yang serius.

Laksanakan pengujian analitik sebelum pengembangan

Selama hampir satu tahun, seperti dalam proyek Kontur, standar dalam proses pengembangan adalah tahap wajib “pengujian analitik”. Tim tidak segera datang ke sini. Dorongannya adalah peningkatan jumlah pengembalian tugas dari pengujian ke tahap analitik dan penyempurnaan lebih lanjut.

Itu sangat menyakitkan untuk tugas-tugas besar dengan fungsi baru. Tugas-tugas front-end yang ditransfer ke fase pengujian adalah mentah, sering gagal pada skenario paling sederhana, diimplementasikan secara berbeda mengingat “dua kali lipat” definisi dan istilah dalam analitik.

Proses pengujian analitik tidak muncul di klik jari atau jenis sihir apa pun. Ini adalah pekerjaan yang melelahkan, tetapi dapat dibagi menjadi beberapa tahap.

Tahap 0. Jual tim ide pengujian analitik

Anda dapat dengan mudah membayangkan situasi ketika Anda tiba-tiba menerima umpan balik dari pekerjaan Anda dengan komentar, saran, dan koreksi. Pikiran pertama orang normal adalah: “Mengapa Anda memutuskan untuk menguji saya? Mereka tidak percaya padaku? Mereka memantau kualitas pekerjaan saya? " Pada tahap ini, sangat penting bahwa analis tidak memiliki perasaan bahwa dia sedang diperiksa untuk kualitas, dan, dalam hal tes gagal, mereka akan dipecat.

Sejumlah pertanyaan dapat dihilangkan jika informasi tersebut disajikan dalam kunci: "ini akan memberi kita kesempatan untuk mempelajari fungsionalitas baru sebelumnya, mempercepat fase pengujian, dan mencegah pengenalan bahkan cacat kecil dalam kode."

Ketika tahap 0 selesai, Anda dapat melanjutkan.

Tahap 1. Implementasi pengujian analitik dalam proses pengembangan

Setelah meyakinkan tim, kami mulai memperkenalkan pengujian analitik ke dalam alur kerja harian. Jika awalnya alur kerjanya tampak seperti ini:

Itu setelah implementasi:

Jika tim Anda memiliki beberapa analis yang melakukan peninjauan satu sama lain sebelum memberikan tugas kepada pengembangan, maka kami melanjutkan untuk menguji teks yang lebih baik. Kami bermaksud bahwa tinjauan analitik tidak mengujinya, tetapi hanya sebagian saja.

Tahap 2. Pengujian analitik

Ada tugas ketika prototipe mengganti versi teks analitik.

Dalam hal ini, prototipe juga diperiksa sebagai teks. Jika prototipe melengkapi analitik, akan bermanfaat untuk melihat tata letak desain fungsionalitas masa depan sebelum membaca dokumentasi. Ini adalah satu-satunya kesempatan Anda untuk melihat tugas sebagai pengguna yang belum membaca TOR dan tidak tahu cara kerja semuanya dan harus bekerja.

Apa yang dapat diperiksa dalam analytics:

1. Solusi yang diusulkan memenuhi tujuan tugas.

Misalnya, jika tujuan tugas adalah untuk mengumpulkan umpan balik dari pengguna, maka solusinya harus melibatkan perekaman dan penyimpanan tanggapan pengguna.

2. Keunikan interpretasi.

Misalnya, kata-kata "tampilkan informasi untuk hari ini" dapat diartikan berbeda. Anda dapat memahami bagaimana "menampilkan informasi untuk hari yang dipilih dalam pengaturan," atau sebagai "menampilkan informasi untuk hari yang sama hari ini."

3. Kelayakan keputusan.

Kelayakan adalah kemampuan untuk mengimplementasikan persyaratan yang ditulis dalam analitik di bawah batasan terkenal dari lingkungan pengembangan, bahasa pemrograman, dan kompleksitas algoritmik. Analis yang baik dapat mengingat algoritma yang dengannya mereka dapat memecahkan masalah yang mereka tulis. Bukan fakta bahwa pengembang akan melakukan sesuai dengan algoritma ini (mereka lebih berpengetahuan, mereka akan menemukan cara untuk membuat algoritma optimal, dll.), Tetapi keberadaannya menunjukkan kelayakan tugas.

4. Pengujian.

Cara memverifikasi bahwa kondisi "meningkatkan hasil pencarian" terpenuhi tidak jelas. Tetapi jika kita menulis ulang kondisi pada "hasil pencarian akan ditampilkan kepada pengguna dalam waktu 1 detik setelah menekan kontrol" Pencarian "- itu jelas.

5. Ketersediaan skenario alternatif.

Dalam kata-kata “Jika nomor dan tanggal diindikasikan, maka kami mencetak nomor dan tanggal. Jika tanggal tidak ditentukan, kami hanya mencetak angka "tidak ada skrip yang cukup:

• tidak ada nomor, tetapi ada tanggal,
• tidak ada data.

6. Penanganan pengecualian.

Dalam kata-kata "Anda dapat mengunduh dokumen hanya dalam format Excel" tidak jelas apa yang harus terjadi jika kita mengunggah file format lain, dan kesalahan apa yang akan kita lihat saat mengunduhnya.

Artefak saat menguji analitik

Artefak apa yang tersisa setelah pengujian analitik:

• kompilasi kasus uji
• daftar periksa untuk pengembang.

Daftar periksa untuk pengembang - pemeriksaan dasar yang diperlukan, komprehensif, dan mendasar dari skenario utama yang harus berfungsi agar dapat diuji. Ini juga alat untuk meningkatkan kualitas kode. Sebelum mengirimkan tugas untuk pengujian, pengembang melewati daftar periksa, dengan cepat mengidentifikasi bug sendiri.

Pengembang harus dibujuk untuk memeriksa daftar periksa tester, menghilangkan kekhawatiran batin pengembang "mereka menguji saya", dengan fokus pada "mempercepat proses, mempercepat pengujian, meningkatkan kualitas". Akibatnya, pengembang kami memeriksa daftar periksa ini dan bersukacita bahwa bukan penguji yang menemukan kesalahan, tetapi dia sendiri ("tidak ada yang akan tahu apa yang saya lakukan dalam skenario omong kosong").

Apa hasilnya

Sekilas, tampaknya memperkenalkan tahap baru dalam proses pengembangan hanya akan meningkatkan TimeToMarket, tetapi ini hanya ilusi. Pada awalnya, tentu saja, proses pengujian analitik akan menjadi baru dan belum teruji, dan tester akan menghabiskan lebih banyak waktu untuk itu. Di masa depan, mendapatkan pengalaman, ia akan dapat melakukannya dengan lebih cepat. Dan hasil yang diperoleh pada tahap pengujian analitik akan mengurangi waktu pada tahap pengujian langsung dan mengurangi jumlah pengembalian seminimal mungkin.

Proses pengujian analitik ini telah diterapkan di beberapa tim Kontur. Tim pengembangan menerima sejumlah keuntungan yang tidak dapat disangkal:

• menghemat waktu pada tahap pengujian: tidak ada biaya untuk desain pengujian dan analitik pengujian, karena semuanya telah dilakukan sebelumnya,
• mempercepat umpan balik kepada pengembang melalui daftar periksa, sebelum kami menemukan bug penting,
• semua pihak yang berkepentingan dapat melakukan pra-periksa daftar periksa dan menambahkan beberapa cek (pada tahap pengujian tindakan ini "lebih mahal").

Kami percaya bahwa Anda akan dapat memperoleh manfaat ini dengan menerapkan fase pengujian analitik di proyek Anda.

Daftar artikel kalender:
Coba pendekatan yang berbeda
Pengujian pasangan yang wajar
Umpan balik: bagaimana itu terjadi
Optimalkan Tes
Baca buku
Pengujian analitik
Penguji harus menangkap bug, membaca Caner dan mengatur gerakan.
Muat layanan
Metrik Layanan QA
Uji keamanan
Kenali pelanggan Anda
Ambil backlog