Fitur pengujian hipotesis untuk aplikasi seluler

Berapa lama tes hipotesis diperlukan untuk aplikasi seluler? Mari kita hitung:

1. Pengembangan aplikasi yang bekerja dalam mode berbeda untuk grup pengguna yang berbeda.
2. Menguji hasilnya.
3. Menempatkan aplikasi di app store dan menunggu persetujuan.
4. Menunggu pengguna memperbarui aplikasi. Pada 2019, sebagian besar pembaruan otomatis dihidupkan, tetapi tidak semua orang memilikinya.
5. Pengumpulan dan analisis statistik.
6. Membawa aplikasi ke keadaan hipotesis yang menang, sejalan dengan pengembangan berikut ...

Jika pengembang Anda mengerjakan Scrum dengan iterasi dua minggu, ini biasanya berarti pengujian hipotesis membutuhkan waktu satu bulan penuh. Dengan metodologi lain, periode ini dapat dipersingkat, tetapi tidak signifikan.

Keadaan ini membuat mustahil untuk mencapai ritme "5 hipotesis per minggu", yang diperjuangkan oleh banyak tim produk.

Di bawah ini saya akan memberi tahu Anda bagaimana Anda dapat mempercepat dan meningkatkan proses ini dan menunjukkan sejumlah solusi siap pakai yang dapat Anda gunakan.

Ayo pergi.

Nyalakan dan matikan

Sebelum masuk ke detail, Anda harus memasukkan istilah tambahan - pola Fitur flag (Fitur toggle) .

Untuk pembaca tanpa latar belakang teknis, klarifikasi mungkin diperlukan:

Ketika mengembangkan beberapa fitur baru, programmer memperkenalkan "switch" dalam kode aplikasi yang mengaktifkan fitur ini. Biasanya, solusi ini digunakan untuk menjaga fitur yang belum selesai dalam kode program umum, tetapi, tentu saja, ini juga dapat digunakan untuk menguji hipotesis.

Untuk menggunakan pola bendera Fitur dalam menguji percobaan, Anda perlu:

1. Fungsionalitas yang dikembangkan sepenuhnya untuk percobaan.
2. Sakelar untuk itu dalam keadaan “Mati” default.
3. Kontrol saklar jarak jauh dari server.

Pertanyaannya adalah, berapa lama waktu yang dihemat jika fungsi masih perlu dikembangkan sebelum melakukan tes A / B? Mari kita coba untuk menguraikan tahapan percobaan:

Apa yang kita lihat di sini?

Pertama, menggunakan fitur bendera, kita dapat mengunggah aplikasi ke toko aplikasi sebelum sepenuhnya menguji kesalahan. Kami hanya perlu memastikan bahwa ketika fungsi baru dimatikan, aplikasi berperilaku seperti sebelumnya - dan ini dapat dilakukan dengan autotest yang ditulis sebelumnya. Sisanya dapat diuji saat aplikasi didistribusikan di antara pengguna.

Kedua, setelah percobaan selesai, Anda dapat menggunakan bendera Fitur untuk mengaktifkan / menonaktifkan fungsi untuk semua pengguna sampai versi berikutnya siap, di mana bendera tidak akan lagi digunakan.

Dengan prinsip inilah layanan Apptimize berfungsi , menyediakan sistem yang siap pakai untuk pengujian A / B.

Menganalisis

Untuk melakukan percobaan, Anda perlu melakukan beberapa hal:

1. Pilih segmen pengguna jika percobaan ini bukan untuk semua orang.
2. Pilih ukuran audiens.
3. Kumpulkan data, dan bukan hanya yang diverifikasi oleh eksperimen. Metrik bisnis lainnya akan diperlukan untuk memastikan bahwa percobaan tidak menghasilkan apa pun dalam metrik lainnya.
4. Kumpulkan dan analisis hasilnya.

