Halo, warga Habrovsk!
Saya memutuskan untuk menulis artikel tentang proses interaksi antara penguji dan analis kami dan tentang bonus yang diterima perusahaan SuperJob dari proses ini.
Pekerjaan penguji dengan persyaratan terdiri dari tiga tahap: Tinjauan FT, Penutupan FT, Tinjauan Kasus.
Ulasan FT
Persyaratan dipertahankan oleh analis di Arsitek Perusahaan, dan dari sana disalin ke Confluence. Setelah persyaratan tertulis, mereka dikirim untuk ditinjau oleh penguji.
Sementara interaksi ini dilakukan melalui Google Sheets, di mana ada:
- Nama FT
- Tautan ke FT
- Bertanggung jawab untuk Analis FT
- Status dari Analis
- Penguji yang bertanggung jawab
- Status dari penguji
Analis meletakkan status "Pada Tinjauan" dalam paragraf yang sesuai dari tabel:
Pada tahap ini, sebagai bagian dari Confluence, pertanyaan diajukan tentang poin persyaratan tertentu, karena fungsi ini memungkinkan Anda untuk menambahkan komentar ke bagian teks yang sewenang-wenang. Dalam komentar, diskusi sedang berlangsung, sebagai akibatnya FT diperbarui.
Setelah persyaratan ditambahkan dan diperbarui, persyaratan dipindahkan ke pengembangan dan pengujian.
Cakupan FT
Test case ditulis dalam TestRail, arsitektur penyimpanan test case mengulangi persyaratan arsitektur penyimpanan. Ini diperlukan untuk kemudahan pencarian, dan agar tidak menemukan kembali sepeda Anda, lebih mudah untuk mengambilnya dari tetangga analis.
Pengujian mencakup persyaratan - setiap item persyaratan, setiap penawaran ditanggung.
Setiap item persyaratan diberi nomor, ada jejak kasus uji untuk item persyaratan. Secara terpisah, saya ingin mencatat bahwa dalam setiap kasus ada versi FT yang ditulis pada kasus ini - persyaratan dapat berubah dan poin di dalamnya juga, jika Anda tidak memperhitungkan versi FT, maka Anda tidak dapat menemukan ujungnya.
Dengan cara ini:
- Sangat mudah untuk memeriksa kualitas cakupan kasus. Di depan mata saya bukan selembar 50 case dan lembar FT yang sama di dekatnya, tetapi Anda memilih satu titik persyaratan dan kemudian Anda melihat kasus mana yang menutupi titik tertentu ini;
- Jika terjadi perubahan persyaratan, Anda dapat segera melihat kasus mana yang perlu diperbaiki.
Kasing ditulis dalam tiga versi:
- Kasing pos (sebagian besar). Ketika kasus hanya memiliki judul, yang jelas apa yang perlu dilakukan. Mereka lebih cepat menulis daripada uji kasus terperinci dan pada saat yang sama liputan transparan:
- Uji kasus. Kasing uji rinci dengan langkah-langkah ketika ada banyak nuansa dalam kasing dan semuanya tidak dapat dimasukkan ke dalam pos;
- Kasing, daftar periksa. Ketika sebuah kasus terdiri dari daftar periksa untuk memeriksa beberapa arah fungsi. Untuk menyorot kasus seperti itu, gunakan di header (kasing):
Di bagian FT, di mana ada mock-up, test case "Rekonsiliasi dengan tata letak M ..." dibuat. Ini berfungsi hanya sebagai pengingat bahwa ada tata letak dan implementasi harus diverifikasi dengannya. Kasus ini tanpa deskripsi internal - daftar periksa untuk rekonsiliasi dengan tata letak yang telah kami jelaskan dalam peraturan.
Ulasan Kasus
Setelah menulis kasus, status "Tinjauan Kasus" dimasukkan ke dalam tabel umum, ini adalah tanda bahwa tester lain dapat mengambil FT ini dan melakukan tinjauan kasus. Hal ini diperlukan agar kasing sama-sama jelas untuk semua penguji dan agar dapat memenuhi persyaratan dengan tampilan yang segar.
Dalam hal bagian ulasan yang tidak berhasil, misalnya, pertanyaan baru yang muncul di FT atau cakupan tidak mencukupi - persyaratan ditransfer ke status "Finalisasi". Tidak ada cukup komentar di TestRail untuk menggambarkan semua keinginan Anda - sementara ini terjadi secara tertulis di Slack, yang tidak terlalu nyaman untuk dilacak.
Jika tinjauan berhasil, FT berada dalam status "Selesai".
Dalam kasus yang jarang terjadi, ketika persyaratan diperbarui setelah menulis kasus pengujian pada mereka, FT dipindahkan ke status "Diperbarui". Selain itu, tester yang mencakup FT berlangganan pembaruan ke halaman Confluence. Jika persyaratan telah banyak berubah, tugas dibuat untuk tester untuk memperbarui kasus.
Kesimpulan
Apa yang memberi kita pendekatan ini?
- Pertama, persyaratan yang terbukti termasuk dalam pengembangan. Ini menghemat waktu pengembang, yang tidak terjangkau oleh ketidaklogisan, kekurangan dan tiang tembok;
- Kedua, penguji sedang mempersiapkan pengujian yang paralel dengan pengembangan, jadi kami mengurangi waktu yang dibutuhkan untuk merilis fitur. Penguji dapat dengan tenang dan bertanggung jawab mendekati proses penulisan kasus, dan tidak dalam format "Ahhh, fitur besar telah jatuh, Anda harus menuangkannya malam ini. Ayo tes lebih cepat! "
- Ketiga, ini adalah peningkatan kualitas pengujian karena peninjauan kasus. Katakan “Tidak!” tampilan kabur.
Apa yang tidak suka?
- Ada kesenjangan waktu yang agak besar antara menulis kasing dan menjalankannya pada fitur - meskipun kasing siap dan hanya dapat diperiksa, penguji tetap berada di luar konteks;
- Seperti yang saya tulis sebelumnya - di TestRail tidak ada cukup komentar, seperti di Confluence - Anda tidak bisa hanya mengambil dan menandai tempat masalahnya, meninggalkan komentar untuk itu.
Itu saja untuk saat ini. Terima kasih atas perhatian anda!
Dan bagaimana proses bekerja dengan kebutuhan Anda?