Saya kebetulan mengenal beberapa admin sistem dan menurutnya, pengujian tidak diberikan preferensi dalam organisasi dibandingkan dengan pengembang. Tidak diragukan lagi rilis perangkat lunak tidak mungkin dilakukan tanpa penguji, tetapi saya tidak pernah menguji, jadi tidak terlalu menyadarinya. Tidak ada pelanggaran yang dimaksudkan.
Jawaban:
Dalam pengalaman saya, sayangnya, mereka sering diperlakukan seperti karyawan kelas dua dan bahkan lebih buruk lagi bagi programmer.
Itu berasal dari sejumlah hal:
Ketika penguji melakukan pekerjaan mereka dengan benar, mudah bagi semua orang tetapi programmer lupa bahwa mereka ada. Sama seperti admin jaringan, Anda hanya memperhatikan mereka ketika mereka tidak melakukan pekerjaan mereka, atau melakukannya dengan buruk. Jadi dari sudut pandang seluruh organisasi, mereka dikenang hanya karena kesalahan mereka.
Ini keliru dilihat sebagai pekerjaan entry-level untuk orang-orang yang bercita-cita untuk menjadi programmer, tetapi belum memenuhi syarat untuk pekerjaan itu. Bahkan, di satu perusahaan tempat saya bekerja, mereka diberi gelar pekerjaan Jr. Programmer meskipun ada permintaan mereka untuk mendapatkan gelar pekerjaan Q&A. Bahkan fakta bahwa mereka berada di departemen QA tidak cukup untuk membuat SDM mengalah.
Karena # 2, diasumsikan bahwa penguji semua orang entry-level, dan harus dibayar sesuai.
Tidak ada yang suka dikritik, dan itu terlalu umum bagi programmer defensif untuk tidak menyukai penguji karena pekerjaan mereka mengharuskan mereka untuk menunjukkan kesalahan programmer sepanjang hari. Sebagai seorang manajer, saya terus-menerus menjalankan misi PR untuk mengingatkan para programmer bahwa tim QA ada di sana untuk membuat mereka terlihat baik, bukan menceritakannya.
Ini cenderung menjadi pekerjaan yang dilakukan orang secara tidak sengaja dan bukan pilihan, setidaknya pada awalnya. Saya tidak ingat ada rencana gelar di salah satu sekolah yang saya hadiri yang menyiapkan orang untuk tanya jawab perangkat lunak. Mereka memang ada, tetapi biasanya di sekolah menengah kejuruan, yang hanya berkontribusi pada gagasan bahwa mereka adalah profesional yang kurang terampil.
Pekerjaan pengujian lebih mungkin daripada pekerjaan pemrograman yang dikirim ke luar negeri. Setidaknya para pemrogram dapat berpendapat bahwa lebih efisien untuk mengkomunikasikan kebutuhan desain secara lokal dan bahwa sangat berharga untuk menjaga pengetahuan tentang cara kerja aplikasi unggulan perusahaan di dalam perusahaan. Pengujian, bagaimanapun, jauh lebih mudah untuk modularisasi dan dengan demikian lebih mudah untuk melakukan outsourcing.
Untuk semua alasan di atas, penguji cenderung melihat tulisan di dinding dan pindah ke pekerjaan lain (seperti pemrograman), terutama yang benar-benar bagus. Ini berarti bahwa sebagian besar pekerjaan pengujian cenderung mendapatkan staf dengan lebih banyak orang entry level yang belum kehabisan tenaga atau pindah ke hal-hal lain, yang sayangnya memperkuat beberapa ide di atas.
Itu tergantung pada perusahaan, tetapi biasanya. Mereka sering dianggap sebagai warga negara kelas dua, dan di banyak perusahaan, pengujian dipandang sebagai posisi entry-level dari mana Anda kemudian beralih menjadi pengembang sejati.
Ini tentu saja omong kosong. Setelah bekerja dengan beberapa penguji yang baik, saya dapat mengatakan bahwa mereka berharga dan sulit didapat. Seseorang dengan pikiran yang cukup kreatif untuk menemukan bug yang tidak jelas dan cukup metodis untuk melakukan pekerjaan yang menyeluruh.
Namun, satu pengecualian: Saya kenal beberapa orang penguji Microsoft, dan saya dengar penguji ada warga kelas satu.
Saya telah bekerja sebagai penguji fungsional selama setahun di proyek yang cukup besar. Setiap tim dengan sekitar 10 anggota memiliki 2-3 penguji. Saya harus mengatakan bahwa kami diperlakukan sama pentingnya dengan proyek sebagai pengembang.
Menemukan bug tidak mudah. Pertama, para penguji harus memahami apa yang seharusnya dilakukan oleh kode. Itu berarti membaca dan memahami persyaratan. Kuncinya di sini adalah memahami persyaratan - jika penguji tidak dapat memahami persyaratan dengan cukup baik untuk mengetahui cara menulis kasus tes positif, Anda harus khawatir. Ini berarti bahwa pengembang telah menulis beberapa kode yang melakukan apa yang mereka anggap harus dilakukan. Apakah asumsi ini benar? Anda tidak tahu sampai Anda menyelesaikan persyaratan, dan Anda dapat berterima kasih kepada penguji Anda karena menemukan kesalahan itu.
Kedua, penguji harus menulis kasus pengujian palsu, yang memastikan bahwa kode tidak sesuai dengan yang seharusnya tidak dilakukan. Aturan praktis yang masuk akal adalah Anda menulis 5-10 test case palsu untuk setiap test case positif. Ini berarti memahami persyaratan lebih jauh, dan sering kali iniinformasi adalah, atau setidaknya dalam proyek kami, membingungkan dan ambigu. (Dan itu bukan karena upaya rendah pada persyaratan pengumpulan - kami memiliki sekitar 13.000 di tim kami saja.) Sekali lagi, para pengembang akan menulis kode mereka menggunakan asumsi mereka, atau bahkan lebih buruk, bahkan tidak menganggap ini sama sekali. Jadi apa yang dilakukan kode dalam kondisi ini yang tidak normal? Anda tidak tahu sampai Anda mengujinya. Mungkin programnya tidak merespons; mungkin hanya crash; mungkin itu menghancurkan data; mungkin ini memungkinkan pengguna untuk menjalankan perintah sebagai pengguna root. Apa pun itu, Anda ingin tahu. Kalau tidak, Anda mungkin mendapati diri Anda membaca tajuk utama berikut di surat kabar suatu hari nanti - BUG DALAM [NAMA PERUSAHAAN ANDA] PROGRAM FLAGSHIP MENCIPTAKAN ANGKA KARTU KREDIT KLIEN.
Jadi perlakukan penguji Anda dengan baik. Perlakukan mereka dengan baik. Bagaimanapun, mereka adalah orang-orang yang membasmi bug dalam perangkat lunak Anda dan membuat hidup Anda, dan kami, lebih mudah.
Penguji yang baik yang dapat menganalisis masalah secara efisien dan dapat melakukan otomasi pengujian yang layak bernilai emas karena ada begitu banyak penguji koboi di luar sana (ketika mewawancarai satu "penguji" begitu dia benar-benar tertawa terbahak-bahak saat dia menyadari bahwa kita tahu dia sedang membuat barang-barang di tempat sementara sedang ditanyai di CV-nya).
Di tim saya, penguji diperlakukan sama - yang mencakup tanggung jawab dan gaji. Jika Anda ingin tester yang mengklik hari berikutnya - outsource mereka ke tempat yang murah (kami juga melakukannya).
Perbarui setelah membaca jawaban lain: Ada banyak profesional QA yang menyukai pekerjaan yang mereka lakukan. Hanya untuk memberikan perspektif lain jika Anda belum menemukan posisi QA yang disegani, satu contoh di sini: Pengujian aplikasi / aplikasi seluler tertanam untuk pembuat mobil terkemuka. Mereka memastikan persyaratan bisnis sepenuhnya dipenuhi sebelum kendaraan dilepaskan ke pasar dan tidak ada pengguna yang mengalami dashboard mobil yang lambat atau tidak responsif. Mereka bekerja erat dengan manajer dan manajemen tingkat yang lebih tinggi, dan juga pengembang mulai dari perencanaan proses QA hingga pengujian langsung pada simulator di fasilitas desain. Saya tidak bisa menganggap mereka rendah hati, mereka menangani tanggung jawab besar dan kepemilikan dan mereka adalah insinyur terbaik.
sekarang jawaban saya sebelumnya, sisi sebaliknya:
Saya telah mengamati bahwa lulusan teknik benci dialokasikan ke unit pengujian (konteks: India, perusahaan layanan perangkat lunak besar di mana semuanya didorong oleh 'persyaratan bisnis'), karena mereka menganggapnya sebagai lingkungan kerja non-teknis. Mereka diberikan lembar excel dengan instruksi seperti 'klik semua tautan di halaman web dan verifikasi', dipaksa untuk bekerja dengan lulusan dari aliran non-teknis (sains, seni) yang mereka anggap sebagai penghinaan dan merasa keterampilan teknologi mereka tidak dimanfaatkan. Alokasi ini murni berdasarkan persyaratan organisasi, dan yang lebih segar, sebagian besar waktu, tidak memiliki kekuatan untuk menegosiasikan jalur kariernya. Jadi, jika Anda seorang pencari kerja yang mengincar perusahaan IT sebesar itu, Anda telah diperingatkan. Anda tidak bisa berbuat banyak, secara praktis, kecuali keluar dari perusahaan pada waktu yang tepat.
Kecuali ada peluang untuk mempelajari pengujian otomatis, pengujian beban / kinerja, dll., Kariernya stagnan sampai batas tertentu. Secara pribadi saya tahu peluang untuk tugas di tempat (= banyak uang dari sudut pandang programmer lepas pantai) lebih banyak untuk unit pengujian di organisasi saya daripada unit lainnya. Mereka bekerja dengan semua vertikal industri sebagai pengisi atau lem, karena pengujian tidak dapat dihindari dalam proyek di semua domain.
Jika Anda yakin dapat mengarahkan karier seperti yang Anda inginkan, pengujian bukanlah hal yang mudah. Dengan pengalaman 4-5 tahun dan sedikit keberuntungan Anda bisa mendapatkan eksposur yang sangat baik, kadang-kadang berinteraksi dengan pengguna bisnis tingkat atas. Anda juga dapat memiliki pemahaman yang baik tentang industri / domain Anda bekerja (dibandingkan dengan pengembang yang sebagian besar akan fokus pada beberapa bagian dari sistem). Pada titik ini orang dapat memilih untuk beralih ke peran analis bisnis juga.
Saya tahu perusahaan tempat tim QA bertanggung jawab atas rilis. Ini berarti bahwa mereka memiliki kekuatan untuk memblokir rilis karena kurangnya kualitas. Jika masalah dilaporkan di lapangan, mereka adalah yang pertama di garis api (setelah insinyur lapangan).
Biasanya mereka memiliki pengetahuan domain yang lebih tinggi. Mereka cenderung mengetahui fungsionalitas keseluruhan produk dengan lebih baik sementara pengembang berkonsentrasi pada modul / fitur mereka.
Saya juga tahu org QA di mana mereka harus menulis alat tes mereka sendiri. Belum lagi mengotomatiskan semuanya. Saya seorang pengembang, dan selalu menghargai QA yang menguji fitur saya.
Setidaknya di organisasi saya, QA diperlakukan sama dengan pengembang. Saya pikir itu karena domain (telekomunikasi) di mana protokol dan pengetahuan arsitektur jaringan sama-sama dihargai dengan keterampilan pemrograman.
Iya. Suka atau tinggalkan mereka sama pentingnya tetapi selalu kurang disukai. Mungkin karena mereka mudah diganti.