Tonton videonya, baca transkripnya, dan tulis opini Anda tentang pertanyaan bersuara di kolom komentar. Mari kita cari tahu bersama: menjadi atau tidak menjadi?
Diskusi nomor satu
Timecodes
0:56 - Apakah pengujian selalu diperlukan?
2:00 - Mengapa menguji kapan Anda perlu meluncurkan fitur ke pasar secepat mungkin?
3:24 - Apakah mungkin untuk menguji fungsionalitas dasar saja atau satu bagian dari aplikasi?
5:29 - Kriteria untuk menguji fungsionalitas
7:28 - Pada titik manakah perusahaan startup atau outsourcing harus berhenti merilis fitur dan mulai membuang-buang waktu untuk pengujian
Pertemuan segera dimulai dengan diskusi hangat. Oleh karena itu, kami akan memperkenalkan peserta dalam diskusi online kami:
- Dmitry Voronin, Insinyur utama di tim Kecepatan (Avito).
- Yuri Chechetkin, pengembang seluler (Revolut)
- Dmitry Manko, pengembang Android (Citymobil)
- Nina Semkina, Programmer Senior (Yandex.Money)
- Vladimir Genovich, Programmer Utama (Yandex.Money)
- Dmitry Zhakov, penguji (Yandex.Money)
Nina Semkina: Banyak orang mengatakan bahwa pengujian harus dimasukkan ke dalam proyek ... Tapi semua orang mengerti bahwa itu sangat mahal. Sangat mahal untuk menghabiskan waktu pengembang dan banyak sumber daya untuk mencakup semua kode dengan tes. Apakah pengujian selalu harus dilakukan?
Dmitry Manko: Apa yang akan Anda uji?
Nina Semkina: Aplikasi Android. Kapan saya perlu memahami bahwa 100% perlu diuji?
Dmitry Manko:Jika pasar tidak mengharapkan munculnya fungsi apa pun, maka, dari sudut pandang pengembangan atau dari sudut pandang cakupan, pengujian dapat disederhanakan atau sepenuhnya diabaikan. Itu semua tergantung produknya. Jika kita membuat kalkulator dengan 2 fungsi, maka kemungkinan besar kita telah melalui serangkaian kasus pengujian lebih dari satu kali. Dengan demikian, pengujian dapat dihilangkan, aplikasi dapat dipasarkan lebih cepat, dan waktu pemasaran dapat dikurangi.
Nina Semkina:Kami selalu memiliki perlombaan waktu-ke-pasar, pasar selalu membutuhkan banyak fitur, dan kami tidak dapat memperlambatnya. Apalagi kalau menyangkut proyek baru yang perlu diluncurkan di pasaran saat ini, kami tidak punya nama, kami bersaing dengan perusahaan lain. Apa yang kita pedulikan tentang pengujian saat ini? Kami perlu menyediakan aplikasi kami dengan fitur dan membuangnya lebih cepat, jika tidak, fitur tersebut akan menjadi usang dalam 3 minggu. Mengapa mengujinya?
Dmitry Voronin:Faktanya, kecepatan pengembangan di beberapa titik mulai bergantung pada cakupan pengujian. Jika, misalnya, sebuah bisnis secara arsitektural terikat dengan satu layar utama, di mana semua fitur utamanya berada, dan perubahan dilakukan di sana berkali-kali, maka tanpa pengujian Anda dapat mulai bergerak ke sana dengan lebih lambat, bahkan dengan "saluran fitur" yang besar. Tampaknya begitu ada sinyal bahwa Anda sering kembali pada regresi, yaitu, alasan untuk memikirkan tentang fakta bahwa ada yang salah dengan lapisan dan Anda tidak mengambil tindakan reaktif. Misalnya, ada yang sering rusak, artinya tempat ini tidak diuji sebagaimana mestinya.
Nina Semkina:Dapatkah saya membuat kesimpulan bahwa hanya fungsionalitas dasar yang perlu terus diuji, dan fitur harus dihubungkan "dalam satu titik". Biarkan fitur individu ini menjadi bug, tetapi mungkin fitur tersebut ada saat ini, dan tidak akan ada besok. Bisakah saya menguji hanya satu bagian dari aplikasi?
Dmitry Manko: Saya lebih suka mengatakan bahwa bagian-bagian penting layak untuk diuji. Yang penting dari sudut pandang bisnis untuk produk ini. Dan jika ada fitur dengan bug, mereka terletak di suatu tempat secara terpisah dan tidak mempengaruhi kesamaan, maka idealnya tutup dengan sakelar jarak jauh. Dan jika menurut analitik Anda melihat bahwa memang ada bug dan pengguna mengeluh, maka matikan fitur ini.
Dmitry Voronin:Dima menyinggung topik yang bagus, bahwa tes bukanlah satu-satunya alat kontrol kualitas yang dimiliki pengembang. Anda harus selalu ingat bahwa selain pengujian unit dan integrasi, pengujian manual, ada dan harus ada pemantauan. Dan ada cara untuk meluncurkan dan mengembalikan perubahan Anda. Jika Anda memiliki semua praktik teknik ini, maka pada prinsipnya Anda dapat mengabaikan beberapa alat untuk mendukung yang lain, jika kecepatan diuntungkan dari ini. Namun secara umum, akan selalu dianggap baik jika pengembang memiliki budaya pengujian - bahwa lebih nyaman dan dapat diandalkan baginya untuk menyampaikan perubahan sehingga ia telah menguji fungsionalitas yang harus dilakukannya. Di perusahaan kami, adalah kebiasaan untuk meninggalkan kode seperti itu, di mana Anda dapat dengan mudah membuat perubahan, dan dengan cepat menjalankan pengujian untuk memahami bahwa Anda tidak merusak apa yang telah terjadi.
Nina Semkina: Dalam obrolan mereka menulis bahwa Anda perlu menguji apa yang mendatangkan penghasilan. Dan ketika biaya pengujian kurang dari kemungkinan kerugian dari fungsionalitas non-kerja. Pada prinsipnya, ini adalah kriteria yang baik untuk memahami apa yang sebenarnya perlu diuji. Bisakah Anda menyebutkan kriteria lain untuk menguji fungsionalitas tertentu?
Dmitry Manko: Kriteria dapat diidentifikasi menggunakan analitik. Misalnya, jika Anda memperbaiki fungsi yang paling sering digunakan, maka disarankan juga untuk mengujinya agar pengguna sesedikit mungkin menemukan bug. Jika bug berada di tempat yang jarang, maka ini adalah masalah kecil. Dan jika larangan ada di layar otorisasi, itu mungkin tidak kritis, tetapi masih merupakan bug yang akan dilihat semua orang. Dan ini sudah menjadi risiko reputasi.
Dmitry Zhakov:Pengujian secara umum umumnya diperlukan. Kita tidak boleh lupa bahwa pengujian adalah pengujian persyaratan yang kami tempatkan pada suatu produk. Jika ada sesuatu yang tidak memenuhi persyaratan, maka ini adalah masalah, bug, masalah. Semua kasus pengujian dan pengujian dapat diotomatiskan, dan jika tidak ada cukup waktu, maka pertama-tama ada baiknya memeriksa momen kritis, lalu yang lainnya. Misalnya, jika Anda memiliki rilis besok dan bisnis Anda menginginkan fitur besok, maka Anda memeriksa fungsionalitas yang paling penting. Dan jika Anda memiliki cukup waktu, Anda dapat memeriksa kasing menengah dan rendah. Ini lebih merupakan pertanyaan apakah pengujian Anda akan manual atau otomatis. Baik itu metrik atau pengujian UI, sepenuhnya dapat diverifikasi oleh robot.
Nina Semkina:Sekarang kita semua berbicara atas nama perusahaan besar dengan banyak sumber daya dan peluang. Dan jika kita mempertimbangkan sudut pandang perusahaan kecil, startup, yang memiliki waktu dan sumber daya yang terbatas. Saya pikir pada awalnya semua orang akan mengorbankan pengujian di sana. Pada titik mana kita dapat memahami bahwa ini adalah tonggak penting ketika kita harus berhenti dan berhenti meluncurkan fitur dan menghabiskan sumber daya untuk pengujian?
Dmitry Manko:Saya dapat berbagi pendapat saya, karena saya berasal dari perusahaan outsourcing. Outsourcing terutama tentang di mana jam kerja dijual, dan pengujian sangat mahal di sana. Terkadang biayanya lebih mahal daripada mengembangkan fungsionalitas itu sendiri. Perusahaan outsourcing seperti itu, ketika pelanggan menunggu aplikasi dan "menendangnya di samping", tidak terkenal untuk melakukan pengujian. Di tim kami, kami dihadapkan pada situasi berikut. Produk adalah menu untuk bar, di mana promosi digunakan untuk banyak kasus (ulang tahun, 2 untuk 1, pelajar, dll.). Dan kami perhatikan bahwa fungsi stok ini rusak setiap bulan selama setahun. Dan kemudian Unit testing mendeskripsikan semua kasus secara ideal. Kami memahami bagaimana semuanya bekerja (ada sekitar 70 kasus uji). Kami mengalahkan produk ini, tetapi, tentu saja, ini tidak mungkin dilakukan di mana-mana.
Yuri Chechetkin:Pengalaman saya bekerja di perusahaan besar - Yandex, Alfa-Bank, Revolut - di fintech, di mana kekritisan bug apa pun menjadi tidak terkendali. Karena itu, saya memiliki pengalaman dalam sebuah startup, dan bahkan di sana, pengujian mutlak diperlukan. Saya pikir tidak masalah apakah itu startup atau tidak, karena pengembang harus bertanggung jawab atas kodenya, dan tes adalah jaminan bahwa kode ini berfungsi. Pengembang pada dasarnya adalah seorang insinyur yang bertanggung jawab atas produk yang dikembangkan. Oleh karena itu, Anda perlu menulis tes bukan karena Anda perlu, tetapi karena tes tersebut akan membantu Anda. Jika ini adalah tes yang ditulis untuk pertunjukan, maka ini dapat memperlambat pengembangan. Dan jika Anda membutuhkan tes dan Anda memahaminya sendiri, maka tes itu harus ditulis. Jika seorang pengembang menulis kode dan yakin bahwa ia bekerja tanpa tes, maka ini adalah risiko dan itu adalah pilihannya. Tapi saya masih berpikirbahwa pengembang tidak boleh mengambil risiko seperti itu dan harus menutupi dirinya sendiri dan menutupi semuanya dengan pengujian.
Nina Semkina: Jadi, kami memutuskan bahwa kami perlu menguji kode kami, kami akan menganalisis topik ini secara lebih detail. Sekarang saya memberikan kesempatan kepada Vladimir Genovich dengan laporannya .
Diskusi nomor dua
Timecodes
0:09 - Bagaimana cara menghapus beban regresi dari QA sebelum rilis? Apakah perusahaan memiliki strategi untuk meningkatkan stabilitas aplikasi?
4:25 - Apakah masuk akal untuk menggunakan objek tiruan atau palsu dalam tes UI
8:05 - Menguji pengguna: apakah dapat diterima atau tidak?
Nina Semkina: Selama laporan, kami menerima pertanyaan dalam obrolan, dan dari dia saya ingin melanjutkan diskusi kami. Bagaimana cara menghapus beban regresi dari QA sebelum rilis? Praktik apa yang digunakan pembicara kami dalam memilih tempat untuk pengujian? Apakah perusahaan memiliki strategi untuk meningkatkan stabilitas aplikasi dan membongkar spesialis QA?
Dmitry Zhakov:Strategi kami adalah kami menguji segalanya. Karena kami adalah perbatasan terakhir, sebagai karyawan sebelum pengguna. Oleh karena itu, kami hanya memberikan aplikasi seperti itu kepada klien, yang bekerja dengan stabil selalu dan di mana saja. Satu-satunya pertanyaan adalah kecepatan. Awalnya, proses manual memakan waktu lama - hingga seminggu. Namun berkat otomatisasi, kami telah mencapai bahwa rilis berlangsung rata-rata 24 jam. Oleh karena itu, jika Anda mengembangkan fungsionalitas apa pun, Anda harus menyetujui bahwa Anda atau penguji akan segera menulis autotest. Dan beberapa kasus khusus seluler yang tidak dapat Anda otomatisasi hanya perlu diperiksa pada regresi, dan robot akan memeriksa sisanya. Dengan demikian, Anda akan meringankan penguji, mereka akan terlibat dalam pekerjaan penelitian yang lebih menarik, dan Anda memberikan robot keseluruhan skrip klik rutin.
Yuri Chechetkin: Sebagian besar perusahaan besar menolak QA, pengujian manual. Ini sebenarnya bukan jalan revolusioner, tapi sedikit peninggalan masa lalu. Dan, misalnya, di perusahaan saya, tempat saya bekerja sekarang, kata seperti regresi bahkan tidak diucapkan. Kami tidak memiliki departemen QA sama sekali.
Vladimir Genovich: Anda mungkin mengotomatiskannya?
Yuri Chechetkin: Tidak juga, dia baru pada tahap awal proyek, dan kemudian dia menghilang sama sekali.
Vladimir Genovich: Anda menjalankan tes UI, bukan?
Yuri Chechetkin: Ada tes UI, tentu saja.
Vladimir Genovich: Dan Tes Unit? Jadi menjalankan tes ini saat rilis bukanlah regresi?
Yuri Chechetkin:Ya, ini adalah regresi, tetapi tidak ada pengujian manual yang biasa kita bicarakan. Dan itu pendekatan yang cukup menarik. Ini menenangkan dan mengubah pengembang dari "anak" yang menulis kode dan memberikannya kepada penguji, menjadi insinyur yang lebih dewasa dan independen yang bertanggung jawab atas kodenya sendiri. Untuk hal visual, review bisa dilakukan oleh designer atau PO. Dan ada hal-hal seperti tes tangkapan layar - seperti Facebook. Jadi tampaknya sekarang perusahaan makanan bisa hidup tanpa QA. Dan penguji sendiri dapat melakukan pekerjaan yang lebih menarik. Tentu saja, cerita yang sedikit berbeda dalam outsourcing - mereka menjual jam kerja, dan QA dapat dijual sebagai layanan tambahan.
Dmitry Zhakov:Ternyata Anda memiliki regresi, itu hanya diberikan ke otomatisasi, dan Anda memiliki orang-orang yang terlibat dalam pekerjaan penelitian aplikasi Anda. Pengujian tidak hanya dapat UI, tetapi juga berbeda.
Yuri Chechetkin: Ya, misalnya, menguji pengguna.
Nina Semkina: Sebelum kita menyentuh topik yang sangat berbahaya ini, saya ingin membaca pertanyaan berikut dari pendengar kita. Apakah masuk akal untuk menggunakan objek palsu atau palsu dalam pengujian UI?
Dmitry Voronin:Masuk akal, dan tanpa mereka tidak ada tempat. Karena pengujian UI dengan integrasi penuh sangat tidak dapat diandalkan. Dan Anda tidak akan pernah bisa mengandalkan pengujian yang memiliki 30 sistem, masing-masing dengan sekumpulan titik kegagalan menjalankan permintaan tarik. Tes semacam itu tidak layak. Dan tidak ada seorang pun di perusahaan mana pun yang dapat membuat hal-hal seperti itu berhasil. Oleh karena itu, pengujian UI adalah kutukan bagi pengembangan seluler. Jika memungkinkan, lebih baik menguji tanpa UI. Tetapi karena fakta bahwa kami dipaksa untuk hidup dengan kerangka kerja, dan satu-satunya alternatif adalah beberapa jenis robotika, dan di iOS, ini pun tidak. Dan untuk memeriksa interaksi dengan setidaknya salah satu sistem yang penting bagi kami, kami menjalankan semuanya di perangkat. UI ada di sini sejauh, karena ketidakdewasaan pengembangan kami, kami ingin menangkap hasil maksimal untuk memeriksa bagaimana pengguna mengklik - kami jadi lebih tenang. Menurut saya,bahwa setelah beberapa waktu ini akan menjadi sesuatu dari masa lalu dan kita tidak akan lagi takut diejek, klik dan tidak akan melawan sistem untuk memeriksa semuanya sebagaimana mestinya, karena bagaimanapun kita tidak akan memeriksa semuanya. Mungkin ada bug visual yang tidak akan diperiksa oleh tes UI apa pun. Oleh karena itu, saya percaya bahwa mengejek dalam pengujian UI dapat dan harus dilakukan, dan tujuan utamanya adalah untuk meningkatkan stabilitas alat ini, untuk membawanya ke keadaan yang berguna. Dan manfaat nyata dalam hal ini adalah memastikan tidak ada regresi. Dan instrumen apa pun yang memerah berubah menjadi "D" kedua dari laporan Vladimir Genovich sebelumnya, saat kita berhenti percaya. Ini terjadi ketika sejumlah besar nilai acak mulai masuk dalam pengujian kami. Dan ujian seperti itu tidak memberikan kepercayaan pada diri sendiri, tetapi hanya memberikan harapan palsu bahwa sesuatu telah diuji.
Dmitry Zhakov: Sekitar 70% kasus kami otomatis, dan mereka tidak menggunakan tiruan tunggal dalam aplikasi. Mungkin lebih mudah untuk memindahkannya ke backend. Misalnya, jika mengacu pada nomor kartu, maka Anda mengharapkan 3DS tidak diminta dari Anda. Artinya, aplikasi tidak mengetahui bahwa ia terkunci. Saya kira ini masalah infrastruktur.
Nina Semkina: Sebelum melanjutkan ke laporan berikutnya, saya ingin kami menyebutkan satu topik licin - pengujian pengguna. Banyak dosa ini: mereka selalu ingin dan menyuntikkan ... Apa pendapat Anda tentang ini? Apakah mungkin untuk meluncurkannya kepada pengguna secara diam-diam, mengumpulkan error dari mereka, dan memperbaikinya sendiri. Dan setelah mengujinya, luncurkan versi lengkap yang bagus. Atau apakah secara umum tidak dapat diterima? Atau apakah ada batasan yang masuk akal?
Yuri Chechetkin:Kami di Revolut mempraktikkannya sedikit dalam arti bahwa hal ini tidak langsung digunakan dalam pertempuran, tetapi pada pengguna yang sebenarnya. Demo juga beberapa pengujian pada pengguna, dan selama demo pertanyaan tentang aliran dan sebagainya muncul. Pada tahap ini mungkin ada pertanyaan tentang desain dan mekanika umum. Antara lain, ada pengguliran internal - perusahaan besar, lebih dari 1000 orang, dan kami dapat meluncurkan di antara rekan kerja. Ini adalah pengujian pengguna, tetapi tidak secara eksternal, dan tampaknya aman. Dan kemudian dapat diluncurkan ke sebagian kecil pengguna nyata di luar, tetapi dengan kemampuan untuk menutup fitur ini dengan sakelar. Menurut Anda, apa yang bisa salah selama tahap-tahap ini?
Dmitry Manko:Dalam kenyataan kami, hal-hal bisa salah. Tidak peduli seberapa keras kami mencoba untuk melakukan tahapan ini dengan baik, bagaimanapun, kasus melompat ketika kami perlu memantau analisis kerusakan. Rilis tidak berakhir dengan fakta bahwa kami mengirimkannya ke toko, semua tahap telah berlalu, semuanya baik-baik saja dengan kami. Anda perlu terus mengamati bagaimana aplikasi berperilaku.
Yuri Chechetkin: Pasti ya. Dalam kasus kami, kami memiliki demo, peluncuran internal, dan pengujian untuk 5% pengguna, bukan pengujian manual. Tentu saja, setelah rilis fitur tersebut, Anda perlu melihat. Penggulungan tidak boleh 100% langsung - ini adalah mekanisme pertahanan utama.
Dmitry Voronin:Masalah etika pengujian pengguna ditangani oleh Google untuk kami. Apple sepertinya tidak memiliki ini. Ada saluran distribusi khusus, seperti yang Anda tahu (produksi alfa, beta ...). Siapa pun dapat mengikuti pengujian beta, dan mereka setuju dengan formulir yang dapat dimengerti, yang mengatakan bahwa mereka secara wajar setuju bahwa mereka dapat menerima versi produk yang tidak stabil. Jadi dia ingin menjadi sukarelawan dan membantu perusahaan membuat produknya lebih baik. Segera setelah kami secara terbuka memberi tahu seseorang tentang hal ini, saya pikir masalah ini harus dihapus dan kami tidak perlu takut untuk meluncurkan versi yang kami tidak yakin 100% di sana. Lebih baik lagi, ketika kami mendapat umpan balik dari sana, dan dengan setiap rilis yang tidak stabil seperti itu, kami meningkatkan proses ini. Jika sebuah perusahaan memiliki proses yang melacak tren kualitas dalam versi beta, maka segalanya akan menjadi lebih baik.Dan ini juga merupakan nilai tambah bagi pengguna - mereka akan menjadi yang pertama menerima fitur. Ini terutama adalah pengguna yang termotivasi dan setia pada produk Anda, dan mereka sendiri ingin menguji hal-hal baru yang muncul di aplikasi. Dan mereka bahkan akan siap mengorbankan sesuatu untuk itu.
Nina Semkina: Kami memahami bahwa ketika kami berbicara tentang audiens yang setia, itu setia selama tidak mempengaruhi kepentingan pribadinya. Beginilah cara kami meluncurkan fitur dengan roti kecil tambahan, yang meskipun jatuh, pengguna ini tidak akan kecewa. Tetapi bahkan jika orang ini mengkonfirmasi bahwa dia siap untuk mengambil versi tes, tetapi ada sesuatu yang tidak beres dengannya (misalnya, uang tambahan akan dihapuskan), maka dia tidak akan setia lagi. Dan semakin besar perusahaan, semakin keras tanggapan pengguna tentang produk tersebut.
Vladimir Genovich:Tapi bagaimana dengan pengadopsi awal yang mencintai Anda, tidak peduli bagaimana perusahaan mengacau? Dan kemungkinan besar, perusahaan ini akan dapat memulihkan kerugiannya. Setuju, jika kami meluncurkan sesuatu, kami berkata kepada pengguna: “Dengar, kami sangat takut. Dan Anda bisa kehilangan 1000 rubel. Tapi kami akan mengembalikan uang Anda. " Kemungkinan besar, pengguna seperti itu akan melakukannya dengan risiko dan risiko sendiri, dan jika uangnya hilang, kami tidak akan memberitahunya nanti: "Yah, Anda sendirilah yang harus disalahkan." Oleh karena itu, menurut saya, bahkan dalam kasus aplikasi perbankan, kami dapat membantu pengguna.
Dmitry Zhakov:Dan jika Anda memiliki terlalu sedikit penguji beta, maka Anda dapat menggunakan pengujian A / B dengan bantuan konfigurasi untuk mengaktifkan / menonaktifkan beberapa fitur, sehingga jika terjadi crash Anda dapat segera menonaktifkan sesuatu dan mengujinya sesuai kebutuhan. Seperti yang kita ingat, sangat sulit untuk melakukan rollback di ponsel, jadi lebih baik untuk memeriksa semuanya secara maksimal sebelum rilis.
Vladimir Genovich: Atau tulis di React Native))
Nina Semkina: Saya akan menyela percakapan kita, karena sudah waktunya untuk laporan berikutnya. Dima, saya memberikan lantai untuk Anda.
Diskusi nomor tiga
Kode waktu
0:05 - Bagaimana cara meningkatkan pengujian regresi? Bagaimana dan kapan pengujian diperkenalkan dalam pengembangan fitur (pengalaman Avito)
10:43 - Di mana pengujian unit mengejar: pada CI atau secara lokal sebelum mendorong?
Nina Semkina: Saya ingin menghubungi Dima Voronin untuk mendengar pendapatnya dan tentang pengalamannya tentang bagaimana mereka meningkatkan pengujian regresi di perusahaan dan ketika mereka memperkenalkan pengujian saat mengembangkan fitur.
Dmitry Voronin:Saya benar-benar memiliki sesuatu untuk dibagikan. Ini adalah sejarah lima tahun berurusan dengan regresi manual. Dan ini sebagian merupakan kelanjutan dari jawaban atas pertanyaan yang kami miliki di antara 2 laporan pertama. Pertanyaan ini adalah tentang apa yang harus dilakukan jika Anda memiliki regresi manual. Karena tidak semua orang bisa mengulang pengalaman Revolut. Orang-orang itu hebat, mereka memotong dari bahu, dan mereka berhasil melakukannya dengan andal. Dibutuhkan banyak keberanian, budaya pembangunan yang baik, dan yang terpenting, memahami pemimpin pembangunan yang tidak merasa liar dengan pendekatan ini. Ini terjadi karena ada inersia dalam pekerjaan kami dan sulit untuk mengubah fondasi, terutama di perusahaan besar. Contoh Revolut membuktikan bahwa jika berhasil, setidaknya lebih cepat daripada regresi manual, dan setiap pengembang mulai menanyakan pertanyaan yang tepat kepada dirinya sendiri.Artinya, dia mulai bertanggung jawab atas sebagian besar siklus rilis, yaitu, tidak sampai saat dia melakukan perubahan, tetapi seperti teknisi dewasa lainnya, dia juga memimpin produk pada tahap rilis.
Apa yang terjadi dengan kami? Kami berada pada titik di mana kami memiliki regresi manual yang dilakukan oleh 5 orang selama 12 hari kerja, dan tanpanya aplikasi seluler tidak akan berfungsi. Itu tahun 2015. Dan pada saat itu kami tidak memiliki satu pun pengujian UI otomatis. Kami menulis unit test hampir dari awal dan menulis dengan cukup aktif. Vladimir dalam laporannya berbicara tentang 10 detik dan 1000 tes - menakutkan bagi saya untuk membayangkan ketika kami melewati momen seperti itu di tahun 2014. Sekarang kami memiliki 12.000 Unit-test, dan tidak memakan waktu 10 detik, ini juga bukan bagian gratis. Meskipun semua teknisi memahami dan menulis tes, ada saat yang sulit. Semua pengujian Unit ini tidak membuktikan satu gram pun tentang bug dalam produksi dan bagaimana aplikasi berperilaku. Artinya, pengujian menangkap perilaku, membuatnya lebih mudah untuk membuat perubahan dan memberikan umpan balik,apakah kamu melakukannya dengan benar Masalahnya adalah ada departemen QA. Tentu saja, bukan itu masalahnya. Masalahnya adalah mereka memiliki tugas untuk memberikan tingkat kualitas tertentu. Dan mereka terbiasa mencapai tingkat ini, mereka mengambil tanggung jawab ini. Dan sulit untuk mengubah momen ini jika tidak datang dari awal produk Anda. Resep apa saja yang tersedia? Hal yang paling benar adalah tidak mengaktifkan mode keras saat kita memecat semua orang dan semuanya diambil alih oleh otomatisasi. Ini mungkin pendekatan paling menakutkan dan paling tidak dewasa yang pernah saya lihat. Apa yang salah dengan itu? Pertama, kualitas pengujian akan hilang untuk beberapa waktu. Kedua, semua proses dihancurkan, dan yang baru tidak dibangun dengan cepat.Dan mereka terbiasa mencapai tingkat ini, mereka mengambil tanggung jawab ini. Dan sulit untuk mengubah momen ini jika tidak datang dari awal produk Anda. Resep apa saja yang tersedia? Hal yang paling benar adalah tidak mengaktifkan mode keras saat kita memecat semua orang dan semuanya diambil alih oleh otomatisasi. Ini mungkin pendekatan paling menakutkan dan paling tidak dewasa yang pernah saya lihat. Apa yang salah dengan itu? Pertama, kualitas pengujian akan hilang untuk beberapa waktu. Kedua, semua proses dihancurkan, dan yang baru tidak dibangun dengan cepat.Dan mereka terbiasa mencapai tingkat ini, mereka mengambil tanggung jawab ini. Dan sulit untuk mengubah momen ini jika tidak datang dari awal produk Anda. Resep apa saja yang tersedia? Hal yang paling benar adalah tidak mengaktifkan mode keras saat kita memecat semua orang dan semuanya diambil alih oleh otomatisasi. Ini mungkin pendekatan paling menakutkan dan paling tidak dewasa yang pernah saya lihat. Apa yang salah dengan itu? Pertama, kualitas pengujian akan hilang untuk beberapa waktu. Kedua, semua proses dihancurkan, dan yang baru tidak dibangun dengan cepat.kualitas pengujian akan hilang untuk beberapa waktu. Kedua, semua proses dihancurkan, dan yang baru tidak dibangun dengan cepat.kualitas pengujian akan hilang untuk beberapa waktu. Kedua, semua proses dihancurkan, dan yang baru tidak dibangun dengan cepat.
Apa yang telah kita lakukan? Kami memulai pengoptimalan kami dengan menulis pengujian UI yang menggantikan regresi. Artinya, ini adalah pengujian infrastruktur lengkap yang menyentuh backend dengan pengguna pengujian. Dan, nyatanya, hasil dari pekerjaan ini adalah, seperti yang Anda ketahui, semua jenis framework populer - misalnya, Kaspresso. Ini persis seperti yang kami letakkan saat kami mulai. Kami meninggalkan banyak artefak yang dapat membantu pengembang. Dan sekarang lebih mudah untuk melakukan pengujian. Kami juga menempatkan berbagai pelari di sumber terbuka, dan setiap orang dapat melihat bagaimana kami bekerja dengan mereka. Namun kami tidak melupakan pengujian manual, tentang pengoptimalannya, dan bagaimana kedua departemen ini mulai bergabung menjadi satu proses yang efektif. Mungkin titik B adalah negara bagian Revolut. Tapi jalan kami dari titik A ke titik B, seperti banyak perusahaan lain,membutuhkan waktu lama. Sekarang kita berada pada tahap ketika QA berperan sebagai peneliti, mereka lebih membenamkan diri dalam produk, mengerjakan persyaratan fungsional, menulis autotest.
Hal yang paling menarik dari praktik perbaikan regresi manual adalah analisis dampak. Artinya, upaya untuk menjawab pertanyaan: "Apa yang berubah dalam rilis ini?" Dan apa yang bisa kami uji dan apa yang bisa kami luncurkan dengan tenang ke tahap selanjutnya. Analisis dampak adalah pertanyaan yang sulit, karena ketika Anda memiliki siklus rilis yang besar, yaitu Anda dirilis selama 2-3 bulan, maka analisis dampak akan selalu menjawab Anda sama, karena selama waktu seperti itu, hampir tidak ada bagian aplikasi yang belum tersentuh. Tetapi jika Anda mempersingkat siklus rilis ini menjadi seminggu, atau bahkan lebih baik menjadi satu hari, maka analisis dampak menunjukkan hal-hal yang cukup memadai, meninggalkan tanda yang akan membantu mengoptimalkan regresi manual. Kami telah menerapkan praktik ini dengan cukup berhasil. Pada awalnya ada kesalahan, tetapi kami mengurangi jumlah pengujian manual satu kali.
Praktik selanjutnya adalah mengoptimalkan model pengujian. Anehnya, tetapi dalam tes ada juga warisan: tes ditulis, tetapi mungkin tidak terlalu optimal, kemudian sesuatu yang lain ditambahkan di sana, dan kasus uji tidak diproses untuk ini ... Dengan analisis terperinci, ternyata dapat dipersingkat beberapa kali jumlah skenario pengujian.
Ketiga arah ini memungkinkan kami mencapai titik kami merilisnya ke beta sekali sehari, seminggu sekali mencapai 100% pengguna, tidak ada regresi manual. Saya berharap cerita ini akan memotivasi perusahaan, yang tidak senang dengan status rilis mereka, untuk bertindak - untuk hanya menekan tombol rilis di masa mendatang, semuanya masuk ke pengguna, dan semua orang hanya melihat grafik.
Yuri Chechetkin:Ini, tentu saja, tidak hanya praktik Revolut, tetapi juga di seluruh dunia, digunakan oleh Google, Facebook, dan sebagainya. Saya setuju bahwa ini harus menjadi transisi yang mulus. Dan ketika banyak yang menjadi PO atau masuk ke QA otomatis, semuanya menjadi sedikit kabur, berkembang dan berubah menjadi sesuatu yang dikatakan. Dan di Rusia, tren ini baru saja dimulai. Dan seperti yang Anda katakan dengan benar, dia harus sesehat mungkin.
Nina Semkina: Ada pertanyaan seperti itu. Siapa yang menjalankan tes Unit di mana? Menggunakan CI atau secara lokal sebelum mendorong?
Yuri Chechetkin: Tampaknya mengemudi secara lokal adalah tugas pengembang, artinya, Anda tidak boleh melakukannya dengan paksa. Jelas bagi saya bahwa harus ada 100% pada CI.
Nina Semkina: Terima kasih untuk semua peserta atas diskusinya! Saya memberikan lantai ke speaker kamiDima Manko dengan laporannya.