Kembali ke sekolah: cara melatih penguji manual untuk menangani tes otomatis

Empat dari lima pelamar QA ingin mempelajari cara bekerja dengan pengujian otomatis. Tidak semua perusahaan dapat memenuhi keinginan penguji manual tersebut pada jam kerja. Wrike mengadakan sekolah otomasi untuk karyawan dan mewujudkan keinginan banyak orang. Saya berpartisipasi di sekolah ini tepatnya sebagai siswa QA.

Saya belajar cara bekerja dengan Selenium dan sekarang secara mandiri mendukung sejumlah autotest tertentu tanpa bantuan dari luar. Dan, berdasarkan hasil pengalaman bersama dan kesimpulan pribadi saya, saya akan mencoba mendapatkan formula sekolah otomasi yang paling ideal.

Pengalaman Wrike dalam mengorganisir sekolah

Ketika kebutuhan akan sekolah otomasi menjadi jelas, organisasinya jatuh ke tangan Stas Davydov, pimpinan teknis otomasi. Siapa lagi selain dia yang dapat menjelaskan mengapa mereka mengambil inisiatif ini, apakah mereka mencapai hasil dan apakah mereka menyesali waktu yang telah dihabiskan? Mari kita beri dia kesempatan:

— Pada tahun 2016, kami menulis kerangka kerja baru untuk pengujian otomatis dan membuatnya mudah untuk menulis pengujian: langkah-langkah normal muncul, struktur menjadi lebih mudah dipahami. Kami mendapat ide: kami perlu melibatkan semua orang yang ingin menulis tes baru, dan agar lebih mudah dipahami, kami membuat serangkaian ceramah. Kami secara kolektif membuat rencana topik, masing-masing calon dosen mengambil satu untuk mereka sendiri dan menyiapkan laporan tentangnya.

— Kesulitan apa yang dialami siswa?

— Terutama, tentu saja, arsitektur. Ada banyak pertanyaan tentang struktur pengujian kami. Banyak yang telah ditulis dalam ulasan tentang topik ini dan kami harus mengadakan kuliah tambahan untuk menjelaskan lebih detail.

— Apakah sekolahnya membayar?

- Iya tentu saja. Berkat dia, banyak orang yang terlibat dalam tes tertulis, dan rata-rata, di rumah sakit, semua orang mulai lebih memahami apa itu tes otomatis, cara penulisannya, dan cara peluncurannya. Beban pada insinyur otomasi juga berkurang: kami sekarang menerima lebih sedikit permintaan bantuan dalam menganalisis pengujian, karena penguji dan pengembang sudah mulai mengatasinya sendiri di hampir semua situasi. Ada beberapa keuntungan internal bagi departemen ini: kami memperoleh pengalaman dalam presentasi dan perkuliahan, berkat beberapa insinyur otomasi yang telah berhasil membuat presentasi di konferensi, dan juga menerima serangkaian video dan presentasi yang hebat untuk orientasi pendatang baru.

Atas nama saya sendiri, saya akan menambahkan bahwa komunikasi antar departemen kami telah disederhanakan ke tingkat yang sangat mudah. Misalnya, sekarang saya praktis tidak perlu memikirkan kasus apa dan pada tingkat atomisitas apa yang akan diotomatisasi. Oleh karena itu, semua pihak yang berkepentingan sangat memperhatikan cakupan tes yang terus berkembang. Tidak ada seorang pun yang menuntut hal yang mustahil dari orang lain.

Secara umum, dampaknya terhadap kerja tim sangatlah positif. Mungkin rekan-rekan yang membaca artikel ini juga berpikir untuk melakukan hal serupa? Sarannya akan sederhana: ada baiknya jika pengujian otomatis menjadi prioritas Anda. Selanjutnya, kita akan membahas pertanyaan yang lebih kompleks: bagaimana mengatur semua ini sebaik mungkin, sehingga biaya semua pihak dapat diminimalkan dan outputnya maksimal.

Mengorganisir Tip

Sekolah itu bermanfaat, namun diakui Stas ada beberapa kesulitan sehingga perlu diadakan perkuliahan tambahan. Dan ketika saya baru-baru ini membandingkan diri saya sendiri-dalam ketidaktahuan dan diri saya sendiri-sekarang saya merumuskan langkah-langkah berikut untuk menciptakan, menurut pendapat saya, cara ideal untuk mengajar penguji memahami tes otomatis.

Langkah 0. Buat kamus

Tentu saja langkah ini diperlukan tidak hanya untuk QA saja. Namun, saya ingin menjelaskannya secara eksplisit: basis kode otomatisasi harus disimpan dalam bentuk yang dapat dibaca. Bahasa pemrograman - tidak kalah pentingnya bahasa, dan dari sini Anda bisa mulai menyelam.

