Apakah pengembangan atau pengujian pengujian unit?


24

Saya berdiskusi dengan manajer pengujian tentang peran unit dan pengujian integrasi. Dia meminta agar para pengembang melaporkan apa yang telah diuji unit dan integrasi mereka serta caranya. Perspektif saya adalah bahwa pengujian unit dan integrasi adalah bagian dari proses pengembangan, bukan proses pengujian. Di luar semantik yang saya maksud adalah bahwa tes unit dan integrasi tidak boleh dimasukkan dalam laporan pengujian dan penguji sistem tidak boleh khawatir tentang mereka. Alasan saya didasarkan pada dua hal.

  1. Tes unit dan integrasi direncanakan dan dilakukan terhadap antarmuka dan kontrak, selalu. Terlepas dari apakah Anda menggunakan kontrak formal, Anda masih menguji apa misalnya metode yang seharusnya dilakukan, yaitu kontrak.

    Dalam pengujian integrasi Anda menguji antarmuka antara dua modul yang berbeda. Antarmuka dan kontrak menentukan kapan tes lulus. Tetapi Anda selalu menguji bagian terbatas dari keseluruhan sistem. Pengujian sistem di sisi lain direncanakan dan dilakukan terhadap spesifikasi sistem. Spesifikasi menentukan kapan tes lulus.

  2. Saya tidak melihat nilai apa pun dalam mengomunikasikan luas dan dalamnya unit dan tes integrasi ke tester (sistem). Misalkan saya menulis laporan yang mencantumkan jenis tes unit apa yang dilakukan pada kelas lapisan bisnis tertentu. Apa yang harus dia ambil dari itu?

    Menilai apa yang harus dan tidak boleh diuji dari itu adalah kesimpulan yang salah karena sistem mungkin masih tidak berfungsi seperti yang diminta spesifikasi meskipun semua unit dan tes integrasi lulus.

Ini mungkin tampak seperti diskusi akademis yang tidak berguna, tetapi jika Anda bekerja di lingkungan yang sangat formal seperti saya, itu sebenarnya penting dalam menentukan bagaimana kita melakukan sesuatu. Lagi pula, apakah aku benar-benar salah?


9
Apakah itu penting?
yannis

5
@YannisRizos Dari judulnya, no. Dari seluruh pertanyaan, sepertinya orang yang bertanya
Ludwig Magnusson

2
@ Rubio Dari pertanyaan Anda, saya setuju bahwa laporan tentang pengujian unit tidak berguna untuk penguji sistem. Tes unit adalah alat yang bermanfaat bagi pengembang. Bagaimana manajer pengujian Anda memotivasi kebutuhan akan laporan ini?
Ludwig Magnusson

2
@LudwigMagnusson Benar, namun jika itu hanya masalah bagi orang yang bertanya, itu terlalu terlokalisasi.
yannis

5
pengembang yang melaporkan kepada manajer pengujian itu salah, apa pun yang terjadi. Jika dia melewati permintaan itu melalui ( manajer dev ) Anda, Anda hanya perlu melakukan apa yang dikatakan atasan Anda. "Bicaralah dengan manajer saya" adalah senjata yang perlu diketahui cara menggunakannya di "lingkungan yang sangat formal" seperti milik Anda
agas

Jawaban:


30

Menulis tes otomatis adalah pekerjaan pengembang; tes adalah bagian dari basis kode dan harus diperlakukan seperti itu - mereka harus tunduk pada tinjauan kode yang sama, standar pengkodean, disiplin kontrol sumber, dll, seperti sisa proyek.

Menjalankan tes mengatakan dilakukan karena dua alasan: Pertama, sebagai alat dalam membimbing pengembang. Anda menjalankan tes untuk memverifikasi bahwa kode yang baru saja Anda tulis melakukan apa yang seharusnya, Anda menggunakannya sebagai dokumentasi tambahan, dan untuk memverifikasi bahwa perubahan tidak merusak fungsi yang ada. Jika Anda melakukan TDD nyata, pengujian juga merupakan sumber spesifikasi teknis yang resmi. Alasan kedua untuk menggunakan tes ini adalah selama QA dan penyebaran. Menjalankan semua tes otomatis harus menjadi salah satu langkah pertama dalam setiap putaran pengujian; menjalankan tes otomatis itu murah (hampir tidak ada tenaga kerja yang diperlukan sama sekali), dan tidak masuk akal untuk melakukan pengujian manual jika tes otomatis gagal.

