Berapa Kali Anda Harus Menguji Fitur yang Sama Setiap Kali Deploy? Mengenal Playwright untuk QA Automation

Mengubah pengujian berulang menjadi proses otomatis yang terukur dengan Playwright CodeGen, Locator, dan Assertion.

Bayangkan Anda sedang mengembangkan aplikasi ERP. Setiap kali ada perubahan kode, Anda harus kembali melakukan hal yang sama: membuka halaman login, memasukkan akun, mengakses dashboard, membuka transaksi, mengisi formulir, menghitung total pesanan, hingga memastikan data berhasil disimpan.

Awalnya mungkin tidak terasa berat. Namun, ketika aplikasi semakin besar, jumlah fitur bertambah, dan perubahan kode semakin sering dilakukan, aktivitas tersebut menjadi pekerjaan yang menghabiskan banyak waktu.

Masalahnya bukan sekadar banyaknya klik. Ada risiko yang lebih besar: perubahan pada satu fitur bisa merusak fitur lain yang sebelumnya sudah berjalan dengan baik.

Tombol yang sebelumnya berfungsi tiba-tiba tidak merespons. Perhitungan diskon berubah. Formulir tidak lagi menyimpan data. Bahkan, fitur yang sudah dinyatakan selesai pada minggu sebelumnya ternyata mengalami regresi setelah pembaruan aplikasi.

Di sinilah QA Automation menjadi penting.

Salah satu teknologi yang dapat membantu mengatasi masalah tersebut adalah Playwright, sebuah framework otomatisasi browser yang memungkinkan developer menguji aplikasi web melalui skenario yang dapat dijalankan berulang kali.

Menariknya, Playwright memiliki fitur CodeGen yang dapat merekam interaksi pengguna dan menerjemahkannya menjadi kode pengujian. Dikombinasikan dengan Locator dan Assertion, developer dapat membangun sistem pengujian yang lebih konsisten tanpa harus menulis seluruh skenario dari awal.

1. Mengapa Pengujian Manual Mulai Menjadi Hambatan?

Pengujian manual tetap memiliki peran penting dalam pengembangan perangkat lunak. Manusia masih dibutuhkan untuk mengevaluasi pengalaman pengguna, melakukan exploratory testing, memeriksa estetika antarmuka, dan menemukan masalah yang belum diketahui sebelumnya.

Namun, ada jenis pengujian yang sebenarnya tidak perlu dilakukan berulang kali secara manual.

Contohnya:

• Memastikan login tetap berfungsi.
• Memastikan formulir dapat menyimpan data.
• Memastikan perhitungan transaksi tidak berubah.
• Memastikan pengguna dengan hak akses tertentu tidak dapat membuka halaman terlarang.
• Memastikan jumlah soal ujian sesuai konfigurasi.
• Memastikan proses checkout menghasilkan total pembayaran yang benar.

Aktivitas seperti ini memiliki karakteristik yang cocok untuk diotomatisasi: langkahnya terstruktur dan hasil yang diharapkan dapat didefinisikan.

Ketika aplikasi memiliki puluhan atau ratusan skenario pengujian, pengujian manual berulang akan semakin membebani tim.

Selain membutuhkan waktu, konsistensi manusia juga memiliki keterbatasan. Ada kemungkinan langkah terlewat, data tidak diperiksa secara teliti, atau hasil pengujian hanya dinyatakan berhasil berdasarkan pengamatan sekilas.

QA Automation membantu menjalankan skenario tersebut secara konsisten dan memberikan hasil yang dapat diperiksa.

2. Mengenal Playwright: Otomatisasi Browser untuk Developer Modern

Playwright adalah framework untuk mengotomatisasi browser dan menguji aplikasi web.

Teknologi ini dikembangkan oleh Microsoft dan mendukung browser Chromium, Firefox, serta WebKit.

Playwright menyediakan dukungan untuk beberapa bahasa pemrograman, termasuk:

• JavaScript dan TypeScript.
• Python.
• Java.
• .NET.

Dalam pengembangan aplikasi berbasis TypeScript, Playwright Test menjadi pilihan yang praktis karena menyediakan test runner, assertion, fixture, serta berbagai fasilitas untuk menjalankan pengujian.

Dengan Playwright, developer dapat mensimulasikan aktivitas pengguna secara otomatis.

Misalnya:

