Pengujian regresi adalah bagian yang sangat penting dalam mengerjakan kualitas produk. Dan semakin banyak produk dan semakin cepat mereka berkembang, semakin banyak upaya yang dibutuhkan.

Yandex belajar bagaimana mengukur tugas-tugas pengujian manual untuk sebagian besar produk menggunakan penilai - karyawan jarak jauh yang bekerja paruh-waktu, dan sekarang ratusan penilai mengambil bagian dalam pengujian produk Yandex, di samping penguji reguler.

Posting ini mengatakan:

• Bagaimana Anda mengatur agar tugas pengujian manual diformalkan mungkin dan melatih ratusan karyawan jarak jauh dengan mereka;
• Bagaimana Anda mengatur untuk menempatkan proses pada rel industri, memberikan pengujian di berbagai lingkungan, menahan SLA dalam kecepatan dan kualitas;
• Kesulitan apa yang mereka hadapi dan bagaimana mereka diselesaikan (dan beberapa belum memutuskan);
• Kontribusi apa yang dilakukan pengujian oleh penilai dalam pengembangan produk Yandex, bagaimana pengaruhnya terhadap frekuensi rilis dan jumlah bug yang terlewatkan.

Teks ini didasarkan pada transkrip laporan Olga Megorskaya dari konferensi Piter 2018 Mei Heisenbug kami:



Dari hari laporan, beberapa angka berhasil berubah, dalam kasus seperti itu kami menunjukkan data aktual dalam tanda kurung. Berikut ini adalah perspektif orang pertama:

Hari ini kita akan berbicara tentang menggunakan teknik crowdsourcing untuk meningkatkan tugas pengujian manual.

Saya memiliki jabatan yang agak aneh: kepala departemen evaluasi ahli. Saya akan mencoba memberi tahu dengan contoh apa yang saya lakukan. Di Yandex, saya memiliki dua vektor tanggung jawab utama:



Di satu sisi, ini semua terkait dengan crowdsourcing. Saya bertanggung jawab atas platform crowdsourcing kami, Yandex.Tolok.

Dan di sisi lain, tim yang, jika Anda mencoba memberikan definisi universal, dapat dikaitkan dengan "kekosongan besar yang tidak produktif." Ini mencakup banyak hal yang berbeda, termasuk salah satu proyek terbaru kami: pengujian manual dengan bantuan orang banyak, yang kami sebut "pengujian oleh penilai".

Aktivitas utama saya di Yandex adalah saya menyatukan kolom kiri dan kanan dari gambar dan mencoba untuk mengoptimalkan tugas dan proses dalam produksi massal menggunakan crowdsourcing. Dan hari ini kita hanya akan membicarakannya menggunakan contoh tugas pengujian.

Apa itu crowdsourcing?

Mari kita mulai dengan apa itu crowdsourcing. Kita dapat mengatakan bahwa ini adalah penggantian keahlian dari satu spesialis khusus dengan apa yang disebut "kebijaksanaan orang banyak" dalam kasus-kasus di mana keahlian spesialis sangat mahal atau sulit untuk diukur.

Crowdsourcing telah digunakan secara aktif di berbagai bidang selama bertahun-tahun. Misalnya, NASA sangat menyukai proyek crowdsourcing. Di sana, dengan bantuan "kerumunan", mereka menjelajahi dan menemukan benda-benda baru di galaksi. Ini sepertinya tugas yang sangat sulit, tetapi dengan bantuan crowdsourcing, tugasnya cukup sederhana. Ada situs khusus di mana ratusan ribu foto yang diambil oleh teleskop ruang angkasa diposting, dan mereka bertanya kepada siapa saja yang ingin mencari objek tertentu di sana. Dan ketika banyak orang yang mencurigakan mirip dengan objek yang mereka butuhkan, maka spesialis tingkat tinggi sudah terhubung dan mulai menjelajahinya.

Secara umum, crowdsourcing adalah metode seperti itu, ketika kita mengambil beberapa tugas tingkat tinggi yang besar dan membaginya menjadi banyak subtugas sederhana dan homogen, di mana banyak pemain independen berkumpul. Masing-masing pemain dapat menyelesaikan satu atau beberapa dari tugas-tugas kecil ini, dan bersama-sama mereka pada akhirnya bekerja untuk satu tujuan bersama yang besar dan mengumpulkan hasil yang bagus untuk tugas tingkat tinggi.

Crowdsourcing Yandex

Kami telah memulai beberapa tahun untuk mengembangkan sistem crowdsourcing kami. Awalnya, ini digunakan untuk tugas-tugas yang terkait dengan pembelajaran mesin: untuk mengumpulkan data pelatihan, untuk mengkonfigurasi jaringan saraf, algoritma pencarian, dan sebagainya.



Bagaimana cara kerja ekosistem crowdsourcing kami? Pertama, kami memiliki Yandex.Toloka . Ini adalah platform crowdsourcing terbuka di mana siapa saja dapat mendaftar baik sebagai pelanggan (memposting tugas mereka, menetapkan harga untuk mereka dan mengumpulkan data), atau sebagai pelaksana (menemukan tugas yang menarik, menyelesaikannya dan menerima hadiah kecil). Kami meluncurkan langit-langit beberapa tahun yang lalu. Sekarang kami memiliki lebih dari satu juta seniman terdaftar (kami menyebutnya toker), dan setiap hari dalam sistem sekitar 17.000 orang menyelesaikan tugas.

Karena kami awalnya membuat Toloka dengan memperhatikan tugas-tugas yang terkait dengan pembelajaran mesin, sudah menjadi kebiasaan bahwa sebagian besar tugas yang dilakukan oleh tolokers adalah tugas yang sangat sederhana dan sepele bagi seseorang untuk dilakukan, tetapi masih cukup sulit untuk algoritma. Misalnya, lihat foto dan katakan apakah ada konten dewasa atau tidak, atau dengarkan rekaman audio dan dekripsi apa yang Anda dengar.

Toloka adalah alat yang sangat kuat dalam hal kinerja dan jumlah data yang membantu untuk dikumpulkan, tetapi agak non-sepele untuk digunakan. Orang-orang di foto mengenakan balaclava kuning karena semua pemain di Tolok tidak dikenal dan tidak dikenal oleh pelanggan. Dan untuk mengelola ribuan anonimus ini, memastikan bahwa mereka melakukan apa yang Anda butuhkan bukanlah tugas yang mudah. Karena itu, tidak semua tugas yang kami miliki, kami sejauh ini mampu menyelesaikannya dengan bantuan kerumunan yang benar-benar "liar" ini. Meskipun kami berusaha keras untuk ini, saya akan mengatakan lebih banyak tentang ini nanti.

