Hai, nama saya Maksim Plavchenok, saya bekerja untuk Bercut, saya melakukan pengujian integrasi. Pada bulan September, saya dan tim saya melewati pencapaian penting: kami tidak menerima kesalahan apa pun sebagai hasil dari pengujian integrasi untuk rilis versi baru penagihan untuk operator seluler. Kami pergi ke ini selama dua tahun; Saya ingin memberi tahu Anda hari ini bagaimana kami berhasil mencapai tujuan kami.
Tidak ada kesalahan berdasarkan hasil uji integrasi - di sini kita berbicara tentang menguji fungsionalitas baru pada penerimaan bisnis di sisi operator. Sedikit penjelasan tentang cara kerja pengujian ini.
Kami merilis versi baru perangkat lunak penagihan sesuai jadwal, 6 kali setahun. Tanggal rilis pengiriman telah diketahui sebelumnya. Pada saat penulisan ini, kami telah menjadwalkan tanggal rilis untuk seluruh tahun depan.
Kekhususan ini dikaitkan dengan perlombaan operator seluler untuk time-to-market. Prinsip utama: pelanggan harus secara teratur menerima fitur penagihan baru. Pembayaran melalui smartphone, menyimpan nomor saat berganti operator, kemampuan untuk menjual lalu lintas yang tidak terpakai - pembaruan bisa berbeda.
"Kami mungkin tidak tahu persis apa yang akan kami rilis dalam satu tahun, tapi kami tahu tanggal pasti kapan pembaruan akan dirilis." Karena ini, dimungkinkan untuk mempertahankan ritme pembaruan yang diinginkan.
Di sisi pengembangan penagihan, sekitar 70 orang terlibat dalam rilis tersebut. Ini adalah 5-6 tim, masing-masing dengan spesialisasinya sendiri: analitik, pengembangan (beberapa tim), pengujian fungsional, pengujian integrasi.
Ya, kami memiliki air terjun dalam proyek penagihan. Namun cerita saat ini bukanlah tentang bagaimana kita secara radikal mengubah paradigma pembangunan dari air terjun ke Agile atau sebaliknya. Setiap pendekatan pengembangan memiliki kelebihannya sendiri dan bagus dalam kondisi yang tepat; Saya ingin meninggalkan diskusi ini di luar cakupan artikel ini. Hari ini saya ingin berbicara tentang perkembangan evolusioner: bagaimana kita bergerak menuju kesalahan nol saat penerimaan rilis dalam kerangka pendekatan pengembangan yang ada.
Zona ketidaknyamanan
Di awal cerita yang dijelaskan, dua tahun lalu, kami memiliki gambaran berikut:
- tim di akhir rantai pengembangan kewalahan; “Saatnya memberi kepada tim berikutnya, dan tim sebelumnya baru saja memulai bagian dari pekerjaannya”;
- pelanggan dapat menemukan sekitar 70 kesalahan setelah siklus pengujian kami.
Kesalahan yang dapat ditemukan menurut hasil uji integrasi bisa kecil (“bagian dari pesan ditampilkan sebagai tanda pisah”) atau bahkan kritis (“tidak ada transisi ke tarif lain”).
Kami memutuskan untuk mengubah penyelarasan ini: kami menetapkan tujuan - tidak ada kesalahan dalam penerimaan bisnis untuk fungsi baru.
Setelah satu tahun, kami dapat mengurangi jumlah kesalahan menjadi 10-15, dan pada pertengahan 2020 - menjadi 2-3. Dan pada bulan September kami berhasil mencapai target nol.
Kami berhasil karena peningkatan di beberapa bidang: alat, keahlian, dokumentasi, bekerja dengan pelanggan, tim. Peningkatan bervariasi dalam hal pentingnya: mengetahui secara spesifik dan proses pelanggan itu penting, pindah ke skala baru untuk menilai kompleksitas tugas adalah opsional, dan bekerja dengan motivasi tim sangat penting. Tapi hal pertama yang pertama.
Poin pertumbuhan
Alat pengujian integrasi utama adalah bangku pengujian. Di sana aktivitas pelanggan ditiru.
Stand bersama
Sampah dari produksi digulung ke bangku uji sehingga Anda dapat menguji dalam kondisi sedekat mungkin dengan pertempuran.
Hasil tangkapannya adalah bahwa tempat pembuangan di stan kami dan stan pelanggan bisa berbeda. Operator membuat dump, meneruskannya kepada kami, kami menguji fungsionalitas baru, menangkap dan memperbaiki bug. Kami memberikan fungsionalitas yang sudah selesai kepada pelanggan, kolega di sisi lain mulai menguji. Kami dan dump mereka dapat berbeda dalam relevansinya: kami menguji pada bulan Juli, operator - pada bulan Agustus, misalnya.
Perbedaannya tidak kritis, tapi tetap ada. Ini mengarah pada fakta bahwa ketika menguji di sisi pelanggan, kesalahan dapat muncul yang tidak kami miliki.
Apa yang kami lakukan: sepakat bahwa skema data yang digunakan untuk pengujian akan sama, dan secara umum kami akan memiliki pendirian yang sama.
Kelambatan pembuangan tetap ada, tetapi kami telah mengonfigurasi infrastruktur di mana kelambatan ini minimal. Karena itu, kami dapat mengurangi jumlah kesalahan yang disebabkan oleh perbedaan antara lingkungan pengujian dan produksi.
Memeriksa pengaturan sebelum pengujian
Saat kami memberikan software versi baru kepada operator, untuk pengujian di sisi pelanggan, kami perlu melakukan pengaturan. Konfigurasikan fungsionalitas baru, mungkin sesuaikan lebih lanjut yang lama.
Kami menulis dokumentasi untuk memberi tahu Anda tentang pengaturan yang diperlukan. Hanya di sini manual dapat menyampaikan informasi dengan distorsi. Dokumentasi ditulis oleh orang, dibaca oleh orang, dan dalam komunikasi orang ada kesalahpahaman.
Ini adalah kekhususan perangkat lunak kami: permintaan tinggi ditempatkan pada pengaturan dalam hal fleksibilitas dan ketersediaan. Pengaturannya rumit, dan tanpa komunikasi tambahan, tidak selalu mungkin untuk menyampaikan semua informasi yang diperlukan hanya dengan dokumentasi.
Akibatnya, pengaturan mungkin tidak selalu dilakukan dengan benar, yang mengarah pada deteksi kesalahan selama pengujian di sisi operator. Saat menganalisis, kami menemukan bahwa ini bukanlah kesalahan perangkat lunak, tetapi pengaturan. Kesalahan seperti itu membuang waktu yang berharga.
Apa yang kami lakukan: kami memperkenalkan prosedur untuk memeriksa pengaturan di sisi pelanggan sebelum memulai pengujian di stan operator.
Prosedurnya adalah sebagai berikut: pelanggan memilih kasing yang kami tunjukkan di dudukan yang dikonfigurasi. Kami menjalankan tes. Jika ada kesalahan, kami akan segera memperbaikinya; jika tidak, tes akan lulus.
Pendekatan ini memungkinkan kami untuk mengurangi jumlah kesalahan yang terkait dengan pengaturan yang salah selama pengujian integrasi.
Komunikasi tambahan seputar dokumentasi
Memeriksa pengaturan sebelum pengujian selain menjelaskan pengaturan ini di manual adalah salah satu contoh komunikasi tambahan di sekitar dokumentasi. Ada yang lainnya.
Misalnya, kami membuatnya sehingga setiap saat selalu ada spesialis di pihak kami, yang dapat dihubungi oleh pelanggan dengan pertanyaan tentang dokumentasi dan sistem secara keseluruhan. Sesuatu seperti saluran dukungan teknis khusus dengan spesialis berkualifikasi tinggi kami.
Penulis teknis kami telah menyelenggarakan lokakarya untuk mendidik karyawan klien tentang fungsi baru.
Proses transfer dokumentasi menjadi kurang rahasia, lebih berkelanjutan: informasi baru, klarifikasi, rekomendasi sekarang dapat dikirim dalam beberapa bagian setelah "pengiriman" dari manual utama; seperti yang terlihat atau sesuai permintaan.
Semua ini memungkinkan untuk menginformasikan pelanggan dengan lebih baik tentang fungsionalitas baru dan dengan demikian mengurangi jumlah kesalahan pada pengujian integrasi.
Keahlian dalam bekerja dengan sistem pihak ketiga
Untuk mengembangkan penagihan, kita harus dapat melacak lalu lintas. Ada sistem PCRF terpisah untuk ini. Panggilan dihitung dalam satu database, SMS di tempat yang sama, dan lalu lintas di database lain; dan ada perangkat lunak khusus yang menyinkronkan semua ini.
Pada saat yang sama, sistem PCRF adalah perangkat lunak berpemilik pihak ketiga. Yaitu, kotak hitam: kami mengirim data ke sana, kami menerima sesuatu sebagai balasannya, tetapi kami tidak dapat mengontrol apa yang terjadi di dalamnya. Selain itu, kami tidak dapat mengubah apa pun di sana.
Penyelarasan ini membatasi kemampuan kami untuk melokalkan dan memperbaiki bug terkait lalu lintas.
Apa yang kami lakukan: Kami mendirikan basis pengetahuan PCRF internal yang terpisah. Setiap insiden, setiap opsi penyesuaian, setiap wawasan - semuanya direkam dan dibagikan oleh tim.
Hasilnya, kami menjadi pengguna yang baik dari sistem PCRF, kami dapat menyesuaikannya dan memahami apa yang harus dilakukannya. Ini menghemat waktu untuk insiden sederhana. Dengan kasus yang kompleks, tentu saja, kami masih meminta bantuan pengembang sistem.
Lebih banyak stand
Fitur lain dalam menguji penagihan operator seluler adalah skrip kustom dapat diperpanjang dari waktu ke waktu. Script lengkap yang ingin kami uji bisa memakan waktu beberapa hari atau bahkan berminggu-minggu.
Sulit untuk menunggu berhari-hari atau berminggu-minggu selama fase pengujian. Pada kenyataannya, untuk memeriksa skenario seperti itu, paling sering itu hanya waktu untuk bersantai di database.
Untuk memundurkan waktu, Anda harus menutup semua sesi kecuali sesi Anda sendiri. Kami mendapatkan situasi ketika, secara bersyarat, 20 penguji dapat mendaftar untuk dua bangku tes, dan semua orang ingin memundurkan waktu. Ini antriannya. Dan antrian adalah kemungkinan bahwa pada tanggal pengiriman perangkat lunak yang disepakati, kita mungkin tidak punya waktu untuk memeriksa semuanya dengan benar.
Apa yang kami lakukan: menyiapkan dudukan terpisah untuk setiap penguji.
Hal ini memungkinkan kami untuk menghapus kesalahan yang terjadi karena “terlambat datang giliran saya untuk berdiri, tidak sempat”.
Virtualisasi
Persiapan booth bukanlah proses yang cepat. Anda perlu terhubung ke jaringan operator, meminta akses, dan itu belum semuanya. Prosedur lengkapnya bisa memakan waktu hingga beberapa minggu. Perjuangan mempersingkat waktu persiapan tribun merupakan arah penting untuk bergerak menuju tujuan nihil kesalahan.
Apa yang kami lakukan: Virtualisasi yang diaktifkan.
Menyalin mesin virtual dengan semua pengaturan yang diperlukan, perangkat lunak yang sudah diinstal sebelumnya, dan mengotomatiskan proses ini membantu mengurangi waktu untuk menyiapkan dudukan menjadi "dalam satu hari".
Perencanaan
Kesalahan dari tes integrasi juga merupakan akibat dari kesalahan perhitungan dalam perencanaan rilis. Kami banyak berayun, pada saat tanggal rilis tetap, tidak semuanya tepat waktu.
Apa yang kami lakukan: Menerapkan tenggat waktu sementara untuk setiap tahap pengembangan. “Jika Anda mengetahui tanggal berakhirnya, maka Anda mengetahui setiap perantara” - prinsip ini membantu kami mengontrol kecepatan gerakan dengan lebih baik menuju tujuan rilis.
Dukung dan lepaskan secara paralel
Pada awal perjalanan kami, ada situasi ketika "hutang" rilis terakhir bertentangan dengan rilis berikutnya. Setelah diterima, bug tiba di sisi pelanggan, dan semua orang pergi untuk memperbaikinya.
Di saat yang sama, jadwal rilis pun tidak bergerak. Akibatnya, pada saat tiba waktunya untuk menangani rilis berikutnya, kami masih dapat terus mengerjakan rilis sebelumnya.
Itu mungkin untuk mengubah situasi karena pemisahan dua grup dari tim: siapa yang akan memperbaiki kesalahan dari penerimaan dan siapa yang akan menangani rilis baru sesuai jadwal.
Pembagian itu bersyarat: tidak harus setengah di sana, tetapi setengah di sini. Kami dapat mentransfer orang antar kelompok sesuai kebutuhan. Dari luar, mungkin terlihat seolah-olah tidak ada yang berubah: di sini adalah orang dari tim, selama sprint dia mengerjakan bug dan fitur baru. Namun nyatanya, pemilihan kelompok perorangan merupakan perbaikan dari kategori "sekarang kita bisa menghembuskan napas". Fokus dari setiap kelompok dan paralelisasi pekerjaan antar kelompok sangat membantu kami.
Secara kronologis, ini adalah salah satu poin pertumbuhan pertama yang kami rumuskan pada postmortem. Dan di sini cerita saya sampai pada bagian tentang instrumen utama.
Alat utama
Perbaikan yang paling membantu kami adalah postmortem yang jujur.
Seseorang menyebutnya retrospektif, seseorang - analisis hasil; dalam tim kami, kata "postmortem" macet. Semua perbaikan yang dijelaskan dalam artikel ini ditemukan pada postmortems.
Prinsipnya sederhana: ada pelepasan, Anda perlu berkumpul dan secara jujur mendiskusikan bagaimana semuanya berjalan. Kedengarannya sederhana, tetapi ada kendala dalam penerapannya. Setelah rilis "tidak berhasil", orang-orang dalam tim memiliki mood "tidak ada waktu untuk menggaruk dengan lidah, Anda perlu melakukan sesuatu". Seseorang mungkin datang ke postmortem dan tetap diam (dan dengan demikian tidak memberikan beberapa informasi yang berpotensi berguna).
Selama dua tahun bergerak menuju tujuan nol kesalahan, kami telah mengembangkan sejumlah prinsip tentang cara kami melakukan postmortem.
- Kumpulkan gambaran lengkapnya
Kami mengundang daftar peserta yang diperluas. Pengembang, penguji, analis, manajer, eksekutif - semua orang yang memiliki keinginan untuk angkat bicara. Secara organisasi, tidak selalu mungkin untuk mengumpulkan semua orang, semua orang. Tidak apa-apa, cara kerjanya juga seperti itu. Intinya bukan untuk menyangkal partisipasi kolega dengan kalimat "di sini, di tim kami, kami merangkum hasilnya, Anda menyimpulkannya di milik Anda". Bekerja dengan stand, kode, proses, interaksi - kami berusaha untuk tidak melupakan aspek apa pun.
- Jangan memegang semuanya sekaligus
Oke, sebagai hasil dari postmortem, kami mendapatkan 30 poin pertumbuhan. Berapa banyak yang dibutuhkan untuk bekerja? Mungkin kita bisa menyelesaikannya sampai lain waktu? Format "pilih 2-3" paling cocok untuk kami. Dalam situasi ini, ada fokus, dan upaya orang-orang dalam tim tidak disebarkan. Lebih baik melakukan lebih sedikit, tetapi sepenuhnya, daripada banyak, tetapi tidak mengingatkan.
- Jangan pintar-pintar dengan formatnya
Ada banyak pendekatan untuk melakukan postmortem. Praktik fasilitasi, teknik dari pemikiran desain dan pemikiran lateral, teknik Goldratt dan ahli lainnya yang dihormati. Dalam pengalaman kami, akal sehat sudah cukup untuk memulai. Kami mencatat masalah, mengelompokkannya, memilih beberapa cluster, menyingkirkan sisanya (lihat poin sebelumnya), mendiskusikan, memperbaiki rencana. Jika ada tujuan yang sama, tidak sulit menemukan bahasa yang sama.
- Bawa bekerja
Mungkin prinsip utama dalam daftar ini. Betapa pun menjanjikan dan meyakinkannya daftar perbaikan setelah hasil postmortem, jika tidak berhasil, maka semuanya sia-sia. Kami setuju, lalu kami melakukannya. Ya, ada urusan mendesak lainnya. Tapi kami juga punya tujuan, dan kami ingin lebih dekat dengannya.
Postmortem bisa sangat menyakitkan. Berbicara tentang kegagalan, bahkan dengan cara yang konstruktif, tidaklah mudah. Tapi melawan ketidaknyamanan itu sepadan. Saya yakin tanpa postmortem kami tidak akan dapat menghasilkan dan mengimplementasikan semua hal yang membantu mencapai tujuan nol kesalahan dalam rilis.
Alat paling penting
Postmortem memungkinkan Anda menemukan cara untuk mencapai tujuan, tetapi jika Anda melihatnya, maka itu bisa disebut konsekuensi dari prinsip tingkat yang lebih tinggi.
Alat yang paling penting adalah keterlibatan tim.
Ada sisi instrumental dari keterlibatan. Misalnya:
- jika kita bekerja lembur, bos ada di samping tim, membantu dengan tangannya;
- jika Anda menghibur tim Anda dengan melacak kemajuan, maka Anda dapat menemukan metrik visual (tidak sulit untuk mengetahui jumlah kesalahannya).
Dan selanjutnya dengan semangat yang sama.
Keterlibatan juga memiliki sisi yang sulit untuk diformalkan - kemampuan untuk membagikan kepercayaan Anda pada kesuksesan dengan tim. Bagaimanapun, tim saya dan saya tidak hanya melihat ke dalam brosur dengan nilai-nilai perusahaan, melihat di sana "lebih kuat bersama-sama" dan memutuskan bahwa, bingo, sebuah solusi telah ditemukan. Kami telah melihat contoh bagaimana tujuan yang menantang dapat dicapai melalui penggabungan kekuatan. Kami memiliki orang-orang di tim kami yang percaya pada kesuksesan dan mencoba menyampaikan keyakinan ini kepada rekan-rekan mereka. Selebihnya adalah masalah teknologi.
Orang adalah hal terpenting.
Ada lebih banyak lagi dalam rilis menuju tujuan nol bug. Bekerja pada perbaikan dokumentasi, peningkatan kecepatan dan kualitas respon terhadap pertanyaan pelanggan yang berbeda. Kali ini saya mencoba membagikan hanya beberapa contoh dan berbicara tentang prinsip-prinsip dasar.
Saya dan tim masih memiliki banyak hal yang harus dilakukan dalam memperjuangkan kualitas rilis dan pengoptimalan waktu ke pasar. Buat hasil secara teratur dapat direproduksi dengan nol kesalahan pada pengujian integrasi, otomatisasi regresi.
Bagaimana mencapai tujuan tersebut masih harus dilihat. Tapi yang kami tahu pasti sekarang: kami pasti akan membuat postmortem dan menerapkan poin pertumbuhan berdasarkan motif. Dan kami akan mencoba menggunakan peluang yang dimiliki tim yang terlibat.
Semoga beberapa dari ini mungkin bisa membantu Anda juga.