1. Membuka halaman aplikasi.
2. Mengisi formulir login.
3. Menekan tombol masuk.
4. Menunggu dashboard ditampilkan.
5. Memastikan nama pengguna muncul.
6. Memastikan pengguna berhasil masuk.

Seluruh proses tersebut dapat ditulis dalam sebuah skenario pengujian dan dijalankan kembali kapan saja.

Hal ini membuat pengujian tidak lagi bergantung sepenuhnya pada aktivitas manual.

3. CodeGen: Mengubah Aktivitas Browser Menjadi Kode

Salah satu hambatan ketika mulai mempelajari QA Automation adalah menulis skrip pengujian dari awal.

Developer harus memahami struktur halaman, mencari elemen HTML, menentukan selector, menulis interaksi, dan membuat validasi hasil.

Playwright menyediakan fitur CodeGen untuk mempercepat proses tersebut.

CodeGen bekerja dengan merekam interaksi pengguna melalui browser dan menghasilkan kode Playwright berdasarkan aktivitas yang dilakukan.

Untuk memulainya, instal Playwright:

npm init playwright@latest

Kemudian jalankan:

npx playwright codegen http://localhost:3000

Sesuaikan alamat tersebut dengan alamat aplikasi yang sedang dikembangkan.

Setelah browser terbuka, developer dapat melakukan aktivitas seperti pengguna biasa.

Contohnya:

• Mengklik tombol login.
• Mengisi username.
• Mengisi password.
• Menekan tombol masuk.
• Membuka halaman transaksi.

CodeGen akan menghasilkan kode berdasarkan interaksi tersebut.

Keunggulan pendekatan ini adalah developer tidak harus selalu mengingat atau menulis seluruh sintaks Playwright secara manual.

Namun, ada hal yang perlu dipahami: kode hasil CodeGen merupakan titik awal pengujian, bukan otomatis menjadi test suite yang siap digunakan di lingkungan produksi.

Kode tersebut tetap perlu diperiksa, dirapikan, dan dilengkapi dengan assertion serta pengelolaan data pengujian.

CodeGen membantu mempercepat penulisan, sedangkan kualitas pengujian tetap bergantung pada kemampuan engineer dalam memahami skenario bisnis.

4. Locator: Menemukan Elemen Tanpa Bergantung pada Struktur HTML yang Rapuh

Salah satu masalah dalam otomatisasi UI adalah penggunaan selector yang terlalu bergantung pada struktur HTML.

Misalnya:

await page.locator(
  'div.container > div:nth-child(2) > button'
).click();

Kode tersebut mencari tombol berdasarkan posisi dan struktur elemen.

Jika developer mengubah susunan HTML atau menambahkan elemen baru, selector tersebut berpotensi tidak lagi menemukan tombol yang dimaksud.

Playwright menawarkan pendekatan Locator yang lebih ekspresif.

Contohnya:

await page.getByRole('button', {
  name: 'Simpan'
}).click();

Kode tersebut mencari tombol berdasarkan peran elemen dan nama yang dapat diakses pengguna.

Playwright juga menyediakan beberapa metode pencarian:

getByRole()

Mencari elemen berdasarkan peran aksesibilitas.

page.getByRole('button', {
  name: 'Login'
});

getByText()

Mencari elemen berdasarkan teks.

page.getByText('Transaksi Berhasil');

getByLabel()

Mencari elemen formulir berdasarkan label.

page.getByLabel('Email');

getByPlaceholder()

Mencari elemen berdasarkan placeholder.

page.getByPlaceholder('Masukkan email');

getByTestId()

Mencari elemen berdasarkan atribut khusus untuk pengujian.

page.getByTestId('submit-order');

Pendekatan ini membuat kode pengujian lebih mudah dibaca dan dipelihara.

Namun, Locator bukan jaminan bahwa pengujian tidak akan rusak. Jika teks tombol berubah, label dihapus, atau struktur aksesibilitas mengalami perubahan, pengujian tetap perlu diperbarui.

Prinsip yang disarankan adalah menggunakan identitas elemen yang bermakna dan stabil, bukan bergantung pada posisi elemen dalam DOM.

5. Assertion: Memastikan Aplikasi Benar-Benar Bekerja

Menemukan elemen dan mengklik tombol saja belum cukup untuk membuktikan aplikasi berjalan dengan benar.

Misalnya, Playwright berhasil menekan tombol Simpan. Apakah itu berarti data sudah berhasil disimpan?

