Apakah programmer penguji buruk?


36

Saya tahu ini sangat mirip dengan pertanyaan lain yang sudah diajukan, tetapi sebenarnya sedikit berbeda. Tampaknya secara umum dianggap bahwa programmer tidak pandai melakukan peran pengujian aplikasi. Sebagai contoh:

Joel on Software - Lima (Salah) Top Alasan Anda Tidak Memiliki Penguji (penekanan)

Jangan pernah berpikir untuk memberi tahu lulusan CS perguruan tinggi bahwa mereka dapat bekerja untuk Anda, tetapi "semua orang harus melakukan tugas di QA untuk sementara waktu sebelum beralih ke kode". Saya telah melihat banyak hal ini. Programmer tidak menjadi penguji yang baik , dan Anda akan kehilangan programmer yang baik, yang jauh lebih sulit untuk diganti.

Dan dalam pertanyaan ini , salah satu jawaban paling populer mengatakan (sekali lagi, penekanan saya):

Pengembang bisa menjadi penguji, tetapi mereka seharusnya tidak menjadi penguji. Pengembang cenderung secara tidak sengaja / tidak sadar menghindari untuk menggunakan aplikasi dengan cara yang dapat merusaknya. Itu karena mereka menulisnya dan sebagian besar mengujinya dengan cara yang seharusnya digunakan.

Jadi pertanyaannya adalah apakah programmer buruk dalam pengujian? Bukti atau argumen apa yang ada untuk mendukung kesimpulan ini? Apakah programmer hanya buruk dalam menguji kode mereka sendiri? Apakah ada bukti yang menunjukkan bahwa pemrogram benar-benar bagus dalam pengujian?

Apa yang saya maksud dengan "pengujian?" Maksud saya bukan pengujian unit atau apapun yang dianggap sebagai bagian dari metodologi yang digunakan oleh tim perangkat lunak untuk menulis perangkat lunak. Maksud saya beberapa jenis metode jaminan kualitas yang digunakan setelah kode telah dibangun dan digunakan untuk apa pun yang oleh tim perangkat lunak akan disebut "lingkungan pengujian."


17
@ jshowter Programmer paling buruk saat menguji kode mereka sendiri sementara brilian ketika menguji kode orang lain. Penguji (penguji yang baik) sendiri adalah pemrogram dengan caranya sendiri (karena mereka perlu memahami logika pemrograman dan fungsinya) dengan pengecualian bahwa mereka tidak menulis terlalu banyak kode. Saya percaya ini lebih berkaitan dengan psikologi karena saya selalu ragu untuk menemukan keraguan dalam pekerjaan saya betapapun buruknya itu.
Ubermensch

6
@Ubermensch, saya tidak setuju dengan pengembang yang menjadi penguji brilian kode orang lain secara default. Beberapa pengembang, karena telah berlatih pengujian untuk sementara waktu. Ini membutuhkan pola pikir yang berbeda dan motivasi yang berbeda pula, yang sama sekali tidak jelas bagi pengembang pada umumnya. Banyak pengembang cenderung berfokus pada - dan paling menikmati - bagian pengkodean, dan mungkin tidak menghargai - atau bahkan menyadari - pentingnya kegiatan lain dalam SDLC penuh.
Péter Török

1
@ jshowter Jika Anda mencari fakta / data penelitian yang sulit, saya tidak dapat menemukannya. Sebagian besar literatur terkait dengan Agile Development dan tidak dapat menemukan yang cocok dengan kasus khusus Anda. Anda dapat mencoba di Google Cendekia atau Scirus.
Ubermensch

3
Kami bukan penguji buruk! Ini BEKERJA di PC saya! ;-)
Joris Timmermans

2
@MadKeithV Ha! Ini adalah avatar JIRA (pelacak masalah) saya;)
yannis

Jawaban:


39

Pertanyaannya tampaknya bertanya secara khusus tentang Pengujian Sistem , jadi itulah yang saya maksudkan di seluruh jawaban ini.

