Mungkin Membubarkan Tim QA Adalah Keputusan yang Keliru

• Setelah optimasi ala DevOps mengurangi bottleneck pada rilis, deployment, manajemen image, dan rollback, titik paling lambat dalam pengiriman perangkat lunak yang tersisa adalah pengujian
• Industri mulai melihat tim QA, bukan pengujian itu sendiri, sebagai bottleneck; ekspektasi terhadap peran ini meningkat, tetapi perlakuan memburuk, makin banyak dikontrakkan, di-offshore, dan perekrutan dipangkas
• Pembubaran organisasi QA mematahkan semangat tenaga QA berpengalaman, sementara developer tidak secara alami mengambil alih pekerjaan kualitas, sehingga masalah perangkat lunak berkualitas rendah membesar
• Manajemen kualitas adalah pekerjaan nyata yang harus dinamai dan ditugaskan, seperti pelacakan cacat, klasifikasi, investigasi, advokasi kualitas, dan pengujian end-to-end
• Jika pekerjaan kualitas tidak diorganisasi, orang yang menemukan dan membereskan masalah tidak mendapat imbalan, sementara pihak yang membuat dengan cepat lalu merusaknya terus-menerus diberi penghargaan

---

Bottleneck yang tersisa setelah optimasi DevOps

• Para praktisi DevOps menerapkan Theory Of Constraints untuk mengoptimalkan pipeline dan praktik pengiriman perangkat lunak secara kuat
• Manajemen rilis manual, deployment, manajemen image, dan rollback produksi menjadi target otomatisasi
• Dalam proses dari backlog produk hingga kode sampai ke pelanggan, aktivitas bernilai rendah diperlakukan sebagai bottleneck yang harus dihilangkan atau dioptimalkan
• Akibatnya, bagian paling lambat dalam pengiriman perangkat lunak yang tersisa adalah pengujian
  • Pengujian juga merupakan alasan adanya continuous delivery
  • Pengujian bisa dibuat lebih cepat, diotomatisasi, dan diparalelkan
  • Jika aktivitas paling bernilai dalam suatu praktik adalah bottleneck, itu dinilai sudah mendekati kondisi optimal

Industri melihat tim QA sebagai bottleneck

• Kebiasaan optimasi diterapkan melampaui pengujian itu sendiri, hingga ke peran QA
• Ada gerakan untuk mengurangi integration test dan end-to-end test menjadi unit test agar bisa diparalelkan
• Pada level tenaga kerja, terjadi pula dorongan memindahkan orang-orang yang dianggap tidak bisa coding ke unit-unit fitur
• Industri mulai melihat bahwa bottleneck-nya mungkin bukan pengujian, melainkan tim QA
  • Ekspektasi terhadap peran QA meningkat
  • Gaji turun atau tidak naik dibandingkan peran lain
  • Peran ini makin dikontrakkan dan di-offshore
  • Pilihan untuk mengurangi perekrutan engineer QA terus berlanjut

Lingkaran setan akibat penyusutan peran QA

• Orang-orang yang tetap berada di QA makin ditempatkan dalam struktur yang merugikan
  • Orang yang cukup mahir coding atau lelah dengan perlakuan tersebut meninggalkan QA
  • Orang lain memandang tenaga yang tersisa di QA sebagai “orang yang belum cukup baik untuk keluar dari bidang itu”
  • Makin sedikit pula orang yang merekomendasikan bidang QA kepada lulusan baru
• Perusahaan berpisah dengan QA dengan cara seperti, “kami tidak akan lagi menyediakan fungsi ini, urus sendiri”
• Proses ini adalah sesuatu yang tidak sopan dan mematahkan semangat bagi orang-orang yang telah membangun karier di QA
• Pembubaran QA memperbesar masalah perangkat lunak berkualitas rendah, dan banyak organisasi menjadi tidak tahu siapa harus melakukan apa dalam kualitas perangkat lunak
• Organisasi yang mempertahankan fungsi QA pun kesulitan menemukan posisi peran itu di dalam bidang yang sudah terlanjur rusak

“Memecat tester” bukanlah solusi

• “Satu trik aneh” untuk pengiriman perangkat lunak yang lebih cepat bukanlah memecat tester
• Merusak bidang QA nyaris merupakan salah satu kesalahan manajemen terburuk
  • Itu adalah pilihan yang menghancurkan sesuatu yang telah berkembang selama puluhan tahun
  • Dampaknya mungkin tidak terasa selama bertahun-tahun
  • Saat organisasi akhirnya merasakan masalahnya, pemulihan yang berarti bisa memakan waktu bertahun-tahun lagi