Oleh karena itu, untuk tugas tingkat yang lebih tinggi, kami memiliki tingkat kinerja yang lebih tinggi. Inilah orang-orang yang kita sebut penilai. Kata "penilai" mungkin sedikit aneh. Itu berasal dari kata "penilaian", yaitu, "penilaian", karena awalnya para penilai digunakan bersama kami untuk mengumpulkan penilaian subjektif dari kualitas hasil pencarian. Data ini kemudian digunakan sebagai target untuk pembelajaran mesin fungsi peringkat pencarian. Sejak itu, banyak waktu telah berlalu, penilai mulai melakukan banyak tugas lain yang berbeda, jadi sekarang ini adalah kata yang biasa: tugas telah berubah, tetapi kata itu tetap ada.

Faktanya, penilai kami adalah karyawan penuh waktu Yandex, tetapi bekerja paruh waktu dan sepenuhnya jarak jauh. Mereka adalah orang-orang yang mengerjakan peralatan mereka sendiri. Kami hanya berinteraksi dengan mereka dari jarak jauh: kami memilih mereka dari jarak jauh, melatih mereka dari jarak jauh, bekerja dari jarak jauh dengan mereka dan, jika perlu, memecat mereka dari jarak jauh. Dengan sebagian besar dari mereka, kita tidak pernah bersinggungan secara langsung dalam kehidupan. Mereka bekerja sesuai dengan jadwal yang nyaman untuk diri mereka sendiri, siang atau malam: mereka memiliki standar minimum setara dengan sekitar 10-15 jam seminggu, dan mereka dapat bekerja saat ini dengan cara yang sesuai untuk mereka. Penilai memecahkan berbagai masalah: mereka terhubung dengan pencarian, dan dengan dukungan teknis, dan dengan beberapa terjemahan tingkat rendah, dan dengan pengujian, yang akan kita bicarakan nanti.

Sebagai aturan, apa pun tugas yang kami ambil, orang-orang paling berbakat selalu menonjol dari kelompok penilai yang melakukannya dengan lebih baik, yang tugasnya lebih menarik. Kami memilih mereka, memberi mereka gelar super-speaker yang keras, dan orang-orang ini sudah melakukan fungsi kurator tingkat tinggi: mereka memeriksa kualitas kerja orang lain, berkonsultasi dengan mereka, mendukung mereka, dan sebagainya.

Dan hanya di bagian paling atas piramida kami, kami memiliki karyawan penuh waktu pertama yang duduk di kantor dan mengelola proses ini. Kami memiliki lebih sedikit orang yang sudah berada di level yang lebih tinggi dan memiliki keterampilan teknis dan manajerial yang kuat, secara harfiah sedikit. Sistem seperti itu memungkinkan kita untuk sampai pada kesimpulan bahwa unit-unit orang "tingkat tinggi" ini membangun jaringan pipa dan mengelola rantai produksi, di mana puluhan, ratusan, dan bahkan ribuan orang terlibat lebih jauh.

Dengan sendirinya, skema ini bukanlah hal baru, namun Jenghis Khan berhasil menerapkannya. Dia memiliki beberapa properti menarik yang kami coba gunakan. Properti pertama cukup dimengerti - skema seperti ini sangat mudah untuk diukur. Jika suatu tugas perlu tiba-tiba mulai melakukan lebih banyak, maka kita tidak perlu mencari ruang tambahan di kantor untuk menanam seseorang di suatu tempat. Secara umum, kita dapat memikirkan sangat sedikit tentang apa: hanya menuangkan lebih banyak uang, merekrut lebih banyak artis untuk uang ini, dan lebih banyak orang berbakat di topi akademis mungkin akan tumbuh dari para seniman ini, dan seluruh sistem ini akan terus berkembang.
Properti kedua (dan mengejutkan bagi saya) adalah bahwa piramida seperti itu direplikasi dengan sangat baik terlepas dari bidang subjek di mana ia diterapkan. Ini juga berlaku untuk area yang akan kita bicarakan hari ini - tugas pengujian manual.

Pengujian Kerumunan

Ketika kami memulai proses pengujian dengan bantuan orang banyak, masalah terbesar adalah kurangnya referensi positif. Tidak ada pengalaman yang bisa kita rujuk dan katakan: "Yah, orang-orang ini melakukan ini, mereka sudah menguji dengan bantuan orang banyak di sirkuit yang sangat mirip dengan kita, dan semuanya baik-baik saja di sana, yang berarti bahwa semuanya akan baik-baik saja dengan kita." Oleh karena itu, kami harus mengandalkan hanya pada pengalaman pribadi kami, yang dipisahkan dari bidang subjek pengujian dan lebih terkait dengan menyiapkan proses produksi yang serupa, tetapi di bidang lain.

Karena itu, kami harus melakukan apa yang kami bisa. Apa yang bisa kita lakukan Intinya, menguraikan satu tugas menjadi tugas dengan tingkat kesulitan yang berbeda dan menyebarkannya di lantai piramida kita. Mari kita lihat apa yang kita dapat.

Pertama, kami melihat tugas-tugas yang disibukkan oleh penguji kami di Yandex dan meminta mereka untuk menyebarkan tugas-tugas ini secara bersyarat pada berbagai tingkat kesulitan. Ini adalah "rata-rata rumah sakit":



Mereka memperkirakan bahwa hanya 57% dari waktu mereka dihabiskan untuk tugas-tugas tingkat tinggi yang kompleks, dan sekitar 20% dihabiskan untuk rutinitas tingkat sangat rendah yang ingin dihilangkan semua orang, dan pada tugas-tugas yang sedikit lebih rumit, yang juga dapat didelegasikan. Didorong oleh angka-angka ini, menunjukkan bahwa hampir setengah dari pekerjaan dapat ditransfer ke suatu tempat, kami melanjutkan untuk membangun pengujian menggunakan orang banyak.

Apa tujuan kami?

• Jadikan pengujian tidak lagi menjadi penghambat yang muncul secara berkala dalam proses produksi saat rilis siap, tetapi menunggu pengujian berlalu.
• Bebaskan spesialis kami yang keren, sangat cerdas, tingkat tinggi - penguji penuh waktu - dari rutinitas, tempati mereka dengan tugas yang benar-benar menarik dan tingkat yang lebih tinggi.
• Tingkatkan keragaman lingkungan tempat kami menguji produk.
• Belajar menangani beban puncak karena penguji kami mengatakan mereka sering mengalami beban yang tidak rata. Bahkan jika, secara rata-rata, sebuah tim mengatasi tugas, ketika suatu puncak terjadi, maka dibutuhkan waktu yang sangat lama untuk menguasainya.
• Karena kami di Yandex masih menghabiskan cukup banyak uang untuk pengujian outsourcing di beberapa proyek, kami berpikir bahwa kami ingin mendapatkan sedikit lebih banyak hasil untuk uang yang kami keluarkan, untuk mengoptimalkan biaya outsourcing kami.

