🗞️ 🛀🏻 👩🏻‍💼 Mengapa dan bagaimana kami menguji pembaruan 👋🏾 👖 🏛️

Dalam artikel ini saya akan menjelaskan mengapa begitu penting untuk tidak melupakan pengujian pembaruan produk dan bagaimana proses ini bekerja di perusahaan kami. Pembaruan stabilitas adalah masalah reputasi produk dan kepercayaan pengguna terhadap inovasi Anda. Dari pengalaman saya sendiri, saya dapat mengatakan bahwa kadang-kadang sebelum memulai pembaruan, misalnya, di telepon, saya lebih suka menunggu setidaknya satu hari dan membaca komentar (mereka selalu relevan hanya untuk versi terbaru). Jika komentarnya kasar, maka kemungkinan saya akan memutuskan untuk memperbarui, cenderung nol. Peringkat aplikasi karena komentar negatif turun, dan tidak mudah untuk mengembalikannya, karena Anda harus dapat menarik minat pengguna dalam memasang pembaruan baru, yang sekarang akan ditakuti.

Apa yang biasanya tidak disukai pengguna?

aplikasi tidak berfungsi sama sekali setelah memperbarui. Misalnya, tidak tahu apa yang harus dilakukan dengan data dalam format lama;
bonus, diskon, simpanan pengguna (game, toko, kafe) hilang;
fitur baru yang pembaruannya diumumkan tidak berfungsi;
fitur baru berfungsi, tetapi beberapa yang lama jatuh;

Semua masalah ini relevan untuk aplikasi seluler dan untuk sistem DLP yang kami uji di rumah. Lebih jauh tentang apa yang sedang kita hadapi.

Apa yang kami rilis dan apa yang perlu diperbarui

Perusahaan kami menyediakan solusi bagi pelanggan untuk melindungi dari kebocoran informasi perusahaan dengan kemampuan untuk mengonfigurasi secara terpisah untuk setiap organisasi, berdasarkan kebutuhannya. Elemen utama dari sistem adalah pengaturannya (dengan kriteria apa pengganggu akan dicari) dan peristiwa (insiden yang direkam).

Produk ini terdiri dari beberapa bagian, dalam artikel ini kita akan mempertimbangkan analisis insiden dan server penyimpanan InfoWatch Traffic Monitor. Produk ini berjalan pada OS keluarga Linux, memiliki database sendiri. Petugas keamanan menggunakan konsol web untuk bekerja. Dua distribusi Linux yang berbeda dan dua database saat ini didukung. Sistem dapat diinstal dengan beberapa cara: all-in-one, ketika semua komponen pada satu mesin; dan instalasi terdistribusi ketika komponen sistem ada pada mesin fisik yang berbeda.

Selain fungsi sistem yang dinyatakan, kami harus menjamin pembaruan dari versi utama N-1 dan N-2 ke N, serta memperbarui dari semua versi kecil - tambalan dan perbaikan terbaru dari setiap versi. Ini disebabkan oleh fakta bahwa pelanggan kami sering memiliki infrastruktur TI yang agak rumit, pembaruan dapat memakan waktu lama, jadi penting untuk membatasi jumlah pembaruan, jangan terlalu sering melakukannya, menghindari downtime.

Semua kondisi ini memberikan serangkaian konfigurasi produk kami yang cukup besar, untuk masing-masingnya kami harus menjamin pembaruan yang berhasil. Dengan ini berarti pembaruan, sebagai akibatnya:

data pengguna tidak hilang
fitur lama tidak rusak
fitur baru tersedia untuk digunakan

Dalam hal ini, prioritas persyaratan dari daftar di atas dalam urutan kepentingan yang menurun. Misalnya, jika Anda mentransfer prioritas dari bidang bekerja dengan sistem DLP ke bidang aplikasi pengguna yang disebutkan di atas, maka menyelamatkan pengguna game mungkin lebih penting daripada kemampuan untuk memulai permainan baru. Dan pengguna aplikasi pemesanan makanan tidak peduli betapa manisnya menu baru jika tombol "Kirim Pesanan" telah berhenti bekerja.

