Beberapa waktu yang lalu, saya menulis
artikel tentang pengalaman saya dalam mengatur pekerjaan QA Engineer pada sebuah proyek. Sekarang saya ingin melanjutkan topik ini, tetapi dalam arah yang lebih sempit - otomatisasi uji. Ini akan
tentang proyek yang sama , itu kecil, tetapi berkembang sesuai dengan permintaan pelanggan reguler. Mungkin pendekatan saya tidak terlalu cocok untuk tim dengan lusinan karyawan dan masing-masing bertanggung jawab atas bagian mereka (menurut saya, setiap proyek harus diatur secara ketat, jika tidak, tidak mungkin untuk mengelola raksasa semacam itu, meskipun mereka akan menemukan biji-bijian yang sehat), tetapi dia pasti akan menarik bagi mereka yang, seperti saya, pernah datang ke pekerjaan baru, dan berdiri di persimpangan jalan bagaimana mengatur tempat mereka sendiri di bawah matahari baru.
Bersiap-siap untuk belajar
Jadi, bagaimana Anda bisa mengatur otomatisasi pengujian pada suatu proyek? Jika jawaban Anda adalah untuk mengambil Selenium yang indah dan semacam kerangka untuk itu dan seterusnya, maka dari 13 tahun pengalaman dalam pengujian, saya tidak akan melakukannya dengan pasti. Harus menguasai cakrawala baru.
Apa yang penuh dengan pendekatan untuk "berputar dalam selenium"? Dan fakta bahwa Anda sudah membaca dan mendengar lebih dari sekali. Kenyataan bahwa tes ini adalah UI, mereka mahal dan lama baik dalam menulis dan menjalankan, dan dalam mempertahankan kinerja. Semua orang tahu ini, tetapi semua rasa sakit dari kebenaran ini hanya ditemui ketika itu diabaikan. Autotest end-to-end UI harus bersifat wajib, tidak seorang pun kecuali mereka yang akan memberi Anda keyakinan bahwa apa yang
dilihat klien setelah pemasangan berikutnya tidak akan mengecewakannya. Tetapi mereka seharusnya tidak menjadi pusat otomatisasi pengujian Anda.
Ambil
Prinsip Piramida Uji sebagai Pusat Kontrol Kualitas Anda. Yang sama, tentang yang sudah banyak dikatakan, tetapi dalam praktiknya, tidak setiap QA mengerti bagaimana membuat piramida ini diterapkan.
Digambar seperti ini:
Dan seperti ini:
Setiap orang akan menemukan opsi untuk arsitektur mereka.
Menempatkan Prinsip-prinsip Piramida Pengujian ke dalam QA
Pertama, tidak peduli seberapa malas dan tidak biasa itu, kuasai pengujian berkulit putih dan menjadi "pengembang sebagian".Naikkan proyek secara lokal, sama seperti yang dilakukan oleh setiap pengembang (pasti, proyek memiliki dokumentasi tentang cara melakukan ini, temukan). Anda mungkin akan berhenti mengutuk bisnis ini selusin kali, melakukannya untuk pertama kali, Anda akan memiliki sejuta pertanyaan dan masalah, tetapi ketika Anda melakukan ini, Anda sudah akan tahu banyak: apa saja gagasan arsitektur, basis data apa, dari mana diteruskan, di mana konfigurasi yang diperlukan , dan yang paling penting, di mana autotests disimpan dan bagaimana menjalankannya.
Kedua, berurusan dengan autotest yang ditulis oleh pengembang sendiri.Temukan tempatnya di struktur proyek, jenis pengujian dan alat apa yang digunakan, bagaimana diluncurkan. Mengevaluasi cakupan proyek dengan autests, pelajari cara menavigasi mereka. Ada banyak alat untuk penilaian cakupan otomatis, Anda dapat menggunakannya, tetapi saya tidak membicarakannya sekarang. Saya lebih lanjut tentang pengembangan naluri Anda: ambil sebagian fungsionalitas dan lihat bagaimana hal itu tercakup oleh tes otomatis: baik atau buruk. Jika itu baik, Anda harus tenang untuk bagian ini, jika itu buruk, Anda telah menemukan diri Anda sebagai front kerja untuk hari-hari ketika tidak ada tugas mendesak dalam agenda. Sementara itu, ingatlah bahwa setiap kali menjalankan, ingatlah bahwa tempat ini dalam kode rentan.
Ketiga, berani, tinjau permintaan tarik pengembang.Setiap kali Anda mulai mengembangkan fungsional baru, tulis semua kotak uji untuknya. Tandai yang Anda harus otomatiskan agar tidak kembali ke pengujian manual untuk fungsi ini. Tinjau permintaan tarik dari pengembang dan secara wajar menuntut implementasi autotest yang mereka lewatkan. Sering kali saya menemukan pengembang yang sangat keren yang menulis tes keren, tetapi bahkan mereka menghasilkan QA yang baik dalam memahami bagaimana tepatnya klien akhir kemungkinan besar akan menggunakan produk tersebut. Oleh karena itu, bahkan untuk spesialis berpengalaman, ada sesuatu yang direkomendasikan dalam penulisan autotest.
Keempat, lebih berani lagi dan tulis autotes langsung di kode produk.Ya, sama seperti yang dilakukan pengembang. Setara dengan mereka. Setiap kali Anda menemukan test case yang perlu diotomatisasi, jangan buru-buru mengimplementasikannya dengan alat terpisah yang hanya digunakan dalam tim QA. Dan pertama-tama, tanyakan pada diri Anda pertanyaan: dapatkah itu dilakukan secara otomatis melalui unit / integrasi swa-uji dalam kode produk? Jika demikian, lakukan hal itu. Jika menakutkan, maka ini menakutkan hanya untuk pertama kalinya, tetapi tingkat keterampilan Anda, karena programmer berpengalaman akan meninjau permintaan tarik Anda. Ya, pada awalnya semua yang telah Anda lakukan akan hancur berkeping-keping, tetapi pengembangan selalu melibatkan rasa sakit :) Tetapi pada akhirnya Anda akan menerima dividen yang luar biasa:
- tes semacam itu akan didukung oleh seluruh tim pengembangan
- mereka akan bekerja terus menerus, terus menerus dan cepat
- mereka akan diintegrasikan ke dalam CircleCi dan dijalankan setiap kali mereka menyebarkan secara otomatis (jika ini diterapkan pada proyek)
- lubang akan ditambal dalam pengujian (Anda menulis apa yang tidak ditulis sebelumnya)
- Anda dapat membantu pengembang menulis tes jika mereka tidak punya waktu
Kelima, buat kumpulan kecil autotest end-to-end UI terbatas yang meniru tindakan pengguna akhir di browser.Ini akan menjadi tes yang hanya akan didukung oleh tim QA. Mereka bisa diwujudkan
- skenario pelanggan paling kritis dan kritis
- fakta bahwa dalam tes integrasi dalam kode utama tidak mungkin untuk sepenuhnya mengimplementasikan, misalnya, bekerja dengan layanan pihak ketiga
Dan ya, Anda sekarang memiliki akses ke proyek, dan Anda tidak perlu memperbarui front-end proyek sehingga memiliki pencari lokasi yang nyaman dan dapat diandalkan untuk Selenium. Tidak perlu menunggu dan meminta siapa pun - buka permintaan tarik di kode produk utama.
Apa yang terjadi?
Sekarang saya sedang mengerjakan skenario seperti itu. Hasilnya, di bagian atas piramida pengujian saya, hanya ada 9 buah tes ujung ke ujung. Dan dukungan mereka adalah tanggung jawab saya. Dan semua puluhan dan ratusan tes lainnya hidup bersama dengan kode produk utama, memulai pekerjaan mereka di komputer lokal pengembang dan didukung oleh seluruh tim insinyur.
Tes end-to-end saya bekerja cukup lama, karena fakta bahwa mereka mengunggah file video ke platform, dan kemudian mengonversinya dengan parameter yang berbeda, mengirimkannya untuk diproses ke layanan pihak ketiga, menunggu jawaban, dan seterusnya, tanpa bertopik. Karena itu, dalam autotest ada banyak saat menunggu akhir operasi. Tim tidak suka prospek memiliki tes seperti itu di CircleCi, dan itu tidak benar-benar perlu. Jadi saya menerapkannya seperti pekerjaan di Jenkins.
Ketika semua pemeriksaan tes dalam kode produk telah selesai, kami menyebarkan brunch yang diuji ke lingkungan pengujian dan menjalankan tes ujung ke ujung menggunakan Jenkins. Beberapa tes fungsional manual lainnya untuk kesetiaan yang lebih besar dari QA dan itu saja, Anda dapat menggabungkan brunch di master. Hari ini, saya bukan satu-satunya yang menggerakkan Jenkins untuk autotest pada lingkungan pengujian, pengembang terus-menerus meluncurkannya ketika mereka perlu menghasilkan data pengujian baru dan mensimulasikan aktivitas pengguna. Ada beberapa dari mereka, sehingga mereka stabil dan selalu berfungsi. Nyaman untuk semua orang.
Saya akan mencatat keuntungan lain yang menyenangkan untuk Engineer QA dalam implementasi piramida pengujian. Ternyata, Anda menjadi bagian dari tim insinyur secara penuh. Anda benar-benar melakukan bagian integral dari satu pekerjaan - menulis kode bersama dengan semua orang, melihat kode pengembang, berkomunikasi dengan mereka, dan mereka melakukan hal yang sama kepada Anda. Anda melihat kerja satu sama lain, kolaborasi yang lebih baik, pembangunan tim yang lebih kuat. Anda akan memahami proyek ini tidak hanya dari luar, tetapi juga dari dalam, layak dihargai, bukan?
Perpisahan terakhir
Artikel saya tidak mengklaim sebagai pil universal yang dapat digunakan kapan saja, di mana saja. Semua proyek sangat berbeda, semua tim sangat berbeda - masing-masing harus membangun jalur terbaiknya sendiri, sering kali ini adalah inti dari berbagai pendekatan dan alat. Bahkan Scrum yang terkenal, berapa banyak proyek yang telah saya lihat, masing-masing mengaku dengan caranya sendiri :) Saya biasanya tidak percaya pada instruksi yang ketat, saya percaya bahwa mereka diperlukan sebagai pedoman, dan saya harus bertindak sesuai dengan situasi.
Namun, dunia TI sedang berkembang, dan semakin banyak orang datang ke dalamnya, jadi saya yakin bahwa di antara para pembaca materi ini pasti akan ada seseorang yang instruksi kecilnya akan membantu saya memilih jalan yang benar. Tersenyumlah padaku dalam komentar jika itu berguna :), umpan balik akan menyenangkan bagiku!