• Bagian yang memang sudah rusak dalam peran QA tetap belum terselesaikan
• Pembagian kerja tidak terjadi, dan developer tidak dengan sukarela mengambil pekerjaan QA tanpa kompensasi tambahan, pengakuan, atau struktur imbalan
• Sebagian orang yang pernah bekerja dengan tim QA berkinerja tinggi dapat meniru sebagian perilakunya, tetapi engineer dan manajer yang lebih baru sulit mengetahui apa yang hilang
• Prinsip intinya adalah bahwa quality assurance adalah pekerjaan
  • Seperti pekerjaan lain, mengasumsikan bahwa “seseorang” akan melakukannya akan berakhir gagal
  • Membiarkannya sebagai pekerjaan tak terlihat juga mengarah pada kegagalan

Pekerjaan yang diperlukan dalam manajemen kualitas perangkat lunak

• Pelacakan cacat

  • Diperlukan cara agar pengguna dapat mengirim informasi bug dan developer dapat mencatat bug
  • Bug adalah tiket individual yang menjelaskan apa yang salah dan seberapa parah dampaknya
  • Bug bukan deskripsi pekerjaan perbaikannya sendiri
  • Bug harus memuat cacat, cara mereproduksi, dan dampaknya
  • Sebagian besar tim developer yang baru-baru ini bekerja bersama penulis tidak melacak cacat semacam ini
  • Alasan seperti “toh tidak akan diperbaiki”, “itu bukan pekerjaan saya”, atau “saya diberi imbalan untuk fitur baru” tidak membenarkan hasil berkualitas rendah
  • Mengelola daftar bug itu sendiri adalah pekerjaan

• Klasifikasi dan penentuan prioritas

  • Klasifikasi bug adalah proses menetapkan, memprioritaskan, merapikan, mengelompokkan, dan menghapus duplikasi bug yang masuk
  • Memiliki kriteria yang konsisten untuk tingkat keparahan tinggi, sedang, dan rendah membantu organisasi
  • Dulu ini disebut “kebersihan bug”
  • Menentukan tim mana yang harus menangani bug tersebut juga adalah pekerjaan
  • Organisasi yang berfungsi baik dapat merespons lebih baik saat ada tekanan eksternal atau restrukturisasi
  • Meski ada PHK, penurunan kualitas dikelola secara bertahap
  • Saat reorganisasi, kategori bug tertentu diserahkan ke tim baru
  • Bug pada fitur yang dihentikan dibuang secara massal
  • Mengatakan bahwa tim yang sama sekali tidak mengalami stres eksternal atau reorganisasi boleh mengabaikan proses klasifikasi ini hampir seperti lelucon

• Investigasi cacat

  • Reproduksi adalah bagian penting dari manajemen bug
  • Seseorang harus mengubah laporan seperti “saya mencoba membeli tiket film tetapi tidak bisa” menjadi “masalah encoding karakter pada pelanggan dengan karakter non-Inggris dalam nama mereka merusak alur pembelian”
  • Pertanyaan seperti “berapa kali masalah ini terjadi” dan “apa dampaknya terhadap pengguna” harus dijawab oleh manusia sungguhan yang meluangkan waktu
  • Investigasi cacat adalah pekerjaan menerapkan ketelitian engineering pada backlog bug

• Peran yang berfokus pada kualitas

  • Memiliki orang di dalam perusahaan yang berfokus pada kualitas produk akhir memiliki nilai nyata
  • Kualitas bisa menjadi urusan semua orang, tetapi pada saat yang sama harus menjadi pekerjaan seseorang
  • Ketegangan antara kualitas dan kecepatan membutuhkan orang yang mengadvokasi kualitas
  • Alat pengujian, kualitas pengujian, dan rencana pengujian membutuhkan pihak yang berkepentingan dan punya pendapat untuk melakukannya sebaik mungkin

• Pengujian end-to-end

  • Salah satu masalah terbesar dan paling umum di banyak organisasi engineering adalah kepemilikan sistem
  • Peningkatan kompleksitas arsitektur terjadi dengan tujuan menjaga tim dan aplikasi tetap kecil, dan ini bisa menjadi strategi yang masuk akal
  • Namun akibatnya, muncul kekosongan pada bagian terpenting aplikasi
  • Tim rata-rata tidak lagi melakukan penggunaan dan verifikasi produk pada level end-to-end, karena itu terlalu sulit
  • Harus dipastikan apakah ada orang di dalam organisasi yang benar-benar menggunakannya sebelum produk dirilis

Masalah organisasi yang muncul ketika pekerjaan kualitas diabaikan