Pertimbangkan contoh dengan tabel pembaruan kami ketika versi utama 3. dirilis Untuk versi 1.0.0, dua tambalan dan tiga hotfix dirilis, dan untuk versi 2.0.0 ada dua hotfix.

1.0.0	2.0.0	3.0.0
1.0.1	2.0.1
1.0.2	2.0.2
1.1.0
1.1.1
1.2.0

Secara total, dalam contoh ini kami memiliki sembilan versi, yang darinya kami harus memutakhirkan ke versi 3.0.0 yang baru. Ada dua OS dan dua database untuk setiap versi produk kami. Itu Sebanyak 27 konfigurasi yang diperbarui dirilis. Dan jika kita juga menggunakan metode instalasi yang berbeda, maka jumlah ini dapat dengan mudah dikalikan dua, sebagai hasilnya kita mendapatkan 54.

Setiap rilis kami mengandung sejumlah fitur yang serius (dari sudut pandang dampak pada produk). Metode penyesuaian sistem dapat berubah, sistem analisis disempurnakan, insiden dilengkapi dengan data baru, versi perubahan lingkungan, misalnya, versi OS atau basis data, dll.

Secara historis ...

Dalam jaman dahulu kala, kami telah mengembangkan pendekatan penelitian ketika menguji pembaruan produk. Dia membuktikan dirinya dalam kondisi pengetahuan yang baik tentang produk dan sejumlah kecil lingkungan dan konfigurasi yang diuji. Tetapi waktu berlalu, tim tumbuh dan mengubah komposisinya: penguji dan pengembang datang dan pergi, dan beberapa fitur tidak berdokumen dilupakan dengan aman.

Merencanakan pengujian penelitian tanpa pengetahuan produk yang baik adalah tugas tanpa pamrih, itu penuh dengan konsekuensi seperti:

Menguji pembaruan setiap kali membutuhkan waktu yang berbeda. Lebih sering, waktu dialokasikan sesuai dengan prinsip residual, karena pembaruan diuji ketika produk sudah distabilkan dan sentuhan akhir tetap sebelum rilis.
Terkadang beberapa lingkungan dilupakan.
, , . , , , «» - .

Persiapan awal juga dilakukan terutama atas kebijakan penguji, yang mendapatkan tugas dan kadang-kadang tanpa memperhitungkan semua perubahan dalam versi.

Selain fitur internal dari proses pengujian, fakta bahwa dokumentasi tidak menjelaskan perubahan yang terjadi dengan fungsionalitas produk yang menambahkan bahan bakar ke api. Dengan demikian, kami dapat menguji bukan apa yang berubah, tetapi apa yang tidak terpengaruh sama sekali oleh rilis saat ini.

Akibatnya, mustahil untuk dengan jelas memahami dari laporan pengujian pembaruan yang pemeriksaan dilakukan, pada nilai apa, dll.

Namun demikian, untuk beberapa waktu kami puas dengan hasil pengujian penelitian: tidak ada begitu banyak cacat militer untuk pembaruan, dan tidak ada sumber daya untuk perubahan untuk keuntungan teoritis.

Ada yang salah

Situasi berubah ketika cacat pembaruan kritis untuk pelanggan kami tetap merangkak. Paling sering mereka ditemukan di suatu tempat jauh dari skenario pembaruan utama dan dikaitkan dengan situasi di mana, misalnya, elemen teknologi analisis yang dibuat dan bekerja di versi sebelumnya memblokir pembaruan, atau beberapa peristiwa hilang dalam database klien, atau skenario paling kritis ketika setelah upgrade beberapa layanan tidak dimulai dan kami menerima produk yang tidak beroperasi. Cacat terkait basis juga sudah mulai muncul di pelanggan kami.

