Pengujian Otomatis: Menjelaskan Nilai Bisnisnya

Untuk memulai, saya rasa ini bukan pengulangan dari pertanyaan lain tentang pengujian unit . Apa yang saya cari bantuan adalah mengartikulasikan nilainya kepada tim programmer, analis, manajer dan penguji. Dengan tes otomatis, saya tidak berpikir saya perlu membuat perbedaan antara tes unit (misalnya JUnit), BDD (misalnya JBehave, Fitness) dan UI (Selenium, Watir) karena saya pikir mereka semua memberikan nilai yang sama (tetapi merasa bebas untuk tulis jawaban yang tidak setuju :))

Berikut ini adalah daftar yang telah saya identifikasi, saya mencari jawaban yang membantu memperluas atau memperbaiki:

1. Penghematan Waktu / Biaya : penulisan tes otomatis dapat memakan waktu lebih lama daripada ujian tertulis. Namun, mengingat pengujian dijalankan beberapa kali, pekerjaan marjinal (yaitu biaya / waktu) untuk melakukan pengujian otomatis adalah beberapa urutan yang lebih kecil. Bahwa tes otomatis yang murah untuk dijalankan memudahkan perubahan sistem dari waktu ke waktu.
2. Dokumentasi : tidak ada cara yang lebih benar untuk mengetahui bagaimana suatu sistem bekerja selain dari pengujiannya. Dokumentasi lain biasanya ketinggalan zaman saat ditulis, tetapi tes (setidaknya yang lulus) mengungkapkan cara kerja yang sebenarnya. Ini berlaku untuk dokumentasi pengguna dan API pengguna akhir.
3. Kualitas Kode : tes menulis memaksa Anda untuk:
   • pertimbangkan klien karena tes adalah klien
   • istirahat dependensi di mana membuat kode diuji sering berarti mencari tahu bagaimana membuat kode itu tidak memerlukan beberapa sistem besar lainnya tersedia

Beberapa pemikiran saya:

1. Jujurlah bahwa menulis tes otomatis akan memakan waktu lebih lama. Jika Anda melakukan TDD tingkat unit (yang saya sarankan sebagai titik awal jika Anda akan berinvestasi dalam pengujian otomatis), Anda dapat mengharapkan sekitar 30% waktu tambahan yang diperlukan untuk membuat kode fitur. Kuncinya di sini adalah menjelaskan bahwa tambahan 30% ini (yang mungkin lebih tinggi dari 30% pada awalnya ketika tim Anda belajar cara menulis tes yang baik) adalah investasi yang dibangun untuk menghemat biaya seiring waktu. Paling tidak dengan TDD tingkat unit, desain sistem Anda secara longgar digabungkan dan sangat kohesif, yang membuat sistem Anda dapat beradaptasi terhadap perubahan seiring waktu. Persyaratan baru dan bug yang tidak terduga selalu memerlukan perubahan pada sistem Anda,
2. Ada banyak perdebatan tentang nilai tingkat Penerimaan dan tes tingkat UI mengingat jumlah waktu yang dibutuhkan untuk menulis tes ini, berapa lama untuk menjalankannya, dan berapa banyak perawatan yang mereka butuhkan. Saya akan merekomendasikan membaca artikel ini oleh James Shore tentang ini.
3. Dalam dunia pengujian otomatis, ada cara baik dan cara buruk untuk melakukannya. Jika Anda mengajukan pengujian otomatis kepada manajemen Anda, saya akan menyampaikan bagaimana Anda berencana untuk melatih tim Anda dalam menulis tes yang baik. Seni Pengujian Unit oleh Roy Osherove, Bekerja Efektif dengan Kode Legacy oleh Michael Feathers, dan Seni Pengembangan Agile oleh James Shore adalah semua buku hebat yang membahas topik ini secara langsung atau tidak langsung. Anda juga harus melihat semacam pelatih atau pelatihan formal juga. Ini perubahan besar.
4. Dalam hal Nilai Bisnis, # 2 dan # 3 poin Anda di atas benar-benar melayani poin pertama Anda, jadi saya akan palu pada poin # 1 dan berbicara tentang bagaimana # 2 dan # 3 melayani poin yang lebih besar. Dokumentasi membuat sistem Anda lebih dimengerti, yang membuat tim Anda bekerja lebih cepat. Kualitas Kode membuat sistem Anda dapat beradaptasi terhadap perubahan, yang membuat tim Anda bekerja lebih cepat. Untuk pebisnis, ini semua tentang memaksimalkan aliran nilai dari saat sebuah ide dilemparkan ke saat ide tersebut disampaikan sebagai perangkat lunak yang berfungsi.