Ini berarti bahwa tanggung jawabnya harus seperti ini:

  • Pengembang menulis tes otomatis
  • Pengembang menjalankan tes otomatis individual sesuai kebutuhan, sebagai bagian dari alur kerja pengembangan mereka
  • QA menjalankan semua tes otomatis sebagai salah satu tahap pertama pengujian

Jika Anda memiliki server build, maka tugas QA (mengenai tes otomatis) bermuara pada "buka laporan server build dan verifikasi bahwa semuanya berwarna hijau".


Pos luar biasa, persis seperti yang akan saya posting. Hanya keraguan yang terlalu bergantung pada unit test dan juga tes integrasi dapat menyebabkan masalah di jalan. Saya tidak setuju dengan fakta bahwa tugas QA bermuara pada memeriksa server build (saya berasumsi Anda bermaksud sesuatu seperti Hudson). Ini menempatkan semua beban pengujian pada pengembang untuk menulis tes yang mencakup SEMUA logika bisnis, sepanjang waktu, yang tampaknya memberi terlalu banyak beban pada pengembang.
dardo

4
@dardo: Tentu saja tes otomatis bukan satu - satunya tes yang harus Anda jalankan, jika tidak, Anda bisa menghilangkan QA sama sekali. Itu akan konyol - banyak aspek yang sangat penting dari setiap produk perangkat lunak tidak dapat diuji secara otomatis. Apa yang saya maksudkan adalah bahwa dengan adanya tes otomatis, QA tidak perlu khawatir tentang hal itu selain memeriksa output build server; setelah itu, mereka melakukan hal normal - pengujian manual dan semi-otomatis pada build yang sudah selesai.
tdammers

Ah ya, setujui 100% Seperti pos pemeriksaan, apakah mereka ada di sana, apakah mereka lulus, dll.
dardo

@tdammers - Pengujian hanya sebagian kecil dari jaminan kualitas.
Matius Flynn

2
Jawaban yang sangat bagus, namun saya tidak setuju bahwa tes harus dilihat an authoritative source of technical specifications. Tes harus menjadi konfirmasi spesifikasi, tetapi tentunya bukan pengganti. Itu bukan untuk mengatakan bahwa saya menganjurkan untuk spec besar di muka baik, tetapi saya membuat perbedaan bahwa kita menerapkan tes untuk memvalidasi hal-hal yang kita tahu tentang cara di mana sistem harus berperilaku, daripada memiliki tes menentukan perilaku. Mungkin ada perbedaan mencolok, tetapi tetap penting.
S.Robins

10

Saya pikir yang paling penting bagi Anda adalah menjelaskan mengapa dia membutuhkan laporan itu.

Mungkin ada penjelasan yang berbeda (seperti yang disarankan oleh beberapa jawaban), yang membutuhkan strategi yang sangat berbeda.

  • jika dia orang yang masuk akal, hanya ingin mendapatkan informasi untuk membantu pekerjaan tim pengujinya, masuk akal untuk mencapai pemahaman bersama, dan mencari solusi yang cocok untuk Anda berdua. Anda dapat mendiskusikan dengannya sifat unit test dan perbedaan mendasar antara unit vs fungsional / sistem / tes penerimaan. Semoga Anda bisa membuatnya mengerti bahwa ini bekerja pada level yang sangat berbeda dan tidak ada yang bisa menggantikan yang lain.
  • jika dia adalah orang yang suka mengendalikan atau birokrat, menuntut laporan hanya untuk kepentingan itu, Anda dapat menghasilkan sesuatu untuk memuaskan keinginannya dengan jumlah usaha yang paling sedikit (mis. apa yang disarankan oleh @Doc :-).
  • jika dia tertarik dengan beberapa permainan kekuatan, Anda dapat mempertanyakan apakah dia memiliki hak untuk meminta laporan dari pengembang. Dalam pengalaman saya, pengembang biasanya tidak seharusnya melaporkan ke departemen QA.

Poin bagus. Dia memang terlihat seperti orang yang berakal. Ketakutan saya, yang saya tidak jelaskan, adalah bahwa tes unit mengarahkan penguji ke arah yang salah dan keamanan palsu dalam apa yang mereka butuhkan dan tidak perlu uji.
Rubio

2
@ Rubio, memang, Anda harus mengklarifikasi kepadanya bahwa unit test tidak dapat menggantikan tes sistem. Bahkan, cakupan uji unit tinggi dari modul tertentu bahkan mungkin menjadi tanda peringatan bahwa modul tersebut membutuhkan perhatian ekstra selama pengujian sistem! Jika pengembang mengambil rasa sakit ekstra untuk menulis banyak tes, kode mungkin telah diubah / diperpanjang secara drastis akhir-akhir ini, dan / atau penuh dengan bug.
Péter Török

