Apakah seorang programmer seharusnya mandiri?

Di tempat kerja saya saat ini, kami tidak memiliki penguji, alasan untuk itu dari manajemen adalah: "jika kami memiliki penguji, Anda tidak akan menguji kode Anda sendiri sama sekali". Pemikiran seperti ini tampaknya merusak kualitas produk, karena ketika saya menguji kode saya sendiri, ada banyak hal yang akan saya lewatkan hanya karena saya tahu sistem luar dan tidak tahu cara menggunakan itu salah". Pengujian kotak hitam tidak benar-benar berfungsi karena secara tidak sadar saya menghindari jebakan yang akan jatuh ke penguji khusus. Banyak waktu saya digunakan untuk memperbaiki bug yang telah dimasukkan ke dalam kode produksi dan ditemukan oleh pengguna akhir.

Sistem yang dimaksud adalah besar tetapi dikembangkan sendiri oleh saya. Ini juga menyebabkan beberapa tugas manajemen jatuh di pangkuan saya, seperti menentukan jadwal dan mengerjakan spesifikasi.

Haruskah tugas semacam ini menjadi tanggung jawab saya? Saya melihat diri saya secara ketat sebagai seorang programmer dan tidak ada yang lain. Dan jika ini adalah tanggung jawab saya, sampai sejauh mana? Kapan sebuah proyek begitu besar sehingga membutuhkan penguji? Haruskah seorang programmer harus memperbaiki spesifikasi, khawatir tentang manajemen proyek atau bahkan memberikan dukungan pelanggan?

Catatan

Beberapa orang mungkin mendapat kesan bahwa saya menentang memperluas tanggung jawab saya - bukan itu masalahnya, saya ingin sekali mendapatkan peran yang melibatkan lebih banyak tugas manajemen, tetapi saat ini tidak ada dalam uraian tugas saya. Sampai saya secara resmi dipekerjakan seperti itu atau tugas tambahan mulai terlihat di gaji saya, saya akan menganggap diri saya sebagai 'hanya' seorang programmer. Sayangnya, sebagai pengembang junior, beralih ke tugas manajerial tidak akan terjadi segera.

Sejauh ini jawaban luar biasa, teruskan mereka jika Anda memiliki sesuatu untuk ditambahkan atau pengalaman pribadi untuk dibagikan!

Anda lakukan memiliki penguji. Hanya, Anda menyebut mereka "pengguna akhir." Ini merugikan karena semua alasan yang Anda jelaskan; tidak peduli seberapa hati nurani Anda, Anda tidak akan pernah bisa melakukan pekerjaan yang cukup baik untuk mengatasi prasangka Anda sendiri tentang bagaimana kode itu "seharusnya" digunakan agar Anda dapat menemukan semua cara yang dapat mengacaukan .

Anda perlu membuka kembali masalah ini dengan manajemen. Pada titik ini, sepertinya Anda memiliki beberapa data sulit untuk mendukung kasus Anda; pendekatan hands-off saat ini untuk Quality Assurance membuang-buang waktu Anda dan membahayakan pengalaman pengguna Anda. Anda harus berhati-hati dalam cara Anda menyajikan ini sehingga jelas ini adalah masalah struktural dan bukan kasus "Anda hanya payah dalam pengujian," tetapi kedengarannya seperti diskusi yang perlu terjadi.

Sepertinya Anda datang ke persimpangan dengan majikan ini. Jika Anda berniat tetap menjadi programmer dan tidak ada yang lain, Anda mungkin perlu mulai mendorong kembali dan meminta mereka mulai memberi Anda bantuan yang Anda butuhkan untuk mengambil beberapa tugas manajerial dari piring Anda, baik dengan membawa seseorang yang baru atau dengan memperluas tanggung jawab rekan kerja yang ada. ("Ini bukan untuk apa kau mempekerjakanku, dan tugas-tugas ini tidak hilang. Waktu yang kuhabiskan untuk melakukan hal-hal ini dengan buruk adalah saatnya aku tidak menghabiskan apa yang aku kuasai.") Tapi itu mungkin atau mungkin tidak realistis. Apakah Anda pikir Anda bisa menangani pindah ke peran yang lebih manajerial jika mereka memberi Anda sumber daya dan otoritas yang Anda butuhkan untuk menyelesaikan pekerjaan dengan benar?

