Sekitar tujuh tahun yang lalu, Dan North dalam artikelnya menggambarkan aplikasi praktis dari pendekatan BDD, yang memungkinkan Anda membuat proses pengembangan lebih mudah dipahami dan dikelola dengan membangun komunikasi internal. Industri ini menunjukkan minat yang meningkat pada metodologi ini setiap hari, yang bertujuan untuk interaksi produktif dari tim standar seperti "analytics-development-testing".
Namun, sekarang hanya sebagian kecil dari perusahaan yang memutuskan untuk menggunakan BDD. Mengapa
Jadi, mari kita cari tahu. BDD (Behaviour Driven Development) adalah metodologi fleksibel yang terkait erat dengan TDD (Test Driven Development - “Development through Testing”). Dari pengalaman, bahkan penguji berpengalaman sering tidak melihat perbedaan antara metodologi ini. Memang, pada pandangan pertama sulit untuk mengisolasi: kedua pendekatan melibatkan penulisan dokumentasi dan tes sebelum dimulainya fase pengembangan. Dan perbedaannya adalah ini: dalam BDD, untuk menggambarkan tes, Anda perlu menggunakan bahasa alami yang dapat dimengerti oleh setiap peserta proyek untuk, pada kenyataannya, menggabungkan pernyataan masalah, tes dan dokumentasi bersama. Dengan kata lain, DSL (bahasa berorientasi subjek tertentu) didefinisikan, kemudian dibuat seperangkat frasa standar terbatas yang menjelaskan perilaku elemen yang diperlukan. Kemudian, dengan bantuan mereka, sebuah skenario dikembangkan menggunakan fungsi baru, yang akan jelas bagi semua orang.
Mari kita lihat perbedaannya sekali, dan itu akan menjadi jelas:
Kami akan menyentuh contoh ini, tetapi pertama-tama, mari kita lihat seluruh variasi metodologi yang saat ini tidak relevan.
Bandingkan beberapa metodologi
Diagram di bawah ini menunjukkan perbandingan tiga pendekatan: TDD, TLD (Test Last Development) dan BDD:
- Ketika kami bekerja sesuai dengan metodologi BDD, spesifikasi autotesting dan drafting menyertai setiap tahap siklus pengembangan perangkat lunak, yang memastikan relevansi autotest dan dokumentasi yang konstan.
- Metodologi TDD dan ATDD (Acceptance Testing) digabungkan dalam diagram dalam satu blok, karena ditulis pada tahap analitik. Seperti disebutkan di atas, TDD didasarkan pada tes menulis sebelum mengembangkan fungsionalitas. Pengembang harus menulis tes untuk menulis fungsionalitas untuk pengujian.
- TLD (Test Last Development) mencakup pengujian setelah penerapan fungsionalitas.
- BDD bersifat universal dan dapat dimasukkan pada setiap tahap perkembangan.
Diagram kedua menunjukkan keterlibatan peserta dalam proses pengembangan dalam penulisan skrip.
- Dalam BDD, setiap anggota tim dapat terhubung ke tes pada tahap apa pun, misalnya, analis, pengguna bisnis, pengembang, dan penguji, karena tes tersebut jelas bagi semua peserta dalam proses.
- BDD juga berguna karena Anda tidak perlu menghabiskan banyak waktu untuk menulis berbagai jenis dokumentasi. Skema pengembangan klasik mensyaratkan, sekurang-kurangnya, spesifikasi dan skrip uji yang biasanya ditulis oleh orang yang berbeda. Dalam BDD, spesifikasi adalah test case, sementara itu juga autotest. Penguji tidak perlu menulis dokumentasi uji terpisah - analis yang menulis spesifikasi dari konstruksi bahasa alami (yang dapat dibaca dan dimengerti oleh anggota tim) sudah melakukan ini untuk mereka.
Tidak diragukan lagi, BDD adalah alat yang baik untuk mencapai kualitas produk. Tes dan dokumentasi ditulis lebih cepat. Untuk bisnis, sebuah proyek menjadi lebih transparan, berkat konstruksi bahasa alami yang dapat dimengerti oleh siapa pun yang jauh dari pemrograman.
Ini tentang pro. Namun demikian, seperti yang telah dikatakan, meskipun ada banyak keuntungan, sedikit yang menerapkan metodologi ini.
BDD baik untuk semua orang, tetapi mengapa tidak menggunakannya?
Jawabannya sederhana: panjang dan mahal. Sebagian besar perusahaan IT akan setuju dengan pernyataan ini. Dan pada awalnya kami tidak terkecuali. BDD tidak nyaman bahkan jika memerlukan keterlibatan spesialis pengujian yang sudah pada tahap elaborasi persyaratan.
BDD membalikkan pedoman pengembangan klasik (TLD) secara terbalik. Ini diimplementasikan dengan buruk karena sulit. Siklus pengembangan memanjang.
BDD tidak diragukan lagi cara untuk mencapai kualitas. Tetapi tidak semua orang bersedia membayar waktu dan spesialis untuk kualitas ini.
Namun, apa yang harus saya lakukan jika saya masih ingin menerapkan BDD?
Anda dapat mencoba menggunakan kerangka kerja yang sudah jadi. Misalnya Mentimun, Squish, Yulup.
Masalah utama dari kompleksitas BDD bukanlah dalam proses, tetapi dalam implementasi dan alat yang ada. Ambil WEB sebagai contoh pengembangan sistem informasi perusahaan. Memiliki implementasi web, kami menemukan WebDriver, yang saat ini menjadi standar untuk mengotomatisasi aplikasi yang berjalan di browser web. Dia memiliki banyak peluang. Untuk mempertimbangkan berbagai penyesuaian elemen halaman, Anda harus menemukan opsi untuk mengaksesnya. Dan di sini, untuk memfasilitasi pengembangan tes, berbagai perpustakaan datang untuk menyelamatkan (Selenide, dll.), Yang menciptakan ekosistemnya sendiri yang perlu Anda ketahui. Untuk bekerja dengan WebDriver, Anda memerlukan programmer atau otomatisasi tester semuanya diimplementasikan menggunakan kode dan desain licik.
Memulai dengan kerangka BDD sulit dan memakan waktu.
Fokus kami adalah pada instrumen yang disebut Gauge. Ini adalah kerangka kerja yang fleksibel dan ringan, didistribusikan di bawah lisensi gratis. Terus terang, kami tidak benar-benar mempelajari alternatifnya, karena Penggunaan Gauge telah ditentukan secara agresif oleh pelanggan kami.
Dalam Gauge, pengujian ditulis dalam file spesifikasi (file dengan ekstensi .spec). Spesifikasi tersebut berisi langkah-langkah tes yang ditulis dalam bahasa alami. Langkah-langkah ini diimplementasikan dalam bahasa pemrograman (kami menggunakan bahasa pemrograman Java). Saat menerapkan langkah-langkah, penting untuk mematuhi Konvensi Penamaan baik dalam nama skrip dan file implementasi, dan atas nama metode implementasi dan langkah skrip, mereka harus benar-benar identik. Fleksibilitas tambahan untuk alat ini adalah bahwa langkah-langkah dapat memiliki parameter.
Ukuran memungkinkan kami untuk menggunakan manfaat BDD. Namun, kami masih mengalami masalah yang merupakan kompleksitas implementasi: masalah alat dan implementasi proses.
Ternyata keterlibatan penguji pada tahap awal memiliki efek buruk pada hasil akhir. Peningkatan waktu untuk mengembangkan tes. Menggunakan kerangka kerja apa pun membutuhkan upaya besar dari penguji, yang, tidak diragukan lagi, harus memiliki perintah pemrograman yang baik. Pada awalnya, proses bekerja dengan skrip adalah sebagai berikut: analis mengatakan tes kepada penguji, dan penulis teknis menuliskannya. Sementara tester berurusan dengan implementasi perangkat lunak, arti dari fungsionalitas yang diuji berubah. Ini mempengaruhi pemisahan titik masuk, dan itu harus menjadi satu, sebagai akibat dari proses dibagi dan berubah menjadi proses "normal", dari mana saya hanya ingin pergi. Yaitu titik masuk terbagi, komunikasi menyebar, tester langsung menuju pelaksanaan tes, penulis teknis mengerti dengan caranya sendiri, dan analis menulis ulang dok-doknya dan berubah pikiran, pengembang masuk ke "dunianya").
Penguji menghabiskan banyak waktu pada kode. Tapi tetap saja tester yang sama harus memikirkan pencarian elemen pada halaman. Situasi itu mengingatkan pada permainan anak-anak terkenal: "Telepon manja". Runtuhnya terjadi. Dan kami memutuskan: BDD hanya akan berfungsi jika analis dapat menulis tes. Penting untuk mengurangi kerumitan tes menulis, untuk menyederhanakannya. Tetapi untuk ini, Anda perlu menyederhanakan antarmuka pengujian secara signifikan. Alat pengujian, implementasi proses bersama dengan semua pendekatan dan perpustakaan harus lebih sederhana.
Karya penguji pada awalnya tampak seperti ini:
- Pemeriksaan dokumentasi, jika ada;
- Menyusun daftar periksa;
- Pengujian ad-hoc
- Menyusun rencana uji;
- Penyempurnaan dari pandangan dunia analis;
- Penyempurnaan gambar dunia oleh pengembang;
- Jika semuanya telah tumbuh bersama, tulislah dokumentasi pengujian, bersamaan dengan pengujian;
- Menunggu bug diperbaiki, menguji bug;
- Deskripsi halaman, kontrol, mencari elemen pada halaman menggunakan Web-Driver. Cari apa yang sudah diterapkan dalam sistem pengujian;
- Menulis tes logika;
- Lepaskan
- Bug dukungan / Bug pemulihan;
- Pembaruan spesifikasi;
- Perbaiki bug
- Pembaruan autotest, memperbarui sejumlah besar kontrol yang diubah;
- Lepaskan
- ...
Item dalam huruf miring (1, 5, 6, 7, 9, 13, 15) menyebabkan biaya waktu. Mereka dapat dan harus dioptimalkan.
Daftar ini diilustrasikan secara singkat dalam diagram proses pengembangan:
Perusahaan kami mengkhususkan diri dalam proyek-proyek dengan implementasi antarmuka web. Berdasarkan ini, kami menggunakan alat Driver Web untuk berinteraksi dengan browser web.
Secara de facto, Selenium Web Driver adalah standar, dan digunakan untuk menggambarkan objek web pada kerangka apa pun, termasuk Gauge, jUnit, perpustakaan Masquerade, dan lainnya. Dia memiliki banyak fleksibilitas untuk tugas yang berbeda, yang menciptakan kesulitan yang berlebihan dalam masalah tipe lokal. Kita perlu menemukan solusi untuk mengurangi kompleksitas.
Sebagai contoh, mari kita tunjukkan dalam diagram bagaimana Selenium Web Driver, kerangka Gauge, perpustakaan Masquerade, dan bahasa pemrograman Java saling berhubungan.
Dalam skema ini, alih-alih kerangka BDD, Anda dapat menempatkan jUnit, TestNG atau lainnya, bundel apa pun akan berfungsi, tergantung pada kebutuhan. Selenium dan Masquerade akan tetap ada, bahasa pemrograman bisa diubah.
Mempercepat Penulisan Kode - Menghubungkan Masquerade
Perusahaan kami berkembang di platform CUBA . Dan khusus untuk platform ini, alat untuk autotest dikembangkan: Masquerade adalah perpustakaan yang menyediakan API ringkas dan nyaman untuk bekerja dengan kode ketika menerapkan tes menggunakan WebDriver. Perpustakaan ini berfungsi pada Selenium Web Driver, berteman dengan selenide dan kerangka kerja apa pun.
Dalam proyek CUBA, setiap elemen halaman web berisi cuba-id, yang tidak berubah. CUBA menggunakan pendekatan komponen , dan perpustakaan Masquerade menyederhanakan interaksi dengan elemen halaman web. Perpustakaan dapat melakukan tindakan dengan elemen halaman web yang diimplementasikan menggunakan CUBA dengan cara yang lebih sederhana. Karena itu, ketika mencari elemen di halaman, Anda tidak perlu menggunakan konstruksi besar dengan XPath, seperti sebelumnya:
$(new By.ByXPath("//*/div/div[2]/div/div[2]/div/div/div[3]/div/div/div[3).click();
Atau konstruksi yang lebih ringkas di Jawa, yang, bagaimanapun, masih rumit:
private static void click(String cssClass, String caption) { $(By.cssSelector(cssClass) .$(byText(caption)) .closest(".v-button") .click(); }
Setelah menghubungkan perpustakaan Masquerade, deskripsi kontrol tertanam terlihat sederhana dan mudah diakses. Anda bahkan tidak perlu mencari kontrol di halaman, karena dia sudah memilikinya di proyek. Berikut adalah contoh deskripsi tombol untuk formulir otorisasi dalam aplikasi:
Dalam kode halaman, kita melihat elemen cuba-id=”loginButton”
Mari kita jelaskan tombol menggunakan perpustakaan Masquerade:
@Wire(path = {"WebHBoxLayout", "loginButton"}) private Button loginButton;
Implementasi tes sederhana pada kerangka jUnit adalah blok otorisasi yang berjalan sebelum setiap tes:
@Before public void loginAdm() { Tests loginTest = _$(Tests.class); loginTest.login(); }
Dan di tubuh metode login, kode berikut:
LoginWindow loginWindow = _$(LoginWindow.class); assertNotNull(loginWindow.getLoginField()); loginWindow.getLoginField() .shouldBe(EDITABLE) .shouldBe(ENABLED); loginWindow.loginField.setValue("admin"); loginWindow.passwordField.setValue("admin"); loginWindow.rememberMeCheckBox.setChecked(true); loginWindow.loginButton().click();
Yang paling penting adalah bagaimana kita menggambarkan halaman itu, bagaimana kita merujuk elemen. Deskripsi halaman LoginWindow:
public class LoginWindow extends Composite<LoginWindow> { @Wire(path = {"loginField"} ) private TextField loginField; @Wire(path = {"passwordField"} ) private PasswordField passwordField; @Wire(path = {"rememberMeCheckBox"} ) private CheckBox rememberMeCheckBox; @Wire(path = {"loginFormLayout", "loginButton"} ) private Button loginButton; }
Mencari barang hanyalah bagian dari perpustakaan Masquerade. Mengakses elemen halaman web memungkinkan Anda untuk melakukan berbagai tindakan dengan elemen-elemen ini. Misalnya, Anda dapat memilih item dari daftar drop-down:
getMaxResultsLayout().openOptionsPopup().select("5000")
Atau urutkan tabel:
Table tb1 = client.getPaymentsTable(); tb1.sort("column_year", Table.SortDirection.ASCENDING);
Lihat tangkapan layar di bawah ini untuk daftar beberapa tindakan tabel:
Menggunakan Masquerade telah sangat menyederhanakan penulisan tes, sekarang untuk menulis tes untuk fungsionalitas baru, Anda perlu:
- Menggunakan Masquerade untuk menggambarkan halaman itu mudah dan tidak memerlukan keterampilan pemrograman khusus.
- Kumpulkan dalam satu kelas semua halaman yang digunakan saat memeriksa fungsionalitas.
- Dari konstruksi bahasa natural yang sudah jadi, kumpulkan skrip uji (ganti nama elemen yang diperlukan di sana), yaitu, tulis spesifikasi Gauge.
Mengintegrasikan Masquerade dan Gauge
Sebelum menggunakan BDD, pendekatan TLD digunakan dan untuk bekerja dengannya kami juga mengoptimalkan proses penulisan kode tes. Bundel jUnit / TestNG + WebDriver + Selenide + Masquerade yang digunakan.
Sekarang, agar dapat bekerja dengan Gauge, kami menambahkan plug-in yang sesuai ke intellij IDEA. Setelah itu, akan dimungkinkan untuk membuat jenis tes - Spesifikasi baru.
Sekarang kita membuat spesifikasi (skrip) dan mengimplementasikan langkah-langkah menggunakan kemampuan WebDriver, Masquerade dan Java.
Kami klik pada langkah skrip dan pergi ke implementasi:
Dalam implementasinya, Anda dapat menggunakan metode login () yang ada.
Seperti apakah kesempurnaan ini?
Ingat contoh yang kami periksa di awal artikel:
"Navigation.openMenu(menu)” berisi implementasi membuka menu menggunakan perpustakaan Masquerade.
Perpustakaan kemudian diperluas dan langkah-langkah universal muncul yang dapat digunakan untuk aplikasi CUBA. Ini adalah langkah-langkah yang memungkinkan Anda untuk bekerja dengan elemen-elemen program: tombol, bidang, tabel. Langkah-langkah universal ini telah menjadi seperangkat frasa standar yang kami gunakan dalam BDD untuk menulis skrip.
Berkat Masquerade + Gauge, kami secara signifikan mengurangi kerumitan pembuatan tes. Sekarang tes dapat ditulis oleh orang-orang yang tidak memiliki keterampilan pemrograman khusus. Sebuah tes dapat ditulis oleh satu orang (sebelumnya, sebuah skrip diciptakan oleh satu orang, tetapi diimplementasikan oleh orang lain, yang menyebabkan kebingungan). Jadi, kami telah mencapai tujuan kami - antarmuka disederhanakan, dan tidak akan sulit bagi analis untuk menulis skrip pengujian.
Perubahan proses ditunjukkan di bawah ini:
Itu:
Itu menjadi:
Sebagai perbandingan, terlihat bahwa persyaratan, spesifikasi, dan dokumentasi pengujian digabungkan dalam satu paragraf. Dokumentasi pengujian juga merupakan autotest, dengan pengecualian implementasi langkah-langkah pengujian tertentu.
Ringkasan
Saat ini, kami berhasil mengembangkan sesuai dengan skema yang ditunjukkan di atas. Dan kami berhasil menyingkirkan masalah utama BDD - peningkatan yang serius dalam hal kompleksitas implementasi, menambah dan menyelesaikan toolkit. Namun, kualitas pengiriman produk telah meningkat.
Waktu yang diperlukan untuk memelihara dokumentasi berkurang secara proporsional dengan jumlah spesifikasi yang diubah, karena satu perubahan spesifikasi (logika sistem) secara otomatis mengarah ke perubahan autotest dalam satu iterasi. Yaitu tester tidak perlu masuk ke sistem dokumentasi (seperti Confluence, dll.) untuk pembaruan, dan ini juga berlaku untuk anggota tim lainnya.
Waktu untuk mengimplementasikan dan mendukung tes di hadapan perpustakaan yang menyederhanakan bekerja dengan objek halaman telah dikurangi setengahnya dibandingkan dengan bekerja dengan driver web bersih yang biasa dan biaya pembuatan kembali tautan XP.
Dalam pengembangan solusi bisnis dan manajemen mutu - biaya menghilangkan kesalahan dalam pengumpulan persyaratan dan analisis tumbuh secara eksponensial . Dengan demikian, kemungkinan masalah yang terkait dengan perubahan produk, sesuai dengan artikel yang ada dan jadwal dalam pengembangan berulang, dengan deteksi dini masalah, yang merupakan studi yang baik tentang persyaratan, secara signifikan mengurangi biaya pengembangan, tergantung pada proyek. Itu bisa 0% dan ~ 40%. Peningkatan inilah yang dicapai melalui pengenalan BDD. Ini dapat diimplementasikan tanpa menyebutnya kata BDD, tetapi itu ada di BDD. Mampu mengatasi masalah adalah bagian penting dari jaminan kualitas.
Sebagai kesimpulan, saya ingin mencatat bahwa skema pengembangan ini juga terintegrasi dengan Continuous Integration dan sistem manajemen uji QA Lens yang dikembangkan di perusahaan kami. Di QA Lens, Anda dapat menulis skrip yang sama seperti di IDEA menggunakan bahasa berorientasi subjek. Bahasa ini terdiri dari glosarium yang sebelumnya disusun dari tindakan yang tersedia yang sebelumnya dilaksanakan. Saat melakukan autotest pada Gauge dari mesin pengembang atau CI, QA Lens secara otomatis mencatat langkah skrip mana yang selesai dan mana yang tidak. Dengan demikian, setelah menjalankan autotest dari skrip yang ditulis oleh seorang analis, departemen pengujian segera menerima informasi terbaru yang lengkap tentang keadaan produk.
Penulis: Sunagatov Ildar dan Yushkova Julia ( Yushkova )