Pengujian Otomatis: Menjelaskan Nilai Bisnisnya


25

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

Jawaban:


21

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.

1
+1 jawaban yang bagus. Tautan menarik ke artikel James Shore. Saya akan menambahkan The Clean Coder oleh Robert Martin ke daftar buku Anda. Saya pikir pengembang membuat tes UI harus mencakup jalur bahagia sementara QA (jika ada) menulis pengecualian. Tes unit harus benar-benar menangani kasus-kasus luar biasa.
orangepips

@orangepips - Terima kasih atas rekomendasi buku. Satu kelemahan dari tes UI ini menjadi jalur bahagia dan kemudian pengujian unit yang mencakup pengecualian adalah bahwa lebih sulit untuk menulis tes unit tersebut jika Anda tidak melakukan pengujian unit untuk semuanya. Pengujian unit membantu mendorong testabilitas aplikasi Anda dengan menjaga kopling tetap rendah sementara tes UI tidak mengharuskan kode di bawahnya digabungkan secara longgar.

dimaksudkan untuk menulis Tes Unit harus mencakup semuanya.
orangepips

1
@orangepips - Saya tidak setuju. "Level QA" / Tes penerimaan harus menguji semua yang penting bagi pengguna .. yaitu jalur bahagia dan skenario alternatif. Tes unit sering menggunakan tiruan, bertopik dan palsu ... yang berarti ada kemungkinan bahwa tes happy path unit dilewati tetapi ketika semua komponen disatukan, tes end-to-end happy path mungkin gagal. Terlalu banyak peluang untuk dibiarkan takdir.
Gishu

2
@orangepips - Keberatan saya terkait dengan QA / Dev Pengecualian / Selamat membagi. Tes unit ada untuk memastikan bahwa Anda membangunnya dengan benar. QA / Tes penerimaan ada untuk memastikan bahwa Anda membangun sistem yang tepat. Jadi semua skenario yang relevan dengan bisnis (misalnya kartu kredit telah kedaluwarsa) harus diuji oleh QA sebelum mereka mencantumkannya siap dikirim. Saya merekomendasikan otomatisasi tes penerimaan - Mengotomatiskan hal-hal rutin yang membosankan, 80% +. Lengkapi itu dengan beberapa pengujian manual non-skrip imajinatif.
Gishu

9

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.


7

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.


+1 untuk gagasan pelaporan dan untuk referensi joule.
orangepips

"Komputer dapat dipercaya untuk dengan setia menjalankan prosedur pengujian yang sama, setiap kali" Perlu diingat bahwa beberapa kesalahan ditemukan oleh orang yang melakukan sesuatu dengan cara yang tidak terduga. Seringkali penguji yang berbeda akan melakukan serangkaian instruksi yang sama dengan cara yang berbeda. Ini adalah hal yang baik karena meningkatkan cakupan pengujian sehingga meskipun otomatisasi pengujian menghemat waktu dan merupakan cara yang bagus untuk memeriksa kemungkinan kegagalan & regresi, pengujian ini tidak dapat sepenuhnya menggantikan pengujian manusia.

Dalam hal ini, tampaknya lebih baik untuk memberi para penguji manusia daftar umum bidang yang perlu dijelajahi dan hal-hal yang harus dicoba, dan bukan petunjuk terperinci yang harus mereka ulangi dengan setia.
Phil Miller

4
@TafT: hanya orang miskin atau bodoh yang pergi tanpa pengujian manual, tetapi pengujian manual dengan nilai tertinggi saya percaya lebih bersifat mengeksplorasi daripada menulis di alam. Dengan demikian dorongan untuk mengotomatisasi apa yang bisa.
orangepips

5

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.


+1 untuk Integrasi Berkesinambungan dari sudut pandang teknis. Tapi, saya tidak yakin bagaimana saya melihat saran Anda memfasilitasi percakapan dengan staf non-teknis (misalnya analis). Juga, apa pendapat Anda tentang memvalidasi di beberapa browser dan OS?
orangepips

Yah, saya hanya bisa memberi tahu pihak saya dari sudut pandang pengembang, tentang para analis - Saya tidak benar-benar memahami peran mereka dalam proyek yang sangat besar - jadi tidak ada saran nyata di sana. Tentang tes lintas-browser lintas-browser, tidak memiliki kesempatan untuk melakukan keduanya.
Denis Biondic

2

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.


Memberi +1 untuk posting blog yang bagus, meskipun poin-poin itu adalah sesuatu yang akan diangkat di sini. Menurut saya perhatian utama adalah tidak memiliki programmer yang hanya mengikuti gerakan. Untuk itu, bagaimana Anda menyarankan mempromosikan kualitas atau setidaknya menghindari suasana yang mencegahnya?
orangepips

tautan yang bagus. Mematangan proses perangkat lunak apa pun membutuhkan banyak pekerjaan. Saya pikir konsekuensi penting juga mengurangi turnover sehingga Anda memiliki cukup banyak orang dengan memori organisasi dan kepercayaan untuk memajukan sesuatu seperti ini.
orangepips

1

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.


apakah ini berbeda dari poin saya # 1?
orangepips

@orangepips: Tidak, saya melewatkan bagian itu. Maaf: o) Namun, penting untuk ditekankan
Morten

1

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.


+1 untuk komentar agama. Saya pikir ada masalah mengidentifikasi apa yang berharga untuk menulis tes otomatis dan jelas jawabannya bukan segalanya. OTO, saya pikir kita lebih baik memiliki setidaknya beberapa pengujian otomatis. Mungkin kunci sebenarnya adalah mengakui bahwa paling tidak dalam organisasi saya hambatan SDLC adalah QA. Jadi usaha saya sendiri diarahkan untuk memperlancar kurva usaha dengan membuat pengembangan memikul sebagian tanggung jawab itu.
orangepips

Sehubungan dengan nomor 3) ini memungkinkan Anda untuk membangun statistik dan membentuk laporan; jelas bisa menjadi nilai jual yang besar. Minggu ini memperkenalkan fitur X menyebabkan 10 tes gagal yang kami deteksi dalam waktu Y berkat pengujian otomatis adalah "kemenangan" yang bagus untuk sebuah proyek, juga membantu mendokumentasikan risiko memperkenalkan fitur baru di masa depan.

1

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.


1
jadi dari mana menurut Anda informasi itu seharusnya berasal?
orangepips

0

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.


Dalam pengalaman saya menggunakan kembali kode adalah kualitas perangkat lunak yang muncul tidak direncanakan. Dengan kata lain, tidak sampai saya menulis ulang hal yang sama untuk ketiga, keempat atau kelima kalinya saya benar-benar mengerti bagaimana membuatnya dapat digunakan kembali. Jadi saya pikir manajer sering merasa dibakar oleh gagasan dari programmer "beri saya lebih banyak waktu untuk membangunnya dengan benar dan itu akan mengarah pada penghematan biaya" karena dalam praktiknya saya menemukan ini sebagai pendekatan yang umumnya salah.
orangepips

0

"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.


0

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.

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.