Dalam situasi ini, proses saat ini tidak lagi memuaskan kami. Sesuatu harus diubah.
Kami mulai dengan merumuskan masalah yang, menurut pendapat kami, mencegah kami menguji pembaruan dengan lebih baik. Setelah diskusi, daftar masalah berikut dibentuk:

;
, ;
, , , , ;
, ;
;
. ? ? ? ?

Selanjutnya, untuk setiap masalah yang teridentifikasi, kami mencoba menemukan solusi yang layak. Selain menyelesaikan masalah spesifik yang telah kami rumuskan untuk diri kami sendiri, kami memutuskan dalam proses diskusi untuk mengajukan persyaratan untuk proses pengujian itu sendiri, di mana kami ingin bekerja lebih jauh.

Prosesnya harus dibuat lebih terbuka dan transparan, untuk ini kami sepenuhnya meninggalkan pengujian penelitian demi kasus uji.

Untuk membuat kasus uji yang diperlukan, kami membutuhkan informasi tentang perubahan antar versi. Informasi ini perlu diminta dari pengembang dan analis produk.

Dalam pendekatan baru, kami menggunakan kombinasi pemeriksaan pada objek sistem (tidak berubah dan berubah selama pembaruan) + pemeriksaan asap fungsi (baik lama, baru atau lama berubah).

Untuk peningkatan, opsi yang paling sulit untuk menginstal sistem akan dipilih - instalasi terdistribusi. Untuk semua OS dan DB. Opsi yang lebih sederhana dihilangkan sebagai kasus khusus.

Kombinasi cek ini akan memberi kita kesempatan untuk menguji komponen sistem berikut:

DB
Web (frontend, backend);
Komponen Linux

Akibatnya, solusi untuk setiap masalah kami disajikan sebagai berikut:
Tidak ada informasi yang cukup tentang perubahan dalam versi saat ini. Pengetahuan tentang sistem tidak mencukupi, tidak cukup informasi tentang sistem. Bersama dengan analis dan pengembang, kami menentukan area perubahan produk antara versi yang diperbarui dan saat ini.

Pembaruan pengujian berubah menjadi regresi. Pengujian fungsional dilakukan, bukan objek sistem dan operasi pada mereka. Kami akan menguji pembaruan pada kasus uji dalam bentuk uji asap verifikasi fungsional + data.

gambar

Pelaporan yang tidak bisa dipahami. Cakupan dan hasil dapat diambil dari kasus uji.

Prosesnya buram. Setelah menyelesaikan setiap masalah individu, proses baru dibentuk yang dibenarkan oleh kebutuhan kita dan juga diperbaiki sedemikian rupa sehingga setiap anggota tim sekarang dapat membiasakan diri dengan prinsip-prinsipnya.

Proses baru

Sebagai hasilnya, kami membangun proses yang agak efektif.

Kami membagi pengujian menjadi beberapa tahap, yang memberikan lebih banyak bonus yang tidak direncanakan, yang dijelaskan di bawah ini:

Latihan.
- Kami menganalisis perubahan dalam sistem, disiapkan bersama dengan analis dan pengembang untuk bidang yang berubah.
- Sesuai dengan hasil analisis, kami menyusun daftar objek sistem yang disiapkan untuk menguji pembaruan.
- Untuk setiap objek sistem, set status, status, dan parameter yang diperlukan ditentukan.
- Kami membuat dudukan dengan versi produk yang diperlukan (diperbarui).
- , .
- ( ).
- smoke- , .
:
- ;
- (, , , );
- , .
- .
- -, .
- .
- , .
- Pemeriksaan operasi pada objek (pembuatan, pengeditan, penghapusan).
- Memeriksa interaksi objek dengan objek lain (deteksi).

Pro dan kontra pendekatan

Kami telah mencapai tujuan kami, yaitu:

