Ringkasan buku Panduan Praktis untuk Menguji di DevOps, Katrina Clokie

Buku ini menceritakan cara membuat pengujian, agar tidak hanya untuk menangkap bug, tetapi untuk menghindari terjadinya bug. Kami benar-benar menyukainya, jadi kami memutuskan, sebagai orang tua, untuk mendukung tradisi abstrak tentang Habré dan menyusun tesis yang paling menarik.

Bagaimana pendekatan untuk menguji organisasi telah berubah:

Air terjun
Semuanya dimulai dengan pengujian dengan metodologi Waterfall. Tahap ini ditandai oleh fakta bahwa pengujian adalah aktivitas hanya dari satu anggota tim (tebak siapa). Tidak seorang pun kecuali penguji yang tahu apa-apa tentang strategi pengujian dan tidak memiliki akses ke kasus pengujian dan daftar periksa. Tugas terbang dengan perintah seperti bola di ping pong. Periode ini ditandai dengan rilis panjang.

Agile
Dalam pekerjaan pada metodologi Agile, pengujian menjadi tanggung jawab seluruh tim. Ini berarti bahwa tidak hanya penguji, tetapi juga pengembang menemukan dan menyelesaikan masalah. Fase ini ditandai dengan rilis yang sering dan umpan balik cepat.

Devops
Sekarang pengujian dipengaruhi oleh dukungan, analitik, infrastruktur, dan pemantauan. Batasan dan sifat pengujian berubah. Informasi sekarang datang ke tim dari berbagai saluran: pemantauan, permintaan dari layanan dukungan, laporan analitis. Pada saat yang sama, pengujian harus dapat diandalkan, tetapi tidak mengganggu rilis cepat.

Pengujian di era DevOps dan CI

Penulis mengklaim bahwa DevOps jauh lebih besar daripada CI. CI berfokus pada praktik teknis yang mempercepat penulisan kode (misalnya, sistem kontrol versi, tes unit, sering melakukan) dan DevOps - pada perubahan organisasi (khususnya, dukungan untuk kolaborasi yang lebih erat antara jenis pekerja pengiriman perangkat lunak: analis, dukungan, tim pengembangan).

Tanpa Agile, tidak akan ada budaya DevOps. Orang harus berpikir fleksibel untuk datang ke DevOps, yang tujuan utamanya adalah keandalan dan frekuensi rilis. Pada saat yang sama, topik pengujian sering terlewatkan dalam laporan tentang DevOps.

Tesis utama Katrina adalah Anda harus selalu menguji dan di setiap tahap - dari awal mengerjakan tugas hingga komit rilis terakhir.

Volume pekerjaan sangat besar. Muncul pertanyaan bagaimana mengatur semua pengujian dan tidak menjadi gila.

Di mana untuk memulai pengujian

• Memahami bagaimana proses pengujian pada proyek sekarang diatur.
• Atur retrospektif strategi pengujian untuk seluruh tim dan jawab pertanyaan tentang apa yang kami uji sekarang dan mengapa. Mungkin ternyata peserta dalam satu tim akan menjawab pertanyaan tentang proses secara berbeda, yang salah.

DevOps lebih dari sekedar pengujian yang fleksibel. Ideologi DevOps menyiratkan proses debugged sempurna tidak hanya dengan cepat menyebarkan versi baru dalam produksi atau berguling kembali ke sebelumnya, tetapi juga sama-sama debugged komunikasi antara dev dan perintah operasi.

10 kriteria untuk membantu memeriksa apakah Agile dalam pengujian Anda:

1. Seluruh tim jelas tahu apa yang perlu diuji saat mengerjakan cerita pengguna tertentu.
2. Setiap orang memiliki pemahaman yang sama tentang persyaratan bisnis.
3. Saat Anda mendiskusikan kisah pengguna, Anda memiliki jawaban untuk pertanyaan, "Bagaimana kami akan menguji ini?"
4. Semua orang di tim tahu cara menjalankan autotest dan di mana harus melihat hasilnya.
5. Anda mendiskusikan terlebih dahulu apa yang akan Anda otomatisasi dan pada tingkat apa agar tidak menggandakan tes pada tingkat yang berbeda. (Item ini bagi kami tampaknya paling penting).
6. Skrip pengujian Anda diversi dan disimpan dengan kode sumber, karena pengujian adalah bagian dari perangkat lunak.
7. Anda tidak memiliki bug di backlog karena Anda memperbaiki bug segera setelah Anda menemukannya, dan tidak hanya mendaftarkannya.
8. Tidak ada downtime dalam pekerjaan server CI.
9. Selama reli, tidak jelas siapa pengembang dan siapa penguji.
10. Tim Anda dapat mengevaluasi kualitas produk. Semua orang mengerti bagaimana proses pengujian pada proyek bekerja.

Anda dapat memeriksa diri Anda menggunakan tautan - di sini penulis menjelaskan mengapa titik-titik ini disorot dan mengapa mereka penting.

Praktik Kolaborasi di DevOps

Semakin sering orang berkomunikasi, semakin mereka memahami apa yang dilakukan kolega dan bagaimana mereka dapat dibantu. Oleh karena itu, Katrina menawarkan mereka untuk membahas pengujian lebih sering. Ada beberapa cara untuk melakukan ini:

• Ulasan daftar periksa oleh analis dan dukungan. Terlibat dalam pengujian awal dapat meningkatkan kualitas rilis.
• Pengujian berpasangan: penguji dan analis, dukungan dan pengembang.
• Rotasi karyawan antara tim pengembang dan dukungan.
• Dojo (sebagai bagian dari pengembangan perangkat lunak) adalah lingkungan di mana orang dapat belajar dan mempraktikkan keterampilan pengembangan mereka bersama-sama: kelas master, berbagi pengetahuan.

Pengujian Produksi

Alat-alat berikut akan membantu memfasilitasi pengujian dalam produksi:

• Pemantauan terkonfigurasi sehingga Anda dapat dengan mudah menemukan dan mengidentifikasi masalah,
• Peringatan menggunakan berbagai saluran komunikasi: misalnya, pesan ke kurir jika server mogok, atau email saat kehabisan memori,
• Analytics (misalnya, Google Analytics), yang menunjukkan berapa banyak pengguna menggunakan fungsionalitas,
• Logging dapat dibaca.
• Umpan balik dari pelanggan - ulasan di toko, formulir umpan balik dalam aplikasi web.

PS

Ringkasan ini tidak termasuk banyak hal menarik. Buku ini ditulis dengan baik, kami merekomendasikannya kepada penguji yang berpikir tentang pengujian pada proyek-proyek DevOps.

Akhirnya, beberapa tautan bermanfaat:

• Buku itu bisa dibeli di sini .
• Tautan ke video kinerja Katrina dari Agile Testing Days 2017.
• Tautan ke blog Katrina Kloki.