Saya telah mengidentifikasi 7 tahap kunci dalam evolusi pengujian untuk menggambarkan bagaimana pendekatan jaminan kualitas di perusahaan berubah. Selama membaca artikel, Anda akan dapat melacak evolusi pengujian, menentukan tahap Anda saat ini dan mencari tahu apa yang harus dilakukan untuk meningkatkan proses dan kualitas pengujian.
Artikel ini awalnya ditulis untuk majalah CIS, tetapi saya pikir itu akan menarik bagi pengguna Habr juga.
Jadi, tahapannya.
- Tidak ada tester. Fungsinya dilakukan oleh pengembang atau manajer.
- Penguji muncul, tetapi hanya menguji proyek pada tahap penyelesaian.
- Penguji memeriksa semua tugas pengembang untuk kesesuaian hasil dengan pernyataan asli masalah.
- Penguji terlibat dalam desain tes.
- Sistem manajemen pengujian sedang diperkenalkan.
- Otomasi uji muncul.
- Hirarki menjadi lebih kompleks, peran baru muncul di tim pengujian.
Sekarang tentang setiap tahap secara lebih rinci.
Tahap 1. Pengujian dilakukan oleh pengembang dan / atau manajer
"Apakah - periksa sendiri" - pendekatan paling sederhana, "naluriah" untuk pengujian. Suatu hal yang umum di perusahaan kecil. Ketika tidak mungkin untuk menyewa tester profesional atau tidak ada pemahaman tentang perlunya pengujian, pekerjaan ini dilakukan sendiri. Menguji diri sendiri adalah pendekatan yang paling tidak rasional dan bermasalah. Itu sebabnya.
- Pengembang sendiri menguji hanya skenario yang ia implementasikan dengan data yang ia gunakan dalam proses pengembangan. Dengan pengujian seperti itu "dalam ruang hampa," skenario alternatif dihilangkan. Akibatnya, kehidupan membuat penyesuaian dan sebagai aturan, kesalahan terjadi pada pengguna akhir.
- Jika manajer menguji, maka ia melakukan ini sebagai beban tambahan, tanpa memiliki keahlian dan tidak memiliki waktu dan kekuatan moral untuk terlibat dalam pengujian. Sehingga Anda dapat menemukan kesalahan besar, tetapi banyak nuansa yang diabaikan.
- Sikap subyektif terhadap proyek, keinginan untuk cepat lulus itu mengarah pada godaan untuk menutup mata kita ke sejumlah masalah yang tampaknya "tidak signifikan".
Kasus ekstrem ketika perusahaan tidak melakukan pengujian sama sekali, dan laporan bug membawa ... pelanggan. Dia menerima rilis, semuanya sudah ada di medan perang, pengembang melaporkan pada peluncuran. Klien membuka proyek dan melihat beberapa kesalahan database biasa atau kesalahan server. Kemudian semakin banyak kesalahan. Klien menjadi tester untuk uangnya sendiri.
Tahap 2. Penguji memeriksa proyek di akhir
Memeriksa seluruh proyek pada tahap pra-rilis adalah metode klasik saat mengerjakan model Waterfall. Proyek ini dibagi ke dalam tahap global (kadang-kadang seluruh proyek adalah satu tahap). Pada setiap tahap, perangkat lunak pertama kali dibuat, dan baru kemudian diuji. Pengujian sudah ada, dan itu bagus. Tetapi ada juga masalah, dan sangat spesifik.
Pertama, ketika kami menguji di bagian paling akhir, kesalahan serius pada tingkat arsitektur akan ditemukan terlambat. Penting untuk mengulang sebagian besar, atau bahkan seluruh proyek. Ini tidak bermanfaat bagi siapa pun.
Kedua, dengan tidak adanya dokumentasi, kami hanya dapat melakukan tes permukaan menggunakan metode pencarian gratis. Ini segera mematikan beberapa skenario alternatif. Kebetulan ada dokumentasi, tetapi dalam prosesnya, tugas berubah dan produk jadi berbeda dari gambar di atas kertas. Sekali lagi, ada kesulitan dalam pengujian dan penguraian laporan bug.
Ketiga, hampir sepanjang waktu proyek biasanya diletakkan pada pengembangan sebagai tugas prioritas. Sisakan waktu untuk memeriksa. Tetapi tidak ada waktu untuk memperbaiki kesalahan, sebagai hasilnya, terkadang perbaikan yang mengesankan memperlambat proyek dan mengganggu tenggat waktu.
Pengujian terpisah terhadap langkah-langkah menimbulkan masalah lain. Di antara tahap-tahap, penguji melupakan detail proyek, dan setiap kali ia harus menyelidiki apa yang terjadi. Ini juga buang-buang waktu kerja.
Secara umum, memeriksa proyek di bagian paling akhir adalah logis dan tampaknya benar, tetapi metode ini tidak memperhitungkan risiko mendeteksi kesalahan global. Oleh karena itu, pengujian berkembang lebih lanjut.
Tahap 3. Semua tugas diperiksa untuk kesesuaian hasil dengan tugas asli.
Lebih lanjut, perusahaan memahami bahwa lebih baik untuk menangkap kesalahan ketika mereka menumpuk. Oleh karena itu, kami beralih dari model Waterfall ke metodologi Agile. Pada titik ini, penguji lebih dekat diintegrasikan ke dalam proses pengembangan. Semua tugas mulai diuji berulang kali secara berurutan: secara terpisah, sebagai bagian dari rilis, pada lingkungan pertempuran.
Pada tahap ini, tugas-tugas diperiksa untuk memenuhi persyaratan yang dinyatakan. Agile membantu untuk bekerja lebih baik, tetapi tidak semua penguji, dan terutama pemimpin mereka, siap untuk berhubungan dengan pengujian dengan cara baru.
Kepala mengharapkan kecepatan dan kualitas dari penguji, tetapi tidak ada pemahaman tentang perlunya dokumentasi pengujian dan melakukan pengujian regresi. Karena itulah masalah khas dari tahap evolusi ini.
Pengujian lebih intuitif daripada terstruktur. Prinsip "apa yang saya lihat adalah apa yang saya uji" mendominasi. Pada setiap iterasi, pemeriksaan berbeda dilakukan dan dalam urutan yang berbeda. Akibatnya, Anda setidaknya dapat melewati kesalahan di salah satu tahap pengujian atau tidak melihatnya sama sekali. Skenario alternatif dan perubahan fungsi terkait juga tidak terlihat.
Plus, masalahnya adalah dengan pengujian regresi, yang, jika dilakukan, tidak sistematis. Faktanya, tester memeriksa apa yang dianggap perlu atau apa yang disarankan pengembang / manajer untuk diperiksa.
Tahap 4. Penguji terlibat dalam desain tes.
Pada tahap ini, desain uji memasuki lokasi. Penguji mulai secara sadar memperhatikan analisis persyaratan. Fungsionalitas dibagi menjadi blok logis, yang dicakup oleh daftar periksa atau kasus uji.
Daftar periksa - daftar cek yang diperlukan untuk menguji fungsionalitas. Daftar periksa lebih umum karena mereka lebih mudah untuk tetap up to date, terutama sebagai bagian dari proyek yang besar dan dinamis.
Kasing uji adalah urutan langkah yang harus diambil untuk memverifikasi fungsionalitas. Deskripsi setiap langkah disertai dengan indikasi perilaku yang diharapkan dari sistem.
Dokumentasi pengujian lengkap muncul, sesuai dengan yang Anda dapat melacak bagaimana fungsional tertentu diperiksa. Dokumentasi uji bermanfaat tidak hanya untuk pengujian awal, tetapi juga dalam uji regresi.
Semua ini disebut desain uji. Dapat dikatakan bahwa pengujian profesional yang bermakna dimulai pada tahap ini. Ini lebih dari sekadar serangkaian tugas yang perlu diperiksa, tetapi merupakan proses terstruktur untuk menganalisis persyaratan, menghasilkan dokumentasi pengujian, dan pengujian langsung. Termasuk mengubah pendekatan untuk menguji data. Data tidak lagi ditemukan secara spontan dalam proses, tetapi diambil dari set yang disiapkan sebelumnya.
Tidak ada minus yang jelas pada tahap desain tes. Secara umum, ini adalah tingkat pengujian yang layak. Untuk streaming situs produksi atau proyek serupa, desain pengujian lebih dari cukup. Hal utama adalah mendekati proses pengujian dengan benar: menganalisis produk, menyusun dokumentasi dan melakukan tes di atasnya.
Tahap 5. Sistem manajemen pengujian sedang diperkenalkan
Selanjutnya, perusahaan tumbuh dengan kebutuhan untuk menggunakan sistem khusus untuk menyimpan kasus uji (daftar periksa) dan melakukan uji coba.
Sistem seperti itu memungkinkan:
- persyaratan toko dan uji kasus;
- Kaitkan persyaratan dengan kasus uji
- menganalisis cakupan tes;
- menyimpan berbagai versi kasus uji;
- Lakukan uji coba
- melakukan analisis komparatif atas uji coba;
- menyimpan laporan pengujian;
- Lacak beban kerja tim untuk menyesuaikan tugas dan sumber daya.
Suatu sistem selalu merupakan langkah baru dalam evolusi. Dalam kasus kami, pertama-tama, kontrol atas proses pengujian ditingkatkan. Kami mengelola tes dengan lebih baik dan mendapatkan tingkat kualitas produk yang baru.
Pada tahap pengembangan proyek selanjutnya, sistem semacam itu membantu semua peserta untuk mengingat bagaimana sesuatu harus bekerja dan bagaimana memeriksanya. Sistem mempercepat pengenalan peserta baru ke dalam proyek.
Tahap 6. Pemeriksaan rutin dilakukan secara otomatis
Dalam proses pengembangan proyek jangka panjang, ada kebutuhan untuk mengotomatisasi inspeksi individu. Untuk ini, pengembang dan penguji menulis autotests. Pengembang biasanya melakukan tes unit, penguji melakukan tes ui. Mereka mulai dengan menutup dengan skenario positif autotests menggunakan fungsi utama: otorisasi, pendaftaran, publikasi catatan, dan sejenisnya.
Autotest yang dikembangkan termasuk dalam proses integrasi berkelanjutan (
CI / CD ), yang memungkinkan tim untuk mempelajari tentang kesalahan segera pada saat komit.
Autotests secara signifikan mengurangi biaya pengujian regresi dan meningkatkan kualitas produk akhir. Tetapi untuk melakukannya, Anda memerlukan tingkat tester tertentu. Perlu juga diketahui bahwa autotests tidak masuk akal pada tahap awal proyek. Sistem berubah dengan cepat, oleh karena itu, untuk menghindari kesalahan hantu, perlu juga untuk mengubah autotest, yang membutuhkan waktu.
Tahap 7. Hirarki menjadi lebih kompleks, peran baru muncul
Kami telah sampai pada tahap evolusi tertinggi, ketika hierarki di departemen pengujian sangat rumit dan spesialis yang sempit muncul: seorang manajer pengujian, seorang pemimpin pengujian, seorang analis pengujian, seorang perancang tes, dan sebagainya.
Tim berkembang, tugas menjadi lebih rumit. Misalnya,
manajer pengujian paling tahu tentang suatu produk dan mengatur pengujian di tingkat yang lebih tinggi. Dia berkomunikasi lebih sering dan lebih dekat dengan pelanggan dan pengembangan daripada dengan tim pengujian.
Pimpinan uji mengorganisir pengujian pada proyek dan mendistribusikan tugas-tugas dalam tim.
Analis uji terlibat dalam analisis persyaratan, dekomposisi dan prioritasnya, menyiapkan bahan untuk desain pengujian dan pengujian selanjutnya. Dan
perancang tes mengubah persyaratan menjadi daftar periksa dan kasus uji.
Peran baru diperlukan pada proyek besar di mana seluruh tim penguji bekerja. Munculnya peran tersebut mengarah ke proses pengujian yang lebih terstruktur, yang tanpanya mustahil untuk bekerja pada proyek-proyek TI yang besar dan kompleks.
Kesimpulan
Kami memeriksa tahapan kunci dalam evolusi pengujian di sebuah perusahaan. Pengujian profesional yang sadar dimulai dari tahap desain pengujian. Desain uji memberikan peningkatan kualitas produk yang stabil.
Proses pengembangan pengujian tidak selalu linier. Anda dapat melewati, menggabungkan, mencampur tahapan tertentu atau segera menuju ke tingkat yang lebih tinggi. Misalnya, di Qualitica kami memiliki sistem manajemen pengujian, yaitu, kami berada di tahap 5. Sekarang, hampir secara bersamaan, kami memiliki spesialis yang sempit (peran baru, tahap 7) dan otomatisasi (tahap 6).
Tidak semua orang membutuhkan sistem manajemen pengujian, autotest, dan bahkan lebih dari itu seorang desainer pengujian. Tetapi, tetap pada tahap pengujian naluriah atau membatasi diri untuk pemeriksaan akhir, tidak mungkin untuk melakukan proyek jangka panjang yang kompleks. Oleh karena itu, saya berharap Anda menemukan titik yang tepat dalam pengembangan pengujian dan datang ke sana untuk meningkatkan kualitas pengujian dan memberi pelanggan produk berkualitas tinggi.