Pertemuan 9 - Automation Testing Intro (Mahasiswa)

Sangat Lambat

Manual testing membutuhkan waktu berjam-jam untuk mengetik form dan memverifikasi data di layar satu per satu.

Biaya Jangka Panjang

Biaya operasional untuk membayar waktu kerja tim QA manual dalam pengujian regresi berulang terus membengkak.

Human Error

Kejenuhan dan kelelahan manusia memicu ketidaktelitian penguji manual saat memverifikasi bug regresi kecil.

Pengujian Beban

Mustahil menguji ketahanan server menerima 10.000 transaksi serentak menggunakan tim tester manual.

Cakupan Terbatas

Sulit mengetes kompabilitas aplikasi secara manual di 20 kombinasi versi browser dan sistem operasi.

Hambat Alur DevOps

Metodologi Agile mewajibkan deployment harian, yang terhambat jika testing regresi manual butuh waktu berhari-hari.

Manual Testing (Fokus Manusia)

• Investasi Awal: Sangat Rendah (cukup dokumen test case).

• Akurasi: Sedang (Rawan terlewat akibat faktor human fatigue).

• Kegunaan UI/UX: Luar Biasa (Manusia peka terhadap keindahan layout).

• Exploratory: Sangat Baik (Tester bebas mengeksplorasi secara dinamis).

• Kecepatan Eksekusi: Lambat (Mengandalkan interaksi fisik klik-ketik).

Automated Testing (Fokus Robot/Script)

• Investasi Awal: Tinggi (Lisensi, coding script, setup framework).

• Akurasi: Sempurna (Script mengikuti kode assertions dengan rigid).

• Kegunaan UI/UX: Buruk (Robot tidak memiliki rasa estetik/keindahan).

• Exploratory: Tidak Bisa (Hanya mengeksekusi jalur skenario tertulis).

• Kecepatan Eksekusi: Sangat Cepat (Berjalan di background compiler).

1. Fitur Sudah Stabil

Modul atau fitur aplikasi tidak lagi mengalami perubahan desain atau logic utama secara dinamis.

2. Skenario Regresi

Pengujian berulang untuk memastikan fitur lama tidak rusak akibat update kode baru.

3. Transaksi Kritis

Fungsi bisnis utama yang vital seperti alur login, payment gateway, dan checkout e-commerce.

4. Pengulangan Tinggi

Test case yang harus dijalankan puluhan kali dengan parameter data berbeda (Data-Driven Testing).

5. Pengujian Beban

Memverifikasi limit kinerja aplikasi menerima lonjakan request transaksi (stress testing).

6. API & Web Services

Uji respon backend endpoint microservices yang melayani lalu lintas pertukaran data.

UI/UX Dinamis

Fitur yang tampilannya masih digonta-ganti setiap minggu oleh UI Designer.

Exploratory Testing

Pengujian acak berdasarkan intuisi tester untuk menguji fungsionalitas ekstrem.

Sekali Pakai (Ad-hoc)

Fitur kustom yang hanya diuji satu kali dan tidak masuk rilis utama.

Usability / UX

Menilai kenyamanan tata letak warna dan alur navigasi dari sudut kognitif manusia.

ROI Rendah

Script uji yang sangat rumit dibuat tetapi fungsinya jarang dieksekusi.

Aspek Fisik

Pengujian yang memerlukan aksi fisik manusia (colok kabel USB, menekan sakelar).

Smoke Test Suite

Kumpulan test case kritis untuk memastikan aplikasi tidak crash saat baru di-deploy ke server testing.

Sanity Test Suite

Pengujian terfokus untuk memverifikasi fungsionalitas baru atau perbaikan bug berjalan dengan sukses.

Regression Test Suite

Pengujian komprehensif pada fitur lama aplikasi untuk memvalidasi tidak ada dampak negatif update kode.

Data-Driven Suite

