Saya bekerja sebagai insinyur QA di
Miro . Saya akan memberi tahu Anda tentang eksperimen kami dalam mentransfer ke pengembang bagian dari tugas pengujian dan mengubah peran penguji menjadi peran QA (Jaminan kualitas).
Pertama, secara singkat tentang proses pengembangan kami. Kami memiliki rilis klien setiap hari dan 3 hingga 5 rilis server per minggu. Tim pengembangan memiliki 60+ orang yang dibagi menjadi 10 tim scrum fungsional.
Saya bekerja di tim Integrasi, yang tugasnya adalah mengintegrasikan layanan kami ke dalam produk eksternal dan mengintegrasikan produk eksternal ke dalam layanan kami. Misalnya, kami
mengintegrasikan pelacak tugas Jira . Kartu Jira - tampilan visual tugas yang dapat Anda kerjakan dengan mudah di papan tanpa pergi ke Jira.
Bagaimana eksperimen dimulai?
Semuanya dimulai dengan masalah biasa. Ketika salah satu penguji pergi ke daftar sakit, kinerja tim sangat berkurang. Tim terus mengerjakan tugas, tetapi kode mencapai tahap pengujian dan tugas dihentikan. Akibatnya, fungsionalitas baru tidak mencapai produksi tepat waktu.
Keberangkatan penguji saat berlibur adalah cerita lain. Dia perlu menemukan terlebih dahulu salah satu penguji yang siap untuk mengambil tugasnya selain dari dirinya sendiri, untuk setuju, untuk terlibat dalam tugas. Pada saat yang sama, dua penguji pergi berlibur adalah kemewahan yang tidak diizinkan.
Kami mulai berpikir bagaimana menyelesaikan masalah, dan menyadari bahwa masalah sebenarnya adalah leher sempit dari proses pengembangan sedang diuji. Saya akan menunjukkan kepada Anda sebuah contoh dari beberapa cerita.
Kisah pertama: rollback tugas tanpa akhir
Ada juga pengembang. Masing-masing memiliki tugasnya sendiri. Pengembang menyelesaikan salah satu tugas dan memberikannya kepada saya untuk pengujian. Karena tugas ini memiliki prioritas lebih tinggi daripada tugas saya saat ini, saya beralih ke tugas itu. Saya menemukan bug, saya mendapatkan semuanya di Jira dan mengembalikannya kepada pengembang untuk direvisi.
Saya kembali ke tugas yang harus ditunda. Pengembang beralih dari tugas baru ke tugas yang saya kembalikan. Dia mengoreksi bug dan mengembalikan saya untuk pengujian. Saya menemukan bug lagi dan mengembalikan tugas lagi. Proses ini bisa berlangsung untuk waktu yang sangat lama.
Akibatnya, total waktu kerja pada tugas meningkat beberapa kali, diikuti oleh peningkatan Waktu ke pasar, dan ini sangat penting bagi kami sebagai perusahaan makanan. Ada beberapa alasan untuk menambah waktu yang dihabiskan untuk tugas:
- Tugas ini terus bergeser antara pengembangan dan pengujian.
- Tugasnya adalah menunggu penguji atau pengembang.
- Pengembang dan penguji harus berganti tugas secara rutin, yang membutuhkan waktu dan energi tambahan.
Kisah kedua: garis tugas yang terus bertambah
Tim scrum kami memiliki beberapa pengembang. Mereka secara teratur menyerahkan tugas mereka kepada saya untuk pengujian. Bentuk antrian tugas yang saya lakukan, berdasarkan prioritas.
Jadi kami bekerja selama sekitar satu tahun, tetapi selama waktu ini perusahaan telah tumbuh secara signifikan: jumlah proyek dan pengembang telah meningkat, dan karenanya jumlah tugas dalam pengujian. Pada saat yang sama, saya masih satu-satunya penguji di tim kami dan tidak bisa melipatgandakan kecepatan saya. Akibatnya, semakin banyak tugas yang terakumulasi dalam antrian pengujian, dan proses transfer tugas antara pengembang dan tester meningkatkan waktu tunggu.
Tiba-tiba saya sakit. Pengiriman fitur baru dari tim produksi kami telah sepenuhnya berhenti. Apa yang harus dilakukan tim dalam situasi seperti itu? Anda dapat meminta bantuan tester dari tim lain. Tetapi, dengan tingkat probabilitas yang tinggi, dia tidak akan terbenam dalam spesifikasi kami, yang akan berdampak negatif pada kualitas dan waktu kedua tim.
Kesimpulan dari kedua cerita itu sama - tim terlalu bergantung pada penguji:
- Kinerja seluruh tim dibatasi oleh kinerja tester.
- Jumlah pengembang tidak dapat ditingkatkan tanpa menambah staf penguji.
- Peningkatan kecepatan pengembangan tidak masuk akal jika semua tugas jatuh ke antrian untuk pengujian.
- Sementara pekerjaan pengembang diperiksa oleh penguji, rasa tanggung jawab pengembang terhadap kualitas berkurang.
- Jika tidak ada tester, maka proses menghasilkan fungsionalitas baru menderita.
Mari kita meningkatkan staf penguji?
Pikiran yang paling jelas adalah meningkatkan staf penguji. Ini akan berhasil, tetapi hanya sampai titik tertentu: jumlah tugas akan terus bertambah, dan tidak mungkin untuk meningkatkan jumlah penguji secara tak terbatas - pada titik tertentu akan menjadi mahal dan tidak efisien.
Fedor Ovchinnikov , CEO Dodo Pizza,
menulis dengan baik tentang masalah "pemikiran sumber daya" (tidak bisakah Anda menyelesaikan masalah? Pekerjakan karyawan lain).
Jauh lebih efisien untuk mempertahankan kecepatan dan kualitas pengembangan dalam sumber daya saat ini. Karenanya, kami memutuskan untuk meluncurkan percobaan yang akan membantu tim membuat fungsionalitas dengan segera, dengan mempertimbangkan semua risiko dan situasi perbatasan. Mereka menyebutnya Transform tester ke QA, karena ini tentang transformasi salah satu peran dalam tim: dari penguji monyet, mengidentifikasi kesalahan oleh pengembang, ke insinyur QA yang secara sadar memastikan kualitas di semua tahap proses pengembangan.
Mari kita tingkatkan proses pengembangan
Tujuan percobaan:
- Untuk menghapus ketergantungan tim pada penguji, tetapi tanpa kehilangan kualitas dan waktu.
- Meningkatkan jaminan kualitas oleh para insinyur QA dalam tim.
Langkah pertama adalah mengubah pemikiran tim. Setiap orang terbiasa bertanggung jawab atas kualitas tim.
Hipotesis kami adalah bahwa meningkatkan waktu untuk mempersiapkan dan menguji tugas akan membantu mengurangi jumlah iterasi dalam mengerjakan satu tugas. Ini, pada gilirannya, akan memungkinkan membawa fungsionalitas baru ke produksi tanpa kehilangan kecepatan dan tingkat kualitas, dan mungkin lebih cepat dan dengan kualitas yang lebih baik.
Bersama dengan tim dan dengan penguji dari tim lain, kami mengembangkan skema kerja baru. Selama setengah tahun, ketika tim mengerjakannya, kami memperhitungkan kesulitan dan masalah yang muncul di sepanjang jalan, dan hari ini kelihatannya seperti ini:
- Presentasi produksi.
- Solusi teknis dan skenario pengujian.
- Pengembangan dan verifikasi.
- Lepaskan
Pernyataan masalah
Pemilik Produk menyajikan pernyataan masalah kepada tim. Tim menganalisis formulasi untuk mengidentifikasi situasi batas dari sisi teknis dan produk. Jika ada pertanyaan yang perlu diselidiki lebih lanjut - tugas terpisah ditetapkan, untuk mana waktu dialokasikan dalam sprint.
Solusi teknis
Hasil analisis perumusan masalah adalah solusi teknis, yaitu satu atau lebih pengembang. Semua karyawan perusahaan yang relevan, termasuk QA, harus terbiasa dan setuju dengan solusi teknis. Solusi teknis menjelaskan masalah yang sedang kami pecahkan, blok fungsional produk yang akan terpengaruh, dan rencana yang diusulkan untuk membuat perubahan pada kode.
Solusi ini memungkinkan Anda mengidentifikasi solusi yang lebih sederhana dan lebih baik berdasarkan pengalaman peserta yang relevan dalam proses pengembangan. Memiliki deskripsi teknis terperinci di tangan - lebih mudah untuk melihat dan menghindari masalah pemblokiran, lebih mudah untuk melakukan tinjauan kode.
Berikut adalah contoh beberapa blok dari solusi teknis:
Deskripsi tugas
Apakah entitas atau pendekatan baru ditambahkan ke sistem?
Jika demikian, mereka dijelaskan dan dijelaskan mengapa tidak mungkin untuk menyelesaikan masalah dalam kerangka pendekatan yang ada.
Apakah interaksi server berubah dalam gugus? Apakah peran cluster baru ditambahkan?
Apakah model data berubah?
Untuk server kita berbicara tentang objek dan model.
Jika model data rumit, Anda dapat menyajikannya dalam bentuk diagram UML, atau sebagai deskripsi teks.
Apakah interaksi antara klien dan server berubah?
Deskripsi perubahan. Jika ini adalah API, dapatkah itu diberikan kepada pengguna eksternal? Jangan lupa tentang penanganan kesalahan - mis. menunjukkan alasan yang benar.
Skenario pengujian
Sejalan dengan ini, pengembang atau QA menyusun skenario pengujian yang memperhitungkan semua tempat yang memungkinkan di mana masalah telah terjadi. Jika pengembang melakukan ini, ia harus memberikan skrip ke QA, yang memeriksa kelengkapan dan kecukupannya. Jika skrip QA, pengembang harus mengkonfirmasi bahwa ia memahami bagaimana masing-masing itemnya dapat diselesaikan. Tim juga mengevaluasi naskah untuk kebenaran.
Untuk kompilasi dan penyimpanan skrip, kami menggunakan HipTest.
Pengembangan dan Validasi
Pengembang mulai menulis kode berdasarkan solusi teknis dan mempertimbangkan semua situasi yang mungkin dijelaskan dalam dokumentasi pengujian. Memberikan ulasan kode dan memeriksa kode terhadap skenario pengujian. Menghasilkan penggabungan dalam master.
Pada tahap ini, QA memberikan dukungan yang diperlukan kepada pengembang. Sebagai contoh, ini membantu dengan memainkan case yang kompleks, mengatur lingkungan pengujian, melakukan pengujian beban, dan menyarankan kemungkinan nuansa keluaran fitur besar untuk produksi.
Rilis fungsionalitas siap
Ini adalah tahap terakhir. Di sini, tim mungkin diminta untuk melakukan tindakan pra-pasca-rilis, misalnya, dimasukkannya fungsi baru untuk pengguna beta.
Dokumentasi dan Alat
Skema kerja yang baru membutuhkan pengembang lebih banyak pencelupan dalam proses pengujian. Karena itu, sebagai QA, penting bagi saya untuk memberi mereka semua alat yang diperlukan dan mengajarkan dasar-dasar pengujian fungsional. Bersama-sama dengan QA dari tim lain, kami membuat daftar dokumentasi yang diperlukan, membuat instruksi pengujian yang hilang dan menyelesaikan yang sudah ada dengan mempertimbangkan hal-hal yang tidak jelas bagi pengembang.
Kemudian kami memberi pengembang akses ke semua alat pengujian dan lingkungan pengujian dan mulai melakukan pengujian bersama. Pada awalnya, pengembang tidak ingin bertanggung jawab atas hasil pengujian, karena tidak ada orang lain yang memeriksa apa pun untuk mereka, itu tidak biasa bagi mereka. Setiap pengembang hanya memiliki skrip pengujian, fungsi yang ia kembangkan, dan tombol Gabungkan. Tapi lambat laun mereka terbiasa.
Hasil Eksperimen
Enam bulan telah berlalu sejak awal percobaan. Grafik menampilkan statistik jumlah bug per minggu di tim kami. Warna merah menunjukkan jumlah semua bug yang ditemukan oleh tim, hijau - jumlah bug yang diperbaiki.
Dapat dilihat bahwa level garis merah tetap pada level yang sama, kecuali untuk burst pada awal percobaan. Tidak ada bug lagi, yang berarti kami telah mempertahankan tingkat kualitas saat ini.
Pada saat yang sama, waktu rata-rata untuk mengerjakan tugas menurun hanya 2%: sebelum dimulainya percobaan, itu adalah 12 jam 40 menit, setelah - 12 jam 25 menit. Jadi kami dapat mempertahankan kecepatan pekerjaan saat ini pada tugas.
Akibatnya, tim kami tidak lagi memiliki ketergantungan yang kuat pada QA. Jika saya sakit atau pergi berlibur - tim akan terus bekerja tanpa kehilangan kecepatan dan kualitas.
Apakah kami menganggap percobaan ini berhasil, meskipun faktanya indikator waktu dan kualitas tetap sama? Ya, kami percaya, karena kami mempertahankan kecepatan dan kualitas pekerjaan dan meluangkan waktu QA untuk pekerjaan yang lebih sadar pada kualitas produk dan proses pengembangan. Misalnya, untuk melakukan pengujian penelitian, tingkatkan cakupan tes fungsional dan jelaskan prinsip dan aturan untuk pengembangan dokumentasi pengujian di semua tim.
Di tim lain, kami menabur benih percobaan. Misalnya, dalam salah satu perintah, QA sekarang tidak menguji apa yang dijelaskan oleh pengembang dalam permintaan tarik, karena pengembang dapat melihatnya sendiri. Di tim lain, QA menganalisis perubahan permintaan dan hanya memeriksa kasus yang kompleks dan tidak jelas.
Hal yang perlu diingat sebelum memulai percobaan
Ini adalah eksperimen yang rumit dan panjang. Ini tidak diterapkan dengan satu klik jari, Anda harus hati-hati mempersiapkannya dan tidak menunggu hasil yang cepat.
Bersiaplah untuk negativitas tim. Anda tidak bisa mengambilnya dan mengatakan bahwa sekarang pengembang sedang menguji fungsionalitasnya. Kita perlu mempersiapkan mereka untuk hal ini, mengembangkan pendekatan, menjelaskan nilai percobaan untuk tim dan produk.
Hilangnya kecepatan di awal tidak bisa dihindari. Waktu untuk melatih pengembang, menulis dokumentasi yang hilang, dan membangun kembali proses membutuhkan waktu, yang harus disumbangkan ke percobaan.
Tidak ada solusi siap pakai. Proses serupa diterapkan, misalnya,
dalam Atlassian , tetapi ini tidak berarti bahwa Anda juga akan dapat mengimplementasikannya sendiri. Adaptasi dengan budaya perusahaan dan spesifikasi tim adalah penting.