Apakah Anda percaya itu adalah ide yang baik untuk Insinyur Perangkat Lunak harus bekerja sebagai Insinyur Jaminan Kualitas untuk beberapa periode waktu? [Tutup]


12

Saya percaya itu. Mengapa?

  1. Saya telah menemui banyak Insinyur Perangkat Lunak yang percaya bahwa mereka entah bagaimana lebih unggul daripada insinyur QA. Saya pikir ini dapat membantu menghilangkan kepercayaan ini jika mereka melakukan pekerjaan seorang insinyur QA untuk beberapa waktu, dan menyadari bahwa itu adalah keahlian yang unik dan berharga.

  2. Semakin baik seorang Insinyur Perangkat Lunak menguji program mereka sendiri, semakin sedikit biaya dalam waktu yang dikeluarkan kode mereka saat menjalani siklus pengembangan perangkat lunak lainnya.

  3. Semakin lama seorang Insinyur Perangkat Lunak menghabiskan waktu untuk memikirkan bagaimana suatu program dapat rusak, semakin sering mereka mempertimbangkan kasus-kasus ini saat mereka sedang mengembangkannya, sehingga mengurangi bug pada produk akhir.

  4. Definisi "lengkap" dari Insinyur Perangkat Lunak selalu menarik ... jika mereka telah menghabiskan waktu sebagai insinyur QA, mungkin definisi ini akan lebih cocok dengan perancang perangkat lunak.

Catatan saya membuat saran di atas dengan kerangka waktu kecil dalam pikiran karena saya tahu seseorang bekerja di posisi yang bukan posisi mereka disewa jelas merupakan resep untuk kehilangan pengembang itu.

Apa yang kalian pikirkan?


1
Pekerjaan pertama saya adalah QA. Saya membencinya, tetapi saya BENAR-BENAR memahami pentingnya QA.
Ayub

Saya tidak sepenuhnya menghargai kreativitas di balik QA sampai saya membaca The Art of Software Testing klasik Glenford Myers .
Macneil

5
Saya telah menemukan banyak Insinyur Perangkat Lunak yang percaya bahwa mereka entah bagaimana lebih unggul daripada orang lain di planet ini ;-)
Steven A. Lowe

Steven terlalu benar.
Macy Abbey

1
Saya menyarankan untuk bertanya, apakah itu ide yang bagus untuk insinyur perangkat lunak untuk melakukan beberapa hal QA, daripada berpikir bahwa beberapa entitas yang tidak dikenal akan memaksa mereka untuk melakukannya.
David Thornley

Jawaban:


13

1. Saya telah menemui banyak Insinyur Perangkat Lunak yang percaya bahwa mereka entah bagaimana lebih unggul daripada insinyur QA. Saya pikir ini dapat membantu menghilangkan kepercayaan ini jika mereka melakukan pekerjaan seorang insinyur QA untuk beberapa waktu, dan menyadari bahwa itu adalah keahlian yang unik dan berharga.

Rekayasa perangkat lunak yang baik memiliki latar belakang dalam kualitas, termasuk pengujian, metrik, dan statistik. Siapa pun yang melakukan pengembangan perangkat lunak apa pun harus sadar (jika tidak terbiasa) menjaga kode sumber yang berkualitas dan memproduksi / memelihara kotak uji yang efektif. Seiring waktu, saya akan curiga bahwa setiap pengembang perangkat lunak akan mendapatkan pemahaman tentang berbagai aspek kualitas - kualitas kode, portabilitas, rawatan, kemampuan uji, kegunaan, keandalan, efisiensi, dan keamanan.

Insinyur perangkat lunak mungkin fokus pada aspek tertentu dari siklus hidup - rekayasa persyaratan, arsitektur dan desain, konstruksi, pengujian, dan pemeliharaan. Namun, terlepas dari fokus Anda (baik sebagai pekerjaan atau pada fase proyek saat ini), penting untuk mengingat kualitas.

2. Semakin baik seorang Insinyur Perangkat Lunak menguji program mereka sendiri, semakin sedikit waktu yang dikeluarkan kode mereka saat menjalani sisa siklus pengembangan perangkat lunak.

Itu mungkin benar. Tetapi beberapa masalah paling baik dilihat kemudian dalam pengembangan. Misalnya, masalah kinerja dan efisiensi mungkin tidak terlihat sampai integrasi. Memiliki kode yang baik, solid, dan unit test yang efektif hanyalah awal. Kualitas perlu dimulai dengan persyaratan, dan ikuti semua jalan melalui kegiatan pemeliharaan.