Mengenai seberapa besar proyek yang perlu sebelum perlu penguji, saya tidak yakin bagaimana mendefinisikan garis itu secara tepat, tapi saya pasti berpikir Anda telah melewatinya. Anda menghabiskan lebih banyak waktu daripada Anda ingin memperbaiki laporan bug yang datang dari pengguna sebenarnya; bagi saya yang mengatakan ini saatnya untuk menghabiskan lebih banyak upaya menghentikan bug dari sampai ke pengguna di tempat pertama.

Iya nih. Jika harus , Anda harus dapat menguji kode Anda. (Saya tidak berbicara tes unit, tetapi tes penerimaan dan semacamnya.)

Tidak ada . Penguji lebih baik dalam pengujian daripada Anda. Dan seperti yang Anda tunjukkan, seperti halnya proofreading, sangat sulit untuk menemukan kesalahan Anda sendiri. Memiliki bola mata ekstra akan berdampak besar (baik) pada kualitas program Anda.

Anda punya banyak pertanyaan lain. Saya hanya akan menjawab satu:

Haruskah seorang programmer harus memperbaiki spesifikasi?

Iya nih! Anda harus mengimplementasikan spesifikasi, jadi Anda harus memastikan bahwa spesifikasi tersebut benar-benar dapat diterapkan. Juga, sebagai seorang programmer - terlatih dalam pemikiran jernih, presisi dan semacamnya - Anda dapat membantu orang menemukan apa yang sebenarnya perlu dilakukan, dan menyingkirkan persyaratan yang ambigu atau cacat secara logis.

Apa yang mereka katakan dan kenyataan mungkin adalah dua hal yang berbeda. Kemungkinan besar alasannya adalah:
"Mengapa saya harus membayar gaji penguji padahal saya hanya bisa membuat programmer melakukan tugas ganda?"

Tentu saja, mereka tidak akan mengatakan itu dan akan membuat segala macam alasan yang menurut mereka masuk akal. Saya bisa memikirkan beberapa bantahan untuk poin mereka, tetapi jujur ​​mereka tidak akan membantu. Saya telah melihat pertempuran ini berulang-ulang dan mereka hanya akan mengubah pendekatan mereka setiap kali Anda menghilangkan prasangka alasan mereka saat ini. Akhirnya mereka akan menyerah dan mengarahkan Anda untuk tetap melakukannya dan Anda akan dicap sebagai pengeluh.

Pendekatan terbaik yang dapat saya pikirkan adalah mengatasinya bukan dari sudut pandang kualitas, yang tampaknya manajemen tidak pernah menilai sampai ada masalah, tetapi dari sudut pandang biaya. Penguji, atau setidaknya dianggap, lebih murah daripada programmer. Ingatkan mereka bahwa dengan meminta Anda melakukan tugas ganda, mereka membayar sumber daya berbayar (programmer) yang lebih tinggi untuk melakukan pekerjaan yang bisa diselesaikan dengan sumber daya yang lebih murah (tester). Dengan demikian mereka tidak memaksimalkan nilai yang mereka ekstrak dari keterampilan pemrograman Anda.

Pendekatan ini memang memiliki kerugian berantakan jika Anda digaji dan mereka tidak memiliki kompromi tentang hanya membuat Anda bekerja lebih lembur tanpa dibayar, tetapi patut dicoba.

Sistem yang dimaksud adalah besar tetapi dikembangkan sendiri oleh saya. Ini juga menyebabkan beberapa tugas manajerial jatuh di pangkuan saya, seperti menentukan jadwal dan mengerjakan spesifikasi.

Cukup adil.

Haruskah tugas semacam ini menjadi tanggung jawab saya?

Yang akhirnya terserah manajemen Anda untuk memutuskan.

Saya melihat diri saya secara ketat sebagai seorang programmer dan tidak ada yang lain.

Mungkin Anda berada di pekerjaan yang salah. Banyak orang suka diberi tanggung jawab ekstra.

Dan jika ini adalah tanggung jawab saya, sampai sejauh mana?

Jika manajemen mengatakan demikian, ya.

Kapan sebuah proyek begitu besar sehingga membutuhkan penguji?

Ketika ada terlalu banyak pekerjaan lain yang harus dilakukan pengembang. Pada saat itu, manajemen perlu memutuskan apakah mereka ingin menggunakan tester khusus, atau mengambil risiko skimping pada pengujian. (Pada akhirnya, pengembang hanya dapat melakukan banyak hal.)

