Menentukan kasus pengujian dan prioritas

Tentukan hal yang akan diuji, tentukan kasus pengujian, dan tentukan prioritas.

Ramona Schwering

Di postingan sebelumnya, Anda telah mempelajari strategi pengujian, jumlah pengujian yang diperlukan untuk menguji aplikasi, dan cara menemukan yang paling sesuai untuk mendapatkan hasil yang paling andal dengan mempertimbangkan resource Anda. Namun, hal ini hanya memberi kita gambaran tentang seberapa banyak yang harus diuji. Anda masih perlu menentukan dengan tepat apa yang akan diuji. Tiga kriteria berikut dapat membantu Anda memahami apa yang diharapkan dalam pengujian dan melihat jenis pengujian serta tingkat detail yang paling sesuai:

1. Perhatikan jalur yang diinginkan. Ini adalah cerita pengguna paling umum atau utama dari aplikasi Anda, tempat pengguna akan melihat error dengan sangat cepat.
2. Tentukan tingkat detail dengan cermat. Pelajari lebih lanjut jika kasus penggunaan Anda rentan atau jika error akan menyebabkan kerusakan yang tinggi.
3. Prioritaskan pengujian tingkat rendah, seperti pengujian unit dan integrasi, daripada pengujian menyeluruh tingkat tinggi jika memungkinkan.

Bagian lainnya dalam artikel ini akan membahas kriteria ini, dan penerapannya saat Anda menentukan kasus pengujian.

Apa yang dimaksud dengan kasus pengujian?

Dalam pengembangan software, kasus pengujian adalah urutan tindakan atau situasi yang dirancang untuk mengonfirmasi efektivitas program atau aplikasi software. Kasus pengujian bertujuan untuk memastikan bahwa software beroperasi sesuai rencana dan semua fitur dan fungsinya berfungsi dengan benar. Penguji atau developer software biasanya membuat kasus pengujian ini untuk menjamin bahwa software memenuhi persyaratan dan spesifikasi yang ditentukan.

Saat kasus pengujian dijalankan, software akan melakukan serangkaian pemeriksaan untuk memastikan software menghasilkan hasil yang diinginkan. Saat melakukannya, pengujian akan memenuhi tugas berikut:

• Verifikasi. Proses pemeriksaan software secara menyeluruh untuk memastikan software berfungsi tanpa error. Menentukan apakah produk yang dibuat memenuhi semua persyaratan non-fungsional yang diperlukan dan berhasil mencapai tujuan yang diinginkan sangatlah penting. Pertanyaan yang dijawab adalah: “Apakah kita membangun produk dengan benar?”
• Validasi. Proses untuk memastikan bahwa produk software memenuhi standar yang diperlukan atau persyaratan tingkat tinggi. Pengujian ini melibatkan pemeriksaan apakah produk yang sebenarnya sesuai dengan produk yang diharapkan. Pada dasarnya, kita menjawab pertanyaan: “Apakah kita membuat produk yang tepat untuk persyaratan pengguna?”

Misalkan program gagal memberikan hasil yang diharapkan. Dalam hal ini, kasus pengujian akan menjadi pembawa pesan—sehingga melaporkan hasil yang tidak berhasil, dan developer atau penguji harus menyelidiki masalah tersebut dan menemukan solusinya. Anggap pemeriksaan dan tindakan sebagai jalur yang diikuti komputer, terlepas dari jenis pengujiannya. Grup data input atau kondisi yang digunakan untuk pemeriksaan disebut "class ekuivalensi". Keduanya akan mendapatkan perilaku atau hasil yang serupa dari sistem yang sedang diuji. Jalur spesifik yang dieksekusi di dalam pengujian dapat bervariasi, tetapi harus cocok dengan aktivitas dan pernyataan yang dilakukan dalam pengujian Anda.

Jalur pengujian: Jenis kasus pengujian yang umum

Dalam pengembangan software, kasus pengujian adalah skenario eksekusi kode yang diharapkan dan diuji perilaku tertentunya. Biasanya, ada tiga skenario untuk membentuk kasus pengujian.

