Bagaimana cara menyederhanakan refactoring? Bagaimana cara mengajari pengembang untuk menghindari kesalahan umum di UI? Bagaimana cara menyenangkan penonton konferensi pengujian jika Anda sendiri bukan penguji?
Secara tradisi, membuka rekaman video laporan
Heisenbug untuk
semua orang , kami menerbitkan 10 teratas di Habré, yang disusun berdasarkan umpan balik audiens. Laporan dalam pos diatur dalam peningkatan peringkat: perbedaan antara tempat-tempat tetangga tidak signifikan, sehingga Anda tidak harus memberikannya banyak kepentingan, tetapi kemenangan utama di akhir. Siapa yang menjadi mereka saat ini?
Perlu merevisi proyek? Punya IDEA!
Pembicara:
Artyom EroshenkoPresentasi laporanBiasanya, IntelliJ IDEA dipahami sebagai "di mana Anda dapat membuat kode," bukan "apa yang Anda bisa kode." Tetapi pada kenyataannya, semua orang dapat memperluas fungsionalitas IDE dengan plug-in mereka sendiri - dan Artyom Eroshenko menggambarkan berdasarkan pengalamannya sendiri apa yang baik dalam konteks refactoring.
Banyak yang tahu Artyom dari laporan sebelumnya tentang Allure Framework. Dalam hal ini, semuanya berbeda: kata "Daya Pikat" juga dapat didengar di sini, tetapi bukan sebagai topik utama pidato, tetapi hanya sebagai satu contoh (transisi dari "Daya Tarik" versi pertama ke yang kedua).
Masalah di Selenium WebDriver
Pembicara:
Alexey BarantsevPresentasi laporanSudah ada banyak laporan, tutorial, dan teks dari berbagai penulis tentang alat yang populer seperti Selenium. Tetapi satu hal untuk mendengarkan beberapa pembicara yang memiliki alat ini, dan yang lainnya Alexei Barantsev, yang telah terlibat dalam pengembangan Selenium WebDriver sejak 2011.
Ketika Anda melihat proyek rumit dari dalam, Anda memahami banyak hal yang tidak terlihat jelas dari luar: misalnya, untuk keputusan yang mungkin tampak aneh bagi pengguna, alasan yang baik terungkap. Dan dalam hal ini, Alexey hanya berbicara tentang bagaimana situasi yang paling "membingungkan" dilihat dari dalam.
Resep untuk membuat dari awal dan pengembangan sistem pengujian beban
Pembicara:
Anatoly PlaskovskyPresentasi laporanAda dua hal dalam persepsi orang tentang pengujian stres yang tidak disetujui Anatoly. Salah satunya adalah ketika kegiatan ini dianggap "dipaku ke domain": mereka mengatakan bahwa dalam pengembangan game dan di fintech semuanya sangat berbeda sehingga pengalaman di salah satu area ini tidak akan berguna di yang lain. Lain adalah ketika kata-kata "stress testing" dan "work on performance" mulai digunakan sebagai sinonim.
Dan kedua ketidaksepakatan ini tercermin dalam laporan: di sini kita berbicara tentang metode umum yang dapat berguna dalam berbagai bidang, dan dengan hati-hati memilih konteks yang sesuai dari kata "memuat" dan "kinerja".
Sistem pengujian dengan dependensi eksternal: masalah, solusi, Mountebank
Pembicara:
Andrey GlazkovPresentasi laporanKetergantungan umumnya mempersulit pengujian, tetapi beberapa kasus bisa sangat rumit. Bagaimana jika sistem Anda harus berhasil berinteraksi dengan orang asing yang sedang dikembangkan secara paralel, dan dari orang asing Anda tidak memiliki kode atau data yang cukup lengkap, tetapi dalam prosesnya juga berubah?
Andrei Glazkov sendiri dihadapkan dengan kasus-kasus rumit sendiri dan berbicara tentang pengalaman yang didapat: dimulai dengan bagaimana, ketika mensimulasikan tindakan sistem eksternal, pembagian menjadi kepalsuan "konyol" dan "pintar" muncul, dan masalah yang muncul ("kode yang dengannya kita kami sedang menguji, itu menjadi sangat rumit sehingga sudah ada bug di dalamnya "), dan beralih ke bagaimana Mountebank memecahkan masalah.
Fitur pengujian visual antarmuka
Pembicara:
Anton UsmanskyPresentasi laporanAlat perbandingan tangkapan layar akan membantu Anda memperhatikan jika ada sesuatu yang "masuk" di antarmuka. Tetapi dalam mencari perbedaan ini, mereka mungkin menemukan tangkapan layar menjadi berbeda, di mana dari sudut pandang antarmuka semuanya tetap seperti sebelumnya. Apa sajakah kasus-kasus ini dan bagaimana cara belajar untuk langsung menolaknya tanpa membuang waktu? Dan bagaimana situasi umum ketika otomatisasi memberi sinyal perbedaan, tetapi untuk mata telanjang manusia, tangkapan layar umumnya terlihat sama?
Anton Usmansky sendiri terlibat dalam pengembangan alat-alat Gemini dan Hermione di Yandex, tetapi laporan itu tidak secara khusus tentang mereka, tetapi tentang prinsip-prinsip umum dari proyek-proyek tersebut. Sebelumnya,
versi teks dari laporan ini muncul di software-testing.ru.
Seribu Satu Bug UI, atau Cara Mengajari Pengembang untuk Menghindari Kesalahan UI Umum
Pembicara:
Ekaterina MikheevaPresentasi laporanHabrausers dapat mengingat
Ekaterina Mikheeva berkat
pos populer tentang jumlah perangkat Android yang diperlukan untuk pengujian. Dalam pembicaraan barunya, fragmentasi Android juga disebutkan, tetapi konteksnya berbeda.
Terkadang menguji UI itu menyenangkan, dan terkadang itu tugas dengan mulut yang pahit: kesalahan yang sama muncul lagi dan lagi, dan itu sama sekali tidak bisa dimengerti, dan sepertinya Anda membuang-buang waktu untuk mencoba memperbaiki seseorang untuk keseratus kalinya. itu adalah "tsya / tsya". Apa kesalahan ini dan apa yang harus dilakukan agar tidak menemui ini lagi? Bagaimana cara kerjanya mempengaruhi fakta bahwa kadang-kadang orang menulis seseorang di telepon seperti "Jangan mengangkat telepon (rusa)"? Dan bagaimana dari "alis" bisa muncul "mata robot"?
Temukan kembali pengujian eksplorasi
Pembicara:
Ingo PhilippPresentasi laporanJika para manajer dapat menyalakan mata mereka dengan kata-kata "test automation", maka dengan kata-kata "exploratory testing" mereka dapat keluar: tidak hanya pekerjaan tidak dapat ditransfer ke robot, juga sulit untuk memformalkan proses, tetapi bagaimana Anda dapat menghemat sumber daya perusahaan?
Ingo Phillip memulai dengan mengapa tanpa ini, perusahaan berisiko kehilangan lebih banyak lagi (“Anda dapat mengotomatiskan verifikasi risiko yang kami ketahui, tetapi bukan yang belum kami ketahui), dan kemudian melanjutkan ke cara hidup dengan itu ( misalnya, apa yang dilakukan dengan formalisasi proses yang sama). Mungkin, peringkat audiens sebagian terkait dengan nada ironis pembicara ("perangkat lunak pengujian seperti mencuci babi: proses tanpa awal dan akhir yang jelas, di mana pada akhirnya Anda tidak mengerti mengapa Anda terlibat di dalamnya dari awal").
Voyeurism Penguji, atau Bagaimana Pemantauan Pengguna Akan Membantu Anda
Pembicara:
Antonina KhisametdinovaPresentasi laporanLaporan tentang antarmuka ini dan kemungkinan kesalahan di dalamnya sudah tidak asing bagi Habr: kami sebelumnya membuatnya
versi teks , sehingga tidak hanya dapat dilihat, tetapi juga dibaca. Jadi, alih-alih uraian, kami hanya akan memberikan beberapa komentar dari para habrausers:
- “Artikel yang menyenangkan. Saya bahkan tidak tahu siapa yang mungkin lebih berguna untuk - QA atau perwakilan desain "
- "Pos yang luar biasa, tidak ada yang baru, tentu saja, tetapi semuanya dikumpulkan di satu tempat dan Anda dapat mengirim orang ke sini, terima kasih"
- “Sepertinya bagi saya ini harus menarik bagi semua pengembang yang setidaknya sedikit dihadapkan dengan antarmuka pengguna”
Kami memiliki DevOps. Mari kita memecat semua penguji
Pembicara:
Baruch SadogurskyPresentasi laporanBaruch terkenal oleh pengunjung di konferensi DevOops dan Joker kami, tetapi penguji melihatnya untuk pertama kalinya. Dapatkah konferensi diterima dengan baik di konferensi pengujian di mana kata-kata "Saya bukan seorang penguji" terdengar tepat di awal? Ternyata - lebih dari.
Di sini kita harus membuat reservasi penting: itu adalah keynote, yaitu, bukan laporan reguler di salah satu dari tiga kamar, tetapi pernyataan umum untuk semua audiens yang membuka konferensi. Oleh karena itu, tidak disebutkan di sini tentang perincian instrumen tertentu, tetapi tentang tren industri. Jika kata DevOps tidak memiliki huruf "QA", lalu apa gunanya devops untuk penguji? Apakah mereka perlu takut pada pekerjaan mereka ketika para pengembang secara mengejutkan secara aktif menulis tes sendiri?
Sebagai keynote, sangat penting bahwa tidak hanya materi yang bagus, tetapi juga pembicara yang cerah - dan ini tidak dapat diambil dari Barukh, Anda akan langsung mengenalinya dari ribuan bahkan dengan suaranya yang keras, bahkan oleh topinya yang berwarna-warni. Dan pada akhirnya, ia memenangkan cinta penguji, mengambil tempat kedua di peringkat ini.
Ekstrim pengujian: trik dari sudut-sudut gelap antarmuka seluler
Pembicara:
Vitaliy FridmanPresentasi laporanJika konferensi dimulai dengan Baruch, maka dengan pidato ini berakhir, yaitu, para pembicara utama menduduki kedua peringkat teratas dari peringkat tersebut. Dalam hal ini, seperti Baruch, karisma dan daya tarik pembicara memainkan peran besar, dan ia juga bukan seorang penguji: Vitaliy adalah pendiri situs terkenal untuk pengembang web / desainer
Smashing Magazine . Ketika sebuah situs mengajari orang lain untuk membuat antarmuka dengan benar, tidak mengherankan bahwa dia sendiri dipikirkan dengan cermat - sehingga Vitaly tahu banyak tentang antarmuka.
Sebelumnya, dia sudah tampil di Heisenbug di St. Petersburg, dan kemudian mengumpulkan ulasan seperti "ini bukan soal pengujian, tapi itu luar biasa." Dan sekarang dia datang ke Moskow, dan kali ini materi presentasi berbeda dari sebelumnya - tetapi antusiasme juga tidak kalah.
Bagi mereka yang sedikit jumlahnya, lebih banyak video Heisenbug 2018 Moscow -
klik di sini .
Jika Anda menyukai laporan ini, perhatikan: pada 17-18 Mei Heisenbug berikutnya akan diadakan di St. Petersburg . Berbeda dengan hub ini, di sana Anda tidak hanya dapat melihat laporan, tetapi juga secara pribadi mengajukan pertanyaan kepada pembicara: masing-masing, setelah pidatonya, menjawab secara rinci di area diskusi khusus. Rincian yang ada tentang program ini ada di situs . Lebih dekat dengan tanggal, program ini akan menjadi lebih sepenuhnya diketahui - tetapi harga tiket secara bertahap meningkat, sehingga membelinya terlebih dahulu menguntungkan. Dan sekarang hari-hari terakhir menerima aplikasi untuk laporan akan datang, jika Anda ingin tidak hanya "melihat orang lain", tetapi juga "menunjukkan diri Anda" - tanggapi!