Membaca artikel tentang topik pengujian web, dua topik muncul dengan syarat: 1) pengujian manual sedang sekarat, autotest (selanjutnya disebut autotests adalah Selenium UI dan tes REST) adalah segalanya bagi kami; 2) pengujian otomatis bukanlah obat mujarab, pengujian manual sangat diperlukan. Pada saat yang sama, dari artikel ada kecenderungan peningkatan persyaratan untuk kualitas perangkat lunak dan kecepatan pengembangan produk. Wrike hanya terjadi ketika persyaratan ini sangat penting.
Produk ini sudah berusia 12 tahun, tetapi masih terus berkembang. Penyebaran terjadi sekali sehari, dan kadang-kadang dua. Oleh karena itu, sangat penting bagi kami bahwa regresi dilakukan secara eksklusif pada autotest. Namun, di Wrike (di perusahaan) ada lebih dari 30 tim scrum, dan staf tim otomasi bukan karet. Dalam keadaan seperti itu, untuk mengharapkan otomatisasi skenario manual paling baik, satu atau dua sprint bukanlah suatu pilihan. Pengalaman perusahaan kami mengatakan bahwa penguji manual dapat menulis autotest secara independen, tergantung pada nuansa tertentu. Dalam artikel saya akan menceritakan tentang mereka dan mengapa, menurut pendapat saya, kemampuan ini tidak hanya membantu untuk mengikuti tren, tetapi juga akan berguna untuk penguji sendiri.
Proses standar
Proses apa yang digunakan banyak tim? Ini bervariasi dari kasus ke kasus, tetapi fitur umum hampir sama. Ada departemen pengujian otomatis dan manual. Penguji manual dapat didistribusikan di antara perintah scrum. Dalam hal ini, otomatisasi, sebagai suatu peraturan, tidak memiliki hubungan dengan tim tertentu.
Ketika bekerja dengan fungsionalitas baru, tester membuat skrip pengujian, beberapa di antaranya ia tandai dengan cara yang telah ditentukan untuk automators. Selain itu, jika sudah ada kasus di mana penyesuaian dilakukan, maka mereka juga dicatat untuk memperbarui kode. Kemudian tes yang ditandai ditransfer ke departemen otomatisasi. Sebuah tim insinyur otomasi bertugas memperbaiki dan menulis autotest baru di salah satu sprint berikut. Selain skenario pengujian pemrograman, tugas automator meliputi menjalankan autotest, menganalisis hasil, serta mendukung dan mengembangkan proyek pengujian. Ternyata departemen otomatisasi bertindak sebagai pelaksana outsourcing, dan penguji manual adalah sejenis pelanggan.
Pelanggan juga menghabiskan waktu menyusun TOR yang terperinci dan akurat, secara berkala mendiskusikan metode implementasi dan memilih tes yang diperlukan. Ada juga risiko bahwa selama tidak adanya bug autotests dapat dilewati. Jangan lupa bahwa ada lapisan masalah teknis yang hanya bisa digulung pada tes otomatis, yang akan menghemat banyak waktu. Tugas-tugas seperti itu harus diperiksa dengan tangan di bagian di mana otomasi masih hilang.
Kontraktor, yang tidak terlalu tenggelam dalam fungsionalitas yang terlibat dalam tim, akan membutuhkan waktu untuk membenamkan diri dalam tugas dan kesadaran TOR secara dangkal. Pada saat yang sama, ada kemungkinan bahwa tes tidak diterjemahkan secara akurat ke dalam kode, karena itu akan memeriksa apa yang tidak kita inginkan. Dengan demikian, efisiensi dari basis pengujian berkurang.
Tim otomasi, menjadi satu-satunya kontributor pada proyek uji, memiliki kendali penuh atas basis kodenya, yang memungkinkannya untuk dikembangkan dengan mudah ke segala arah. Namun, waktu untuk ini menjadi tidak mencukupi karena meningkatnya beban dari tim lain. Masalahnya dapat diselesaikan dengan memperluas staf, tetapi kemudian biaya otomatisasi akan melebihi efektivitasnya. Bahkan jika Anda menghapus sebagian dari beban, memberikan penguji manual kesempatan untuk menjalankan tes dan menganalisis yang jatuh, ini tidak akan membawa hasil yang tepat. Karena mereka tidak memiliki alat untuk debugging tes, mereka mungkin tidak mengerti bahwa tes macet karena perubahan xpath dan sebagainya.
Dengan demikian, pada output kami mendapatkan bahwa autotest dengan skema ini tidak mengikuti pertumbuhan produk, yang mengarah pada cakupan kode yang buruk. Karena interpretasi TK yang tidak akurat, tes dapat melewati bug. Ketika mereka kedaluwarsa untuk waktu yang lama, yang jatuh tidak segera diperbaiki, dan sulit bagi penguji manual untuk segera memberi tahu bagian mana dari sistem yang tercakup dengan baik oleh otomatisasi. Autotests menjadi semacam kotak hitam, di mana penguji tidak percaya. Oleh karena itu, jumlah pemeriksaan manual yang tidak perlu semakin meningkat, persyaratan tugas semakin panjang, dan kualitas menurun dalam jangka panjang.
Anda dapat mengatasi kekurangan ini, tetapi semakin besar produk dan perusahaan, semakin menyakitkan bagi peserta dalam proses, dan yang paling penting, sulit untuk mengikuti tren peningkatan kecepatan dan peningkatan kualitas. Penguji sendiri menjadi sandera bagi rutinitas dan praktis tidak tetap pada perkembangan waktu.
Jalan yang salah
Jadi, bagaimana cara kerjanya pada contoh tim tempat saya bekerja. Ada tim pengujian otomatis dan manual. Data awal masih serupa, tetapi kemudian perbedaan dimulai. Penguji manual didistribusikan di antara tim scrum mereka. Setiap tim scrum memiliki autotester sendiri. Kadang-kadang dapat dialokasikan bukan untuk satu tetapi untuk dua tim, jika beban memungkinkan.
Ketika bekerja dengan fungsionalitas baru, tester menulis daftar periksa, yang menurutnya ia kemudian melakukan pemeriksaan manual. Bagian minimum yang diperlukan dari tes dari daftar periksa ini adalah otomatis. Penguji sendiri menulis autotest ini pada saat fitur sedang dalam pengembangan atau pengujian. Selanjutnya, kode tertulis diberikan kepada peninjau untuk ditinjau. Dengan pengecualian yang jarang, tugas tanpa autotes tidak dapat dikeluarkan.
Tentu saja, tidak ada persyaratan dalam Wrike untuk menulis autotest oleh penguji manual. Ini tetap pada kebijaksanaan tim. Anda dapat memberikan segalanya untuk otomatisasi. Anda dapat membatasi diri Anda untuk memperbaiki tes yang rusak dan / atau menulis baru dengan analogi, dan mendelegasikan tugas yang lebih kompleks (membuat tes baru atau memperluas pegangan back-end lama, Obyek Halaman atau langkah-langkah dan kelas uji) ke alat otomatisasi khusus. Itu semua tergantung pada Anda, tetapi bodoh untuk melewatkan keuntungan yang diberikan oleh penulisan independen tes otomatis.
Seluruh regresi kami didasarkan pada autotest, dan tanggung jawab penguji manual meliputi menjalankan dan menganalisis kegagalan autotest. Untuk setiap cabang yang sedang dikerjakan oleh tim, mereka menjalankan tes otomatis sebagai penjamin kualitas awal dan akhir. Karena itu, jauh lebih mudah bagi mereka yang menulis autotests sendiri untuk memahami mengapa tes yang berjalan di cabang mereka gagal. Terkadang alat seperti jalankan kembali dan laporan di
Allure benar
- benar cukup, di mana Anda dapat memahami alasan crash pengujian dari tangkapan layar dan langkah-langkahnya. Namun, seringkali asisten terbaik adalah kemampuan untuk menjalankan tes secara lokal, bermain-main dengan langkah-langkah atau menjalankannya dalam mode debug, melihat xpath yang diharapkan dan nyata. Tanpa pengalaman bekerja dengan proyek uji, ini akan memakan banyak waktu, atau akan perlu untuk mengalihkan perhatian alat otomatisasi khusus.
Selain itu, penulisan independen autotest memungkinkan untuk menjalankannya bahkan sebelum fitur dirilis. Penguji selalu mengetahui tingkat cakupan bagian sistemnya, dan tugas teknis hanya bergulir pada pengujian otomatis, yang secara signifikan menghemat waktu dan sumber daya tim. Tes itu sendiri selalu relevan, karena crash disesuaikan sebelum rilis. Tes yang rusak segera diperbaiki di cabang yang sama di mana yang baru ditulis.
Penguji manual secara maksimal terbenam dalam tugas tim, oleh karena itu, tes otomatis minimum yang diperlukan dipilih, yang mencakup sebagian besar kasus. Sampel direvisi beberapa kali selama pengujian, seperti selama pemeriksaan manual, fungsionalitas dipelajari secara lebih rinci dengan semua nuansa. Dengan demikian, efisiensi pengujian semacam itu semakin meningkat. Menulis autotest memungkinkan Anda untuk lebih memahami arsitektur aplikasi, komponen yang digunakan, dan interaksi front-end dengan back-end. Pada akhirnya, pengetahuan ini membantu pendekatan yang lebih sadar dan efektif untuk pengujian produk. Sebagai contoh, jika beberapa perintah membuat perubahan pada komponen umum, maka Anda lebih mungkin mengetahui sebelumnya apakah ruang lingkup Anda akan atau tidak akan terpengaruh, karena ketika bekerja dengan xpath Anda memahami komponen mana yang digunakan di bagian aplikasi Anda.
Dapat dikatakan bahwa menulis autotests membutuhkan waktu. Ya, tugas akan dirilis satu hingga tiga hari lebih lambat dari biasanya, tetapi dalam jangka panjang itu terbayar. Apalagi ada metode optimasi. Misalnya, saat fitur sedang dikembangkan, Anda dapat menyusun daftar periksa yang diperlukan dan membuat kosong untuk tes, sehingga menghemat waktu. Jika Anda memiliki kerangka kerja fungsionalitas yang siap pakai, dimungkinkan untuk menambah atau memperbaiki xpath yang ada, jika perlu, membuat Obyek Halaman baru atau menyesuaikan langkah-langkahnya. Kemudian, pada tahap penulisan autotest, setelah pemeriksaan manual, Anda hanya perlu menambahkan blok kode dalam urutan yang benar.
Berkat kerangka yang dikembangkan oleh tim otomasi kami, penulisan autotest untuk sebagian besar merupakan kompilasi kode dari blok - seperti Lego. Kesederhanaan ini memungkinkan Anda untuk dengan cepat beradaptasi dengan penguji manual dan mulai menulis autotest dengan analogi dengan yang sudah ada. Dari pengalaman saya sendiri, saya akan mengatakan bahwa butuh sekitar dua minggu dari saat saya pergi bekerja di Wrike sampai autotest pertama yang saya tulis, bersama dengan tugas-tugas lain.
Kontrol kualitas tes otomatis tertulis dilakukan melalui tinjauan kode. Tidak ada satu cabang uji pun yang masuk ke rilis tanpa ulasan. Ini adalah momen pelatihan yang baik, karena tester mengambil informasi yang berguna dari komentar pada kodenya dan membangun pengalaman solusi yang baik: misalnya, ia mengelola perpustakaan Java standar lebih efisien atau mendefinisikan xpath lebih tepat. Lain kali akan jelas cara terbaik untuk bekerja dengan situasi tertentu.
Tentu saja, pengembangan proyek pengujian, kerangka kerja, dan pelatihan penguji manual mengambil sumber daya otomatisasi, terutama pada tahap awal, tetapi tampaknya bagi saya bahwa upaya ini sepenuhnya terbayar. Kami memiliki banyak peningkatan di lingkungan pengujian otomatis yang membuat pekerjaan kami lebih mudah. Produk itu sendiri memiliki cakupan yang baik, sehingga Anda dapat mengandalkan regresi. Ini membantu mempercepat proses peluncuran fitur ke lingkungan pengguna dan sangat melindungi saraf penguji.
Menurut pengalaman tim kami, ini adalah salah satu proses terbaik untuk bekerja dengan produk yang besar dan berkembang pesat di perusahaan besar. Selain itu, sejalan dengan tren saat ini dalam meningkatkan kualitas perangkat lunak dan kecepatan pengiriman kepada pengguna. Penguji sendiri praktis menyingkirkan rutinitas, berkembang dalam beberapa arah dan melihat aplikasi dari beberapa sudut.
Secara singkat tentang hal utama
Untuk kenyamanan, saya akan menyoroti keunggulan untuk penguji manual di satu tempat, sehingga lebih mudah untuk menyadari signifikansinya secara individu atau bersama-sama:
- Gambaran yang lebih lengkap terbentuk tentang tingkat dan kualitas otomasi ruang lingkup Anda;
- Autotests tersedia sebelum fitur dirilis, yang memungkinkan untuk dengan cepat memeriksa kualitasnya kapan saja;
- Efisiensi autotests meningkat, seperti halnya efisiensi pengujian secara umum;
- Pendekatan yang lebih terinformasi dan efektif untuk pengujian sedang dibentuk;
- Menyingkirkan regresi manual yang monoton dan tes evaluasi yang panjang;
- Pertumbuhan pribadi dan pengembangan kompetensi.
Untuk meringkas
Tentu saja, tidak ada peluru perak. Apa yang cocok untuk satu perusahaan dapat ditolak dengan tajam oleh perusahaan lain. Dalam kasus Wrike, produk tumbuh sangat cepat dan tidak ada waktu untuk regresi manual yang panjang dan pengujian evaluatif. Kami memiliki peran ini dilakukan oleh autotests, yang mencakup hampir setiap komponen produk besar. Ini membantu menjaga kualitas, mengoptimalkan sumber daya, dan menyediakan fungsionalitas baru kepada pengguna dengan lebih cepat.
Berita buruknya adalah ia tidak dapat melakukan tanpa bug, tetapi dalam kasus kami, paling sering ini adalah beberapa kasus ekstrim. Berita baiknya adalah bahwa bug selama perbaikan juga ditumbuhi autotests.
Untuk beberapa alasan, sudah menjadi hal biasa di masyarakat sehingga gagasan untuk menulis autotest oleh penguji manual ditolak. Ada dua argumen paling populer di pihak penguji: "Mereka tidak membayar ekstra untuk ini" dan "Kami sudah memiliki cukup banyak pekerjaan." Bagi saya pribadi, kedua argumen tersebut berantakan ketika saya menyadari bahwa saya dapat menjalankan swa-uji pada saat fitur dikembangkan dan dalam waktu singkat memahami cara kerjanya dengan benar. Itu sangat berharga. Tugas kami adalah meningkatkan dan menjaga kualitas produk, sehingga setiap peluang digunakan untuk memfasilitasinya. Dari saat saya mulai menulis autotests, rutinitas dalam pekerjaan saya menjadi semakin tidak disadari.
PS Artikel ini hanya mencerminkan pengalaman tim kami dan mungkin tidak sesuai dengan keyakinan Anda. Karena itu, saya akan senang mengetahui tentang pendekatan yang memandu Anda dalam pekerjaan Anda. Saya juga akan senang dengan kritik yang sehat dan kesempatan untuk membahas artikel di komentar.