Alexey Barantsev mungkin salah satu orang paling terkenal dalam pengujian Rusia: ia dikenal baik oleh
software-testing.ru , dan oleh
selenium2.ru , dan dengan partisipasi dalam Selenium WebDriver, dan tidak hanya. Pada saat yang sama, ia juga salah satu yang paling berpengalaman: dalam pengujian sudah sejak 1994. Dan ketika diketahui bahwa dia akan berbicara di konferensi Heisenbug kami dengan
laporan "Troubles in Selenium WebDriver", kami ingin bertanya kepada pembicara seperti itu. Kami mulai dengan pertanyaan tentang bagaimana pengujian di tahun 90an berbeda dari hari ini, dan kemudian beralih ke realitas modern.
- Di antara pembaca wawancara mungkin ada orang-orang yang bahkan belum dilahirkan ketika Anda sudah mulai menguji. Katakan, bagaimana semuanya berbeda dari zaman kita?- Jika kita berbicara tentang beberapa dasar pengujian (teori, teknik kunci), maka tidak ada perubahan khusus. Tetapi pada saat yang sama, otomatisasi uji, tentu saja, terus berubah. Teknologi pengembangan baru muncul dan menghilang, dan bersama mereka teknologi dan alat yang dirancang untuk menguji perangkat lunak muncul atau menghilang. Bagaimana seseorang dapat membandingkan pengujian apa yang dulu dan yang sekarang? Bagaimanapun, untuk membandingkan, mana yang lebih baik - dulu ada SABUN, sekarang REST. Kemudian kami menguji layanan web yang ditulis menggunakan SOAP, dan sekarang yang ditulis menggunakan REST. Apa bedanya?
- Ya, beberapa teknologi tidak hanya "muncul dan menghilang", tetapi menjadi teknologi tanpanya yang sekarang sulit dibayangkan industri: "Bagaimana kita hidup tanpa Git?"- Mereka hidup normal tanpa Git. Ada CVS, kami hidup baik-baik saja dengan itu, lalu ada Subversi, lalu Git. Ini semua tidak begitu menarik, tetapi yang benar-benar berubah sangat banyak adalah kecepatan. Kecepatan pengembangan, dan dengan itu kecepatan pengujian. Ini bahkan bukan tentang iterasi pendek, Agile, pendekatan untuk mengatur jam kerja. Justru kecepatan pengembangan produk yang telah berubah.
Ketika kami mulai bekerja, pada pertengahan 90-an, kami memiliki proyek yang berlangsung selama enam bulan, setahun, dua tahun. Pengembangan dan pengujian. Kemudian proyek-proyek ini mulai menurun menjadi tiga bulan, dua. Bahkan, dalam dua bulan hal yang sama dikembangkan seperti awal tahun. Dan sekarang apa yang terjadi: orang-orang datang ke hackathon, mengembangkan produk yang berfungsi dalam sehari, menguji dan meluncurkannya. Jelas bahwa ini masih merupakan prototipe, tapi tetap saja, selama sehari. Mustahil untuk membayangkan ini.
Mengapa ini terjadi? Tentu saja, alat berkembang. Tapi itu bahkan bukan masalah alat, beberapa masih menulis kode di vi atau emacs. Lebih penting lagi, banyak kode yang sudah jadi telah ditulis, ada perpustakaan yang baik yang telah diuji secara menyeluruh. Di suatu tempat, Anda masih perlu menulis banyak kode Anda, mengembangkan algoritma unik, dan semuanya masih membutuhkan waktu lama di sana. Tetapi dalam situasi lain, Anda dapat mengambil komponen yang sudah jadi, dari mereka dengan cepat, seperti dari seorang desainer, merakit produk jadi. Dan, karenanya, juga lebih mudah untuk mengujinya, karena kita sudah merakitnya dari komponen yang andal dan teruji. Ini telah banyak berubah.
- Dan apa yang telah berubah dalam pandangan dunia orang - dalam cara kita melihat pengujian / pengembangan dan apa yang kita harapkan dari mereka?- Di tahun 90-an, baik pengembang dan penguji memiliki lebih banyak kepercayaan pada standar. Sebenarnya, Agile tidak muncul dari awal, tetapi hanya karena kekecewaan dalam semua standar ini.
Pertama, ada gagasan bahwa standar akan menyelamatkan kita dari kode berkualitas rendah: kita akan menulis semuanya sesuai dengan standar, dan semuanya akan terintegrasi dengan baik, bekerja. Mungkin ini benar, hanya standar yang dikembangkan sangat lambat, dan semuanya dengan sangat cepat berjalan maju dan menjadi usang sebelum standar diterima.
Kedua, ada keyakinan bahwa akan mungkin untuk menggambar diagram secara formal sesuai dengan diagram UML, mendeskripsikan persyaratan perangkat lunak, dan secara otomatis menghasilkan kode sumber, dan semua ini akan berhasil, dan bahkan tidak perlu diuji. Diasumsikan bahwa segera pengembang akan berhenti menulis kode, sebaliknya mereka akan menggambar diagram UML dan menggambarkan kondisi dalam beberapa bahasa tingkat tinggi. Itu tidak lepas landas, itu tidak berhasil. Meskipun di pesta tempat saya menoleh, taruhan yang sangat besar dibuat untuk ini.
Sekarang, beberapa jenis gelombang baru mungkin telah dimulai: kecambah kecerdasan buatan dari mana-mana dari semua tempat, dan sekali lagi ide ini muncul bahwa pengembang tidak akan menulis kode. Sebaliknya, beberapa sistem kecerdasan buatan akan dilatih, dan semuanya akan bekerja dengan sendirinya. Dengan demikian, penguji tidak perlu melakukan apa pun. Pengembang akan melatih kecerdasan buatan, dan dia akan melakukan segalanya. Mari kita lihat bagaimana jadinya. Mungkin itu akan berhasil seperti terakhir kali.
- Mari kita beralih ke waktu kita. Anda menggunakan perangkat lunak-testing.ru. Bagi yang tidak aktif mengikutinya: apa yang terjadi di sana?- Kami menerbitkan banyak konten, sekarang bagian utama adalah konten yang diterjemahkan. Karena, terus terang, di Rusia sangat sulit untuk menemukan penulis yang menulis tentang pengujian. Saya tidak tahu mengapa itu terjadi: ada saat ketika banyak orang menulis dalam bahasa Rusia, dan kemudian bahan bakar mereka habis, atau karena alasan tertentu tidak ada cukup blog dan artikel di RuNet. Dan di bagian Internet berbahasa Inggris, semua ini masih berkembang, ada banyak artikel yang ditulis di sana.
Komunikasi secara bertahap pindah ke ruang obrolan, yaitu, orang tidak menulis teks, tetapi berkomunikasi. Ini bukan untuk mengatakan bahwa kita mengikuti tren ini dengan sangat hati-hati. Kami berpartisipasi dalam obrolan, tetapi jangan mencoba untuk memimpin tren ini. Kami masih bertindak dengan cara lama, berusaha memberikan konten yang tepat kepada orang, dan mereka akan menemukan tempat untuk berkomunikasi.
- Sekarang orang juga beralih dari teks ke blogging video - tetapi apakah ada hal seperti itu dalam pengujian?- Dalam pengujian, tren ini hampir tidak terlihat. Ada satu atau dua blogger video, kasus yang terisolasi.
- Ada ungkapan "Jika Anda ingin memahami sesuatu yang nyata - cobalah untuk menjelaskannya kepada orang lain." Dan ketika Anda secara sistematis mengedit teks orang lain, apakah Anda mulai lebih memahami topik, termasuk sudut, di mana Anda sendiri tidak akan melihat? Apakah berguna juga bagi seorang tester untuk menjadi editor?- Pekerjaan editorial sangat berbeda dari pembaca. Tugas editor bukan untuk memahami apa yang tertulis dalam teks, melainkan untuk tidak melewatkan kekurangannya. Jujur, ini tidak berkontribusi pada tampilan holistik. Ketika kami memilih bahan, saya lebih melihatnya sebagai pembaca: apakah menarik untuk dibaca atau tidak. Saat ini saya belum menjadi editor. Tetapi ketika kita melihat teks yang diterjemahkan dan bersiap untuk publikasi, maka dalam hal ini sebagai editor. Sehingga selama mengedit, selama persiapan untuk publikasi, sesuatu dipahami - ini tidak terjadi. Jadi ada mode yang berbeda: satu mode adalah editor, yang lain adalah pembaca.
- Pertanyaan tidak bijaksana. Ada iklan banner di software-testing.ru, tetapi dalam jurnalisme sulit untuk menghasilkan uang dengan itu - apakah lebih baik dalam hal pengujian, atau tidak mengompensasi pekerjaan Anda dan situs ada karena cinta seni?- Tidak ada pendapatan iklan yang tidak mengompensasi pekerjaan di situs. Itu ada untuk membuat gambar, gambar, untuk mempertahankan keberadaan kita di jaringan. Dan pusat pelatihan menghasilkan dari kita.
- Pertanyaan selanjutnya adalah tentang pelatihan. Anda telah mengajar orang lain untuk menguji selama bertahun-tahun, tetapi bagaimana hal ini memengaruhi bagaimana Anda memandang diri sendiri?- Di sini prinsip yang Anda sebutkan sedikit berhasil sebelumnya: saat Anda menjelaskan sesuatu kepada seseorang, Anda sendiri akan memahami sesuatu. Sangat membantu untuk lebih memahami, memahami. Ketika Anda pertama kali mengatakan suatu topik, tampaknya semuanya jelas. Dan kemudian Anda menonton kuliah Anda, Anda memahami apa yang bisa Anda katakan dengan lebih baik, ulangi, beberapa hal baru muncul. Setelah itu, kadang-kadang saya menulis beberapa artikel tambahan: pertama Anda menyiapkan materi untuk kursus, dan kemudian Anda mengerti bahwa Anda perlu menambahkan sesuatu yang lain untuk membuatnya lebih jelas. Dan, tentu saja, bahkan lebih menarik untuk mendapatkan semacam umpan balik. Orang-orang juga mengatakan sesuatu yang menarik. Anda ditanyai semacam pertanyaan tiba-tiba, dan hanya di sini Anda mengerti bahwa Anda tidak mengerti. Dan saya sama sekali tidak berpikir bahwa saya harus memikirkannya. Ini sangat berharga.
- Ketika Anda mengajar banyak orang, Anda mulai memperhatikan beberapa kesalahan khas banyak orang. Bisakah Anda merumuskan beberapa "kesalahan penguji tipikal" umum?- Kesalahan umum pada setiap orang adalah bahwa kebanyakan orang di IT mencoba mempelajari segala sesuatu dari pengalaman mereka sendiri, melewati semua penggaruk. Dari sudut pandang saya, lebih logis untuk bergerak dengan cara yang berbeda: mempelajari sesuatu, dan hanya setelah itu melanjutkan pekerjaan.
Dalam hal ini, saya adalah orang yang atipikal. Ketika saya membeli beberapa peralatan rumah tangga, saya pertama duduk dan membaca instruksinya. Karena itu, mentransfer pengalaman psikologis saya sendiri kepada orang lain cukup sulit bagi saya. Saya mengerti bahwa ya, kebanyakan orang tidak bertindak seperti ini, mereka pergi menyapu terlebih dahulu, dan kemudian mereka mulai mencari cara untuk menghindari ini. Saya percaya ini salah, dan mereka percaya itu benar.
- Sekarang saya ingin bertanya tentang Selenium. Bagaimana komunitas Pengemudi Selenium dan seluruh ekosistem di sekitarnya masuk ke komunitas? Apakah ada langkah dan prestasi? Misalnya, "lakukan sepuluh permintaan tarik dan lanjutkan ke langkah berikutnya."- Tidak ada prosedur standar, tidak ada peraturan, tidak ada kriteria seleksi khusus. Semuanya benar-benar individual. Ketika Anda melihat bahwa seseorang sudah terlibat, maka ia secara bertahap diberikan lebih banyak hak. Proses masuk ini terjadi secara berbeda untuk semua orang. Seseorang mulai memperbaiki bug dan mengirimkan permintaan penarikan. Dan seseorang mulai merespons pengguna di milis: kami memiliki orang yang bertanggung jawab untuk bekerja dengan pengguna yang sama sekali tidak memiliki komitmen terhadap kode, tetapi ia benar-benar memegang milis. Seseorang sedang menulis dokumentasi -
ini adalah tugas yang juga melibatkan bekerja dengan kode sumber, tetapi, tentu saja, kebanyakan orang merasakan partisipasi dalam proyek secara khusus dengan permintaan tarik.
Ada masalah organisasi dengan permintaan tarik terkait dengan fakta bahwa kami tidak memiliki cukup pekerja, sehingga permintaan tarik dapat berbohong untuk waktu yang sangat lama, dan tidak ada yang menganggapnya. Karena itu, Anda harus gigih agar diperhatikan. Anda tidak hanya perlu mengirim permintaan tarik, Anda harus menerobosnya. Mereka yang menerobos filter ini kemudian berhasil memasuki proyek secara bertahap.
- Dan kepada siapa harus menulis untuk menerobos?- Ya, tulis untuk semua orang. Dalam obrolan IRC, minta untuk mengevaluasi permintaan penarikan. Secara umum, ada filter non-teknis di mana seseorang secara bertahap menembus. Dan jika Anda melakukan permintaan tarik dan menunggu sampai Anda diundang ke proyek, maka tidak, mereka tidak akan melakukannya.
- Secara intuitif saya ingin mengasumsikan bahwa jika alat yang sangat populer di kalangan penguji sedang dikembangkan, maka alat itu sendiri telah diuji jauh lebih teliti daripada rata-rata proyek TI. Apakah contoh Selenium mengkonfirmasi ini atau tidak?- Saya tidak tahu tentang "proyek rata-rata", tetapi Selenium benar-benar diuji dengan cukup teliti. Ada banyak tes, tes terus bekerja, mereka terus-menerus menemukan bug, termasuk bug regresi, termasuk bug regresi di browser. Saya secara teratur menulis laporan bug ke pengembang browser.
Menurut saya, situasi dengan tes-tes ini cukup makmur, walaupun saya tidak bisa mengatakan bahwa tes-tes itu ada di mana-mana ditulis sepenuhnya secara sistematis: lagipula, semuanya juga telah tumbuh secara organik selama dua puluh tahun terakhir. Jika Anda mulai menulisnya dari awal, mengambil spesifikasi dan dengan hati-hati mendesainnya, maka, mungkin, akan lebih baik untuk menulis banyak tes dengan cara yang berbeda. Namun sejauh ini tidak ada pemikiran untuk duduk dan menulis ulang sepenuhnya beberapa bagian dari tes, tes yang dikembangkan secara organik menghadapi tugas mereka.
- Seringkali ada perselisihan "browser mana yang lebih baik", dan karena Anda mengiriminya laporan bug, menarik untuk dibandingkan dari sisi non-standar: browser mana yang memiliki respons terbaik terhadap laporan bug dan mana yang lebih buruk?- Saya tidak ingin menyinggung siapa pun, jadi saya tidak akan mengkritik siapa pun, tetapi saya bisa memuji. Pengembang Firefox bereaksi paling baik. Mereka adalah yang paling terlibat, paling aktif dalam hal bekerja dengan laporan bug. Yang, mungkin, hanya cocok dengan semangat open source mereka.
Dan yang paling menjengkelkan bukanlah reaksi tim terhadap laporan bug. Inilah yang perusahaan-perusahaan yang mengembangkan browser kode-tertutup (Microsoft, Apple) memiliki pelacak bug tertutup. Artinya, ketika bertemu dengan bug, Anda tidak dapat melihat apakah seseorang telah mengirim laporan bug seperti itu, apakah ini bug yang dikenal.
- Beberapa tahun yang lalu Anda mengatakan bahwa tugas Selenium adalah menjadi standar web. Dia menjadi, dan kemudian apa? Apa tonggak besar berikutnya?- Tangkap dunia dalam menghadapi alat otomatisasi. Artinya, kita perlu memastikan bahwa semua standar baru ini didukung.
- Artinya, menjadi modul bawaan untuk semua alat otomatisasi UI baru lainnya?- Ya. Artinya, mereka dapat menggunakan sepuluh modul lainnya, tetapi mereka semua harus dapat bekerja melalui protokol standar.
Di dalam Selenium ada tugas penting berikut, yang akan diselesaikan terlebih dahulu oleh beberapa implementasi prototipe, dan kemudian dalam kerangka standar. Protokol HTTP pada dasarnya satu arah, yaitu, satu sisi mengirimkan permintaan, yang lain memprosesnya, dan praktis tidak ada umpan balik. Dan ini tidak terlalu baik, dan justru di sini para pesaing sangat aktif menunjukkan ini, memberikan tekanan pada titik yang menyakitkan ini, karena saya ingin, secara kasar, memiliki panggilan balik. Ketika beberapa peristiwa terjadi di browser, saya ingin beberapa pemberitahuan tentang ini akan datang. Ini belum dalam alat Selenium. Tetapi kami benar-benar ingin menambahkan ini. Jadi, mungkin, perubahan kardinal akan terjadi, perubahan protokol dimungkinkan. Tanpa ini, akan sulit. Kami membutuhkan protokol dua arah.
"Kamu dan Simon Stewart adalah kontributor utama Selenium, kan?"- Ini benar ketika datang ke bagian Jawa.
"Sejauh yang saya tahu, Anda belum pernah bertemu." Bagaimana itu bisa terjadi? Pengembang selenium tidak memiliki "perusahaan"?- "Pihak perusahaan" yang kami miliki dalam bentuk pertemuan di konferensi, tetapi secara terpisah - tidak. Dan dalam hal konferensi, Simon bahkan datang ke Moskow Heisenbug tahun lalu, tetapi saya tidak berada di Moskow pada saat itu, jadi kami tidak berpotongan.
Tapi, terus terang, kita sekarang hidup di dunia yang tidak apa-apa, kita masih terus berkomunikasi.
- Pertanyaan terakhir, akhirnya. Menurut Anda apa yang akan menjadi masa depan pengujian otomatisasi secara umum dan UI pada khususnya?- Saya tidak suka membuat ramalan, karena mereka hampir tidak pernah menjadi kenyataan. Pengujian berada di belakang pengembangan dengan sedikit keterlambatan; Oleh karena itu, para pengembang mendikte mode: mereka secara damai dipecah menjadi JS - dalam pengujian juga, semua secara damai dibobol menjadi JS. Dan kita harus mengikuti perubahan. Dan apa yang akan dimiliki pengembang - siapa yang tahu.
Alexey akan tampil di Heisenbug Moskwa pada 6-7 Desember - dan selain dia, akan ada puluhan pembicara lain. Di situs web Heisenbug Anda dapat melihat program lengkap dan membeli tiket.