Beberapa waktu lalu gw kepikiran sesuatu.
Sekarang ini, bikin test case udah nggak sesusah dulu.
Lo tinggal kasih requirement ke AI, minta bikinin test scenario, beberapa detik kemudian langsung keluar puluhan skenario. Mau sekalian dibikinin automation pake Playwright? Bisa. Mau generate API testing script? Bisa juga.
Bahkan sekarang AI udah mulai bisa bantu investigasi error, memperbaiki locator yang rusak, sampai menjalankan testing secara otomatis.
Keren banget kan?
Tapi justru dari situ gw jadi kepikiran.
Kalo semua orang bisa bikin test case dan automation dengan gampang, terus apa yang bikin seorang QA Engineer punya nilai lebih dibandingkan yang lain?
Gw udah lebih dari 10 tahun berkecimpung di dunia software engineering, khususnya Quality Assurance. Dari zaman automation masih harus ditulis manual, sampai sekarang kita bisa ngobrol sama AI buat menghasilkan kode.
Dan gw mulai melihat satu pola.
Setiap kali teknologi baru muncul, kita selalu sibuk membicarakan tools-nya.
Dulu Selenium. Terus Appium. Lalu Cypress, Playwright, dan sekarang AI testing agents.
Nggak ada yang salah dengan itu. Gw sendiri juga seneng nyobain tools baru.
Tapi ada satu hal yang menurut gw sering kelewat dari pembahasan kita.
Tools membantu kita melakukan testing. Tapi tools nggak otomatis bikin kita tahu apa yang seharusnya diuji.
Nah, dari sini gw mau ngajak kalian ngobrol soal apa yang menurut gw bakal jadi kemampuan penting buat QA Engineer di tahun 2027.
Tulisan ini juga terinspirasi dari artikelnya Ben Rogojan di SeattleDataGuy, What’s Going To Matter In 2027 For Data Engineers?
Ada satu gagasan menarik dari tulisannya: ketika teknologi bikin pekerjaan teknis semakin gampang dikerjakan, tantangannya justru bergeser ke bagaimana kita bisa memastikan hasil pekerjaan tersebut benar dan bisa dipercaya.
Dan menurut gw, fenomena yang sama juga lagi terjadi di dunia QA.
1. Software Makin Cepet Dibikin. Tapi Apakah Makin Berkualitas?
Coba bayangin.
Dulu developer butuh lima hari buat menyelesaikan satu fitur.
Sekarang, berkat AI, fitur yang sama bisa selesai dalam dua hari.
Wah, produktivitas naik dong?
Ya, bisa jadi.
Tapi sekarang coba lihat dari sisi QA.
Sebelumnya dalam seminggu lo cuma perlu ngetest satu fitur. Sekarang dalam waktu yang sama bisa ada tiga fitur yang harus diuji.
Belum lagi code changes yang makin banyak, integrasi yang makin kompleks, dan requirement yang kadang masih ambigu.
Nah, pertanyaannya:
Apakah kecepatan kita memastikan software berkualitas juga meningkat sebanding dengan kecepatan kita membuat software?
Gw nemu data menarik dari laporan State of AI in Quality Engineering 2026 yang diterbitkan TestMu AI.
Dalam survei mereka:
40% tim responden mengatakan lebih dari setengah production code mereka dihasilkan dengan bantuan AI.
81% pernah menggabungkan kode atau test buatan AI yang belum sepenuhnya mereka pahami.
44% melaporkan peningkatan escaped defects atau production incidents ketika penggunaan AI-generated code meningkat.
Tapi perlu diingat, angka ini berasal dari responden survei TestMu AI, bukan representasi otomatis seluruh industri. Dan angka 44% tadi juga bukan berarti AI terbukti menyebabkan peningkatan bug.
Meskipun begitu, gw melihat ada sesuatu yang menarik.
Kita sekarang punya kemampuan menghasilkan kode lebih cepat. Tapi kemampuan memastikan kode itu benar belum tentu ikut meningkat.
Bahkan bisa muncul masalah yang lebih unik.
Misalnya developer menggunakan AI untuk mengimplementasikan fitur, lalu QA menggunakan AI untuk membuat test case berdasarkan requirement yang sama.
Keduanya bisa saja menghasilkan sesuatu yang terlihat benar.
Padahal requirement awalnya punya asumsi yang keliru.
Jadinya kode dan test sama-sama konsisten, tapi sama-sama salah memahami kebutuhan bisnis.
Lucu juga ya.
Test-nya hijau semua, fiturnya jalan, tapi ternyata yang kita validasi adalah kesalahan yang sama. Hehehe.
Nah, gw rasa di tahun 2027, kemampuan QA bukan lagi sekadar menghasilkan lebih banyak test.
Tapi bagaimana kita bisa membangun confidence bahwa sistem memang bekerja sebagaimana mestinya.
Karena 100% test passed bukan berarti 100% software berkualitas.
2. Critical Thinking: Jangan Cuma Jago Bikin Test Case
Gw mau kasih contoh sederhana.
Misalnya kita lagi ngetest fitur voucher di aplikasi e-commerce.
Requirement-nya:
User mendapatkan diskon 20% untuk pembelian minimal Rp200.000.
Gampang kan?
Kita minta AI bikin test case, mungkin hasilnya seperti ini:
Belanja Rp199.999, nggak dapet diskon.
Belanja Rp200.000, dapet diskon 20%.
Belanja Rp300.000, dapet diskon 20%.
Voucher expired nggak bisa digunakan.
Voucher yang udah dipake nggak bisa digunakan lagi.
Secara teknis, semua skenario tadi masuk akal.
Tapi coba gw tanya.
Minimal transaksi Rp200.000 itu dihitung dari mana?
Dari harga barang sebelum diskon atau setelah diskon?
Ongkir termasuk nggak?
Kalo ada diskon dari merchant, voucher tadi masih bisa dipake?
Terus kalo user refund sebagian barang dan total transaksi akhirnya turun jadi Rp150.000, gimana?
Diskonnya dihitung sebelum pajak atau setelah pajak?
Loh, kok jadi banyak pertanyaan?
Nah, justru itu poinnya.
Testing bukan sekadar mencari kombinasi input untuk mendapatkan expected result.
Kadang kita justru perlu mempertanyakan expected result itu sendiri.
Masalahnya, kadang kita terlalu percaya bahwa requirement yang diberikan udah pasti benar dan lengkap.
Padahal belum tentu.
Gw beberapa kali melihat masalah yang akar penyebabnya bukan karena developer salah ngoding.
Implementasinya justru sesuai requirement.
Tapi ternyata requirement tersebut nggak mempertimbangkan satu kondisi bisnis tertentu.
Jadi sebenarnya siapa yang salah?
Menurut gw, bukan soal mencari siapa yang salah, tapi bagaimana kita bisa menemukan asumsi yang keliru sebelum berubah jadi masalah di production.
AI tentu bisa membantu kita brainstorming skenario.
Tapi kita tetap perlu punya kemampuan berpikir kritis buat mempertanyakan hasilnya.
Dan gw percaya, skill ini bakal semakin berharga.
Karena semakin gampang orang menghasilkan jawaban, semakin penting kemampuan kita mengajukan pertanyaan yang tepat.
3. Risk-Based Testing: Nggak Semua Bug Layak Diperjuangkan
Ada satu kebiasaan di dunia QA yang menurut gw menarik buat dipertanyakan.
Kenapa kita masih sering mengukur produktivitas QA dari jumlah bug yang ditemukan?
Misalnya ada dua QA.
QA pertama menemukan 20 bug dalam satu sprint.
QA kedua cuma menemukan 3 bug.
Siapa yang lebih produktif?
Kalo cuma lihat angka, jelas QA pertama.
Tapi gimana kalo 20 bug tadi cuma masalah UI kecil, sementara dari 3 bug yang ditemukan QA kedua, salah satunya bisa menyebabkan user kehilangan uang?
Masih yakin QA pertama lebih produktif?
Hehehe.
Gw kasih contoh dalam aplikasi finansial.
Bug pertama: foto profil user nggak muncul setelah diganti.
Bug kedua: ketika user melakukan withdrawal dan request mengalami timeout, sistem memproses retry sebagai transaksi baru sehingga ada risiko dana ditarik dua kali.
Dua-duanya bug.
Tapi tentu dampaknya beda jauh.
Inilah kenapa menurut gw Risk-Based Testing bakal makin penting.
Bukan berarti bug kecil boleh diabaikan begitu aja.
Tapi kita harus ngerti bahwa waktu, tenaga, dan sumber daya yang kita punya terbatas.
Apalagi ketika development makin cepat.
Lo nggak mungkin ngetest semua kemungkinan dengan kedalaman yang sama.
Jadi kita perlu bisa menilai risiko.
Seberapa besar kemungkinan masalah terjadi?
Kalo terjadi, dampaknya apa?
Berapa banyak user yang bisa terdampak?
Apakah ada cara mendeteksi atau memulihkan masalah tersebut dengan cepat?
Bahkan kadang risiko kecil yang sering terjadi bisa lebih merugikan dibandingkan risiko besar yang sangat jarang terjadi.
Nah sekarang coba bayangin.
Tim lo mau release dua jam lagi.
Regression testing belum semuanya selesai.
Product Manager nanya, “Kita aman buat release nggak?”
Menurut gw, jawaban QA yang baik bukan sekadar:
“Belum, karena masih ada 50 test case yang belum dijalankan.”
Tapi lebih ke:
“Bagian pembayaran dan withdrawal udah kita validasi, termasuk beberapa skenario failure. Masih ada risiko di fitur X yang belum diuji, tapi dampaknya terbatas pada kondisi Y. Kita bisa mempertimbangkan staged rollout sambil monitoring metrik tertentu.”
Lihat bedanya?
Yang satu melaporkan aktivitas testing.
Yang satu membantu tim memahami risiko.
QA bukan cuma soal menemukan bug. Tapi juga membantu tim memahami bug mana yang paling beresiko (berbahaya).
4. Paham Bisnis Itu Sama Pentingnya dengan Paham Coding
Kalo gw tanya, skill apa yang perlu dipelajari seorang QA Engineer?
Biasanya jawabannya:
Python, Java, Selenium, Playwright, Appium, API Testing, SQL, dan seterusnya.
Setuju. Semuanya penting.
Tapi gw jarang dengar orang menjawab:
“Belajar memahami bagaimana bisnis tempat kita bekerja menghasilkan uang dan melayani penggunanya.”
Padahal menurut gw ini penting banget.
Coba bayangin lo kerja di aplikasi marketplace.
Ada fitur refund.
Dari sisi teknis, lo mungkin ngetest:
User request refund, API return
200 OK, database status berubah jadirefunded, notifikasi terkirim.
Selesai?
Belum tentu.
Gw mau tanya.
Kalo user bayar sebagian pake wallet dan sebagian pake kartu debit, refund-nya masuk ke mana?
Kalo merchant udah menerima settlement, siapa yang menanggung pengembalian uang?
Kalo yang di-refund cuma satu dari tiga barang, berapa nilai yang perlu dikembalikan?
Bagaimana pencatatannya di ledger?
Kalo payment gateway bilang refund berhasil tapi uang belum sampai ke user, apakah sistem kita tetap boleh menampilkan status sukses?
Nah loh.
Ternyata satu fitur refund yang kelihatannya sederhana bisa melibatkan banyak proses bisnis.
Dan sering kali bug paling berbahaya justru muncul dari interaksi antarproses tersebut.
Ini juga alasan kenapa menurut gw seorang QA sebaiknya nggak cuma ngerti cara sebuah fitur bekerja.
Tapi juga memahami kenapa fitur itu harus bekerja dengan cara tertentu.
AI bisa membantu kita membaca dokumentasi, menjelaskan arsitektur, atau menyusun gambaran business flow.
Tapi kalo ada aturan bisnis yang bahkan nggak pernah ditulis di dokumentasi, AI juga belum tentu mengetahuinya.
Kadang jawabannya justru ada di kepala orang finance, operations, risk, atau customer support.
Jadi jangan cuma ngobrol sama developer dan Product Manager.
Coba sesekali ngobrol sama orang yang setiap hari menangani konsekuensi ketika aplikasi kita bermasalah.
Bisa jadi perspektif mereka bakal mengubah cara kita melakukan testing.
5. AI Nggak Cuma Membantu QA. QA Juga Bakal Ngetest AI
Selama ini pembahasan AI di dunia QA biasanya berkisar pada:
Gimana bikin test case pake AI?
Gimana bikin automation script pake AI?
Gimana menghasilkan bug report dengan lebih cepat?
Semuanya menarik.
Tapi ada satu pertanyaan yang menurut gw jauh lebih menarik.
Gimana kalo software yang harus kita test justru menggunakan AI?
Misalnya perusahaan lo bikin AI customer service.
User bertanya soal status refund.
AI menjawab berdasarkan informasi akun dan riwayat transaksi.
Sekarang gimana cara lo ngetest-nya?
Kalo API konvensional, kita mungkin bisa membandingkan actual result dengan expected result yang udah ditentukan.
Tapi AI nggak selalu memberikan kalimat yang sama setiap kali ditanya.
Dua jawaban bisa berbeda susunan katanya, tapi keduanya benar.
Sebaliknya, ada juga jawaban yang kedengarannya meyakinkan, padahal isinya salah.
Terus gimana menentukan test-nya pass atau fail?
Nah, di sinilah tantangan baru muncul.
Kita perlu mulai berpikir tentang AI evaluation.
Misalnya, kita punya AI financial assistant.
Coba bayangin user bertanya:
“Saldo investasi gw berapa?”
AI menjawab dengan benar.
Oke, bagus.
Tapi sekarang user bilang:
“Tolong tarik semua uang gw dan transfer ke rekening baru.”
Apakah AI boleh langsung menjalankan instruksi tersebut?
Harusnya nggak, tanpa otorisasi dan persetujuan yang sesuai.
Terus gimana kalo user mencoba memanipulasi AI supaya membocorkan informasi akun orang lain?
Atau bagaimana kalo perubahan prompt membuat jawaban AI yang sebelumnya benar menjadi salah?
Kita perlu mulai memikirkan evaluation datasets, adversarial testing, regression evaluation, sampai monitoring perilaku AI di production.
Menariknya, dalam laporan TestMu AI 2026 tadi, 37% responden yang mengembangkan AI agent mengaku belum punya metode evaluasi sistematis untuk agent mereka.
Artinya, masih ada tantangan besar dalam memastikan kualitas produk berbasis AI.
Apakah berarti semua QA harus belajar jadi Machine Learning Engineer?
Menurut gw nggak.
Tapi setidaknya kita perlu memahami bahwa menguji software yang hasilnya nggak selalu deterministik membutuhkan pendekatan yang berbeda.
Dan menurut gw ini bakal jadi salah satu area menarik untuk dipelajari menjelang 2027.
6. Software Udah Release Bukan Berarti Tugas QA Selesai
Dulu gw punya pemahaman bahwa tugas QA kurang lebih selesai ketika regression testing berhasil, nggak ada blocker, dan aplikasi siap release.
Tapi semakin lama bekerja di dunia software, semakin gw sadar bahwa pendekatan itu terlalu sempit.
Kenapa?
Karena production punya kebiasaan unik.
Kadang masalah yang nggak pernah muncul di testing environment justru muncul ketika software dipake user beneran.
Dan nggak selalu karena QA kurang testing.
Bisa karena jumlah transaksi, perilaku user, kondisi jaringan, service dependency, atau masalah dari pihak ketiga.
Misalnya fitur pembayaran.
Di staging, semuanya lancar.
API sukses, status transaksi benar, notifikasi terkirim.
Tapi di production, payment gateway tiba-tiba mengalami gangguan.
Beberapa request timeout.
Sebagian transaksi tertahan.
Sebagian user mencoba melakukan pembayaran berulang kali.
Dan sekarang kita punya masalah yang nggak pernah terlihat selama functional testing.
Nah, apakah ini berarti QA gagal?
Belum tentu.
Tapi menurut gw, ini menunjukkan bahwa kualitas software nggak bisa cuma diukur berdasarkan apa yang terjadi sebelum release.
Kita juga perlu memahami apa yang terjadi setelah release.
Makanya gw melihat observability sebagai salah satu kemampuan penting buat QA Engineer.
Belajar membaca logs, metrics, dan traces.
Memahami error rate, latency, crash rate, sampai business metrics seperti payment success rate.
Bukan berarti QA harus berubah jadi SRE atau DevOps Engineer.
Tapi QA perlu punya kemampuan melihat sinyal ketika kualitas produk mulai menurun.
Misalnya setelah release versi baru, ternyata payment success rate turun.
Padahal semua automated tests hijau.
Nah, data production ini bisa menjadi petunjuk bahwa ada sesuatu yang perlu diinvestigasi.
Menurut gw, hal tersebut jauh lebih bermakna dibandingkan cuma merayakan regression test yang berhasil 100%.
Karena kualitas software nggak berhenti ketika aplikasi berhasil dirilis. Kualitas harus terus diamati ketika aplikasi digunakan.
7. Dari Quality Assurance ke Quality Engineering
Ada satu pola kerja yang mungkin masih familiar buat banyak QA.
Developer selesai bikin fitur.
Lalu dilempar ke QA.
QA testing.
Kalo ada bug, balikin ke developer.
Kalo udah aman, baru release.
Alur seperti ini sebenarnya nggak selalu salah.
Tapi ketika development semakin cepat, QA bisa berubah jadi bottleneck.
Apalagi kalo jumlah QA jauh lebih sedikit dibandingkan jumlah developer.
Coba bayangin ada 10 developer yang aktif mengerjakan fitur, tapi cuma ada satu atau dua QA.
Semua perubahan harus melewati QA sebelum release.
Lama-lama QA bukan lagi orang yang membantu mempercepat feedback.
Malah jadi antrean panjang.
Nah, menurut gw salah satu perubahan penting ke depan adalah bagaimana kita mulai berpikir sebagai Quality Engineer.
Bukan berarti harus ganti job title ya. Hehehe.
Tapi memperluas cara kita melihat tanggung jawab atas kualitas.
Kenapa kita harus selalu menunggu fitur selesai baru mulai testing?
Kenapa nggak ikut membahas risiko dari awal?
Kenapa nggak membantu developer membuat automated checks yang bisa mereka jalankan sendiri?
Kenapa nggak menyiapkan API contract testing supaya masalah integrasi bisa terdeteksi lebih awal?
Kenapa nggak membuat test data dan testing environment yang lebih bisa diandalkan?
Atau kenapa nggak memikirkan bagaimana fitur dibuat lebih mudah diuji sejak tahap desain?
Intinya, jangan sampai kontribusi QA cuma muncul di akhir proses development.
Gw percaya kualitas software adalah tanggung jawab bersama.
Developer, QA, Product Manager, bahkan tim operations punya perannya masing-masing.
Dan semakin kita bisa membangun sistem kerja yang mendorong semua orang peduli kualitas, semakin kecil ketergantungan kita pada satu orang yang harus mengetes semuanya.
QA yang baik bukan cuma menemukan masalah. Tapi juga membantu tim membangun cara kerja supaya masalah lebih cepat ditemukan, bahkan sebelum sampai ke QA.
8. Berhenti Bangga Sama Jumlah Test Case
Gw mau kasih sebuah pertanyaan.
Misalnya ada dua tim QA.
Tim A punya 10.000 automated test cases.
Tim B cuma punya 2.000 automated test cases.
Menurut kalian, tim mana yang kualitas produknya lebih bagus?
Kalo jawaban kalian Tim A karena test case-nya lebih banyak, coba pikir lagi.
Gimana kalo dari 10.000 test tadi, sebagian besar cuma memvalidasi skenario yang risikonya rendah?
Sementara Tim B punya 2.000 test yang fokus pada critical business flows dan failure scenarios?
Belum tentu Tim A lebih baik, kan?
Ini salah satu alasan kenapa gw kurang setuju kalo kualitas QA cuma diukur dari jumlah test case, jumlah bug, atau automation coverage.
Bukan berarti angka-angka itu nggak berguna.
Tetap berguna, selama kita ngerti konteksnya.
Misalnya automation coverage tinggi bisa membantu kita tahu seberapa luas pengujian otomatis yang dimiliki.
Tapi angka itu sendirian nggak bisa menjawab apakah risiko paling berbahaya udah tertangani.
Menurut gw, di tahun 2027 kita perlu lebih sering ngobrol tentang metrik yang berkaitan dengan dampak.
Contohnya:
Risk Coverage
Apakah area dengan risiko bisnis paling tinggi udah punya pengujian yang memadai?
Escaped Defects
Masalah seperti apa yang masih lolos ke production, dan kenapa nggak terdeteksi sebelumnya?
Feedback Time
Seberapa cepat tim mengetahui bahwa sebuah perubahan membawa masalah?
Reliability Signals
Apakah aplikasi tetap andal setelah release? Bagaimana error rate, transaction success rate, atau crash rate-nya?
Release Confidence
Bukti apa yang kita punya untuk mendukung keputusan bahwa sebuah fitur cukup siap dirilis?
Nggak ada satu angka ajaib yang bisa menggambarkan kualitas software secara utuh.
Tapi kombinasi metrik yang tepat bisa membantu kita membuat keputusan yang lebih baik.
Karena menurut gw, tujuan akhir QA bukan menghasilkan dashboard yang penuh angka hijau.
Tujuannya adalah membantu tim memahami kondisi kualitas produk yang sebenarnya.
9. Communication Skill: Ketika QA Harus Berani Menyampaikan Risiko
Kita sering menganggap komunikasi sebagai soft skill.
Biasanya diwujudkan lewat kemampuan menulis bug report yang jelas.
Steps to reproduce, actual result, expected result, screenshot, dan logs.
Itu penting.
Tapi menurut gw kemampuan komunikasi seorang QA jauh lebih luas daripada sekadar menulis bug report.
Coba bayangin situasi ini.
Besok ada jadwal release.
Malam ini QA menemukan bug yang cukup serius.
Developer bilang butuh beberapa hari untuk memperbaikinya.
Product Manager bilang release nggak bisa ditunda karena sudah ada komitmen bisnis.
Stakeholder kemudian bertanya:
“Jadi menurut QA, kita release atau nggak?”
Wah, menarik nih. Hehehe.
Dalam situasi seperti ini, skill teknis aja nggak cukup.
Kita perlu bisa menjelaskan risiko dengan bahasa yang dipahami semua pihak.
Misalnya:
Bug ini berdampak ke siapa?
Apakah semua user bisa terdampak atau hanya kondisi tertentu?
Apa konsekuensi bisnisnya?
Ada workaround nggak?
Bisa nggak fiturnya di-disable menggunakan feature flag?
Apakah memungkinkan staged rollout?
Kalo terjadi masalah setelah release, apakah kita bisa rollback?
Dan yang paling penting, apa saja yang masih belum kita ketahui?
Menurut gw, QA nggak harus menjadi orang yang punya keputusan final untuk release.
Keputusan itu seharusnya mempertimbangkan banyak perspektif, termasuk bisnis, engineering, operations, dan risiko yang bisa diterima.
Tapi QA punya peran penting untuk memastikan semua pihak memahami konsekuensi dari keputusan tersebut.
Bukan sekadar bilang:
“QA nggak approve.”
Atau sebaliknya:
“Semua test case passed, silakan release.”
Tapi menjelaskan alasan di balik rekomendasi tersebut.
Karena ketika terjadi masalah, yang dibutuhkan tim bukan cuma catatan bahwa QA pernah menemukan bug.
Tapi pemahaman tentang risiko, mitigasi, dan keputusan yang dibuat berdasarkan informasi yang tersedia.
Menurut gw QA yang dewasa secara profesional bukan yang paling sering mengatakan ‘jangan release’, tapi yang mampu menjelaskan kapan release layak dilakukan, kapan sebaiknya ditunda, dan kenapa.
10. Jadi, Apa yang Harus Kita Pelajari Buat Menghadapi 2027?
Nah, setelah ngobrol panjang lebar, mungkin sekarang muncul pertanyaan.
“Oke, terus gw harus belajar apa?”
Apakah harus belajar tools AI terbaru?
Harus pindah dari Selenium ke Playwright?
Harus belajar programming lebih dalam?
Atau harus langsung belajar AI agents?
Jawaban gw: tergantung.
Tergantung pengalaman lo, produk yang lo kerjakan, dan masalah yang sedang dihadapi tim lo.
Tapi kalo gw harus memilih, ada lima hal yang menurut gw layak jadi fokus pengembangan QA Engineer.
Pertama, perkuat fundamental software testing.
Belajar lagi soal test design, boundary value analysis, equivalence partitioning, exploratory testing, dan risk-based testing.
Bukan cuma menghafal definisi ISTQB.
Tapi benar-benar memahami kapan teknik tersebut berguna dan kenapa kita menggunakannya.
AI bisa membantu menerapkan teknik testing.
Tapi kalo kita sendiri nggak paham fundamental-nya, gimana caranya kita tahu output AI itu benar?
Kedua, tingkatkan kemampuan teknis.
Belajar API testing, SQL, programming, arsitektur aplikasi, CI/CD, dan observability.
Nggak harus menguasai semuanya sekaligus.
Tapi semakin paham cara software bekerja, semakin mudah kita menginvestigasi masalah.
Gw percaya QA yang mampu memahami apa yang terjadi di balik UI punya keuntungan besar dibandingkan yang cuma mengandalkan tampilan aplikasi.
Ketiga, pahami domain bisnis.
Kalo lo kerja di fintech, pelajari bagaimana uang berpindah, bagaimana transaksi diproses, dan apa konsekuensinya ketika sistem gagal.
Kalo lo kerja di e-commerce, pelajari pembayaran, inventory, fulfillment, refund, dan settlement.
Kalo lo kerja di ride-hailing, pelajari matching driver, perhitungan tarif, pembatalan, dan pembayaran.
Jangan sampai kita tahu cara ngetest tombol, tapi nggak ngerti tujuan bisnis dari tombol tersebut.
Keempat, belajar menggunakan AI secara kritis.
Silakan pakai AI untuk membantu menulis automation, membuat test data, memahami kode, atau brainstorming skenario.
Gw sendiri melihat banyak manfaatnya.
Tapi jangan berhenti di kemampuan membuat prompt.
Belajar juga mengevaluasi hasil AI.
Pahami keterbatasannya.
Biasakan mempertanyakan asumsi yang digunakan.
Dan kalo produk lo mulai menggunakan AI, pelajari bagaimana cara mengevaluasi perilakunya.
Kelima, latih kemampuan komunikasi dan pengambilan keputusan.
Belajar menyampaikan risiko dengan jelas.
Belajar berargumentasi berdasarkan bukti.
Belajar memahami trade-off antara kualitas, waktu, dan kebutuhan bisnis.
Karena pada akhirnya, hasil testing akan digunakan manusia untuk mengambil keputusan.
Dan kemampuan membuat informasi teknis menjadi sesuatu yang mudah dipahami adalah skill yang nggak kalah penting.
Closing Thoughts: Kita Nggak Cuma Dibayar Buat Ngetest Software
Gw nggak tahu persis seperti apa dunia QA di akhir tahun 2027.
Mungkin AI testing agents bakal jauh lebih canggih.
Mungkin semakin banyak aktivitas testing yang bisa berjalan otomatis.
Mungkin tools yang kita gunakan sekarang sudah mulai ditinggalkan dan diganti sesuatu yang baru.
Bisa jadi.
Tapi ada satu hal yang gw percaya.
Semakin gampang melakukan testing, bukan berarti semakin gampang memastikan software berkualitas.
Karena software quality bukan cuma soal berapa banyak test case yang berhasil dijalankan.
Bukan sekadar automation coverage.
Bukan juga jumlah bug yang ditemukan.
Tapi tentang apakah produk kita benar-benar bekerja sesuai kebutuhan, bisa diandalkan, dan nggak membawa risiko yang nggak bisa diterima oleh penggunanya.
Dan untuk memahami semua itu, kita butuh lebih dari sekadar tools.
Kita butuh kemampuan berpikir kritis, memahami risiko, mengenal bisnis, menguasai aspek teknis, dan berkomunikasi dengan baik.
Jadi mungkin, menjelang tahun 2027, pertanyaan yang perlu kita tanyakan ke diri sendiri bukan lagi:
“Berapa banyak test case yang gw bikin hari ini?”
Tapi:
“Keputusan apa yang menjadi lebih baik karena pekerjaan gw sebagai QA Engineer?”
Karena kalo jawaban kita cuma jumlah test case atau bug report yang berhasil dibuat, mungkin kita perlu melihat kembali apa sebenarnya nilai yang kita berikan.
Gw pernah menulis tentang konsep Via Negativa dalam Quality Assurance, bahwa kita nggak bisa membuktikan sebuah aplikasi benar-benar bebas bug hanya karena testing kita berhasil.
Dan menurut gw, pemikiran itu masih relevan sampai sekarang.
Semakin banyak test yang kita jalankan belum tentu membuat kita semakin yakin terhadap kualitas produk, kalo ternyata kita belum memahami risiko yang sesungguhnya.
Pada akhirnya, kita bukan sekadar orang yang mencari kesalahan dalam software. Kita adalah orang yang membantu tim memahami apa yang bisa salah, seberapa besar dampaknya, dan bagaimana membuat keputusan yang lebih baik.
Dan menurut gw, nilai itulah yang akan tetap penting di tahun 2027, bahkan ketika AI sudah bisa melakukan semakin banyak pekerjaan teknis kita.
Gimana menurut kalian?
Apakah AI bakal mengubah peran QA secara fundamental, atau justru membuat kemampuan berpikir seorang tester semakin berharga?
Tulisan ini adalah opini dan proyeksi pribadi gw tentang perkembangan Quality Assurance menuju 2027, bukan prediksi pasti mengenai masa depan industri.
Referensi
Ben Rogojan, SeattleDataGuy — What’s Going To Matter In 2027 For Data Engineers?, 4 November 2026.
TestMu AI — State of AI in Quality Engineering 2026, 2 November 2026.
Fachrul Ch — Quality Assurance Via Negativa, 16 September 2024.