Saya pikir ada perbedaan penting yang harus dibuat antara menjadi orang jahat untuk memilih melakukan pengujian, dan benar-benar menjadi buruk dalam pengujian.

Mengapa programmer buruk dalam pengujian:

  • Jika Anda telah menulis kode, Anda (harus) sudah memikirkan sebanyak mungkin cara agar ada yang salah, dan telah mengatasinya.
  • Jika menemukan bug yang sangat niggly berarti Anda harus pergi dan memperbaikinya, dalam basis kode Anda mungkin muak, maka itu tidak akan membantu motivasi Anda.

Mengapa programmer pandai pengujian:

  • Pemrogram cenderung menjadi pemikir yang logis, dan pandai bekerja secara sistematis.
  • Pemrogram berpengalaman akan sangat pandai mengidentifikasi kasus tepi dengan cepat dan dengan demikian menghasilkan tes yang bermanfaat. (Jika ada proses pengujian formal, maka sebagian besar dari semua kasus ini seharusnya sudah diidentifikasi dan diuji sebelum pengujian sistem.)
  • Pemrogram cukup baik dalam memastikan bahwa semua informasi yang berguna masuk ke dalam laporan bug.

Mengapa programmer adalah penguji yang buruk:

  • Programmer lebih mahal daripada penguji (dalam sebagian besar kasus).
  • Pola pikirnya berbeda secara mendasar: "Bangun produk (yang berfungsi)" vs "Benda ini tidak keluar dari pintu dengan bug (tidak dikenal) di dalamnya."
  • Penguji biasanya akan lebih efisien - yaitu melakukan lebih banyak tes dalam jumlah waktu yang sama.
  • Pemrogram mengkhususkan diri dalam pemrograman. Profesional QA berspesialisasi dalam pengujian.

4
Perhatikan bahwa pemikiran logis dari pemrogram dapat menjadi kerugian untuk menjadi penguji yang baik. Berapa kali Anda melihat seorang programmer bereaksi dengan "tetapi itu tidak mungkin!" ketika dihadapkan dengan bug yang ditemukan? Hanya untuk mengetahui bahwa mereka telah melewatkan sesuatu yang serius dalam alasan mereka yang membuat bug "tidak mungkin".
Joris Timmermans

2
@CraigYoung - jelas bahwa itu pemikiran logis yang salah, tapi itu sangat umum (sistemnya kompleks). Masalahnya adalah bahwa dalam pengujian Anda tidak boleh menggunakan pemikiran logis untuk menghilangkan tes "tidak perlu", dan tampaknya sulit bagi pengembang untuk menghindari jenis pemikiran itu.
Joris Timmermans

3
+1 Jawaban yang bagus dan seimbang. Juga menjelaskan mengapa kombinasi antara unit otomatis dan tes integrasi yang ditulis oleh programmer bersama dengan pengujian sistem oleh QA adalah kombinasi terbaik.
Danny Varod

1
+1 untuk "pola pikir secara fundamental berbeda". Bagaimanapun, ini adalah peran yang berbeda, dengan perangkat keterampilan yang terkait (tetapi berbeda).
joshin4colours

3
@MadKeithV Pemikiran logis sangat penting dalam pengujian dan juga menghilangkan tes yang tidak perlu. Apakah Anda memikirkan pengujian kotak hitam vs kotak putih? Dalam pengujian kotak hitam Anda menyusun tes dari persyaratan tanpa sepengetahuan implementasi. Untuk memeriksa asumsi yang salah, logika salah, dll. Pengembang IMHO pandai dalam hal ini, asalkan mereka tidak tahu implementasinya. Khususnya jika mereka menulis kode, dan membuat kesalahan, mereka cenderung melakukan kesalahan yang sama dalam tes. Pengujian sistem harus berupa pengujian kotak hitam.
MarkJ

19

Saya pikir programmer buruk dalam menguji kode mereka sendiri .