Kembali ke sekolah: cara melatih penguji manual untuk menangani tes otomatis

Berikut adalah tangkapan layar tampilan tugas dengan nama elemennya. Bayangkan Anda sedang menguji tampilan tugas sebagai kotak hitam dan belum pernah melihat Selenium seumur hidup Anda. Apa fungsi kode ini?

Kembali ke sekolah: cara melatih penguji manual untuk menangani tes otomatis

(Spoiler - tugas dihapus melalui istirahat atas nama admin, dan kemudian kita melihat bahwa ada catatan tentang hal ini di aliran.)

Langkah ini sendiri mendekatkan bahasa QAA dan QA. Lebih mudah bagi tim otomatisasi untuk menjelaskan hasil proses; penguji manual harus menghabiskan lebih sedikit upaya dalam membuat kasus: kasus dapat dibuat kurang detail. Meski begitu, semua orang saling memahami. Kami menerima kemenangan bahkan sebelum pelatihan sebenarnya dimulai.

Langkah 1. Ulangi frasa

Mari kita lanjutkan paralelnya dengan bahasa. Ketika kita belajar berbicara sejak kecil, kita tidak memulai dari etimologi dan semantik. Kita ulangi “ibu”, “beli mainan”, tapi jangan langsung masuk ke akar kata Proto-Indo-Eropa. Jadi begini: tidak ada gunanya mendalami fitur teknis autotest secara mendalam tanpa mencoba menulis sesuatu yang berhasil.
Kedengarannya agak berlawanan dengan intuisi, tetapi berhasil.

Pada pelajaran pertama, ada baiknya memberikan dasar bagaimana menulis autotest secara langsung. Kami membantu menyiapkan 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 ada. Kami menulis satu atau dua tes dengan mereka dan memberi mereka pekerjaan rumah, yang akan saya format seperti ini: cabang bercabang dari master, tetapi beberapa tes telah dihapus darinya. Hanya uraiannya yang tersisa. Kami meminta penguji untuk memulihkan pengujian ini (tentu saja, bukan melalui show diff).

Hasilnya, orang yang mendengarkan dan melakukan segalanya akan mampu:

  1. belajar bekerja dengan antarmuka lingkungan pengembangan: membuat cabang, hotkey, melakukan, dan mendorong;
  2. menguasai dasar-dasar struktur bahasa dan kelas: di mana memasukkan suntikan dan di mana mengimpor, mengapa anotasi diperlukan, dan simbol apa yang ditemukan di sana, selain langkah-langkah;
  3. memahami perbedaan antara tindakan, menunggu dan memeriksa, di mana menggunakan apa;
  4. perhatikan perbedaan antara pengujian otomatis dan pemeriksaan manual: dalam pengujian otomatis Anda dapat menarik satu atau beberapa pengendali alih-alih melakukan tindakan melalui antarmuka. Misalnya, mengirim komentar langsung ke backend alih-alih membuka tampilan tugas, memilih input, mengetik teks, dan mengklik tombol Kirim;
  5. merumuskan pertanyaan yang akan dijawab pada langkah berikutnya.

Poin terakhir ini sangat penting. Jawaban-jawaban ini dapat dengan mudah diberikan sebelumnya, namun merupakan asas pengajaran yang penting bahwa jawaban tanpa pertanyaan yang dirumuskan tidak diingat dan tidak digunakan ketika akhirnya dibutuhkan.

Akan ideal jika saat ini seorang insinyur otomasi dari tim QA memberinya tugas menulis beberapa tes dalam pertempuran dan mengizinkannya untuk melakukan subkomitmen ke cabangnya.

Apa yang tidak boleh diberikan:

  1. pengetahuan yang lebih mendalam tentang fungsionalitas lingkungan pengembangan dan bahasa pemrograman itu sendiri, yang hanya diperlukan saat bekerja dengan cabang secara mandiri. Itu tidak akan diingat, Anda harus menjelaskannya dua atau tiga kali, tetapi kami menghargai waktu para insinyur otomasi, bukan? Contoh: menyelesaikan konflik, menambahkan file ke git, membuat kelas dari awal, menangani dependensi;
  2. segala sesuatu yang berhubungan dengan xpath. Dengan serius. Anda perlu membicarakannya secara terpisah, sekali dan sangat terkonsentrasi.

Langkah 2. Perhatikan tata bahasanya lebih dekat