• Bisa saja muncul respons, “kami agile, lean, dan dinamis, jadi tidak perlu melakukan pekerjaan seperti ini”
• Jika dilihat lebih dekat, pekerjaan-pekerjaan ini kemungkinan besar sudah terjadi di dalam organisasi, tetapi dilakukan dengan buruk
• Mendengar pernyataan “kami tidak melakukan quality assurance” di bidang lain seperti mobil, bank, atau dokter bukanlah pengalaman yang baik
• Jika aktivitas kualitas tidak dikenali dan diorganisasi, situasinya dapat menjadi sangat buruk
• Karyawan yang paling berhati nurani menjadi yang paling getir
  • Mereka melihat dan sering menyelesaikan masalah kualitas
  • Mereka tidak mendapat pengakuan untuk itu
  • Saat mengangkat kekhawatiran kualitas, mereka diperlakukan seperti orang yang ingin memperlambat laju
  • Mereka melihat orang-orang yang “bergerak cepat dan merusak banyak hal” berulang kali mendapat imbalan
  • Mereka merasa berada dalam posisi membersihkan kekacauan orang lain dengan marah
• Dalam organisasi seperti ini, sikap peduli itu sendiri menjadi kerugian bagi karier

[GN⁺]

Opini Hacker News

• Pada akhir 1970-an, di awal karier, saya bekerja di Product Assurance, yakni organisasi QA di IBM Hursley Park. Untuk menguji produk yang menjadi tanggung jawab saya, sebuah sistem pengolah kata, saya membuat kode dan perangkat keras, lalu menjalankan test case terhadap sistem yang diuji
  Isu yang ditemukan hanya disampaikan kepada tim pengembang dalam bentuk penjelasan umum, dengan tujuan membuat tim pengembang memperbaiki bug, bukan sekadar membuat test case lulus. Hasilnya, jika kami menemukan 3 bug pada pemenggalan baris untuk kata ber-hyphen dan penghapusan dengan backspace, tim pengembang bisa memperbaiki 4 bug di area itu, tetapi dari bug yang benar-benar kami temukan hanya 2 yang ikut diperbaiki; dengan begitu, jumlah bug nyata yang tersisa bisa diperkirakan secara statistik
  Di organisasi yang tidak memiliki tim QA, kami memperkenalkan konsep sniff test. Biasanya ini berupa sesi sekitar 1 jam ketika siapa pun di perusahaan atau departemen mencoba-coba fitur baru; meski fitur sudah dianggap selesai, kondisi batas hampir selalu rusak. Masalah sering muncul hanya dengan mencoba kondisi sederhana seperti mengisi semua field dengan "" lalu submit, menavigasi UI hanya dengan keyboard, atau memakai font besar dan zoom browser 110%, dan sekarang hal itu bahkan tidak lagi mengejutkan

  • Di perusahaan kami, hal seperti itu disebut bug bash, dan biasanya sangat produktif dari sisi jumlah cacat yang ditemukan
    Saat pengembangan fitur kecil, biasanya hanya para programmer yang mengujinya, dan ini sangat berguna karena cara itu bisa berbeda dari cara penggunaan pengguna akhir yang sebenarnya
  • Strategi menyembunyikan asal-usul tes otomatis dari developer menarik. Sepertinya itu bisa membuat mereka berfokus pada pemecahan masalah yang sebenarnya, bukan menonaktifkan tes atau hanya menyesuaikan diri agar lulus tes
  • Dulu di Microsoft, ini disebut bug bash, dan startup saya juga mewarisi ide tersebut. Seluruh perusahaan didorong untuk mengosongkan waktu pada sore hari dan ikut serta, bahkan ada hadiah untuk bug yang dampaknya paling besar atau paling menarik
  • Saya ragu siapa sebenarnya yang terbantu dengan membuat 100 tiket bug dalam satu jam. Jika banyak duplikat, 10 bug yang berbeda saja sudah cukup menunjukkan bahwa fitur itu sangat buruk, dan setelah itu rasanya seperti terus memukuli reruntuhan
  • Cara memiliki test case QA yang presisi tetapi hanya memberi developer penjelasan yang samar cukup cerdas. Saya baru pertama kali melihat pendekatan seperti itu, dan fakta bahwa jumlah bug yang tersisa bisa diperkirakan juga mengesankan

