Haruskah penguji mengotomatiskan pekerjaan mereka?


9

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?


Mulailah memanggil mereka "pengembang dalam pengujian" dan ambiguitas teratasi.
Edward Strange

@Crazy Tapi bukankah lebih mahal untuk memiliki 2 tim pengembang?
Jader Dias

5
Lebih mahal dari apa? Menjual produk yang diuji dengan buruk? Menghambat proses pengembangan karena pengembang menulis tes bukan produk?
Edward Strange

Jawaban:


12

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.


Tetapi tidak bisakah mereka meminta pengembang untuk menulis test case itu?
Jader Dias

1
Untuk alasan yang saya katakan di atas, pengembang akan tahu lebih banyak tentang implementasi internal dan akan mendekati perangkat lunak berbeda dari yang datang dari luar.
James Love

Saya tidak bisa melihat bagaimana implementasi test case dapat berbeda dari satu orang ke orang lain.
Jader Dias

5
@ Jader, Anda ingin orang yang berbeda menulis tes otomatis daripada menulis kode aslinya. Kalau tidak, tes akan bias bekerja dengan kode seperti yang tertulis.
Marcie

3
Selama beberapa minggu terakhir, saya memiliki pengembang yang membantu saya menulis perlengkapan untuk kode-kodenya. Dia adalah dev yang sangat baik, tetapi dia pasti merindukan beberapa nuansa cakupan untuk kode-nya hanya karena dia tidak berpikir tentang cakupan secara mendalam. Jika pengembang benar-benar membantu dalam pengujian, mintalah seorang penguji meninjau pekerjaan mereka.
Ethel Evans

11

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.


Tetapi mengapa mereka harus dan tidak hanya pengembang?
Jader Dias

@JaderDias, seperti yang telah disebutkan, penguji seharusnya tidak memiliki prasangka tentang kode yang mereka coba uji
CaffGeek

3

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.


Ingin tahu tentang kalimat terakhir Anda - Anda tidak berpikir pengembang dapat berkontribusi untuk tes fungsional? Bagaimana jika para penguji menguraikan struktur pengujian dan mengidentifikasi kasus-kasus pengujian dan para pengembang hanya membantu implementasi?
Miss Cellanie

1
Saya pikir saya membayangkan penguji yang merupakan pengembang di kanan mereka sendiri dan dapat menulis tes mereka sendiri. Tugas mereka adalah untuk berjalan melalui persyaratan dan berbicara dengan pengguna untuk mengidentifikasi kasus uji kemudian menulis kasus. Ini membuat pengembang logika bebas dekat dengan logika saat mereka menulisnya. Ini juga membuat penguji cukup jauh dari "memiliki" logika sehingga mereka dapat mencoba memutusnya dengan objektivitas dan tanpa penyesalan.
Taylor Harga

2

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.


0

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.


Visual Studio 2010 (Premium atau Ultimate, tidak ingat yang mana) memiliki sesuatu yang merekam tindakan layar untuk mengotomatiskan pengujian UI. Saya melihat demo ini oleh Andrew Woodward MVP ketika melakukan pertunjukan UI Testing SharePoint, sungguh luar biasa.
James Love

Merekam & bermain dengan benar memiliki reputasi yang buruk. Itu cenderung sangat rapuh, dan sulit dipertahankan. Ya, sebagai yang cepat & kotor "Saya harus menjalankan ini di 4 pusat data yang berbeda, saya tidak ingin menyimpannya untuk digunakan di masa mendatang", tidak apa-apa, tapi tetap buruk untuk mempertahankannya karena Anda berakhir dengan banyak pengulangan. Satu elemen kecil berubah - dan tiba-tiba Anda harus memperbarui 100 tes. Menyakitkan. Ini juga sama sekali tidak menggantikan tes manual, yang cenderung dirancang dengan asumsi bahwa manusia akan melihat semua hal-hal lain yang tidak Anda periksa secara eksplisit.
testerab

Apa yang akan sangat manis akan menjadi sesuatu yang bisa membawa hal-hal ke tingkat yang sedikit lebih rendah daripada memindahkan pointer dan mengklik mouse, sehingga Anda benar-benar merekam tombol apa yang diklik daripada di mana klik terjadi. Itu akan membuat jenis pengujian ini lebih tangguh dan praktis. Ketika Anda perlu menjalankan setiap skrip, misalnya, sembilan versi windows yang berbeda, adalah mimpi buruk untuk melakukannya secara manual pada semuanya.
glenatron

Tombol Mengidentifikasi oleh id daripada lokasi adalah sangat mungkin dengan beberapa alat. Rekam dan putar skrip yang dilakukan seperti itu MASIH mengerikan untuk dipertahankan, sayangnya - skrip ini tidak menyelesaikan masalah pengulangan. Saya tidak berpikir ada yang menjauh dari kebutuhan untuk merancang otomasi pengujian Anda dengan hati-hati, jika Anda benar-benar ingin menyimpan skrip atau membuat lebih dari selusin dari mereka. Pernahkah Anda berpikir untuk menggunakan sesuatu yang didorong kata kunci seperti Kerangka Robot bersama dengan Auto-It?
testerab

0

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.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.