7

Saya pikir peran QA dan Pengembangan, dan interaksi, dapat sangat bervariasi antara organisasi. Tetapi secara umum, di tim saya, saya memberi tahu anggota yang bergabung untuk berpura-pura seolah-olah tidak ada tim QA, dalam arti bahwa mereka bertanggung jawab atas perubahan yang mereka dorong ke dalam produksi. Pada gilirannya, tim QA kami tidak banyak berasumsi tentang pengujian pengembang, dan melakukan sejumlah pengujian sistem secara keseluruhan.

Untuk alasan ini, tim QA kami tidak terlalu peduli tentang apa yang diuji dan tidak unit sebelum mereka memulai pengujian.

Saya pikir sangat membantu bagi tim QA untuk memahami apa yang dilakukan dan tidak dicakup oleh unit test, pada level tinggi, sehingga kita dapat bekerja bersama untuk mengidentifikasi kesenjangan, dan area yang mungkin membutuhkan lebih banyak kekakuan. Jadi, mungkin rekan Anda setelah ringkasan tingkat tinggi, yang bertentangan dengan detail berdarah.


5

Dia bersikeras bahwa para dev melaporkan laporan tentang unit dan integrasi yang mereka uji dan caranya.

Apakah dia benar-benar berusaha memperdebatkan apakah pengujian semacam ini sebenarnya dalam ranah "pengembangan", atau apakah dia hanya mencoba mencari tahu seberapa baik kode Anda dicakup oleh pengujian unit? Hanya dengan melihat informasi yang Anda berikan, sepertinya dia hanya ingin tahu bagian mana dari kode yang dibahas dan di mana dia harus memfokuskan upaya timnya.

Saya bekerja pada tim pengujian keluar dari sekolah sebelum saya pindah ke peran pengembangan, dan saya bisa melihat bagaimana ini mungkin berharga baginya dan timnya.


1
Tetapi bukankah seharusnya fokus datang dari spesifikasi? Ada situasi ketika perubahan kode memiliki akibat yang tidak terduga dan kemudian sangat penting bagi pengembang untuk berkomunikasi bahwa pengujian juga harus mencakup ini dan ini.
Rubio

1
@Rubio: Tentu saja, tetapi dari sudut pandang yang sepenuhnya praktis, coba dan lihat dari sudut pandangnya. Dengan asumsi bahwa semua bagian aplikasi tidak akan memiliki jumlah kode yang sama dengan yang tercakup dalam tes unit, tidakkah Anda ingin mendedikasikan lebih banyak sumber daya terbatas Anda ke bagian aplikasi dengan cakupan lebih sedikit? Bagi saya, itu hanya masalah melihat laporan dan berkata kepada tim saya, "Hai teman-teman, sepertinya Area X memiliki lebih sedikit kode yang dicakup oleh tes daripada Area Y, mari kita coba fokus untuk menjalankan tes di Area X"
Jason

@ Rubio: ya, tetapi jika Anda melakukan TDD (yaitu BDD) dengan benar maka tes Anda harus melawan spesifikasi di tempat pertama. Jika perusahaan Anda benar-benar tercerahkan, maka tim uji dapat menulis tes untuk tim pengembang.
gbjbaanb

2
Apa yang diuji: laporan cakupan kode yang dibuat secara otomatis. Bagaimana cara diuji: baca kode tes unit. @ gbjbaanb: "tim uji bisa menulis tes untuk tim dev." Ada banyak hal yang salah dengan pernyataan itu, sehingga saya tidak tahu harus mulai dari mana, kecuali mengatakan, Ide Sangat Buruk .
BryanH

5

Saya tidak melihat bahwa itu terlalu penting.

Jika Anda tidak menyediakannya untuk QA / Pengujian, dan mereka tidak melakukan tes yang tepat, dan gagal dalam produksi, itu adalah kesalahan mereka untuk membiarkannya melalui QA ke dalam produksi tanpa memverifikasi itu berfungsi seperti yang ditentukan.

Jika Anda menyediakannya untuk QA / Pengujian, dan mereka tidak melakukan tes yang tepat ... hasil yang sama seperti jika Anda belum memberikannya.

Namun, jika Anda memberikannya, mereka dapat membandingkannya dengan spesifikasi juga, dan / atau menyarankan tes mana yang mungkin cacat, atau perlu diubah karena mereka memang menemukan bug.

