Haruskah penguji mengotomatiskan pekerjaan mereka?

Kami mencoba mengatur proses pengujian kami. Kami bertanya-tanya apakah penguji kami harus mengembangkan tes regresi otomatis, atau apakah pengembang harus melakukan itu.

Dan bagaimana dengan jenis tes otomatis lainnya? Haruskah penguji mengembangkannya?

Saya mengatakan penguji harus mengembangkan tes otomatis - mereka memiliki pendekatan "luar sepasang mata" untuk kode, dan akan (atau haruskah itu hanya 'mungkin'?) Menemukan bug yang belum Anda pikirkan, apalagi menangani .

Ditambah pemahaman mereka tentang persyaratan fungsional mungkin tingkat yang lebih tinggi daripada pemahaman pengembang - jadi duduk di antara pengetahuan tingkat rendah hardcore programmer, tetapi tidak setinggi tingkat BA.

Jika Anda dapat mengotomatiskannya, mengotomatiskannya.

Biarkan penguji bebas untuk menemukan hal-hal yang tidak dapat Anda otomatisasi. Dan ketika mereka menemukan bug baru, jika itu bisa otomatis dan ditambahkan ke tes otomatis, tambahkan.

Menurut pendapat saya, pengembang dan penguji bertanggung jawab untuk berbagai jenis tes.

Pengembang, saat menulis logika, harus juga menulis unit dan tes integrasi. Ini akan memungkinkan dev untuk memastikan bahwa apa yang mereka tulis sejauh ini berfungsi sebagaimana dimaksud. Selain itu, tes ini akan tetap ada untuk dev untuk dijalankan ketika mereka membuat perubahan di masa depan. Setelah logika selesai, dev dapat dipastikan bahwa apa yang ditulis bekerja karena mereka memahami spesifikasi dan dapat meneruskan ke tester.

Penguji dari titik ini harus bertanggung jawab untuk menulis tes sistem luas yang memastikan logika bisnis berfungsi sebagaimana dimaksud.

Mengingat bahwa devs seringkali terlalu terikat pada kode, penguji harus dapat membantu membersihkan tes dev tetapi tidak sebaliknya.

Dalam pengalaman saya, cara tester mengatur dan mengeksekusi test case secara otomatis sebenarnya berbeda dari cara pengembang melakukannya. Penguji akan berpikir lebih banyak tentang bagaimana mendapatkan informasi terbanyak dari kasus uji, bagaimana menjalankan tes dengan cepat, bagaimana menjaga agar tes tetap terjaga, dan sebagainya. Yang paling penting, penguji akan melihat nuansa cakupan pengujian yang akan dilewatkan oleh pengembang.

Jika sumber daya pengembangan tes rendah, pengembang dapat membantu - tetapi penguji harus meninjau pekerjaan mereka dengan cermat. Pengembang harus bekerja pada perlengkapan dan alat uji sebelum menulis kasus pengujian yang sebenarnya, dan pengembang seharusnya tidak pernah menulis kasus pengujian untuk kode mereka sendiri. Memiliki pengembang membantu dengan pengujian memang memiliki fasilitas - itu memperlihatkan devs ke bagian lain dari produk, dan pengujian dapat membantu mereka menjadi pengembang yang lebih baik. Namun, sama seperti pekerjaan pengembang junior tidak akan pernah berjalan tanpa ulasan kode, pekerjaan QA seorang pengembang harus mendapatkan ulasan QA dari seseorang dengan lebih banyak pengalaman pengujian.

Diedit untuk menambahkan: Saya seorang SDET dengan pengalaman 5 tahun. Saya bekerja dengan para pengembang hebat dengan 10+ tahun pengalaman masing-masing, dan akhir-akhir ini telah bekerja dengan mereka untuk melewati hambatan pengujian.

Satu hal yang saya benar-benar ingin lihat adalah alat otomatisasi yang solid untuk penguji yang akan memungkinkan mereka untuk merekam kemajuan mereka secara efektif melalui skrip pengujian dan kemudian mengizinkan skrip tersebut untuk dijalankan secara otomatis di masa depan. Terutama jika ini juga memfasilitasi skrip yang sama dijalankan pada versi sistem operasi yang berbeda tanpa tester harus melalui semuanya dengan tangan.

Sayangnya, tentu saja untuk produk yang saya kerjakan, tidak ada alat di pasar yang melakukan pekerjaan itu. Tetapi perlu mengingat hal ini dan melihat apa yang tersedia di pasar jika ada sesuatu yang akan bekerja untuk apa yang Anda lakukan.

Satu perbedaan kritis yang sangat penting di sini adalah ini: apakah penguji Anda hanya memeriksa , atau mereka menguji ?

Posting blog ini oleh Michael Bolton menjelaskannya dengan lebih baik, tetapi pada intinya: apakah mereka hanya ingin mengkonfirmasi perilaku, atau mereka mencari masalah dengan sistem?

Saya pikir itu juga berguna untuk mempertimbangkan Kuadrat Pengujian Agile (Brian Marick awalnya menggambarkan ini, tapi saya menemukan mereka dalam buku Lisa Crispin dan Janet Gregory "Agile Testing": bahkan jika Anda tidak mengikuti metodologi pengembangan Agile, saya pikir perbedaan antara tes yang mengkritik produk, dan tes yang mendukung tim, benar-benar bermanfaat ketika mempertimbangkan otomatisasi, dan mencoba mengembangkan rencana untuk siapa melakukan apa, dan mengapa.

Misalnya, pemeriksaan unit yang ditulis oleh pengembang bertindak sebagai detektor perubahan, memungkinkan Anda untuk menangkap regresi lebih awal saat dijalankan kembali secara teratur - ini adalah tes yang mendukung tim. Pemeriksaan regresi tingkat sistem yang otomatis sehingga dapat dijalankan kembali secara teratur dan cepat juga mendukung tim dengan menangkap regresi lebih awal, dan melengkapi pengujian unit yang dilakukan oleh pengembang. Itu membebaskan waktu penguji Anda untuk melakukan pengujian yang mengkritik pengujian eksplorasi produk, misalnya. Atau mungkin menerapkan beberapa pemeriksaan otomatis untuk menguji stres produk.

Hal lain yang sangat saya sukai dari presentasi Lisa Crispin yang saya tautkan adalah bahwa itu menunjukkan bahwa otomatisasi juga dapat digunakan untuk mendukung pengujian manual - membuat data uji, otomasi digunakan untuk membuat skenario ke titik yang ingin Anda fokuskan hari ini, untuk contoh.

Mempertimbangkan dua artikel ini diharapkan akan membantu Anda untuk menganalisis jenis pengujian apa yang ingin Anda lakukan, membuatnya lebih mudah untuk memilih apa yang mungkin cocok untuk otomatisasi, dan mencari tahu bit otomatisasi mana yang lebih cocok untuk dilakukan oleh penguji, dan yang mana oleh pengembang.