Empat dari lima pencari kerja QA ingin belajar cara bekerja dengan autotests. Tidak semua perusahaan dapat memenuhi keinginan penguji manual seperti itu selama jam kerja. Wrike mengadakan sekolah otomasi bagi karyawan dan menyadari keinginan ini bagi banyak orang. Saya berpartisipasi di sekolah ini tepatnya sebagai siswa-QA.
Saya belajar cara bekerja dengan Selenium dan sekarang saya secara mandiri mendukung sejumlah autotest dengan hampir tidak ada bantuan dari luar. Dan, berdasarkan hasil dari pengalaman bersama kami dan kesimpulan pribadi saya, saya akan mencoba untuk mendapatkan formula sekolah otomatisasi yang paling ideal sebanyak mungkin.
Pengalaman Sekolah Wrike
Ketika kebutuhan akan sekolah otomasi menjadi jelas, organisasinya jatuh pada Stas Davydov, pimpinan teknis otomasi. Siapa lagi selain dia yang bisa menjelaskan mengapa mereka datang dengan inisiatif ini, apakah mereka mencapai hasil dan tidak menyesali waktu yang dihabiskan? Kami memberinya lantai:
- Pada tahun 2016, kami menulis kerangka kerja baru untuk autotest dan membuatnya sehingga tes menjadi mudah untuk ditulis: langkah-langkah normal muncul, struktur menjadi jauh lebih dimengerti. Kami punya ide: kami perlu menarik semua orang yang ingin menulis tes baru, tetapi untuk membuatnya lebih mudah dipahami, kami menciptakan serangkaian kuliah. Kami secara kolektif membuat rencana untuk masing-masing dosen di masa depan mengambil satu dan menyiapkan laporannya.
- Apa kesulitan siswa?- Pada dasarnya, tentu saja, arsitektur. Ada banyak pertanyaan tentang struktur tes kami. Dalam umpan balik kami menulis banyak tentang topik ini dan kami harus melakukan kuliah tambahan untuk menjelaskan lebih detail.
- Apakah sekolah membayar?- Ya tentu saja. Berkat dia, banyak orang terlibat dalam tes menulis, dan, rata-rata, di rumah sakit, semua orang mulai lebih memahami apa autotest itu, bagaimana mereka ditulis dan bagaimana mereka berjalan. Beban otomatisasi juga telah berkurang: kami sekarang menerima beberapa kali lebih sedikit permintaan untuk bantuan dengan analisis tes, karena penguji dan pengembang mulai mengatasinya sendiri di hampir semua situasi. Nah, ada beberapa keuntungan internal untuk departemen: mereka memperoleh pengalaman dalam presentasi dan ceramah, karena beberapa automatist telah berhasil membuat presentasi di konferensi, dan juga menerima serangkaian video dan presentasi yang kuat untuk pendatang baru yang sedang naik daun.
Dari saya sendiri, saya akan menambahkan bahwa komunikasi antara departemen kami telah disederhanakan ke tingkat yang sangat mudah. Sebagai contoh, sekarang saya praktis tidak perlu berpikir tentang kasus apa dan dengan tingkat atomicity apa yang diberikan untuk otomatisasi. Akibatnya, kepedulian terhadap cakupan tes, yang terus tumbuh, sepenuhnya berasal dari semua pihak yang berkepentingan. Tidak ada yang menuntut hal yang mustahil dari orang lain.
Secara umum, dampak pada kerja tim unik positif. Mungkin kolega yang membaca artikel ini juga berpikir untuk mengadakan sesuatu seperti ini? Maka sarannya akan sederhana: sepadan jika autotest menjadi prioritas Anda. Selanjutnya, kita akan berbicara tentang pertanyaan yang lebih kompleks: bagaimana mengatur semuanya seakurat mungkin sehingga biaya semua pihak minimal dan pengeluaran maksimum.
Kiat Organisasi
Sekolah itu berguna, tetapi, seperti diakui Stas, ada beberapa kesulitan, karena itu perlu mengatur kuliah tambahan. Dan seperti halnya seorang siswa baru-baru ini yang belajar membandingkan dirinya sendiri dalam ketidaktahuan dan dirinya sendiri sekarang, saya merumuskan langkah-langkah berikut untuk menciptakan yang ideal, menurut pendapat saya, cara untuk mengajar para penguji cara menangani autotest.
Langkah 0. Buat kamus
Tentu saja, langkah ini diperlukan tidak hanya untuk QA. Namun demikian, saya ingin mengatakannya secara eksplisit: basis kode otomatisasi harus disimpan dalam bentuk yang dapat dibaca. Bahasa pemrograman adalah, paling tidak,
bahasa , dan dari sini Anda dapat memulai penyelaman.
Berikut ini adalah tangkapan layar dari taskview dengan nama-nama elemen. Bayangkan Anda melakukan taskview sebagai kotak hitam dan belum pernah melihat Selenium dalam hidup Anda. Apa yang dilakukan kode ini?
(Spoiler - melalui istirahat tugas dihapus atas nama administrator, dan kemudian kita melihat bahwa ada catatan tentang ini dalam aliran.)
Langkah ini sendiri memungkinkan Anda untuk mendekatkan bahasa QAA dan QA. Lebih mudah bagi otomatisasi untuk menjelaskan hasil dari suatu proses, penguji manual harus mengeluarkan lebih sedikit untuk mengkompilasi kasus: mereka dapat dibuat lebih tidak terperinci. Namun mereka saling memahami. Kami mendapat kemenangan bahkan sebelum pelatihan itu sendiri dimulai.
Langkah 1. Ulangi frasa
Kami melanjutkan paralel dengan lidah. Ketika kita belajar berbicara di masa kecil, kita tidak beralih dari etimologi dan semantik. Kami ulangi “ibu”, “beli mainan”, tetapi kami tidak segera masuk ke akar kata-kata ini sebelum bahasa Indo-Eropa. Jadi di sini: tidak masuk akal untuk menyelami kedalaman fitur teknis autotest, tanpa mencoba menulis sesuatu yang berfungsi.
Kedengarannya agak berlawanan dengan intuisi, tetapi berhasil.
Dalam pelajaran pertama, ada baiknya memberikan dasar tentang cara menulis autotest secara langsung. Kami membantu mengatur lingkungan pengembangan (dalam kasus saya, Intellij IDEA), menjelaskan aturan bahasa minimum yang diperlukan untuk menulis metode lain di kelas yang ada menggunakan langkah-langkah yang tersedia. Kami menulis satu atau dua tes dengan mereka dan memberikan pekerjaan rumah, yang saya rancang sebagai berikut: cabang yang diberikan dari master, tetapi beberapa tes dihapus di dalamnya. Hanya uraian mereka yang tersisa. Kami meminta para penguji untuk mengembalikan tes-tes ini (tidak melalui show diff, tentu saja).
Menurut hasil, orang yang mendengarkan dan melakukan segalanya akan dapat:
- belajar bekerja dengan antarmuka lingkungan pengembangan: membuat cabang, hotkeys, komit, dan push;
- untuk menguasai dasar-dasar struktur bahasa dan kelas: di mana menyuntikkan, dan di mana untuk mengimpor, mengapa anotasi diperlukan dan apa yang ada untuk simbol secara umum, kecuali untuk langkah-langkah;
- memahami perbedaan antara tindakan, harapan dan verifikasi, di mana menggunakan apa;
- perhatikan perbedaan antara pemeriksaan otomatis dan pemeriksaan manual: dalam pengujian otomatis, Anda dapat menarik satu atau satu penangan daripada melakukan tindakan melalui antarmuka. Misalnya, mengirim komentar langsung ke backend alih-alih membuka taskview, menyorot input, mengetik dan menekan tombol Kirim;
- rumuskan pertanyaan yang akan dijawab pada langkah selanjutnya.
Poin terakhir sangat penting. Jawaban ini dapat dengan mudah diberikan sebelumnya, tetapi ini adalah prinsip pengajaran yang penting: jawaban tanpa pertanyaan yang dirumuskan tidak diingat dan tidak berlaku ketika, akhirnya, mereka diminta.
Akan sangat ideal jika pada saat itu automator tim QA akan menggantungkan tugas padanya dengan menulis beberapa tes dalam pertempuran dan membiarkannya berkomitmen pada utasnya.
Apa yang seharusnya tidak Anda berikan:
- pengetahuan yang lebih mendalam tentang fungsi lingkungan pengembangan dan bahasa pemrograman itu sendiri, yang akan dibutuhkan hanya ketika bekerja secara independen dengan cabang. Saya tidak ingat, saya harus menjelaskannya dua atau tiga kali, dan kami menghargai waktu otomasi, bukan? Contoh: resolusi konflik, menambahkan file ke git, membuat kelas dari awal, bekerja dengan dependensi;
- semuanya terkait dengan xpath. Serius. Anda perlu membicarakannya secara terpisah, sekali dan dengan sangat terkonsentrasi.
Langkah 2. Kami melihat tata bahasanya
Mari kita ingat tangkapan layar dengan tampilan tugas dari langkah nomor 0. Kami memiliki langkah yang disebut checkCommentWithTextExists. Penguji kami sudah memahami apa langkah ini dan Anda bisa melihat ke dalam langkah itu dan sedikit menguraikannya.
Dan di dalam kita memiliki yang berikut:
onCommentBlock(userName).comment(expectedText).should(displayed());
Di mana onCommentBlock adalah
onCommonStreamPanel().commentBlock(userName);
Sekarang kita belajar untuk mengatakan tidak "membeli mainan", tetapi "membeli mainan dari toko Detsky Mir, berdiri di lemari biru di rak ketiga dari atas." Kita perlu menjelaskan bahwa kita menunjuk ke elemen berurutan dari elemen yang lebih besar (stream -> blok dengan komentar dari orang tertentu -> bagian dari blok ini di mana teks yang diberikan duduk).
Tidak, masih belum waktunya untuk membicarakan xpath. Hanya untuk menyebutkan secara singkat bahwa semua instruksi ini dijelaskan oleh mereka dan warisan melewati mereka. Tetapi Anda perlu berbicara tentang semua penguji dan penyiar ini, mereka berhubungan dengan langkah ini dan perlu untuk memahami apa yang terjadi. Tapi jangan berlebihan: siswa Anda akan dapat mempelajari latihan yang lebih kompleks sendiri nanti. Kemungkinan besar, harus, tunggu sampai, ditampilkan ();, ada ();, bukan ();
Pekerjaan rumahnya jelas: cabang di mana isi beberapa langkah dihapus, yang diperlukan untuk sejumlah tes tertentu. Biarkan penguji mengembalikannya dan jalankan kembali menjadi hijau.
Selain itu, jika tim penguji tidak hanya memiliki fitur baru, tetapi juga beberapa perbaikan bug, Anda dapat memintanya untuk segera menulis tes untuk bug ini dan melepaskannya. Kemungkinan besar, semua elemen sudah dijelaskan, hanya beberapa atau tiga langkah yang bisa dilewatkan. Ini akan menjadi latihan yang sempurna.
Langkah 3. Perendaman penuh
Selengkap mungkin untuk tester yang akan terus memenuhi tanggung jawab langsungnya. Akhirnya, Anda perlu berbicara tentang xpath.
Pertama, kami memperjelas bahwa semua onCommentBlock dan komentar ini dijelaskan oleh mereka.
Total:
"//div[contains(@class, 'stream-panel')]//a[contains(@class,'author') and text()='{{ userName }}']//div[contains(@class,'change-wrapper') and contains(.,'{{ text }}')]"
Urutan cerita sangat penting. Pertama kita mengambil xpath yang ada dan menunjukkan bagaimana di tab elemen ada satu dan hanya satu elemen. Selanjutnya, kita berbicara tentang struktur: kapan Anda perlu menggunakan WebElement, dan kapan Anda perlu membuat file terpisah untuk elemen baru. Ini akan membantu untuk lebih memahami warisan.
Penting untuk secara eksplisit mengatakan bahwa elemen tunggal adalah semua taskview, itu berisi elemen anak - seluruh aliran yang mengandung elemen anak - komentar terpisah, dll. Elemen anak - di dalam induk baik pada halaman dan dalam struktur kerangka kerja autotest.
Pada titik ini, audiens harus sudah memiliki pemahaman yang kuat tentang bagaimana mereka diwarisi dan apa yang dapat dimasukkan setelah titik di onCommentBlock. Pada titik ini, kami menjelaskan semua operator: /, //,., [] Dan seterusnya. Dalam memuat, kami membuktikan pengetahuan tentang menggunakan
@class dan hal-hal lain yang diperlukan.
Siswa harus memahami bagaimana menerjemahkan xpath dengan cara ini. Untuk memperbaiki - benar, pekerjaan rumah. Kami menghapus deskripsi elemen, biarkan mereka mengembalikan pekerjaan tes.
Kenapa persis seperti ini?
Kita seharusnya tidak membebani seseorang dengan pengetahuan yang rumit, tetapi kita harus menjelaskan semuanya sekaligus, dan ini adalah dilema yang sulit. Dengan cara ini akan memungkinkan kita untuk membuat pendengar pertama mengajukan pertanyaan dan tidak memahami sesuatu dan menjawabnya pada saat berikutnya. Jika kita berbicara tentang keseluruhan arsitektur, maka pada saat topik langkah-langkah atau xpath dianalisis, bagian terpenting darinya sudah akan dilupakan karena tidak dapat dimengerti.
Namun demikian, salah satu dari Anda mungkin akan dapat berbagi pengalaman tentang cara mengoptimalkan proses lebih banyak lagi. Saya senang membaca saran seperti itu di komentar!