Kami ingin percaya bahwa kode kami berfungsi dengan baik sesuai dengan persyaratan dan mengujinya. Di tempat saya, kami menguji kode kami sendiri, lalu menguji satu sama lain kode sebelum melepaskan ke dalam siklus pengujian yang sebenarnya dan jauh lebih banyak bug ditangkap dengan cara itu daripada hanya dengan menguji kode kami sendiri


1
Dua sen saya. Pengembang biasanya hanya menguji perubahan terakhir, perbaikan terakhir, fitur terakhir, mereka (dari saya lakukan) dan, dalam beberapa kasus, mereka (kami) sedikit buta atau malas untuk menguji fitur lainnya.
Andrea Girardi

11

Pemrogram jelas merupakan orang yang tepat untuk menguji beberapa bagian dari sistem - di tempat mereka adalah satu-satunya yang mungkin dapat melakukannya secara efektif.

Satu tempat programmer cenderung sangat buruk dalam pengujian adalah seluruh bit "menggunakan UI seperti pengguna normal" - mereka bukan pengguna normal dan tidak berperilaku seperti mereka. Sebagai contoh:

  • Pemrogram cenderung sangat baik dalam mendapatkan entri teks yang tepat. Masalah yang cukup umum yang saya lihat adalah memimpin atau terutama membuntuti ruang. Kebanyakan orang tidak kelihatan seperti mereka, tetapi programmer yang baik mungkin religius tentang membuat string mereka hanya string yang tepat tanpa ruang yang asing.
  • Programmer cenderung menjadi keyboardis, memanfaatkan tab dan cara pintas lainnya untuk mempercepat pekerjaan. Pengguna normal cenderung mengambil mouse di antara bidang.
  • Programmer cenderung memahami apa yang dikatakan sistem daripada mengabaikan pesan kesalahan dan hanya mengklik OK.

Jadi, pengguna normal melakukan banyak hal yang tidak dilakukan oleh programmer. Anda tidak dapat bergantung sepenuhnya pada tim pengembang untuk UAT.


3
Contoh tambahan untuk poin-poin pertama Anda: Pengguna kami memiliki kecenderungan untuk menyalin dari MS Word, yang memasukkan hal-hal aneh seperti em-dash dan kutipan pintar - yang kadang-kadang akan merusak perpustakaan yang tidak kami tulis. Tak satu pun dari kita yang pernah ada di Word, sehingga kasus penggunaan hampir tidak melintasi pikiran kita, apalagi diuji.
Izkata

1

Pada tingkat teknis (tes unit, tes integrasi, tes regresi), pemrogram mungkin satu-satunya orang yang memenuhi syarat untuk menjadi penguji, karena jenis tes ini dapat diotomatisasikan dan karenanya harus otomatis, yang merupakan sesuatu yang memerlukan pemrograman.

Tapi saya tidak berpikir itu yang Anda bicarakan, dan saya cukup yakin itu juga bukan apa yang Joel Spolsky maksud - itu adalah bagian yang tersisa, pengujian manual langsung: mengubah dokumen persyaratan dan spesifikasi fungsional menjadi skrip uji dan kemudian dengan cermat mengeksekusi skrip ini terhadap produk jadi.

Menjadi tester yang baik membutuhkan kualitas yang sebagian besar ortogonal bagi mereka yang membuat programmer yang baik. Ada sedikit tumpang tindih - Anda harus dapat berpikir secara analitis, Anda memerlukan afinitas tertentu dengan komputer pada umumnya - tetapi selain itu, keterampilan penguji jauh berbeda. Itu sendiri tidak berarti Anda dapat memiliki kedua set keterampilan, dan pada kenyataannya, beberapa orang mungkin melakukannya. Namun, untuk menjadi programmer yang benar-benar baik memerlukan kemalasan tertentu (keinginan untuk mengotomatiskan tugas-tugas Anda), sementara tester yang benar-benar bagus perlu kegigihan (periksa semua tiga ribu bidang formulir untuk inkonsistensi), dan sebagai konsekuensinya, bahkan para programmer yang memiliki apa yang diperlukan untuk menjadi seorang tester biasanya membenci ide itu.

