Hai Nama saya Alyona Isakova, saya seorang penguji terkemuka di Avito, dan saya ingin memberi tahu Anda tentang pengalaman saya dalam memperkenalkan pengujian Agile kepada tim. Ketika saya membaca artikel tentang pengujian Agile dan ATDD yang tersedia dalam bahasa Rusia, saya mendapat kesan bahwa saya "tidak modis," "bukan tentang Agile." Tampaknya ini adalah semacam struktur kompleks yang mengharuskan dimasukkannya pengembang, dan sebelum diterapkan, saya masih harus "membajak dan membajak."

Untuk sementara saya hidup dengan ide ini, menulis daftar tugas selama melakukan tugas, mengumpulkan pertemuan "tim fitur", di mana PM, QA, Frontend dan Backend diundang untuk membahas nuansa tugas sebelum implementasi.

Mereka yang mengerti apa yang mereka bicarakan sudah memperhatikan tangkapannya, bukan?

Jika Anda google apa itu "Agile testing", Anda dapat memberikan saran untuk mengikuti kursus, beberapa artikel dengan pandangan tentang pendekatan dan definisi di Wikipedia:

"Pengujian tangkas adalah praktik pengujian perangkat lunak yang mengikuti prinsip pengembangan perangkat lunak tangkas. Pengujian tangkas melibatkan semua anggota tim tangkas lintas fungsional, dengan keahlian khusus yang disumbangkan oleh penguji untuk memastikan memberikan nilai bisnis yang diinginkan oleh pelanggan pada interval yang sering, bekerja pada kecepatan yang berkelanjutan. Spesifikasi dengan contoh digunakan untuk menangkap contoh perilaku yang diinginkan dan yang tidak diinginkan serta pedoman panduan. "

Saya tidak tahu tentang Anda, tetapi saya tidak selesai membaca definisi ini pertama kali, saya diserang oleh kerinduan. Padahal, semuanya tidak begitu kering. Intinya adalah bahwa pengujian Agile adalah pendekatan untuk proses pengujian, di mana tester jauh lebih terlibat dalam tahap pertama tugas dan kurang (atau benar-benar tidak ada) dalam yang terakhir, tidak seperti pendekatan Waterfall.

Bagaimana alur tugas kita diatur

Perlu dikatakan bahwa awalnya tim kami bekerja pada SCRUM yang ketat, maaf untuk ekspresi, yang jelas berjalan dengan baik dengan pengujian Agile, Anda dapat mengatakan itu menyiratkan itu.

1. Pernyataan dari pelanggan (anggap PM)

Pada tahap ini, rumusan masalah bagi kami dilakukan sesuai dengan skema Kisah Pengguna, Kriteria penerimaan, Kasus penggunaan. Pernyataan seperti itu, jelas Agile, tidak disengaja - itu adalah prestasi rekan saya di unit ini, yang telah memperkenalkan pengujian Agile di timnya. Mengapa saya tidak bisa meminjam pengalaman dari tim tetangga, saya akan memberi tahu Anda nanti di artikel.

2. Tinjau pernyataan masalah oleh tester

Pada tahap ini, tugas diperiksa untuk keunikan, konsistensi dan kegunaan. Dalam kasus saya, saya juga menambahkan item "tes" di sini, yang menjelaskan kasus uji tambahan (misalnya, negatif), yang tidak sesuai untuk ditulis dalam format Use case. Pada saat itu, saya tidak sepenuhnya sadar bagaimana menggunakan kriteria Penerimaan, jadi saya hanya mencoba memberikan masukan maksimum kepada pengembang untuk pemeriksaan saya berikutnya.

3. Diskusi tugas oleh semua yang tertarik atau "tim fitur"

Panggung itu dilakukan seperlunya. Jika setelah peninjauan, penguji memutuskan bahwa tugasnya jelas dan diskusi tambahan tidak diperlukan, kami melanjutkan ke paragraf keempat.

Jika tahap itu perlu, maka pada pertemuan itu kejelasan dibuat pada persyaratan, pekerjaan tambahan. Seringkali tugas diuraikan, kondisi pengujian dibahas selama operasi independen frontend dan backend.

4. Tugas diikuti dalam tumpukan, direncanakan, dilaksanakan, diluncurkan dan membawa manfaat dan kebahagiaan

Tampaknya semuanya tidak terlalu buruk, tetapi ada sesuatu yang perlu diperbaiki: setidaknya Anda dapat menghapus beberapa langkah tambahan, karena kami tidak mengerti mengapa itu terjadi.

Apa yang telah dilakukan untuk meningkatkan

