QA engineer
QA engineer memegang kualitas sebagai sebuah disiplin, bukan sebagai titik pemeriksaan di ujung sprint. Pekerjaannya dimulai dengan mempertanyakan kebutuhan sebelum apa pun dibangun, berlanjut ke menentukan apa yang memang layak diuji, dan berakhir pada pandangan yang bisa dipertanggungjawabkan tentang apakah sebuah rilis layak sampai ke pengguna. Panduan ini menjelaskan cakupan pekerjaannya, tekanan yang membuatnya diperlukan, dan mengapa ia sebuah disiplin, bukan sekadar skrip yang diikuti.
Apa yang dikerjakan seorang QA engineer?
QA engineer mencari tahu bagaimana sebuah produk perangkat lunak bisa gagal dan memastikan timnya mengetahui kegagalan itu sebelum penggunanya. Pekerjaannya mencakup menelaah kebutuhan dan kriteria penerimaan untuk mencari ambiguitas sebelum pengembangan dimulai, merancang test di sekitar tempat risikonya benar-benar berada, menjelajahi produk untuk memunculkan masalah yang tidak akan dicari pemeriksaan terskrip mana pun, melaporkan defect dengan cukup jelas sehingga dipahami dan diprioritaskan dengan tepat, serta memberi masukan tentang apakah sebuah rilis sudah siap. Pada dasarnya ini peran penilaian: keterampilan yang menentukan adalah memutuskan apa yang layak mendapat perhatian dan apa yang tidak, dalam waktu yang tersedia.
Bagian tersulit dari pekerjaan ini adalah mengurangi. Pengujian yang menyeluruh bukan sekadar tidak praktis, melainkan mustahil secara aritmetika â sebuah formulir dengan sepuluh field dan beberapa keadaan valid pada masing-masingnya menghasilkan lebih banyak kombinasi daripada yang bisa dijalankan tim mana pun seumur hidup. Karena itu setiap keputusan pengujian adalah keputusan alokasi, dan dua orang bisa menjalankan jumlah kasus yang sama sambil menghasilkan informasi yang sama sekali berbeda banyaknya. Ini juga sebabnya cakupan penuh adalah sasaran yang buruk: code coverage mencatat baris mana yang dieksekusi saat test berjalan, bukan apakah perilaku yang dihasilkan benar, apakah asersinya bermakna, atau apakah kebutuhannya memang tepat sejak awal.
Sebagian besar pekerjaan yang paling bernilai terjadi sebelum kodenya ada. Defect jauh lebih sering berasal dari kesalahpahaman daripada dari salah ketik â kriteria penerimaan yang tidak menyebutkan apa yang terjadi ketika inputnya kosong, aturan bisnis yang dibaca berbeda oleh dua orang, integrasi yang perilaku gagalnya tidak pernah dibicarakan. Menanyakan apa yang terjadi di batas nilai selagi spesifikasinya masih ditulis menghilangkan sebuah defect yang jika tidak akan ditemukan, dilaporkan, ditriase, diperbaiki, direview, lalu diuji ulang. Menemukan bug adalah bagian yang terlihat dari peran ini; mencegahnya adalah bagian yang lebih bernilai, dan sebagian besar tak terlihat â karena itulah ia perlu diakui secara eksplisit sebagai bagian dari pekerjaannya.
Ada satu jebakan organisasional yang terus membayangi peran ini. Ketika kualitas diperlakukan sebagai departemen alih-alih sebagai milik bersama tim, QA berubah menjadi gerbang tempat pekerjaan dilempar: engineer menguji lebih seadanya karena toh ada orang lain yang akan mengujinya, pekerjaan yang belum terverifikasi menumpuk di akhir setiap sprint, dan orang yang seharusnya meningkatkan kualitas menghabiskan waktunya memproses antrean. Susunan yang produktif justru sebaliknya â meningkatkan kemampuan menguji seluruh tim, membuat risiko terlihat sejak awal, dan mengerjakan penjelajahan serta analisis yang tidak sempat atau tidak terpikir dikerjakan orang lain.
Kapan tim membutuhkan kapabilitas ini
Sebagian besar tim menguji pekerjaannya sendiri dengan memadai untuk sementara waktu. Berikut tekanan yang biasanya menyingkapkan batas dari susunan itu.
Defect yang lolos selalu berujung pada kebutuhannya
Masalah setelah rilis ternyata bukan kesalahan penulisan kode melainkan ketidaksepakatan tentang apa yang seharusnya terjadi. Tidak ada yang menginterogasi spesifikasi untuk mencari ambiguitas sebelum masuk sprint, sehingga kesalahpahaman yang sama ditemukan berulang kali pada titik paling mahal dalam siklusnya.
Tidak ada yang bisa memastikan sebuah rilis aman dikirim
Keputusannya diambil berdasarkan firasat, berdasarkan pipeline yang hijau, atau berdasarkan siapa yang terdengar paling yakin saat stand-up. Ketika kemudian ada yang salah, tidak ada catatan tentang apa yang sudah diketahui dan apa yang diasumsikan, sehingga percakapan yang sama terulang pada rilis berikutnya.
Kegagalan menumpuk di titik pertemuan antarfitur
Setiap fitur berfungsi ketika diperiksa sendiri-sendiri dan masalahnya muncul pada interaksi di antaranya â perubahan izin yang mengubah isi sebuah ekspor, pengaturan mata uang yang sampai ke satu layar dan tidak ke layar lain. Engineer yang menguji pekerjaannya sendiri jarang menyeberangi batas itu, karena batas itu bukan milik siapa-siapa.
Laporan bug memakan biaya lebih besar daripada bug-nya
Laporan datang tanpa langkah reproduksi, tanpa rincian environment, tanpa pernyataan hasil aktual dibanding yang diharapkan, dan kadang tanpa kesepakatan bahwa perilakunya memang salah. Engineer menghabiskan porsi waktu yang tidak sedikit untuk merekonstruksi laporan alih-alih memperbaiki apa yang dilaporkan.
Produknya punya kewajiban di luar sekadar berfungsi benar
Konformansi aksesibilitas, persyaratan regulasi, aturan penanganan data, atau komitmen layanan dalam kontrak memunculkan kategori kegagalan yang tidak dicari test fungsional dan tidak berada pada posisi untuk disadari developer selagi membangun.
Tim hanya pernah mengonfirmasi harapannya sendiri
Orang menguji apa yang mereka niatkan untuk dibangun. Itu batas kognitif, bukan masalah kedisiplinan, dan itulah sebabnya seorang engineer bisa menguji pekerjaannya sendiri dengan teliti dan tetap melewatkan kasus yang tidak pernah terbayangkan olehnya. Orang yang kebiasaan profesionalnya mencari hal tak terduga menemukan kelas defect yang sama sekali berbeda.
Kapabilitas inti
Analisis risiko
Mencari tahu bagian produk mana yang paling menyakitkan bila rusak, seberapa besar kemungkinan masing-masing rusak, dan mengarahkan usaha sesuai itu. Ini menuntut pemahaman atas bisnisnya sekaligus atas perangkat lunaknya â komponen yang rapuh secara teknis dan komponen yang kritis secara komersial sering kali bukan hal yang sama.
Strategi pengujian
Menentukan apa yang diperiksa otomatis, apa yang diperiksa manusia, apa yang diverifikasi di produksi lewat monitoring, dan apa yang secara sadar dibiarkan tidak diuji. Strategi yang tidak menyebutkan apa yang tidak akan diuji adalah daftar keinginan, bukan rencana.
Analisis kebutuhan dan kriteria penerimaan
Membaca sebuah spesifikasi untuk menemukan apa yang tidak dikatakannya: kondisi batas yang hilang, perilaku kesalahan yang tidak terdefinisi, asumsi tersirat tentang urutan atau keadaan, dan aturan yang ditafsirkan berbeda oleh dua pembaca. Pertanyaan yang diajukan pada tahap ini menghilangkan defect, bukan mendeteksinya.
Teknik desain test
Menerapkan equivalence partitioning, analisis nilai batas, decision table, pemodelan transisi keadaan, dan kombinasi berpasangan untuk menyusutkan ruang input yang mustahil menjadi kumpulan kasus yang bisa dipertanggungjawabkan. Inilah beda antara cakupan yang diargumentasikan dan cakupan yang sekadar diklaim.
Exploratory testing
Penyelidikan terstruktur ketika merancang, menjalankan, dan belajar terjadi bersamaan, biasanya ditata dalam sesi berbatas waktu dengan charter yang eksplisit. Bila dikerjakan dengan baik ia disiplin dan terdokumentasi, dan ia menemukan defect yang tidak bisa ditemukan skrip yang ditetapkan sebelumnya, karena skrip hanya mencari apa yang sudah terpikirkan seseorang.
Pelaporan dan advokasi defect
Menulis laporan yang bisa direproduksi orang yang tidak terlibat, lalu meyakinkan mengapa masalah itu penting. Advokasi adalah separuh yang diremehkan: defect yang dilaporkan benar tetapi diberi tingkat keparahan yang keliru, atau dijelaskan dengan cara yang mengaburkan dampaknya bagi pengguna, diam-diam turun prioritas lalu ikut terkirim.
Triase dan penilaian tingkat keparahan
Memisahkan tingkat keparahan dari prioritas, mengenali ketika beberapa laporan menggambarkan satu penyebab yang sama, dan mengidentifikasi laporan yang tampak kosmetik tetapi menandakan ada yang salah secara struktural. Triase yang andal menjaga backlog defect tetap menjadi alat pengambilan keputusan alih-alih kuburan.
Penilaian kesiapan rilis
Merangkai apa yang diketahui dan apa yang tidak menjadi pernyataan yang bisa ditindaklanjuti pengambil keputusan: risiko mana yang sudah diperiksa, mana yang diterima, apa yang belum tercakup, dan apa yang perlu diawasi setelah deployment. Perannya adalah memberi informasi bagi keputusan rilis, bukan memegang hak veto.
Pengamatan kebergunaan dan aksesibilitas
Menyadari perilaku yang benar secara teknis dan keliru secara praktis â tindakan destruktif tanpa konfirmasi, pesan kesalahan yang tidak memberi tahu pengguna apa pun yang bisa dilakukan, alur yang tidak bisa diselesaikan dengan keyboard. Audit spesialis adalah bidangnya sendiri, tetapi banyak hal sudah tertangkap sebelum seorang auditor melihatnya.
Pemahaman domain
Mengetahui perangkat lunaknya untuk apa dan siapa yang bergantung padanya. Pengetahuan domain mengubah "totalnya tidak seperti yang saya duga" menjadi "pembulatan pajaknya keliru untuk pesanan yang dikirim ke yurisdiksi kedua", dan biasanya inilah aset seorang QA engineer yang nilainya paling cepat bertambah.
Ekosistem teknologi
Berikut teknologi yang umum dipakai dalam quality assurance. Daftar ini menggambarkan lanskap disiplinnya secara umum sebagaimana dipraktikkan di pasar, bukan klaim tentang perangkat yang dikuasai engineer mana pun. Tool di sini lebih sedikit menentukan dibanding pada kebanyakan peran engineering, karena inti pekerjaannya adalah analisis dan penilaian, bukan mengoperasikan sebuah produk tertentu.
Manajemen dan pelacakan test
- Jira
- TestRail
- Xray
- Zephyr
- Azure Test Plans
Inspeksi dan eksplorasi
- Browser developer tools
- Postman
- Charles Proxy
- Fiddler
- Klien SQL
- Konsol feature flag
Spesifikasi dan kolaborasi
- Gherkin
- Example mapping
- Confluence
- Notion
- Miro
Pemeriksaan aksesibilitas dan kebergunaan
- axe DevTools
- WAVE
- NVDA
- VoiceOver
- Lighthouse
Sinyal dari produksi
- Sentry
- Datadog
- Grafana
- Kibana
- Tool session replay
Cakupan perangkat dan platform
- BrowserStack
- Sauce Labs
- Xcode Simulator
- Android Emulator
Bagaimana peran ini bekerja dengan tim Anda
Engineer bekerja di dalam tim Anda, mengikuti prioritas dan standar Anda. Anda yang mengarahkan pekerjaannya; Talent.ID menangani hubungan kerjanya. Pembagian di bawah ini adalah keseluruhan pengaturannya.
Tetap milik Anda
- Produk
- Prioritas bisnis
- Roadmap
- Arsitektur
- Prioritas sprint
- Standar engineering
- Kolaborasi teknis sehari-hari
Ditangani Talent.ID
- Hubungan kerja
- Payroll
- Benefit karyawan
- Administrasi talenta
- Hubungan karyawan berkelanjutan
Seperti apa ini dalam praktik
Skenario hipotetis, ditulis untuk menunjukkan bagaimana model kerjanya diterapkan. Ini bukan klien Talent.ID dan bukan proyek yang pernah dikerjakan.
- Tantangan
- Sebuah tim beralih ke ritme rilis yang lebih sering dan mendapati proses kualitasnya tidak bertahan menghadapi perubahan itu. Verifikasi selama ini dikerjakan sekaligus di akhir tiap siklus, defect muncul terlalu telat untuk diperbaiki tanpa menggeser tanggal, dan tidak ada yang bisa memberi product owner gambaran jelas tentang apa yang sudah dan belum diperiksa sebelum sebuah deployment.
- Pendekatan
- Tambahan kapasitas kualitas bekerja di dalam proses delivery yang sudah dijalankan tim â alur tiket mereka, definisi selesai mereka, ritme rilis mereka, dan standar kualitas mereka. Engineer dan product owner klien tetap menetapkan prioritas dan memutuskan apa yang dikirim; kapasitas tambahan menyumbang analisis risiko, desain test, dan pekerjaan eksplorasi bersama mereka, bukan beroperasi sebagai tahapan terpisah yang harus dilewati pekerjaan.
- Yang ditambahkan ke tim
- Tim memperoleh kapasitas kualitas sambil tetap memegang keputusan produk dan standar engineering-nya. Apa yang dianggap siap dirilis tetap menjadi penilaian klien.
Disiplin terkait
Pertanyaan yang sering diajukan
- Apa bedanya QA engineer dan test automation engineer?
- QA engineer bertanggung jawab atas kualitas sebagai sebuah disiplin: risiko mana yang penting, apa yang dibiarkan tak terdefinisi sebuah spesifikasi, apa yang tidak akan pernah terpikir dicari oleh pemeriksaan terskrip, dan apakah sebuah rilis layak keluar. Test automation engineer bertanggung jawab atas sistem pengujian otomatisnya sendiri â desain framework, data test, kendali environment, menjaga hasilnya deterministik, dan membuat eksekusinya cukup cepat untuk layak ditunggu. Peran pertama ditentukan oleh keluasan pertimbangan; yang kedua adalah peran engineering yang keluarannya adalah suite itu sendiri. Keduanya saling melengkapi alih-alih saling menggantikan: suite yang dibangun tanpa pertimbangan kualitas akan memeriksa hal yang keliru dengan sangat andal.
- Apakah QA engineer perlu menulis kode?
- Cukup untuk bekerja efektif, dan itu biasanya lebih sedikit daripada yang disiratkan iklan lowongan. Membaca basis kodenya, melakukan query ke database, memanggil API secara langsung, mengikuti stack trace, dan memeriksa trafik jaringan semuanya menaikkan kualitas pekerjaannya secara berarti. Membangun dan memelihara framework otomatisasi adalah pekerjaan berbeda dengan pusat gravitasi berbeda, dan menuntut kemampuan pemrograman yang kuat pada peran QA cenderung menyaring keluar justru kandidat analitis dan komunikatif yang paling dibutuhkan peran ini.
- Apakah menambahkan QA engineer memperlambat tim?
- Iya, ketika kualitas ditata sebagai gerbang: pekerjaan diselesaikan, diserahkan, diantrekan, dikembalikan, lalu dikerjakan ulang, dan serah terimanya sendiri yang menjadi penghambat. Umumnya tidak, ketika QA engineer terlibat sejak kebutuhannya ditulis, karena defect yang tidak pernah dibangun adalah defect yang paling banyak menghemat waktu. Bila menambah kapasitas kualitas justru memperlambat sebuah tim, penyebabnya biasanya susunannya, bukan orangnya.
- Tidak bisakah developer menguji pekerjaannya sendiri?
- Mereka memang seharusnya begitu, dan itu saja tidak cukup. Developer yang menguji pekerjaannya sendiri memverifikasi bahwa pekerjaannya melakukan apa yang mereka maksudkan, sehingga kasus yang tidak pernah mereka pertimbangkan tetap tak tersentuh â dan seberapa pun telitinya, batas itu tidak sepenuhnya hilang, karena ia melekat pada kenyataan bahwa merekalah yang membangunnya. QA engineer membawa model independen tentang apa yang seharusnya dilakukan perangkat lunaknya, serta kebiasaan yang tertuju pada hal tak terduga alih-alih pada yang diniatkan.
- Sebaiknya QA berada di bawah engineering atau berdiri sebagai fungsi terpisah?
- Menempatkan QA engineer di dalam tim delivery umumnya lebih berhasil, karena kedekatanlah yang memungkinkan pencegahan dan jaraklah yang mengubah kualitas menjadi serah terima. Jalur pelaporan terpisah bisa membantu menjaga standar profesi di organisasi yang lebih besar, tetapi ketika quality assurance menjadi departemen mandiri yang menerima pekerjaan yang sudah jadi, kegagalan yang sudah dikenal itu menyusul: engineer menguji lebih seadanya, antreannya memanjang, dan kualitas menjadi sesuatu yang tim merasa telah dialihkan ke pihak lain.
- Setingkat apa senioritas yang dibutuhkan pekerjaan kualitas?
- Bergantung pada seberapa banyak yang belum mapan. Menjalankan pendekatan yang sudah baku terhadap fitur yang terspesifikasi dengan baik bisa dikerjakan dengan baik pada tingkat menengah. Menetapkan apa yang sebenarnya harus diuji sebuah tim, menegosiasikan risiko dengan product owner, atau membangun praktik kualitas di tempat yang belum punya sama sekali menuntut orang yang pernah melihat bagaimana keputusan semacam itu berjalan seiring waktu â dan biaya dari pertimbangan yang lemah di sini baru muncul berbulan-bulan kemudian, dalam bentuk hal-hal yang berhenti disadari tim.
- Bagaimana QA engineer bekerja dengan tim engineering yang sudah ada?
- Ditempatkan di dalam tim Anda, seorang QA engineer mengikuti proses delivery Anda yang sudah berjalan â alur kerja Anda, definisi selesai Anda, standar engineering Anda, dan ritme rilis Anda. Ini skema penambahan kapasitas tim, sehingga prioritas harian, arah produk, dan keputusan untuk merilis semuanya tetap milik Anda. Sisi Talent.ID adalah hubungan kerja, administrasi talenta, payroll, benefit karyawan, dan hubungan yang berkelanjutan dengan karyawan tersebut.
Ceritakan kebutuhan tim Anda
Jelaskan kekurangannya â pekerjaannya, stack-nya, cara tim Anda berjalan â dan kami akan menyampaikan apa yang dapat kami dukung. Bila bukan sesuatu yang bisa kami bantu, kami akan mengatakannya.