Dan kemudian ada bias selektif: Seorang programmer yang sudah terlibat dengan sebuah proyek, bahkan jika hanya sedikit, sudah memiliki pengetahuan dalam tentang basis kode, dan akan mengalami kesulitan mendekati dengan pikiran kosong, dari perspektif pengguna akhir . Bahkan tidak harus eksplisit, seperti pada "Saya tahu tombol ini berfungsi, jadi saya hanya akan mencatat 'lulus'"; itu bisa menjadi jauh lebih halus, dan efek-efek halus itu dapat menyebabkan kasus-kasus tepi kritis tidak terjawab dalam pengujian.


1

Dari pengalaman saya, ya, programmer adalah penguji buruk. Terlalu sering saya melihat orang lain dan saya pergi, "Huh, tapi saya mengujinya sebelum saya check-in!" ketika dihadapkan oleh penguji mereproduksi bug di depan Anda.

Mengapa? Yah, saya tidak yakin mengapa itu tapi mungkin itu karena kami ingin melihat hal-hal bekerja. Atau kita hanya ingin menyelesaikan dengan menguji fitur ini atau itu.

Lagi pula, pengujian bukanlah keterampilan yang kami pelajari dan kami tidak bekerja sebagai programmer karena kami pandai memecahkan fitur. Kita juga mungkin tidak tahu bagaimana melakukan perencanaan pengujian yang tepat atau semua hal lain yang dilakukan QA. Kami tidak lagi memenuhi syarat untuk melakukan pekerjaan penguji daripada penguji yang memenuhi syarat untuk menerapkan pipa rendering 3d baru Anda.

Seperti dalam pertanyaan, pengujian tidak berarti sesuatu yang otomatis tetapi sebenarnya pengujian dengan menggunakan program.


1

Ada beberapa level pengujian. Pengujian "tingkat rendah" dapat dan harus dilakukan oleh pengembang. Saya pikir di unit testig.

Di sisi lain, pengujian "tingkat tinggi" sama sekali hal lain. Secara umum saya pikir pengembang adalah penguji buruk bukan karena mereka kehilangan keterampilan, tetapi karena sangat sulit mengubah cara berpikir dan cara bekerja dalam beberapa waktu.

Saya menggunakan untuk mencoba menguji sebanyak mungkin kode saya, tetapi setelah setidaknya 10 menit dibuat oleh tester, sesuatu untuk mempertimbangkan bug atau peningkatan muncul. Ini berarti menguji sesuatu yang Anda buat, adalah pekerjaan yang sulit. Anda tahu di mana harus mengklik, Anda tahu kapan mengklik, Anda tahu logika bisnis, Anda mungkin tahu bagaimana data bertahan. Anda adalah dewa yang tidak akan pernah jatuh.


0

Apa jenis pengujian yang Anda maksud? Jika Anda maksud pengujian menyeluruh yang komprehensif maka saya bisa melihat beberapa alasan untuk mengatakan ya meskipun saya menduga kebanyakan orang akan miskin dalam kategori ini jika seseorang menganggap semua kombinasi input yang mungkin sebagai persyaratan untuk pengujian tersebut.

Saya dapat mengakui bahwa pengembang yang mendesain perangkat lunak mungkin memiliki visi terowongan ketika datang ke apa kode untuk menangani dan mengabaikan beberapa kasus batas yang mungkin saja tidak dipertimbangkan. Misalnya, jika saya membuat formulir web yang mengambil angka, n, dan kemudian mencetak dari 1 ke n di layar, saya mungkin kehilangan beberapa kasus khusus seperti jika tidak ada yang dimasukkan atau sesuatu yang bukan angka alami seperti e atau pi . Apa yang seharusnya dilakukan oleh program dalam kasus-kasus ini dapat dipertanyakan.

Pengembangan yang Didorong Tes akan menjadi contoh metodologi pengembangan yang menempatkan pengujian pada sudut pandang berbeda yang mungkin memberikan pandangan lain di sini.


