Jadi Pada tahun 2018, di Heisenbug (Moscow Testing Conference), Baruch Sadogursky (Pengembang Advokat di JFrog) menyajikan keynote yang menarik, di mana ia berbicara tentang ide-ide dasarnya tentang ke mana harus pergi. Pada 2019, di Heisenbug yang sama, sekuel laporannya diadakan tentang BAGAIMANA untuk mencapai tujuan ini. Di satu sisi, saya ingin mendukung versi gerakan B. Sadogursky, yang disiarkannya, tetapi pertama-tama saya masih tidak mengetahuinya, dan kedua, saya akan berani merumuskan visi saya dan menggambarkan jalur pribadi saya berdasarkan pengalaman saya sendiri.
Diberikan
Untuk konteks (itu fiktif dan kebetulan dengan kasus nyata adalah kebetulan murni), kami akan menghadirkan beberapa perusahaan vendor TI regional dengan unit pengembangan yang cukup besar. Dalam unit ini ada fungsi pengujian, yang terdiri dari 30 orang bersyarat dari berbagai tingkat pengetahuan dan keterampilan.
Perusahaan
Perusahaan yang disajikan memiliki beberapa produk yang telah di rilis untuk waktu yang lama dan tahap awal pengembangan mereka selesai lebih dari 7-8 tahun yang lalu. Mengingat bahwa perusahaan adalah vendor, perusahaan memantau produknya dan secara teratur mengembangkannya, tetapi tidak membuat ulang dari awal. Ini berarti bahwa produk tersebut mengandung sejumlah besar kode warisan, solusi teknologi dan arsitektur "kuno". Pengujian pada produk-produk ini pada tahap awal tidak dipertimbangkan, sebelum pengembangan mereka dilakukan pada prinsip "lebih cepat, lebih cepat dan dalam produksi", tetapi hari ini ada sejumlah besar pengujian manual - baik regresi maupun pengujian fungsi baru. Secara ideologis, pengembangan produk dilakukan di bawah tekanan kebutuhan bisnis sehingga tidak ada waktu untuk memikirkan kembali ideologi dan memperbaiki produk itu sendiri. Ini dilakukan hanya pada saat semua orang mengerti bahwa ini tidak akan bekerja lebih jauh dari kata "sepenuhnya".
Selain produk lama, perusahaan ini mengembangkan solusi yang sama sekali baru menggunakan teknologi terbaru dan pendekatan arsitektur. Tapi di sini, tidak semuanya lancar, karena tekanan umum dari kebutuhan bisnis tidak surut. Pengujian pada proyek semacam itu sudah ada pada tahap awal pengembangan, namun, "solusi manual" masih berlaku, yang memberikan hasil tercepat dan memungkinkan pengembang untuk menulis kode produk secara eksklusif tanpa memikirkan bagaimana itu akan diuji.
Fungsi tes
Sekarang beberapa kata tentang struktur: seperti yang saya katakan, sekitar 30 orang adalah bagian dari fungsi pengujian. Dari jumlah tersebut, 17-19 adalah tautan junior dengan pengalaman di bidang ini tidak lebih dari 1 tahun. Seringkali, ini adalah orang-orang tanpa pendidikan teknis, tetapi dengan "mata menyala" dan keinginan besar untuk bekerja di bidang TI (mengapa mereka memiliki keinginan ini adalah topik yang terpisah untuk diskusi). Sisa 11-13 orang adalah manajer senior dan menengah: 3-4 orang mewakili senior dan 7-10 orang - rata-rata. Seluruh fungsi pengujian didistribusikan di 13-15 produk / proyek berbeda dengan berbagai tingkat partisipasi, kompleksitas dan keterlibatan.
Budaya
Ini adalah pengantar terakhir.
Sayangnya, masih ada beberapa kesalahpahaman tentang nilai yang dapat dibawa fungsi pengujian. Ini karena hasil pekerjaan dalam bentuk (misalnya) fitur baru dapat dilihat oleh semua orang, dapat dimengerti dan praktis “nyata” - ketika diterapkan, kualitas produk secara keseluruhan meningkat, dan setidaknya menjadi tidak memalukan untuk produk perusahaan. Pada saat yang sama, ada beberapa sekte pengembang di mana pernyataan berikut ini benar: "Pengembang adalah pemain utama, dan jika dia tidak ada, maka sisanya dapat dipecat", serta "Pengembang adalah sumber daya yang mahal dan mereka harus menulis hanya kode produk dan tidak terganggu oleh kegiatan yang tidak penting ". Berdasarkan pernyataan ini, "budaya" tertentu telah terbentuk di perusahaan ini.
Pernyataan masalah
Dan seperti kata mereka, apa masalahnya? Mengapa mengubah sesuatu jika semuanya berfungsi seperti itu? Mengapa pindah ke suatu tempat jika ada model yang berfungsi, dan ia membawa dividennya?
Pertanyaan-pertanyaan ini secara logis dapat muncul pada seseorang yang membayar untuk seluruh perkembangan. Tetapi ada 3-4 orang dalam fungsi pengujian yang menganggap diri mereka diremehkan, yang melihat laporan pertama B. Sadogursky dan tidak hanya yang melihat sisi berlawanan dari situasi dan ingin mengubah apa yang terjadi menjadi lebih baik dan, dengan demikian, menyelesaikan beberapa masalah sakit.
Berikutnya - fantasi dan saran murni berdasarkan bahan dari berbagai penulis dan spesialis di bidang TI.
Solusi (mungkin)
Mari kita mulai dengan mendefinisikan tujuan dan sasaran dalam kerangka perubahan. Kami akan secara sadar menghilangkan sisi pedagang dan tidak akan mengangkatnya, ini adalah topik yang terpisah untuk holivar, terutama karena ia memainkan peran penting dalam situasi perusahaan saat ini.
Kami menggambar masa depan. Untuk apa kita berjuang?
Pertama-tama, kami ingin dalam waktu singkat mendapatkan kumpulan produk (!) Berkualitas tinggi yang akan mendatangkan keuntungan yang cukup tinggi. Anda perlu memahami bahwa "menguntungkan" tidak berarti "kualitas".
Apa yang perlu kita lakukan untuk mencapai tujuan? Pertama-tama, saya mengusulkan untuk mempertimbangkan jalur dari sudut pandang teknologi, dan bukan perdagangan. Untuk mencapai tujuan tersebut, perlu untuk fokus pada fakta bahwa produk harus memenuhi kebutuhan pengguna akhir, sambil memiliki biaya rendah baik untuk pengembangan fungsi baru dan untuk pemeliharaan yang sudah dalam produksi. Artinya, selama pengembangan, kita harus: a) memahami vektor gerakan dengan jelas, b) membuat produk cukup andal sehingga tidak ada masalah dengan operasinya, secara sederhana, pastikan tidak ada kesalahan saat bekerja dengan produk. Berdasarkan hal ini, kita harus memiliki apa yang disebut Kebijakan Nol Bug untuk semua produk, yaitu pengujian kami, sebagai suatu proses, harus memberi kami jaminan tidak adanya kesalahan produksi.
Aspek kedua adalah fokus pada hasil akhir dari seluruh proses pengembangan, yang akan memungkinkan kita untuk tidak mengembangkan apa yang tidak dapat digunakan pengguna atau tidak bisa mengerti BAGAIMANA menggunakannya. Kami hanya menyebutkan bagian kedua secara sepintas, karena topiknya sangat luas, tetapi tidak akan berhasil tanpa menyentuhnya.
Jadi, tujuan kami adalah:
" Cepat, efisien, dan untuk uang yang masuk akal " (murah, kemungkinan besar, Anda tidak dapat segera melakukannya).
Sekarang mari kita coba menghubungkan apa yang diberikan dengan tujuan yang dimaksud.
Cepat Ya, itu mungkin, tetapi kami membahayakan kualitas: proses penjaminan kualitas manual yang ada akan dapat memberikan kecepatan eksekusi yang cukup hanya pada produk kecil dengan cerita pengguna yang sederhana. Selain itu, profil perusahaan adalah pengembangan solusi yang agak rumit untuk mengotomatisasi proses bisnis. Kesimpulan - "cepat" tidak berfungsi, karena kerja manual a priori pada volume besar akan kalah dari solusi otomatis apa pun.
Fokus pada hasilnya . Itu mungkin, tetapi mengharuskan peserta untuk menghasilkan nilai perendaman yang cukup dalam di area subjek dan waktu yang dihabiskan untuk menyampaikan nilai ini kepada pelaksana akhir. Pada saat yang sama, para pelaku adalah pengembang yang, sebagai bagian dari salah satu pernyataan, harus menghabiskan waktu maksimum menulis kode tanpa terganggu oleh lingkungan.
Dari semua ini, maka untuk menyelesaikan masalah utama, perlu melibatkan tidak hanya pakar QA, tetapi juga pengembang dalam proses pengujian. Pada saat yang sama, untuk meningkatkan kecepatan pengiriman nilai, perlu untuk lebih hati-hati mempertimbangkan proses otomatisasi pengiriman dan otomatisasi verifikasi dari apa yang disampaikan.
Apa yang perlu dilakukan untuk menyelesaikan masalah utama?
Menurut pendapat saya sendiri, berdasarkan pengalaman, dibutuhkan:
- Benamkan pengembang lebih banyak dalam sasaran produk dari produk mereka;
- Untuk meyakinkan bisnis bahwa biaya otomatisasi penting dan memberikan manfaat ekonomi lebih besar untuk semua biaya ekonomi.
- Adalah bijaksana untuk mengotomatisasi semua yang dapat diotomatisasi, untuk mengecualikan pekerjaan manual dari proses pengiriman nilai secara maksimal.
- Menerapkan Kebijakan Nol Bug, yang tanpanya pengguna akan menghadapi masalah yang mengusir produk kami. Ngomong-ngomong, contoh sukses "DoDo" menunjukkan bahwa ini cukup dapat dicapai.
Apa yang perlu kita lakukan untuk meyakinkan peserta tentang perlunya mengubah sikap dan pandangan dunia?
Pengembang
Bagaimana cara berdebat - mengapa mereka perlu melakukan hal lain selain pemrograman kode fungsional favorit mereka? Saya mengusulkan untuk fokus langsung pada masalah yang muncul dengan organisasi seperti itu. Ada beberapa di antaranya:
- Mengembangkan apa yang tidak akan dibutuhkan siapa pun. IMHO, ini adalah salah satu masalah pertama. Para pengembang melakukan sesuatu, menjaga kepercayaan bahwa mereka melakukannya dengan benar, tetapi pada akhirnya mereka mendapatkan hasil yang salah yang diinginkan pengguna akhir. Mengapa Karena tugas dan masalah tidak dikirimkan kepada mereka oleh mereka yang pada akhirnya menggunakan produk, tetapi oleh manajer atau pelanggan yang kemudian tidak menggunakan produk ini. Mengapa ini terjadi? Semua orang memiliki pandangan berbeda. Jika pengembang itu diajukan bukan semata-mata teknis, tetapi tugas fungsional dengan deskripsi hasil pada output (dan bahkan lebih baik - dengan deskripsi masalah yang harus diselesaikan tugas ini), maka akan ada lebih banyak pemahaman tentang hasil dan, akibatnya, jumlah kasus mengembangkan sesuatu yang tidak perlu akan berkurang. Ya, ini adalah kebenaran terkenal, tetapi masalahnya masih belum hilang, perlu diselesaikan dengan bisnis, membenarkan dengan cara yang sedikit berbeda perumusan tugas untuk pengembangan. Tentang cara menyampaikan ini ke bisnis - lebih lanjut.
- Kebutuhan untuk beralih antar konteks. Seringkali, dalam proses pengembangan dengan adanya pengujian manual, hasil pengujian terlambat, sebagai akibatnya, pengembang harus terganggu dengan menyelesaikan masalah yang muncul sebagai hasil pengujian. Apa yang mencegah pengembang memeriksa setelah menerapkan hasil mereka sendiri? Ada dua poin. Yang pertama adalah kurangnya pengetahuan dan keterampilan di bidang jaminan kualitas. Yang kedua - pengembang sering berpikir bahwa ini bukan pekerjaan mereka, dan, akibatnya, tidak ingin melakukannya. Dalam salah satu podcast awal RadioQA, ada masalah lengkap tentang pengembangan tanpa penguji, yang menjelaskan secara terperinci efek ini dan alasan "keengganan" ini.
Bagaimana pengujian akan membantu pengembang atau bagaimana membantu mereka memecahkan masalah yang ditunjukkan?
- Dapatkan informasi lebih lanjut tentang bidang subjek atau tujuan tugas yang harus diselesaikan. Apa saja pertanyaan khas yang diajukan pengembang saat memperkenalkan tugas? "Bagaimana melakukan ini?" "Dan apa yang perlu dilakukan di sini?" "Dan bagaimana melakukan ini terlepas dari fakta bahwa hanya ini yang diketahui?" "Dan bagaimana ini akan mempengaruhi fungsi itu?" Semua pertanyaan ini ditujukan untuk mengklarifikasi pelaksanaan tugas , dan tidak memahami variabilitas tugas ini. Apa yang dilakukan seorang penguji ketika dia berkenalan dengan deskripsi baru dari suatu fungsi baru? Dia juga mengajukan pertanyaan, tetapi dengan cara yang sedikit berbeda: "Apa yang akan terjadi jika?" "Mengapa harus begitu?" "Apa yang harus saya dapatkan pada akhirnya?" "Apa yang saya miliki di awal?" "Bagaimana ini harus dikaitkan dengan itu? " Artinya, hampir semua pertanyaan ditujukan untuk mengidentifikasi dengan tepat skenario pengguna dan memahami hasil dari fungsi ini.
Apa yang penting Dengan mengajukan tidak hanya mengklarifikasi pertanyaan (bagaimana menerapkan), tetapi juga pertanyaan yang bertujuan memahami hasil akhir, Anda dapat memperoleh lebih banyak informasi tentang tugas, membuat metode yang diharapkan tidak hanya akrab, tetapi juga lebih sederhana dan lebih efektif. Dalam skenario positif, ini akan membantu untuk tidak menulis kode tambahan atau untuk membuat apa yang dibutuhkan pengguna akhir, yang merupakan apa yang kita butuhkan.
Seseorang akan bertanya: "Mengapa saya, sebagai pengembang, harus tertarik, atau saya harus memikirkannya?" Kami akan menjawab - agar tidak berkembang "ke meja". Hasil survei pengembang di lingkungan saya menunjukkan bagaimana demotivasi saat Anda melakukan sesuatu, tetapi jangan lepaskan (letakkan di rak).
- Pertanyaan lain: "Mengapa saya, sebagai pengembang, perlu melakukan pengujian jika kami memiliki penguji?" Atau "Mengapa saya perlu mengembangkan beberapa kode tambahan yang tidak memenuhi tugas produk yang ditetapkan?" . Di sini Anda dapat menawarkan sesuatu yang lain. Tes otomatis pada dasarnya adalah kode yang sama yang mematuhi hukum pemrograman yang sama dengan sedikit nuansa. Ketika seorang pengembang bekerja dalam kerangka produk besar, ia terpaksa mematuhi aturan pengembangan dan teknologi yang dipilih dalam produk, dan menulis dalam bahasa yang ditulis produk ini untuk menggunakan kerangka kerja yang digunakan dalam produk ini. Tidak perlu melakukan ini saat menulis tes: tidak ada yang memaksa Anda untuk menggunakan bahasa yang sama atau pendekatan yang sama: saat menerapkan pengujian otomatis, Anda dapat dengan mudah mencoba bahasa yang sama sekali baru dan mendapatkan pengalaman dengannya.
Ada satu aturan sederhana yang dipatuhi pengembang ketika menulis kode produk - optimalisasi maksimal dari apa yang Anda lakukan, konsumsi sumber daya yang optimal, kinerja optimal, (lebih disukai) penggunaan kembali maksimum dan sebagainya. Saat mengembangkan tes otomatis, ada juga aturan, ada template, ada kerangka kerja, tetapi mereka berbeda. Tugas mereka adalah untuk memungkinkan mereka membuat kode uji secepat mungkin, yang akan berhasil ... Itu hanya akan berfungsi.
Optimalisasi dan kecepatan eksekusi dalam autotests adalah poin sekunder dan tidak dapat segera diingat. Jadi jika Anda tiba-tiba ingin mencoba dengan Kotlin, Java, atau bahasa lain, tetapi proyek ini ditulis dalam bahasa yang sama sekali berbeda dari yang Anda inginkan (misalnya, dalam C #), Anda dapat mengubahnya ke bahasa yang Anda inginkan dengan mengembangkan autotes.
- “Bagaimana saya menguji? Saya tidak mengerti apa-apa tentang ini. Saya hanya seorang pengembang. " Di sini, penguji akan datang untuk menyelamatkan, atau lebih tepatnya insinyur QA yang sangat menyadari semua teknologi di mana produk utama ditulis. Berkat pengetahuan mereka, mereka dapat membantu mendidik pengembang tentang bagaimana dan apa yang harus diuji, bagaimana memilih data yang tepat, apa yang harus dilakukan oleh pembuat data untuk meminimalkan risiko berdasarkan jenisnya dan apa yang tidak perlu Anda perhatikan sama sekali. Dalam tandem seperti itu, penguji memanfaatkan pengetahuan mereka, dan pengembang tidak melakukan pekerjaan yang tidak perlu dan tidak perlu.
- “Tapi bagaimana dengan kecepatan? Dia menderita! ” Ya, dia akan menderita pada tahap awal pengembangan proyek, dan ya, tentu saja, dari awal hingga terjun ke otomatisasi penuh itu mahal. Apa yang harus dilakukan agar biayanya optimal? Minimal, kita harus memahami dengan jelas bagaimana dan apa yang harus diotomatisasi. Dan juga masuk akal untuk tidak menutup segala sesuatunya dengan tes dan mengusahakan cakupan 100% dari kode, tetapi untuk melakukannya berdasarkan pada model risiko. Insinyur QA akan melakukan hal yang sama.
- "Kecepatan! Kami ingin mendapatkan pengiriman yang cukup cepat. Kami juga ingin dipercaya dan produk kami bebas dari kesalahan! ” Di sini saya mengusulkan untuk mengubah pendekatan pembangunan. Jika dulunya modis untuk menjalankan semuanya dalam mode debug secara lokal, sekarang sering untuk aplikasi serius dibutuhkan beberapa infrastruktur untuk bekerja. Di sinilah semua tren baru tentang dockereization dan penerapan berbagai tegakan sangat cocok. Hal lain yang penting: bahkan pada tahap pengembangan pertama, Anda perlu berpikir tentang bagaimana itu akan dikirim ke kios kerja, yaitu, tidak hanya menyebarkan semuanya dengan tangan, tetapi mengatur proses penyebaran otomatis. Apa yang akan memberi kita? Ketika tiba saatnya untuk pengiriman ke produksi, itu akan cukup bagi kita untuk hanya mengubah titik perhitungan, dan tidak mengkonfigurasi seluruh proses dari awal. Apa yang akan memberi pengembang ini? Lebih percaya diri bahwa ia melakukan segalanya dengan benar, karena skrip pengiriman telah diperiksa lebih dari satu putaran, dan seharusnya tidak ada masalah dengan rilis.
Bisnis
Tetapi bagaimana dengan bisnis? Kenapa dia harus tertarik pada transformasi ini? Mengapa masuk akal baginya untuk berinvestasi dalam pendekatan ini? Membangun penjelasan, saya akan pergi dengan cara yang sama. Masalah apa yang dimiliki bisnis ini sekarang, masalah apa yang harus Anda selesaikan ketika bekerja di bidang TI dan ketika mengembangkan produk teknologi tinggi? Sekali lagi, saya akan mengandalkan pendapat saya di sini:
- "Apa yang paling tidak sesuai dengan bisnis ini?" Seringkali, pengembangan lupa bahwa produk tersebut tidak hanya harus dikembangkan, tetapi juga dijual, yang memerlukan serangkaian tindakan yang cukup besar, termasuk mempersiapkannya untuk masuk ke pasar. Melakukan ini setelah produk dikembangkan adalah kegagalan yang dijamin, itulah sebabnya sebagian besar pekerjaan menyiapkan saluran penjualan dan mempromosikan produk baru dimulai hampir pada saat pengembangan dimulai.
“Apa yang terjadi jika pengembangannya terlambat untuk tanggal rilis? Atau apakah pengembangan itu akan menghasilkan produk berkualitas tinggi yang tidak memadai di pasaran? ” Akan ada kerugian. Dan tidak hanya materi, tetapi juga reputasi. Penting bagi bisnis untuk memastikan bahwa pada saat penjualan mulai, produk tidak hanya akan siap, tetapi juga akan berkualitas baik. Jika ada tahap-tahap pengujian manual dalam proses pengembangan, mau tidak mau harus dilakukan penjadwalan ulang untuk tenggat waktu, atau untuk memperhitungkan risiko gangguan pada tahap-tahap ini. Dimungkinkan untuk memprediksi faktor manusia, tetapi sulit dan (menurut saya) tidak lebih murah.
- "Apa lagi yang dipedulikan bisnis?" Tentu saja, dia khawatir tentang investasi modal dalam pengembangan. Tetapi investasi modal, sebagian besar, meskipun banyak, dilakukan pada tahap awal, yaitu Sebelum rilis, atau setidaknya sebelum rilis, biaya tidak diimbangi dengan penjualan. Seiring dengan investasi modal, ada juga biaya operasional, yang mulai berkontribusi pada tahap operasional dan penting untuk mencoba meminimalkannya sebanyak mungkin.
"Mengapa otomatisasi cukup mahal (dalam hal pengeluaran modal) dalam kasus ini menang sehubungan dengan pendekatan manual?" Pendapat saya adalah faktor yang jelas. Otomasi adalah perkembangan yang sama. , . , , , , . , . Mengapa ini penting? . , , « , , , » , , .
- — . , . , , . , .
? , - . . , , , . , , , , , . , .
, « ». ?
- , , , , . : X Y , , , X Z , Z < Y. : , , ( ) .
- — QA-. , «» . , QA- , , , . : , , , , , .
— , . . , , , , , , , , , . .
- — . , , . , , , , . , QA-. , . , , «» — , , , . , , .
- , , — (, , - ). . , . , , , , , (), .
— , . , , , , . , , , « » — . , .
. .
? , 90% , 60% , .
, . , , - . , . , , , , — , .
«» , . «» , QA-. , — . , , ShiftLeft- QA- , - , QA- .
- . , . .