Saya ingin menekankan bahwa di antara tujuan-tujuan ini tidak ada tugas untuk mengganti penguji dengan orang banyak, entah bagaimana melanggar mereka, dan sebagainya. Yang kami ingin lakukan hanyalah membantu tim pengujian, menghilangkan rutinitas tingkat rendah.

Mari kita lihat apa yang akhirnya kita lakukan. Saya akan mengatakan segera bahwa tugas utama pengujian sekarang dilakukan bukan oleh level terendah "piramida", oleh para tolker, tetapi oleh penilai, karyawan penuh waktu kami. Selanjutnya, kita akan membahas terutama tentang mereka, kecuali untuk yang paling akhir.

Penilai sekarang melakukan tugas pengujian regresi untuk kami dan mereka melakukan semua jenis jajak pendapat seperti "lihat aplikasi ini dan tinggalkan umpan balik Anda". Sekitar 300 orang sekarang memenuhi syarat untuk tugas bantuan penuh ( catatan: sejak laporan menjadi 500 ). Tetapi angka ini bersyarat, karena sistem yang kami bangun berfungsi untuk jumlah orang yang sewenang-wenang: sebanyak yang kami butuhkan. Sekarang kebutuhan produksi kami dipenuhi oleh begitu banyak orang. Ini tidak berarti bahwa setiap saat mereka siap dan siap untuk melaksanakan tugas: karena penilai bekerja dalam jadwal yang fleksibel, setiap saat, 100-150 orang siap untuk terhubung. Tapi kumpulan pemain hampir sama. Dan tugas-tugas sederhana, seperti jajak pendapat, ketika Anda hanya perlu mengumpulkan umpan balik informal dari pengguna, kami melewati lebih banyak orang: ratusan dan ribuan penilai berpartisipasi dalam jajak pendapat tersebut.

Karena ini adalah orang-orang yang bekerja dengan peralatan mereka sendiri, setiap penilai memiliki perangkat pribadinya sendiri. Ini, secara default, adalah desktop dan semacam perangkat seluler. Karenanya, kami menguji produk kami pada perangkat penilai pribadi. Tetapi jelas bahwa mereka tidak memiliki semua perangkat yang mungkin, jadi jika kita perlu pengujian di beberapa lingkungan yang jarang, kami menggunakan akses jarak jauh melalui perangkat pertanian.

Sekarang pengujian kerumunan sudah digunakan sebagai proses produksi standar untuk sekitar 40 ( catatan: sekarang 60 ) layanan dan tim Yandex: ini adalah Mail, Disk, dan Browser (seluler dan desktop), dan Maps, dan Pencarian, dan banyak, banyak siapa Ini penasaran. Ketika kami menetapkan rencana untuk akhir kuartal ketiga pada musim gugur 2017, kami memiliki tujuan yang ambisius: untuk menarik setidaknya, entah bagaimana, “bahkan dengan penipuan, bahkan dengan menyuap”, setidaknya lima tim yang akan menggunakan proses pengujian kami dengan bantuan orang banyak. Dan kami sangat membujuk semua orang, berkata: "Jangan takut, ayo, coba!" Tetapi setelah hanya beberapa bulan, kami memiliki lusinan tim.

Dan sekarang kami sedang memecahkan masalah lain: bagaimana mengelola untuk menghubungkan semakin banyak tim baru yang ingin bergabung dengan proses ini. Jadi kita dapat berasumsi bahwa sekarang ini sudah menjadi praktik standar di Yandex, yang terbang sangat baik.

Apa yang kami lakukan dalam hal indikator produksi? Sekarang kami sedang melakukan sekitar 3.000 kasus pengujian regresi per hari ( catatan: per Oktober 2018, sudah ada 7.000 kasus ). Tes berjalan, tergantung pada ukurannya, membutuhkan beberapa jam hingga (pada puncaknya) 2 hari. Sebagian besar berlalu dalam beberapa jam, dalam sehari. Pengenalan sistem semacam itu memungkinkan kami untuk mengurangi biaya sekitar 30% dibandingkan dengan periode ketika kami menggunakan outsourcing. Hal ini memungkinkan tim untuk merilis lebih sering, rata-rata, beberapa kali, karena rilis mulai lulus dengan kecepatan yang tersedia untuk pengembangan, dan bukan yang tersedia untuk pengujian, ketika kadang-kadang menjadi hambatan.

Sekarang saya akan mencoba memberi tahu bagaimana kita umumnya membangun proses produksi, yang memungkinkan kita untuk datang ke skema ini.

Infrastruktur

Mari kita mulai dengan infrastruktur teknis. Anda yang telah melihat Toloka sebagai platform, bayangkan seperti apa tampilannya: Anda dapat masuk ke sistem, memilih tugas yang menarik minat Anda, dan menyelesaikannya. Untuk karyawan internal, kami memiliki instance internal Toloka, di mana kami, antara lain, mendistribusikan tugas dari berbagai jenis untuk penilai kami.



Gambar menunjukkan tampilan antarmuka ini. Di sini Anda dapat melihat tugas-tugas yang tersedia untuk penilai: di sini ada beberapa tugas untuk pengujian dan beberapa tugas dari jenis yang berbeda, yang juga dinilai oleh penilai dari contoh ini. Maka orang tersebut datang, melihat tugas-tugas yang tersedia untuknya saat ini, mengklik “Lanjutkan”, menerima uji kasus untuk dianalisis dan mulai melaksanakannya.

Bagian penting dari infrastruktur kami adalah pertanian. Tidak semua perangkat ada di tangan, jadi tugasnya adalah, pada kenyataannya, pasangan: test case dan lingkungan di mana Anda perlu memeriksanya. Ketika seseorang mengklik tombol Lanjutkan, sistem akan memeriksa untuk melihat apakah ia memiliki lingkungan untuk diuji. Jika ada, maka orang tersebut hanya mengambil tugas dan mengujinya pada perangkat pribadi. Jika tidak, maka kami mengirimkannya melalui akses jarak jauh ke tambak.



Gambar menunjukkan tampilannya, menggunakan contoh peternakan seluler. Jadi seseorang yang terhubung ke ponsel dari jarak jauh di kantor kami di pertanian. Untuk Android, kami menggunakan solusi open source OpenSTF. Tidak ada solusi yang baik untuk iOS - sejauh kami telah membuat sendiri (tetapi kami akan membicarakannya secara rinci di lain waktu), karena kami tidak dapat menemukan sumber terbuka atau sesuatu yang masuk akal untuk dibeli. Jelas bahwa tambak berguna dalam kasus di mana kami tidak memiliki orang yang memiliki perangkat yang tepat. Dan nilai tambah penting lainnya adalah bahwa peternakan memiliki tingkat pemanfaatan yang sangat tinggi: kapan pun dan apa pun orangnya masuk, kami dapat mengirimkannya ke peternakan kapan saja. Ini lebih baik daripada membagikan perangkat secara langsung, karena perangkat yang diserahkan kepada seseorang tersedia untuk bekerja hanya jika orang itu siap untuk bekerja.

