Hai Kami membuka rekaman video laporan Heisenbug 2018 Piter. Dan terutama untuk Habr, kami membuat sepuluh laporan terbaik menurut pendapat para pengunjung konferensi - para ahli di bidang pengujian. Yang paling "offtopic" tiba-tiba menjadi laporan yang paling disukai!
Laporan dalam seleksi diberi peringkat dengan urutan yang meningkat. Tetapi ini tidak berarti bahwa "yang lebih muda" jauh lebih buruk: semua orang, kecuali para pemimpin, memiliki peringkat yang kira-kira sama dari 4,27 menjadi 4,52. Karena itu, seperti biasa, Anda perlu mengawasi semuanya. Temui aku di bawah luka!
Otomasi Perusahaan dengan Selenium dan mengapa sangat sedikit hubungannya dengan Selenium
Pembicara:
Michael PalotasLokasi: 10
Peringkat: 4,3 ± 0,1
Presentasi laporanBagian atas dibuka dengan presentasi oleh pencipta Selenium Grid Michael Palotas. Michael bertanggung jawab atas pengujian di eBay, memunculkan praktik-praktik teknik baru dan berhasil bekerja di Intel, Ericsson, dan perusahaan lain.
Michael tidak hanya berbicara tentang alat otomasi Selenium itu sendiri. Dia benar mencatat bahwa Selenium adalah "rasa sakit yang lebih rendah" dalam otomatisasi dan pengujian, dan memberikan banyak contoh praktis tentang bagaimana implementasi alat berubah menjadi bekerja pada proyek skala besar yang perlu dipertahankan dan dikelola.
Michael mengungkapkan masalah utama yang mencegah tim pengembangan dari menciptakan solusi yang terukur dan andal menggunakan Selenium, dan menunjukkan cara yang rapi dan hemat biaya untuk mencapai otomatisasi pengujian lengkap.
Apakah ada pengujian otomatis di video game seluler?
Pembicara:
Dmitry Alekseev / Evgeny ShumakovLokasi: 9
Peringkat: 4,3 ± 0,1
Presentasi laporanDi masa lalu Heisenbug, Philip Keks telah menyentuh pada topik auto-testing di game mobile, tetapi dalam kasusnya, game itu dengan gameplay yang sangat sederhana. Dalam laporan itu, Dmitry dan Eugene dari Zeptolab sama sekali tidak sederhana: apakah mereka memainkan Cut the Rope atau King of Thieves? Bagaimana cara menambahkan autests ke mereka, jika semua pemain memiliki perangkat yang berbeda, tidak ada kerangka kerja, dan bagaimana melacak bug?
Sebuah laporan oleh Dmitry dan Eugene menunjukkan bahwa tidak ada yang mustahil dalam pengembangan dan pengujian. Penguji Zeptolab telah datang dengan cara yang cukup sulit untuk menghilangkan koordinat dan dump adegan grafik dengan mengklik tes di Appium. Laporan ini mudah dimengerti bahkan untuk orang-orang dari bidang yang berbeda, dan menunjukkan dengan baik pada tahap apa dimungkinkan untuk menghemat waktu dan upaya pengembang di pengembang game mobile.
JUnit, beri aku lima! Kode porting ke JUnit 5 Extensions
Pembicara:
Dmitry TuchsLokasi: 8
Peringkat: 4,3 ± 0,1
Presentasi laporanDmitry Tuchs dengan yakin menyatakan: JUnit dibuat untuk semua tes. Baru saja muncul JUnit 5, yang menerima basis kode, arsitektur, dan API baru, tetapi kesederhanaan dan ekspresi kerangka tidak terpengaruh.
Dalam laporan tersebut, Dmitry jelas menunjukkan tidak hanya proses migrasi dari versi JUnit sebelumnya (hanya mengganti anotasi!), Tetapi juga berbagai gaya pengujian yang didukung JUnit 5, dan menjawab pertanyaan - apa gunanya beralih ke kerangka kerja baru secara umum.
Laporan ini berguna untuk semua penguji Java yang terlibat dalam pengujian pada proyek web skala besar, menulis fungsionalitas gaya AAA (Atur - Undang - Tegas, dan salah satu A di akhir laporan tidak lagi diperlukan), dan ingin membuat API sederhana sehingga pemula dapat bekerja dengan pelapis uji.
Pengujian Berdasarkan Petri Nets
Pembicara:
Alexey RodionovLokasi: 7
Peringkat: 4,35 ± 0,05
Presentasi laporanBayangkan bahwa tes Anda tidak dapat menemukan kesalahan yang terjadi dalam kondisi yang tidak biasa, dan membuat lebih banyak tes tidak lagi mungkin, karena waktu eksekusi melebihi semua batas yang mungkin.
Apa yang harus dilakukan Pergi ke perangkat matematika untuk mencari cara alternatif untuk mengembangkan tes menggunakan grafik. Komite program menyebutnya "Pengujian 2.0."
Laporan kode-penuh hardcore dari Alexei Rodionov tentang bagaimana Toptal beralih tentang tes konvensional untuk pengujian berdasarkan model matematika, apa yang baik dan buruk dapat ditemukan di jalan, dan mengapa Anda harus memperhatikan jaring Petri untuk mengoptimalkan pengujian.
Saat kecepatan dan penskalaan diperlukan: server perangkat iOS yang didistribusikan
Pembicara:
Nikolay AbalovLokasi: 6
Peringkat: 4.4 ± 0.2
Presentasi laporanPengembang pengujian UI mungkin tidak asing dengan masalah pengujian yang berjalan di iOS. Nikolai mengutip Badoo sebagai contoh - ketika ia mulai menyiapkan laporan, ada 1.200 tes end-to-end. Ketika selesai - 1300. Di konferensi, jumlah tes meningkat menjadi 1400. Ini adalah 35-40 jam waktu mesin dalam simulator, atau 1,5 jam waktu nyata.
Dalam laporan itu, Nikolai memberi tahu bagaimana ia berhasil mengurangi waktu pengujian menjadi 30 menit dengan masuk ke server perangkat, dan bagaimana ini membuat infrastruktur dan pengujian lebih mudah untuk diukur dan dipelihara. Nikolay berbicara tentang bagaimana "mengurai" sebuah simpul dari pengujian dan infrastruktur, dan belajar bagaimana menjalankan proses secara paralel menggunakan model paralelisasi baru. Untuk laporan ini, kami membuat
versi teks tentang Habré, sehingga Anda tidak hanya dapat melihatnya, tetapi juga membacanya.
Akhirnya - saran setengah komik dari Nikolai: jika Anda perlu mengurangi waktu untuk lulus tes - hapus saja bagian itu. Dan waktu akan berkurang, dan tidak akan ada lagi tes yang tidak dapat diandalkan, dan mudah untuk mengukur! Jika Anda perlu lebih serius - lihat laporan itu sendiri.
Pengujian Konfigurasi untuk Pengembang Java: Pengalaman Praktis
Pembicara:
Ruslan ChereminLokasi: 5
Peringkat: 4,4 ± 0,1
Presentasi laporanPada konferensi Heisenbug sebelumnya, Andrei Satarin berbicara tentang cara untuk menutupi tes tidak hanya dengan kode, tetapi juga dengan konfigurasi. Ruslan Cheremin bekerja dalam tim bersama Andrei dan terinspirasi untuk menggunakan pendekatan ini untuk tujuannya sendiri.
Ruslan dalam bentuk yang dapat diakses menceritakan apa yang dapat dianggap sebagai konfigurasi (semuanya!), Bagaimana menyingkirkan rasa malu dari menulis tes konfigurasi, dan mengapa ini penting, bermanfaat dan cukup sederhana. Presentasi hebat dengan contoh-contoh sederhana, banyak penyisipan kode dan penjelasan yang mudah tentang apa yang terjadi.
Penguji sebagai musuh terburuk mereka sendiri
Pembicara:
Michael BoltonLokasi: 4
Peringkat: 4,46 ± 0,07
Presentasi laporanMichael Bolton yang legendaris dengan keynote akhir yang harus diperhatikan setiap penguji.
Dia tidak akan berbicara tentang metode, alat, kerangka kerja, dan banyak lagi. Michael berbicara tentang esensi penguji, perannya dalam dunia TI, pentingnya profesi dan interaksi dengan orang-orang, bukan dengan aplikasi. Pengujian bukan tentang tes. Pengujian adalah tentang orang.
Michael mengungkapkan masalah profesi penguji, menyarankan bagaimana mengembangkan keterampilan profesional, sosial dan mental yang tidak hanya akan meningkatkan efektivitas seorang spesialis, tetapi juga rasa hormat di antara rekan kerja. Laporan yang sangat segar, tulus dan penting.
Apakah Anda masih melihat laporan Anda? Lalu kami pergi ke Anda!
Pembicara:
Artyom EroshenkoLokasi: 3
Peringkat: 4,52 ± 0,06
Presentasi laporanSlogan utama dari laporan ini adalah “Masalah apa yang kita pecahkan? Artyom dengan jelas dan jelas menggambarkan perubahan dalam versi Allure 3 yang telah lama ditunggu-tunggu dan menjelaskan mengapa fitur baru diperlukan - visualisasi, alat baru, konfigurasi tunggal, dan banyak lagi.
Laporan ini sederhana, menarik dan intuitif dan akan bermanfaat baik bagi mereka yang telah lama duduk di Allure dan tidak terbiasa dengan laporan jenis ini.
Pengujian fuzzing: mencari bug di kompiler JIT dan tidak hanya
Pembicara:
Maxim KazantsevTempat: 2
Peringkat: 4,6 ± 0,1
Presentasi laporanAda masalah. Orang mungkin tidak menyadari bahwa bug dalam aplikasi mungkin terkait dengan kompiler, dan kemungkinan bug dalam kompiler itu sendiri sulit diprediksi, dan menemukan bug serta memperbaikinya bahkan lebih sulit.
Jika dalam beberapa laporan koleksi menganjurkan untuk mengurangi jumlah tes, maka dalam menguji penyusun suasana mereka sendiri dan aturan mereka sendiri. Maxim Kazantsev dari Azul Systems menceritakan dalam laporan tempat kedua tentang bagaimana menyederhanakan kehidupan baik bagi mereka yang bekerja dengan kompiler dan dalam arah yang sama sekali berbeda menggunakan pengujian Fuzzing.
Sederhana: jika satu tes "baik" menemukan bug dengan probabilitas 10-6, maka itu tidak menemukan bug dengan probabilitas 0,999999. Dan lima juta tes TIDAK akan menemukan bug dengan probabilitas 0,9999995000000 ≈ 0,007. Jadi, ada bug dengan probabilitas lebih dari 99%!
Ini adalah jenis pengujian di mana jutaan tes acak dihasilkan yang melewati seluruh proyek, tanpa berpikir memeriksa semua yang mereka temui. Dan, anehnya, metode ini sangat membantu untuk menemukan masalah di mana Anda membutuhkan kecepatan dan keandalan yang tinggi.
Hardcore, laporan berkualitas tinggi dengan contoh kode. Pastikan untuk melihat setidaknya karena cara yang tidak standar dan menarik untuk mencari (dan menemukan!) Masalah dalam kode.
Pengujian hingga yang terakhir: pola desain antarmuka responsif yang cerdas
Pembicara:
Vitaliy FridmanLokasi: 1
Peringkat: 4,72 ± 0,06
Presentasi laporanDan inilah pemimpin daftar pendek kami, yang anehnya, bukan tentang pengujian sama sekali. Vitaliy Fridman, yang terkenal di kalangan desainer web dan pengembang web, berbicara kepada audiens yang tidak biasa di sini dan menaklukkannya!
Vitaly secara sistematis melewati semua tahapan UX dan berbicara secara rinci tentang komponen antarmuka dan masalah yang terkait dengannya dan dapat digunakan dalam pengujian. Ini termasuk penerapan "komidi putar" di berbagai negara, dan kiat untuk membuat perbandingan karakteristik barang yang benar-benar nyaman (dan tidak seperti biasanya), dan daftar periksa yang berguna dalam menciptakan "akordeon". Banyak pemirsa berkata: "Ya, ini bukan tentang pengujian, tapi itu luar biasa." Selamat menikmati!
Dan bagi mereka yang tidak sedikit, kami memberikan tautan ke
daftar putar , di mana ada pertunjukan lain dengan Heisenbug 2018 Piter.
Jika Anda tertarik dengan laporan, harap perhatikan: Heisenbug 2018 Moskow akan diadakan pada 6-7 Desember, di mana pengembang Selenium WebDriver Alexei Barantsev, yang telah menguji sejak 1994, akan datang.
Informasi paling terkini tentang program ini selalu dapat dilihat di situs web konferensi , dan di sana Anda dapat membeli tiket (harga yang secara bertahap meningkat).