Hai, Habr. Di BackendConf terakhir, Anton Olievsky, kepala departemen pengujian perangkat lunak dan kontrol kualitas kami, berbicara tentang hal yang paling penting, mungkin, yang paling penting - sikap sadar untuk bekerja.
Ini masalahnya. Kecepatan menerapkan ide bisnis telah menjadi faktor kunci. Kecepatan dalam SJ ini diperkirakan berdasarkan waktu rata-rata yang dibutuhkan untuk menyelesaikan tugas. Di perusahaan kali ini sama dengan 65 hari. Ya, 2 bulan sejak membuat tugas hingga mengirimkannya ke pengguna.
Anton mengatakan bahwa mereka dapat mempercepat proses sebanyak 3 kali berkat pengujian sadar. Sekarang kami akan memberi tahu Anda apa itu dan bagaimana tepatnya.
Bagaimana sebelumnya?
Prosesnya seperti ini:
- 5 penguji untuk 40 pengembang;
- Setiap tugas diuji secara terpisah;
- Tugas jadi bergabung ke cabang rilis;
- Pada rilis, pengujian penerimaan dilakukan;
Kemudian integrasi.
Jika hasilnya berhasil, rilis dikirim ke pengguna, dan 50-60 tugas menunggu pengujian terus tergantung di papan tulis.
Bagaimana Anda bekerja dengan tugas:
- Dari pengembangan, tugas masuk ke pengujian dan hilang dalam daftar tak berdasar orang lain menunggu;
- Dalam daftar, dia bisa melorot dari beberapa hari menjadi sebulan;
- Kemudian tugas itu diperiksa oleh tester, bug dibuat di atasnya dan dikirim kembali ke pengembangan;
- Programmer memperbaiki bug dan mengembalikan tugas lagi untuk ujian.
Siklus diulangi dan tugas bisa membeku pada tahap pengujian selama beberapa bulan. Dari sudut pandang teknis, semuanya baik-baik saja, hanya fitur yang dirilis perlahan dan bisnis tidak bahagia. Penguji terus-menerus mendengarkan fakta bahwa perkembangan bergerak sangat lambat, tenggat waktu terputus, dan bisnis kehilangan uang.
Seperti halnya penguji normal, mereka membaca buku pintar tentang pengujian dan berpikir bahwa yang utama adalah kualitas produk. Seperti, Anda perlu menemukan bug sebanyak mungkin dan pasti memperbaiki semuanya. Tapi tidak.
Kenapa tidak
Karena kita tidak perlu memperbaiki bug, tetapi membantu bisnis, jadi Anton pergi ke produk Dima untuk menghadapi situasi tersebut. Di sana mereka memutuskan bahwa hal utama adalah kecepatan pelepasan fitur. Faktanya adalah bahwa bisnis tidak suka kehilangan uang untuk mengembangkan dan memperbaiki proyek, yang tidak jelas apakah itu akan membawa manfaat. Karena itu, lebih baik untuk merilis proyek yang tidak sempurna dan, berdasarkan hasil keberhasilannya, memutuskan apakah akan membawanya ke ideal atau menguranginya. Penguji berkumpul dan mencoba memahami cara meningkatkan kecepatan pelepasan. Ternyata, semuanya jelas.
SJ memiliki penerimaan (seperangkat kasing pada bidang fungsionalitas utama untuk memeriksa produk secara keseluruhan, misalnya, otorisasi pengguna, penempatan pekerjaan, dll.), Yang terdiri dari 150 kasing dan membutuhkan 1,5 hari pengujian. Itu terlalu panjang.
Serius, ini sekitar 1,5 hari pemeriksaan manual 2 kali seminggu. Apa yang harus dilakukan dengan pemeriksaan manual berulang? Otomatiskan.
Ternyata untuk mengotomatisasi 100 kasus. Kasus yang tidak menguntungkan untuk dibagikan secara otomatis, mengirim surat, menerima SMS tetap tidak menguntungkan. Penguji senang, karena ada biaya yang kurang teratur untuk pengujian rilis - 3 jam, bukannya 1,5 hari. Kedua, autotests memberikan umpan balik cepat tentang apakah akan mulai menonton rilis sama sekali dan memungkinkan menangkap bug bahkan sebelum tugas masuk ke rilis.
Hampir semuanya sudah diputuskan, tetapi kemudian CTO datang.
Apa lagi yang salah?
Dia datang dan berkata bahwa kita perlu melihat di mana overdosis jam kerja masih berjalan. Orang-orang duduk dan menyadari bahwa tindakan berulang hanya pada rilis - itu adalah penerimaan dan integrasi.
Bagaimana dengan integrasi. Singkatnya, ada situasi ketika mereka mengirim rilis dan produk Dim datang dengan marah bahwa tugas yang mereka janjikan tidak datang ke pertempuran. Mereka mulai mencari tahu ke mana dia pergi. Ternyata ketika memegang tugas ke cabang rilis beberapa komit hilang dan tugas itu hilang secara visual untuk pengguna.
Devops mulai memperbaiki skrip pembuatan, dan penguji memeriksa kembali kasus untuk setiap tugas pada rilis untuk memastikan bahwa semuanya berjalan bersama dan semua tugas sudah ada. Tampaknya sulit untuk memeriksa tugas-tugas yang sudah terlihat. Tetapi ternyata ada sekitar 5 tugas untuk setiap tester dalam rilis, dan kasus kompleks muncul, seperti mengubah sesuatu dalam database, menjalankan skrip, memeriksa surat yang diterima. Seluruh tahap ini membutuhkan banyak waktu: dari 2 hingga 10 jam kerja semua penguji.
Orang-orang mengambil statistik selama beberapa bulan dari praktik ini dan ternyata tidak ada lagi kasus dengan rilis yang buruk dan pada tahap ini hanya beberapa kali ada bug tidak kritis yang terlewatkan saat menguji tugas. Timbang semua pro dan kontra dan memutuskan untuk meninggalkan tahap ini.
Sekarang ok
Tidak apa-apa Di dunia IT, Anda tidak dapat menikmati kesuksesan lama, karena selalu ada sesuatu untuk ditingkatkan. Dalam kasus kami, ini adalah rilis 2 kali seminggu. Misalnya, penguji memeriksa tugas pada hari Rabu pagi dan mengirimkannya untuk dirilis, dan tugas tersebut akan sampai ke pengguna hanya pada hari Selasa minggu depan.
Apa lagi Terlalu banyak perbaikan terbaru dari bisnis. Bisnis telah merencanakan untuk merilis fitur untuk beberapa tanggal, mengumumkannya dan meluncurkan iklan, dan penguji adalah: "Sampah, gay, kami telah merencanakan rilis di sini dan tugas akan diluncurkan hanya minggu depan." Karena itu, untuk setiap tugas seperti itu, produk Dima menggunakan mereka.
Dan semua orang tahu bahwa jika Dima masuk dalam pengembangan, maka tunggu yang mendesak. Penggerebekan seperti itu bosan dengan para devs dan penguji. Apakah ini bukan alasan untuk pergi ke ruang pertemuan lagi ?! Mereka semua mengunci diri bersama dan memutuskan bahwa bisnis perlu merilis lebih sering, jadi Anda perlu mengotomatisasi lebih banyak lagi, memeriksa rilisnya dalam tiga jam, mengotomatiskan pembuatan rilis harian dan mengonfigurasi peluncuran autotest pada rilis dan melakukan penerimaan setiap hari.
Ini adalah kemenangan kecil, karena fitur tumpah setelah menguji maksimum pada hari berikutnya. Ada sedikit masalah dengan perbaikan panas, beberapa dikirim ke rilis saat ini, dan beberapa menunggu rilis besok. Ini memungkinkan penguji untuk tidak terganggu oleh pemeriksaan ini dan meluangkan waktu untuk menguji tugas-tugas baru. Statistik tentang bug yang terlewatkan tetap tidak berubah.
Kemudian penguji Julia datang ke Anton dan mengatakan bahwa dia muak dengan itu. Seperti, lakukan apa yang Anda inginkan, tetapi dia tidak bisa lagi melakukan penerimaan setiap hari, mengingat fakta bahwa sesuai dengan fungsi utama jarang sesuatu berubah dan tidak menemukan bug. Karena itu, Julia menawarkan untuk melakukan penerimaan seminggu sekali.
Baiklah, gay baik-baik saja.
Dan bagaimana?
Hemat waktu - 12 jam seminggu untuk menguji tugas-tugas baru, lebih sedikit penurunan motivasi pada cek monoton. Dari minus - bug dapat hidup hingga 5 hari dari tanggal penampilan. Banyak yang telah berhasil dilakukan untuk mempercepat, tetapi pada saat yang sama, mereka hanya berdampak kecil pada hal yang paling penting - waktu rata-rata yang diambil untuk menyelesaikan tugas produksi.
Mereka maju ke arah gawang, tetapi tidak mencapainya. Ya, penguji dapat mengabdikan waktu mereka untuk tugas-tugas baru, tetapi untuk kecepatan peralihan itu setetes dalam ember.
Anton pergi untuk memikirkan tugas apa yang harus melalui pengujian dan menyadari bahwa hampir semuanya. Dan arusnya sangat besar, seperti Palung Mariana, jadi tidak mungkin untuk memproses semuanya. Oleh karena itu, diputuskan untuk memprioritaskan. Pada tahap ini, produk yang Dima bantu, yang, bersama dengan Anton, memverifikasi semua yang tidak penting untuk bisnis.
Hanya poin yang terkait langsung dengan uang dan hal-hal penting bagi pengguna yang tersisa.
Singkatnya, hanya 50 yang tersisa dari daftar 300 item.
Anda sudah bisa bekerja dengan ini. Omong-omong, bonus apa yang diberikan pengembangan web?
- Kemampuan untuk dengan cepat menanggapi bug yang ditemukan dalam pertempuran;
- Pemantauan masalah secara online;
- Dukungan teknis berhubungan dengan pengguna.
Sekarang yang paling penting. Ya, buku-buku pengujian mengajarkan Anda cara menguji segala sesuatu, tetapi semua keadaan memberi tahu Anton bahwa tidak semuanya perlu diuji. Menurut Anton, tiga hari refleksi ini, dia merasa seperti Hamlet dengan pertanyaannya "Menjadi atau tidak menjadi."
Mengumpulkan semua keinginannya menjadi kepalan, dia memutuskan apa yang akan terjadi. Dan dia menolak untuk menguji fungsionalitas yang tidak penting. Penguji mulai menuangkan tugas pada 250 poin setelah pengembangan segera ke rilis. Serius.
Tidak setiap perusahaan akan setuju untuk langkah seperti itu, dan hampir semua penguji menolak untuk menguji menyakiti rumor. Tetapi keputusan ini memungkinkan untuk fokus pada hal yang sangat penting.
Kegagalan untuk menguji adalah langkah yang bertanggung jawab dan berbahaya.
Jika Anda juga ingin melakukan ini:- Daftar fungsi kritis tersedia untuk umum sehingga pengembang dapat mengaksesnya;
- Untuk mengevaluasi pendekatan baru, tambahkan ke Jira hubungan "dihasilkan dalam => menelurkan". Jadi, Anda dapat melacak berapa banyak bug yang melewati dalam tugas yang tidak dapat diuji;
- Karena tidak bodoh untuk menguji sebagian besar tugas, periksa beberapa kasus utama di dalamnya, tetapi dalam rilis agar tidak memperlambat penuangan;
- Fungsionalitas kritis untuk menguji sesuai dengan skema lama.
Apa yang akan berubah?- Sebagian besar tugas akan berhenti tergelincir selama fase pengujian;
- Penguji hanya akan berurusan dengan tugas-tugas penting bisnis;
- Yang penting dibawa ke pengujian lebih cepat, karena yang tidak penting sekarang tidak mengganggu papan tulis.
Apa yang sangat buruk- Pengguna nyata lebih mungkin mengalami kesalahan kecil;
- Beban dukungan teknis meningkat, karena bug yang terlewatkan mulai datang dari pengguna.
Apakah itu sakit?
Orang-orang menyelesaikan semua langkah yang dijelaskan dalam enam bulan. Ya, sakit, tetapi hasilnya adalah sebagai berikut:
Waktu rata-rata yang diambil untuk menyelesaikan tugas dikurangi menjadi 19 hari dan terus menurun;
Alur tugas pengujian berkurang. Penguji mulai bersiap untuk menguji fitur-fitur penting secara paralel dengan pengembangan;
Produk Dima benar-benar berhenti pergi ke Anton.
Alih-alih kesimpulan
Jangan gunakan pendekatan kami dalam bidang kedokteran atau konstruksi pesawat terbang. Dalam situasi yang tidak terkait dengan risiko seumur hidup - uji keputusan dan pendekatan Anda.
Jangan percaya buku dan hentikan pengujian demi pengujian, hanya karena itu ditulis di suatu tempat.
Tanyakan pada diri Anda apakah Anda memenuhi harapan bisnis dan apakah setiap item pada daftar tugas Anda benar-benar bermanfaat.
SuperJob bersamamu. Kesadaran untuk semua!