Kami berbicara sedikit tentang bagaimana itu diterapkan untuk penilai kami dari sudut pandang teknis, dan sekarang bagian yang paling menarik bagi saya: prinsip-prinsip bagaimana kami mengatur produksi ini.

Prinsip-prinsip organisasi produksi dalam kerumunan

Bagi saya dalam proyek ini, menarik bahwa bidang subjek tampaknya sangat spesifik, tetapi semua prinsip pengorganisasian produksi cukup universal: prinsip-prinsip yang sama yang digunakan dalam mengatur produksi massal di bidang subjek lain.

1. Formalisasi

Prinsip pertama (bukan yang paling penting, tetapi salah satu yang paling penting, salah satu dari "paus, gajah, dan kura-kura" kami) adalah formalisasi tugas. Saya pikir Anda semua tahu ini sendiri. Hampir semua tugas paling mudah dilakukan sendiri. Agak sulit untuk menjelaskan kepada kolega Anda yang duduk di sebelah Anda di ruangan sehingga ia melakukan apa yang Anda butuhkan. Dan tugasnya adalah memastikan bahwa ratusan seniman yang belum pernah Anda lihat, yang bekerja dari jarak jauh, kapan saja, melakukan apa yang Anda harapkan dari mereka - tugas ini beberapa urutan besarnya lebih rumit dan menyiratkan ambang batas yang agak tinggi untuk masuk untuk mulai melakukan ini sama sekali. Dalam konteks tugas pengujian, tugas bersama kami, tentu saja, adalah kasus uji yang perlu diteruskan dan diproses.

Dan kasus uji apa yang harus digunakan untuk dapat menggunakannya dalam tugas seperti pengujian kerumunan?

Pertama - dan ternyata ini bukan masalah fakta - kasus uji seharusnya secara umum.Ada kalanya tim datang kepada kami yang ingin terhubung ke pengujian oleh penilai, kami berkata: "Hebat, bawa kasus uji Anda, kami akan melaluinya!" Pada saat ini, pelanggan sedih, pergi, tidak selalu kembali. Setelah beberapa permohonan, kami menyadari bahwa saya mungkin perlu bantuan di tempat ini. Karena jika seorang penguji dari tim layanan secara teratur menguji layanannya, ia tidak benar-benar membutuhkan kasus uji yang lengkap dan dijelaskan dengan baik. Dan jika kita ingin mendelegasikan tugas ini ke sejumlah besar pemain, maka kita tidak bisa melakukannya tanpa itu.

Tetapi bahkan dalam kasus-kasus ketika ada uji kasus sama sekali, mereka hampir selalu dimengerti hanya untuk orang-orang yang sangat tenggelam dalam layanan. Dan semua orang lain yang berada di luar konteks, sangat sulit untuk memahami apa yang terjadi di sini dan apa yang perlu dilakukan. Oleh karena itu, penting untuk merevisi kasus uji sehingga dapat dimengerti oleh orang yang tidak tenggelam dalam konteks.

Dan yang terakhir: jika kita mengurangi tugas pengujian untuk secara resmi melewati kasus-kasus tertentu, sangat penting untuk memastikan bahwa kasus-kasus ini terus diperbarui, diperbarui dan diperbarui.

Saya akan memberikan beberapa contoh.



Gambar di atas, misalnya, menunjukkan kasus yang baik dari layanan Tolok asli kami, di mana Anda perlu memeriksa kebenaran profil artis. Semuanya dipecah dalam langkah-langkah. Ada setiap langkah yang harus diambil. Ada harapan tentang apa yang harus terjadi pada setiap langkah. Kasus seperti itu akan jelas bagi siapa pun.



Dan ini adalah contoh kasus yang tidak begitu sukses. Secara umum, tidak jelas apa yang terjadi. Gambaran itu tampaknya ada di sana, tetapi dalam kenyataannya - apa itu, apa yang Anda inginkan dari saya? Kasing jenis ini - tidak ada di sana segera;

Bagaimana kita membangun proses formalisasi kasus uji sehingga, pertama, kita memiliki semuanya, terus muncul dan diisi ulang, dan, kedua, bahwa mereka cukup dimengerti oleh penilai?

Melalui coba-coba, kami sampai pada skema ini:



Pelanggan kami, yaitu, semacam layanan atau tim, datang dan dalam bentuk sewenang-wenang sewenang-wenang baginya, menjelaskan kasus-kasus uji yang ia butuhkan.

Setelah ini datang penilai pintar kami, yang melihat teks yang diformulasikan secara bebas ini dan menerjemahkannya ke dalam kasus uji yang diformalkan dengan baik dan dicat dalam detail kecil. Mengapa penilai ini penting? Karena dia sendiri berada di posisi orang-orang yang mengambil kasus uji dari daerah yang sama sekali berbeda, dan memahami betapa terperinci kasus tes seharusnya bagi rekan kerja untuk memahaminya.

Setelah itu, kami menjalankan kasus: kami memberikan tugas kepada penilai dan mengumpulkan umpan balik. Prosesnya diatur sedemikian rupa sehingga jika seseorang tidak memahami apa yang dituntut darinya dalam sebuah test case, ia melewatkannya. Sebagai aturan, setelah pertama kali ada persentase operan yang cukup besar. Bagaimanapun, tidak peduli seberapa baik kita memformalkan kasus uji pada tahap sebelumnya, tidak pernah mustahil untuk menebak apa yang akan dipahami orang. Oleh karena itu, proses pertama hampir selalu merupakan versi uji, fungsinya yang paling penting adalah untuk mengumpulkan umpan balik. Setelah kami mengumpulkan umpan balik, menerima komentar dari penilai, mempelajari apa yang mereka pahami dan apa yang tidak, kami menulis ulang, menambahkan kasus uji sekali lagi. Dan setelah beberapa iterasi kami menjadi keren, sangat jelas diformulasikan kasus uji yang dapat dimengerti oleh semua orang.

Merapikan ini memiliki efek samping yang menarik. Pertama, ternyata untuk banyak tim ini umumnya merupakan fitur pembunuh. Semua orang mendatangi kami dan berkata, "Bisakah Anda benar-benar menulis kasus uji untuk saya?" Ini adalah hal terpenting yang kami tarik dari pelanggan kami. Efek kedua, tidak terduga bagi saya - urutan dalam kasus uji memiliki efek tertunda lainnya. Sebagai contoh, kami memiliki penulis teknis yang menulis dokumentasi pengguna, dan jauh lebih mudah bagi mereka untuk menulis berdasarkan uji kasus yang dipahami dan dipahami. Sebelumnya, mereka harus mengalihkan perhatian layanan untuk mencari tahu apa yang perlu dijelaskan, tetapi sekarang kita dapat menggunakan test case yang jelas dan keren.

