Pengujian otomatis membantu Anda meningkatkan kualitas aplikasi dalam berbagai cara. Misalnya, alat 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 mencapai tingkat produktivitas yang lebih tinggi saat mereka menggunakan pendekatan sistematis untuk pengujian yang dipasangkan dengan peningkatan infrastruktur. Dengan begitu, Anda akan mendapatkan masukan tepat waktu tentang perilaku kode. Strategi pengujian yang baik melakukan hal berikut:
- Mengidentifikasi masalah sedini mungkin.
- Dieksekusi dengan cepat.
- Memberikan indikasi yang jelas saat ada sesuatu yang perlu diperbaiki.
Halaman ini akan membantu Anda memutuskan jenis pengujian yang akan diterapkan, tempat menjalankan pengujian, dan seberapa sering pengujian harus dijalankan.
Piramida pengujian
Anda dapat mengategorikan pengujian dalam aplikasi modern berdasarkan ukuran. Pengujian kecil hanya berfokus pada sebagian kecil kode, sehingga pengujian ini cepat dan andal. Pengujian besar memiliki cakupan yang luas dan memerlukan penyiapan yang lebih kompleks sehingga sulit dipertahankan. Namun, pengujian besar memiliki fidelitas* yang lebih tinggi, dan 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 di setiap kategori harus membentuk piramida, dengan pengujian kecil yang lebih banyak membentuk dasar dan pengujian besar yang lebih sedikit 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 menurut ukuran tidak disusun menjadi piramida. Terlalu banyak pengujian end-to-end yang besar dan terlalu sedikit pengujian UI komponen:
Artinya, terlalu sedikit pengujian yang dijalankan sebelum penggabungan. Jika ada bug, pengujian mungkin tidak dapat mendeteksinya hingga pengujian menyeluruh harian atau mingguan dijalankan.
Penting untuk mempertimbangkan implikasi yang ditimbulkan terhadap biaya identifikasi dan perbaikan bug serta alasan pentingnya memfokuskan upaya pengujian pada pengujian yang lebih kecil dan lebih sering:
- Jika bug ditemukan oleh uji unit, biasanya bug tersebut dapat diperbaiki dalam beberapa 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.
Namun, strategi pengujian yang tidak efisien lebih baik daripada tidak ada strategi sama sekali. Jika bug sampai ke produksi, perbaikannya memerlukan waktu yang lama untuk sampai ke perangkat pengguna, terkadang berminggu-minggu, sehingga feedback loop menjadi yang paling lama dan paling mahal.
Strategi pengujian yang dapat diskalakan
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 mendefinisikan kategori mereka 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 error selisih satu dalam fungsi matematika.
- Pengujian komponen memverifikasi fungsi atau tampilan modul atau komponen secara terpisah dari komponen lain dalam sistem. Tidak seperti pengujian unit, area permukaan pengujian komponen meluas ke abstraksi yang lebih tinggi di atas metode dan class individual.
- Contoh: Screenshot test untuk tombol kustom
- Pengujian fitur memverifikasi interaksi dua atau lebih komponen atau modul independen. Pengujian fitur lebih besar dan lebih kompleks, serta
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 dev yang dapat berisi hook pengujian,
sebagai sistem yang sedang diuji.
- Contoh: Pengujian perilaku UI untuk memverifikasi perubahan konfigurasi di perangkat lipat, pengujian pelokalan, dan aksesibilitas
- Pengujian kandidat rilis memverifikasi fungsi build rilis.
Pengujian ini mirip dengan pengujian aplikasi, kecuali biner aplikasi diminifikasi dan dioptimalkan. Ini adalah pengujian integrasi end-to-end 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
Pengkategorian ini mempertimbangkan 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 |
|
|---|---|---|---|---|---|
Satuan |
Metode atau class tunggal 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 |
Mocked |
Lokal |
Dapat di-debug |
Pra-penggabungan |
Aplikasi |
Tingkat aplikasi Integrasi dengan fitur dan/atau layanan yang dimiliki oleh tim lain |
Mocked |
Perangkat |
Dapat di-debug |
Sebelum penggabungan |
Kandidat Rilis |
Tingkat aplikasi Integrasi dengan fitur dan/atau layanan yang dimiliki oleh tim lain |
Server produksi |
Perangkat |
Build rilis yang di-minify |
Pasca-penggabungan |
Menentukan kategori pengujian
Sebagai aturan praktis, Anda harus mempertimbangkan lapisan terendah piramida 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 diuji |
Deskripsi tentang apa yang sedang diuji |
Kategori pengujian |
Contoh jenis pengujian |
|---|---|---|---|
Logika validator formulir |
Class yang memvalidasi alamat email berdasarkan ekspresi reguler dan memeriksa apakah kolom sandi telah diisi. 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 mengirimkan kredensial ke pengelola autentikasi dan menerima respons yang dapat berisi berbagai error. |
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 penyiapan |
Kandidat Rilis |
Pengujian perilaku UI Compose menyeluruh yang berjalan di perangkat |
Dalam beberapa kasus, apakah sesuatu termasuk dalam satu kategori atau kategori lain dapat bersifat subjektif. Ada alasan lain 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 Kandidat Rilis, tetapi mereka juga dapat terlibat dalam tahap lainnya. Misalnya, pengujian eksploratif untuk bug dalam fitur tanpa skrip.
Infrastruktur pengujian
Strategi pengujian harus didukung oleh infrastruktur dan alat untuk membantu developer menjalankan pengujian secara berkelanjutan dan menerapkan aturan yang menjamin bahwa semua pengujian lulus.
Anda dapat mengategorikan pengujian menurut cakupan untuk menentukan kapan dan di mana pengujian mana yang akan dijalankan. Misalnya, mengikuti model 5 lapisan:
Kategori |
Lingkungan (di mana) |
Pemicu (kapan) |
|---|---|---|
Satuan |
[Lokal][4] |
Setiap commit |
Komponen |
Lokal |
Setiap commit |
Fitur |
Lokal dan emulator |
Sebelum penggabungan, sebelum menggabungkan atau mengirimkan perubahan |
Aplikasi |
Lokal, emulator, 1 ponsel, 1 perangkat foldable |
Setelah 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 dijalankan sebelum menggabungkan atau mengirimkan perubahan.
- Pengujian Aplikasi dijalankan setelah penggabungan.
- Pengujian Release Candidate dijalankan setiap malam di ponsel, perangkat foldable, dan tablet.
- Sebelum rilis, pengujian Kandidat Rilis dijalankan di sejumlah besar perangkat.
Aturan ini dapat berubah seiring waktu saat jumlah pengujian memengaruhi produktivitas. Misalnya, jika memindahkan pengujian ke irama harian, Anda dapat mengurangi waktu build dan pengujian CI, tetapi Anda juga dapat memperpanjang siklus masukan.