Jika Anda tidak menggunakan solusi siap pakai dari Apptimize, pendekatan paling sederhana adalah kombinasi Google Analytics untuk Firebase untuk analitik dan Firebase Remote Config untuk mengatur konfigurasi individual (segmen dan tes). Alat-alat ini dirancang untuk bekerja bersama.

Karena itu, Anda perlu:

1. Gunakan Google Analytics untuk Firebase untuk melacak metrik bisnis.
2. Gunakan Firebase Remote Config untuk mengelola flag Fitur.
3. Gunakan Firebase Remote Config untuk menentukan segmen dan parameter percobaan.
4. Analisis data dari Google Analytics menggunakan kunci dari Firebase Remote Config dalam analisis. Fitur ini disediakan oleh alat-alat ini “out of the box”.

Kami akan mengoptimalkan lebih lanjut

Kami melihat bagaimana mempersingkat siklus pengujian hipotesis untuk aplikasi seluler, mengurangi waktu yang dihabiskan untuk menguji dan menyebarluaskan hasil percobaan. Tetapi pendekatan ini tidak memungkinkan untuk membuang waktu untuk persetujuan dan distribusi aplikasi. Tujuan "5 hipotesis per minggu" dengan pendekatan ini masih sangat tidak realistis.

Untuk mempercepat percobaan, Anda harus dapat mengembangkan dan mengirim fungsionalitas baru tanpa harus memperbarui aplikasi. Ini bisa dicapai, Anda harus menggunakan antarmuka pengguna yang dinamis. Namun, pendekatan ini memiliki masalah:

Di satu sisi, ada batasan teknis pada konstruksi antarmuka sesuai dengan pengaturan yang diterima dari luar. Sebagian besar kerangka kerja pengembangan seluler menggunakan pendekatan deklaratif di mana tidak mungkin atau sangat sulit.

Di sisi lain, kebijakan toko aplikasi melarang pengunduhan dan pelaksanaan kode arbitrer, karena dapat digunakan untuk fungsi yang melanggar aturan toko aplikasi.

Batasan lain adalah jumlah data yang ditransfer dari Firebase Remote Config. Itu tidak dapat digunakan untuk mentransfer seluruh antarmuka. Ini optimal untuk menyimpan di dalamnya hanya "kunci" dari versi tertentu dari antarmuka, dan ketika mengubah kode ini, memuat antarmuka dari layanan pihak ketiga. Dengan sendirinya, ini tidak membatasi pilihan kerangka kerja pengembangan seluler, tetapi membutuhkan upaya implementasi tambahan.

Solusi optimal adalah pendekatan di mana hanya antarmuka pengguna yang dibangun secara dinamis, dan logika bisnis tetap diperbaiki. Karena sebagian besar percobaan produk berhubungan khusus dengan antarmuka, Anda dapat mempertahankan kecepatan kerja yang tinggi. Pada saat yang sama, percobaan yang membutuhkan penyempurnaan dari logika bisnis dapat dilakukan secara paralel, sesuai dengan proses yang dijelaskan di atas dengan bendera.

Secara teknis, pendekatan ini paling mudah diimplementasikan dalam kerangka kerja yang memiliki karakteristik sebagai berikut:

1. Antarmuka pengguna reaktif, berkinerja tinggi yang tidak menggunakan pendekatan deklaratif secara default.
2. Dukungan untuk Google Analytics untuk Firebase dan Firebase Remote Config.
3. Solusi lintas-platform diinginkan untuk mempercepat pengembangan secara keseluruhan.

Secara optimal, kerangka kerja Flutter memenuhi kriteria ini. Sebagai bukti konsep pendekatan ini, baginya ada perpustakaan yang memungkinkan Anda membuat antarmuka yang dinamis .

Menggunakan antarmuka dinamis yang dibuat oleh Flutter, Google Analytics untuk Firebase dan Firebase Remote Config, Anda dapat mengembangkan aplikasi yang dapat dibandingkan dengan situs web dengan kemudahan pengujian hipotesis.