Pengujian – mungkin bagian yang paling diremehkan dari pengembangan aplikasi

Mengapa saya harus membayar Anda untuk menguji pekerjaan Anda sendiri?

Ini adalah pertanyaan yang sering saya dengar selama bertahun-tahun ketika mendiskusikan anggaran pengujian dengan klien. Bagi yang belum tahu, kedengarannya seperti pertanyaan yang wajar. Namun, siapa pun yang terlibat dalam pengembangan perangkat lunak tahu betapa rumit dan memakan waktu pengujian. Pengujian, pada kenyataannya, adalah salah satu bagian terpenting dari setiap proyek pengembangan perangkat lunak.

Platform e-niaga besar adalah hal yang sangat kompleks dengan jutaan baris kode, gigabyte data, dan banyak titik integrasi. Ada begitu banyak bagian bergerak yang saling terkait; begitu banyak tautan dalam rantai sehingga sangat mudah terjadi kesalahan. Aplikasi ini akan digunakan dalam jutaan cara berbeda melalui banyak browser di berbagai perangkat desktop dan seluler. Proyek pengembangan akan berlangsung setidaknya 6 bulan dengan banyak orang berbeda yang mengerjakannya. Jumlah area dan skenario yang dapat diuji hampir tidak terbatas. Sungguh mengherankan apa pun bekerja sama sekali!

Pengujian dapat dibagi menjadi beberapa area yang berbeda, tetapi setiap area pengujian penting untuk dipertimbangkan. Setiap proyek sedikit berbeda; beberapa klien suka melakukan banyak pengujian sendiri, beberapa suka mengalihdayakannya sedangkan beberapa mengharapkan pengembang mereka melakukan semuanya. Pengujian juga bukan entitas tetap; Anda dapat melakukan banyak pengujian dan Anda dapat melakukan sedikit. Semakin banyak Anda menguji, semakin Anda akan mengurangi risiko proyek tetapi semakin banyak waktu yang dibutuhkan dan semakin banyak biayanya.

Pengujian unit

Tes unit adalah tes yang menguji 'unit' kecil kode untuk memastikan bahwa mereka berfungsi seperti yang diharapkan. Misalnya, ketika formulir dikirimkan, itu harus menyimpan detail yang dimasukkan ke dalam tabel database. Ini adalah tes mandiri yang secara khusus, dan hanya, memastikan bahwa unit berfungsi seperti yang diharapkan. Dengan menggunakan metodologi pengembangan yang didorong oleh pengujian yang sebenarnya, pengembang pertama-tama akan menulis pengujian sebelum benar-benar membuat kode apa pun sehingga kode tersebut dapat dianggap selesai hanya ketika pengujian telah berlalu. Dalam praktiknya, pengujian unit hanya digunakan pada beberapa area utama aplikasi untuk memastikan bahwa fungsi inti berfungsi seperti yang diharapkan. Sementara pengujian unit dapat mengurangi kemungkinan terjadinya masalah fungsional, itu juga dapat meningkatkan waktu pengembangan.

Pengujian asap

Anda mungkin akan sering mendengar agensi pengembangan Anda berbicara tentang pengujian asap. Uji asap adalah subset pragmatis dari kasus uji yang mencakup perjalanan dan fungsi utama pengguna di seluruh aplikasi Anda. Paling tidak, pengembang Anda diharapkan untuk melakukan tes asap sebelum menyerahkan apa pun kepada Anda untuk UAT.

pengujian UI

Pengujian Antarmuka Pengguna (UI) bisa menjadi hal yang sangat kompleks dan memakan waktu. Sejumlah besar perangkat seluler, tablet, dan desktop, sistem operasi, dan browser yang akan digunakan untuk mengakses situs web berarti hampir tidak mungkin untuk menguji setiap kombinasi secara manual. Karena banyaknya variasi berbeda yang perlu dicakup, pengujian UI adalah kandidat yang sempurna untuk pengujian otomatis. Alat uji otomatis dapat mengikuti perjalanan tertulis melalui situs web Anda dan menguji apakah hasil yang diharapkan tercapai. Mereka juga dapat merekam setiap perjalanan sehingga setiap perjalanan dapat diputar ulang. Meskipun metode ini tidak sempurna, metode ini dapat secara signifikan mengurangi jumlah masalah UI utama yang mungkin dihadapi situs web.

