Saya menulis artikel ini di pertemuan kerja pada tahun 2013. Dan pada saat penulisan ini (2019), itu masih relevan.
Awalnya, saya menuliskan daftar periksa sebagai pengingat, termasuk kepada saya sendiri. Karena Anda harus kembali ke tugas, termasuk orang yang TIDAK memeriksanya. Misalnya, selama regresi diperlukan untuk memeriksa setidaknya fungsional dasar.
Jadi Anda membuka tugas, membuka komentar terakhir untuk melihat dokumentasi apa, apa yang berhasil, dan di sana ... Itu kosong. Atau sederhana "Semuanya dicentang, semuanya baik-baik saja." Di mana dokumentasinya? Saya tidak dalam subjek tugas, saya ingin membaca lebih lanjut!
Atau jika pelanggan menulis bahwa ada sesuatu yang tidak berhasil untuknya, dan Anda ingin memeriksa apakah situasinya dicakup oleh swa-uji. Anda pergi ke tugas, dan tidak ada tautan ke autotests. Mereka tidak menulis sama sekali? Atau hanya tidak memberikan tautannya? Saya harus mencari tahu ...
Maka daftar periksa untuk menutup tugas muncul:
- Periksa tugasnya (halo cap). Gunakan daftar periksa siap pakai untuk tugas-tugas tipikal + hindari kesalahan tipikal dalam autotests.
- Tulis dokumentasi untuknya (pengguna minimal, pengguna maks dan "untuk kolega").
- Di JIRA, tinggalkan komentar "Aku memeriksa inti perakitan, pelanggan, melihat ini, ini dan itu, ini dia."
- Lampirkan data uji ke tugas jika ada yang diperiksa secara manual.
Ini semacam "tentang kita," tetapi sebenarnya universal. Yah, kecuali bahwa di perusahaan Anda penguji tidak menulis dokumentasi, maka kami mengubah paragraf kedua menjadi "memeriksa bahwa semua dokumentasi yang diperlukan sudah ditulis atau diperbarui."
Kami akan menganalisis setiap item secara terpisah.
Dokumentasi
Jika tidak ada dokumentasi untuk tugas tersebut (tidak masalah apakah ini bug atau peningkatan), itu ditemukan kembali.
Jika ada dokumentasi, tetapi di JIRA tidak ada tautan ke sana di komentar terakhir, tugas itu ditemukan kembali.
(Masa sulit, tindakan keras)Kebutuhan minimum untuk menulis / memperbaiki kebutuhan pengguna.
Jika ada perubahan dalam konfigurasi proyek, Anda perlu memeriksa bahwa ada dokumentasi teknis untuk perubahan tersebut. Jika tidak, tulis.
Jika tugas migrasi ditambahkan, segera tulis instruksi umum untuk memperbarui rilis.
Komentar
Jika Anda harus kembali ke tugas nanti, terkadang berguna untuk mengetahui versi mana yang diuji oleh tester dan apa yang dia periksa (singkatnya).
Kami menulis versi dari lincah, memberikan tautan ke dokumentasi dan deskripsi singkat: Saya memeriksanya secara manual melalui antarmuka / SOAP / buffer.
Uji data
Jika tugas itu diperiksa secara manual, pastikan untuk melampirkan data uji ke dalamnya (jika mereka tidak menimbang 3TB)
Ya, data ini dapat diperoleh dari repositori bersama, tetapi di sana mereka sudah dapat diubah atau bahkan dihapus.
(Kami memiliki repositori umum dari data uji, tetapi semua file disimpan pada disk. Kami mencobanya di sistem kontrol versi, saya tidak menyukainya, tidak ada yang berkomitmen sama sekali, tetapi entah bagaimana mereka menaruhnya di disk)Terkadang sepertinya ini semua sampah, mereka membuat satu rekanan atau mengumpulkan pilihan berdasarkan tampilan.
Tetapi jika dalam setengah tahun masalah muncul di Pelanggan dan tugas-tugas lama untuk pemutaran dinaikkan, file-file ini akan banyak membantu, diverifikasi lebih dari sekali. Tetapi data aktual dari penyimpanan sudah usang.
Ingat - ini akan memakan waktu 1 menit untuk mengambil kueri sql siap dan memeriksa database. Dan lagi untuk duduk dan mengajukan permintaan ini - mungkin butuh satu jam, jika tidak lebih. Hemat waktu Anda!
Oleh karena itu:
- Membuat database dari dbStart - lampiran dbStart (excel, di mana sepotong database untuk pengujian disimpan).
- Kami mengunduh data uji dari penyimpanan - kami melampirkan file yang diunduh.
- Kami mengunduhnya dari tempat lain - kami menambahkannya ke repositori dan melampirkan ke tugas.
Lihat juga:Bagaimana cara cepat membuat database template di Maven? - tentang cara kami melakukan dbStart untuk pengujian.
Komentar tentang tes, dokumen, dan data harus final. Dan tidak begitu banyak sehingga "Saya menulis tes ini dan itu, menemukan masalah ini dan itu" dan kemudian korespondensi dengan pengembang untuk 20 komentar, dan "final" Anda tersesat di suatu tempat di tengah. Jika Anda tersesat - duplikat (yang lama dapat dihapus).
Contohnya
Ketika kami merekrut penguji baru, artikel ini tidak cukup. Karena saya menemukan kembali tugas-tugas junior dan memberi tahu bagaimana cara memperbaiki komentar akhir sehingga dapat dimengerti. Dan mereka, pada gilirannya, meminta contoh "bagaimana caranya".
Jadi dalam artikel tersebut, blok lain muncul - “Contoh”. Penting untuk memberikan tautan ke tugas nyata di jira yang berfungsi + beberapa artikel tambahan dalam pertemuan. Contohnya harus berbeda: baik untuk komentar besar ketika 200 autotest ditulis pada tugas, dan untuk tugas kecil yang akan dihadapi para pria setiap hari.
Saya tidak akan memberikan tautan, tetapi maknanya, saya harap, jelas. Bagian ini terlihat seperti ini:Contoh tugas besar di mana ada banyak dermaga dan tes:
- TEST-679 - Perbaikan JMS
- TEST-760 - Mengembalikan aliran ke berbagai sumber JMS
Contoh tugas kecil:
TEST-816 - memperpanjang model persetujuan.
Saat menguji "tambahkan fungsionalitas ke Demo", berikan perhatian khusus pada refactoring - kirimkan dokumentasi ke inti, semua tes di Demo, dan sisanya melalui inklusi, dll. Contoh:
TEST-4519 - Tambahkan rekonsiliasi silang FL-IP ke Demo.
Contoh komentar yang bermanfaat "bagaimana saya menguji ini" yang Anda kembalikan lagi (lebih baik untuk menempatkannya di HOWTO, tetapi Anda harus membiarkannya dalam tugas):
TEST-812 - Buatlah pembangunan kembali indeks tanpa pemblokiran (tempat untuk meletakkan jeda * untuk memeriksa)
* Bryak: Breakpoint (gaul) - kode breakpoint. Ini adalah ketika Anda menjalankan kode sumber dalam mode debug, titik-titik seperti itu membantu melacak parameter, untuk melokalisasi kesalahan.PS - lihat artikel pengujian lainnya di blog saya