Haruskah pengembang bertanggung jawab atas pengujian selain pengujian unit, jika demikian yang mana yang paling umum?


35

Saat ini saya sedang mengerjakan proyek yang agak besar, dan saya telah menggunakan JUnit dan EasyMock untuk fungsionalitas unit test yang cukup luas. Saya sekarang tertarik pada jenis pengujian apa yang harus saya khawatirkan. Sebagai pengembang, apakah tanggung jawab saya untuk mengkhawatirkan hal-hal seperti pengujian fungsional, atau regresi? Apakah ada cara yang baik untuk mengintegrasikan ini dengan cara yang bisa digunakan dalam alat-alat seperti Maven / Ant / Gradle? Apakah ini lebih cocok untuk Penguji atau BA? Apakah ada jenis pengujian lain yang bermanfaat yang saya lewatkan?


2
Meskipun sederhana dalam praktik, skalakan sejauh yang diizinkan di lingkungan Anda sambil tetap berbicara dalam praktik versus terisolasi, yang biasanya ada. Pikirkan tim ujung ke ujung sebagai lebih dari segregasi dan lebih banyak tentang keahlian, masing-masing tim mewakili keterampilan yang bervariasi yang harus ditingkatkan untuk kesuksesan ujung ke ujung. The tim harus bertanggung jawab untuk keberhasilan yang tes diperlukan untuk mencapai. Bagaimana mereka ditangani sehubungan dengan implementasi hanya itu, detail implementasi berdasarkan pada keahlian.
Aaron McIver

1
Jawaban untuk pertanyaan ini juga akan tergantung pada tingkat keterampilan anggota tim lainnya. Misalnya, pada tim di mana QA tidak memiliki keterampilan pemrograman yang kuat, pengembang mungkin menemukan diri mereka melakukan lebih dari pada tim di mana QA dapat menulis uji coba mereka sendiri.
neontapir

Kriteria yang baik adalah seberapa otomatis tes tersebut. Pemrogram pandai mengotomatisasi hal-hal dengan kode.
rwong

Jawaban:


44

Adalah tanggung jawab Anda untuk berusaha memberikan kode bebas cacat. Anda harus menulis, membantu menulis, atau memastikan tes ditulis atau dilakukan untuk memberikan Anda kepercayaan pada kode yang Anda berikan.

Catatan: Saya tidak mengatakan Anda diminta untuk memberikan kode bebas cacat. Sebaliknya, Anda harus berusaha menulis kode terbaik yang Anda bisa untuk persyaratan yang Anda berikan. Bagian dari kemampuan melakukan itu berarti kode harus diuji.

Apakah itu berarti Anda bertanggung jawab secara pribadi untuk tes fungsional dan regresi sebagian besar merupakan fungsi dari bagaimana perusahaan Anda diatur. Semua programmer dengan ketrampilan tertinggi yang saya tahu tidak bertanya pada diri sendiri "apakah ini tanggung jawab saya untuk menulis tes tipe X?". Sebaliknya, mereka bertanya pada diri sendiri "apa yang harus saya lakukan untuk memastikan kode saya diuji dengan benar?". Jawabannya mungkin menulis tes unit, atau menambahkan tes ke regresi, atau mungkin berarti berbicara dengan seorang profesional QA dan membantu mereka memahami tes apa yang perlu ditulis. Namun, dalam semua kasus, itu berarti mereka cukup peduli dengan kode yang mereka tulis untuk memastikan kode tersebut diuji dengan benar.

Intinya: Anda harus bertanggung jawab untuk memberikan kode berkualitas tinggi. Jika itu berarti Anda perlu menulis beberapa tes fungsional atau regresi, lakukanlah.


Saya setuju dengan sepenuh hati dengan memberikan bagian kode berkualitas tinggi. Saya merujuk lebih ke "di atas dan di luar" kode yang baik. Misalnya, lakukan perubahan yang dianggap "bebas bug" dalam perspektif Anda memiliki kinerja negatif di tempat lain. Contoh terbaik yang bisa saya pikirkan adalah persyaratan tidak diperiksa dengan benar untuk beban. Jadi kode saya menyebabkan masalah memuat di server meskipun itu "bebas bug" (ok jadi argumen dapat dibuat bahwa itu bukan humor saya). PS Saya pikir bagian kepercayaan diri Anda adalah kunci di sini.
Jackie