Satu hal yang bernilai pasti adalah bahwa tes otomatis dapat dijalankan terus menerus; seperti setiap jam membangun kembali atau serupa Melakukan hal ini memaksa bug atau regresi keluar ke tempat terbuka dengan cepat dalam hitungan jam atau hari dari seorang programmer yang mengerjakan kode yang menyinggung, ini membuat pengalihan konteks menjadi lebih mudah. Manfaat kedua untuk pengujian berkelanjutan adalah memaksa Anda untuk membuat tes Anda dalam kondisi kerja; tidak ada yang lebih membosankan daripada menghabiskan minggu pertama siklus tes memperbaiki semua tes yang ketinggalan zaman. Jika Anda dapat mengotomatiskannya, Anda dapat menjalankannya kapan saja & dengan menjalankannya secara teratur, Anda dapat menangkap bug dalam pengujian atau kode Anda dengan cepat.

Biaya Tes

Setelah tes otomatis ditulis, ini dapat dijalankan oleh komputer dengan biaya beberapa joule. Tes manual yang setara mengharuskan seseorang di daftar gaji mengerjakan daftar instruksi.

Uji Reliabilitas

Komputer dapat dipercaya untuk secara setia menjalankan prosedur pengujian yang sama, setiap saat. Manusia cenderung melakukan kesalahan dan malas.

Mode kegagalan pengujian komputer juga jauh lebih mudah terlihat - itu macet (laporan pengujian berhenti muncul), itu memiliki sedikit kesalahan yang menyebabkan hasil tes palsu (jalankan tes deterministik lagi, dan hasilnya berbeda). Jika manusia melewatkan satu langkah dan mengecek "OK", bagaimana kita bisa tahu?

Uji Daya Tahan

Tes otomatis harus berupa artefak konkret (misalnya sepotong kode) agar dapat dijalankan, dan secara alami disertakan dengan artefak pengembangan perangkat lunak lainnya - sumber repositori. Tes manual dapat dikembangkan pada selembar kertas catatan oleh tester, dan tidak pernah diformalkan. Bisnis lebih cenderung membutuhkan proses untuk memastikan hal itu tidak terjadi.

Nilai Tes

Komputer dapat diprogram untuk menghasilkan hasil tes dalam bentuk yang konsisten dan mudah dianalisis. Orang tersebut melakukan entri data untuk menghasilkan hal yang sama, atau merekam catatan bentuk bebas yang membutuhkan analis, pengembang, atau manajer untuk dicerna.

Sebagian besar (tergantung pada cakupan tes Anda) kode bebas bug, dan saya akan mengatakan bahwa salah satu argumen terbesar adalah ketika Anda mengatakan kepada manajer Anda bahwa Anda dapat menulis tes untuk bug yang ditemukan, memastikan Anda akan selalu tahu di masa depan jika bug itu kembali :)

Pendapat saya adalah bahwa tes unit / integrasi paling penting, sedangkan jika Anda menerapkan beberapa pola UI seperti MVC, itu sudah cukup untuk sebagian besar proyek. Saya biasanya menguji semua tindakan pada controller / presenter saya, dan membiarkan penyatuan data ke Views.

Tentu saja, pengujian otomatis tidak menggantikan titik lama yang baik dan klik berpetualang di sekitar aplikasi Anda mencoba mencari tahu hal-hal terliar yang bisa dilakukan pengguna Anda.

Ada juga titik Integrasi Berkelanjutan .

Satu hal lagi - seseorang harus berusaha agar kualitas kode mengarah pada kualitas produk, nilai bisnis, dan pemeliharaan - jika tidak, tidak ada gunanya melakukannya.