3. Semakin lama seorang Insinyur Perangkat Lunak menghabiskan waktu untuk memikirkan bagaimana suatu program dapat rusak, semakin sering mereka mempertimbangkan kasus-kasus ini ketika mereka sedang mengembangkannya, sehingga mengurangi bug pada produk akhir.

Itu pernyataan yang sepenuhnya benar. Tetapi sekali lagi, itu juga tergantung pada persyaratan insinyur untuk memverifikasi bahwa tidak ada konflik dalam persyaratan, arsitek untuk memastikan bahwa desain benar-benar memenuhi persyaratan, dan sebagainya. Setiap orang harus mencoba menyodok lubang dalam pekerjaan mereka dan kemudian bekerja dengan orang yang tepat untuk menutupnya dengan baik dan kencang.

4. Definisi "lengkap" dari Insinyur Perangkat Lunak selalu menarik ... jika mereka telah menghabiskan waktu sebagai insinyur QA, mungkin definisi ini akan lebih cocok dengan perancang perangkat lunak.

"Lengkap" hanya dapat diukur terhadap persyaratan. Entah persyaratan dipenuhi dan proyek selesai, atau ada persyaratan tidak lengkap dan proyek tidak lengkap. Ukuran lengkap lainnya tidak berguna.


Terima kasih Thomas, itu jawaban yang sangat informatif dan bijaksana.
Macy Abbey

6

Membuat programmer bertanggung jawab atas kode mereka dan meminta mereka untuk memperbaiki bug mereka sendiri dapat mengatasi hal ini. Itu dan hilangnya bonus dan / atau pekerjaan.

Bukan berarti pengalaman ini tidak akan membantu, tetapi seberapa jauh Anda bisa melangkah dengan garis pemikiran ini? Dukungan Teknis, Penjualan, Pengguna Beta, gosok toilet (itu akan menjadi pengalaman yang merendahkan).


Benar Jeff, tapi saya pikir pendekatan pertama tidak selalu mengajarkan mereka alat yang mereka butuhkan untuk menjadi programmer yang lebih efisien / kuat. Itu memang memberikan tekanan, yang bagus.
Macy Abbey

Juga, salah satu negatif dari pendekatan ini adalah kehilangan programmer untuk jangka waktu tertentu, satu minggu ... dua minggu, sebulan? Dan saya pikir itu bukan ide yang baik untuk meminta mereka melakukan pekerjaan yang tidak banyak berhubungan dengan pekerjaan mereka saat ini ... (menggosok toilet: P)
Macy Abbey

6

"... harus bekerja sebagai insinyur QA ..."? Anda membuatnya terdengar bermusuhan atau hukuman.

Saya seorang pengembang perangkat lunak. Saya menganggap itu bagian dari pekerjaan saya untuk menjadi insinyur QA juga, meskipun kami memiliki departemen QA. Adalah tugas saya untuk mengirimkan perangkat lunak yang menyelesaikan hal-hal tertentu, dan, untuk itu saya harus menulis unit test dan memastikan perangkat lunak melewatinya.

Saya bermitra dengan departemen QA kami. Tujuan saya adalah membuat pekerjaan mereka lebih mudah, sama seperti pekerjaan mereka adalah membantu saya memenuhi tujuan saya dalam memberikan perangkat lunak yang melakukan apa yang seharusnya, sehingga membuat hidup saya lebih mudah. Saya menganggap mereka sebagai mata kedua dan jaring pengaman, seperti halnya saya melakukan tes unit.

Saya memilih untuk mengembangkan perangkat lunak, dan ingin mengembangkan perangkat lunak. Jika beberapa manajer datang kepada saya dan mengatakan kepada saya bahwa saya tidak bisa melakukan itu dan harus melakukan QA, saya akan memberitahu mereka bahwa mereka perlu menemukan pengembang perangkat lunak baru DAN orang QA karena saya tidak akan bekerja di sana. Saya anal karena bisa dengan kode saya tetapi proses kreatif dan pemrograman teka-teki / tantangan sangat penting bagi saya. Saya lebih baik kembali ke mengendarai fork lift jika saya tidak bisa menulis kode karena berada di lingkungan perusahaan tanpa menjadi kreatif dan ditantang dengan cara saya akan benar-benar neraka bagi saya.

