Satu setengah tahun yang lalu, kami menghancurkan tim pengujian: kami mengabaikan regresi, mentransfer autotest E2E ke Selenium untuk mendukung pengembang, dan menyebar di antara tim yang melihat fitur untuk mencegah bug sejak awal. Dalam mimpi indah, bagi kami tampaknya itu akan lebih berguna: QA berfungsi pada kualitas, pengujian dimulai lebih awal, dan pengembang menulis autotest sendiri dan tidak ada yang mengganggu mereka.
Tapi
Apa konsekuensi urutan pertama dan kedua
Ray Dalio dalam Principles memiliki konsep "konsekuensi urutan kedua". Ini adalah konsekuensi yang tidak jelas dari keputusan kita, yang seringkali tidak dapat kita prediksi. Misalnya, pada tahun 60-an abad ke-20, perang dengan burung pipit diluncurkan di Tiongkok. Burung pipit memakan biji-bijian, dan agar mereka berhenti memakannya, Tiongkok mulai berburu burung. Selama perburuan, orang Cina membunuh hampir dua miliar burung secara massal.
Akibat genosida burung pipit, panen meningkat setelah setahun. Ini adalah konsekuensi urutan pertama. Tetapi tidak ada yang memakan serangga dan belalang dan ulat berlipat ganda, yang mulai menghancurkan lebih banyak tanaman, yang menyebabkan kelaparan besar-besaran di China pada tahun-tahun berikutnya. Ini adalah konsekuensi orde kedua.
Konsekuensi urutan pertama adalah konsekuensi langsung dari keputusan kita dan selalu ada di permukaan. Konsekuensi urutan kedua tidak kentara dan seringkali berjangka panjang. Untuk memahaminya, Anda perlu memikirkan dan mensimulasikan situasinya. Misalnya:
- Jika Anda membayar pengembang untuk jumlah baris kode, akan ada lebih banyak kode, tetapi kualitasnya akan lebih buruk. Seiring waktu, orang akan mulai menipu dan menghasilkan lebih banyak kode buruk untuk mendapatkan lebih banyak uang. Ini adalah konsekuensi orde kedua.
- Jika Anda mulai berolahraga, awalnya akan terasa sakit dan membutuhkan waktu lama. Tetapi setelah beberapa saat (dari seminggu hingga berbulan-bulan) sebuah kebiasaan akan muncul, dan kesehatan serta penampilan akan meningkat. Ini adalah konsekuensi orde kedua.
- Jika Anda mabuk seperti babi setiap hari Jumat, maka Jumat malam akan baik. Tetapi Sabtu pagi akan menjadi buruk - ini adalah konsekuensi urutan kedua. Dan jika Anda melakukan ini secara teratur, selama bertahun-tahun, maka mungkin itu akan berkembang menjadi alkoholisme dan sirosis hati. Tapi ini sudah merupakan konsekuensi urutan ketiga dan "cerita yang sama sekali berbeda."
Kami memiliki tim QA dan kami "membubarkannya"
Sekarang saya akan memberi tahu Anda bagaimana kami merasakan konsekuensi dari urutan pertama dan kedua. Kami memiliki tim penguji khusus yang terdiri dari 7 orang: 4 di antaranya menulis autotest, dan 3 mengujinya secara manual. Di beberapa titik, kami memutuskan untuk berpisah dan membubarkan diri dalam beberapa tim. Mengapa?
Karena pengembang terlambat menerima umpan balik.
Bug berada pada tahap ketika semua pengembangan "selesai", semuanya "terintegrasi" dan perlu untuk memeriksa apakah produk siap untuk dirilis. Tidak ada pengujian penerimaan , itu dilakukan oleh analis produk yang tidak memiliki keterampilan pengujian. Selain itu, penguji dan pengembang berada di dunia yang berbeda dan sedikit berinteraksi.
Solusi yang jelas (kemudian) adalah memisahkan tim yang mengerjakan fitur (bagian) tertentu dari sistem untuk mencegah bug sejak awal. Kami tidak ingin melepaskan pekerjaan kami, jadi kami memutuskan untuk mentransfer fungsi kami ke pengembang. Kami memikirkan tentang autotests - kami akan menyerahkannya kepada pengembang dan mereka akan menguji diri mereka sendiri tanpa masalah.
Pertama, mereka memutuskan untuk menguji hipotesis pada diri kami sendiri dengan sebuah "eksperimen": kami akan membahas skenario kritis regresi dengan pengujian otomatis dan menolak regresi manual. Jika, sebagai hasil dari pengalaman, jumlah hotfix dan rollback rilis tidak meningkat secara dramatis, eksperimen tersebut dapat dianggap berhasil. Dan begitulah yang terjadi - tidak ada lagi perbaikan terbaru. Terselesaikan - tidak setuju.
Catatan . Perusahaan tersebut memiliki produk bernama Restoran. Ini mencakup semua layanan dan monolit kami. Tujuan dari produk ini adalah untuk mengotomatiskan dan mengoptimalkan pekerjaan semua karyawan restoran semaksimal mungkin. Pekerjaan kami sekarang lebih berfokus pada pencegahan kesalahan. Sekarang kita adalah QA dalam produk "Restoran": kita mengembangkan kualitas dalam produk, kita berpartisipasi di semua tahap pengembangan tugas.
Konsekuensi urutan pertama dan kedua
Konsekuensi langsung . Seperti yang diharapkan, kami mulai terlibat dalam pengembangan tugas dari awal, berpartisipasi dalam PBR, perencanaan, lokakarya, dan membawa keahlian pengujian kepada mereka. Kami menjadi lebih dekat dengan tim pengembang, atau lebih tepatnya menjadi bagian darinya, dan masalah kami juga merupakan masalah tim. Keahlian dalam pengujian, jaminan kualitas, dan pengetahuan luas tentang sistem mulai tumbuh di tim. Kami, pada gilirannya, mulai membenamkan diri dalam pekerjaan pengembang dan memahami penderitaan mereka.
Sekarang, yang tidak kami rencanakan adalah konsekuensi urutan kedua .
Tidak ada yang mendorong kualitas produk . Ada 2 sisi dari masalah ini:
- kualitas dalam hal proses;
- kualitas tes otomatis dan jalur pipa.
Dalam tim QA kami yang berdedikasi, kami telah mendorong kualitas. Kami adalah orang terakhir yang melihat produk di depan pengguna dan memahami bagaimana mereka melihatnya. Kami membahas perubahan dan perbaikan pada tim retro, datang dengan proposal ke tim pengembangan untuk memutuskan bersama apakah mereka harus diperkenalkan atau tidak. Kami memantau autotest dan memperbaiki stabilitasnya.
Setelah kami berpencar dalam tim, semuanya menghilang entah kemana. Dalam tim pengembangan, kami adalah bagian dari tim,
Semua ide ditujukan hanya untuk meningkatkan keadaan tim - kami melakukan segalanya untuk merilis fitur berkualitas, bukan produk berkualitas. Akibatnya, solusi yang sangat kuat yang dapat meningkatkan kualitas produk ke tingkat yang baru tidak lagi muncul.
Kompetensi menulis autotest telah menghilang - autotest mulai membengkok dan lebih sering jatuh tanpa mengubah kodenya. Pada saat tim dibubarkan, penguji manual baru mulai memahami dasar-dasar otomatisasi. Ternyata baik penguji maupun pengembang tidak memiliki keahlian apa pun. Selain itu, keahlian menjadi bingung ketika orang yang menulis tes ini beralih ke pengembangan, manajemen produk, dan seseorang berhenti.
Kami tidak tahu pasti autotest apa yang kami miliki, apa yang dicakupnya, kami tidak tahu bagaimana mereka berkembang, berevolusi, menambah atau menghapus - semuanya diserahkan kepada belas kasihan pengembang. Akibatnya, ketika diperlukan untuk menemukan beberapa informasi di autotests, itu adalah pencarian yang sama yang tidak dapat Anda ketahui tanpa pengembang.
Pekerjaan ekstra untuk pengembang . Sulit menjadi pengembang. Jika sebelumnya mereka biasa menulis kode produk, yang secara “ajaib” diverifikasi dan masuk ke produksi, sekarang mereka perlu menulis tes sendiri, mengedit dan menstabilkan. Di PBR kami menentukan skenario mana yang harus dicakup oleh pengujian, dan pengembang memilih sendiri tingkat autotest.
Para pengembang melewati beberapa tahap untuk menerima
Penyangkalan... Semua rilis Dodo IS diluncurkan oleh pengembang. Mereka mengatur proses, berkomunikasi dengan tim pengujian beban, melihat log dan memantau selama rilis. Pengembang yang meluncurkan rilis, dihadapkan dengan tes merah, tidak mencoba mencari tahu alasannya, tetapi hanya memulai kembali pipa sampai berubah hijau 5-7-10 kali. Ini karena tidak ada kepercayaan pada tes otomatis.
Jumlah maksimum restart yang saya temukan adalah 44 kali !!! Menurut saya aturan yang kami adopsi di salah satu retro "Jangan rilis dengan tes merah. Jika tesnya berwarna merah, cari tahu apa masalahnya. Jika masalah ada dalam pengujian, perbaiki atau tanda tangani dan buat kartu untuk membuka kunci pengujian dan menambahkannya ke backlog. "
Marah : pengembang bersumpah pada pengujian kami, mereka mengatakan bahwa mereka
Tidak ada tawar-menawar atau depresi, penerimaan segera datang : pengembang sekarang dapat menulis tes E2E UI dan API sendiri, menstabilkan dan meningkatkannya.
Jumlah bug yang dijual mulai meningkat . Bug non-kritis mulai merembes ke dalam produksi. Ada beberapa alasan untuk ini:
- Tes otomatis kami tidak mencakup semua fungsi, tetapi hanya yang penting. Dan tidak ada lagi pengujian regresi manual.
- Tidak ada cukup insinyur QA untuk semua tim. Tim tidak memiliki kompetensi pengujian, sehingga mereka tidak memperhatikan pengujian
Akibatnya, kami mulai menemukan bug dalam produksi secara tidak sengaja. Mereka tidak kritis, tetapi berapa banyak dari mereka secara umum yang tidak terbayangkan.
Bagaimana kita mengatasi masalah ini
Mungkin tim lain bisa memprediksi semua konsekuensi yang tidak jelas, tetapi kami tidak bisa. Kami membuat keputusan, setelah beberapa bulan melihat konsekuensinya, dan mulai menghilangkannya.
Membuat guild Restaurant QA atau Community of practice, yang mencakup semua QA Restoran. Tujuan komunitas adalah untuk mendorong kualitas seluruh produk, untuk menyebarkan praktik pengujian yang baik ke semua tim produk. Ini adalah pendidikan yang menggabungkan keunggulan tim QA yang berdedikasi dan kami juga mendapat manfaat dari QA dalam tim pengembangan.
Kami bertemu sekali seminggu: kami berbagi hasil, penemuan, dan berencana untuk bekerja sama dalam hal kualitas. Kami juga mengalokasikan beberapa slot per minggu untuk mengerjakan tugas-tugas serikat. Misalnya, kami sedang menyelesaikan bot asisten kami untuk pelepas.
Tugas... Guild menutupi sebagian masalah kurangnya kualitas pemilik dan autotest. Tetapi guild tidak memiliki kompetensi yang kuat dalam pengembangan dan otomatisasi, jadi CTO kami membuat keputusan yang berkemauan keras dan mengatur tugas yang sedang dikerjakan.
Sekarang developer dapat meningkatkan proses pipeline secara sistematis: menstabilkan, menemukan masalah yang menunda rilis, dan memperbaikinya. Satu pengembang dari tim pengembang menjadi pemilik pipa selama sebulan dan secara sistematis memperbaikinya. Bukan merilis, tetapi meningkatkan - ini membuat proses rilis dan dukungan pengujian menjadi mudah dan mudah. Sekarang setelah metrik produk meningkat, kami menyingkirkan penjawab ini, tetapi kami dapat mengembalikannya kapan saja. (Sementara menulis artikel, kami kembali karena pemberitahuan mulai stabilitas mendegradasi)
Program... Kami menutup masalah kurangnya kompetensi dengan kursus untuk penguji manual dan pekerjaan berpasangan dengan pengembang yang berpengalaman dalam otomatisasi.
Pekerjaan ekstra untuk pengembang . Tidak ada yang dapat Anda lakukan, pengembang baru saja mencapai tahap menerima tes otomatis. Sekarang mereka menulis pengujian E2E sendiri, jika pengujian tingkat yang lebih rendah tidak dapat mencakup fitur, dan mereka menstabilkan pipeline. Seperti yang mereka katakan di buku pintar, ini adalah praktik yang baik ketika seluruh tim, pengembang, dan penguji dapat menulis tes. Ini juga memengaruhi perjalanan kami ke sisi layanan mikro minum dari monolit. Ada lebih sedikit tes di monolit, dan lebih banyak lagi di repositori terpisah, pipa menjadi lebih stabil.
Kami menyelidiki produk tersebut... Kami memecahkan masalah bug dalam produksi dengan mulai menyelidiki produk untuk ketidakkonsistenan dengan perilaku yang diharapkan. Kami telah menjadwalkan sesi pengujian eksplorasi mingguan. Dan kami membawa bug ke backlog ke pemilik produk.
Apa yang akan kita lakukan sekarang?
Kegagalan untuk mempertimbangkan konsekuensi urutan kedua dan ketiga telah menyebabkan keputusan yang buruk. Ini sangat berbahaya ketika opsi pertama dan bukan yang terbaik memperkuat bias yang sudah ada. Tapi sekarang, dengan semua pengalaman yang didapat, kami akan bertindak berbeda.
Misalnya, hilangnya kompetensi dapat diatasi dengan meminta mereka untuk berbagi kompetensi dengan semua teknisi QA dalam suatu produk atau pengembang dari tim beberapa bulan sebelum transisi orang dengan kompetensi dalam otomatisasi. Dan lebih baik sekaligus.
Tidak ada cara untuk mengimbangi masalah pekerjaan ekstra untuk pengembang , tetapi itu mungkin untuk mengurangi rasa sakit menulis tes dengan tidak meletakkannya di depan fakta, tetapi:
- tunjukkan nilai tes secara eksplisit;
- ajari pengembang untuk menulis, meningkatkan dan memelihara tes ini;
- ( ), .
Ketika kami berpisah, kami bahkan tidak memikirkan masalah ini. "Kalau dipikir-pikir" sepertinya, yah, bagaimana mungkin, memikirkannya itu dasar. Tapi di belakang kita semua kuat - coba prediksi masa depan.
Konsekuensi urutan kedua atau ketiga bagi saya mungkin merupakan konsekuensi urutan pertama untuk orang yang lebih berpengalaman yang telah membuat keputusan seperti itu berkali-kali dan telah melihat hasil dari keputusan tersebut.
Terlalu banyak ketidakpastian dan variabel yang mempengaruhi hasil.
Penting untuk tidak memprediksi konsekuensinya, tetapi, setidaknya, untuk mengetahui apa yang mungkin terjadi. Sebelum membuat keputusan apa pun, penting untuk memikirkan tentang kemungkinan konsekuensi yang akan terjadi, membaca informasi tentang kasus di perusahaan lain untuk setidaknya memiliki gambaran tentang skala kemungkinan konsekuensi yang tidak jelas.
Siapa pun yang belajar memprediksi konsekuensi urutan kedua (dan bahkan ketiga) dari keputusan apa pun akan dapat menyelamatkan atau menghancurkan umat manusia. Atau menghasilkan uang lebih banyak daripada Scrooge McDuck - setidaknya dari fluktuasi harga saham.
Bagaimana saya akan mencoba memprediksi konsekuensinya sekarang
Saya membaca artikel tentang topik ini dan menyimpulkan sendiri beberapa aturan yang, menurut penulis, akan membantu memprediksi konsekuensi semacam itu. Saya akan mencoba menggunakannya:
- Sebelum membuat keputusan - tanyakan pada diri Anda pertanyaan "Apa yang akan terjadi selanjutnya?" dan menambahkan slot waktu ke pertanyaan. Apa yang akan terjadi dalam 10 menit, 10 bulan atau 10 tahun?
- Latih pemikiran Anda terhadap konsekuensi tersebut dengan memikirkan situasi yang berbeda. Misalnya, apa konsekuensi dari urutan kedua atau bahkan ketiga pertama jika seluruh dunia beralih ke mobil listrik, atau, misalnya, memperkenalkan pendapatan tanpa syarat dasar. Tidak ada jawaban yang benar dalam latihan ini, tetapi ini akan membuat Anda berpikir lebih luas.
- Ingatlah bahwa pikiran pertama di kepala Anda adalah urutan pertama. Selalu.
Jika Anda mengalami masalah lain saat mengubah organisasi tim penguji atau tim lain, tulis di komentar, akan menarik untuk mengetahui masalah apa yang Anda hadapi dan bagaimana Anda menyelesaikannya.
P.S. 2 QA- « » . . : , , SRE- mobile SRE . . , : (@EvgenSkt) HR (@alexpanev).
, , , : « » « » ( «» — ). QA, « ? ».
-, .