Ada cerita tentang seorang anak muda yang awal mulanya tertarik pada dunia Quality Assurance (QA) bukan karena idealisme ingin menyelamatkan produk dari bug. Alasannya sangat sederhana dan pragmatis: kebutuhan untuk mencari kerja, bosan melihat pengujian manual yang itu-itu saja, dan adanya keinginan kuat untuk ikut mengoding karena menyukai dunia teknologi.
Dari sanalah ambisi itu dimulai. Dengan bermodalkan device seadanya seperti hp android yang di install termux, proses belajar dilakukan secara otodidak. Ada kepuasan tersendiri ketika berhasil menaklukkan hal-hal teknis yang awalnya terlihat rumit—mulai dari menguasai framework modern seperti Pytest Playwright atau Playwright dengan TypeScript, hingga sukses membangun pipeline CI/CD di GitHub Actions agar robot testing bisa berjalan otomatis dan mengirim notifikasi ke Telegram.
Pada titik itu, sempat muncul perasaan jemawa. Ada asumsi keliru di dalam kepala bahwa jika seseorang sudah mahir menulis skrip otomatisasi dari nol dan membuat status pengujian menjadi "hijau" di reporting tool, maka tugasnya sebagai QA sudah selesai dan otomatis naik kelas. Sebuah pemikiran khas pemula yang merasa sudah menaklukkan dunia hanya karena robotnya bisa berjalan sesuai perintah.
Namun, tamparan realitas itu datang ketika ia mencoba membangun automation framework untuk sebuah proyek nyata, yaitu sebuah Enterprise POS (Point of Sale) SaaS. Jujur saja, proyek SaaS tersebut sebenarnya tidaklah besar, melainkan proyek buatan seorang solo fullstack developer. Di sinilah benturan realitas itu terjadi, memicu kebingungan besar di tengah masa belajarnya.
Robot testing yang dibuat dengan kode-kode canggih mendadak terasa membingungkan, bukan karena kodenya eror, melainkan karena ia mulai dihadapkan pada kenyataan alur bisnis (business flow) dari aplikasi tersebut. Sangat mudah memerintahkan robot untuk mengklik tombol kasir. Namun, apa gunanya jika kita tidak paham mengapa alur stok opname harus memotong inventaris dengan metode tertentu? Apa gunanya skrip yang berjalan lancar jika kita melewatkan logika anomali pembukuan akuntansi di belakang sistem? Logika industri seperti ini tidak memiliki dokumentasi sintaks di internet dan tidak bisa ditebak hanya dengan melamun di depan monitor rumah.
Hal yang sama juga meruntuhkan keangkuhan saat melakukan pengujian API (API Testing). Awalnya, ada pemikiran bahwa jika respons API sudah mengembalikan Status Code 200 OK dan lolos validasi skema JSON, maka pengujian sudah selesai. Padahal, status 200 hanyalah konfirmasi bahwa gerbangnya terbuka, bukan jaminan bahwa datanya benar.
Ketika menguji metode PUT atau PATCH untuk pembaruan data bisnis, realitasnya jauh lebih rumit. Satu skenario pengujian yang solid bisa membutuhkan hingga lebih dari 4 request berantai: melakukan GET awal untuk mencatat data lama, mengeksekusi PUT, melakukan GET kembali untuk memastikan data benar-benar berubah di database, hingga memvalidasi dampaknya ke modul lain. Tanpa pemahaman alur bisnis yang matang, pengujian API hanya akan menjadi aktivitas ketik skrip yang dangkal dan rapuh.
Dari pengalaman berharga dan fase kebingungan inilah, anak muda itu akhirnya belajar sebuah pelajaran penting: pemahaman alur bisnis adalah hal yang sepenuhnya berbeda dari membangun skrip yang canggih sekalipun. Keinginan untuk lepas dari kejenuhan QA manual dan belajar ngoding automation adalah langkah yang bagus, namun menguasai tool automation tercanggih tanpa dibarengi kepekaan terhadap produk hanya akan melahirkan robot pengetik skrip yang kaku.
Pada akhir cerita, artikel ini adalah refleksi sekaligus pengingat nyata bagi diri saya sendiri. Kemampuan teknis bisa kita kejar secara mandiri di kamar. Namun, kedewasaan memahami bagaimana sebuah bisnis di dunia nyata bekerja hanya bisa matang ketika kita berani keluar, terjun langsung ke lapangan, dan membenturkan diri dengan ekosistem industri yang sesungguhnya.