Yang pertama adalah yang paling dikenal, yang mungkin sudah Anda gunakan. Ini adalah jalur sukses, juga dikenal sebagai “skenario hari bahagia” atau “jalur emas”. Jalur ini menentukan kasus penggunaan yang paling umum dari fitur, aplikasi, atau perubahan Anda—cara fitur, aplikasi, atau perubahan tersebut seharusnya berfungsi bagi pelanggan.

Jalur pengujian kedua yang paling penting untuk dibahas dalam kasus pengujian Anda sering kali dihilangkan karena tidak nyaman—seperti yang mungkin tersirat dari namanya. Ini adalah “jalur yang menakutkan” atau, dengan kata lain, pengujian negatif. Jalur ini menargetkan skenario yang menyebabkan kode berperilaku tidak semestinya atau memasuki status error. Menguji skenario ini sangat penting jika Anda memiliki kasus penggunaan yang sangat rentan dan menimbulkan risiko tinggi bagi pemangku kepentingan atau pengguna.

Ada beberapa jalur lain yang mungkin ingin Anda ketahui dan pertimbangkan untuk digunakan, tetapi biasanya jalur tersebut jarang digunakan. Tabel berikut merangkumnya:

Ada beberapa metode untuk mengategorikan jalur tersebut. Dua pendekatan umum adalah:

• Partisi ekuivalensi. Metode pengujian yang mengategorikan kasus pengujian ke dalam grup atau partisi dan, sebagai hasilnya, membantu membuat class ekuivalensi. Hal ini didasarkan pada gagasan bahwa jika satu kasus pengujian dalam partisi menemukan cacat, kasus pengujian lain dalam partisi yang sama kemungkinan akan mengungkapkan cacat serupa. Karena semua input dalam class ekuivalensi tertentu harus menunjukkan perilaku yang sama, Anda dapat mengurangi jumlah kasus pengujian. Pelajari partisi ekuivalensi lebih lanjut.
• Analisis batas. Metode pengujian, yang juga dikenal sebagai analisis nilai batas, yang memeriksa batas atau ekstrem nilai input untuk menemukan potensi masalah atau error yang mungkin muncul pada batas kemampuan atau batasan sistem.

Praktik terbaik: Menulis kasus pengujian

Kasus pengujian klasik yang ditulis oleh penguji akan berisi data spesifik untuk membantu Anda memahami konten pengujian yang ingin dilakukan dan, tentu saja, menjalankan pengujian. Penguji biasa akan mendokumentasikan upaya pengujian mereka dalam tabel. Ada dua pola yang dapat kita gunakan pada tahap ini, yang membantu kita menyusun kasus pengujian dan nantinya, pengujian itu sendiri:

• Pola Arrange, act, assert. Pola pengujian "arrange, act, assert" (juga dikenal sebagai "AAA" atau "Triple A") adalah cara mengatur pengujian ke dalam tiga langkah yang berbeda: mengatur pengujian, lalu melakukan pengujian, dan terakhir, menarik kesimpulan.
• Pola Given, when, then. Pola ini mirip dengan pola AAA, tetapi memiliki beberapa akar dalam pengembangan berbasis perilaku.

Artikel mendatang akan membahas pola ini secara lebih mendetail, segera setelah kita membahas struktur pengujian itu sendiri. Jika Anda ingin mempelajari pola ini lebih dalam pada tahap ini, lihat dua artikel berikut: Arrange-Act-Assert: Pola untuk menulis pengujian yang baik dan Given-When-Then.

Berdasarkan semua pembelajaran dari artikel ini, tabel berikut merangkum contoh klasik:

Dalam pengujian otomatis, Anda tidak perlu mendokumentasikan semua kasus pengujian ini dengan cara yang diperlukan penguji, meskipun hal ini sangat membantu. Anda dapat menemukan semua informasi ini dalam pengujian jika Anda memperhatikannya. Jadi, mari kita terjemahkan kasus pengujian klasik ini menjadi pengujian otomatis.