Pengujian otomatis yang mengulang skenario uji berkali-kali menggunakan data input dari file external (CSV/JSON).

Cross-Browser Suite

Menjalankan script uji secara paralel di Chrome, Firefox, Safari, dan Edge secara serentak.

API Test Suite

Uji level integrasi response data web services (REST API) secara cepat tanpa memicu visual interface.

Biaya Awal Tinggi

Investasi setup server, pelatihan tim, dan lisensi tools berbayar (jika ada) membutuhkan anggaran besar.

Pemeliharaan Script

Script pengujian akan rusak (broken) saat developer mengubah nama ID elemen UI pada layout aplikasi.

Flaky Tests

Hasil uji mendeteksi error semu (false failure) akibat isu latensi koneksi internet atau server lambat.

Learning Curve

Tim tester manual wajib menguasai keahlian koding pemrograman agar bisa menyusun framework otomatis.

Ekspektasi Keliru

Anggapan salah bahwa automasi 100% akan menemukan seluruh jenis bug secara ajaib.

Manajemen Data Uji

Kesulitan mereset database dan menyediakan data unik yang selalu valid sebelum tes otomatis jalan.

Page Object Model (POM)

Pola arsitektur memisahkan logic penulisan tes dengan selector element visual web halaman web.

Modular & Reusable

Membuat library fungsi pembantu (misalnya loginHelper) untuk mencegah kode script pengujian duplikat.

Separation of Data

Memisahkan test data (CSV/Excel) dari kode program agar script tidak perlu dirubah saat data diganti.

Assert yang Terarah

Menuliskan pembuktian sukses/gagal secara spesifik dengan pesan kegagalan yang jelas (explicit check).

Independent Tests

Tiap test case dirancang mandiri tanpa bergantung pada kondisi output test case lain.

Script Code Review

Melakukan evaluasi code script testing antar anggota tim untuk menjaga kualitas standar penulisan.

1. Deskripsi Proyek

Bekerja berkelompok (3-4 orang) berperan sebagai Tim QA untuk mengidentifikasi kebutuhan kelayakan automasi pada aplikasi web ril.

2. Analisis Kelayakan

Menyusun laporan Feasibility Study menganalisis kelayakan teknis aplikasi, CLI ROI, dan kesiapan kompetensi tim.

3. Pemilahan Test Case

Memilih minimal 20 skenario uji manual, lalu memilah 10 diantaranya yang layak diautomasi berdasarkan parameter tingkat repetisi.

4. Pemilihan Alat Uji

Merekomendasikan alat uji (Selenium, JUnit, Postman, JMeter) yang paling cocok dengan sistem yang sedang ditargetkan.

5. Nilai Tambah (Opsional)

Membuat prototipe coding script pengujian otomatis sederhana menggunakan Selenium IDE (Web) atau Postman Runner (API).

6. Luaran & Presentasi

Proyek dikerjakan selama 3 minggu. Laporan kemajuan dikumpulkan bertahap hingga presentasi final pada Pertemuan 12.

Modul A: Pengisian KRS Mahasiswa

Dipakai di awal semester serentak oleh ribuan mahasiswa secara bersamaan.
Rekomendasi: YA. Gunakan Apache JMeter untuk menguji ketahanan performa server.

Modul B: Halaman Login (ada CAPTCHA dinamis)

Fungsi kritis utama yang diakses berulang kali setiap hari.
Rekomendasi: YA. Gunakan Selenium (dengan bypass CAPTCHA di server sandbox).

Modul C: Input Nilai oleh Dosen

Hanya diakses dua kali setahun (akhir UTS/UAS), alurnya stabil.
Rekomendasi: TIDAK. Lebih efisien diuji manual karena frekuensi eksekusi sangat rendah.

Modul D: Pembayaran Uang Kuliah Online

Kritis finansial, terintegrasi bank.
Rekomendasi: YA. API integration testing otomatis menggunakan Postman untuk memvalidasi callback server.