Apakah mungkin untuk mengotomatisasi sesuatu? Maka kita akan memecat semua penguji, tentu saja. Mengapa mereka dibutuhkan sekarang, tidak ada pengujian "manual" yang tersisa. Benar setelah semua?
Ini adalah kisah tentang masa depan pengujian dalam hal DevOps. Akan ada angka-angka konkret dan kesimpulan yang murni praktis, bagaimana ternyata spesialis yang baik selalu memiliki pekerjaan. (Atau tidak bekerja! Lihat foto Shakespeare dan takut, nasibmu akan diputuskan sekarang).
Materi ini didasarkan pada transkrip laporan oleh Baruch
jbaruch Sadogursky, Advokat Pengembang di JFrog. Versi teks dan video laporan berada di bawah potongan.
Halo semuanya! Lihat kutipan dari Shakespeare dalam gambar di atas? Ini adalah Henry VI, proposal untuk membunuh semua pengacara. Anda mengerti, sejak itu kami memiliki lebih banyak cara vegetarian untuk menyingkirkan profesi yang salah. Kami tidak akan membunuh siapa pun, ambil saja dan tembak semua orang.
Lebih tepatnya, ada kesempatan seperti itu. Akankah kita memecat seseorang?
Mari kita bicara.
Ini Vasya. Suatu pagi, dia datang untuk bekerja dan berjalan melewati ruang pertemuan utama. Dan di sana bosnya menyambut konsultan baru.
Seorang konsultan efisiensi datang ke perusahaan dan berkata: “Kami akan melakukan DevOps seperti di netflix *. Kami secara khusus terbang ke Silicon Valley untuk sebuah konferensi, dan di sana kami diberi tahu bagaimana kabar mereka di netflix. ”
* Penafian: Netflix sering digunakan dalam artikel ini sebagai cita-cita DevOps yang tidak dapat dicapai. Penggunaan ini adalah kata rumah tangga.
Diskusi apakah Netflix benar-benar memiliki DevOps yang sempurna berada di luar cakupan artikel ini (kemungkinan besar, omong-omong, tidak).
Mereka menginstal Spinnaker, lalu meluncurkan Chaos Monkey, dan semuanya otomatis. Dan kami akan melakukan ini dan akan sangat efektif.
Bos bertanya, bagaimana dengan penguji. “Dan di sini, seperti di netflix -
kebebasan dan tanggung jawab . Para pengembang akan menulis tes sendiri. "
Dan kemudian Vasya jatuh sakit, karena dia melihat kartu namanya, dan di sana ...
Vasya mulai khawatir: terakhir kali ketika konsultan efisiensi datang, temannya, Natasha, yang bekerja sebagai administrator sistem, dipecat. Karena di mana-mana DevOps. Dan kemudian dia menyadari bahwa segera semuanya akan menjadi sangat buruk.
Tapi, tentu saja, lalu Vasya bangun.
Nama saya Baruch Sadogursky, saya adalah Advokat Pengembang di JFrog. Editor artikel ini secara khusus meminta untuk menulis beberapa paragraf sehingga tidak ada yang meragukan otoritas saya untuk memberi tahu kami bagaimana kami akan memecat penguji.
JFrog adalah startup Silicon Valley, penilaian terakhir kami adalah lebih dari satu miliar dolar. Kami secara resmi
unicorn dan kami melakukan otomatisasi DevOps. Produk kami -
Artifactory ,
Xray ,
Mission Control, dan sebagainya - alat untuk otomasi yang mengubah pabrik pengolahan daging Omsk menjadi netflix.
Saya sendiri bukan seorang tester, jadi, mungkin, saya akan mengatakan omong kosong. Dalam program konferensi, di mana laporan ini awalnya dibaca, ada sebutan khusus - gambar dengan koktail Molotov. Jadi, pembicara akan membawa semacam bid'ah, dan penonton akan terbakar. Ini tentang saya. Di Twitter, saya
@jbaruch . Seperti yang sudah Anda pahami, saya orang yang sangat ceria, saya harus segera mengikuti.
Saya punya berita untuk Anda: 80% pengembang menulis tes. Pengembang puas dengan semua jenis jajak pendapat. Nah, JetBrains senang dengan
Laporan Kondisi Ekosistem Pengembang yang sangat baik. Mereka bertanya siapa yang menulis tes unit.
- 59% menulis sendiri
- 11% melihat tes unit dalam kode mereka dan tidak tahu dari mana mereka berasal.
Secara total, 70% pengembang menggunakan tes unit. Ini luar biasa.
Ada studi yang lebih mendalam
oleh Hubstaff tentang pengujian dengan bantuan pengembang, ini sedikit lebih tua - 2014. Menurutnya:
- 85% pengembang menulis unit test,
- 15% tidak;
- 40% bekerja sesuai dengan metodologi pengembangan yang digerakkan oleh tes;
- cakupan yang baik - antara 34 dan 66 di antara 31% pengembang.
Sebagian besar pengembang mengklaim bahwa mereka juga menguji sesuatu dengan pena. Mereka berbohong, tentu saja, tetapi statistiknya adalah sebagai berikut.
Sejak 2011, kutipan favorit kami adalah:
"Setiap perusahaan adalah perusahaan perangkat lunak" . Termasuk, tentu saja, pabrik daging Omsk tempat Vasya bekerja. Di mana-mana ada perangkat lunak dan semua orang di perangkat lunak ini berusaha menghasilkan uang. Apa yang diinginkan perusahaan? Mendayung rampasan dengan sekop. Dari mana uang itu berasal? Dari pelanggan yang puas. Apa yang diinginkan pelanggan? Fitur baru. Dan kapan mereka menginginkan fitur baru? Sekarang!
Buku komik CEO Dilbert adalah bos kepala Vasya. Dia juga mendengarkan segala macam laporan menarik. Dia percaya bahwa jika pelanggan menginginkan fitur baru, maka mereka perlu lebih sering merilis fitur baru. Masuk akal. Untuk melakukan ini, kurangi gesekan dalam tim.
Haruskah saya melepaskan lebih sering? Misalnya, pada tahun 2017, Java beralih ke rilis yang lebih sering, karena semua orang menginginkan fitur dan, sepertinya, mereka harus dirilis lebih cepat. Setiap enam bulan Jawa baru keluar. Tapi tidak ada yang menggunakannya.
Kami baru-baru ini memiliki Joker, kami menjadi tuan rumah
Java Puzzlers di atasnya. Pada awalnya, kami selalu bertanya siapa yang berada di Jawa, untuk memahami potongan puzzle mana yang akan ditanyakan.
Gambar tidak berubah: 80%, atau bahkan lebih, masih duduk di Jawa 8, yang dirilis seratus tahun yang lalu. Tidak ada yang mengambil yang kesembilan, atau yang kesepuluh, atau yang kesebelas.
Untuk memahami mengapa mereka tidak menggunakannya, Anda perlu memahami bagaimana kami membuat keputusan tentang apakah akan mengambil pembaruan atau tidak. Mari kita bayangkan bagaimana kita menempatkan setiap pembaruan - sistem operasi, aplikasi, browser - apa pun yang Anda inginkan.
Bagaimana kami menempatkan pembaruan
Pemberitahuan tiba bahwa kami memiliki pembaruan, mari kita instal sistem operasi baru. Apakah kita menginginkan ini? Apakah ada sesuatu yang berguna di sana, atau apakah kita memiliki mesin kasir yang berjalan pada Windows 98 Embedded, dan kita tidak memerlukan yang lain?
Jika kita menginginkan pembaruan ini, pertanyaan selanjutnya adalah seberapa berbahayanya. Satu hal ketika Facebook memperbarui, dan kami telah menggulir, dan kami tidak akan bisa menyukainya. Ini adalah hal lain ketika sistem pendukung kehidupan dimatikan di rumah sakit. Jika kami tidak peduli dengan risikonya, mari perbarui. Jika ada risiko, maka pertanyaannya adalah memercayai orang yang meluncurkan pembaruan.
Tidak ada masalah dengan Apple sebelumnya: ada sistem operasi baru - mari kita ambil. Sebelumnya, dan sekarang kami takut diperbarui, tidak ada kepercayaan sebelumnya. Jika kami percaya - tidak ada masalah, kami memperbarui. Jika kami tidak percaya, Anda perlu menguji.
Kami melakukan apa yang disebut tes penerimaan. Di sini mereka memberi tahu kami: Jawa baru telah keluar, dan misalnya, kami adalah Baidu. Highload, 100.500 server, cloud, JVM di mana-mana. Kami mengambil beberapa bagian dari server, mulai mengubah Java. Sekelompok insinyur harus melakukan sesuatu dan memeriksanya. Sekali setiap tiga tahun itu normal, tetapi setiap enam bulan sekali ... Apakah Anda kacau? Kami hanya akan memeriksanya selama enam bulan. Tentu saja, kami tidak akan mengambil Java baru ini.
Karena itu, jika kita dapat memeriksa dengan cepat, ada baiknya memperbarui. Tetapi jika Anda harus memeriksa untuk waktu yang lama, maka Anda dapat melewati beberapa versi. Tidak ada yang akan terjadi jika kita merangkak dari versi kedelapan segera ke keduabelas.
Masalahnya adalah kepercayaan. Jika kami tidak percaya, maka memperbarui akan sulit. Jika masalah kepercayaan diselesaikan, maka tidak ada masalah dengan pembaruan. Entah kita memiliki fitur, atau kita tidak peduli.
Ambil Chrome. Dia, mulai dengan beberapa versi, memperbarui tanpa meminta siapa pun sama sekali. Risiko di sana kecil, tetapi masih ada. Namun di sisi lain, kami percaya mereka yang menulis Chrome. Lebih sering daripada tidak, ketika rilis Chrome baru keluar, tidak ada yang rusak di sana. Faktanya, kita tidak memiliki masalah dengan kepercayaan, dan kita berada di jalan ini.
Kami memiliki pembaruan, risiko tidak penting, kami percaya - kami memperbarui. Dan mereka tidak akan bertanya apakah kami mau atau tidak, karena itu kami akan selalu memperbarui. Inilah yang sedang dilakukan.
Bayangkan netflix meluncurkan pembaruan baru, dan sekarang kita dapat melewati tidak hanya teks dan screensaver, tetapi juga semua tempat yang membosankan. Pembaruan keren? Keren Apakah kita menginginkannya? Kami ingin. Apakah ini akan berhasil? Kemungkinan besar ya. Dalam kasus ekstrem, kita akan pergi ke YouTube, melihat kartun jika netflix rusak.
Pertanyaan tentang kepercayaan sangat penting. Bagaimana kita menyelesaikannya? Kata "kita" berarti dua pendiri JFrog, Fred Simon (Fred Simon), Yoav Landman (Yoav Landman) dan pelayan Anda yang rendah hati. Kami
menulis buku yang menyarankan cara mengatasi masalah ini.
Katakanlah kita membujuk CEO kita, dia membaca Liquid Software, dan sekarang dia mengerti mengapa dia membutuhkan pembaruan. Dia bertanya kepada konsultan bagaimana kita akan memperbarui lebih sering. Agile! DevOps! Apa itu DevOps?
Devops
Izinkan saya memberi tahu Anda sedikit teori tentang apa itu DevOps, karena kami menghasilkan uang darinya. Lihatlah gambarnya, kami memiliki grup, tim, departemen ini:
Ada pengembang, ada Ops - sysadmin yang mengambil apa yang ditulis pengembang dan melemparkannya pada prod. Dan di tengah-tengah antara pengembang Ops, ada QA yang sedang diuji. Artinya, para pengembang duduk, menulis, lalu membawanya ke penguji, mengujinya, menugaskannya ke administrator sistem, dan mereka mengunggahnya ke prod. Untuk ini, kami memiliki departemen yang terpisah.
Bahasa Rusia indah: departemen selalu
terpisah , ini adalah akar kata. Dalam bahasa Inggris, daya tarik ini bukan, oleh karena itu, departemen yang berbeda ini disebut
silo . Terjemahan terbaik dari kata ini ke dalam bahasa Rusia diberikan oleh Anton Weiss, yang merupakan
pembicara terbaik
di DevOops . Dia menyebut silo "sumur." Departemen berbeda - sumur dalam. Untuk memuat beberapa pekerjaan di sana, Anda harus turun, dan kemudian menarik keluar pekerjaan dari sana - bangkit. Paling mudah melakukannya dalam kelompok. Bagaimana kita mengelompokkan hal-hal yang kita dapatkan dari sumur?
Secara alami, dalam ember. Yaitu, kita memiliki "ember kerja". Para pengembang menulis sesuatu di sumur, kami memasukkannya ke dalam ember, membawanya keluar dari sumur, membawa ember ke penguji, dan menurunkannya ke mereka di dalam sumur.
Banyak tindakan yang dilakukan untuk mentransfer pekerjaan antara sumur yang berbeda. Saat kami mengelompokkan tugas untuk menghemat pekerjaan ini, kami mulai memuat ember ini. Tentu saja, semakin besar embernya, semakin kita akan menghemat proses transfer ini. Karena itu, ember dibuat besar.
Apa masalah dengan ember besar? Fakta bahwa mereka mengisi untuk waktu yang lama. Karena itu, ketika kita memiliki fitur penting yang perlu segera dirilis untuk produksi, karena ada garis pelanggan dengan uang, kita tidak dapat melakukan ini. Kami memiliki sumur, lebih baik kita kumpulkan lebih banyak di ember. Oleh karena itu, fitur-fitur penting menunggu semua omong kosong, selama kita memiliki cukup untuk mengisi ini dengan baik. Ini buruk, seperti yang Anda mengerti. Ini dipecahkan oleh fakta bahwa kita mendapatkan dan mencampur semua sumur ini.
Itu bukan salahku! Saya hanya mengambil tiga warna asli, meletakkannya di atas satu sama lain, dan warna ini ternyata. Sekarang kita semua melakukan segalanya. Kami memiliki insinyur seperti itu yang keduanya Shvets, dan Reapers, dan Dyuras. Ini adalah Dev, QA dan Ops. Dia menulis dan menguji kode, dan kemudian dia mengeluarkan semuanya pada produksi - seperti unicorn.
Apa masalah unicorn? Bahwa mereka tidak ada. Dan yang ada, mereka sudah lama dipekerjakan oleh netflix. Karena itu, tetap bagi kita untuk membuat campuran.
Campuran
Kami memiliki budaya yang sama, tujuan bersama. Kami meninggalkan sumur, kami semua bersama sekarang, tetapi kami masih memiliki spesialisasi yang mendalam. Pengembang masih lebih banyak pengembang daripada Ops, dan tester lebih banyak tester daripada pengembang. Meskipun demikian, mereka mengerti segalanya. Mereka mengerti apa yang mereka lakukan, mengapa mereka melakukannya dan bagaimana cara kerjanya.
Artinya, kita memiliki orang berbentuk T, "orang dalam bentuk huruf T".
Mereka memiliki spesialisasi yang mendalam, mereka tahu betul apa yang mereka lakukan. Mereka tahu betul dan segala hal lainnya juga. Misalnya, pengembang mengerti sedikit cara menguji dengan benar, bagaimana tata cara proses pada prod dan sebagainya.
DevOps adalah:
- Budaya yang kita miliki sekarang memiliki tujuan bersama, kita memahami apa yang kita lakukan bersama.
- Otomasi untuk rilis lebih sering.
Kecepatan dan kualitas
Mari kita bicara tentang asumsi bahwa ada hubungan terbalik antara kecepatan dan kualitas. Secara kasar, semakin cepat kita rilis, semakin buruk kualitasnya. Dan sebaliknya: jika kita tidak terburu-buru, kita akan punya waktu untuk menguji semuanya dengan seksama. Kami memiliki trade-off!
Untuk memahami apakah ketergantungan ini benar-benar ada, mari kita beralih ke makalah ilmiah dan berbicara tentang laporan
State of DevOps dari organisasi DORA. Saya sangat menyarankan Anda melihat laporan ini dengan seksama.
Seberapa banyak Anda bisa percaya padanya? Laporan itu mengatakan bahwa lebih dari lima ribu orang diwawancarai dalam lima tahun, dan pada 2018 hampir 2000 orang. Ini adalah sampel yang sangat besar, dan berdasarkan kuantitas seperti itu, misalnya, perkiraan dibuat dalam pemilihan AS. Karena itu, penelitian bisa dipercaya.
Selain itu, Nicole Forsgren, yang memimpin DORA, tidak seperti kita, adalah seorang ilmuwan, jadi semuanya serius di sana. Mari kita lihat apa yang dikatakan DORA tentang korelasi terbalik ini.
Pertama, mereka membagi semua responden menjadi tiga kelompok: berkinerja rendah, Berkinerja sedang dan berkinerja tinggi.
Selain itu, ada Elite. Ini Netflix (sebenarnya tidak, lihat
penafian di atas).
Seperti yang Anda lihat, proporsinya berubah. Secara alami, lima tahun yang lalu ada lebih banyak berkinerja rendah, sekarang ada lebih banyak berkinerja tinggi, karena kita sudah mulai memahami sedikit apa yang kita lakukan.
Ini entah bagaimana aneh. Ternyata Medium sedang diuji dengan pegangan lebih dari Rendah. Mengapa Ya, karena Rendah tidak menguji apa pun.
Mereka memiliki tren, grafik yang disebut kurva-J, yang menunjukkan korelasi yang sangat atau korelasi terbalik antara kecepatan dan kualitas. Dan di sini semuanya sangat aneh. Pada titik tertentu, kami melihat konfirmasi korelasi terbalik ini. Artinya, semakin cepat kami rilis, semakin rendah kualitasnya.
Tapi kemudian korelasinya tidak hanya tidak terbalik, itu langsung. Semakin cepat kami rilis, semakin baik kualitas kami. Katakanlah kita sedang dan uji dengan pena. Semuanya tidak buruk, tetapi perlahan, karena kami percaya bahwa jika kami tidak terburu-buru, maka kami akan menguji semuanya dengan lebih baik. Kemudian seorang konsultan dari DevOps datang dan berkata: “Itu dia, sekarang kita mengotomatiskannya. Dan kita tidak perlu penguji. Semuanya baik-baik saja. "
Tapi tanpa tes, itu omong kosong. Setelah kami menyadari bahwa setelah semua sesuatu perlu diuji, dan perlu untuk mengotomatisasi dengan benar, kami mulai mengotomatisasi dengan benar dan terus berjuang untuk ketinggian setinggi langit.
Kegagalan ini, di mana ada banyak bug, harus diatasi dengan benar. Bagaimana masuk ke dalamnya, saya pikir tidak ada pertanyaan. Pertanyaannya adalah bagaimana keluar dari situ.
Kita perlu menjawab pertanyaan tentang bagaimana hidup tanpa pengujian manual. Jawabannya sama dengan pertanyaan tentang bagaimana hidup tanpa mengatur server. Jelas mungkin. Apa yang berubah?
Sebelumnya, kami memiliki administrator sistem yang meluncurkan produk untuk prod. Dia duduk dan menunggu pengembang selesai menulis. Setelah itu, ia mengambil produk ini dan pergi untuk memasukkan CD-ROM dan menempelkan kabel. Apa yang terjadi pada semua orang saat ini? Semua orang menunggu. Ini adalah hambatan, colokan.
Kami menyelesaikan ini dengan otomatisasi yang tepat. Kami mengotomatiskan proses, kami memiliki pipa yang disiapkan sebelumnya, dan sekarang produk diluncurkan secara otomatis segera setelah selesai menulis. Apakah ini berarti bahwa sekarang orang-orang ini tidak diperlukan? Tidak. Ini berarti bahwa mereka diperlukan, tetapi mereka melakukan sesuatu yang lain.
Hal yang sama dengan pengujian. Kami memiliki penguji yang menguji produk. Mereka menunggu sampai mereka menulis suatu produk. Menulis - saatnya untuk menguji. Apa yang dilakukan orang lain saat mereka menguji? Mereka tidak melakukan apa-apa, mereka menunggu. Bagaimana kita mengatasi ini?
Sekali lagi, otomatisasi yang tepat. Kami sedang membangun suatu proses. Dia akan menjamin kualitas produk. Kita dapat menyiapkan proses ini terlebih dahulu, dan kemudian produk diuji secara otomatis.
- Ini membutuhkan, misalnya, tim lintas fungsi . Di sini kami bangun dari sumur dan duduk bersama. Sekarang kami memiliki singa berbaring dengan domba, dan penguji bekerja sama dengan programmer.
- Kami melakukan pengujian berkelanjutan . Ini seperti pengujian otomatis, tetapi lebih cerdas.
- Dalam proses pengembangan, "pengujian otak" dilakukan. Ini adalah istilah yang lebih benar daripada "pengujian manual," karena pengujian manual adalah tentang otak, bukan tentang tangan. Terima kasih atas istilah ini kepada saudara kembarku di Facebook Alexey Vinogradov. Tes otak terjadi selama proses pengembangan. Begitu sesuatu muncul, Anda sudah dapat memeriksa alirannya, Anda sudah dapat memahami cara kerjanya, Anda sudah dapat mulai menguraikan beberapa kasus sudut, yang kemudian akan kami otomatisasi.
- Kami sekarang mengikuti pengembang. Jika dia tidak menulis tes pada awalnya, kita bisa menamparnya. Ini adalah Test Driven Development .
- Umpan balik instan itu penting. Kita harus memiliki saluran pipa yang segera memberi tahu kita segera setelah ada masalah. Karena kita harus segera pergi dan memperbaikinya.
- Partisipasi dalam desain . Kebetulan Anda melihat sesuatu dan berpikir bagaimana kita sekarang akan menguji omong kosong ini. Tapi permisi, di mana Anda saat semua orang memutuskan akan ada apa-apa? Anda datang ke pertemuan dan mengatakan bahwa Anda tidak setuju, Anda harus melakukannya secara tidak sadar. Anda harus terlibat dalam desain untuk memastikan bahwa Anda dapat mengujinya nanti.
- Alat, memanfaatkan, berdiri - apa yang banyak dari Anda lakukan hari ini tidak ke mana-mana. Sebaliknya, ini akan lebih. Oleh karena itu, seseorang harus menulis ini.
- Rekayasa kekacauan . Anda selalu bermimpi meluncurkan Chaos Monkey dalam produksi, terutama jika Anda memiliki jaringan ATM di Windows 95. Inilah kesempatan Anda.
- Dan akhirnya, Anda perlu mengajar orang bebal untuk merancang tes . Kami memutuskan bahwa pengembang setidaknya mengklaim bahwa mereka menulis tes. Sekarang biarkan mereka menulis ujian, hanya kita perlu mengajari mereka bagaimana melakukannya. Siapa yang akan mengajar mereka, bagaimana mereka tahu cara menulis tes? Hanya kamu. Tidak ada orang lain
Tetap mengotomatiskan semuanya. Bahkan, kami dapat mengotomatisasi pengujian. Masalahnya adalah Anda dapat mengotomatisasi bagian tertentu.
Anda semua tahu lelucon ini tentang bagaimana tester memasuki bar, memesan bir, memesan 0 bir, memesan bir 99999999999, memesan kadal, memesan -1 bir, dan memesan ... Ini adalah bug, karena harus asdfgh, bukan yang ini, bukan yang ini omong kosong.
Mudah otomatis. Jelas bahwa tidak ada masalah dalam angka sama sekali. Kami menempatkan pengacak, dia melakukannya untuk kami. Bahkan kadal hari ini sudah dapat dihasilkan di sana. Ini membingungkan - saya harap Anda mendengarnya, karena saya membacanya kemarin.
Tapi kemudian klien datang, bertanya di mana toilet itu dan segalanya, bilah terbakar, semua orang mati dan semua itu. Ini tidak bisa otomatis. Ya, semampu Anda, tetapi pertama-tama Anda harus memahami dengan kepala Anda bahwa bar tidak hanya di tempat minuman, tetapi juga di mana toilet berada. Selain itu, kemungkinan klien ingin pergi ke toilet sedikit lebih banyak daripada kenyataan bahwa ia akan memesan kadal. Oleh karena itu, lebih penting untuk memeriksanya, tetapi untuk ini Anda perlu memahami bisnis, Anda perlu memahami produk, dan hanya orang-orang dengan kepala yang dapat melakukan ini.
, , , . DevOps. , . T- — , .
, - . « », , . , , , . , Selenium . , .
, .
— . , , . . , , Ops- , , , , , , , .
Developers in test — , , . , . , ; — , ; TDD , , , , . , , .
« ». , , , , , — . , , , , , , , , , , Continuous Testing .
end-to-end , . , , DevOps, .
, - , . , 70- : « DevOps, ». , , .
. -, , , , , . : ( EVP Engineering, SignalFx) , , .
70- . . , , . , . , , , , . , , , , — , netflix .
, , , , , , , , , . . , .
, . . « , », — , , .
«, — . — : , , , . , , , , , . . , - , . ? Artifactory , ?!».
, — , . , . ? !
DORA: , , , .
New Work. , New Work Low — 30%, Medium — 40%, High Elite — 50%. ( , Low) , , .
.
Heisenbug 2018 Moscow, — 17-18 Heisenbug. , . , ( ).