Artikel ini akan menarik bagi mereka yang, sama seperti kita dihadapkan dengan masalah memilih spesialis yang cocok di bidang pengujian.
Anehnya, tetapi dengan peningkatan jumlah perusahaan IT di republik kita, hanya jumlah programmer yang layak, tetapi bukan penguji, yang meningkat. Banyak yang ingin profesi ini, tetapi tidak banyak yang mengerti artinya.
Saya tidak bisa mengatakan untuk semua perusahaan IT, tetapi kami telah menetapkan peran QA / QC untuk spesialis kualitas kami. Mereka adalah bagian dari tim pengembangan dan berpartisipasi di semua tahap pengembangan, dari penelitian hingga rilis versi baru.
Penguji dalam tim, bahkan pada tahap perencanaan, harus mempertimbangkan semua persyaratan fungsional dan non-fungsional untuk menerima cerita pengguna. Dia seharusnya tidak lebih buruk daripada programmer, atau bahkan lebih baik, untuk memahami karakteristik operasional produk dan membantu tim untuk tidak membuat keputusan yang salah pada tahap perencanaan. Penguji harus memiliki gagasan yang jelas tentang bagaimana fungsionalitas yang diimplementasikan akan bekerja dan apa jebakannya. Penguji kami menyusun rencana pengujian dan menguji kasus itu sendiri, serta mempersiapkan semua tribun yang diperlukan untuk pengujian. Menguji menurut spesifikasi yang telah selesai sebagai clicker monyet bukan pilihan kami. Bekerja di dalam tim, ia harus membantu mengeluarkan produk yang layak dan membunyikan alarm tepat waktu jika terjadi kesalahan.
Apa yang kami temui ketika mencari penguji
Pada tahap mempelajari banyak resume, tampaknya ada spesialis dengan pengalaman yang cocok untuk kami dan tidak akan ada masalah dengan memilih tester di tim kami. Namun, dalam pertemuan tatap muka, kami semakin dihadapkan dengan kandidat yang pada kenyataannya cukup jauh dari dunia teknologi informasi (misalnya, mereka tidak dapat memberi tahu prinsip-prinsip interaksi browser dan server web, dasar-dasar keamanan, basis data relasional dan non-relasional, tidak memiliki gagasan tentang virtualisasi dan containerisasi), tetapi pada saat yang sama mereka mengevaluasi diri mereka sendiri pada tingkat QA Senior. Setelah lebih dari selusin wawancara, kami sampai pada kesimpulan bahwa jumlah spesialis yang cocok untuk kami di wilayah ini dapat diabaikan.
Selanjutnya, saya akan memberi tahu Anda langkah apa yang kami ambil dan langkah apa yang kami melangkahi untuk menemukan pejuang yang sangat lama ditunggu-tunggu untuk kualitas.
Bagaimana kami mencoba memperbaiki situasi
Setelah menderita dengan sumber spesialis siap pakai, kami mulai menembak di daerah terdekat:
- Kami mencoba menerapkan praktik penilaian untuk mengidentifikasi di antara sejumlah besar "orang-orang yang melarikan diri", mereka yang dapat kami tumbuhkan dari spesialis yang kuat.
Sekelompok kandidat potensial, dengan tingkat pengetahuan yang kurang lebih sama, kami ditawari untuk menyelesaikan tugas. Mengamati proses berpikir mereka, mereka mencoba memilih kandidat yang paling menjanjikan.
Secara khusus, kami datang dengan tugas untuk memeriksa perhatian, memahami kemampuan teknologi dan fitur multikulturalisme:
- Pertemuan diadakan untuk penguji untuk memperluas batas-batas pemahaman profesi untuk kontingen yang ada.
Saya akan bercerita sedikit tentang masing-masing.
Qfa Software QA dan Testing Meetup # 1 adalah upaya pertama kami untuk mengumpulkan mereka yang tidak acuh terhadap profesi dan pada saat yang sama untuk memahami apakah masyarakat akan tertarik pada apa yang ingin kami sampaikan kepada mereka. Pada dasarnya, laporan kami adalah tentang di mana harus memulai, jika Anda memutuskan untuk menjadi penguji. Bantu para pemula membuka mata mereka dan lihatlah tes orang dewasa. Kami berbicara tentang langkah-langkah yang perlu diambil oleh penguji pemula untuk bergabung dengan profesi. Tentang apa kualitas itu dan bagaimana mencapainya dalam kondisi nyata. Dan juga apa pengujian otomatis dan di mana lebih tepat untuk menerapkannya.
Selanjutnya, dengan interval 1-2 bulan, kami mengadakan dua mitaps lagi. Sudah ada dua kali lebih banyak peserta. Di Ufa Software QA dan Testing Meetup # 2, kami terjun lebih dalam ke area subjek. Kami berbicara tentang sistem pelacakan bug, tentang pengujian UI / UX, menyentuh Docker, Ansible, dan juga berbicara tentang kemungkinan konflik antara pengembang dan penguji dan cara mengatasinya.
Metap ketiga kami "Perangkat Lunak QA dan Pengujian Temu Ufa # 3" secara tidak langsung berkaitan dengan pekerjaan penguji, tetapi berguna untuk mengingatkan programmer pada waktunya tentang tugas teknis dan organisasi mereka: pengujian beban, pengujian e2e, Selenium dalam swa uji, dan kerentanan aplikasi web.
Selama ini kami belajar membuat cahaya dan suara normal dalam siaran dari acara kami:
→ Langkah pertama dalam pengujian - QA Perangkat Lunak Ufa dan Pengujian Pertemuan # 1
→ Pengujian UI / UX - QA Perangkat Lunak Ufa dan Pertemuan Pengujian # 2
→ Pengujian Keamanan, Pengujian Beban, dan Pengujian Otomatis - Ufa QA dan Pengujian Meetup # 3 - Dan pada akhirnya kami memutuskan untuk mencoba hackathon untuk penguji
Bagaimana hackathon disiapkan dan dilakukan untuk penguji
Pertama-tama, mereka mencoba memahami "binatang" macam apa ini dan bagaimana biasanya itu dilakukan. Ternyata, acara semacam ini di Federasi Rusia telah diadakan tidak berkali-kali, dan tidak ada tempat untuk meminjam ide. Kedua, saya tidak ingin segera, dalam acara yang meragukan sekilas, menginvestasikan banyak sumber daya. Oleh karena itu, kami memutuskan bahwa kami akan melakukan hackathon mini pendek, bukan untuk seluruh siklus kerja QA, tetapi untuk tahapan terpisah.
Sakit kepala utama kami adalah kurangnya praktik penguji lokal dalam pembentukan peta pengujian yang dapat dipahami. Mereka tidak mencurahkan waktu untuk meneliti pada tahap sebelum implementasi cerita pengguna dan pembuatan kriteria penerimaan yang dimengerti oleh pengembang untuk persyaratan fungsional dan non-fungsional, UI / UX, keamanan, pekerjaan dan beban puncak. Oleh karena itu, kami memutuskan, untuk pertama kalinya, untuk melalui bagian paling menarik dan kreatif dari pekerjaan mereka - analisis dan pembentukan persyaratan untuk penelitian pra-proyek.
Mereka memperkirakan jumlah peserta yang potensial dan memutuskan bahwa kami membutuhkan setidaknya 5 backlog untuk rilis MVP, 5 produk, dan 5 orang yang akan bertindak sebagai pemilik produk, menguraikan kebutuhan bisnis dan membuat keputusan tentang pembatasan.
Inilah yang kami dapatkan:
simpanan untuk hackathon .
Gagasan utamanya adalah memunculkan topik yang jauh dari semua pekerjaan sehari-hari para peserta dan memberi mereka ruang untuk imajinasi kreatif.
Kesalahan apa yang telah kita buat dan apa yang bisa dilakukan dengan lebih baik
Penerapan praktik penilaian, yang sangat populer di bidang penerimaan tenaga penjualan dan manajer tingkat bawah, menghabiskan banyak energi, tetapi tidak memungkinkan kami memberikan perhatian yang memadai kepada setiap peserta dan mengevaluasi kemampuannya. Secara umum, opsi pemilihan ini menciptakan citra negatif perusahaan, karena cukup banyak orang menerima umpan balik yang tidak mencukupi dan, di masa depan, membentuk efek tirani pengusaha (komunikasi dalam komunitas TI sangat berkembang). Sebagai hasilnya, kami memiliki dua kandidat potensial dengan prospek yang sangat jauh.
Di sini mitapas adalah hal yang baik. Basis yang luas untuk studi sedang dibuat, tingkat keseluruhan peserta sedang dinaikkan. Perusahaan semakin dikenal di pasar. Tetapi, kompleksitas dari usaha semacam itu tidaklah kecil. Harus dipahami dengan jelas bahwa sekitar 700-800 jam kerja akan diperlukan untuk mengadakan pertemuan dalam setahun.
Sedangkan untuk penguji hackathon. Acara seperti itu belum sempat bosan, karena, tidak seperti hackathons untuk pengembang, mereka diadakan lebih jarang. Keuntungan dari usaha ini adalah bahwa dengan cara yang jelas Anda dapat bertukar sejumlah besar pengetahuan praktis dan cukup akurat menentukan tingkat masing-masing peserta.
Setelah menganalisis hasil acara, kami menyadari bahwa ada banyak kesalahan:
- Kesalahan yang paling tidak termaafkan adalah percaya bahwa 4-5 jam sudah cukup bagi kita. Akibatnya, hanya perkenalan dan kenalan dengan jaminan simpanan memakan waktu hampir 2 jam.
Bekerja dengan para pemilik produk pada tahap awal dan waktu untuk membenamkan diri dalam bidang subjek membutuhkan banyak waktu. Jadi, sisa waktu jelas tidak cukup untuk studi yang komprehensif kartu pengujian. - Tidak ada cukup waktu dan energi untuk umpan balik terperinci pada setiap kartu, karena sudah malam. Karena itu, bagian ini jelas-jelas gagal oleh kami, dan pada awalnya dianggap sebagai yang paling berharga dalam hackathon.
- Kami memutuskan untuk mengevaluasi kualitas penelitian dengan suara sederhana dari semua peserta, mengalokasikan 3 suara untuk setiap tim yang dapat mereka berikan untuk pekerjaan dengan kualitas terbaik. Mungkin akan lebih baik untuk mengatur juri.
Apa yang telah Anda raih
Kami menyelesaikan sebagian tugas kami dan sekarang kami memiliki 4 orang lelaki tampan yang berani yang duduk di belakang 4 tim pengembangan. Sejumlah besar kandidat potensial yang kuat dan perubahan nyata pada tingkat QA-komunitas kota belum diperhatikan. Tetapi, ada beberapa kemajuan dan ini tidak bisa lain kecuali bersukacita.