Saya pikir Anda harus memimpin dengan poin ajaib dari "Biaya lebih rendah" dan "lebih banyak Fitur / satuan waktu" / siklus-waktu yang lebih kecil.

Namun sebelum mengajukan kasus, saya sarankan untuk merenungkan situasi Anda. Pertanyaan Anda membuat saya menulis posting blog tentang potensi kontra pengujian otomatis.

Kemudahan refactoring adalah faktor besar di sini. Memiliki cakupan yang baik dengan uji unit yang bagus dan READABLE (!!!), Anda dapat memperbaiki sistem Anda tanpa merasa gugup dengan mengorbankan fungsionalitas yang ada.

Anda harus menjual konsep - Anda harus menghindari memberi tahu mereka bahwa itu akan meningkatkan kode. Jika mereka memiliki investasi dalam kode yang akan segera menempatkan mereka anti Anda / pengujian otomatis. Jika ada gunanya mereka juga akan mengerti GIGO jadi tidak akan mengerti mengapa Anda berpikir itu tidak berlaku.

Saya akan meninggalkan penjualan sebagai aspek dokumentasi juga, hal-hal seperti Fitnesse dapat melakukannya dengan baik, tetapi sampai mereka mengalaminya mungkin sulit untuk divisualisasikan.

Area yang saya pikir mungkin memiliki keberuntungan untuk menjualnya

1. Tes Unit dapat menggantikan banyak memanfaatkan pengembang - di mana Anda membuat aplikasi hanya untuk mendapatkan area untuk debug / uji tanpa melalui semua login / menu.

2. Tes memungkinkan Anda untuk mengatur dan dengan mudah mengulangi situasi masalah - tanpa menghabiskan banyak waktu menyiapkan data uji (terutama menggunakan sistem ejekan yang layak)

3. Ketika Anda membangun suite tes BDD & UI - Anda mendapatkan respons yang jauh lebih cepat jika ada jeda sederhana daripada menunggu waktu berikutnya tester melihatnya

4. Tes BDD & UI dapat menghindari Anda berulang kali menekan tombol untuk memeriksa semua aspek yang mungkin telah dipengaruhi oleh perubahan Anda dan menghemat Anda harus mengingat setiap bidang.

5. Pembuatan otomatis sering disorot ketika seseorang lupa kode masuk

6. Tes membantu Anda menghindari bug muncul kembali.

7. Tes Unit dan penghinaan yang layak akan berarti lebih sedikit kode yang saling terkait dan akan lebih mudah untuk diselesaikan

Ingat Anda mencoba menjualnya, bukan mengubahnya menjadi agama - jadi terimalah langkah-langkah kecil dan cobalah untuk tidak membuatnya anti-Anda. Mereka juga perlu waktu untuk menyesuaikan dan belajar menulis tes yang bagus.

Seseorang harus percaya ada masalah sebelum mereka akan menerima solusi yang diusulkan untuk masalah itu.

Tes otomatis dapat menghemat biaya perbaikan bug, jadi jika rekan Anda tidak percaya bahwa biaya perbaikan bug cukup besar atau berlebihan, mereka akan sulit diyakinkan. Jika biaya itu tinggi atau berlebihan, tetapi orang-orang tidak percaya itu, Anda mungkin harus terlebih dahulu mendapatkan data yang meyakinkan tentang biaya tersebut.

Apa yang disukai bisnis adalah meningkatkan nilai dan menurunkan biaya. Anda harus menjelaskan bagaimana pengujian otomatis akan meningkatkan nilai karena hal itu menambah biaya tambahan.

Jika kode Anda modular, Anda dapat menggunakannya kembali. Yang berarti bahwa tes tidak harus ditulis lagi dan Anda hanya dapat bekerja di atas kode yang ada.

Jika ada proyek lawas, pengujian otomatis membuatnya lebih mudah untuk refactor. Utang teknis harus dibayar di beberapa titik.

Argumen dokumentasi yang Anda berikan tidak terlalu bagus. Perbedaan antara menjaga agar tes selalu mutakhir dan dokumentasi selalu mutakhir hanyalah kebiasaan.