Mari kita ingat tangkapan layar tampilan tugas dari langkah #0. Kami memiliki langkah yang disebut checkCommentWithTextExists. Penguji kami sudah memahami apa yang dilakukan langkah ini dan kami dapat melihat ke dalam langkah tersebut dan menguraikannya sedikit.

Dan di dalamnya kita memiliki yang berikut ini:

onCommentBlock(userName).comment(expectedText).should(displayed());

Dimana onCommentBlock berada

onCommonStreamPanel().commentBlock(userName);

Sekarang kita belajar untuk mengatakan bukan “beli mainan”, tetapi “beli mainan dari toko Detsky Mir, yang terletak di lemari biru di rak ketiga dari atas”. Perlu dijelaskan bahwa kita menunjuk ke suatu elemen secara berurutan, dari elemen yang lebih besar (aliran -> blok dengan komentar dari orang tertentu -> bagian dari blok ini tempat teks tertentu berada).

Tidak, ini masih belum waktunya membicarakan xpath. Sebut saja secara singkat bahwa semua instruksi ini dijelaskan oleh mereka dan warisan melewati mereka. Namun kita perlu membicarakan semua pencocokan dan pelayan ini; mereka berhubungan secara khusus dengan langkah ini dan diperlukan untuk memahami apa yang sedang terjadi. Namun jangan berlebihan: siswa Anda dapat mempelajari sendiri pernyataan yang lebih kompleks nanti. Kemungkinan besar, seharusnya, menunggu Hingga, ditampilkan();, ada();, tidak(); sudah cukup.

Pekerjaan rumahnya jelas: sebuah cabang di mana isi dari beberapa langkah yang diperlukan untuk sejumlah tes telah dihapus. Biarkan penguji memulihkannya dan membuat proses menjadi hijau kembali.

Selain itu, jika tim penguji tidak hanya memiliki fitur baru dalam pekerjaannya, tetapi juga beberapa perbaikan bug, Anda dapat memintanya untuk segera menulis pengujian untuk bug tersebut dan melepaskannya. Kemungkinan besar, semua elemen telah dijelaskan; hanya beberapa langkah yang mungkin hilang. Ini akan menjadi latihan yang sempurna.

Langkah 3. Perendaman penuh

Selengkap-lengkapnya bagi seorang penguji yang akan tetap menjalankan tugas langsungnya. Terakhir, kita perlu membicarakan tentang xpath.

Pertama, mari kita perjelas bahwa semua onCommentBlock dan komentar ini dijelaskan oleh mereka.

Kembali ke sekolah: cara melatih penguji manual untuk menangani tes otomatis

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 tab elemen berisi satu dan hanya satu elemen. Selanjutnya, kita akan membahas tentang strukturnya: kapan Anda perlu menggunakan WebElement, dan kapan Anda perlu membuat file terpisah untuk elemen baru. Ini akan memungkinkan Anda untuk lebih memahami warisan.

Harus dinyatakan secara eksplisit bahwa satu elemen adalah keseluruhan tampilan tugas, berisi elemen anak - seluruh aliran, yang berisi elemen anak - komentar terpisah, dll. Elemen anak berada di dalam elemen induk baik pada halaman maupun dalam struktur kerangka autotest.

Pada titik ini, audiens seharusnya sudah memahami dengan jelas bagaimana mereka diwarisi dan apa yang bisa dimasukkan setelah titik di onCommentBlock. Pada tahap ini, kami menjelaskan semua operator: /, //, ., [] dan seterusnya. Kami menambahkan pengetahuan tentang penggunaan ke dalam beban @class dan hal-hal lain yang diperlukan.

Kembali ke sekolah: cara melatih penguji manual untuk menangani tes otomatis

Siswa harus memahami cara menerjemahkan xpath dengan cara ini. Untuk mengkonsolidasikan - itu benar, pekerjaan rumah. Kami menghapus deskripsi elemen, biarkan mereka mengembalikan pekerjaan pengujian.

Mengapa jalur khusus ini?

Kita tidak boleh membebani seseorang dengan pengetahuan yang kompleks, tetapi kita harus menjelaskan semuanya sekaligus, dan ini adalah dilema yang sulit. Jalur ini akan memungkinkan kita untuk membuat pendengar bertanya dan tidak memahami sesuatu, lalu menjawabnya pada saat berikutnya. Jika kita berbicara tentang keseluruhan arsitektur, maka pada saat topik langkah atau xpath dianalisis, bagian terpentingnya sudah terlupakan karena tidak dapat dipahami.

Namun, beberapa dari Anda mungkin dapat berbagi pengalaman tentang bagaimana proses tersebut dapat lebih dioptimalkan. Saya akan dengan senang hati membaca saran serupa di komentar!

Sumber: www.habr.com

Tambah komentar