Penafian: Ini adalah terjemahan dari sebuah artikel . Semua hak milik penulis artikel asli dan perusahaan Miro.
Saya seorang Insinyur QA di Miro . Biarkan saya memberi tahu tentang percobaan kami mentransfer tugas pengujian sebagian ke pengembang dan mengubah peran Test Engineer menjadi QA (Jaminan kualitas).
Pertama singkat tentang proses pengembangan kami. Kami memiliki rilis harian untuk sisi klien dan 3 hingga 5 rilis sisi server. Tim memiliki 60+ orang yang dilibatkan dalam 10 Tim Scrum Fungsional.
Saya bekerja di tim Integrasi. Tugas kita adalah:
- Integrasi layanan kami ke dalam produk eksternal
- Integrasi produk eksternal ke dalam layanan kami
Sebagai contoh, kami telah mengintegrasikan Jira . Kartu Jira - representasi visual tugas sehingga berguna untuk bekerja dengan tugas-tugas yang tidak membuka Jira sama sekali.
Bagaimana eksperimen dimulai
Semua dimulai dengan masalah sepele. Ketika seseorang dari Test Engineers sakit cuti maka kinerja tim terdegradasi secara signifikan. Tim terus mengerjakan tugas. Namun ketika kode itu mencapai tahap tugas pengujian ditahan. Akibatnya fungsi baru tidak mencapai waktu produksi.
Pergi berlibur oleh Test Engineer adalah cerita yang lebih kompleks. Dia perlu menemukan Teknisi Uji lain yang siap untuk mengambil tugas tambahan dan melakukan berbagi pengetahuan. Pergi berlibur oleh dua Teknisi Uji pada saat yang sama bukan merupakan kemewahan yang berlaku.
Kami sudah mulai berpikir bagaimana menyelesaikan masalah ini. Kami menemukan bahwa penyebab utama adalah bahwa fase pengujian adalah hambatan. Izinkan saya membagikan beberapa contohnya.
Kasus 1: Tugas ping-pong
Ada Saya dan Pengembang. Masing-masing punya tugas sendiri. Pengembang telah menyelesaikan satu tugas dan mengirimkannya untuk pengujian kepada saya. Sejauh tugas baru ini memiliki prioritas lebih tinggi, saya mengaktifkannya. Saya menemukan cacat, membesarkan mereka di Jira dan mengembalikan tugas ke Pengembang untuk perbaikan.
Saya beralih kembali ke tugas sebelumnya. Pengembang beralih dari tugas saat ini ke tugas yang dikembalikan. Setelah perbaikan, pengembang mengembalikan tugas kembali ke Saya untuk pengujian ulang. Saya menemukan cacat lagi dan mengembalikan tugas kembali. Ini bisa berlangsung lama.
Akibatnya akumulasi waktu yang dihabiskan untuk tugas meningkat dalam beberapa waktu dan oleh karena itu waktu ke pasar yang penting bagi kami sebagai perusahaan produk. Ada beberapa alasan peningkatan upaya:
- Tugas terus bergerak antara Test Engineer dan pengembang
- Tugas menghabiskan waktu menunggu Test Engineer atau Developer
- Pengembang dan Teknisi Uji harus sering beralih konteks antara tugas yang menyebabkan tambahan waktu dan energi mental.
Kasus 2: tugas antrian meningkat
Ada beberapa pengembang di Tim Scrum kami. Mereka mengirim tugas kepada saya untuk pengujian secara teratur. Itu membentuk antrian tugas yang saya lanjutkan berdasarkan prioritas.
Begitulah cara kami bekerja selama sekitar satu tahun. Namun selama ini perusahaan tumbuh. Jumlah proyek dan pengembang meningkat dan karenanya jumlah tugas untuk pengujian. Pada saat yang sama saya masih merupakan satu-satunya Test Engineer di Tim Scrum kami dan saya tidak dapat meningkatkan kinerja saya berkali-kali. Akibatnya semakin banyak tugas terjebak dalam antrian untuk pengujian dan proses ping-pong juga meningkatkan waktu tunggu.
Tiba-tiba saya sakit. Pengiriman Fitur Baru dari Tim Scrum kami ke produksi terhenti sepenuhnya.
Tim apa yang harus dilakukan dalam situasi ini? Mungkin untuk meminta bantuan Test Engineer untuk tim lain. Namun Test Engineer lain tidak dalam konteks dan tidak mendapatkan transfer pengetahuan di muka yang akan berdampak negatif pada kualitas dan jadwal di kedua tim.
Hasil dari kedua kasus dalam hal yang sama - tim terlalu tergantung dari test Engineers:
- Kecepatan tim dibatasi oleh kecepatan Test Engineer.
- Sejumlah pengembang tidak dapat ditingkatkan tanpa menambahkan Test Engineers karena tidak masuk akal untuk mempercepat pengembangan jika semua tugas yang dikembangkan terjebak dalam antrian untuk pengujian.
- Sementara Test Engineer memverifikasi tugas setelah Pengembang, tanggung jawab pengembang terhadap kualitas menurun.
- Jika Test Engineer tidak tersedia maka proses pengiriman menderita.
Mari menambahkan Test Engineers?
Ide yang jelas - mari kita meningkatkan jumlah Test Engineers. Itu bisa bekerja sampai saat tertentu: jumlah tugas akan meningkat tetapi tidak mungkin untuk meningkatkan jumlah Engineer Uji terus menerus. Itu akan terlalu mahal dan tidak efisien.
Lebih efisien adalah menjaga kecepatan dan kualitas dengan sumber daya saat ini. Itu sebabnya kami memutuskan untuk meluncurkan percobaan yang akan membantu tim untuk membuat fungsionalitas dengan kualitas bawaan dengan asumsi risiko dan kasus sudut. Kami menyebut eksperimen ini "Transform tester to QA" karena ini tentang transformasi satu peran dari penguji monyet yang mencari bug ke QA yang secara sadar memengaruhi dan memberikan kualitas di semua fase SDLC.
Mari kita tingkatkan proses pengembangan
Tujuan percobaan:
- Hapus ketergantungan tim dari Teknisi Uji tidak kehilangan kualitas dan waktu.
- Meningkatkan tingkat jaminan kualitas yang diberikan oleh QA dan tim.
Langkah penting pertama adalah mengubah pola pikir tim. Semua diharapkan bahwa Teknisi Uji secara eksklusif peduli dan bertanggung jawab atas kualitas.
Gagasan kami adalah menambahkan upaya dalam persiapan tugas dan verifikasi akan membantu mengurangi jumlah iterasi ping-pong. Oleh karena itu akan memungkinkan untuk memberikan fungsionalitas baru pada produksi menjaga kecepatan dan tingkat kualitas yang dapat diterima atau bahkan meningkatkannya.
Tim Scrum saya bersama dengan Teknisi Uji dari Tim lain telah menciptakan proses baru. Kami telah bekerja sesuai proses baru ini selama setengah tahun dan memperbaiki beberapa masalah muncul selama ini dan sekarang prosesnya terlihat seperti:
- Presentasi pada pernyataan tugas.
- Solusi teknis dan skenario pengujian.
- Pengembangan dan verifikasi.
- Lepaskan
Pernyataan tugas
Pemilik Produk menyajikan pernyataan tugas untuk Tim. Tim menganalisis pernyataan tugas untuk menemukan kasus sudut dari sudut pandang teknis dan produk. Jika ada pertanyaan yang muncul untuk klarifikasi atau investigasi maka itu dilacak sebagai tugas terpisah dengan waktu khusus dalam sprint.
Solusi teknis
Sebagai hasil dari Analisis adalah Solusi Teknis yang dibuat oleh satu atau beberapa pengembang. Semua rekan tim yang relevan bersama dengan QA harus meninjau dan menyetujui hal itu. Solusi Teknis berisi tujuan solusi, blok fungsional produk yang akan terpengaruh dan deskripsi perubahan kode yang direncanakan.
Solusi Teknis tersebut memungkinkan untuk menemukan solusi yang lebih ringan dan lebih tepat berdasarkan pengalaman peserta proses pengembangan yang relevan. Setelah Solusi Teknis terperinci, lebih mudah untuk menemukan dan menghindari masalah memblokir, lebih mudah untuk melakukan tinjauan kode.
Ini adalah contoh dari beberapa blok dalam Solusi Teknis:
Deskripsi tugas
Apakah entitas atau pendekatan baru diperkenalkan ke dalam sistem?
Jika ya, ini dijelaskan bersama dengan penjelasan mengapa tidak mungkin untuk menyelesaikan tugas dengan pendekatan saat ini.
Apakah interaksi server dalam cluster berubah? Apakah peran kluster baru diperkenalkan?
Apakah Model Data berubah?
Untuk server, ini tentang objek dan model.
Jika model data kompleks, maka dapat direpresentasikan diagram UML atau deskripsi teks.
Apakah interaksi klien-server berubah?
Uraian perubahan. Jika itu API, bisakah kami menerbitkannya? Jangan lupa tentang penanganan pengecualian yaitu alasan log yang benar.
Skenario pengujian
Secara paralel, Pengembang atau QA menciptakan skenario pengujian dengan asumsi kasus sudut dan titik masalah potensial. Jika itu dibuat oleh Pengembang maka QA harus memeriksanya pada kelengkapan. Jika Skenario Pengujian dibuat oleh QA maka Pengembang perlu meninjau dan mengonfirmasi bahwa sudah jelas bagaimana menerapkan setiap poin. Tim juga menilai Skenario Uji pada kebenaran.
Untuk membuat dan menyimpan skenario pengujian, kami menggunakan HipTest.
Pengembangan dan verifikasi
Pengembang membuat kode aplikasi berdasarkan Solusi Teknis dan mengasumsikan kasus sudut dan skenario pengujian. menyampaikan ulasan kode dan memverifikasi fitur terhadap skenario pengujian. Menggabungkan cabang menjadi master.
Pada tahap ini QA mendukung Pengembang. Misalnya membantu dengan mereproduksi kasus pengujian yang kompleks, konfigurasi lingkungan pengujian, melakukan pengujian pemuatan, berkonsultasi tentang memberikan fitur besar pada produksi.
Pelepasan fungsionalitas yang dilakukan
Ini adalah tahap terakhir. Di sini Tim mungkin perlu memberikan tindakan sebelum dan sesudah rilis. Misalnya beralih pada fungsi baru untuk pengguna beta.
Proses pengembangan baru telah dibutuhkan dari Pengembang lebih dalam melibatkan proses pengujian itu.
Oleh karena itu penting bahwa saya sebagai QA menyediakan mereka dengan semua alat yang diperlukan dan mempelajarinya Dasar-dasar Pengujian Fungsional. Bersama-sama dengan QA Tim lain, kami telah menyusun daftar dokumentasi yang diperlukan, telah membuat instruksi pengujian yang hilang dan telah memperbarui yang sudah ada termasuk yang tidak jelas untuk hal-hal Pengembang.
Kemudian kami telah memberikan akses kepada Pengembang untuk semua alat pengujian dan lingkungan pengujian dan telah mulai melakukan pengujian bersama. Pada awalnya Pengembang tidak ingin bertanggung jawab atas hasil pengujian karena tidak ada yang memverifikasi setelah mereka. Itu tidak biasa. Setiap Pengembang hanya memiliki Skenario Uji, fungsi yang dibuat oleh tombol Pengembang dan Gabung. Tapi mereka cepat beradaptasi.
Hasil Eksperimen
Sudah setengah tahun sejak awal Eksperimen. Ada grafik jumlah bug per minggu. Jumlah semua bug yang ditemukan diwakili oleh warna merah. Jumlah bug tetap diwakili oleh hijau. Garis kuning adalah awal dari Eksperimen.
Terlihat bahwa garis merah tetap pada tingkat yang sama kecuali tombak pada awal Eksperimen.
Jumlah bug tidak bertambah dan oleh karena itu kami menjaga tingkat kualitas saat ini.
Seiring dengan itu rata-rata waktu yang dihabiskan untuk tugas menurun pada 2%: 12 jam dan 40 menit sebelum Eksperimen vs 12 jam 25 menit setelahnya. Artinya kita berhasil menjaga kecepatan.
Akibatnya tidak ada lagi ketergantungan yang sulit dari QA dalam Tim. Jika saya sakit atau akan berlibur, Tim akan melanjutkan pengembangan tanpa kehilangan kecepatan dan kualitas.
Apakah kami menganggap Eksperimen berhasil meskipun kecepatan dan kualitasnya tetap sama? Ya kami melakukannya karena pada saat yang sama kami telah membebaskan kapasitas QA untuk pekerjaan sadar pada produk dan Strategi QA. Misalnya untuk pengujian eksplorasi, meningkatkan cakupan uji fungsional dan menjelaskan prinsip dan aturan pembuatan dokumentasi pengujian di semua tim.
Kami juga memiliki pola pikir eksperimen benih di tim lain. Misalnya dalam satu Tim QA sekarang tidak menguji apa yang dijelaskan dalam permintaan tarik oleh Pengembang karena Pengembang dapat memverifikasi sendiri. di Tim lain QA meninjau permintaan tarik dan menguji hanya kasus sudut yang rumit dan tidak jelas.
Apa yang harus diingat sebelum meluncurkan percobaan
Ini rumit dan jauh. Itu tidak bisa segera diimplementasikan. Itu membutuhkan persiapan dan kesabaran. Itu tidak menjanjikan kemenangan cepat.
Bersiaplah untuk tahan Tim. Bukan hanya cara untuk menyatakan bahwa mulai sekarang Pengembang akan memverifikasi fungsionalitas. Penting untuk mempersiapkan mereka dalam hal ini, menyusun pendekatan, menggambarkan pro-eksperimen untuk Tim dan produk.
Kehilangan kecepatan di awal tidak bisa dihindari. Waktu untuk transfer Pengetahuan untuk Pengembang, untuk membuat dokumentasi yang hilang dan untuk perubahan dalam proses itu merupakan investasi.
Tidak ada peluru perak. Proses serupa diterapkan misalnya di Atlassian, tetapi itu tidak berarti bahwa itu mungkin untuk menerapkannya di perusahaan Anda. Penting untuk mengadaptasi eksperimen untuk budaya dan spesifik perusahaan.