Prosesnya menjadi transparan. Kita tahu bahwa kita sedang menguji bagaimana, berapa lama waktu yang dibutuhkan, dan artefak apa yang akan dihasilkan. Kami menerima kriteria objektif yang memungkinkan untuk memberikan putusan kami tentang pembaruan produk yang berfungsi atau tidak bekerja.
Laporan menjadi jelas. Kehadiran kasus uji dan laporan tentang hasil bagian mereka memungkinkan untuk dengan cepat melaporkan kepada manajer proyek dan direktur teknis tentang kualitas perakitan yang dibuat.
Cakupan yang lebih besar dan lebih dapat dipahami daripada dengan pendekatan penelitian.
Sekarang kami sedang menguji perubahan data dan fungsionalitas. Berkat responsif para analis dan pengembang, kita dapat mengatakan dengan tingkat akurasi tinggi apa yang telah berubah dalam sistem dan di mana ada risiko terkena cacat.

Tetapi dengan menjalankan strategi pengujian baru, kami tidak dapat gagal untuk menemukan minus yang jelas dari pendekatan baru - peningkatan waktu pengujian yang signifikan.

Kami mulai menghabiskan waktu tidak hanya pada pengujian langsung, seperti halnya dengan pengujian penelitian. Biaya waktu baru dikaitkan terutama dengan persiapan untuk pengujian, yaitu:

analisis perubahan;
pembuatan, pengisian, pemeliharaan tegakan untuk memperbarui;
memperbarui alat tes lama dan membuat yang baru.

Minus ini bisa menjadi penentu untuk membuat keputusan untuk meninggalkan metodologi baru, jika bukan karena satu "tetapi".

Semua persiapan, dan ini adalah tahap yang paling memakan waktu, dapat dilakukan segera setelah komposisi akhir dari rilis terbentuk, bahkan tanpa produk jadi. Dengan demikian, kami "menyebar" persiapan sesuai dengan rencana pengujian, tanpa membebani periode pra-rilis yang terlalu jenuh. Itu masih harus lulus tes pada produk jadi stabil.

Secara total, menurut hasil peningkatan tahap pertama, kami menerima yang berikut: kami mulai menghabiskan lebih banyak waktu pengujian, tetapi pada saat yang sama kami memiliki proses yang transparan, tampilan yang jelas dari hasil dan cakupan yang lebih, yang memungkinkan kami untuk:

mendeteksi lebih banyak cacat sebagai akibat dari memeriksa pembaruan produk di departemen Anda;
mengurangi jumlah cacat saat memperbarui pelanggan kami oleh teknisi implementasi;
mengurangi jumlah cacat yang diterima dari dukungan teknis.

Apa berikutnya? - tentang pengoptimalan

Mungkin ini bisa diselesaikan, tetapi waktu selalu merupakan uang. Selain itu, sudah berdasarkan hasil terobosan pertama dari metodologi baru, cara untuk mengoptimalkan biaya waktu menjadi lebih jelas terlihat.

Kami pergi dalam dua cara:

optimasi berdasarkan analisis uji coba: di sini kami terlibat dalam mengidentifikasi ketergantungan yang jelas dan implisit hasil pengujian pada lingkungan yang digunakan. Ini adalah cara pengujian fungsional.
otomatisasi uji. Kemudian tim otomatisasi kami datang untuk menyelamatkan.

Saya akan berbicara lebih banyak tentang setiap jalur.

Cara pertama: optimisasi berdasarkan analisis uji coba.

Dengan cara ini kami memilih untuk mengoptimalkan pengujian pembaruan antara versi utama, yaitu antara yang ada perubahan signifikan dalam fungsi.

Hal pertama yang kami perhatikan adalah tes yang bergantung pada database dan hanya pada database. Kami dapat memahami pemeriksaan apa yang cukup untuk dilakukan sekali di setiap basis, dan kemudian mengecualikannya dari kombinatorik kami dengan OS sepenuhnya.