Belum tentu.

Bisa saja permintaan gagal, validasi backend menolak data, atau aplikasi menampilkan pesan kesalahan.

Karena itu, pengujian membutuhkan Assertion.

Assertion adalah mekanisme untuk membandingkan hasil aktual dengan hasil yang diharapkan.

Contoh:

import { test, expect } from '@playwright/test';

test('memastikan pesan transaksi berhasil', async ({ page }) => {
  await page.goto('http://localhost:3000/orders');

  await page.getByRole('button', {
    name: 'Simpan'
  }).click();

  await expect(
    page.getByText('Transaksi Berhasil')
  ).toBeVisible();
});

Dalam contoh tersebut, pengujian tidak hanya melakukan klik, tetapi juga memastikan pesan keberhasilan benar-benar muncul.

Beberapa assertion yang sering digunakan:

await expect(locator).toBeVisible();

await expect(locator).toHaveText('Berhasil');

await expect(locator).toHaveValue('32500');

await expect(locator).toBeEnabled();

await expect(locator).toHaveCount(25);

Playwright menyediakan auto-waiting dan assertion yang melakukan retry sampai kondisi terpenuhi atau batas waktu habis.

Dengan demikian, developer tidak perlu sembarangan menggunakan jeda waktu tetap seperti waitForTimeout() untuk menunggu setiap elemen.

Kombinasi Action, Locator, dan Assertion menjadi fondasi penting dalam pengujian UI.

6. Studi Kasus: Menguji Perhitungan MOQ pada Sistem ERP

Sekarang kita masuk ke contoh yang lebih dekat dengan kebutuhan bisnis.

Bayangkan sebuah aplikasi ERP digunakan untuk mengelola transaksi pesanan barang berdasarkan berat.

Sistem memiliki aturan:

• Total berat pesanan: 260 kg.
• Berat setiap produk: 8 gram.
• Sistem harus mengonversi berat menjadi jumlah unit produk.

Secara matematis:

260 kg = 260.000 gram.

Jumlah produk:

260.000 ÷ 8 = 32.500 pieces.

Artinya, aplikasi harus menghasilkan 32.500 unit.

Bagaimana memastikan perhitungan tersebut tetap benar setelah developer mengubah kode aplikasi?

Salah satu caranya adalah membuat automated test.

import { test, expect } from '@playwright/test';

test('menghitung jumlah produk berdasarkan MOQ', async ({ page }) => {
  await page.goto('http://localhost:3000/orders');

  await page.getByLabel('Berat Pesanan (kg)')
    .fill('260');

  await page.getByLabel('Berat Produk (gram)')
    .fill('8');

  await expect(
    page.getByLabel('Jumlah Pieces')
  ).toHaveValue('32500');
});

Contoh tersebut menguji hasil yang ditampilkan aplikasi melalui antarmuka pengguna.

Asumsinya adalah seluruh berat bersih dapat dikonversi menjadi unit produk tanpa susut atau pembulatan.

Dalam sistem produksi, aturan seperti toleransi berat, pembulatan, satuan minimum, dan validasi stok juga harus diuji sesuai kebutuhan bisnis.

Untuk menjaga kualitas lebih baik, pengujian sebaiknya dibagi menjadi beberapa lapisan:

1. Unit test untuk menguji rumus perhitungan secara langsung.
2. Integration test untuk memastikan komunikasi backend dan database berjalan benar.
3. End-to-end test untuk memastikan pengguna dapat menyelesaikan proses transaksi melalui UI.

Dengan pendekatan tersebut, kesalahan dapat ditemukan pada lapisan yang tepat.

7. Studi Kasus: Menguji Sistem Ujian pada Learning Management System

Contoh berikutnya adalah aplikasi Learning Management System (LMS).

Sebuah sistem ujian memiliki konfigurasi:

• 25 soal pilihan ganda.
• 15 sub-soal esai.
• Durasi ujian 45 menit.

Pengujian manual dapat dilakukan dengan membuka halaman ujian dan memeriksa satu per satu komponennya.

Namun, proses ini menjadi tidak efisien jika harus dilakukan setiap kali ada pembaruan aplikasi.

Playwright dapat membantu mengotomatisasi skenario tersebut.

Contoh sederhana:

import { test, expect } from '@playwright/test';