Ada keuntungan yang pasti dalam memiliki penguji yang berdedikasi, tetapi ada kerugian juga ... selain biaya mempekerjakan staf tambahan.

Haruskah seorang programmer harus memperbaiki spesifikasi,

Jika perlu, ya. Bahkan, jika spesifikasi perlu disempurnakan dan tidak ada orang lain yang mengerjakannya, maka kegagalan untuk melakukan ini kemungkinan akan menyebabkan proyek gagal.

khawatir tentang manajemen proyek

Jika perlu, ya.

atau bahkan memberikan dukungan pelanggan?

Jika perlu, ya.

Kedengarannya bagi saya seperti Anda terlalu banyak bekerja, dan bereaksi terhadap tekanan. Ini adalah sebuah masalah. Tetapi mengambil posisi bahwa itu "bukan tugas Anda untuk melakukan X, Y, Z" tidak akan membantu. Rencana yang lebih baik adalah untuk memperjelas bahwa hanya ada begitu banyak yang dapat Anda lakukan, dan tunjukkan bahwa ini kemungkinan akan menyebabkan tenggat waktu terlewatkan, kualitas terputus, dukungan pelanggan yang buruk, dan sebagainya. Tetapi tetap lakukan yang terbaik ... tanpa merusak kesehatan, hubungan, dll dalam prosesnya.

Kami memiliki penguji. Saya tidak ingin bekerja tanpa mereka. Meskipun saya menulis unit test (menggunakan TDD), dan tes integrasi otomatis untuk semua kode saya, penguji masih memiliki fungsi yang sangat berharga.

1. Mereka sangat terampil, dan memiliki keterampilan yang berbeda dengan programmer.
   1. Mereka memiliki banyak pengalaman dan pengetahuan tentang bagaimana melakukan pengujian QA, dan bagaimana memverifikasi bahwa kode yang telah diproduksi benar-benar cocok dengan harapan pengguna dan perilaku pengguna yang sebenarnya.
   2. Mereka telah mengalami banyak bug, dan sangat pandai memikirkan situasi yang dapat merusak perangkat lunak.
   3. Mereka cenderung sinis dan sistematis. Saya telah mengamati bahwa programmer seringkali jauh lebih optimis.
2. Mereka memberikan umpan balik awal yang berharga tentang kegunaan. Misalnya, saat membuat API REST baru-baru ini, area yang tidak mudah dimengerti oleh penguji QA adalah indikasi area yang baik yang juga membuat pengguna tidak senang.
3. Mereka menguji pada lingkungan aktual, pada kenyataannya banyak konfigurasi perangkat keras, OS, dll.
4. Mereka tahu cara membangun skala besar, realistis, test bed dan melakukan pengujian kinerja, beban dan stres
5. Mereka fokus untuk mencegah rilis buruk keluar. Programmer cenderung fokus untuk merilis kode. Hampir seperti, seorang programmer akan merilis kode secara default, tetapi tester QA akan memerlukan alasan untuk merilisnya (telah terbukti bekerja!)

"Jika kami memiliki penguji, Anda tidak akan menguji kode Anda sama sekali"

" Jika mobil Anda memiliki sabuk pengaman, Anda akan menabraknya sepanjang waktu! "

Haruskah tugas semacam ini menjadi tanggung jawab saya? [...] Dan jika ini adalah tanggung jawab saya, sejauh mana?

Jawabannya adalah "itu tergantung". Dari apa yang saya mengerti, majikan Anda melihat Anda sebagai "departemen satu orang". Jika itu masalahnya, ya, itu adalah (tanggung jawab Anda). Jika Anda memiliki tanggung jawab yang benar-benar Anda benci dan ingin hindari, cari posisi dalam perusahaan dengan departemen IT yang lebih besar.

Kapan sebuah proyek begitu besar sehingga membutuhkan penguji?

Itu bukan (cukup) pertanyaan yang tepat untuk ditanyakan. Anda lebih baik bertanya "kapan kualitas produk / citra perusahaan begitu penting sehingga diperlukan penguji?"

Haruskah seorang programmer harus memperbaiki spesifikasi, [...]