Sungguh, saya tidak melihat banyak kekurangan dalam menyediakannya. Masih dalam QA / pengujian untuk memvalidasi terhadap spesifikasi. Jika mereka mengambil jalan malas dan hanya mengandalkan bahwa pengujian Anda cukup baik karena mereka semua lulus, itu adalah mereka yang gagal dalam pekerjaan mereka. Selama mereka masih memiliki spek juga, hasil tes unit / integrasi hanya bulu, dan seharusnya tidak dapat melukai Anda dengan satu atau lain cara. Ini adalah alasan kami memiliki dev dan QA. Pemeriksaan berulang yang dilakukan aplikasi seperti yang ditentukan.

Devs membuat kesalahan, QA membuat kesalahan, idealnya mereka tidak membuat kesalahan pada item yang sama ... dan jika mereka lakukan ... itu berpotensi analis yang menjatuhkan bola menulis spec yang tidak jelas.


2
Kelemahan bagi saya adalah kerja ekstra yang tidak memberikan nilai atau sedikit.
Rubio

@ Rubio, pekerjaan ekstra apa? Cukup cetak hasilnya. Jika mereka dinamai dengan baik, itu memberi tahu mereka apa yang Anda uji. Seharusnya tidak perlu kode aktual atau deskripsi tentang cara kerjanya. Jika mereka melakukannya, mereka dapat mencarinya sendiri.
CaffGeek

1
Menghasilkan laporan dari 3500 unit / tes integrasi yang lulus mungkin akan sedikit membantu untuk menguji, bahkan jika tes tersebut dinamai (yang seharusnya tetapi tidak). Untuk memberi penguji informasi yang bermakna tentang uji unit, pengembang harus menggali melalui tes unit yang terkait dengan fitur tertentu dan entah bagaimana berkomunikasi dengan penguji apa yang sebenarnya diuji dan bagaimana hal itu ditegaskan. Itu banyak pekerjaan.
Rubio

1
@Rubio - otomatisasi adalah teman Anda. Anda dapat mengatur server integrasi berkesinambungan yang mengirimkan laporan kapan saja ada checkin (ini juga akan membantu Anda). Jika QA meminta penjelasan tentang tes dan kode, maka sepertinya mereka telah melampaui tingkat kewajaran dan masuk ke ranah "gagal memahami konsep". Jika mereka tidak dapat atau tidak akan membaca kode, maka mereka tidak berguna. Pada saat itu, obrolan dengan manajer Anda akan bermanfaat, dan Anda dapat menjabarkannya seperti, "QA ingin saya menghabiskan x% dari waktu saya untuk membantu mereka membaca kode, apakah tidak apa-apa?"
BryanH

1
+1 untuk mengatakan bahwa itu tidak membebaskan QA dari tanggung jawab mereka untuk menguji perangkat lunak secara independen .

2

Pengujian unit adalah tanggung jawab pengembang bahwa pengujian dapat bermanfaat untuk memahami cara kerja potongan kode. Beberapa mungkin melihat ini sebagai bentuk dokumentasi dan dengan demikian memiliki beberapa nilai walaupun mungkin ada overhead jika tes unit diubah secara teratur.

Nilai lain dalam melewati tes adalah bahwa hal ini dapat menghindari penggandaan pada tes yang mungkin berlebihan dalam hal memastikan fungsionalitas dasar.

Ada juga pengujian penerimaan pengguna yang terpisah dari semua ini karena pengguna akhir mungkin memiliki pemahaman sendiri tentang bagaimana suatu sistem berfungsi.


1
Pengujian berlebihan adalah yang sering digunakan sebagai argumen dan kadang-kadang mungkin benar. Namun, pengujian sistem selalu dilakukan pada seluruh sistem sedangkan pengujian unit / integrasi berfokus pada unit tertentu. Saya melihat bahaya di sini.
Rubio

2

Jika perusahaan Anda memiliki metodologi yang ditetapkan untuk memastikan kualitas produknya (jika mereka sesuai dengan SOX, atau berusaha meningkatkan level CMMI mereka, mereka mungkin melakukannya), maka produk harus dapat berdiri untuk mengaudit untuk menunjukkan bahwa prosesnya diikuti.

Seringkali, proses yang didefinisikan termasuk pengujian unit (yang merupakan hal yang baik). Sayangnya, ini juga berarti Anda harus mendokumentasikan tes unit Anda dan membuktikan bahwa tes tersebut dijalankan untuk dapat mengaudit. Jadi itu berarti Anda perlu cara untuk melaporkan tes unit Anda.

