Bagaimana saya bisa memulai pengujian di pengujian anti budaya [Tutup]


20

Saya memiliki pengakuan untuk dibuat: Pengujian otomatis yang diformalkan tidak pernah menjadi bagian dari latar belakang pemrograman saya. Saya sekarang bekerja di perusahaan yang sangat besar dengan banyak pengembang (kebanyakan dari mereka adalah pengembang web dari satu jenis atau lainnya), dan jelas bahwa sebagian besar dari mereka tidak menguji *. (* Saya tidak akan terus mengatakan secara formal ; tolong simpulkan.)

Jika saya menunggu untuk mendapat dukungan dari organisasi saya untuk memulai pengujian itu tidak akan pernah terjadi. Jika saya mencoba "mengubah sesuatu dari dalam" dengan mendorong pengujian pada manajemen, saya akan kehabisan tenaga sebelum perubahan terjadi. Saya perlu memulai pengujian sekarang.

Tetapi dengan TDD dan sejenisnya aku akan berakhir dengan banyak kode pengujian tepat bersama dengan kode produksi. Sistem kontrol versi kami (semua terpusat) tidak terorganisir untuk menyimpan kode pengujian. Saya harus menemukan tempat untuk semua itu di stasiun kerja saya.

Apakah mungkin untuk memulai praktik pribadi pengujian perangkat lunak dalam budaya yang tidak menghargai atau menyediakan alat untuknya? Teknik dan alat apa yang Anda gunakan untuk memungkinkan Anda menguji ketika alat dan organisasi resmi tidak memiliki tempat untuk pengujian, kerangka kerja dan otomatisasi?


14
Mengapa Anda tidak dapat menyimpan kode pengujian di VCS perusahaan Anda? Saya membayangkan bahwa dalam proyek yang memiliki srcdirektori untuk kode produksi, akan mungkin untuk menambahkan testdirektori juga - atau apakah itu secara eksplisit dilarang karena alasan tertentu?
Péter Török


@ PéterTörök Anda melebih-lebihkan kami. Kami tidak memiliki srcdirektori, kami memiliki root web. Untuk memeriksa kode saya ke VCS pusat saya akan memeriksanya ke root web.
kojiro

Jika Anda tidak memiliki kontrol sumber dalam budaya antitesting Anda, saya akan mencoba untuk melakukannya terlebih dahulu (atau juga) karena itu akan memecahkan banyak masalah lain yang saya yakin tim Anda sedang mengalami. Kemudian meletakkan dasar untuk apa yang ingin Anda lakukan untuk pengujian.
Scott Wylie

@ScottWylie Saya tidak cukup mengatakan itu. Kami memiliki VCS, kami hanya tidak mengelolanya untuk pengujian (atau banyak hal di luar pengeditan langsung untuk hal-hal webroot). Saya pikir keponakan seseorang membuat CVS pada tahun 1998 dan tidak ada yang mengubahnya sejak itu.
kojiro

Jawaban:


22

Saya pribadi telah melakukan ini dengan cukup sukses. Faktor kunci untuk sukses:

  • Dapatkan dukungan manajemen (sementara). Keuntungan dari tes otomatis didokumentasikan dengan baik dan harus meyakinkan manajer mana pun untuk setidaknya mencobanya. Itu termasuk menemukan tempat di VCS dan membangun server, karena
  • Tes otomatis hanya memberikan nilai penuh jika dijalankan secara rutin dan otomatis sehingga Anda segera mengetahui masalah dan tidak harus bergantung pada orang yang tidak lupa menjalankannya. Anda perlu membangun server yang menjalankannya setidaknya setiap hari. Ini bisa menjadi workstation lama. Jenkins hanya membutuhkan sedikit kerja untuk bisa berlari.
  • Menurut contoh. Tulis tes, bicaralah tentang manfaat yang mereka berikan kepada Anda, dan ketika mereka mengungkapkan kesalahan yang diperkenalkan oleh pengembang lain membicarakannya dalam hal bagaimana mereka dilindungi dari kemungkinan rasa malu yang jauh lebih besar.
  • Pilihlah buah yang menggantung rendah. Beberapa bagian dari aplikasi akan sulit untuk diuji, yang lain mudah. Beberapa akan kuat, yang lain rapuh. Tes tertulis untuk komponen rapuh, tetapi mudah untuk menguji memberikan nilai paling dalam waktu singkat.
  • Lihat apakah Anda dapat menulis tes yang dapat digunakan kembali, mis., Konvensi atau fitur pengujian yang harus dimiliki semua modul (halaman web, layanan REST, apa pun) tetapi yang sering dilupakan.

7

Tanpa dukungan manajemen Anda mati di dalam air. Manajemen akan mengklaim bahwa Anda tidak melakukan pekerjaan yang layak, Anda akan dikenakan sanksi dalam ulasan Anda, dan akhirnya Anda akan dipecat. Ada cara untuk membawa manajemen untuk melihat bahwa pengujian awal lebih murah biayanya. Dimungkinkan untuk mengubah budaya tetapi Anda meletakkan leher Anda di blok memotong.