Secara umum opsi yang Anda berikan terdengar sangat bermusuhan dan membuat saya bertanya-tanya apakah Anda memiliki pengalaman yang sangat buruk dengan beberapa pengembang yang mengerikan. Dalam pikiran saya, seorang pengembang harus SELALU menyadari masalah kualitas dan pengujian dan harus cukup bangga dengan pekerjaan mereka sehingga mereka tidak menganggapnya selesai sampai melewati pengujian ketat dalam pengujian unit mereka seperti apa yang akan digunakan oleh departemen QA resmi. Jika saya memiliki rekan kerja, atau memimpin teknologi di sebuah tim dan memiliki pengembang yang menunjukkan "kebodohan" apa pun terhadap QA, dia akan mendapati saya menariknya untuk koreksi sikap. Jika kedua sisi koin pengiriman perangkat lunak tidak dapat bekerja sama dan bertindak sebagai tim, ada masalah budaya nyata. Saya tidak ingin bekerja di sana dan SDM, bersama dengan manajemen tingkat atas, perlu diberi tahu.


Halo Greg, saya mengajukan pertanyaan dengan memikirkan seorang insinyur perangkat lunak yang baru di bidangnya, dan tidak memahami nilai QA, dan yang belum memiliki banyak pengalaman dalam mengembangkan serangkaian kriteria penerimaan yang didefinisikan dengan baik. Alasan saya memilih "harus" adalah karena seperti yang Anda katakan, saya tidak berpikir banyak insinyur perangkat lunak akan memilih untuk bekerja sebagai insinyur jaminan kualitas (sebagai tugas tunggal mereka) karena mereka jelas memilih untuk menjadi pengembang perangkat lunak. Saya sangat menghargai dan membagikan perspektif Anda tentang bagaimana seharusnya sikap dan hubungan pengembang perangkat lunak yang baik dengan QA.
Macy Abbey

Apakah Anda pikir memiliki pekerjaan insinyur perangkat lunak baru sebagai insinyur QA akan membantu mereka mencapai titik Anda sekarang?
Macy Abbey

1
Benar-benar tidak. Pastikan mereka memahami bagaimana tim bekerja; Kembangkan sikap memiliki masalah; Budaya suasana terbuka yang mendorong orang untuk bekerja dalam tim ad-hoc untuk mendiskusikan dan menyelesaikan masalah. Terlalu banyak orang dan perusahaan mendorong silo pengetahuan dan sikap "kita terhadap mereka semua". Jujur saja, "kita melawan mereka semua" perlu pergi ke dalam tembok perusahaan karena itu menyakiti semua orang.
the Tin Man

2
@Macy Abbey, salah satu taktik yang perlu dipertimbangkan adalah membuat pengembang bekerja sama dengan tim QA untuk mengembangkan skenario pengujian. Tes unit dapat ditulis dan dirancang bersama-sama, atau tim QA dapat menambahkan tes mereka ke folder "tes" di mana pengembang memiliki tes unit. Beberapa orang berpikir harus ada pemisahan antara dev dan QA tetapi itu mendorong persaingan. Jika kedua kelompok menggunakan bola mata mereka dan menguji trik bersama-sama, mungkin mereka dapat menemukan bug dan fitur yang terlewat lebih cepat.
the Tin Man

@ Greg Terima kasih Greg, itu terdengar seperti taktik yang bagus. Saya yakin Anda telah meyakinkan saya bahwa campuran taktik lain lebih baik daripada yang saya usulkan pada awalnya.
Macy Abbey

5

Membuat programmer bekerja sebagai insinyur QA adalah resep untuk kehilangan pengembang terbaik Anda. Pemrograman dan QA membutuhkan perangkat keterampilan dan proses pemikiran yang berbeda.

Namun, penting bagi programmer Anda terampil dalam seni pengujian dan memvalidasi pekerjaan mereka sendiri sebelum meneruskannya ke tim QA. Pengembang dan QA memiliki akses ke berbagai alat, pengetahuan, dan keterampilan. Para pengembang perlu terampil dalam melangkah melalui kode mereka mencari perilaku yang tidak terduga, pengujian unit untuk kondisi batas, menekankan kode berulir mencari kondisi ras dll. Yaitu Pengujian dari perspektif pengembang.

QA melakukan pengujian dari perspektif pengguna. Berpikir seperti jenis pengguna yang berbeda, menciptakan kasus tepi yang aneh, dan membuat masalah yang tidak jelas dapat direproduksi adalah keterampilan QA.


1
Terima kasih Ptolemy, saya membuat saran ini dengan kerangka waktu kecil di pikiran karena saya sadar seseorang bekerja di posisi yang bukan posisi mereka disewa jelas merupakan resep untuk kehilangan pengembang itu.
Macy Abbey