• 15–20 tahun lalu saya bekerja di dua perusahaan yang berinvestasi pada tim QA kelas atas, dan tim-tim itu benar-benar sepadan nilainya. QA pandai menemukan bug yang tidak terpikirkan oleh developer karena mereka terlalu dekat dengan masalah, dan produknya pun menjadi kelas dunia
  Kuncinya, di kedua perusahaan itu manajemen puncak menetapkan bahwa tim QA memiliki wewenang akhir soal apakah rilis dilakukan atau tidak
  Perusahaan saat ini cenderung menganggap lebih baik developer memakai tes otomatis dan terlalu memedulikan code coverage, tetapi saya sudah terlalu sering melihat produk dengan 100% code coverage yang secara objektif tidak berfungsi. Bukan berarti tes otomatis itu buruk, melainkan masalahnya adalah menghilangkan tester QA manusia

  • Organisasi QA/QE yang hebat juga serupa. Rantai komando yang memutuskan apakah rilis production akan disertifikasi berbeda dari pengembangan, dan struktur insentifnya juga berbeda
    Tim QE di perusahaan tempat saya bekerja baru-baru ini menulis kode dalam jumlah sangat besar untuk menjalankan pengujian; jumlah baris kodenya bahkan lebih banyak daripada modul yang diuji dan disertifikasi
  • Code coverage tidak dapat menemukan bug yang muncul dari kode yang tidak ditulis, padahal seharusnya ditulis. Coverage hanyalah salah satu dari banyak metrik, dan memperlakukannya seolah-olah satu-satunya standar adalah hal bodoh
    Meski begitu, saya pernah mendengar seorang manajer pengujian di perusahaan software besar yang semua orang kenal menyatakan bahwa karena mereka sudah mencapai 100% coverage, maka tim testing sudah selesai
  • Instruksi bahwa QA punya hak keputusan akhir saja tidak cukup; harus ada budaya QA
    Bahkan dengan wewenang seperti itu, perusahaan yang QA-nya sebagian besar kontraktor bergaji rendah dan hanya melakukan apa yang diperintahkan tetap berantakan
  • Saya pernah melihat developer menulis tes tanpa assertion atau tes yang hanya berisi assertTrue(true). Selalu hijau dan coverage-nya 100%
    Orang-orang yang sama sering bertanya mengapa mereka harus menulis tes kalau mereka bisa membuat fitur baru, lalu seorang QA senior datang dan menghancurkan semuanya. Suatu kali ia menemukan bahwa jika F5 ditekan 50 kali selama 1 menit, backend akan terus menjalankan permintaan database lalu mati dengan outOfMemory
  • Saya sangat menyukai QA yang teliti. Sebagai developer, terlalu bergantung pada harapan bahwa mereka akan menangkap hal-hal yang saya lewatkan adalah antipola, tetapi ketika saya takut menjalankan kode saya sendiri selama 1 menit, mereka justru menikmatinya
    Mereka bangga menemukan kondisi batas yang jauh melampaui spesifikasi, dan nilainya memang besar. Seperti type system yang baik memberi rasa percaya diri saat melakukan perubahan, QA yang hebat juga memberi developer rasa percaya diri. Terutama untuk aplikasi dengan banyak interaksi seperti game, sulit mencakup seluruh ruang parameter hanya dengan unit test dan integration test

• Pernyataan bahwa karyawan yang paling berhati nurani dalam organisasi adalah yang paling getir adalah kebenaran yang menyakitkan. Mereka melihat masalah kualitas, sering memperbaikinya sendiri, tetapi tidak mendapat pengakuan, dan ketika menyuarakan kekhawatiran soal kualitas, mereka diperlakukan seperti orang yang ingin memperlambat laju
  Pihak “bergerak cepat dan pecahkan sesuatu” terus diberi imbalan, sementara orang-orang yang peduli harus membereskan kekacauan setelahnya dan makin menumpuk kemarahan. Bagi mereka, kepedulian itu sendiri terasa seperti kerugian besar bagi karier, karena memang demikian adanya
  DBA dan organisasi infrastruktur berada dalam posisi yang sama dengan QA, dan saya berharap bandulnya segera berayun kembali

  • Tinggal lompat saja dari kapal dan biarkan perusahaan itu bangkrut. Lebih baik membuatnya bangkrut lebih cepat; hal-hal baik menjadi mungkin ketika kita tidak memaksa menopang perusahaan yang buruk
  • Cara bandul kembali menurut saya adalah jika kamu membangunnya, kamu yang mengoperasikannya. Kalau tidak suka pager on-call berbunyi, jangan membuatnya berbunyi
  • Pada akhirnya tergantung pelanggan. Apakah mereka akan pergi karena bug dan outage, atau tetap bertahan karena fitur baru yang mengilap
  • QA dan testing itu penting, tetapi saya tidak yakin apakah orang-orang yang hanya melihat keuntungan bisa diyakinkan. Karena deployment lewat internet menjadi terlalu mudah, pendekatan “rilis cepat dan patch nanti” sepertinya akan terus bertahan
    Perhitungannya adalah: kalau pengguna bisa melaporkan bug dan menerima update lewat internet, untuk apa menghabiskan banyak uang dan waktu? Setelah game dan software bergeser dari media fisik ke distribusi berbasis download, patch tampaknya menjadi lebih murah. Tentu saja ini berujung pada masalah keamanan yang mengerikan dan pengalaman pengguna yang buruk, tetapi selama orang di atas memaksimalkan keuntungan, mereka tidak terlalu peduli
  • Engineer yang berhati nurani tidak selalu benar; konteks dan keseimbangan tetap diperlukan. Kadang mereka benar tetapi cara menyampaikannya rusak, dan kadang mereka hanya berada di tempat yang salah
    Jika sedang membuat produk POC SaaS, Anda tidak memerlukan kualitas setingkat mikrokontroler avionik. Setiap trade-off memiliki risiko dan biaya, dan engineer yang baik harus memahami perbedaannya