Merasa keinginan yang tak terpuaskan untuk meningkatkan, pengembang dan saya lulus kelas master internal pada pengujian Agile. Ternyata untuk sepenuhnya mematuhi pendekatan, tim hanya perlu mengubah terminologi dan sedikit mengencangkan sekrup sepeda khusus kami.
Memperkenalkan pendekatan, mengamati tim yang sudah ada, tidak cukup, Anda memerlukan blok pengetahuan dan tahap kesadaran, yang dalam kasus saya diberikan oleh kelas master. Nilai tambah yang besar adalah kenyataan bahwa kami menjalani pelatihan dengan pengembang, yang saya sangat menyarankan semua orang, sulit untuk melebih-lebihkan bantuannya. Anda berdua (penguji dan pengembang) adalah minimum yang diperlukan dan cukup untuk mulai menerapkan pendekatan. Selain itu, setiap tim dan produk adalah individual, untuk memperbaiki metode ini untuk Anda sendiri, Anda setidaknya harus mencoba.

Sebagai contoh, di tim tetangga ada pengalaman dalam penggunaan berguna tes Unit dengan deskripsi awal dalam alat untuk menyimpan kasus uji dan otomatisasi berikutnya. Tim kami memutuskan untuk terlebih dahulu menentukan verifikasi yang diperlukan secara konseptual, mengotomatiskannya, dan setelah itu secara otomatis memilih kasus dari kode ke alat penyimpanan. Anda mungkin memiliki cara berinteraksi sendiri.

Saya tidak menyatakan bahwa tanpa acara khusus tidak mungkin untuk memperkenalkan pendekatan, dalam kasus apa pun. Tetapi Anda perlu meluangkan waktu untuk memahami, memotivasi tim dan mulai berubah dan berubah. Bersiaplah bahwa tidak semua orang akan segera menerima peningkatan dalam waktu yang dihabiskan untuk tugas dengan tangan terbuka, saya beruntung dalam hal ini.

Apa yang harus dibaca tentang topik ini

“Tes tangkas. Kursus Pelatihan untuk Tim Utuh, ”Janet Gregory dan Lisa Crispin. Buku ini baru-baru ini diterbitkan dalam terjemahan Rusia dan tersedia di Ozone.

Apa yang sebenarnya telah berubah

1. Pada pertemuan kami untuk mengklarifikasi simpanan (PBR), saya menjadi seperti murid yang sangat baik yang menanyakan segalanya dan segalanya: "Apa yang akan terjadi jika layanan pihak ketiga jatuh?", "Apa yang akan terjadi jika kita mengembalikan nol, bukan 0?", "A mengapa kita menyebutnya, dan tidak di sana? "," Dan bagaimana jika kita tidak mendapatkan semua data? "," Bagaimana jika planet ini ditangkap oleh dinosaurus pemberontak? " Hanya bercanda, hanya pertanyaan penting, tidak ada "nol" dan "0".
   Seiring berjalannya waktu, para pria menyadari bahwa dalam diskusi semacam itu, beberapa kasus yang tidak diketahui sebelumnya telah lahir yang sekarang dapat mereka ramalkan. Sebelumnya, pertanyaan seperti "Apa yang terjadi jika semuanya berantakan?" Saya bertanya-tanya dalam fase pengujian, dan sekarang dalam fase pengaturan.
2. Alih-alih item "Tes" dalam tugas, kami menulis "Kriteria penerimaan" secara rinci dan secara sadar, dan juga menentukan jumlah dan tingkat autotest di masa mendatang.
   Untuk kejujuran, perlu dikatakan bahwa tidak dalam 100% kasus kita mengetahui tingkat autotest sebelumnya. Ada kalanya kita secara teknis tidak bisa melakukan ini atau butuh waktu lebih lama daripada yang kita miliki di rapat. Dalam praktiknya, seringkali tidak mungkin untuk bertindak secara dramatis. Dan ini diizinkan - sesuatu akan datang seiring waktu.
3. Item “Tinjau pernyataan masalah oleh tester” dan “tim fitur” yang saat ini tidak kami lakukan. Kami menyelesaikan semua masalah pada pertemuan PBR, karena semua orang yang diperlukan sudah ada di sini, dan kriteria penerimaan dibahas dalam proses.
4. Penguji ditambahkan ke kode ulasan pengujian unit untuk mengonfirmasi bahwa ada cukup pemeriksaan.
5. Alih-alih pengujian fungsionalitas biasa, pada akhir proses pengembangan, autotest (di semua tingkatan) dijalankan dan hanya pengujian penelitian yang dilakukan.
   Idealnya, tentu saja, pengujian tidak boleh ada sama sekali, tetapi dalam praktik kami, kami telah menemukan bahwa ketika Anda membuat perubahan pada produk yang dikembangkan oleh banyak tim, lebih mudah dan lebih benar untuk menambahkan pengujian penelitian.

Kesulitan apa yang Anda hadapi?

1. Apa itu unit test

Kami dihadapkan dengan fakta bahwa kami, QA, tidak memahami pengujian unit apa yang diuji dan karenanya tidak memercayai mereka, dan sebagai penghargaan atas kewaspadaan kami, kami menulis tes pada tingkat yang lebih tinggi dan dengan tumit ketukan “untuk mengotomatisasi, Anda tidak dapat berbelas kasihan”.