Beberapa layanan pengujian pihak ketiga seperti Pencari Bug menawarkan layanan sumber kerumunan di mana ratusan penguji manusia lepas dari seluruh dunia digunakan untuk menguji situs web dan dibayar ketika mereka menemukan masalah. Pendekatan ini bisa menjadi cara yang relatif hemat biaya untuk menguji aplikasi Anda di ratusan kombinasi perangkat/platform/browser. Itu normal untuk siklus pengujian menghasilkan sekitar 200 masalah yang diangkat. Tantangannya sering kali dalam mengkategorikan dan memprioritaskan masalah sehingga Anda memfokuskan sumber daya Anda untuk menangani yang paling penting. Setiap situs web akan memiliki simpanan masalah tingkat rendah yang terus-menerus yang tidak mungkin diselesaikan.

Pengujian regresi

Pengujian regresi adalah bagian yang sangat penting dari pengembangan yang sedang berlangsung. Ini dirancang untuk menguji apakah ada perubahan pada satu bagian aplikasi yang menyebabkan masalah pada bagian lain. Misalnya, perubahan pada fungsi JavaScript yang digunakan untuk memvalidasi formulir hubungi kami berpotensi memengaruhi formulir yang digunakan dalam proses pembayaran. Karena sifat kompleks dari platform e-niaga apa pun, masalah regresi tidak jarang terjadi sehingga merancang rencana uji regresi yang solid sangat penting untuk memastikan bahwa pengalaman pengguna Anda tidak terpengaruh oleh masalah ini.

UAT

Pengujian Penerimaan Pengguna (UAT) adalah bagian penting dari proyek pengembangan apa pun dan melibatkan klien yang melakukan pengujian platform ujung-ke-ujung penuh sebelum ditayangkan. UAT adalah proses yang paling sering saya lihat di bawah perkiraan. Ini juga merupakan bagian dari proyek yang pertama menderita ketika jadwal ketat. Namun, ini cenderung mengarah pada tingkat kegagalan yang lebih tinggi. Untuk setiap pembuatan situs web baru, kami menyarankan agar setidaknya 2 bulan UAT direncanakan. Situs web e-niaga Anda hanyalah satu bagian dari bisnis perdagangan Anda dan proses ujung-ke-ujung yang melibatkan pencarian, pembayaran, manajemen pesanan, pembayaran, pengiriman, layanan pelanggan, keuangan, dan semua bagian lain dari rantai itu harus diuji.

UAT sering dikacaukan atau digabungkan dengan SIT (System Integration Testing) di mana Anda akan secara khusus menguji integrasi antara beberapa sistem. SIT adalah bagian dari pengujian ujung ke ujung yang memastikan bahwa semua bagian rantai bekerja sama dengan benar.

UAT yang baik melibatkan pembuatan kasus uji dan rencana pengujian. Ini umumnya berbentuk satu set skrip (skrip menjadi serangkaian tugas yang harus dijalankan) yang akan dijalankan oleh penguji manual dan lulus atau gagal tes sesuai dengan hasilnya. Bukan hal yang aneh jika rencana uji UAT ujung ke ujung mencakup lebih dari 500 kasus uji.

A di UAT adalah salah satu alasan mengapa itu sangat penting. Di akhir proses UAT, Anda umumnya akan dianggap telah menerima aplikasi tersebut, jadi penting bagi Anda untuk mengujinya secara menyeluruh untuk memastikan bahwa aplikasi tersebut bekerja persis seperti yang Anda harapkan. Ini tidak berarti bahwa bug yang belum ditemukan tidak akan bergaransi tetapi jika ada fungsionalitas yang tidak berfungsi seperti yang Anda harapkan, ini perlu diambil di UAT. Alasan lain mengapa begitu penting adalah bahwa ini adalah kesempatan terakhir untuk mengambil masalah sebelum ditayangkan. Setiap bug dan masalah cenderung berdampak negatif pada pengalaman pengguna.

UAT membutuhkan banyak usaha atas nama klien, sesuatu yang sering diremehkan. Beberapa klien menggunakan agen pengujian eksternal untuk mendukung mereka selama UAT yang secara signifikan dapat mengurangi risiko proyek di mana klien tidak memiliki tenaga untuk melaksanakan UAT secara efektif.

Pengujian keamanan

