Halo semuanya, nama saya Sergey. Saya menguji antarmuka Yandex.Market. Saya tahu bahwa di antara para pembaca Habr ada banyak spesialis IT yang entah bagaimana terhubung dengan proses rilis dan pengujian. Saya punya pertanyaan untuk Anda. Pernahkah terjadi dalam praktik Anda bahwa fitur tidak bergulung untuk waktu yang lama dalam produksi? Apakah Anda menyadari rilis kembung dan pemeriksaan volumetriknya?
Saya pikir semua orang punya ini. Saya datang ke Yandex 3 tahun lalu, tim kami masih sangat muda, prosesnya belum sepenuhnya mapan. Dan saya mengalami masalah ini secara langsung.
Seperti dulu
Pada saat itu, tim produk kami tidak memiliki area tanggung jawab khusus dan hanya terlibat dalam proyek yang mereka ciptakan. Kemudian mereka hancur berantakan. Pengujian juga tidak terkait dengan tim pengembangan. Itu ada sebagai layanan dan terhubung ke proyek sesuai kebutuhan.
Tugas diperiksa hanya dengan tangan, tes integrasi tidak stabil, persentase cakupan dengan autotest kecil. Cek itu berlangsung sangat lama. Kelompok tugas yang siap untuk perhitungan terus tumbuh dan dapat mencapai ukuran yang sangat besar.
Adapun rilis, salah satu manajer terlibat dalam perakitan dan perhitungan. Kami mengadakan pertemuan dengan semua manajer dan memutuskan apa yang akan jatuh ke rilis berikutnya dan apa yang bisa ditunda.
Mereka memeriksa rilis secara acak: siapa pun yang punya waktu untuk memeriksanya, dia memeriksanya. Penekanannya adalah pada pengujian regresi manual, yang bisa berlangsung beberapa hari. Dan ini terlepas dari kenyataan bahwa rilis menjalankan paket autotests dan ada departemen yang menulis dan mendukung mereka.
Jadi, masalah yang diselesaikan jatuh ke dalam pengujian dan dapat diuji hingga 2 hari. Lalu dia masuk ke rilis, diperiksa selama 4 hari. In prod, tugas ternyata paling baik dalam seminggu. Beberapa orang menyukainya, perlu mengubah sesuatu. Dan hal terpenting untuk berubah adalah prosesnya.
Kontur
Hal pertama yang kami lakukan adalah memperkenalkan divisi ke dalam kontur - tim spesialis dari berbagai bidang. Tidak seperti tim sebelumnya, kontur tidak putus setelah proyek berakhir. Mereka terus menghasilkan proyek dan ide baru dalam bidang tanggung jawab mereka.
Dari 1 hingga 3 penguji bertanggung jawab untuk menguji di setiap sirkuit. Setiap penguji sirkuit yang bertanggung jawab hadir di semua tahap pengembangan produk mulai dari ide hingga tanya jawab.
Bertugas
Untuk menyusun kerja rilis, kami memperkenalkan dua peran dalam tim pengujian kami: panduan rilis dan tester rilis. Sebagai master rilis, kami memiliki 4 penguji yang bertugas pada satu waktu, semua orang terlibat dalam tugas rilis. Untuk masing-masing peran ini, kami mengatur jadwal tugas.
Tugas-tugas yang muncul saat bertugas lebih diutamakan daripada menguji fitur-fitur produk di dalam sirkuit. Agar penguji tidak harus menunggu lama tanpa gangguan, tugas rilis diatur sebagai berikut: satu shift bertugas dari Senin hingga Rabu, yang kedua - dari Rabu hingga akhir Jumat. Di setiap shift - 4 orang, 2 orang per platform.
Dokumentasi
Dan bagaimana dengan dokumentasinya? Kami tidak memiliki sebanyak itu, tetapi itu. Misalnya, ketika meluncurkan fitur, kami, bersama dengan pengembang dan manajer, menentukan jumlah autotest yang optimal. Jika kami tidak dapat mengotomatiskan sesuatu, atau jika suatu fitur membutuhkan posting segera tanpa pengujian otomatis, kami menulis sebuah kasus di suite uji semua kasus verifikasi Pasar dan, jika perlu, memasukkannya ke suite uji rilis pengujian regresi.
Jika kami memeriksa perbaikan bug dan melihat bahwa autotest tidak dituliskan pada bug, kami juga mengatur tugas untuk mengembangkannya, dan pengeditan segera bergulir dengan tes yang tertulis di dalamnya.
Saat meletakkan setiap percobaan, kami memiliki daftar periksa, karena kami tidak tahu sebelumnya apakah percobaan akan berhasil.
Daftar periksa adalah serangkaian pemeriksaan positif pada fitur percobaan. Penguji rilis menggunakannya dengan setiap rilis saat percobaan bekerja. Daftar periksa ini juga bisa kosong untuk tugas otomasi di masa mendatang jika percobaan berhasil dan kami meluncurkannya untuk 100% pengguna.
Saat memeriksa rilis, kami menggunakan berbagai test kit tergantung pada kompleksitas dan kepenuhan rilis. Kami memiliki suite uji dan suite uji kecil dengan jumlah kasus uji maksimum. Test suite mana yang akan digunakan, tester rilis memutuskan.
Di beberapa daerah, kami juga menggunakan daftar periksa cek positif untuk pengembang. Dengan itu, pengembang dapat memeriksa tugasnya sendiri dan melihat kemacetan dalam pengembangan fitur. Jika penguji telah berubah pada proyek, ini akan membantu spesialis baru untuk dengan cepat bergabung dengan proyek. Daftar periksa ditulis sebelum dimulainya pengembangan, segera setelah menjadwalkan tugas.
Itu saja untuk dermaga.
Bagaimana kami menguji tugas
Kami menggunakan berbagai teknik desain pengujian: kelas ekivalensi, nilai batas, pengujian berpasangan, skenario pengguna. Keahlian penguji juga sangat penting. Pasar adalah mesin besar, dan Anda perlu tahu bagaimana semua bagiannya bekerja untuk memperbaiki atau meningkatkan sesuatu. Sebagai contoh, kami memiliki 4 jenis kartu komoditas dan 6 jenis masalah komoditas. Tanpa mengetahui hal ini, mustahil untuk menguji tugas mengubah halaman ini secara kualitatif.
Peran penting dalam memeriksa tugas dimainkan oleh autotests. Kami menjalankan autotest fungsional untuk setiap tugas yang kami laksanakan, menganalisis crash, dan melaporkan bug.
Dalam kasus khusus, ketika tugas mempengaruhi banyak komponen Pasar, kami juga menjalankan tes layar - mereka membantu kami menangkap bug.
Ketika verifikasi tugas selesai, kami meninggalkan komentar bahwa semuanya baik-baik saja dan bahwa tugas tersebut dapat dikeluarkan. Dalam komentar, kami menunjukkan berapa banyak tes yang telah ditulis, atau kami mengatakan bahwa tes tidak diperlukan, dan kami menerjemahkan tugas ke dalam status “pending release”.
Selanjutnya, tugas diambil oleh wizard rilis, dan dikirim ke rilis bersama dengan tugas-tugas terbukti lainnya. Kami mencoba untuk mengisi rilis dengan tugas untuk memeriksanya dalam 8 jam oleh 4 penguji: 2 untuk versi sentuh dari Pasar dan 2 untuk versi desktop. Tujuan kami adalah untuk meluncurkan setidaknya 5 rilis. Artinya, kecepatan pengiriman tugas ke prod dibandingkan dengan apa itu, meningkat 5 kali lipat.
Bagaimana kami memeriksa rilis
Kami mulai memeriksa rilis dengan memeriksa tes otomatis dan tes layar. Setelah melihat laporan, kami dapat langsung menangkap hingga 90% masalah. Kami menganalisis crash tes: jika terkait dengan bug atau rusak oleh tiket dalam rilis, kami mencari tugas di mana crash ini direproduksi, dan meminta untuk diperbaiki. Jika ini tidak dilakukan, tugas tidak termasuk dalam rilis.
Tes juga bisa mati sendiri. Dalam hal ini, kami mematikan tes dari menjalankan autotest dan memulai tugas untuk memperbaikinya dan membuat mox jika perlu.
Bergantung pada tugas dalam rilis, kita dapat menggunakan kit uji rilis lengkap, atau kita dapat sepenuhnya menolak regresi manual. Keputusan tersebut dibuat oleh penguji rilis.
Jika rilis memiliki beberapa suntingan kecil, pemeriksaan tugas dilakukan secara lokal, dan regresi manual diganti dengan pemeriksaan laporan uji otomatis.
Terlepas dari kelengkapan rilis dan tugas, tim penguji rilis memeriksa eksperimen yang saat ini ditunjukkan pada persentase pengguna yang berbeda dalam produksi. Daftar periksa yang ditulis oleh penguji eksperimen digunakan.
Ketika semua pemeriksaan selesai, tester rilis meninggalkan komentar di mana ia mendaftar semua kegiatan rilis dan, jika perlu, menulis tugas untuk memperbaiki tes yang rusak.
Master rilis menganalisis laporan penembakan (pengujian beban) dan, jika ia melihat peningkatan kesalahan, restart mereka. Jika ini tidak membantu, ia mencari pelakunya atau mencari bantuan dari pengembang yang bertugas.
Jika semuanya baik-baik saja dengan hasil pemotretan, panduan rilis membuka grafik Pasar dan mulai meluncurkan rilis ke dalam produksi. Grafik perlu dipantau agar tidak ketinggalan pertumbuhan kesalahan.
Jika rilis ini yang harus disalahkan atas pertumbuhan kesalahan, master rilis memutar kembali dan memahami alasannya. Jika jadwal normal, ia menyelesaikan rilis dan mulai mengumpulkan yang baru dari tugas yang sudah jadi.
Berjuang untuk yang terbaik
Terlepas dari kenyataan bahwa semuanya bekerja dengan baik, Anda harus selalu berusaha untuk yang terbaik. Kami berada di ambang pengiriman berkelanjutan di masa depan yang lebih cerah, di mana tugas-tugas akan diuji dan diluncurkan secara paralel satu sama lain, tanpa tahap peralihan dalam bentuk rilis. Ini akan memungkinkan Anda untuk tidak terganggu oleh arloji saat rilis dan secara signifikan mempercepat pengiriman fungsionalitas kepada pengguna.
Kami memutuskan untuk beralih ke CD secara bertahap. Langkah pertama adalah pengenalan monorepositori, yang menggabungkan peluncuran fungsionalitas ke kedua platform - sentuhan dan desktop - dalam satu rilis. Pendekatan ini memiliki keunggulan untuk pengembangan dan pengujian. Kami menghabiskan lebih sedikit waktu untuk menguji komponen. Tugas sekarang di satu tempat, membuat navigasi lebih mudah. Lebih mudah bagi manajer untuk bernavigasi, karena dia tahu waktu yang tepat untuk meluncurkan tugas rilis di prod, dan tidak ada reaksi balik antara meluncurkan platform.
Langkah selanjutnya ke CD adalah pengenalan "luka hijau". Untuk setiap tiket yang diperiksa oleh tester, 2 jenis tes untuk kedua platform akan diluncurkan: tes fungsional dan tes layar. Semua tes harus memiliki moki. Jika pengujian untuk salah satu platform gagal, tugas tidak akan dianggap diverifikasi. Jika tes gagal, Anda harus memahami mengapa ini terjadi. Hanya dengan tidak adanya tes jatuh dan berhasil menyelesaikan semua pemeriksaan tugas akan dikirim ke prod.
Terima kasih atas perhatian anda Semoga pengalaman kami bermanfaat bagi Anda, saya tunggu komentar Anda.