Salut! Minggu depan, kelas akan dimulai dalam aliran baru kursus
spesialis-QA , sehubungan dengan ini kami akan membagikan kepada Anda materi yang bermanfaat yang diterjemahkan secara khusus untuk siswa kursus. Ayo pergi.
Ringkasan: Banyak penguji hanya melakukan pengujian fungsional, tanpa melampaui itu. Tetapi pengujian perangkat lunak adalah pencarian informasi kualitas produk yang dapat membantu pemangku kepentingan membuat keputusan yang tepat, dan ada banyak cara untuk menemukan informasi di luar pengujian fungsional. Artikel ini menjelaskan enam metode yang dapat membantu Anda meningkatkan efektivitas proyek Anda.
Pengujian fungsional tetap valid bahkan dengan implementasi otomatisasi yang luas. Banyak produk perangkat lunak memerlukan pengujian manual untuk memverifikasi dan memeriksa semua fungsi dan interaksinya.
Sayangnya, banyak penguji hanya melakukan pengujian fungsional, tanpa melampaui itu. Alasan untuk ini mungkin karena kurangnya keterampilan, ketidakmampuan untuk menulis kode, takut akan hal yang tidak diketahui, atau pengetahuan yang terbatas tentang lanskap pengujian.
Mengutip Sam Kaner, pengujian perangkat lunak adalah pencarian informasi kualitas produk yang dapat membantu pemangku kepentingan membuat keputusan yang tepat.
Selain pengujian fungsional, ada cara lain untuk menemukan informasi. Dalam artikel ini, kita akan melihat enam cara yang telah membantu saya meningkatkan efektivitas proyek saya.
1. Periksa semua pesan
Penguji biasanya mempelajari dokumen persyaratan, mendiskusikannya dengan pemangku kepentingan, dan kemudian mengembangkan tes. Tetapi kita semua tahu bahwa ada skenario yang tidak tercakup oleh kasus uji yang muncul saat menggunakan produk. Sebagian besar dari mereka dilindungi oleh pengembang, tetapi beberapa mungkin mengejutkan semua orang.
Tim pengembang dapat membantu dengan menyusun daftar semua pesan yang ada dalam produk, termasuk pesan kesalahan, pesan informasi, dan peringatan. Ini juga akan berfungsi sebagai tes cakupan pengujian yang baik dalam hal pesan yang ditampilkan oleh sistem. Jika penguji belum pernah melihat pesan yang akan ditampilkan kepada pengguna, maka mereka harus kembali dan memahami dalam hal apa pesan ini akan ditampilkan.
Suatu hari, setelah menerima daftar pesan, saya segera memperhatikan bahwa beberapa di antaranya benar-benar baru bagi tim penguji. Setelah mempelajari, kami menyadari bahwa mereka berasal dari kode usang dan, meskipun kami tidak lagi mendukung fungsi ini, mereka berada dalam kode sumber. Kode ini seharusnya sudah dihapus karena tidak lagi mempengaruhi produk.
Bergantung pada arsitektur aplikasi, menyiapkan daftar seperti itu bisa mudah atau sulit. Tetapi jika Anda berpikir latihan ini akan membantu tim penguji menguji lebih baik, maka para pemangku kepentingan harus setuju untuk menemukan cara untuk mempersiapkan daftar pesan. Coba pendekatan ini dan periksa seberapa baik Anda mengetahui produk Anda dan apa cakupan tes Anda.
2. Lakukan Ulasan UX
Banyak tim produk merilis versi pertama dengan sangat cepat, dan kemudian berpikir untuk menstabilkan kode setelah mencapai sejumlah pelanggan atau sesuai dengan indikator lain. Rilis cepat awal biasanya diutamakan daripada melakukan rilis yang tepat. Tetapi karena semakin banyak pengembang yang terlibat, ada kemungkinan inkonsistensi yang tinggi.
Dalam proses menstabilkan produk, fokuslah untuk menyingkirkan segala inkonsistensi UX. Lakukan tinjauan UX dari seluruh aplikasi. Mulai dengan ikon, teks, tindakan, fungsi, dan utas utama. Gunakan karakter dan curah pendapat untuk ulasan UX lengkap. Pikirkan juga tentang titik sentuh untuk pengguna. Bagaimana Anda menghadapinya? Apakah ada yang menyesatkan dalam aplikasi Anda? Ada latihan di
https://cantunsee.space yang akan membantu Anda menguji kemampuan UI Anda.
Ketika kami membuat tinjauan UX dari salah satu produk yang digunakan secara aktif di perusahaan kami, kami menemukan pola inkonsistensi dan dapat dengan mudah mengaitkannya dengan berbagai keputusan yang kami buat sebagai sebuah tim, merilis fitur dengan terburu-buru, mengembangkan outsourcing ke tim lain, merilis fitur dengan plugin yang ketinggalan zaman dan sebagainya.
3. Melakukan analisis pesaing
Sangat disayangkan bahwa banyak penguji bekerja dalam isolasi dan tidak tahu tentang produk-produk dari perusahaan lain. Periksa pesaing Anda dengan informasi periklanan, webinar, demo, berita di media dan blog, dan kemudian tuliskan fitur dan analisis kekuatan dan kelemahan produk Anda.
Tanyakan tim produk Anda jika Anda dapat mengakses penawaran perusahaan lain dan bertanya bagaimana Anda dapat membantu analisis pesaing. Selain menganalisis fungsionalitas, pertimbangkan juga kriteria seperti kegunaan, kinerja, keamanan, dan ketersediaan. Berguna untuk membuat tabel komparatif “fungsionalitas - kriteria evaluasi” dengan poin-poin yang dinilai oleh produk.
4. Jelajahi alat
Alat bagus untuk mereka yang tahu cara menggunakannya secara efektif. Mereka dapat menghemat banyak uang dan waktu dan sangat melengkapi pengujian. Sebagai seorang penguji, Anda harus memiliki pengetahuan luas tentang sistem yang digunakan dan proses yang digunakan.
Selain mengotomatiskan pemeriksaan fungsional dan dengan cepat membuat data uji, ada juga alat untuk mendeteksi pola dalam log, untuk mereplikasi data dari produksi, untuk mensimulasikan fungsi, untuk merekam tindakan pengguna dan untuk menanggapi peristiwa berdasarkan aturan. Juga, untuk mencapai sebagian besar tujuan akhir, tidak perlu membeli alat milik. Ini bisa berupa program sederhana dengan ratusan baris yang mengambil tangkapan layar aplikasi berdasarkan pemicu dalam log.
Terkadang tidak jelas bagi semua orang seberapa berguna ini atau alat lain sampai Anda mendemonstrasikan manfaat apa yang dapat mereka berikan, jadi pelajari kemampuan mereka.
5. Pikirkan tentang risiko yang bisa menjadi "mimpi buruk"
Seperti yang dijelaskan dalam buku Elizabeth Hendrickson, Explore It! Kurangi Risiko dan Tingkatkan Keyakinan dengan Pengujian Eksplorasi ", salah satu cara untuk mencegah bencana adalah dengan memikirkan kemungkinan tajuk berita buruk yang terkait dengan produk atau proyek Anda dan menguji risiko-risiko ini. Penguji pandai memikirkan kemungkinan skenario kecelakaan, dan keterampilan ini dapat membantu tim pengembangan menghindari kesalahan saat menulis kode, menghemat waktu dan upaya di muka.
Ini bisa menjadi permainan yang menyenangkan untuk dimainkan dengan banyak pemangku kepentingan, dan itu akan memberikan keyakinan kepada semua orang bahwa risiko akan diatasi. Ketika kami memainkan permainan ini dengan salah satu tim kami, beberapa berita utama yang diciptakan oleh dukungan teknis dan manajemen memberi kami sudut pandang yang berbeda - tanpanya, kami tidak akan pernah memikirkan tes ini.
6. Habiskan waktu dengan dukungan pelanggan
Karena terus menggunakan produk mereka, tim pengujian dapat menjadi bias. Dan apa yang tampaknya penguji sebagai perilaku yang diharapkan, pada kenyataannya, mungkin merepotkan bagi pengguna. Anda dapat memeriksa panggilan dukungan untuk mencari tahu tentang rasa sakit pelanggan dan masalah menggunakan aplikasi Anda.
Setelah kami mengeluh tentang fitur salah satu produk kami dan kenyamanan penggunaannya, tetapi ini tidak diterima sebagai bug. Meskipun ketika beberapa klien mulai berurusan dengan masalah kegunaan yang serupa, ini diperbaiki dengan prioritas tinggi. Kejadian ini telah memberi kami otoritas besar dalam organisasi. Dan kemudian kami diundang untuk mengambil bagian dalam berbagai diskusi tentang solusi kegunaan.
Suara pelanggan adalah data nyata yang harus Anda perhatikan, dan Anda dapat menggunakan data ini untuk berkontribusi pada pengembangan produk Anda.
Keenam metode ini mudah dikombinasikan dengan pengujian fungsional dan sangat bermanfaat. Cobalah mereka dalam pekerjaan pengujian Anda dan beri tahu kami tentang pengalaman Anda.
Itu saja. Kami menantikan komentar Anda dan mengundang Anda ke hari terbuka, yang akan diadakan pada tanggal 21 Juni.