Lihatlah alat seperti Sonar untuk membantu Anda - itu akan melaporkan tingkat cakupan kode dan hasil uji unit Anda berjalan.


SOX tidak, CMMI ya. Uji unit / integrasi kami adalah bagian dari proses peninjauan kode dan hal itu tahan terhadap audit. Saya bisa mendapatkan laporan yang dihasilkan dari uji unit / integrasi, tapi itu cukup samar untuk seorang tester. Cakupan juga dalam laporan tetapi itu sendiri tidak berarti apa-apa.
Rubio

Pertama, jangan berikan tes Anda nama samar. Lihat dannorth.net/introducing-bdd . Kedua, cakupan kode mungkin tidak banyak bicara tentang kualitas pengujian, tetapi setidaknya menunjukkan bahwa unit yang diuji tidak meledak ketika sebagian besar dari semua kode dijalankan.
Matthew Flynn

Tautan yang bagus, terima kasih. Saya ingat pernah membaca artikel majalah yang luar biasa yang mengeksplorasi berbagai cara untuk menamai unit test tetapi tidak bisa mati karena saya menemukannya sekarang. Mungkin Majalah Visual Studio atau Majalah Code.
Rubio

2

Ini benar-benar tergantung pada perusahaan tetapi dari pengalaman saya bekerja baik sebagai penguji sistem dalam pendekatan tradisional tetapi juga sebagai penguji yang bekerja dalam tim tangkas dalam model CD, mengetahui apa yang telah unit dan diuji integrasi sangat berguna.

Kualitas adalah tanggung jawab tim - baik pengembang, penguji dan Manajemen Produk dan bekerja bersama adalah cara terbaik untuk memastikan hal itu.

Jadi manajer pengujian ingin tahu apa yang telah diuji unit dan integrasi dan ini merupakan pekerjaan ekstra untuk pengembang tetapi menghemat keseluruhan pekerjaan untuk proyek! Dengan memberikan informasi kepada manajer tes, mereka dapat memfokuskan upaya tim pengujian mereka pada apa yang penting dan penting. Seperti disebutkan sebelumnya, jika area kode tidak diuji unit, tim dapat memfokuskan upaya mereka di sana dibandingkan dengan area yang banyak diuji - mengapa menduplikasi upaya? Anda semua bekerja menuju tujuan akhir yang sama dari perangkat lunak berkualitas tinggi yang dirilis tepat waktu.


1

Saya akan berpikir bahwa akan bermanfaat untuk menyediakan hal semacam ini. Cakupan unit test haruslah sesuatu yang diketahui oleh pengembangan dan pengujian sehingga mereka dapat menjelaskannya.

Jelas, Anda harus menguji hal-hal penting dalam bisnis apa pun yang terjadi. Anda harus menguji fungsionalitas yang umum digunakan dengan keras terlepas dari apakah ia memiliki cakupan uji unit yang bagus. Tidak ada salahnya untuk memberi tahu mereka tempat-tempat lain yang dicakup oleh unit test. Apakah kode sudah memeriksa kasus tepi dalam satu kontrol kecil ini? Hal-hal semacam ini bermanfaat untuk diketahui di semua sisi bisnis.


Saya akan menulis jawaban yang sama. Sementara pengujian unit harus berada dalam domain pengembang perangkat lunak, memberi tim pengujian rasa cakupan kode dapat membantu tim pengujian untuk memahami dan menargetkan area spesifik yang mungkin memerlukan perhatian lebih besar oleh penguji. Ini juga bisa menjadi cara untuk menjaga pengembang dalam permainan mereka dalam hal memastikan mereka memperhitungkan sebanyak mungkin kasus yang efektif untuk melakukannya. Hal ini memungkinkan tim pengujian untuk tidak hanya memvalidasi keseluruhan sistem, tetapi juga memperhitungkan semua hal yang mungkin dianggap mahal untuk diuji.
S.Robins

1

Perlu disebutkan pendekatan yang dibahas dalam buku "Bagaimana Google Menguji Perangkat Lunak": Pengujian dan Kontrol Kualitas adalah tanggung jawab semua orang, dan standarnya sangat ketat.

The nyata peran apa yang secara tradisional disebut "Pengujian" departemen, sebenarnya produktivitas pengembang; yaitu otomatisasi untuk memungkinkan organisasi mencapai tingkat ketelitian yang disyaratkan secara ekonomi.

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.