Saya terkadang sangat terkejut bagaimana beberapa pengecer gagal melakukan pengujian keamanan dengan cukup serius. Bukan hal yang aneh jika pengecer tidak tahu kapan terakhir kali mereka menjalankan uji penetrasi di platform web mereka. Ini umumnya adalah mereka yang belum terkena serangan cyber (atau belum tahu bahwa mereka telah terkena). Dalam iklim saat ini di mana kejahatan dunia maya terus tumbuh dalam frekuensi dan kecanggihan, dan terutama dengan GDPR di cakrawala di Eropa, pengujian keamanan semakin penting. Semua platform web e-commerce harus diuji penetrasi oleh spesialis pihak ketiga setidaknya setiap tahun tetapi idealnya dua kali setahun. Juga disarankan agar aplikasi Anda dipindai untuk kerentanan menggunakan perangkat lunak khusus seperti Nessus secara teratur. Di Envoy, kami cenderung memindai platform web klien kami setiap minggu untuk memastikan bahwa kerentanan aplikasi diketahui dengan sangat cepat. Setidaknya Anda harus melakukan pemindaian keamanan aplikasi sebelum setiap rilis ke produksi. Tidak ada gunanya menunggu selama 6 bulan hingga uji penetrasi berikutnya ketika Anda telah memperkenalkan kerentanan aplikasi baru.

Pengujian kinerja

Pengujian kinerja umumnya digunakan untuk menentukan berapa banyak lalu lintas, permintaan halaman, pengguna bersamaan, dan volume pesanan yang dapat ditangani situs web Anda. Ini adalah proses yang lebih sulit daripada yang Anda bayangkan karena, untuk menguji secara akurat, Anda perlu meniru perilaku pengguna nyata dan, seperti yang akan Anda ketahui, pengguna nyata melakukan banyak hal berbeda. Hal terbaik yang dapat Anda lakukan adalah meniru perjalanan pengguna utama Anda seperti mencari, menambahkan ke keranjang, dan checkout. Idealnya Anda ingin melakukan pengujian beban pada lingkungan produksi Anda daripada lingkungan pementasan karena akan memberi Anda gambaran yang jauh lebih benar, tetapi ini juga kemungkinan akan membuat platform Anda offline di beberapa titik selama pengujian.

Sebagian besar pengecer cenderung melakukan uji beban setahun sekali, biasanya sebelum periode perdagangan puncak seperti Black Friday atau Natal. Masalah yang dapat disebabkan oleh hal ini adalah, sejak pengujian tahunan terakhir, sejumlah besar perubahan mungkin telah dilakukan pada aplikasi, beberapa di antaranya mungkin memiliki dampak tambahan pada kinerja. Jika uji beban tahunan menunjukkan penurunan kinerja dibandingkan tahun sebelumnya, sangat sulit untuk menentukan perubahan atau perubahan mana selama setahun terakhir yang berkontribusi terhadap penurunan kinerja tersebut. Ini juga mungkin tidak memberi Anda cukup waktu untuk menyelesaikan masalah kinerja sebelum perdagangan puncak dimulai.

Untuk mengatasi ini, disarankan untuk melakukan benchmark kinerja sebelum setiap rilis kode baru. Ini tidak perlu dilakukan pada lingkungan produksi selama setiap pengujian dilakukan pada lingkungan yang sama karena tujuannya adalah untuk menentukan apakah kinerja telah meningkat atau menurun relatif terhadap rilis terakhir. Pendekatan ini memungkinkan tim pengembangan untuk memahami dari mana peningkatan atau penurunan kinerja berasal. Ini, tentu saja, membutuhkan waktu dan oleh karena itu akan meningkatkan waktu dan biaya pengembangan

Meskipun daftar di atas tidak lengkap, Anda dapat melihat bahwa ruang lingkup pengujian dalam pengembangan perangkat lunak bisa sangat besar dan kompleks. Setiap jenis pengujian membutuhkan waktu dan usaha dan Anda tidak boleh hanya berasumsi bahwa itu semua dilakukan sebagai standar tanpa biaya tambahan. Perusahaan dengan fokus kuat pada pengujian akan mengalokasikan hingga 40% dari setiap waktu proyek untuk pengujian yang dapat menjadi jumlah yang sangat mengejutkan. Pengujian yang baik dapat mengurangi risiko proyek dan dapat membayar sendiri dalam jangka panjang karena akan menghasilkan lebih sedikit bug, kinerja yang lebih baik, dan pengalaman keseluruhan yang lebih baik bagi pelanggan Anda.