test('memastikan konfigurasi jumlah soal ujian', async ({ page }) => {
  await page.goto('/exam/123');

  await expect(
    page.getByRole('group', {
      name: /pilihan ganda/i
    })
  ).toHaveCount(25);

  await expect(
    page.getByRole('group', {
      name: /esai/i
    })
  ).toHaveCount(15);
});

Contoh ini mengasumsikan setiap soal menggunakan elemen dengan role group dan accessible name yang sesuai.

Implementasi sebenarnya harus menyesuaikan struktur HTML aplikasi.

Bagaimana dengan timer 45 menit?

Pengujian timer sebaiknya tidak hanya memastikan angka 45:00 muncul.

Ada beberapa skenario yang perlu diperiksa:

• Timer dimulai ketika sesi ujian dimulai.
• Timer berkurang sesuai waktu.
• Jawaban tetap tersimpan selama sesi berlangsung.
• Pengguna tidak dapat melanjutkan ujian setelah waktu habis.
• Sistem menjalankan mekanisme pengumpulan jawaban sesuai aturan.
• Perubahan waktu pada browser tidak dapat digunakan untuk melewati batas waktu server.

Poin terakhir sangat penting.

Untuk aplikasi ujian, batas waktu harus ditegakkan oleh backend. Jam pada browser hanya berfungsi sebagai representasi bagi pengguna, bukan sumber kebenaran utama.

Dengan begitu, pengujian tidak hanya memeriksa tampilan, tetapi juga memastikan aturan bisnis berjalan sebagaimana mestinya.

8. Integrasi Playwright dengan CI/CD

Otomatisasi pengujian akan memberikan manfaat lebih besar jika diintegrasikan ke dalam pipeline CI/CD.

CI/CD memungkinkan pengujian dijalankan secara otomatis ketika developer mengirim perubahan kode.

Sebagai contoh, alur pengembangan dapat dibuat seperti berikut:

Developer mengubah kode
          |
          v
     Git Push
          |
          v
    CI Pipeline
          |
          v
   Install Dependencies
          |
          v
     Build Application
          |
          v
    Run Playwright Tests
          |
          v
     Test Results
          |
     +----+----+
     |         |
   Passed    Failed
     |         |
     v         v
  Continue   Fix Bug
  Deployment

Dengan pendekatan ini, aplikasi dapat menjalani serangkaian pengujian sebelum perubahan kode diteruskan ke tahap deployment.

Jika pengujian gagal, tim dapat memeriksa laporan kegagalan dan memperbaiki masalah sebelum perubahan dirilis.

Playwright juga menyediakan Trace Viewer untuk membantu menganalisis kegagalan melalui rekaman aktivitas, snapshot halaman, dan informasi jaringan.

Hal ini sangat membantu ketika sebuah pengujian berhasil di komputer developer, tetapi gagal saat dijalankan di lingkungan CI.

9. Jangan Hanya Menguji UI: Bangun Strategi QA Berlapis

Satu kesalahan yang sering terjadi ketika mulai menggunakan browser automation adalah mencoba menguji seluruh kebutuhan aplikasi hanya melalui UI.

Padahal, tidak semua pengujian harus dilakukan menggunakan browser.

Sistem pengujian yang baik sebaiknya menggunakan beberapa lapisan.

Unit Testing

Digunakan untuk menguji fungsi atau logika secara terpisah.

Contohnya:

• Rumus MOQ.
• Perhitungan diskon.
• Perhitungan PPN.
• Validasi nilai transaksi.

Integration Testing

Digunakan untuk memastikan beberapa komponen dapat bekerja bersama.

Contohnya:

• Backend dapat menyimpan transaksi.
• API menghasilkan respons yang benar.
• Database menyimpan nilai sesuai aturan.
• Sistem autentikasi memeriksa hak akses.

End-to-End Testing

Digunakan untuk menguji keseluruhan alur dari perspektif pengguna.

Contohnya:

• Login.
• Membuat transaksi.
• Menyimpan data.
• Melihat hasil transaksi.
• Memastikan pengguna mendapatkan informasi yang benar.

Visual Regression Testing

Digunakan untuk mendeteksi perubahan tampilan yang tidak diharapkan.

Playwright juga menyediakan kemampuan screenshot comparison untuk membantu pengujian visual.

Dengan pembagian ini, setiap jenis pengujian memiliki tanggung jawab yang jelas.

