Pengujian otomatis membantu Anda meningkatkan kualitas aplikasi dengan beberapa cara. Misalnya, API ini membantu Anda melakukan validasi, mendeteksi regresi, dan memverifikasi kompatibilitas. Strategi pengujian yang baik memungkinkan Anda memanfaatkan pengujian otomatis untuk berfokus pada manfaat penting: produktivitas developer.
Tim akan mencapai tingkat produktivitas yang lebih tinggi jika menggunakan pendekatan sistematis untuk pengujian yang dipadukan dengan peningkatan infrastruktur. Tindakan ini memberikan masukan yang tepat waktu tentang perilaku kode. Strategi pengujian yang baik akan menghasilkan hal-hal berikut:
- Mendeteksi masalah sedini mungkin.
- Dieksekusi dengan cepat.
- Memberikan indikasi yang jelas saat ada yang perlu diperbaiki.
Halaman ini akan membantu Anda memutuskan jenis pengujian yang akan diterapkan, tempat menjalankannya, dan seberapa seringnya.
Piramida pengujian
Anda dapat mengategorikan pengujian dalam aplikasi modern berdasarkan ukuran. Pengujian kecil hanya berfokus pada sebagian kecil kode, sehingga mempercepat dan dapat diandalkan. Pengujian besar memiliki cakupan yang luas dan memerlukan penyiapan yang lebih kompleks yang sulit dikelola. Namun, pengujian besar memiliki lebih banyak fidelitas*, dan pengujian tersebut dapat menemukan lebih banyak masalah sekaligus.
*Fidelitas mengacu pada kemiripan lingkungan runtime pengujian dengan lingkungan produksi.
Sebagian besar aplikasi harus memiliki banyak pengujian kecil dan relatif sedikit pengujian besar. Distribusi pengujian dalam setiap kategori harus membentuk piramida, dengan lebih banyak pengujian kecil yang membentuk dasar dan lebih sedikit pengujian besar yang membentuk ujung.
Meminimalkan biaya bug
Strategi pengujian yang baik akan memaksimalkan produktivitas developer sekaligus meminimalkan biaya untuk menemukan bug.
Pertimbangkan contoh strategi yang mungkin tidak efisien. Di sini, jumlah pengujian berdasarkan ukuran tidak disusun menjadi piramida. Ada terlalu banyak pengujian menyeluruh yang besar dan terlalu sedikit pengujian UI komponen:
Artinya, terlalu sedikit pengujian yang dijalankan sebelum penggabungan. Jika ada bug, pengujian mungkin tidak mendeteksinya hingga pengujian menyeluruh harian atau mingguan dijalankan.
Penting untuk mempertimbangkan implikasinya terhadap biaya identifikasi dan perbaikan bug serta alasan pentingnya membiaskan upaya pengujian Anda ke pengujian yang lebih kecil dan lebih sering:
- Jika terdeteksi oleh pengujian unit, bug biasanya diperbaiki dalam hitungan menit, sehingga biayanya rendah.
- Pengujian menyeluruh dapat memerlukan waktu berhari-hari untuk menemukan bug yang sama. Hal ini dapat menarik beberapa anggota tim, sehingga mengurangi produktivitas secara keseluruhan dan berpotensi menunda rilis. Biaya bug ini lebih tinggi.
Meskipun demikian, strategi pengujian yang tidak efisien lebih baik daripada tidak ada strategi sama sekali. Jika bug sampai ke produksi, perbaikannya memerlukan waktu lama untuk diluncurkan di perangkat pengguna, terkadang berminggu-minggu, sehingga feedback loop-nya adalah yang terpanjang dan paling mahal.
Strategi pengujian yang skalabel
Piramida pengujian secara tradisional dibagi menjadi 3 kategori:
- Pengujian unit
- Pengujian integrasi
- Pengujian menyeluruh.
Namun, konsep ini tidak memiliki definisi yang tepat, sehingga tim mungkin ingin menentukan kategorinya secara berbeda, misalnya menggunakan 5 lapisan:
- Pengujian unit dijalankan di mesin host dan memverifikasi satu unit logika
fungsional tanpa dependensi pada framework Android.
- Contoh: memverifikasi kesalahan off-by-one dalam fungsi matematika.
- Pengujian komponen memverifikasi fungsi atau tampilan modul atau
komponen secara independen dari komponen lain dalam sistem. Tidak seperti pengujian unit, area permukaan pengujian komponen meluas ke abstraksi yang lebih tinggi di atas setiap metode dan class.
- Contoh: Pengujian screenshot untuk tombol kustom
- Pengujian fitur memverifikasi interaksi dua komponen atau modul independen
atau lebih. Pengujian fitur lebih besar dan lebih kompleks, dan
biasanya beroperasi di tingkat fitur.
- Contoh: Pengujian perilaku UI yang memverifikasi pengelolaan status di layar
- Pengujian aplikasi memverifikasi fungsi seluruh aplikasi
dalam bentuk biner yang dapat di-deploy. Pengujian ini adalah pengujian integrasi besar yang
menggunakan biner yang dapat di-debug, seperti build developer yang dapat berisi hook pengujian,
sebagai sistem yang sedang diuji.
- Contoh: Pengujian perilaku UI untuk memverifikasi perubahan konfigurasi dalam pengujian perangkat foldable, pelokalan, dan aksesibilitas
- Pengujian kandidat rilis memverifikasi fungsi build rilis.
Pengujian ini mirip dengan pengujian aplikasi, hanya saja biner aplikasi
diminifikasi dan dioptimalkan. Pengujian ini adalah pengujian integrasi menyeluruh yang besar
yang berjalan di lingkungan yang sedekat mungkin dengan produksi tanpa
mengekspos aplikasi ke akun pengguna publik atau backend publik.
- Contoh: Perjalanan penting pengguna, pengujian performa
Kategorisasi ini memperhitungkan fidelitas, waktu, cakupan, dan tingkat isolasi. Anda dapat memiliki berbagai jenis pengujian di beberapa lapisan. Misalnya, lapisan pengujian Aplikasi dapat berisi pengujian perilaku, screenshot, dan performa.
Cakupan |
Akses jaringan |
Eksekusi |
Jenis build |
Lifecycle |
|
|---|---|---|---|---|---|
Unit |
Satu metode atau class dengan dependensi minimal. |
Tidak |
Lokal |
Dapat di-debug |
Pra-penggabungan |
Komponen |
Tingkat modul atau komponen Beberapa kelas bersama-sama |
Tidak |
Lokal |
Dapat di-debug |
Pra-penggabungan |
Fitur |
Tingkat fitur Integrasi dengan komponen yang dimiliki oleh tim lain |
Ditiru |
Perangkat |
Dapat di-debug |
Pra-penggabungan |
Aplikasi |
Tingkat aplikasi Integrasi dengan fitur dan/atau layanan yang dimiliki oleh tim lain |
|
Emulator |
Dapat di-debug |
Pra-penggabungan |
Kandidat Rilis |
Tingkat aplikasi Integrasi dengan fitur dan/atau layanan yang dimiliki oleh tim lain |
Server produksi |
Emulator |
Build rilis yang diminifikasi |
Pasca-penggabungan |
Menentukan kategori pengujian
Sebagai aturan praktis, Anda harus mempertimbangkan lapisan piramida terendah yang dapat memberikan tingkat masukan yang tepat kepada tim.
Misalnya, pertimbangkan cara menguji penerapan fitur ini: UI alur login. Bergantung pada hal yang perlu diuji, Anda akan memilih kategori yang berbeda:
Subjek yang sedang diuji |
Deskripsi hal yang sedang diuji |
Kategori pengujian |
Contoh jenis pengujian |
|---|---|---|---|
Logika validator formulir |
Class yang memvalidasi alamat email berdasarkan ekspresi reguler dan memeriksa apakah kolom sandi dimasukkan. Tidak memiliki dependensi. |
Pengujian unit |
|
Perilaku UI formulir login |
Formulir dengan tombol yang hanya diaktifkan jika formulir telah divalidasi |
Pengujian komponen |
Pengujian perilaku UI yang berjalan di Robolectric |
Tampilan UI formulir login |
Formulir yang mengikuti spesifikasi UX |
Pengujian komponen |
|
Integrasi dengan Pengelola Autentikasi |
UI yang mengirim kredensial ke pengelola autentikasi dan menerima respons yang dapat berisi error yang berbeda. |
Pengujian fitur |
|
Dialog login |
Layar yang menampilkan formulir login saat tombol login ditekan. |
Pengujian aplikasi |
Pengujian perilaku UI yang berjalan di Robolectric |
Perjalanan penting pengguna: Login |
Alur login lengkap menggunakan akun pengujian terhadap server staging |
Kandidat Rilis |
Pengujian perilaku UI Compose menyeluruh yang berjalan di perangkat |
Dalam beberapa kasus, apakah sesuatu termasuk dalam satu kategori atau kategori lainnya dapat bersifat subjektif. Mungkin ada alasan tambahan mengapa pengujian dipindahkan ke atas atau ke bawah, seperti biaya infrastruktur, ketidakstabilan, dan waktu pengujian yang lama.
Perhatikan bahwa kategori pengujian tidak menentukan jenis pengujian dan tidak semua fitur harus diuji di setiap kategori.
Pengujian manual juga dapat menjadi bagian dari strategi pengujian Anda. Biasanya, tim QA melakukan pengujian Calon Rilis, tetapi mereka juga dapat terlibat dalam tahap lain. Misalnya, pengujian eksplorasi untuk bug dalam fitur tanpa skrip.
Menguji infrastruktur
Strategi pengujian harus didukung oleh infrastruktur dan alat untuk membantu developer terus menjalankan pengujian dan menerapkan aturan yang menjamin bahwa semua pengujian lulus.
Anda dapat mengategorikan pengujian menurut cakupan untuk menentukan waktu dan tempat menjalankan pengujian. Misalnya, mengikuti model 5 lapisan:
Kategori |
Lingkungan (tempat) |
Pemicu (kapan) |
|---|---|---|
Unit |
[Local][4] |
Setiap commit |
Komponen |
Lokal |
Setiap commit |
Fitur |
Lokal dan emulator |
Pra-penggabungan, sebelum menggabungkan atau mengirimkan perubahan |
Aplikasi |
Lokal, emulator, 1 ponsel, 1 perangkat foldable |
Pasca-penggabungan, setelah menggabungkan atau mengirimkan perubahan |
Kandidat Rilis |
8 ponsel berbeda, 1 perangkat foldable, 1 tablet |
Pra-rilis |
- Pengujian Unit dan Komponen dijalankan di sistem Continuous Integration untuk setiap commit baru, tetapi hanya untuk modul yang terpengaruh.
- Semua pengujian Unit, Komponen, dan Fitur berjalan sebelum menggabungkan atau mengirim perubahan.
- Pengujian aplikasi berjalan setelah penggabungan.
- Pengujian Release Candidate dijalankan setiap malam di ponsel, perangkat foldable, dan tablet.
- Sebelum rilis, pengujian Release Candidate dijalankan di sejumlah besar perangkat.
Aturan ini dapat berubah dari waktu ke waktu jika jumlah pengujian memengaruhi produktivitas. Misalnya, jika Anda memindahkan pengujian ke ritme harian, Anda dapat mengurangi waktu build dan pengujian CI, tetapi Anda juga dapat memperpanjang siklus masukan.