Bukan hanya karena mereka tidak akan bekerja dalam posisi yang mereka pekerjakan, mereka juga tidak akan berada dalam posisi yang mereka pilih sebagai profesi mereka dan bersekolah. Itu adalah tamparan besar bagi banyak orang yang menaruh hati mereka pada karir mereka. Bagi mereka yang hanya menganggap pekerjaan sebagai gaji, itu akan baik-baik saja.
the Tin Man

@Reg: Orang-orang yang ada di dalamnya untuk gaji tidak akan menyukainya juga. Resume mereka akan lebih bernilai dengan X + 1 tahun rekayasa perangkat lunak daripada X tahun rekayasa perangkat lunak dan satu tahun QA, setidaknya sejak awal. Belum lagi Anda harus membayar orang-orang QA Anda serta orang-orang perangkat lunak Anda, karena tidak ada orang di dalamnya untuk gaji akan bersedia menerima pemotongan gaji.
David Thornley

Eh, itu menganggap Anda bekerja di tempat yang membayar orang QA terampil kurang dari devs. Saya tahu beberapa tempat melakukannya, tetapi itu tidak mencerminkan pengalaman saya - ketika saya tahu gaji orang pada umumnya mereka setara.
testerab

1
Pada tahun-tahun awal menjadi programmer, gaji Anda sangat tergantung pada berapa tahun pengalaman pemrograman yang Anda miliki. Jadi memiliki 2 tahun C # dan 1 tahun QA memberi Anda gaji 2 tahun C # daripada gaji 3 tahun C #.
Michael Shaw

3

Tidak harus - programmer dan penguji diharuskan memiliki keterampilan yang berbeda. Hanya karena Anda seorang programmer yang baik tidak berarti Anda bisa menjadi tester yang baik (banyak orang tidak mengerti itu, tetapi menjadi seorang programmer tidak secara otomatis membuat Anda memenuhi syarat untuk menjadi seorang tester).

Penguji yang hebat perlu memiliki keterampilan yang benar-benar jahat, dapat melakukan hal-hal yang tidak dirancang perangkat lunak untuk dilakukan, tetapi dapat mengharapkan pengguna melakukannya di dunia nyata. Itu membutuhkan keterampilan, kesabaran, kemampuan untuk melihat apa yang salah di mana, pemahaman tentang mentalitas pengguna dan banyak faktor lainnya.

Perhatikan bahwa saya menggunakan kata programmer dan tester - tetapi jika Anda seorang insinyur perangkat lunak dan belum memutuskan apakah Anda ingin menjadi programmer atau tester, maka itu mencakup kedua hal ini dan karenanya ya, Anda harus memiliki pengalaman dalam keduanya setidaknya dalam beberapa tahun pertama hidup Anda sebelum mengambil keputusan.

Itu tidak berarti bahwa Anda mengambil programmer yang berpengalaman dan membuatnya menguji untuk sementara waktu hanya untuk membuatnya mengerti betapa sulitnya para insinyur QA bekerja.


Benar Roopesh, meskipun saya pikir pasti ada persimpangan antara dua set keterampilan, di mana bekerja sebagai QA untuk rentang waktu kecil akan meningkatkan kecepatan seseorang meningkatkan keterampilan pengujian mereka.
Macy Abbey

1

Berikut adalah beberapa masalah potensial yang saya lihat dengan proposal Anda:

1) Jika Anda menyarankan agar Anda menempatkan insinyur perangkat lunak baru di lapangan ke departemen QA untuk tugas singkat, bukankah ini hanya memiliki efek sebaliknya? - mereka mungkin berasumsi bahwa QA adalah sesuatu yang Anda lakukan ketika Anda seorang pemula dan Anda tidak mengerti apa yang Anda lakukan - setelah semua, itulah cara kerjanya bagi mereka.

2) Menjadi penguji yang sangat buruk untuk sementara waktu tidak serta merta mengajari mereka sesuatu yang berharga. Tapi itu mungkin membuat mereka tidak bisa dijangkau nanti, karena mereka akan menganggap bahwa mereka tahu semua tentang pengujian sekarang, karena mereka menghabiskan 6 minggu di departemen pengujian sekali waktu.

3) Mengingat bahwa mereka jelas hanya akan berada di sana untuk waktu yang singkat, dan petugas QA akan mengetahui hal ini, kemungkinan besar mereka hanya akan diberikan tugas yang relatif ringan dan mudah yang membutuhkan sedikit pengawasan atau pemahaman, tetapi yang membuat mereka sibuk . Ini hanya akan memperkuat 1 dan 2.

