Kata Pembuka
Tony Voellm (Google)
Link: Video
Keynote Pembuka - Evolusi dari Uji Mutu ke Teknik Pengujian
Ari Shamash (Google)
Anda telah membuat aplikasi. Anda telah meluncurkannya. Anda tahu bahwa Anda akan pasti berhasil, membangun volume, mendapatkan dana, membuang semuanya, lalu memulai dari awal agar dapat "melakukannya dengan benar". Namun, permintaan akan fitur baru sangat tinggi. Sekarang Anda diminta untuk mendorong skala yang belum pernah ada sebelumnya dengan kecepatan yang belum pernah disebutkan sebelumnya. Aduh! Selanjutnya bagaimana?
Anda tidak dapat membuangnya dan memulai dari awal, Anda hanya perlu mengembangkan apa yang Anda miliki, sambil terus menambahkan fitur berkualitas tinggi dengan kecepatan yang luar biasa. Selain itu, Anda perlu memastikan bahwa apa yang sudah ada tidak rusak. Bagaimana cara melakukannya? Untungnya, bidang baru sedang dibentuk dalam industri rekayasa software yang menangani skenario umum ini: di Google, kami menyebutnya "rekayasa pengujian".
Pembahasan ini akan berfokus pada pengertian engineering pengujian, perkembangannya dari uji mutu, dan cara industri ini secara keseluruhan menerapkan penerapan uji coba (dengan contoh penerapannya di Google).
Sistem Pengujian dalam Skala @Twitter
James Waldrop (Twitter)
James akan membahas alat, proses, dan filosofi yang digunakan untuk menguji performa di Twitter. Penekanan khusus akan ditempatkan pada library pengujian beban open source Iago, yang ditulisnya agar tim engineering Twitter dapat melakukan pengujian beban sebelum men-deploy kode ke produksi. Pembahasan akan membahas detail implementasi beberapa pengujian ini (termasuk kode sumber) dan cara mengelola faktor-faktor seperti OAuth dan protokol Thrift arbitrer yang dikelola.
Bagaimana Cara Menguji OS Seluler?
David Burns (Mozilla) dan Malini Das (Mozilla)
Ini adalah masalah yang dihadapi Mozilla saat kami memutuskan untuk terjun ke dunia FirefoxOS. Tempat untuk memulai dan cara melakukannya adalah membuktikan tugas yang menarik. Mari kita lihat cara kami menyelesaikan masalah ini dan cara kami membuat framework baru.
Otomatisasi Seluler dalam Pipeline Continuous Delivery
Igor Dorovskikh (Expedia) dan Kaustubh Gawande (Expedia)
Expedia mulai berinvestasi dalam aplikasi Web Seluler dan iOS/Android pada awal 2012. Pada saat yang sama, Test Engineer mulai mengembangkan solusi otomatisasi pengujian untuk membuat kualitas dan kemampuan pengujian produk sejak awal. Dalam pembahasan ini, kami akan membagikan pengalaman dan pembelajaran tentang cara memanfaatkan alat open source untuk membangun pengujian otomatis di lingkungan Agile dan pengembangan berkelanjutan Expedia. Kita akan membahas Test Pyramid dan membahas lebih mendetail tentang alat open source tertentu yang berfungsi dengan baik untuk kita. Beberapa alat open source yang kami gunakan adalah alat BDD seperti Cucumber, alat otomatisasi web Selenium-WebDriver, alat otomatisasi iOS Frank, alat otomatisasi Android Robotium dan Calabash, serta sistem Continuous Integration Jenkins. Selain itu, kami akan membagikan beberapa prinsip penayangan Agile yang kami coba terapkan seperti TDD, Pemrograman Penyambungan, Build, dan Radiator Pengujian. Terakhir, kami akan membagikan beberapa manfaat yang telah kami ketahui dari investasi kami dalam Agile dan otomatisasi pengujian, dan bagaimana hal tersebut membantu kami mencapai sasaran Continuous Delivery.
Pengujian Dekoder Otomatis dengan GStreamer dan OpenCV
David Röthlisberger (YouTube)
Kami akan membangun sistem pengenalan citra yang merekam video dalam 3 menit, menggunakan alat command line dan OpenCV GStreamer. (GStreamer adalah framework penanganan media open source; OpenCV —"Open Computer Vision"—adalah library pemrosesan gambar open source.)
Contoh utama sistem semacam ini adalah http://stb-tester.com, alat sumber terbuka yang dikembangkan di YouView untuk mengotomatiskan pengujian UI dekoder kami. Kami akan menjelaskan penguji stb, fleksibilitas yang ditawarkan oleh dasar-dasar GStreamer, beberapa kemungkinan yang dapat dilakukannya, dan tantangan yang akan dihadapi.
Link: Video
Webdriver untuk Chrome
Ken Kania (Google)
Sejak awal sebagai browser khusus Windows, Chrome telah diperluas ke Mac, Linux, ChromeOS, dan yang terbaru, Android dan iOS. Pengujian aplikasi web tingkat pengguna di seluruh platform ini sulit dan memerlukan berbagai pendekatan otomatisasi. Diskusi ini akan menjelaskan upaya yang dilakukan tim Chrome untuk menyediakan WebDriver untuk Chrome di semua platform. Tindakan ini akan mencakup tampilan teknis mengenai pendekatan yang mendasarinya tetapi akan berfokus pada cara developer dapat menggunakan ChromeDriver baru untuk menulis pengujian bagi berbagai platform Chrome. Selain itu, status project saat ini dan rencana untuk masa depannya akan dibahas.
Karma - Test Runner untuk JavaScript
Vojta Jina (Google)
Pengantar Karma - test runner yang membuat pengujian aplikasi JavaScript pada browser sungguhan berjalan dengan lancar dan menyenangkan.
Pengujian tidak bersifat opsional saat seseorang mem-build aplikasi JavaScript yang harus berfungsi di banyak browser dan perangkat. Namun, menjalankan pengujian di semua lingkungan ini sulit. Karma mengubah tugas yang biasanya rumit ini menjadi sepotong kue. Produk ini memungkinkan Anda menjalankan pengujian JavaScript di browser atau perangkat sungguhan seperti ponsel atau tablet langsung dari terminal terminal atau IDE favorit.
Link: Video
Pengukuran Kualitas Video Otomatis
Patrik Höglund (Google)
Ya, Anda dapat otomatis menguji pengukuran subjektif yang rumit seperti kualitas video. Diskusi ini akan menunjukkan cara kami membuat pengujian video call WebRTC secara menyeluruh dan otomatis. Kita akan melihat toolchain pada tingkat tinggi dan tantangan apa yang kami hadapi saat membuatnya. Ini sangat cocok jika Anda menginginkan inspirasi tentang cara meningkatkan pengujian media.
Ketika Hal Buruk Terjadi Pada Aplikasi Bagus...
Minal Mishra (Netflix)
Ledakan komputasi seluler dan tablet telah memadati industri software dengan platform pengembangan aplikasi. Mengembangkan aplikasi konsumen di platform komputasi memiliki pengalaman yang luar biasa bagi pengguna akhir. Perusahaan software yang ditujukan untuk konsumen selalu berusaha semaksimal mungkin saat mengembangkan aplikasi untuk platform ini. Namun, tantangan terbesar dalam pengembangan aplikasi hanya dimulai setelah perusahaan meluncurkan versi pertama aplikasi. Konsumen dan perusahaan software menginginkan fitur dan fungsi terbaru yang tidak dikembangkan sesegera mungkin dengan kualitas tertinggi. Hal ini menyebabkan churn kode konstan di setiap lapisan stack. Kami, engineer otomatisasi UI, membuat berbagai sistem deteksi untuk mendeteksi masalah aplikasi lebih cepat daripada setelahnya. Dalam pembahasan ini, saya akan menyampaikan beberapa tantangan dan keberhasilan di balik sistem deteksi tersebut, yang membantu menemukan masalah di luar lapisan aplikasi, tetapi masih berdampak buruk pada pengalaman pengguna.
Pengujian untuk Game Pendidikan dan Game Pendidikan untuk Pengujian
Tao Xie (Universitas Negara Bagian Carolina Utara)
Diskusi ini menghadirkan Pex4Fun (http://www.pexforfun.com/), yang memanfaatkan pembuatan pengujian otomatis untuk mendukung penilaian otomatis dalam sistem pemrograman online yang dapat menskalakan hingga ratusan ribu pengguna. Produk ini memberikan pengalaman bermain game yang berorientasi pemrograman di luar kelas, melatih pengguna untuk mempelajari berbagai keterampilan pemrograman dan rekayasa software, termasuk keterampilan pengujian seperti menulis pengujian unit berparameter. Pex4Fun memberikan kontribusi yang signifikan terhadap masalah umum penilaian tugas, serta memberikan pengalaman belajar yang menyenangkan berdasarkan game interaktif. Pex4Fun telah mendapatkan popularitas tinggi di komunitas: sejak dirilis ke publik pada Juni 2010, jumlah klik tombol "Ask Pex!" (menunjukkan upaya yang dilakukan oleh pengguna untuk menyelesaikan game di Pex4Fun) telah mencapai lebih dari satu juta pada awal 2013.
Menutup Keynote - Cara Facebook Menguji Facebook di Android
Simon Stewart (Facebook)
Facebook adalah salah satu aplikasi Android paling populer yang ada. Dalam pembahasan ini, Anda akan menemukan hal yang dilakukan Facebook untuk memastikan bahwa setiap rilis sebaik yang diperlukan. Kita akan membahas semuanya mulai dari cara mengelola kode, melalui pendekatan hingga pengujian dan dogfood hingga dogfooding.
Membuka Keynote - JavaScript yang Dapat Diuji - Merancang Aplikasi Anda untuk Kemampuan Pengujian
Mark Trostler (Google)
JavaScript yang dapat diuji adalah suatu proses. Mulai dari layar kosong atau aplikasi yang sudah diimplementasikan (atau di antara keduanya) dapat menguji kode JavaScript Anda dengan sederhana, bersih, dan efektif adalah fitur yang diperlukan. Kode yang tidak dapat diuji akan ditulis ulang.
Meskipun JavaScript bersifat unik karena berbagai lingkungan tempatnya berjalan, ada beberapa metodologi 'yang dapat diuji' yang telah teruji dari bahasa lain yang juga berlaku untuk JavaScript. Dan tentu saja, ada tantangan unik yang harus dihadapi developer JavaScript saat menulis dan menguji kode mereka.
Pola apa yang membuat kode dapat diuji? Anti-pola mana yang menghambat pengujian? Metrik dan postingan panduan umum apa yang dapat digunakan untuk mengukur kemampuan pengujian kode kami? Setelah proses pembuatan kode yang dapat diuji dimulai sekarang, apa langkah selanjutnya?
Bergabunglah dengan kami untuk membahas proses penulisan JavaScript yang dapat diuji. Kami akan menyelidiki ide, pola, dan metodologi yang sangat meningkatkan kemampuan pengujian, dan karenanya mempertahankan pemeliharaan, ketepatan, dan lama kode Anda. Apakah Anda menulis master JavaScript sisi klien atau server, proses ini akan sangat meningkatkan kualitas kode.
Breaking the Matrix - Pengujian Android dalam Skala
Thomas Knych (Google), Stefan Ramsauer (Google), dan Valera Zakharov (Google)
Anda siap minum pil merah?
Perangkat seluler telah mengubah cara manusia berinteraksi dengan komputer. Ini bagus, tetapi sebagai engineer, kami dihadapkan dengan matriks lingkungan yang terus berkembang tempat kode kami berjalan. Hari-hari dengan mempertimbangkan hanya sedikit browser dan resolusi layar yang tidak akan kembali. Bagaimana cara engineer mengatasi Matriks? Kita akan membahas cara Google menghadapi masalah pengujian ini di workstation, cloud, dan head...
"Saya mencoba membebaskan pikiran Anda, Neo. Tapi saya hanya bisa tunjukkan pintunya. Hanya Anda yang harus melewatinya".
Otomatisasi UI Android
Guang Zhu (朱光) (Google) dan Adam Momtaz (Google)
Karena Android semakin populer di dunia seluler, developer aplikasi dan vendor OEM menjelajahi berbagai cara untuk melakukan pengujian aplikasi UI secara menyeluruh atau di seluruh platform. Dengan tinjauan singkat tentang solusi Otomatisasi UI yang ada di Android, pembahasan ini memperkenalkan framework UI Automator Android yang baru dirilis, dan terus memberikan penjelasan tentang framework, kasus penggunaan, dan alur kerja umum.
Appium: Otomatisasi untuk Aplikasi Seluler
Jonathan Lipps (Saus Lab)
Appium adalah server Node.js yang mengotomatiskan aplikasi seluler native dan hybrid (baik iOS maupun Android). Filosofi Appium menyatakan bahwa aplikasi tidak boleh diubah agar menjadi otomatis, dan Anda harus dapat menulis kode pengujian dalam bahasa atau framework apa pun. Hasilnya adalah server Selenium WebDriver yang berbicara seluler seperti native. Appium berjalan di perangkat dan emulator sungguhan dan merupakan open source sepenuhnya, menjadikannya cara yang sangat cocok untuk memulai otomatisasi pengujian seluler. Dalam pembahasan ini, saya akan menguraikan prinsip-prinsip yang mendasari desain Appium, membahas Appium dalam bidang framework otomatisasi seluler lainnya, dan memperkenalkan arsitektur yang menciptakan keajaiban. Terakhir, saya akan menggali kode untuk pengujian sederhana aplikasi seluler baru, dan menunjukkan Appium yang menjalankan pengujian ini di iPhone dan Android.
Membangun Infrastruktur Uji Seluler yang Skalabel untuk Google+ Seluler
Eduardo Bravo (Google)
Menguji aplikasi native dengan cara yang bermakna, stabil, dan skalabel merupakan tantangan. G+ telah mengembangkan solusi yang efisien untuk mengatasi masalah ini dengan menyediakan infrastruktur yang tepat untuk setiap skenario pengujian kompleks yang disajikan oleh seluler. Infrastruktur pengujian kami saat ini menyediakan alat yang tepat untuk aplikasi iOS dan Android guna memberi keyakinan kepada tim pengembangan kami bahwa perubahan baru tidak akan mengganggu klien yang ada.
Espresso: Pengujian UI baru untuk Android
Valera Zakharov (Google)
Update [Oktober 2013]: Espresso sekarang menjadi open source. Lihat https://code.google.com/p/android-test-kit/.
Mengembangkan pengujian Android yang andal harus semudah dan semudah mengambil gambar espresso. Sayangnya, dengan alat yang ada, alat ini mungkin terasa lebih seperti double-shot-caramel-flavor-upside-down-single-whip-half-decaf-latte karena membingungkan dan jarang konsisten. Espresso adalah framework pengujian Android baru yang memungkinkan Anda menulis pengujian UI yang ringkas, menarik, dan andal dengan cepat. API inti berukuran kecil, dapat diprediksi, dan mudah dipelajari. Namun, API ini juga dapat disesuaikan. Pengujian Espresso menyatakan ekspektasi, interaksi, dan pernyataan mereka dengan jelas tanpa mengganggu boilerplate, infrastruktur kustom, atau detail implementasi yang berantakan. Pengujian berjalan optimal dengan cepat - tunggu, sinkronkan, tidur, dan lakukan polling, lalu biarkan framework memanipulasi dan menyatakan dengan lancar ketika UI sedang dalam keadaan nonaktif. Mulailah menikmati menulis dan mengeksekusi pengujian UI - cobalah suntikan Espresso.
Pengujian Performa Web dengan WebDriver
Michael Klepikov (Google)
Dalam pengujian performa web, kita tahu betul cara menganalisis pemuatan halaman. Namun, kami perlu beralih di luar pemuatan halaman: aplikasi modern sangat interaktif, dan operasinya cenderung tidak memuat ulang seluruh halaman, melainkan memperbaruinya. Orang yang berbeda, termasuk saya, telah mengintegrasikan WebDriver ke dalam rangkaian pengujian performa web, yang membantu, tetapi tetap memisahkan pengujian performa dari rangkaian pengujian UI lainnya. Saya mengusulkan untuk mem-build fitur pengujian performa langsung ke WebDriver sendiri, memanfaatkan Logging API yang baru-baru ini ditambahkan. Hal ini memungkinkan pengumpulan metrik performa saat menjalankan pengujian fungsional reguler, sehingga integrasi pengujian performa menjadi jauh lebih lancar ke dalam alur pengembangan dan pengujian secara keseluruhan. Ini juga jauh lebih tidak mengganggu toolchain/build pengujian kustom yang dibuat oleh hampir setiap organisasi besar.
Kami akan mendemonstrasikan hal ini dengan ChromeDriver generasi baru (WebDriver untuk browser Chromium).
Pengujian Data Maps Berkelanjutan
Yvette Nameth (Google) dan Brendan Dhein (Google)
Pengujian berkelanjutan umumnya adalah menjalankan pengujian unit dan pengujian integrasi. Namun, saat data yang diproses server Anda sebenarnya adalah penyebab perubahan terbesar, bagaimana Anda memastikan bahwa konsumen data masih dapat digunakan dan tidak ada yang error di bawah laju perubahan atau perubahan yang buruk? Kita akan membahas teknik untuk pengujian data berkelanjutan dengan contoh dari Google Maps.
Menemukan Culprit Secara Otomatis di Build yang Gagal - yaitu Siapa yang Rusak Build-nya?
Celal Ziftci (UCSD) dan Vivek Ramavajjala (Google)
Build berkelanjutan adalah salah satu infrastruktur utama di Google. Jika build gagal, penting untuk menentukan daftar perubahan penyebab (CL)/daftar perubahan dengan cepat, sehingga dapat diperbaiki agar build kembali berwarna hijau.
Solusi deteksi kulprit ada untuk build kecil dan menengah, tetapi tidak untuk build integrasi besar.
Pencari penyebab kami menargetkan menemukan CL penyebab masalah untuk build besar secara otomatis, dalam jangka waktu yang sangat singkat dengan kesuksesan tinggi. Berdasarkan penggunaan produksi pada beberapa project dalam 9 bulan terakhir, pencari pencari memberikan hasil yang sangat menjanjikan. Lihat diskusi kami untuk melihat cara kami menerapkan pencari penyebab, seberapa suksesnya dalam produksi, serta seperti apa rasanya dan seperti apa tampilannya.
Investigasi Empiris terhadap Kualitas Lini Produk Software
Katerina Goseva-Popstojanova (West Virginia University)
Lini produk software menunjukkan kesamaan yang tinggi di antara sistem dalam lini produk dan jumlah kemungkinan variasi yang ditentukan. Berdasarkan data yang diekstrak dari dua studi kasus - lini produk industri ukuran sedang dan lini produk open source yang besar dan terus berkembang - kami mengeksplorasi secara empiris jika penggunaan kembali yang sistematis meningkatkan kualitas dan mendukung prediksi potensi kesalahan di masa mendatang dari kesalahan yang dialami sebelumnya, metrik kode sumber, dan perubahan metrik. Hasil riset kami mengonfirmasi, dalam setelan lini produk software, temuan pihak lain bahwa kesalahan lebih berkorelasi dengan perubahan metrik dibandingkan dengan metrik kode statis. Hasil penilaian kualitas menunjukkan bahwa meskipun paket yang lebih lama (termasuk kesamaan), terus berubah, sehingga kepadatan tetap rendah. Selain itu, kualitas lini produk open source meningkat seiring berkembangnya rilis. Prediksi berdasarkan model regresi linier umum secara akurat memberikan peringkat pada paket sesuai dengan kesalahan pasca-rilis menggunakan model yang dibuat pada rilis sebelumnya. Hasilnya juga mengungkapkan bahwa prediksi kesalahan pasca-rilis memanfaatkan informasi lini produk tambahan.
AddressSanitizer, ThreadSanitizer, dan MemorySanitizer -- Alat Pengujian Dinamis untuk C++
Kostya Serebryany (Google)
AddressSanitizer (ASan) adalah alat yang menemukan overflow buffering (dalam stack, heap, dan global) serta bug penggunaan setelah memori dalam program C/C++. ThreadSanitizer (TSan) menemukan data race dalam program C/C++ dan Go. MemorySanitizer (MSan) adalah alat yang sedang berlangsung yang menemukan penggunaan memori yang tidak diinisialisasi (C++). Alat ini didasarkan pada instrumentasi compiler (LLVM dan GCC), yang membuatnya sangat cepat (misalnya ASan hanya menimbulkan 2x pelambatan). Kami akan membagikan pengalaman dalam pengujian berskala besar menggunakan alat-alat ini.
Keynote Penutup - Minum Lautan - Menemukan XSS dalam Skala Google
Claudio Criscione (Google)
Pembuatan skrip lintas situs, atau XSS, setara dengan wabah hitam abad pertengahan yang modern di dunia aplikasi web: penyebarannya luas, buruk, dan hanya ada sedikit atau tidak ada cara teknis untuk mendeteksinya hingga terlambat. DOM XSS adalah varian yang sangat menjijikkan dari keduanya, karena memerlukan browser sungguhan atau yang setara untuk dideteksi: masalah sulit dengan sedikit solusi otomatis yang tersedia.
Kami membutuhkan alat mandiri yang canggih untuk mengidentifikasi DOM XSS di awal siklus proses pengembangan, yang dapat digunakan oleh para engineer di luar tim keamanan: kami hanya ingin produk yang dapat memindai kumpulan aplikasi kami yang besar, bergerak cepat, sangat kompleks, dan sulit ditemukan. Tentu saja, kami tidak menemukan apa pun. Jadi, kami membuat sendiri: pemindai aplikasi web yang menargetkan DOM XSS yang dirancang dengan teknologi Google standar. Cloud Run berjalan di App Engine dan memanfaatkan browser Chrome yang kuat dan beberapa CPU sebagai platform pemindaian keamanan.
Mereka juga merupakan warga yang baik dari persenjataan pengujian di Google: lembaga ini berada di dalam infrastruktur pengujian kami, bukan menjadi instrumen tim keamanan.
Dalam pembahasan ini, kami menguraikan pendekatan baru kami, tantangan yang kami hadapi saat menskalakan sistem kami ke ukuran Google, serta ide di balik model deteksi dan crawling kami pada aplikasi yang intensif JavaScript.