• Masalah inti tim QA sama seperti tim IT atau organisasi manajemen. Jika mereka bekerja dengan baik, mereka terlihat seperti tidak melakukan apa-apa
  Karena itu, sering muncul situasi di mana mereka harus “membenarkan” pekerjaan mereka sendiri, dan ini biasanya berasal dari ketergantungan berlebihan pada metrik. Seperti hukum Goodhart, mereka tidak memahami metrik itu sebenarnya proksi untuk apa, atau apa tujuan nyata dari pekerjaan tersebut
  Tim QA yang buruk terlalu banyak mencari-cari kesalahan agar terlihat punya sesuatu untuk dikatakan, sementara tim QA yang baik memverifikasi kualitas sekaligus melatih karyawan agar menghasilkan kualitas yang lebih tinggi
  Saya merasa ada kurangnya pelatihan secara luas di kalangan tenaga kerja. Tulisan “persentil ke-95 pun tidak sehebat itu” (https://news.ycombinator.com/item?id=38560345) yang belum lama ini masuk halaman depan juga mengatakan bahwa di bidang apa pun, mencapai 5% teratas itu mudah karena sebagian besar pelaku tidak berlatih secara aktif atau menerima umpan balik
  Saya pikir perusahaan semestinya terus berlatih seperti tim profesional, bukan tim olahraga amatir. Perekrutan juga seharusnya melihat “bisakah kita membuat orang ini menjadi top performer?” alih-alih “apakah orang ini sudah merupakan top performer?” Fakta bahwa seseorang berhasil di lingkungan sebelumnya ternyata tidak terlalu berarti jika lingkungan barunya sangat berbeda

  • Persentil ke-95 bisa jadi bukan hasil dari upaya luar biasa, melainkan hasil dari mengurangi kesalahan yang tidak perlu, tetapi meme budaya yang menganggapnya sebagai sesuatu yang sangat sulit sudah tersebar luas
    Di setiap tulisan tentang kualitas perangkat lunak, banyak komentar yang menganggap wajar ketidakpedulian luas para engineer. Tergantung situasinya, tetapi orang-orang tampaknya cukup baik-baik saja mengikuti optimum lokal organisasinya sendiri dan melepaskan inisiatif. Itu tidak sepenuhnya salah mereka, tetapi mereka juga tidak sepenuhnya tidak bersalah
  • Saya terus melihat pola “harus membenarkan pekerjaan” di tim DevOps. Biasanya orang operasi yang paling tinggi bayarannya atau paling senior menghabiskan banyak waktu memadamkan kebakaran yang tercipta karena ketidakmampuan atau kesalahannya sendiri, sehingga terlihat seperti sedang melakukan sesuatu
    Jika pekerjaan berulang dihilangkan lewat otomasi, posisi orang itu akan hilang; tetapi jika dilakukan dengan benar, manajer akan mengira ia duduk seharian tanpa melakukan apa-apa, jadi insentif untuk melakukannya dengan benar kecil
  • Saat bekerja dengan developer baru, tes dasar seperti double-click, spasi di depan, dan tombol back Android saja sering bisa membuat mereka tersandung. Setelah beberapa tiket ditolak, mereka mempelajari hal-hal ini dan setelah itu masalah yang sama jarang muncul
    Karena tidak dinilai berdasarkan jumlah bug yang ditemukan, tidak ada tekanan untuk memaksakan pencarian bug bodoh demi menaikkan angka
  • Saya mendengar kalimat “kalau dilatih begitu, mereka akan pergi ke tempat lain dengan bayaran lebih tinggi” di hampir semua perusahaan. Pelatihan yang bermakna selalu menjadi uphill battle
    Pelatihan yang baik membutuhkan orang-orang yang cukup luas dan baik di dalam fungsi teknis. Mereka tidak perlu tahu semua teknologi terbaru, tetapi harus bisa mendeteksi dan menunjukkan omong kosong. FAANG pun bukan pengecualian

• Seperti juga disebutkan dalam tulisan ini, inti sebenarnya adalah bahwa QA hampir selalu terlihat sebagai departemen biaya bagi unit bisnis dan manajemen atas
  Saya punya hipotesis bahwa lebih baik tidak bekerja di organisasi yang dipandang sebagai departemen biaya. Bonus, pengakuan, dan rasa hormat selalu mengalir ke pihak yang menghasilkan uang, sementara departemen biaya dibebani lebih banyak pekerjaan dengan lebih sedikit orang, disalahkan saat gagal, dan dipotong lebih dulu ketika perusahaan merampingkan diri. IT juga sama
  Karena lingkaran setan ini, karier QA pasti selalu lebih sulit dibanding menjadi developer dengan keterampilan serupa. Orang-orang hebat menjadi lelah dan keluar secepat mungkin, lalu struktur itu memperkuat dirinya sendiri

  • Bahkan sebagai developer aplikasi mobile, saya merasa harus berhati-hati agar tidak mengambil pekerjaan yang bersifat departemen biaya
    Aksesibilitas, observabilitas, logging yang baik, peningkatan infrastruktur testing, penyesuaian CI/CD, reliabilitas, linting yang lebih baik, dan isu analyzer semuanya penting, tetapi imbalannya datang saat merilis fitur dengan cepat
    Tahun ini saya menghabiskan terlalu banyak waktu untuk pekerjaan seperti itu karena merasa tim dan aplikasi membutuhkannya, dan saya khawatir dengan penilaian kinerja akhir tahun. Sekarang saya mengerti mengapa orang lain menghindari pekerjaan ini, dan tahun depan saya berencana lebih fokus pada rilis fitur yang lebih terlihat. Maaf untuk bug di aplikasi, tetapi saya butuh pekerjaan untuk membayar KPR
  • Saya setuju dengan rasa bahwa itu departemen biaya, tetapi dari pengalaman saya, nuansanya sedikit lebih kompleks
    Ada organisasi yang sungguh-sungguh menghargai nilai yang dibawa QA/QC. Saya lebih sering melihatnya di manufaktur daripada perangkat lunak; dugaan saya karena perangkat lunak pada dasarnya lebih abstrak dan pemborosan lebih sulit dilacak
    QA yang benar-benar baik bukan orang yang mencari jalan mudah, melainkan orang yang percaya pada misi QA. Pada akhirnya, nilai muncul ketika organisasi dan individu sungguh-sungguh menerima semangat QA, dan banyak tempat hanya melakukannya secara formalitas
  • Saya bekerja di tim platform front-end untuk peningkatan performa, desain CI, dan rekayasa proses, tetapi jauh lebih sulit mendapat pengakuan dan promosi dibanding orang-orang yang merilis fitur yang langsung berubah menjadi uang di rekening bank
    Meski begitu, saya tidak keberatan. Saya menikmati membuat sesuatu menjadi lebih baik dan kokoh, dan itu membuat hati tenang. Saya akan menyerahkan pekerjaan merusak kepada orang-orang sinis
  • Seumur hidup saya hampir selalu bekerja di departemen biaya, tetapi saya tidak ingin menukarnya dengan hal lain
    Tidak masalah jika bonus dan semacamnya pergi ke kelompok lain. Sebagai pekerja teknis saya dibayar cukup baik, dan banyak dari peran penghasil uang itu akan membuat saya benar-benar tidak bahagia meskipun saya sebenarnya bisa melakukannya dengan baik
  • Karena itu saya tidak bekerja di departemen IT bisnis tradisional

• Kualitas perangkat lunak, maintainability kode, dan desain yang baik hanya penting jika Anda berencana bekerja lama di perusahaan itu
  Jika Anda berniat pindah ke perusahaan berikutnya setelah beberapa tahun, jalur optimalnya adalah mengerjakan hal-hal yang sangat terlihat, naik dengan cepat, lalu memakai riwayat itu untuk mendapatkan pekerjaan dengan gaji lebih tinggi. Jika beberapa tahun kemudian proyek itu rusak atau tidak bisa dipelihara, Anda tidak peduli karena saat itu Anda sudah tidak ada di sana
  Startup juga berjalan dengan cara yang sama. Growth mindset yang terukir di mana-mana adalah pola ini. Meski produk menjadi tidak bisa dipelihara 5 tahun kemudian, pada saat itu mereka mungkin sudah exit dan mencairkan uang
  Saya tidak benar-benar menyalahkan orang-orang seperti itu. Itu praktik yang dipakai perusahaan sendiri, dan orang-orang hanya bermain sesuai aturan tersebut. Saya tidak menyukainya dan benar-benar membencinya, tetapi saya bisa memahaminya
  Bagian yang menarik adalah ketika para manajer dan eksekutif mengeluhkan turnover, kurangnya komitmen pada perusahaan, dan quiet quitting. Itu seperti merasakan sendiri racun yang mereka buat

  • Menganggap bahwa produk startup mungkin menjadi tidak bisa dipelihara 5 tahun kemudian bisa jadi sikap yang masuk akal. Sebab sebagian besar startup gagal dan tidak bertahan 5 tahun
    Jika 5 tahun kemudian mereka masih bertahan sambil memikul technical debt, bagi banyak startup itu justru masalah yang baik. Karena itu berarti mereka bertahan selama 5 tahun

• Engineer QA biasanya juga sangat jago debugging. Mereka menyentuh pipeline, source, direktori test, dan menangani hampir semua aspek pengembangan serta deployment aplikasi
  Saat saya menjadi QA lead, saya sering melihat software engineer yang setiap hari mengeluh di Slack tetapi tidak mau membaca pesan error pipeline. Saat optimasi pipeline pun mereka mengabaikan akar masalah, lalu berhari-hari menebak-nebak gejala yang muncul dari akar masalah itu seolah-olah itu masalah ajaib yang tak bisa dipahami
  Sikap meremehkan engineer QA yang disebut dalam tulisan ini bukan berlebihan. Bahkan perusahaan yang memiliki organisasi QA pun sering kali tidak menerapkan proses wawancara seketat organisasi engineering, sehingga engineer QA dinilai rendah
  SWE yang menghormati QA hanyalah mereka yang pernah bekerja di QA sendiri. Sikap meremehkan itu begitu merajalela hingga akhirnya saya kembali ke organisasi engineering, lalu mencoba mengubahnya dengan senioritas sebagai principal engineer atau lewat peran manajerial, tetapi gagal. Engineering tidak bisa melihat melampaui keangkuhannya sendiri, dan leadership juga tidak membantu
  CTO baru di perusahaan tempat saya bekerja sebelum di-PHK mengatakan kebutuhan akan QA bisa dihilangkan dengan otomatisasi, tetapi tidak punya satu pun contoh tentang apa maksudnya. Begitulah tingkat penghormatan dari atas terhadap pekerjaan membuat software yang baik

• Microsoft tampaknya menjadi contoh paling mencolok dari masalah ini. Setelah membubarkan tim QA, bug pada update Windows dan produk cloud meningkat secara terlihat

  • Pendapatan tetap masuk, jadi mungkin secara bisnis itu keputusan yang benar… membuat saya menghela napas
    Dalam pekerjaan saya banyak memakai software dan layanan Microsoft, dan saya berharap mereka membayar harga dalam bentuk apa pun atas penurunan kualitas itu

• Mungkin ini hanya pengalaman pribadi, tetapi saya belum pernah melihat tim QA yang benar-benar menulis test untuk engineering
  Tim QA yang pernah saya temui menulis rencana pengujian lalu menjalankannya secara manual, atau sesekali menjalankannya lewat test browser/perangkat yang terotomasi. Test seperti ini juga bernilai, tetapi menurut saya nilainya lebih rendah dibanding unit test atau integration test
  Dalam model ini, pada praktiknya tim engineering-lah yang menjadi tim QA, sementara tim QA terpisah kerap menciptakan noise dengan menemukan hal-hal yang bukan bug seolah-olah bug, dan biaya yang ditimbulkan lebih besar daripada nilai yang diberikan
  Saya ingin mempelajari model tim QA yang berjalan dengan baik. Pengujian manual itu bagus, tetapi dalam pengalaman saya ada batasnya. Saya tidak bermaksud merendahkan orang-orang QA, hanya berbagi pengalaman saya

  • Nilai QA yang saya lihat ada pada keakraban dengan produk. QA yang baik lebih tahu daripada siapa pun bagaimana produk benar-benar bekerja
    Mereka memahami keseluruhan sistem yang terlihat oleh pengguna secara lebih menyeluruh daripada PM, sales, atau sebagian besar tim developer, dan bisa mengatakan dengan tepat apa yang akan terjadi jika tombol tertentu ditekan. QA yang buruk memang sumber noise, tetapi developer, system administrator, serta support level 1/2 yang buruk juga sama saja
  • QA yang baik bagi developer software itu seperti editor yang baik bagi penulis. Mereka melihat hasil kerja yang dibuat susah payah dengan dingin dan mengkritiknya tanpa ampun
    Saat mengalaminya memang sangat menyebalkan, tetapi kualitas hasil akhirnya menjadi jauh lebih baik
    QA dulu biasanya tidak menulis test, melainkan menguji kode secara manual sambil mencoba segala perilaku aneh yang Anda harap tidak dilakukan pengguna. Mereka menemukan masalah dan bug yang umumnya sulit ditangkap dengan test
    Sekarang QA dilemparkan ke pengguna. Saat bekerja dengan developer muda, saya merasa konsep QA itu sendiri makin terasa asing. Ketika bug lolos ke production lalu saya bertanya “waktu kamu coba-coba di lokal, hasilnya bagaimana?”, sering kali saya mendapat tatapan aneh. Sikapnya seperti: type checker sudah lolos, jadi kenapa tidak dirilis?
    Efisiensi programmer masa kini diukur dengan jumlah PR per menit, jadi memasukkan bug bukan masalah, malah bagus. Kalau seseorang menemukannya di production, beberapa hari kemudian bisa membuat PR lagi untuk memperbaikinya. Kalau ada QA, alur seperti ini pasti rusak
  • Saya adalah QA yang menulis test untuk engineering, dan jabatan tepatnya SDET. Saya menangani bukan hanya rencana pengujian, tetapi juga test framework, infrastruktur, dan otomatisasi rencana pengujian tersebut
    Setiap perusahaan mengimplementasikan fungsi QA dengan cara berbeda. Ada yang menyerahkannya kepada pelanggan, ada yang kepada developer, customer support, QA manual, atau SDET. Pada akhirnya itu bergantung pada seberapa besar leadership mementingkan kualitas dan bagaimana mereka memandang QA
    Jika ada tim QA, menurut saya peluang suksesnya paling tinggi ketika mereka terlibat sejak awal proses. Tim QA yang baik seharusnya menemukan bug sebelum kode ditulis. Semakin terlambat mereka terlibat, semakin terlambat bug ditemukan, dan mereka makin terjepit di antara “code complete” dan rilis. Tim QA harus memiliki kemampuan otomatisasi agar bisa menghabiskan waktu untuk test case baru, bukan mengulang pengujian manual
    Tulisan ini cukup menyakitkan untuk dibaca. QA kadang diperlakukan sebagai warga kelas dua, dan dikeluarkan dari diskusi yang bisa memberi konteks untuk melakukan pekerjaan dengan benar. Ketika orang-orang bagus pergi ke development atau product management, kondisinya memburuk, dan spiral menurun itu benar-benar ada
  • Tidak ada cara formal untuk menjalankan organisasi QA, sehingga orang sering direkrut lalu diberi tahu “coba urus sendiri”. Akibatnya organisasi lain tidak memahami kebutuhan QA dan mengabaikannya
    Yang Anda gambarkan sekarang adalah masalah leadership, bukan masalah kegunaan QA
  • Dalam model klasik, sebagian besar organisasi QA berjalan seperti organ tambahan yang tak berguna. Secara struktural memang begitu, dan faktor besarnya adalah ketika development terlambat, QA yang terdorong ke belakang
    QA menghabiskan waktu membangun infrastruktur test dan rencana pengujian tanpa dilibatkan sejak awal, lalu di akhir menerima segumpal kode dan jadwal persetujuan 48 jam, sehingga harus sign-off di bawah tekanan ekstrem
    Namun sesekali ada juga organisasi QA yang memahami problem domain secara mendalam dan benar-benar memimpin development. Mereka bergerak berdampingan dengan development dari awal sampai akhir, dan bukan hanya meningkatkan kualitas, tetapi juga menghemat waktu semua orang

• Saat membuat FoundationDB, mereka berfokus pada kualitas dan pengujian hingga nyaris terobsesi. Karena itu, mereka bahkan membuat bahasa bernama Flow, sehingga dapat mensimulasikan klaster FDB dalam skala sembarang secara deterministik, memberinya kondisi ekstrem, lalu menandai pelanggaran properti sistem dan mereproduksi dengan sempurna eksekusi pengujian yang menyebabkan pelanggaran tersebut
  Setiap malam, puluhan ribu eksekusi pengujian berjalan hingga mencapai titik ketika, jika tidak ada kode baru, pada dasarnya semuanya menunjukkan lampu hijau. Pengujian yang menunjukkan lampu merah hampir selalu disebabkan oleh penambahan kode terbaru, sehingga mudah diidentifikasi dan diperbaiki
  Berkat itu, tim dapat mengembangkan dengan keyakinan bahwa bug yang baru dimasukkan akan cepat tertangkap, dan hal ini menghasilkan kecepatan yang membuat mereka percaya diri mengambil proyek berani seperti menulis ulang sistem pemrosesan transaksi setelah rilis. Hasilnya, mereka juga mendapatkan peningkatan kecepatan 10x
  Pada akhirnya, fokus pada kualitas berujung pada kecepatan, dan keduanya sama sekali tidak bertentangan. Saya tidak menganggap ini sebagai fenomena yang terisolasi, dan karena itulah hal ini berlanjut menjadi proyek baru, tetapi itu cerita untuk lain waktu

  • Apakah bahasa ini Flow yang dimaksud? https://github.com/apple/foundationdb/blob/main/flow/README....