"Apa yang saya cari bantuan adalah mengartikulasikan nilainya ke tim pemrogram, analis, manajer dan penguji. Dengan tes otomatis, saya tidak berpikir saya perlu membuat perbedaan antara tes unit (misalnya JUnit), BDD ( misalnya JBehave, Kebugaran) dan UI (Selenium, Watir) karena saya pikir mereka semua memberikan nilai yang sama (tapi jangan ragu untuk menulis jawaban yang tidak setuju :)) "

OK saya akan menerima tantangan itu;)

Saya kebanyakan bekerja dengan programmer dan QA dan alat saya ruby, rails, testunit, rspec, melati dan selenium.

Alat BDD / TDD dari rspec dan testunit adalah bagian dari pemrograman. Anda tidak memecahkannya dan membicarakannya secara terpisah dengan manajemen, Anda tidak menunda karena kurangnya waktu, Anda memasukkannya ke dalam semua perkiraan waktu Anda. Jika benar-benar didorong, tanyakan berapa banyak waktu yang dimiliki orang untuk menjelaskan ilmu komputer dan pemrograman kepada mereka. Saya tidak menggunakan tes ini untuk ujung depan

GUI / UI / Jasmine / Selenium. Ini berbeda. Saya memiliki ini dilakukan oleh orang-orang QA yang memiliki latar belakang programmer. Kami memastikan pengujian ditulis agar sekuat mungkin dan berdasarkan konten bukan tata letak. Biaya (mungkin baru) ini harus dijelaskan sebagai biaya bergeser . Alih-alih membayar dengan perangkat lunak yang rusak, pelanggan yang hilang dan perbaikan mahal kemudian, Anda membayar lebih sedikit (relatif) sekarang dengan beberapa praktik sederhana.

Saya pikir kuncinya adalah berbicara tentang kategori tes tertentu yang akan Anda buat, bukan 'pengujian otomatis' secara keseluruhan. Yang terakhir bisa agak samar-samar dan mengkhawatirkan, dan terlalu mudah untuk memberikan contoh di mana itu akan membuang-buang waktu.

Saya selalu merekomendasikan membagi tes Anda menjadi 4 kelompok (lebih detail di sini ). Tetap bersama saya di sini, saya akan membahas bagaimana ini membantu Anda menjual pengujian kepada orang lain dalam waktu singkat.

1. Tes fungsionalitas inti Anda . Yaitu, untuk alat pemantauan situs web, ini akan menjadi tes peringatan yang harus diaktifkan untuk situs web yang Anda pantau. Tes-tes ini memastikan hal-hal ini tidak pernah rusak.
2. Tes asap dari seluruh aplikasi Anda . Misalnya, menggunakan Selenium untuk menavigasi semua tautan / tombol di aplikasi web dan pastikan tidak ada kesalahan dari server. Tes ini menghindari Anda membuang-buang waktu penguji dengan membangun yang jelas rusak.
3. Tes dari setiap kode yang rapuh . Yaitu, untuk modul lama itu tidak ada yang ingin disentuh, atau potongan kode kompleks yang sepertinya selalu memiliki bug di dalamnya.
4. Tes yang ingin ditulis para dev untuk mendukung pekerjaan mereka . Karena terkadang tes berguna ketika Anda menulis sesuatu, tetapi jangan termasuk dalam kategori di atas.

Dengan membagi tes Anda ke dalam kategori ini sekarang Anda dapat memiliki diskusi yang berbeda. Ambil tiga kelompok pertama (yang keempat adalah atas kebijaksanaan individu) dan tanyakan apakah orang berpikir tes untuk potongan kode itu akan bermanfaat? Jika Anda tidak bisa mendapatkan persetujuan, mungkin Anda tidak memasukkan tes itu untuk saat ini. Jika Anda bisa, yaitu jika orang setuju bahwa tes seputar fungsionalitas inti yang dijalankan pada setiap komit bermanfaat, maka mulailah menambahkannya.

Kelompok lain yang dapat berguna adalah tes yang sulit atau memakan waktu untuk dilakukan secara manual . Seharusnya ada manfaat yang cukup mudah dijelaskan di sini dalam hal menghemat waktu pengujian manual, atau menguji hal-hal yang dilewati karena kurangnya waktu.