Tidak semua masalah harus diselesaikan dengan browser automation.

10. Bagaimana Memulai QA Automation pada Proyek Kecil?

Tidak perlu menunggu aplikasi menjadi besar untuk mulai menerapkan otomatisasi pengujian.

Developer dapat memulainya dari fitur yang paling sering digunakan dan memiliki risiko bisnis tinggi.

Prioritaskan:

1. Login dan autentikasi.
2. Proses pembuatan serta penyimpanan data.
3. Perhitungan transaksi.
4. Validasi formulir.
5. Hak akses pengguna.
6. Proses pembayaran atau transaksi penting.

Setelah itu, buat test suite secara bertahap.

Beberapa prinsip yang perlu diterapkan:

• Gunakan data pengujian yang konsisten.
• Hindari ketergantungan antar-test.
• Gunakan Locator yang stabil.
• Tambahkan assertion pada setiap skenario penting.
• Pisahkan data pengujian dari data produksi.
• Pastikan lingkungan pengujian dapat diulang.
• Periksa hasil tes sebelum melakukan deployment.

Tidak perlu langsung membuat ratusan skenario. Mulailah dengan beberapa pengujian yang memberikan dampak paling besar.

11. Apakah Playwright Akan Menggantikan QA Manual?

Jawabannya tidak.

Otomatisasi bukan berarti seluruh aktivitas pengujian harus diserahkan kepada mesin.

Ada banyak aspek yang tetap membutuhkan penilaian manusia, seperti:

• Apakah tampilan aplikasi mudah dipahami?
• Apakah alur pengguna terasa alami?
• Apakah informasi disampaikan dengan jelas?
• Apakah pengalaman pengguna sesuai kebutuhan?
• Apakah terdapat perilaku tidak terduga yang belum tercakup dalam test case?

Automated testing bekerja berdasarkan skenario yang telah didefinisikan.

Jika sebuah masalah belum pernah dimasukkan ke dalam skenario pengujian, bukan berarti Playwright akan otomatis menemukannya.

Karena itu, pendekatan terbaik adalah menggabungkan pengujian otomatis dan manual.

Manusia berfokus pada eksplorasi, analisis, dan evaluasi kualitas. Mesin menangani pengujian berulang yang sudah terstruktur.

12. Kesimpulan: Dari Mengulang Klik Menjadi Membangun Kepercayaan

Dalam pengembangan perangkat lunak modern, tantangan bukan hanya membuat fitur baru, tetapi memastikan fitur lama tetap bekerja ketika aplikasi terus berkembang.

Playwright menawarkan pendekatan praktis untuk membangun otomatisasi browser.

CodeGen mempercepat pembuatan skenario awal melalui rekaman interaksi. Locator membantu menemukan elemen dengan pendekatan yang lebih bermakna. Assertion memastikan hasil pengujian sesuai dengan ekspektasi.

Ketiganya dapat menjadi fondasi untuk membangun sistem QA Automation yang terukur.

Namun, kualitas perangkat lunak tidak ditentukan oleh banyaknya skrip pengujian yang dimiliki sebuah proyek. Kualitasnya ditentukan oleh seberapa baik pengujian tersebut mewakili kebutuhan pengguna dan aturan bisnis.

Tidak ada automated test yang dapat menjamin seluruh kemungkinan perilaku aplikasi selalu benar.

Akan tetapi, pengujian yang dirancang dengan baik dapat mengurangi risiko regresi, mempercepat proses validasi, dan meningkatkan kepercayaan tim terhadap setiap perubahan kode.

Tujuan QA Automation bukan menggantikan manusia dalam menguji perangkat lunak, melainkan membebaskan manusia dari pekerjaan pengujian berulang agar dapat lebih fokus pada peningkatan kualitas produk.

---

Referensi dan Dokumentasi Resmi

1. Playwright Documentation — Dokumentasi utama Playwright.
2. Generating Tests with Codegen — Panduan merekam interaksi browser menjadi kode.
3. Locators — Referensi penggunaan Locator.
4. Assertions — Panduan validasi hasil pengujian.
5. Best Practices — Praktik terbaik membangun pengujian yang stabil.
6. Continuous Integration — Integrasi Playwright dengan CI/CD.
7. Trace Viewer — Analisis kegagalan pengujian.

Artikel ini disusun sebagai materi edukasi pengembangan perangkat lunak dan QA Automation.