Terlepas dari kenyataan bahwa teknologi unit testing telah ada selama 30 tahun (Kent Beck menulis artikel “Simple Smalltalk Testing: With Patterns” pada tahun 1989), tidak semua programmer memiliki teknologi ini dan tidak semua perusahaan menjadikan pengujian otomatis sebagai bagian dari budaya perusahaan mereka. . Meskipun ada keuntungan nyata dari pengujian otomatis, resistensi perilaku masih cukup kuat. Siapa pun yang mencoba menerapkan tes otomatis tahu bahwa selalu ada beberapa alasan mengapa ini tidak dapat dilakukan.
Dari pengalaman pribadi saya menerapkan metode pemrograman yang andal di perusahaan saya, di perusahaan yang saya berkonsultasi, berkomunikasi di konferensi, dan juga dari sumber yang tersedia untuk umum, saya telah merumuskan keberatan dan penolakan yang khas yang menghambat penerapan budaya pengujian otomatis.
Saya mengelompokkan semua keberatan ke dalam piramida pemrograman yang andal, yang meliputi empat level:
- Budaya profesional (tingkat tertinggi, dasar pemrograman yang andal) adalah seperangkat norma, aturan tidak tertulis, keyakinan karyawan yang membimbingnya dalam pekerjaannya. Sebagai contoh: "Mengirim kode yang ditemukan oleh tes ke repositori buruk", "Membungkam tentang kesalahan yang ditemukan dalam kode itu memalukan".
- Manajemen adalah prosedur, kebijakan, aturan yang diadopsi oleh organisasi, serta kehendak (keputusan) para pemimpin. Misalnya: “Setiap fungsi aplikasi yang dikembangkan harus melewati kode ulasan. Tanpa pengecualian! "
- Metode adalah pendekatan ilmiah, metode untuk memecahkan masalah tertentu. Misalnya: "Jika fungsi aplikasi sulit untuk diuji, Anda perlu meningkatkan testabilitas aplikasi dengan menerapkan templat Injeksi Ketergantungan."
- Teknologi (tingkat terendah) adalah bahasa pemrograman, perpustakaan, kerangka kerja, alat. Misalnya, JUnit, Selenium, XCTest dan sebagainya.
Mengapa pembagian seperti itu diperlukan? Karena masalah satu tingkat diselesaikan dengan metode tingkat yang sama atau dengan metode tingkat yang lebih tinggi. Misalnya, jika tidak lazim bagi organisasi untuk menulis tes otomatis (masalah budaya profesional), maka masalah ini tidak dapat diselesaikan dengan menjelaskan proses bisnis pengujian secara terperinci (level "manajemen") atau dengan memasang kerangka kerja modern (level "teknologi"). Saya memberikan jaminan bahwa dalam seminggu tidak ada yang akan menulis tes, terlepas dari proses bisnis yang disetujui.
Keberatan budaya
“Program saya tidak rusak. Saya tidak melihat perlunya pengujian. "
Saya mendengar pernyataan ini dari para pemula atau programmer yang terlalu percaya diri.
Tentu saja, sekali fungsi tertulis tidak dapat rusak dengan sendirinya. Tetapi di sini penting untuk dipahami bahwa seiring waktu, program mungkin memerlukan dukungan, pengenalan fungsi baru atau penambahan fungsi yang ada. Kompleksitas program - jumlah kelas dan ketergantungannya - cukup besar, dan akhirnya, setelah membuat fungsi baru atau meningkatkan yang sudah ada, kesalahan akan terjadi cepat atau lambat. Tes otomatis akan mendeteksi regresi semacam itu.
Selain itu, seringkali keberatan semacam itu dapat didengar dari programmer pemula yang tidak memiliki konsep pengujian. Misalnya, hanya kerusakan yang dianggap gangguan, bukan kesalahan fungsional.
Pada salah satu wawancara yang saya lakukan, dialog berikut berlangsung:
- Apakah Anda memiliki keterampilan pengujian otomatis?
- Tidak, saya menulis program sederhana, tidak ada yang perlu dipecahkan.
- Apa motivasi Anda untuk berganti pekerjaan?
- Saya ingin menulis aplikasi yang kompleks.
Saya tahu betul bagaimana ini berakhir. Programmer dipercaya untuk mengembangkan program yang lebih kompleks, tetapi ia tidak tahu metode pengujian otomatis, ia tidak dapat menguji aplikasi secara kualitatif, dan ia tidak dapat mengatasi skala proyek, yang akan mengarah pada gangguan proyek, pembengkakan biaya pengembangan, hilangnya reputasi. Karena saya pribadi mengelola proyek, di mana saya tidak dapat mengatasi skala proyek dan gagal justru karena kurangnya tes otomatis.
Keengganan untuk bertanggung jawab atas kualitas kode, untuk pengujian.
Tes otomatis adalah satu-satunya sumber informasi operasional dan obyektif tentang kualitas sebenarnya dari produk perangkat lunak. Dengan kata lain, programmer selalu memiliki pengawas di belakangnya, yang dapat melaporkan kepada manajemen kapan saja tentang seberapa baik programmer melakukan pekerjaannya. Tes otomatis memungkinkan Anda untuk menghubungkan produktivitas pekerjaan tidak dengan tiket tertutup di Jira, tetapi dengan kualitas produk perangkat lunak yang sebenarnya. Dan di sini Anda sudah perlu memikirkan cara menulis dengan andal sehingga setiap perubahan kode tidak merusak fungsi yang ada. Sehingga setiap fungsi baru berfungsi tidak hanya dalam skrip, ketika semuanya baik-baik saja, tetapi juga memproses kesalahan dengan benar.
Tanggung jawab adalah komitmen sukarela untuk memastikan hasil kerja yang positif. Karyawan menerima kewajiban ini berdasarkan karakter dan pendidikannya. Sayangnya, karena krisis budaya dan profesional, tidak setiap programmer siap untuk mengambil kewajiban seperti itu.
"Tulis sekarang juga tanpa kesalahan"
Orang-orang yang tidak begitu akrab dengan cara kerja pengembangan perangkat lunak mungkin memiliki sikap negatif terhadap pengembang yang menyebutkan beberapa jenis kesalahan.
- Mari kita bahas aplikasi dengan tes otomatis.
- Kenapa?
- Untuk memastikan semuanya bekerja dengan benar dan tidak ada kesalahan.
- Apakah Anda menulis dengan kesalahan? Apakah Anda memiliki kualifikasi rendah? Menulis segera tanpa kesalahan.
"Ya, tapi semua orang membuat kesalahan ..."
- Tetapi perusahaan XYZ berkata kepada seorang teman bahwa mereka memiliki programmer top yang menulis tanpa kesalahan!
Dengan demikian, pengembangan tes sulit untuk "dijual" kepada pelanggan yang secara teknis tidak paham. Akibatnya, manajemen terpaksa mengembangkan proyek tanpa tes otomatis, yang mengarah ke masalah yang diketahui.
Keberatan Manajemen
“Dengan tes, menulis sebuah program dua kali lebih lama. Kami tidak akan memenuhi tenggat waktu. ”
Sepintas, tesis ini tampak adil. Sangat penting untuk menghabiskan waktu menulis tes programmer. Tetapi programmer dan manajemen tidak memperhitungkan bahwa total waktu pengembangan produk tidak hanya mencakup pemrograman, tetapi juga debugging dan dukungan, serta biaya yang sangat besar untuk pengujian regresi manual setelah melakukan koreksi.
Tes otomatis memiliki beberapa fungsi:
- Memeriksa
1.1. Tes memverifikasi bahwa objek uji berfungsi dengan benar.
1.2. Tes memeriksa kualitas pekerjaan programmer: apakah tugas diselesaikan, apakah ada efek samping dalam bentuk regresi. - Mendiagnosis Tes diagnostik dapat secara signifikan mengurangi waktu untuk mencari cacat. Tes memungkinkan Anda untuk menentukan lokasi kesalahan yang akurat untuk kelas dan metode, dan kadang-kadang akurat ke baris kode.
- Mengotomatisasi . Tes memungkinkan Anda untuk dengan cepat dan mudah memasukkan objek uji dalam kondisi yang diinginkan untuk debugging.
- Mendokumentasikan .
4.1. Tes penerimaan mencatat persyaratan pelanggan untuk produk yang sedang dikembangkan.
4.2. Pengujian menunjukkan contoh penggunaan komponen yang dikembangkan, sehingga mengurangi waktu yang dihabiskan untuk mempelajari pekerjaan sistem oleh programmer lain.
Di salah satu organisasi yang saya berkonsultasi, manajer menolak memperkenalkan budaya pengujian otomatis:
- Tapi bagaimanapun, menulis tes untuk waktu yang lama! Kami tidak akan memenuhi tenggat waktu!
- Apakah Anda memiliki kesalahan yang telah Anda cari dan koreksi untuk waktu yang sangat lama?
- Ya, ada beberapa.
- Kasus apa yang paling sulit?
- Kami mencari satu kesalahan selama 80 jam.
- 80 jam adalah dua minggu kerja programmer. Jika Anda bahkan menghabiskan satu minggu penuh pengujian otomatisasi, itu akan menghemat waktu berbulan-bulan dalam mendiagnosis dan men-debug aplikasi Anda!
Organisasi kami memiliki postulat: "Dengan tes, menulis sebuah program dua kali lebih cepat!" dan dalil ini tidak dibahas. Hanya koefisien 2 yang dibahas - kadang-kadang ada 3 dan 4. Dan beberapa proyek tidak dapat diselesaikan tanpa pengujian otomatis yang kompeten (lihat proyek kewalahan).
"Kami sudah memiliki departemen pengujian manual, biarkan mereka menguji."
Sekilas, pemisahan spesialisasi ke dalam pengujian dan pemrograman tampaknya logis.
Tapi mari kita lihat kelemahan dari pengujian manual:
- Itu sangat mahal.
- Butuh waktu yang sangat lama. Sebagai contoh: skrip uji untuk aplikasi mobile "Bioskop Online" menghasilkan waktu 40 jam. Dan ini hanya untuk satu platform! Jika Anda perlu menguji aplikasi pada iPhone, iPad, Apple TV, Android, Fire TV, maka Anda perlu menghabiskan 40 × 6 = 240 jam waktu kerja, ini adalah satu setengah bulan, yang tidak dapat diterima untuk siklus pengembangan singkat.
- Pengujian manual tunduk pada kesalahan manusia yang umum - itu tidak memberikan hasil yang objektif dan benar.
Selain itu, beberapa jenis pengujian tidak dapat dilakukan dalam waktu yang wajar, karena jumlah kombinasi format dan berbagai skrip pengujian sangat besar. Sebagai contoh:
- Berfungsi untuk mengimpor file CSV.
- Parser untuk dokumen teks.
- Instrumen keuangan.
Metode Tingkat Keberatan
Ketidaktahuan tentang metode pengujian otomatis.
Karena krisis dalam pendidikan, tidak ada disiplin pengujian otomatis di mana pun di universitas. Ada beberapa kursus seperti itu di sekolah-sekolah TI komersial. Dan kursus yang ada dangkal dan berkualitas buruk. Oleh karena itu, saya sering bertemu orang bodoh di antara programmer: mereka tidak tahu cara menguji aplikasi non-sepele (lebih sulit dari 2 + 2 = 4).
Padahal, ilmu pengujian cukup luas. Misalnya, tidak setiap programmer akan segera menjawab pertanyaan: a) apa itu testability? b) apa yang dapat dikontrol dan diamati? c) pola desain mana yang meningkatkan testabilitas aplikasi? Dan sebagainya.
Pemrogram tidak tahu apa yang mereka tulis, bagaimana tampilannya, apa fungsi dan antarmuka yang akan.
Sangat sulit untuk menguji apa yang tidak jelas kelihatannya. Dengan kata lain, tanpa persyaratan yang ditentukan sebelumnya untuk aplikasi, programmer tidak dapat memahami apa yang diharapkan darinya.
Keunikan dari beberapa proyek adalah bahwa mereka dikembangkan menggunakan teknologi Produk yang Layak Minimum, yang dengan kata lain dapat digambarkan sebagai berikut: "Mari kita lakukan setidaknya sesuatu untuk waktu minimum dan anggaran minimum", dan programmer dianggap oleh pelanggan atau manajemen sebagai analis, desainer, arsitek, programmer dan tester dalam satu botol. Dengan pendekatan ini, tahap formal merancang sistem perangkat lunak tidak termasuk: definisi logika bisnis, domain, antarmuka komponen, serta organisasi internal mereka tentang hubungan mereka di antara mereka. Tidak ada arsitektur formal, tidak ada antarmuka, tidak ada proses bisnis yang ditentukan - tidak jelas apa yang harus diuji, melalui antarmuka mana dan apa hasil yang diharapkan.
Kode yang tidak pantas.
Testability adalah properti proyek yang mengatakan betapa mudahnya dapat diuji. Kesesuaian tes ditentukan oleh dua sifat lainnya: kemampuan kontrol dan kemampuan observasi. Manageability - properti yang menentukan betapa mudahnya memasukkan aplikasi ke kondisi yang diinginkan untuk pengujian (memenuhi prasyarat). Observabilitas - betapa mudahnya mempertimbangkan keadaan setelah tes, bandingkan dengan yang diharapkan.
Misalnya, otentikasi dua faktor menggunakan SMS sangat sulit untuk diuji secara otomatis, karena fungsi menerima SMS berada di luar lingkup lingkungan pengujian otomatis. Sistem seperti itu tidak cocok.
Menghadapi sistem yang tidak cocok, programmer menyerah dan menghindari pengujian sistem seperti itu.
Persiapan data uji.
Salah satu hambatan yang tidak terlihat adalah persiapan data uji dan standar. Misalnya: keadaan awal basis data tempat pengujian dilakukan. Penyiapan data uji dapat memakan banyak waktu dan pekerjaan rutin, sehingga pekerjaan ini dianggap tidak berterima kasih dan tidak menarik di kalangan programmer.
Solusi:
- pengembangan nilai referensi dan contoh-contoh pada tahap pengembangan tes penerimaan - mereka juga akan membantu menyelesaikan konflik dengan pelanggan pada tahap penerimaan pekerjaan;
- pengembangan nilai referensi pada tahap perancangan sistem. Misalnya, permintaan dan respons HTTP standar - akan membantu lebih mudah untuk mengintegrasikan klien dan server;
- pengembangan prosedur khusus untuk merakit basis data, di mana keadaan yang diperlukan dari basis data dibuat secara otomatis, dan tidak secara manual
- penggunaan templat Object Mother [Fowler, Schuh, Peter, dan Stephanie Punke. "Mempermudah Pembuatan Objek Tes di XP." XP Universe. 2003], yang membantu untuk dengan mudah mengalokasikan dan menginisialisasi objek dalam keadaan yang diperlukan.
Layanan pengujian.
Selama pengembangan proyek, persyaratan untuk itu (klarifikasi, perubahan) dapat berubah. Atau internal refactoring dapat terjadi, yang akan mengarah pada perubahan antarmuka kelas. Dengan perubahan persyaratan, kriteria penerimaan fungsi tertentu juga akan berubah, dan disertai pengujian. Pada titik tertentu, pemrogram mungkin menolak untuk melayani tes - yaitu, dari mempertahankan mereka up to date.
Solusi:
- menggunakan templat “adaptor” untuk memisahkan logika pengujian dari antarmuka yang diuji;
- penggunaan tes tingkat tinggi (Gherkin, Mentimun, Diberi Kapan-Saat);
- lihat solusi untuk resistensi "persiapan data uji".
Kesimpulan
Tidak ada keraguan bahwa perangkat lunak harus dapat diandalkan: melebihi harapan pelanggan. Tes otomatis bukan satu-satunya, tetapi komponen penting dalam pengembangan perangkat lunak yang andal.
Saya merumuskan keberatan dan hambatan khas untuk pelaksanaan pengujian otomatis, yang secara pribadi saya temui di organisasi saya, serta di organisasi-organisasi yang saya konsultasikan.
Artikel ini hanya menguraikan masalah dan hampir tidak menyentuh cara untuk menyelesaikannya. Secara umum, strategi untuk menyelesaikan masalah ini bagi saya seperti ini:
- Pembentukan dan promosi budaya desain TI yang baru, yaitu keandalan, kebanggaan, dan tanggung jawab pribadi atas hasilnya.
- Mengembangkan standar tinggi baru untuk pengujian kode.
- Pengembangan dan implementasi kursus pelatihan.
- Pengenalan motivasi dalam karier programmer dan manajer, terkait dengan kualitas produk perangkat lunak yang dikembangkan, serta keterampilan pengujian otomatis.
Hal terpenting yang berhasil saya pahami adalah bahwa masalahnya ada pada tingkat yang berbeda: teknologi, metodologis, manajerial dan budaya. Dan mereka perlu ditangani pada tingkat yang sesuai. Sangat sulit untuk menerapkan tes otomatis jika programmer tidak terlatih dalam metode desain yang sesuai uji atau jika manajemen tidak mendukung budaya pemrograman yang dapat diandalkan dalam organisasi.
Saya akan berterima kasih atas contoh dari praktik Anda tentang betapa mudah atau sulitnya untuk menerapkan tes otomatis di organisasi Anda. Masalah apa yang kamu hadapi? Bagaimana Anda mengatasinya?