Saya akan memberi contoh.



Inilah yang tampak seperti kasus uji sebelum melewati penggiling daging kami: sangat sedikit, bidang uraian tidak diisi, dikatakan "baik, lihat tangkapan layar di aplikasi" dan hanya itu.



Beginilah caranya dia mulai menjaga setelah dia ditulis ulang - menambahkan langkah dan harapan pada setiap langkah. Sudah jauh lebih baik. Jauh lebih menyenangkan bekerja dengan test case seperti itu.

2. Pembelajaran yang skalabel

Tugas selanjutnya adalah favorit saya, yang menurut saya paling kreatif dalam hal ini. Ini adalah tugas pembelajaran yang skalabel. Agar kami dapat beroperasi dengan angka seperti itu - “di sini kami memiliki 200 penilai, di sini ada 1.000, dan di sini secara umum 17.000 pelanggan bekerja setiap hari” - penting untuk dapat dengan cepat dan scalably melatih orang.


Sangat penting untuk datang ke sistem seperti itu ketika Anda tidak lagi menghabiskan waktu untuk melatih sejumlah orang yang sewenang-wenang daripada melatih spesialis tertentu. Ini, misalnya, adalah apa yang kami temui ketika bekerja dengan outsourcing. Para spesialis sangat keren, tetapi untuk membenamkan mereka dalam konteks pekerjaan, layanan membutuhkan banyak waktu, dan pada output kami masih mendapatkan satu orang yang terbenam dalam konteks selama enam bulan. Dan ini adalah skema yang sangat skalabel. Ternyata setiap orang berikutnya perlu dibenamkan dalam konteks tugas selama enam bulan lagi. Dan perlu untuk memperluas hambatan ini.

Untuk lowongan massal apa pun, tidak hanya dalam pengujian, kami merekrut orang melalui beberapa saluran. Untuk pengujian, kami melakukannya. Pertama, kami menarik orang-orang yang, pada prinsipnya, tertarik pada tugas-tugas pengujian, orang-orang di suatu tempat di tingkat penguji junior, bagi mereka ini adalah awal yang baik, pencelupan di bidang subjek. Tetapi masih ada sejumlah orang seperti itu di pasar, dan kita perlu bahwa kita tidak memiliki batasan untuk mempekerjakan orang, sehingga kita tidak pernah bergantung pada jumlah pemain.

Oleh karena itu, selain mencari penguji khusus untuk tugas-tugas ini, kami melakukan serangkaian orang yang hanya menanggapi posisi umum penilai. Kami mempromosikan tentang pendekatan ini: tidak peduli apa pun orang yang Anda ambil, jika ada banyak dari mereka, Anda dapat membangun suatu proses sehingga Anda memilih yang paling mampu dari mereka dan mengarahkan mereka untuk menyelesaikan masalah yang Anda kejar. Dalam konteks pengujian, kami membangun pelatihan sehingga dimungkinkan bagi orang yang sewenang-wenang yang bahkan tidak tahu apa-apa tentang pengujian untuk mengajar setidaknya dasar-dasar minimum sehingga mereka mulai memahami sesuatu. Berkat pendekatan ini, kami tidak pernah mengalami kurangnya pemain dan jumlah orang yang bekerja untuk kami dalam tugas-tugas ini, semuanya bermuara pada pertanyaan tentang berapa banyak uang yang bersedia kami keluarkan untuk itu.

Saya tidak tahu seberapa sering Anda menemukan topik ini, tetapi dalam semua jenis artikel sains populer, terutama tentang pembelajaran mesin dan jaringan saraf, sering ditulis bahwa pembelajaran mesin sangat mirip dengan pelatihan manusia. Kami menunjukkan kepada anak 10 kartu dengan gambar bola, dan untuk yang ke 11 kalinya ia akan mengerti dan berkata: “Oh! Ini bola! ” Bahkan, visi komputer dan teknologi pembelajaran mesin lainnya juga bekerja pada dasarnya.

Saya ingin berbicara tentang situasi yang berlawanan: melatih orang dapat dibangun dengan cara formal yang sama seperti mesin pelatihan. Apa yang kita butuhkan untuk ini? Kita membutuhkan satu set pelatihan - satu set contoh pra-ditandai di mana seseorang akan dilatih. Kita memerlukan satu set kontrol, di mana kita dapat memeriksa apakah dia belajar dengan baik atau tidak. Seperti dalam pembelajaran mesin, Anda memerlukan set tes yang kami mengerti bagaimana fungsi kami umumnya bekerja. Dan kita membutuhkan metrik formal yang akan mengukur kualitas pekerjaan yang dilakukan. Berdasarkan prinsip-prinsip inilah kami telah membangun pelatihan dalam tugas-tugas pengujian regresi paling sederhana.


Gambar tersebut menunjukkan bagaimana pelatihan ini terlihat bersama kami. Ini terdiri dari beberapa bagian. Pertama, ada teori, lalu latihan, dan kemudian ujian berlangsung, di mana kami memeriksa apakah seseorang memahami esensi masalah atau tidak mengerti.



Mari kita mulai dengan teorinya. Jelas bahwa untuk tugas apa pun yang dilakukan penilai, kami memiliki instruksi yang besar, berbobot, dan lengkap dengan sejumlah besar contoh, di mana semuanya dijelaskan dengan sangat rinci. Tapi tidak ada yang membacanya.

Oleh karena itu, untuk memverifikasi bahwa pengetahuan teoretis benar-benar ada di kepala seseorang, kami selalu memberikan akses ke instruksi, tetapi setelah itu kami menggunakan apa yang kami sebut sebagai "tes teoritis". Ini adalah ujian, di mana kami memuat pertanyaan penting bagi kami dan jawaban yang benar. Pertanyaan mungkin yang paling bodoh. Saya pikir bagi Anda ini akan menjadi contoh lucu, tetapi bagi orang-orang yang dihadapkan dengan tugas pengujian untuk pertama kalinya dalam hidup mereka, ini sama sekali bukan hal yang jelas. Misalnya: "Jika saya bertemu beberapa bug, apakah saya harus memulai beberapa tiket - satu untuk setiap bug - atau membuang semuanya dalam satu tumpukan?" Atau: "Bagaimana jika saya ingin mengambil tangkapan layar, tetapi tangkapan layar itu tidak berhasil bagi saya?"

