Banyak yang menganggap pengujian pada lingkungan produksi sebagai praktik yang berbahaya: itu tidak membantu mencegah masalah menjangkau pengguna akhir, tetapi menyatakan bahwa mereka ada. Selain itu, tester terlepas dari alur kerja standar dan teknik yang digunakan dalam lingkungan pengujian. Nama saya Olya Mikhalchuk, saya seorang insinyur QA di perusahaan fintech ID Finance. Dalam posting ini saya akan menjelaskan mengapa pengujian pada prod secara signifikan dapat membantu proyek Anda.
Mengapa Anda memerlukan QA pada prod jika ada lingkungan pra-produksi
Selama proses pengembangan perangkat lunak, selalu ada beberapa lingkungan tempat aplikasi tersebut digunakan. Lingkungan yang digunakan pengguna akhir, seperti yang Anda tahu, disebut produksi. Biasanya diasumsikan bahwa pengujian harus dilakukan di lingkungan yang terpisah, lebih sering di lingkungan QA atau Staging (pre-prod), untuk mencegah kesalahan menjangkau pengguna. Tetapi ada teknik seperti QA on prod, yang secara sempurna membantu menyelesaikan masalah yang secara fisik tidak mungkin diselesaikan di lingkungan pengujian.
Tugas apa yang dilakukan QA on prod membantu
1. Masalah perbedaan antara lingkungan Pementasan dan Produksi.
Pementasan sering dianggap sebagai salinan dari lingkungan produksi, yang tidak dapat diakses oleh pengguna akhir, tetapi paling mirip dengan lingkungan tempur. Ketika aplikasi ini cukup kompleks, sinkronisasi dan pemeliharaan salinan mini semacam itu menjadi tugas yang memakan waktu dan tidak selalu rasional.
Misalnya, pada proyek kami, pra-prod lebih banyak digunakan untuk pengujian fungsional pada skenario pengujian yang dibuat secara manual. Itu tidak memiliki sumber daya teknis yang sebanding dengan lingkungan produksi. Selain itu, kami biasanya tidak sepenuhnya menyinkronkan konfigurasi dan database dengan lingkungan produksi, yang tidak mengganggu tes fungsional. Mengapa kita tidak menyalin lingkungan prod? Bayangkan berapa banyak sumber daya yang diperlukan untuk membuat salinan, katakanlah, Facebook, dengan server, layanan, basis data, dan konfigurasi super-kuat yang sama seperti pada produksi. Ini sebenarnya cara menyebarkan aplikasi lain dengan jenis yang sama.
Selain itu, ketika berintegrasi dengan layanan pihak ketiga, Anda selalu memiliki pengaturan berbeda untuk lingkungan pengujian dan pertempuran (API yang sama). Saya tidak mengatakan bahwa lingkungan pengujian dan pementasan tidak ada gunanya. Tidak mungkin 100% menjamin bahwa setelah berhasil menyelesaikan tes tertentu pada satu lingkungan, layanan tidak akan jatuh pada yang lain. Pengujian tambahan untuk produksi dapat membantu menyelesaikan masalah ini.
2. Tingkat multitasking dan pemuatan nyata.
Beberapa kesalahan hanya dapat dideteksi di bawah multitasking dan beban kerja yang nyata dan lama. Ini berlaku untuk kebocoran memori, stabilitas, kecepatan dan stabilitas sistem. Sebagai contoh, kami memiliki situasi ketika masalah kinerja sistem muncul karena fakta bahwa dua tugas sumber daya intensif dilakukan dalam interval waktu yang sama. Pengembang mengoptimalkan pekerjaan tugas, tim melakukan tes pada lingkungan pre-prod, menyampaikan perubahan, lalu melakukan pemeriksaan produksi.
3. Kesalahan Penerapan
Dari definisi tersebut, penyebaran adalah pemasangan oleh kelompok kerja dari versi baru dari kode program layanan dalam infrastruktur produksi. Oleh karena itu, cara terbaik untuk melihat kesalahan penempatan adalah melalui pengujian dalam proses penempatan itu sendiri.
4. Kurangnya pemantauan pada pre-prod
Salah satu cara terbaik dan tak terpisahkan untuk mengontrol bahwa aplikasi berfungsi seperti yang kita harapkan adalah memantau metrik tertentu. Misalnya, dari contoh sederhana dan paling kritis: memantau jumlah pendaftaran pengguna baru per jam, pada konversi dari satu tindakan target ke yang lain, pada jumlah pinjaman yang dikeluarkan. Tentu saja, pemantauan seperti itu hanya masuk akal di lingkungan pertempuran.
5. Kemampuan untuk menganalisis skenario pengguna akhir untuk menggunakan sistem
Produksi - gudang kasus uji untuk tester. Jika memungkinkan, tester dapat melihat dan memproses skrip yang digunakan oleh pengguna akhir, tester dapat mengidentifikasi skenario paling kritis, atau mencari tahu penyebab cacat, atau memperhatikan kasus-kasus non-sepele saat menguji pada pre-prod.
6. Kemampuan untuk mempertahankan statistik dan metrik kualitas perangkat lunak yang lebih andal.
Sebagai contoh, jumlah kesalahan dalam log aplikasi atau komponen, laporan bug dan laporan lain yang dapat dilakukan oleh penguji, secara lebih realistis menunjukkan kualitas perangkat lunak dibandingkan dengan laporan yang sama dari lingkungan pengujian.
7. Selalu lebih baik jika kesalahan pada prod diperhatikan oleh penguji "Anda" daripada pengguna akhir.
Biasanya, setelah tugas disampaikan, tester melakukan pemeriksaan dasar terhadap fungsionalitas baru atau yang berubah pada prod. Selain itu, kami memiliki orang yang terpisah di perusahaan kami - penguji pada prod. Saya ingin sekali lagi mencatat bahwa saya tidak memposisikan QA pada prod sebagai pengganti pengujian pra-produksi, dan, tentu saja, perlu untuk mencegah bug dan mengambil langkah-langkah pencegahan. Tetapi pengujian semacam itu bisa menjadi teknik tambahan yang hebat dalam proses memastikan kualitas pada proyek Anda.
Praktik QA yang berguna pada produksi yang bekerja secara efektif di proyek kami1. Memeriksa tugas yang disampaikan untuk memastikan bahwa tugas tersebut sudah mapan dan bekerja di lingkungan baru.
Misalnya, ketika kami memperkenalkan integrasi dengan mitra baru, selain tes pada pra-prod, kami pasti akan memeriksa integrasi setelah pengiriman, karena ada banyak pengaturan tergantung pada lingkungan (API, URL, komponen). Ada juga masalah pihak ke-3 - kesalahan tidak di pihak kita, tetapi di sisi layanan terintegrasi.
2. Penebangan dan audit.
Pencatatan yang baik membantu pengembang dan penguji melihat masalah bahkan sebelum pengguna akhir menebaknya, serta memperhatikan tempat-tempat yang perlu dioptimalkan. Audit tindakan dan perubahan memungkinkan kami untuk selalu mencari tahu alasan perilaku tertentu tanpa masalah. Misalnya, jika komponen kebijakan kredit tidak dapat memberikan keputusan tentang pinjaman, untuk menganalisis mengapa hal ini terjadi, pertama-tama kita beralih ke log. Item ini berlaku untuk lingkungan prodcution dan pra-produksi.
3. Sistem pemantauan dan peringatan
Seperti yang saya sebutkan di atas, pemantauan dengan metrik tertentu adalah salah satu cara terbaik untuk mengontrol bahwa semuanya baik-baik saja dengan aplikasi kita. Selain itu, jika ada masalah, Anda harus mengirim peringatan ke pihak yang berkepentingan (misalnya, jumlah aplikasi pinjaman 20% kurang dari yang diharapkan - kami akan mengirimkan peringatan ke TI dan departemen bisnis, beban CPU di atas normal - beri tahu administrator dan perawan). Perlu untuk memastikan bahwa peringatan tentang masalah tepat waktu dan relevan, serta benar-benar menunjukkan masalah.
4. Pemeriksaan regresi dan stabilitas
Praktik keren adalah secara berkala menjalani uji regresi untuk memastikan tidak ada yang salah di mana pun. Ini dapat membantu dalam beberapa kasus yang sempit dan spesifik ketika pemantauan tidak melihat masalah.
5. Pelaporan dan statistik
Seperti dalam setiap pengujian, pelaporan, dan statistik hasil pengujian prod membuat proses lebih transparan, kualitas perangkat lunak dan penyebab cacat lebih terlihat.
Semua kesalahan tidak dapat dideteksi pada pre-prod, sehingga mereka akan jatuh ke lingkungan pertempuran. Jika pengguna menemukan mereka, itu akan mempengaruhi reputasi perusahaan dan, pada akhirnya, kehilangan uang. Pengujian pada prod akan membantu mencegah hal ini.