10
Merupakan tanggung jawab Anda untuk memberikan kode bebas cacat. Ini merupakan tanggung jawab pengembang untuk membangun apa yang diminta . Cacat dapat dan muncul dari persyaratan yang tidak dikumpulkan / diinterpretasikan dengan buruk, masalah lingkungan dalam penerapan yang diberikan, konflik dalam OS, dll ... Kecuali analisis akar permasalahan dilakukan pada setiap cacat, kode bebas cacat untuk bisnis berarti yang mereka harapkan untuk melakukan apa yang diharapkan pengguna dan apa pun yang kurang adalah cacat. Adalah tidak realistis untuk menganggap pengembang dapat tetap terlibat di seluruh SDLC hanya untuk meningkatkan kepercayaan diri; itu tidak akan skala.
Aaron McIver

2
"Pengujian program bisa menjadi cara yang sangat efektif untuk menunjukkan keberadaan bug, tetapi tidak memadai untuk menunjukkan ketidakhadiran mereka." - Edsger W. Dijkstra, "The Humble Programmer" (kuliah Penghargaan Turing), 1972.
John R. Strohm

1
"Adalah tanggung jawabmu untuk memberikan kode bebas cacat." adalah negeri peri. Anda dapat memberikan apa yang diperlukan ruang lingkup tetapi kasus tepi dan interpretasi logika bisnis membuat pernyataan Anda tidak mungkin untuk hidup sesuai. Menurut Anda mengapa setiap rilis utama perangkat lunak memiliki rilis dan tambalan dll? Karena kita semua tidak sempurna termasuk logika bisnis.
Jason Sebring

4
Apakah semua orang yang mempermasalahkan kalimat pertama jawaban ini akan lebih bahagia jika Bryan mengatakannya, "Adalah tujuan Anda untuk memberikan kode bebas cacat"?
Carson63000

13

Ini mungkin membantu Anda:

Kuadran pengujian lincah

Q1 ditulis oleh pengembang.

Q2 diotomatisasi oleh pengembang dan ditulis dalam kolaborasi dengan bisnis dan / atau penguji.


Pengembang juga sering terlibat dalam pengujian Q4.
neontapir

File tertaut tidak dapat ditemukan lagi.
Dušan Rychnovský

3

Apakah ada jenis pengujian lain yang bermanfaat yang saya lewatkan?

Ada pengujian penerimaan yang saya sarankan kerangka kerja gaya BDD yang menggunakan bahasa Gherkin : JBehave (Java), Mentimun (Ruby), Behat (PHP), dll. Jenis pengujian ini memiliki beberapa keunggulan dibandingkan pengujian unit:

  • Tes mudah dibaca oleh non-pengembang, sehingga Anda dapat menunjukkannya kepada pelanggan
  • Tes dengan jelas menggambarkan proses bisnis tanpa masuk ke detail implementasi (maksud saya implementasi tidak penting - itu memang benar - tetapi lebih baik ketika Anda memisahkan persyaratan bisnis dari kode itu sendiri)
  • Tes melakukan hal-hal yang akan dilakukan pengguna menggunakan aplikasi Anda
  • Mereka lebih mudah untuk menulis (IMHO, mungkin tergantung pada bahasa dan kerangka kerja): tidak ada mengejek, rincian teknis yang lebih sedikit

3

Tes fungsional dapat diotomatisasi seperti halnya pengujian unit, dan sangat berguna untuk menguji bagaimana berbagai komponen proyek Anda bekerja bersama, dan seberapa baik sistem Anda mencerminkan aturan bisnis.

Juga, tes otomatis ini, berfungsi sebagai paket uji regresi dan penerimaan untuk setiap perubahan besar (atau kecil) yang harus Anda lakukan untuk perangkat lunak (perbaikan bug, refactor, perubahan bisnis, fungsionalitas baru, dll). Ini memberi pengembang lebih percaya diri untuk melakukannya.

Ada beberapa kerangka kerja untuk pengujian semacam ini, kami menggunakan fitnesse dengan hasil yang sangat bagus. Memiliki pustaka yang sangat baik untuk menguji halaman web (kami menggunakannya untuk menguji aplikasi web kami dan layanan web kami) dan terintegrasi dengan sangat baik dengan Maven dan Jenkins .

Kami juga biasa melakukan "pengujian lintas fungsional", di antara pengembang, tetapi pengujian semacam ini tidak "berulang", jadi kegunaannya terbatas ...


2

Sebagai seorang pengembang, saya menganggap diri saya bertanggung jawab atas unit yang menguji semua kode saya dan menjamin yang terbaik dari kemungkinan saya yang tidak cacat. Itu sebabnya kami memiliki begitu banyak alat yang dapat digunakan seperti mengejek. Tujuan membuat objek mengejek dalam pengujian Anda adalah untuk mencoba dan mengisolasi kode Anda dari dunia "luar" dan menjamin bahwa itu berfungsi dengan baik dan jika ada sesuatu yang gagal, "itu bukan salah Anda".