Terima kasih sudah menanyakannya. Saya memperbarui pertanyaan saya untuk mengatakan apa yang saya anggap sebagai pengujian. Pada dasarnya, pengujian adalah hal-hal yang terjadi setelah perangkat lunak dibangun dan digunakan, bukan selama pengembangan (seperti pengujian unit) atau sebagai bagian dari metodologi pengembangan (seperti peer review).
jhsowter

0

Pemrogram mendefinisikan tes dengan baik ketika mereka mendefinisikan tes sebelum menulis kode. Dengan latihan, mereka menjadi lebih baik.

Namun, ketika mendefinisikan tes untuk kode yang mereka tulis, mereka tidak melakukannya dengan sangat baik. Mereka akan memiliki titik buta yang sama dalam pengujian yang mereka miliki dalam menulis kode.

Menggunakan programmer untuk melakukan pengujian manual itu konyol. Pengujian manual cukup konyol; membuat programmer melakukannya dengan sangat konyol. Itu mahal dan mengusir programmer yang kompeten.


Sebanyak saya menganjurkan tes unit dan integrasi tes, saya tidak melihat bagaimana TDD (atau menulis tes pertama) memperbaikinya. Jika Anda menulis skenario sukses utama sebelum kode, Anda mungkin tidak akan menemukan sebagian besar bug. Anda harus memikirkan semua hal yang bisa salah. Memiliki kode tertulis, dapat membantu menemukan beberapa di antaranya, karena Anda dapat menjelajahi cabang dan metode yang Anda panggil untuk melihat apa yang dapat memecahkannya.
Danny Varod

Juga, banyak bug yang saya temukan yang tidak terjawab oleh pengembang terkait pesanan panggilan API. Sesuatu yang sebagian besar tes unit tidak mencakup, terutama jika Anda tidak tahu metode apa yang bisa disebut yang dapat mempengaruhi yang Anda uji (dan yang belum diimplementasikan).
Danny Varod

@Danny: dengan TDD, Anda hanya boleh menulis cabang atau metode untuk merespons tes yang gagal, dan Anda hanya menulis kode yang diperlukan untuk membuat lulus ujian yang gagal.
kevin cline

Saya tahu metodologi TDD, saya hanya tidak setuju dengan kesimpulan.
Danny Varod

0

Salah satu jenis pengujian yang secara khusus saya lihat gagal di devlopers menguji apakah persyaratan telah terpenuhi. Apa yang para pemuja pikir artinya sesuatu dalam suatu persyaratan dan apa yang para penguji pikir artinya adalah seringkali adalah dua hal yang sama sekali berbeda.

Saya dapat memikirkan satu baru-baru ini di mana develoepr diminta untuk melakukan ekspor delta dan dev berpikir itu berarti untuk mendapatkan catatan yang belum dikirim sekali dan penguji berpikir itu berarti mendapatkan recrds baru dan perubahan apa pun. Mereka harus kembali ke klien untuk mencari tahu siapa yang benar. Saya mengkaji kode itu dan saya membuat asumsi yang sama bahwa dev lakukan tentang persyaratan. Karena secara logis jika Anda ingin memasukkan pembaruan, Anda akan menyebutkannya. Dan saya biasanya pandai menemukan hal-hal yang ambigu karena saya dulu pengguna akhir.

Jadi pengembang lain yang melakukan pengujian akan cenderung membuat banyak asumsi yang sama karena mereka juga akan membuat asumsi tertentu seperti "baik mereka akan memiliki lebih banyak detail jika itu berarti X wakil Y karena ada begitu banyak detail yang harus dijawab sebelum saya bisa melakukan Tetapi penulis persyaratan tidak berpikir seperti itu. Jadi seseorang yang berpikir lebih seperti persyaratan penulis perlu menguji asumsi pengembang dan seseorang yang bukan pengembang adalah orang yang lebih baik untuk melihat ada masalah.

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.