Ini bisa sangat berbeda, pertanyaan tingkat rendah sewenang-wenang, dan penting bagi kita bahwa seseorang bekerja secara mandiri pada tahap mempelajari teori. Oleh karena itu, tes teoritis terdiri dari pertanyaan jenis ini: "Saya menemukan beberapa bug, haruskah saya memiliki satu tiket atau beberapa?" Jika seseorang memilih jawaban yang salah, dadu merah jatuh yang berbunyi, "Tidak, tunggu, jawaban yang benar berbeda, perhatikan itu." Bahkan jika seseorang belum membaca instruksi, dia tidak dapat lulus tes ini.



Poin berikutnya adalah latihan. Bagaimana memastikan bahwa orang yang tidak tahu apa-apa tentang pengujian sama sekali dan tidak menanggapi kekosongan penguji secara khusus, memahami apa yang harus dilakukan selanjutnya? Di sini kita sampai pada set pelatihan itu. Saya pikir Anda akan segera menemukan sejumlah besar bug yang ada di gambar ini. Beginilah tugas pelatihan untuk penilai: di sini ada tangkapan layar di depan Anda, temukan semua bug di sana. Apa yang salah di sini? Kalkulator mencuat. Apa lagi Tata letak pergi.



Atau inilah contoh yang lebih kompleks, dengan tanda bintang. Kotak surat penerima utama terbuka, saya orang yang mengirim surat ini. Jadi saya melihat gambar seperti itu di depan saya. Apa bug di sini? Masalah terbesar di sini adalah bahwa salinan buta ditampilkan, dan sebagai penerima surat saya melihat siapa itu dalam salinan buta.

Setelah melewati beberapa lusin contoh seperti itu, bahkan seseorang yang jauh dari pengujian, sudah mulai memahami apa itu dan apa yang diperlukan darinya lebih lanjut ketika melewati kasus-kasus uji. Bagian praktisnya adalah serangkaian contoh di mana kita sudah tahu bug; kami meminta orang itu untuk menemukan mereka dan pada akhirnya kami menunjukkan kepadanya: "Lihat, bug ada di sini", sehingga ia menghubungkan tebakannya dengan jawaban yang benar.



Dan bagian terakhir adalah apa yang kita sebut ujian. Kami memiliki unit uji khusus, bug yang sudah diketahui oleh kami, dan kami meminta orang untuk melewatinya. Di sini kita tidak lagi menunjukkan kepadanya jawaban yang benar dan salah, tetapi lihat saja apa yang bisa dia temukan.

Keindahan sistem ini dan skalabilitasnya terletak pada kenyataan bahwa semua proses ini terjadi secara otonom, tanpa partisipasi seorang manajer. Kami menjalankan sebanyak mungkin orang yang Anda inginkan: setiap orang yang ingin membaca instruksi, setiap orang yang ingin mengikuti ujian teoretis, setiap orang yang ingin mengikuti latihan - semua ini terjadi secara otomatis dengan satu sentuhan tombol, dan kami tidak memiliki masalah sama sekali.

Bagian terakhir - ujian - juga dilewati oleh semua orang yang ingin, dan akhirnya, kita mulai melihat mereka dengan cermat. Karena ini adalah rakitan pengujian dan kami mengetahui semua bug sebelumnya, kami dapat secara otomatis menentukan berapa persen bug yang ditemukan seseorang. Jika sangat rendah, maka kami tidak melihat lebih jauh, kami menulis beat otomatis: "Terima kasih banyak atas upaya Anda!" - dan tidak memberikan orang ini akses ke misi tempur. Jika kita melihat bahwa hampir semua bug telah ditemukan, maka pada saat itu seseorang sudah menghubungkan siapa yang melihat seberapa benar tiket dikeluarkan, seberapa banyak semuanya dilakukan dengan benar sesuai prosedur, dari sudut pandang instruksi kami.

Jika kita melihat bahwa seseorang secara independen menguasai teori dan praktik dan lulus ujian dengan baik, maka kita membiarkan orang-orang seperti itu masuk ke dalam proses produksi kita. Skema ini bagus karena tidak tergantung pada berapa banyak orang yang kita lewati. Jika kita membutuhkan lebih banyak orang, kita hanya membanjiri lebih banyak orang di pintu masuk dan mendapatkan lebih banyak di pintu keluar.

Ini adalah sistem yang keren, tetapi, tentu saja, akan naif untuk percaya bahwa setelah itu Anda sudah dapat memiliki tester yang sudah jadi. Bahkan orang-orang yang telah berhasil menyelesaikan pelatihan kami memiliki banyak pertanyaan yang perlu mereka bantu dengan cepat. Dan di sini kita dihadapkan dengan banyak masalah yang tidak terduga bagi kita.

Orang-orang banyak bertanya. Selain itu, pertanyaan-pertanyaan ini bisa sangat aneh sehingga Anda tidak akan pernah berpikir dalam hidup Anda bahwa jawaban atas pertanyaan-pertanyaan ini harus ditambahkan ke instruksi, dijelaskan dalam ujian atau sesuatu seperti itu. Jika Anda memikirkannya, ini adalah situasi yang normal. Kita masing-masing, ketika kita menemukan diri kita di daerah yang tidak kita kenal, tidak mungkin mengajukan pertanyaan yang tampaknya konyol bagi seorang spesialis.

Di sini situasinya diperburuk oleh fakta bahwa kita memiliki beberapa ratus orang ini, dan bahkan jika masing-masing dari kita bertanya pada orang tertentu, kemungkinan mengajukan pertanyaan bodoh itu rendah, secara total ternyata: Ya Tuhan Apa yang sedang terjadi Itu membanjiri kita! "

Terkadang pertanyaannya terasa aneh. Misalnya, seseorang menulis: "Saya tidak mengerti apa artinya" masuk ke Undo. " Mereka berkata kepadanya: “Teman! Ini sama dengan mengklik tombol "Batal". " Dia: "Oh! Terima kasih Sekarang saya mengerti segalanya. ”

Atau orang lain berkata: "Semuanya tampak baik-baik saja, tetapi ada sesuatu yang rusak, saya tidak bisa mengerti apakah ini kesalahan atau tidak." Tapi setelah satu menit dia sendiri mengerti dari mana dia masuk ke tugas pengujian; mungkin foto yang rusak tidak terlalu normal. Di sini dia mengerti, dan baik-baik saja.

Atau inilah contoh menarik yang benar-benar menjerumuskan kita ke dalam jurang penelitian untuk waktu yang lama. Seorang pria datang dan berkata:



Semua orang tidak mengerti apa yang terjadi, dari mana asalnya - kami berusaha sangat keras, mendeskripsikan kasus pengujian - sampai kami mengetahui bahwa ia memiliki semacam ekstensi browser khusus yang diterjemahkan dari bahasa Rusia ke bahasa Inggris, dan kemudian dari bahasa Inggris ke bahasa Rusia , dan pada akhirnya kami mendapatkan beberapa bid'ah.