Yang sedang berkata, terlepas dari kenyataan bahwa itu bukan kesalahan Anda dan bahwa kode Anda berfungsi sebagaimana mestinya, itu tidak berarti Anda tidak dapat membantu dalam sisa tes. Saya percaya ini juga tanggung jawab Anda untuk membantu dan mengintegrasikan pekerjaan Anda pada pekerjaan yang dibuat oleh orang lain. Tim Pengembangan TI harus bekerja setiap saat sebagai mesin yang diminyaki dengan baik, bekerja bersama dengan departemen lain (seperti QA) sebagai tim yang lebih besar untuk menyediakan perangkat lunak yang andal.

Tapi itu pekerjaan tim, bukan hanya milikmu.


1

Jelas tes integrasi ; mereka lebih penting dan lebih sulit untuk ditulis daripada tes unit. Ini seperti membangun rumah; dengan pengujian unit, Anda hanya memastikan fakta bahwa batu bata itu solid dan tahan terhadap tekanan, suhu, kelembaban, dan kondisi lainnya. Tetapi Anda tidak memiliki petunjuk bagaimana rumah terlihat dan berperilaku dengan batu bata disatukan.

Masalah dengan proyek-proyek besar, terutama yang berada di wadah Java adalah bahwa pengujian integrasi sulit. Jadi untuk memfasilitasi tes integrasi sistem dalam proyek-proyek besar, kerangka pengujian diperlukan, dibuat khusus untuk proyek, yang merupakan tugas pengembang untuk mengkodekannya. Baru-baru ini perbaikan besar telah dibuat di bidang ini dan platform seperti Arquillian sangat menyederhanakan penulisan kerangka pengujian (atau bahkan menggantikannya).


1

Di dunia nyata Anda hanya bertanggung jawab sebagaimana tim / bos Anda meminta pertanggungjawaban Anda. Jika Anda dibayar atau diminta untuk bekerja keras tanpa henti untuk menemukan setiap sudut dan celah celah dan melompat ke tingkah bos Anda (atau pemasaran yang lebih buruk) interpretasi bug logika bisnis, maka dengan segala cara, Anda bertanggung jawab untuk semua.

Jadi dengan kata lain, lakukan apa yang diminta oleh ruang lingkup yang diberikan kepada Anda. Merupakan tambahan yang bagus untuk menggunakan akal sehat atau melihat orang lain menggunakan produk yang Anda bangun untuk mendapatkan rasa menggunakan kasus dan kemungkinan masalah untuk memperbaiki tetapi membawa ini ke tim atau bos Anda sebelum "memperbaiki". Ini termasuk alat yang Anda pilih. Semua usaha Anda harus menjadi sesuatu yang menjadi perhatian semua orang.

Jika pertanyaan Anda tentang pelacakan bug yang berguna, saya suka bugzilla, google docs, zendesk atau basecamp dalam hal sistem komunikasi.


1

Saya tidak berpikir ini sudah dibahas - maaf jika saya melewatkannya.

Salah satu masalah adalah penggunaan waktu pengembang yang efisien.

Pengembang sering tidak memiliki keterampilan untuk menjadi pandai pada jenis pengujian tertentu. Sebagian, ini wajar saja. Itu alasan yang sama mengapa penulis memiliki editor. Sangat sulit untuk melihat kekurangan dalam sesuatu jika Anda terlalu dekat dengannya. Tetapi ini juga tentang keahlian yang berbeda dan spesialisasi yang berbeda.

Karena itu, pengembang menghabiskan waktu pengujian dalam biaya: syarat manfaat. Pengembang itu akan lebih produktif melakukan hal-hal lain, dan penguji spesialis akan lebih produktif melakukan pengujian.

Tentu saja itu membuat berbagai asumsi yang belum tentu valid. Di sebuah perusahaan kecil, misalnya, mungkin tidak masuk akal untuk mempekerjakan orang yang berspesialisasi dalam pengujian. Meskipun mungkin lebih masuk akal untuk mempekerjakan staf pendukung tambahan dan meminta mereka melakukan pengujian, atau setidaknya untuk membuat orang menguji kode yang tidak mereka tulis sendiri.


0

Saya percaya ini adalah tanggung jawab kami (pengembang juga) untuk mencakup semua skenario pengujian yang mungkin sebelum dirilis untuk QA. Tujuan QA adalah untuk memvalidasi perangkat lunak. Plus, memalu kode Anda sendiri untuk kesalahan akan selalu membuat Anda terlihat baik datang waktu QA.