Saya sarankan membaca bab Machiavelli The Prince tentang cara memperkenalkan perubahan sebelum melakukan apa pun.


Milik Anda adalah jawaban kedua yang menunjukkan bahwa pengujian akan menghabiskan waktu yang tidak akan dihabiskan. Tetapi menguji penginjil (menurut saya) akan memberi tahu Anda bahwa pengujian menghemat waktu. Tidak hanya dalam jangka panjang, tetapi bahkan dalam jangka hingga proyek jangka menengah, karena Anda tidak akan menghabiskan banyak waktu debugging kode produksi Anda, dan tes memaksa Anda untuk menyesuaikan kode untuk melewatinya, yang (dalam saya pemahaman teori) semua berfungsi untuk mengurangi keseluruhan waktu yang dihabiskan pengkodean. Sudahkah Anda menemukan bahwa tidak demikian halnya?
kojiro

1
@ Kojiro: Ya, pengujian keseluruhan akan mengurangi waktu dan biaya. Namun, itu tidak akan dilakukan dalam jangka pendek. Beberapa manajer memandang jangka pendek sebagai hal yang lebih penting. Lagi pula, apa yang merupakan perangkat lunak yang baik jika tidak ada yang dibayar perusahaan dan dapat membebani pelanggan untuk perbaikan bug.
Sardathrion

2
Pengujian menghemat waktu, tetapi ketika Anda harus mengulang setengah dari kode untuk diuji, Anda membuang-buang waktu pada awalnya melakukan semua itu hanya untuk, berbulan-bulan di jalan, dapat memiliki tes dan kemudian mempercepat. Manajer tidak berpikir dalam "bulan ke depan" mereka berpikir dalam "bulan ini", jadi yang mereka lihat adalah "buang-buang waktu" karena pengembang itu tidak membuat kode baru yang mereka mainkan dengan tes yang kita bisa ' t menjual atau, lebih mungkin, kode refactoring yang "sudah berfungsi"
Wayne Molina

Biasanya, bahkan dalam jangka pendek itu akan menghemat waktu. Ketika Anda mengerjakan sesuatu, itu jauh lebih cepat untuk dapat menggunakan sepotong kode melalui tes, kemudian harus menjalankan seluruh aplikasi dan membujuknya untuk mengeksekusi sepotong kode tertentu.
Stefan Billiet

3

Dalam pengalaman saya jika budaya anti-pengujian, Anda tidak bisa memperkenalkannya secara wajar. Entah tes akan dilihat sebagai buang-buang waktu dan Anda akan ditegur karena "membuang-buang waktu" atau "terlalu lama", atau kode telah dirusak sejak bertahun-tahun karena tidak ditulis dengan cara yang dapat diuji (mis. Tanpa antarmuka, semuanya digabungkan dengan erat) dan Anda harus menghabiskan banyak waktu untuk refactoring dan / atau menulis ulang kode (sehingga berisiko "terlalu lama" dan "membuang-buang waktu") untuk membuatnya dapat diuji sehingga Anda dapat menulis tes di tempat pertama .

Anda mungkin memiliki kesempatan jika Anda melakukan hal-hal greenfield yang hanya harus berinteraksi dengan hal-hal yang ada (membuat pembungkus yang bagus di sekitar area buruk) atau jika Anda dapat melakukannya dalam jumlah kecil di mana itu tidak akan menyebabkan masalah atau mengharuskan Anda untuk "kerjakan tugas-tugas yang tidak ditugaskan kepadamu" yang dapat menempatkanmu di rumah anjing.


1

Saya tidak berpikir Anda akan melangkah terlalu jauh sampai Anda dapat membuat kasus yang cukup baik bahwa ada masalah (yang saat ini mungkin tidak dikenali) yang dapat diatasi dengan pengujian otomatis.

Jika ada budaya pengujian manual terhadap skrip yang ditetapkan, maka ada biaya untuk mengeksekusi skrip tersebut ditambah dengan risiko hasil yang tidak lengkap atau tidak akurat. Mungkin ada sejarah (didokumentasikan atau dalam bentuk "kisah perang") ini. Sarankan proyek percontohan untuk mengotomatisasi beberapa tes manual tersebut dengan maksud untuk memberikan penghematan biaya jangka panjang.

Jika bahkan tidak ada fungsi pengujian manual maka saya akan menyarankan bahwa bisnis tidak menganggap bahwa segala jenis pengujian formal, otomatis atau sebaliknya, memiliki nilai. Dalam hal ini saya akan menganggap jalan di depan panjang dan curam, tetapi sekali lagi itu mungkin memerlukan demonstrasi yang jelas bahwa bisnis dapat memperoleh manfaat dari mengadopsi pendekatan yang kurang kasual untuk kualitas perangkat lunak. Jika Anda tidak dapat melakukan itu maka sulit untuk melihat bagaimana mungkin ada dukungan untuk ide dengan alasan komersial.


0

Satu ide adalah bahwa Anda bertujuan untuk menulis tes yang membuktikan bahwa kode yang ditulis orang lain salah. Harus menjual konsep.

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.