Bahkan, ada banyak pertanyaan seperti itu, studi masing-masing dari mereka membutuhkan waktu yang tidak nol. Dan pada titik tertentu, pelanggan kami - layanan tim Yandex yang menggunakan pengujian oleh penilai - mulai merobek rambut mereka dan berkata: "Dengar, kita akan menghabiskan lebih sedikit waktu jika kita menguji semua ini sendiri, daripada duduk di ruang obrolan ini dan menjawab untuk pertanyaan-pertanyaan aneh ini. "

Karena itu, kami sampai pada sistem obrolan dua tingkat. Ada banjir bersyarat, di mana penilai kami berkomunikasi dengan kurator mereka, "orang-orang bertopi" - 90% dari masalah diselesaikan di sini. Dan hanya masalah yang paling penting dan kompleks yang ditingkatkan menjadi obrolan khusus di mana tim layanan duduk. Ini sangat memudahkan kehidupan semua tim, semua orang mendesah dengan tenang.



Kengerian yang saya bicarakan ini tidak begitu mengerikan. Berita baiknya adalah semua proses ini bertemu dengan sangat cepat. Peluncuran pertama selalu sangat buruk. Pada gambar di atas, 6 mulai berturut-turut dari regresi yang sama terlihat.

Lihatlah berapa banyak waktu yang dihabiskan anggota staf untuk menjawab pertanyaan, untuk pertama kalinya ketika penilai tidak mengerti apa yang mereka bicarakan dan apa yang mereka inginkan dari mereka. Mereka menemukan beberapa bug, mereka mulai banyak tiket tentang apa-apa. Karena itu, yang pertama adalah horor-horor-horor, yang kedua adalah horor-horor, dan yang ketiga kalinya, 80 persen dari semua proses bertemu. Dan kemudian muncul proses yang berhasil: penilai terbiasa dengan tugas baru, dan setelah setiap peluncuran kami mengumpulkan umpan balik, menambah kasus uji, dan menyelesaikan sesuatu. Dan ternyata sebuah pabrik keren yang bekerja dengan mengklik tombol dan tidak memerlukan keterlibatan spesialis penuh waktu.

3. Kontrol kualitas

Poin yang sangat penting, yang tanpanya semua ini tidak akan berhasil, adalah kontrol kualitas.

Para penilai kami bekerja dengan upah sesuai hasil kerja: semua tugas mereka diatur dan dikuantifikasi dengan sangat jelas, setiap unit kerja memiliki tarif standar sendiri, dan mereka menerima pembayaran untuk jumlah unit yang diselesaikan. Toloka bekerja dengan cara yang persis sama, dan secara umum semua orang. Sistem ini memiliki banyak kelebihan, sangat fleksibel, tetapi juga memiliki kekurangan. Dalam sistem dengan upah borongan, kontraktor mana pun akan mencoba untuk mengoptimalkan pekerjaan mereka - menghabiskan waktu dan upaya sesedikit mungkin pada tugas untuk mendapatkan lebih banyak uang per unit waktu. Oleh karena itu, sistem apa pun yang dibangun di atas crowdsourcing dijamin bekerja dengan kualitas minimum yang Anda izinkan. Jika Anda tidak memiliki kendali atas kualitas, maka kualitasnya akan turun serendah mungkin.

Berita baiknya adalah Anda bisa melawannya, itu bisa dikontrol. Jika kita bisa mengukur kualitas pekerjaan, maka tugasnya turun ke pekerjaan yang cukup sederhana. Ini dalam teori. Dalam praktiknya, tidak sesederhana itu sama sekali, terutama dalam tugas-tugas pengujian. Karena pengujian, tidak seperti banyak tugas massal lainnya yang kami selesaikan dengan bantuan penilai, berurusan dengan peristiwa langka, dan semua jenis statistik bekerja sangat buruk di sana. Sangat sulit untuk memahami seberapa sering seseorang benar-benar menemukan bug, jika pada dasarnya ada sedikit bug. Oleh karena itu, kita harus memutarbalikkan dan menggunakan beberapa metode kontrol kualitas sekaligus, yang bersama-sama akan memberi kita gambaran tertentu tentang kualitas pekerjaan pemain.

Yang pertama adalah cek di tumpang tindih. "Tumpang tindih" berarti bahwa kami menetapkan setiap tugas kepada beberapa orang. Kami melakukan ini secara alami, karena setiap test case perlu diuji di beberapa lingkungan. Dengan demikian, ternyata uji kasus yang sama diperiksa di lingkungan A, B, dan C. Kami memiliki tiga hasil dari tiga orang - yang lulus uji kasus yang sama. Kemudian kita melihat apakah hasilnya berbeda.

Kadang-kadang terjadi bahwa bug ditemukan di satu lingkungan, tetapi tidak di dua lainnya. Mungkin itu benar, atau mungkin kesalahan seseorang: salah satu orang menemukan bug tambahan, atau keduanya palsu dan tidak menemukan sesuatu. Bagaimanapun, ini adalah kasus yang mencurigakan. Jika kami mengalami hal ini, maka kami mengirim untuk memeriksa kembali untuk memastikan dan memeriksa siapa yang benar dan siapa yang harus disalahkan. Skema semacam itu memungkinkan kita untuk menangkap orang-orang yang, misalnya, memulai tiket ekstra di mana mereka tidak diperlukan, atau ketinggalan di mana mereka dibutuhkan. Pada saat yang sama, kami melihat seberapa benar tiket dimulai, apakah semuanya sesuai dengan prosedur: apakah tangkapan layar ditambahkan, jika perlu, adalah deskripsi yang jelas ditambahkan, dan sebagainya.

Selain itu, dan terutama ini menyangkut kebenaran tiket, itu bagus dan nyaman untuk secara otomatis mengontrol beberapa hal yang, di satu sisi, tampaknya sepele, tetapi, di sisi lain, cukup kuat mempengaruhi alur kerja. Karena itu, kami secara otomatis memeriksa apakah ada aplikasi untuk tiket, apakah tangkapan layar ditambahkan, apakah ada komentar di tiket atau hanya ditutup tanpa melihat berapa banyak waktu yang dihabiskan untuk mengidentifikasi kasus yang mencurigakan. Di sini Anda dapat menemukan banyak heuristik dan menerapkannya. Prosesnya hampir tak ada habisnya.

Memeriksa tumpang tindih adalah hal yang baik, tetapi memberikan penilaian yang agak bias, karena kami hanya memeriksa kasus kontroversial. Terkadang Anda ingin melakukan pemeriksaan spot yang jujur. Untuk melakukan ini, kami menggunakan uji coba. Pada tahap pelatihan, kami telah mengumpulkan rakitan uji khusus yang kami ketahui sebelumnya di mana ada bug dan di mana tidak. Kami menggunakan peluncuran serupa untuk kontrol kualitas dan memeriksa berapa banyak bug yang ditemukan seseorang dan berapa banyak yang terlewat. Ini adalah cara yang keren, ini memberikan gambaran dunia yang paling lengkap. Tapi itu cukup mahal untuk digunakan: sementara kami masih mengumpulkan perakitan tes baru ... Kami menggunakan pendekatan ini sangat jarang, setiap beberapa bulan.