Seperti yang diputuskan:
Kami, dengan pengembang Agile-berpendidikan kami (berterima kasih padanya dan kesabarannya), duduk di sudut, dan selama satu jam, ia menjelaskan kepada saya dengan jari apa tes unit, apa yang mereka makan dan mengapa mereka tidak bisa mengecek "omong kosong ini". Sebagai hasil dari penderitaan kami, skema layanan yang luar biasa telah lahir: mereka membuatnya sedemikian rupa sehingga mereka sendiri mengerti.

Satu panah yang dipilih - satu perjalanan - satu pemeriksaan dalam unit test

Akibatnya, setelah beberapa bulan, saya sendiri menulis unit test kecil dan menghapus cek yang berlebihan di tingkat atas. Ini, tentu saja, terutama copy-paste, tetapi sadar!

Mungkin Anda sudah memahami esensi pengujian unit dengan baik dan Anda tidak perlu menghabiskan waktu untuk item ini, tetapi jika tidak, subkautifikasikan pengembang Anda di lingkungan yang tenang dan serang dia dengan pertanyaan.

2. Dalam implementasi saat ini, tidak semua tes dapat dihilangkan tanpa modifikasi

Seperti yang diputuskan:
Kumpulan data e2e tes yang tidak perlu dengan menambah jumlah tes unit.
Kami telah merevisi unit test yang telah dilaksanakan, kami telah menuliskan cek apa yang kami inginkan dari mereka. Setelah itu, cukup diharapkan, ternyata kami kehilangan beberapa cek.
Setelah menentukan apa dan pada level apa yang kita inginkan, kita menetapkan tugas untuk masa depan.
Setelah melatih tentang apa yang sudah ada, kami mengambil aplikasi nyata dari pendekatan tersebut dan mulai menulis cek tentang metode yang belum tersedia. Sudah lebih sulit.

Kesimpulan

• Keunikan dari pendekatan ini adalah bahwa itu alami dan tumbuh dari hal-hal seperti: "menyampaikan nilai kepada pengguna", "mengurangi QA manual", "memberikan cakupan". Bagaimana tepatnya Anda akan melakukan ini adalah masalah lain, tetapi pendekatan ini memiliki sesuatu untuk ditawarkan kepada Anda dan menyarankan kunci master mana yang digunakan untuk menyederhanakan hidup Anda dan tidak kehilangan apa pun.
  Misalnya, "Praktik pengujian tangkas" adalah alat yang siap pakai untuk aplikasi, dan "Nilai" dan "Prinsip" adalah apa yang dipahami oleh penguji orang sehat, tetapi tetap layak untuk berulang kali mengatakannya pada diri sendiri dan tim Anda, karena saya tahu dari pengalaman : mereka sering dipindahkan ke latar belakang dalam mode beban tinggi.

  
  

• Hal utama dalam metodologi ATDD adalah bahwa sebelum Anda melakukan sesuatu, Anda perlu membuat kriteria untuk pekerjaan yang dilakukan dan kriteria untuk pekerjaan yang harus dilakukan dengan benar. Secara kasar, pendekatan menentukan periode waktu di mana Anda setuju dengan tim. Sisanya sejalan dengan permainan.

  
  

Misalnya, Anda menyadari bahwa dalam kondisi Anda, Anda tidak dapat membedakan lapisan integrasi tes - tidak apa-apa. Mulailah dengan langkah pertama pendekatan: tulis kriteria penerimaan, tentukan tes dan levelnya, buat tugas untuk masa depan yang lebih cerah. Tahap yang paling berguna di sini adalah definisi cek di muka, dari pertanyaan cermat Anda pada tahap menetapkan tugas - hasil positif tercepat yang akan membuktikan kepada tim Anda bahwa Anda tidak membuang waktu mereka.

• Secara umum, pendekatan pengujian Agile dan nilai-nilai, prinsip-prinsip dan praktik yang diusulkan di dalamnya mengikuti dari hal-hal yang sangat jelas, seperti yang dikatakan guru favorit saya dalam aljabar yang lebih tinggi: "Tapi di sini perlu untuk menerapkan akal sehat." Ini layak untuk diikuti, dan tidak hanya dalam pengujian.

Suatu ketika, di tengah diskusi, tim dan saya menyadari bahwa kami menulis cek pada terlalu banyak kondisi, dan ini membawa kami pada pertanyaan: "Apakah kita memanggil metode tepat pada parameter itu?" Ternyata perumusan masalah dapat disederhanakan secara mendasar dengan menyebut esensi itu sendiri, dan bukan logika di atas level darinya. Artinya, kondisi ketika kita memiliki entitas dependen, tetapi tidak ada entitas itu sendiri, itu tidak ada. Itu membuat hidup lebih mudah bagi kami.

Dengan cara menentukan tingkat test case, ini adalah holivar terpisah, ketika Anda mulai merasa sakit, cobalah untuk berkonsultasi literatur. Dan ingatlah bahwa praktik harus diterapkan di tempat yang benar-benar menyelesaikan masalah, di mana itu membuat hidup lebih mudah. Semua bagus, semoga berhasil dan segel!