Langkah kedua adalah "runtuhnya" pemeriksaan volumetrik dari fungsi lama ke dalam daftar periksa. Dalam iterasi pertama, fungsionalitasnya, terlepas dari apakah itu muncul di rilis saat ini, di yang sebelumnya atau selalu, bergantung pada tes lengkapnya sendiri. Sekarang, tes lengkap hanya bergantung pada fitur-fitur baru, sementara fungsi lama diperiksa pada daftar periksa.

Selain itu, daftar periksa yang sama sangat berguna bagi kami ketika merilis tambalan dan perbaikan terbaru, di mana selain pembaruan antara versi utama, juga penting untuk memeriksa pembaruan dalam versi.

Cara kedua: otomatisasi tes

Pertama-tama, saya ingin membuat reservasi yang kita tidak memahami hal otomatisasi pengujian memperbarui karena itu berlaku umum dan nada umumnya baik, tapi karena update adalah jenis pengujian yang tidak dapat dikecualikan dalam rilis apapun, baik itu besar melepaskan, menambal atau perbaikan terbaru. Kami memilih jalur ini untuk mengurangi waktu pengujian pembaruan untuk versi minor, yaitu tambalan dan hotfix, yaitu versi yang komposisi fungsionalnya tidak berubah. Dalam hal ini, otomatisasi pengujian terlihat sangat efisien.

Pada tahap ini, pengujian pembaruan saat melepaskan tambalan dan hotfix hampir seluruhnya otomatis.

Menguji pembaruan saat versi utama dirilis dibagi antara pengujian manual dan otomatis. Secara manual memeriksa area yang dapat berubah yang dipengaruhi oleh fitur. Tes untuk area yang tidak berubah secara otomatis dikejar, paling sering lebih banyak menggunakan autotest yang sudah ditulis untuk versi sebelumnya dengan sedikit pembaruan untuk yang baru.

Untuk memulai proses otomatisasi kasus uji, kami harus menyempurnakannya lagi, karena bahasa tes dari penguji manual memungkinkan lebih banyak kesulitan daripada kemampuan autotest. Artinya, kami juga mengalokasikan waktu untuk persiapan tes untuk otomatisasi, yang benar-benar terbayar hampir untuk pertama kalinya.

Ringkasan

Kami memiliki proses penelitian untuk menguji pembaruan. Pada titik tertentu, ia tidak lagi memuaskan kami karena penurunan kualitas pembaruan yang nyata. Kami tidak memilih pengganti untuk pengujian penelitian sebagai teknik yang sudah jadi, tetapi membentuknya berdasarkan masalah yang kami identifikasi. Pembentukan metodologi baru, yang kami gunakan dan terus tingkatkan, dipengaruhi oleh solusi yang disiapkan untuk masalah, serta keinginan umum untuk proses pengujian.

Saya tidak berpikir bahwa dalam situasi ini kami menciptakan sepeda ketika kami mengambil jalur untuk menciptakan proses kami sendiri yang dirancang khusus untuk proyek kami dan fitur-fitur produk kami. Jika kita membongkar proses menjadi bagian-bagian penyusunnya, kita memperoleh, secara umum, teknik yang diterima secara umum dan banyak digunakan.

Terlepas dari kenyataan bahwa hasil pekerjaan yang kami kumpulkan dalam satu artikel yang tidak terlalu banyak, seluruh proses mulai dari memahami masalah hingga memperkenalkan solusi baru dan mengoptimalkan pengujian membutuhkan waktu hampir dua tahun bagi kami.

Kami mencoba untuk dengan jujur menggambarkan di sini semua pro dan kontra, serta jebakan dari keputusan kami, sehingga cerita tersebut tidak terlihat secara eksklusif seperti kisah sukses "itu buruk - itu menjadi baik".

Kami harap pengalaman Anda bermanfaat.

Penulis materi:tryzhova (Ryzhova Tatyana).

Mengapa dan bagaimana kami menguji pembaruan