Poin penting terakhir: bahkan jika kita telah melakukan segalanya, kita harus menganalisis mengapa bug dilewati. Kami memeriksa apakah mungkin untuk menemukan bug ini dengan langkah-langkah pada test case. Jika itu mungkin, tetapi orang tersebut ketinggalan, maka, maka, orang itu adalah sebuah cangkir, dan Anda harus memiliki efek pada dirinya. Dan jika kasus ini tidak ada, maka Anda perlu menambah, memperbarui kasus uji.

Akibatnya, kami mengurangi semua metrik kualitas menjadi satu peringkat penilai, yang memengaruhi karier dan nasib mereka dalam sistem kami. Semakin tinggi peringkat seseorang, semakin banyak ia menerima tugas dan klaim hadiah yang lebih sulit. Semakin rendah peringkat penilai, semakin besar kemungkinan akan diberhentikan. Ketika seseorang bekerja dengan stabil dengan peringkat rendah, kami akhirnya berpisah dengannya.

4. Delegasi

Yang paling terakhir dari pilar skema piramidal terukur yang ingin saya bicarakan adalah tugas-tugas delegasi.



Saya akan mengingatkan sekali lagi bagaimana bentuk piramida kami untuk tugas-tugas pengujian manual. Kami memiliki orang-orang "tingkat tinggi" - mereka adalah penguji penuh waktu, perwakilan tim layanan yang menyusun program pelatihan untuk layanan yang mereka perlu uji, membentuk strategi untuk apa yang perlu diuji, menulis kasus uji utama dalam bentuk bebas.

Selanjutnya, kami memiliki penilai paling berbakat yang mentransfer kasus uji dari bentuk bebas ke yang diformalkan, membantu penilai lain, mendukung mereka di ruang obrolan dan melakukan pemeriksaan silang dan kontrol kualitas selektif.
Lebih jauh lagi ada awan banyak pemain kami yang melakukan regresi langkah demi langkah.

Selanjutnya kita memiliki Toloka, yang belum kita lupakan.Sekarang kami berada pada tahap percobaan: kami memahami bahwa kasus paling sederhana dapat diberikan untuk pengujian kepada kerumunan yang tidak berpribadi di Toloka. Akan jauh lebih murah dan lebih cepat, karena ada lebih banyak pemain di sana. Tetapi sementara kita sedang dalam proses membangun sistem ini. Sekarang kami hanya memberikan yang paling sederhana, tetapi saya berharap bahwa dalam beberapa bulan kami akan sampai pada fakta bahwa kami akan mendelegasikan lebih banyak lagi.



Sangat penting untuk memantau perkembangan piramida ini. Pertama (pertanyaan seperti itu sering diajukan kepada saya, jadi saya ingin menjawabnya secara proaktif), crowdsourcing bukanlah penolakan terhadap pekerjaan spesialis tingkat tinggi yang mendukung orang banyak, tetapi alat penskalaan. Kami tidak dapat menolak bagian atas piramida ini, "kepala" kami, kami hanya dapat menggunakan crowdsourcing untuk menambah lebih banyak tangan ke sistem ini, jadi sangat mudah untuk meningkatkannya hampir gratis.

Kedua, ini bukan ilmu roket, tetapi Anda harus terus-menerus mengingat ini: keseluruhan cerita berfungsi dengan baik dan benar jika tugas-tugas yang paling sulit untuk tingkat ini diselesaikan di setiap tingkat. Secara kasar, jika hal yang sama dapat dilakukan pada beberapa tingkat piramida, ini harus dilakukan pada tingkat terendah. Ini bukan cerita yang statis, tetapi yang dinamis. Kita mulai dengan fakta bahwa hanya orang "tingkat tinggi" yang dapat melakukan beberapa tugas, secara bertahap memperbaiki proses dan menurunkan tugas-tugas di bawah ini, meningkatkan dan mengurangi seluruh proses.

Dan saya cukup sering mendengar ucapan seperti itu: "Mengapa repot-repot dengan taman ini, lebih baik mengotomatisasi semuanya dan menghabiskan energi untuknya." Tapi crowdsourcing bukan pengganti untuk otomatisasi, itu adalah hal yang paralel. Kami melakukan ini bukan bukan otomatisasi, tetapi sebagai tambahan. Sistem seperti itu hanya memungkinkan kita untuk membebaskan pekerja yang dapat terlibat dalam otomatisasi, di satu sisi, dan, di sisi lain, memformalkan proses dengan cukup baik, yang kemudian akan lebih mudah untuk diotomatisasi.


Pada akhirnya, saya akan mengingatkan sekali lagi bagaimana keseluruhan cerita kami terlihat. Kami mulai dengan mendapatkan test case dalam bentuk gratis. Kami menjalankannya beberapa kali melalui penilai, mengumpulkan umpan balik, menentukannya. Setelah itu kita menjadi dingin, sudah menjilat kasus-kasus tes Sejalan dengan ini, kami merekrut banyak, banyak orang, menempatkan mereka melalui sistem pelatihan otomatis dan di pintu keluar kami hanya mendapatkan mereka yang mampu mengatasi semua langkah sendiri dan menyadari apa yang kami inginkan darinya. Kami mendapat kerumunan yang terlatih. Ia bekerja untuk kami pada kasus uji yang diformalkan, dan kami mengontrol kualitasnya: kami terus memeriksanya, menganalisis kasus dengan bug yang terlewat untuk meningkatkan proses kami.

Dan sistem seperti itu bekerja untuk kita, lalat. Saya tidak tahu apakah kisah saya akan bermanfaat saat ini untuk seseorang dari sudut pandang praktis, tetapi saya berharap itu akan memungkinkan kita untuk berpikir sedikit lebih luas dan menganggap bahwa beberapa tugas dapat diselesaikan dengan cara ini. Karena - dan kita sering menjumpai ini - salah satu dari Anda sudah bisa membayangkan diri Anda berpikir: "Yah, mungkin ini bekerja di suatu tempat, tapi jelas bukan untuk saya. Saya memiliki tugas yang sangat sulit sehingga ini bukan tentang saya sama sekali. " Tetapi pengalaman kami menunjukkan bahwa hampir semua tugas dari hampir semua bidang subjek, jika diuraikan dengan benar, diformalkan, dan dibangun menjadi proses yang jelas, dapat ditingkatkan setidaknya sebagian dengan bantuan orang banyak.

Heisenbug 2018 Piter , : 6-7 Heisenbug , , .