4) Jika Anda ingin menghindari 1, 2, dan 3, bagaimana Anda akan meyakinkan departemen tes Anda bahwa ada baiknya menginvestasikan sejumlah besar energi untuk mengajar dan mengawasi seseorang yang bahkan tidak tertarik dalam pengujian? (Saya dapat memberi tahu Anda, dibutuhkan sejumlah waktu dan energi yang menakutkan untuk bekerja dengan seseorang yang, mari kita ingat, belum dipilih karena kemampuan pengujian mereka . Anda tidak menawarkan sumber daya tambahan tim uji selama beberapa minggu, Anda Sedang meminta mereka untuk kehilangan salah satu dari orang yang paling berpengalaman selama beberapa minggu, sementara mereka mengajar pemula Anda).

Setelah mengatakan semua itu, saya pikir tujuan keseluruhan Anda - untuk meningkatkan pemahaman pengujian perangkat lunak baru - benar-benar fantastis. Saya pikir saran Greg lebih mungkin untuk mencapainya - buat tim dev & QA Anda berkolaborasi secara erat bersama, dan bekerja untuk meruntuhkan penghalang di antara tim. (Saat ini saya bekerja di sebuah perusahaan di mana penguji dan pemrogram berada di tim yang sama - ini sangat bagus, dan saya tidak pernah ingin kembali bekerja di tim yang terpisah.)

Jika Anda masih ingin pemrogram melakukan tugas di QA - berikut ini sarannya: pimpin dengan memberi contoh. Pergi sendiri dulu. Mungkin membuatnya menjadi sesuatu yang anggota tim Anda bisa lakukan ketika mereka sudah bagus, dan ingin mendapatkan keunggulan tambahan, dengan menghabiskan sedikit waktu setiap minggu dengan tim lain yang berspesialisasi dalam bidang yang tumpang tindih - tes, DBA, dll. Jika Anda mempresentasikannya seperti itu, maka Anda akan memiliki lebih banyak peluang untuk sukses.


0

Saya telah memiliki semacam jalur karier yang merupakan kebalikan dari apa yang biasanya Anda lihat. Saya mulai sebagai dukungan perangkat lunak untuk fisika yang menantang secara ilmiah, kemudian akhirnya bekerja di persimpangan arsitektur, pemrograman, dan algoritma untuk perusahaan komputer. Setelah itu berlari saya melakukan optimasi kinerja kode teknik utama selama beberapa tahun, tetapi bahkan pekerjaan itu habis. Sekarang, bahwa saya mendekati usia pensiun saya melakukan QA pada kode yang sama. Ini adalah kombinasi dari tantangan, dan pekerjaan yang membosankan. Kami memiliki orang baru yang benar-benar tajam yang bekerja 100% untuk perbaikan bug, dan saya menghabiskan banyak bekerja dengannya. Ini adalah posisi yang menantang, dan Anda dapat belajar banyak dari melakukannya. Pada titik ini minat utama saya dalam pengembangan profesional adalah untuk anak laki-laki kembar saya, yang merupakan mahasiswa baru comp sci college. Jadi saya memiliki minat baru dalam belajar (atau belajar kembali) hal-hal yang akan relevan dengan karier mereka, terutama matematika terapan. Saya memiliki perspektif yang berbeda sekarang karena saya khawatir dengan QA / validasi, sedangkan untuk seperempat abad sebelumnya adalah kecepatan, kecepatan, kecepatan dengan biaya berapa pun.


Anekdot ini tampaknya tidak mengandung jawaban atas pertanyaan itu.
tidak ada yang

-2

Pengujian perangkat lunak adalah proses yang merusak daripada konstruktif. Tetapi programmer berpikir konstruktif untuk produk mereka untuk memastikan produk selesai tepat waktu dan sesuai anggaran. Jika pengembang perangkat lunak berpikir seperti merusak produk mereka sendiri maka siapa yang akan membangun produk selanjutnya. Jadi setiap bagian dari siklus pengembangan perangkat lunak harus dilakukan oleh orang-orang yang ditugaskan di setiap bagian siklus pengembangan. Jika Anda terlibat dalam dua atau lebih bidang maka itu yakin Anda tidak akan pernah sempurna pada salah satu dari mereka, jadi lakukan satu hal baik programmer atau QA atau opsi lain dan sempurna pada itu.

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.