Saya pikir apa yang saya coba maksudkan adalah apa yang dianggap efektif "memalu".
Jackie

Itu pasti subjektif. Saya akan mengatakan semua jenis tes yang berlaku untuk proyek Anda (tentu saja tidak semua jenis tes berlaku untuk semua proyek). Berikut adalah daftar yang layak: softwaretestinghelp.com/types-of-software-testing . Apa yang Anda lakukan sendiri dan apa yang Anda pilih sebelumnya tentu saja tergantung pada waktu, sumber daya, dan kemampuan Anda sendiri. Misalnya, Anda mungkin tidak dapat melakukan Pengujian Penerimaan karena ada aturan tertentu yang hanya diketahui pengguna untuk mengikuti. Singkatnya, lakukan semua yang Anda bisa dalam waktu yang Anda miliki.
Honus Wagner

Untuk proyek saya yang sebagian besar web, saya biasanya mencoba untuk mencakup Unit, Fungsional, Kegunaan, Regresi, Kinerja tidak peduli apa. Jika saya punya waktu, saya memilih White Box, Stres, Kompatibilitas, bahkan Penerimaan jika saya cukup tahu. Gaya pengkodean umum saya sangat berorientasi pada kinerja, jadi saya menurunkan prioritas pada hal itu. Tidak satu pun dari ini berarti bahwa QA tidak akan menemukan sesuatu yang salah pada salah satu dari jenis tes tersebut, itu hanya berarti mereka akan menemukan lebih sedikit dan membuat untuk putaran yang jauh lebih mudah 2.
Honus Wagner

0

Siapa yang lebih baik daripada pengembang untuk mengetahui kasus uji apa yang paling relevan. Pengembang harus bertanggung jawab untuk melakukan semua pengujian unit, jika memungkinkan pengembang harus membantu untuk menulis dan menjalankan skrip pengujian. Karena ini jarang terjadi dalam proyek besar, waktu harus diberikan kepada pengembang untuk meninjau semua kasus uji. Selain itu pengembang harus memiliki pengetahuan dan menggunakan berbagai alat uji otomatis yang tersedia.

Dalam karir pengembangan saya, saya menemukan bahwa proyek berakhir dengan hasil yang lebih baik jika ada integrasi yang erat antara tim pengembangan dan tim pengujian.

setidaknya satu anggota dari masing-masing tim harus mengikuti rapat perencanaan dan implementasi lainnya.


1
Satu-satunya masalah yang saya miliki dengan ini adalah bahwa harus ada tingkat isolasi antara pengembang dan tim pengujian, jika tim pengujian menjadi ternoda dengan pendapat pengembang "the code works". QA dan pengembang memiliki tujuan yang berlawanan; pengembang berusaha membuatnya berfungsi, sementara tim QA berusaha membuatnya pecah, dan pengembang tidak selalu memiliki perspektif terbaik tentang relevansi pengujian.
Robert Harvey

Saya tidak setuju seratus persen, tetapi belakangan ini saya telah terlibat dengan aplikasi mobile dan saya pikir mereka memerlukan tingkat integrasi sedikit di luar yang tradisional. Perhatikan saya menggunakan istilah integrasi. mungkin ada isolasi tetapi kedua tim harus meninjau dan berkontribusi pada kasus uji. Kecil kemungkinan pengembang akan memiliki akses ke semua sumber daya pengujian yang diperlukan untuk melakukan pengujian yang tepat, juga tidak mungkin bahwa penguji akan memiliki pengetahuan untuk mengembangkan kasus pengujian untuk sesuatu yang lebih maju seperti streaming video melalui jaringan seluler. terlalu banyak isolasi = masalah.
Michelle Cannon

lebih lanjut saya pikir pasar yang lebih vertikal dan lebih khusus mereka lebih banyak integrasi antara tim diperlukan. sebenarnya semua orang harus masuk ke tahap pengujian dengan anggapan bahwa kode tersebut bekerja di bawah beberapa kondisi yang diuji tetapi lebih mungkin cacat daripada tidak
Michelle Cannon

Ini sepertinya berhasil, tim uji menghasilkan dokumen kasus penggunaan menggunakan spesifikasi fungsional. Tim pengembang meninjau menggunakan dokumen kasus berdasarkan spesifikasi teknis dan fungsional dan menambahkan kasus sesuai kebutuhan. Tim uji mengembangkan skenario uji dari kasus penggunaan. Kasus uji tinjauan uji pengembangan. Memakan waktu tentu saja, tetapi lebih baik daripada menguji nanti dalam tahap penyebaran atau produksi.
Michelle Cannon
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.