Iya tentu saja. Sering kali, ada perbedaan besar antara apa yang dibutuhkan pengembang / pelaksana dan apa yang disediakan klien [sebagai spesifikasi].

Sering kali terserah pada Anda untuk menemukan area abu-abu / tidak spesifik dan mengajukan pertanyaan yang tepat, untuk memperhatikan dan menunjukkan persyaratan yang secara teknis tidak mungkin atau bertentangan dan seterusnya (terutama jika Anda satu-satunya pengembang).

[...] khawatir tentang manajemen proyek atau bahkan memberikan dukungan pelanggan?

Itu tergantung pada tanggung jawab yang Anda terima ketika Anda mengambil posisi itu. Misalnya, beberapa posisi mengharuskan Anda untuk menangani pelanggan secara langsung. Semua hal lain dianggap sama, saya akan berusaha untuk menghindari posisi seperti itu (tetapi terserah Anda, dan Anda mungkin tidak memiliki banyak pilihan pekerjaan).

Pertama-tama, pengujian, atau lebih baik dikatakan Jaminan Kualitas, bukan hanya tentang menguji fungsi dengan mengklik melalui aplikasi. Jaminan Kualitas adalah tentang proses . Tidak hanya untuk menguji aplikasi untuk menemukan kesalahan, mereka juga harus mencegah pengembang untuk melakukannya.

1. Spesifikasi produk + kasus penggunaan
   Bahkan jika semua orang tahu (atau berpikir mereka tahu) apa fungsi produk itu, itu harus dituliskan. Anda tidak dapat menguji aplikasi tanpa spesifikasi yang jelas. Spesifikasi menentukan perilaku yang benar dan bug.
2. Tes unit, Tes integrasi
   Tes internal yang sulit untuk diuji melalui UI, status aplikasi yang luar biasa. Ini adalah suatu keharusan untuk setiap sistem yang lebih besar. Kedua jenis tes ini juga memiliki properti lain yang menarik - tes ini memaksa Anda memeriksa setiap bagian kode lagi dan Anda akan menyadari masalah bug / arsitektur yang belum pernah Anda lihat sebelumnya.
3. Kualitas Kode & Standar Pengkodean
   Salah satu tugas yang harus dilakukan QA adalah mengukur kompleksitas kode. Kode dengan kompleksitas rendah mengurangi kemungkinan kesalahan (mencegah bug).
4. Ulasan kode
   Ketika suatu proyek mencapai ukuran tertentu, atau digunakan oleh banyak pengguna, ulasan kode adalah suatu keharusan. Programmer lain selalu menemukan masalah kode / bug yang Anda lewatkan. Pemrogram terkadang buta terhadap bug yang jelas dalam kode mereka sendiri.
5. Dokumentasi
   Dokumentasikan kode Anda dan arsitekturnya, ini akan membantu Anda menyadari kemungkinan kelemahan (pengalaman saya sendiri).
6. Penguji
   Penguji bukan monyet yang hanya mengklik UI. Penguji mengambil spesifikasi & kasus penggunaan dan membuat kasus uji. Lalu dia mengujinya satu per satu. Jika bug dilaporkan oleh pengguna akhir, sebuah test case harus ditambahkan untuk itu.

Seorang programmer tidak boleh membuat spesifikasi (1). Anda tidak ada di sana untuk memutuskan fungsi. Biasanya mereka harus berbicara dengan pengguna akhir, membuat desain grafis dll. Ini adalah tugas yang memakan waktu. Jika seorang programmer memutuskan fungsi, biasanya berakhir dengan "tidak apa-apa tapi bisakah Anda mengubah segalanya di jendela ini besok?" "ini bukan apa yang saya inginkan" "itu berfungsi tetapi sulit untuk digunakan" "ini tidak ada satu-satunya fungsi yang benar-benar kami butuhkan".

Apa yang bisa dicapai oleh seorang programmer adalah 2, 3 dan 5.

Anda memerlukan programmer lain untuk 4. Perusahaan mana pun yang memiliki proyek TI besar dan hanya satu pengembang yang mengetahui langkah sistemnya dengan alasan yang sangat berbahaya.

Jika Anda tidak punya cukup waktu, jangan pernah repot-repot membuat test case (5). Orang yang berdedikasi biasanya diperlukan karena membutuhkan banyak waktu. Tanpa uji kasus, pengujian hanyalah lelucon.