Tentukan hal yang akan diuji, tentukan kasus pengujian, dan prioritaskan.
Dalam postingan sebelumnya, Anda telah mempelajari strategi pengujian, jumlah pengujian yang diperlukan untuk menguji aplikasi, dan cara menemukan yang paling cocok untuk mendapatkan keyakinan besar dengan hasil sambil mempertimbangkan resource Anda. Namun, hal ini hanya memberi kita gambaran tentang seberapa banyak yang harus diuji. Anda masih perlu menentukan dengan tepat apa yang harus diuji. Tiga kriteria berikut dapat berguna dalam memahami apa yang diharapkan dalam pengujian dan melihat jenis dan tingkat detail pengujian apa yang paling cocok:
- Jaga jalan bahagia Anda. Ini adalah cerita pengguna paling umum atau utama dari aplikasi Anda, tempat pengguna akan melihat error dengan sangat cepat.
- Tentukan tingkat detail dengan cermat. Jelaskan lebih detail jika kasus penggunaan Anda rentan atau di mana error akan menyebabkan kerusakan yang tinggi.
- Prioritaskan pengujian tingkat rendah, seperti pengujian unit dan integrasi, daripada pengujian menyeluruh tingkat tinggi jika memungkinkan.
Bagian selanjutnya dari artikel ini membahas kriteria ini, dan bagaimana kriteria ini diterapkan saat Anda menentukan kasus pengujian.
Apa yang dimaksud dengan kasus pengujian?
Dalam pengembangan software, kasus pengujian adalah serangkaian tindakan atau keadaan yang dirancang untuk mengonfirmasi keefektifan program atau aplikasi software. Kasus pengujian bertujuan untuk memastikan bahwa perangkat lunak beroperasi sesuai rencana dan bahwa semua fitur dan fungsinya berjalan 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, perangkat lunak melakukan serangkaian pemeriksaan untuk memastikannya memberikan hasil yang diinginkan. Saat melakukannya, pengujian akan memenuhi tugas-tugas berikut:
- Verifikasi. Proses pemeriksaan perangkat lunak secara menyeluruh untuk memastikan bahwa perangkat lunak berfungsi tanpa kesalahan. Menentukan apakah produk yang dibuat memenuhi semua persyaratan non-fungsional yang diperlukan dan berhasil mencapai tujuan yang dimaksudkan sangatlah penting. Pertanyaan yang dijawab adalah: “Apakah kita membuat produk dengan benar?”
- Validasi. Proses untuk memastikan bahwa produk software memenuhi standar yang diperlukan atau persyaratan tingkat tinggi. Tahap ini melibatkan pemeriksaan apakah produk yang sebenarnya sesuai dengan produk yang diharapkan. Pada dasarnya, kita menjawab pertanyaan: “Apakah kita membuat produk yang tepat untuk kebutuhan pengguna?”
Misalkan program gagal memberikan hasil yang diharapkan. Dalam hal ini, kasus pengujian adalah pengirim pesan—sehingga melaporkan hasil yang gagal, dan developer atau penguji harus menyelidiki masalah dan menemukan solusi. Anggap pemeriksaan dan tindakan sebagai jalur yang diikuti komputer, apa pun jenis pengujiannya. Grup data input atau kondisi yang digunakan untuk pemeriksaan disebut "class kesetaraan". Pengujian tersebut akan mendapatkan perilaku atau hasil yang serupa dari sistem yang sedang diuji. Jalur spesifik yang dijalankan 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 untuk perilaku tertentu. Biasanya, ada tiga skenario untuk membentuk kasus pengujian.
Yang pertama adalah yang paling terkenal, yang mungkin sudah Anda gunakan. Ini adalah happy path, juga dikenal sebagai “skenario hari bahagia” atau “golden path”. Pendekatan ini menentukan kasus penggunaan paling umum untuk fitur, aplikasi, atau perubahan Anda—bagaimana cara tersebut berfungsi bagi pelanggan.
Jalur pengujian paling krusial kedua yang harus dibahas dalam kasus pengujian Anda sering diabaikan karena terasa tidak nyaman—seperti namanya. Ini adalah “jalur menakutkan” atau, dengan kata lain, pengujian negatif. Jalur ini menargetkan skenario yang menyebabkan kode tidak berfungsi atau memasuki status error. Pengujian 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 itu jarang digunakan. Tabel berikut meringkasnya:
| Jalur pengujian | Penjelasan |
|---|---|
| Jalan dengan marah | Hal ini akan mengarah ke error, tetapi merupakan hal yang diharapkan; misalnya, jika Anda ingin memastikan penanganan error berfungsi dengan benar. |
| Jalur tunggakan | Jalur ini menangani skenario terkait keamanan yang perlu dipenuhi aplikasi Anda. |
| Jalur terpencil | Jalur yang menguji skenario dalam aplikasi Anda tidak mendapatkan cukup data untuk berfungsi, misalnya, menguji nilai null. |
| Jalur yang terlupakan | Menguji perilaku aplikasi dengan resource yang tidak mencukupi, misalnya, memicu kehilangan data. |
| Jalur yang tidak pasti | Pengujian dengan pengguna yang mencoba melakukan tindakan atau mengikuti cerita pengguna dalam aplikasi Anda, tetapi belum menyelesaikan alur kerja tersebut. Hal ini dapat menjadi kasus, misalnya, saat pengguna menyela alur kerja mereka. |
| Greedy path | Mencoba menguji menggunakan input atau data dalam jumlah besar. |
| Jalur yang penuh tekanan | Mencoba membebani aplikasi dengan cara apa pun yang diperlukan hingga aplikasi tidak lagi berfungsi (serupa dengan pengujian beban). |
Ada beberapa metode untuk mengategorikan jalur tersebut. Dua pendekatan yang umum adalah:
- Partisi kesetaraan. Metode pengujian yang mengategorikan kasus pengujian ke dalam grup atau partisi, sehingga membantu membuat class ekuivalensi. Hal ini didasarkan pada gagasan bahwa jika satu kasus pengujian dalam sebuah partisi menemukan kecacatan, kasus pengujian lain dalam partisi yang sama kemungkinan akan menunjukkan kecacatan yang serupa. Karena semua input dalam class kesetaraan tertentu harus menunjukkan perilaku yang identik, Anda dapat mengurangi jumlah kasus pengujian. Pelajari partisi ekuivalensi lebih lanjut.
- Analisis batasan. Metode pengujian, 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 tertentu untuk membantu Anda memahami konten pengujian yang ingin dilakukan dan, tentu saja, menjalankan pengujian. Seorang penguji biasa akan mendokumentasikan upaya pengujian mereka dalam sebuah tabel. Ada dua pola yang dapat kita gunakan pada tahap ini, membantu kita menyusun kasus pengujian dan nantinya, pengujian itu sendiri juga:
- Pola Atur, bertindak, nyatakan. Pola pengujian "atur, bertindak, tegaskan" (juga dikenal sebagai "AAA" atau "Tiga A") adalah cara mengatur pengujian ke dalam tiga langkah yang berbeda: mengatur pengujian, kemudian melakukan pengujian, dan yang terakhir, menarik kesimpulan.
- Diberikan, jika, maka. Pola ini mirip dengan pola AAA tetapi memiliki beberapa akar dalam pengembangan yang didorong perilaku.
Artikel mendatang akan membahas detail lebih lanjut tentang pola-pola ini, segera setelah kami membahas struktur pengujian itu sendiri. Jika Anda ingin mempelajari lebih dalam pola-pola ini pada tahap ini, lihat dua artikel ini: Arrange-Act-Assert: A pattern for write good testing dan Providen-When-That.
Berdasarkan semua pembelajaran dari artikel ini, tabel berikut merangkum sebuah contoh klasik:
| Informasi | Penjelasan |
|---|---|
| Prasyarat | Semua yang perlu dilakukan sebelum menulis pengujian. |
| Objek yang sedang diuji | Apa yang perlu diverifikasi? |
| Data input | Variabel dan nilainya. |
| Langkah-langkah yang akan dijalankan | Semua hal yang akan Anda lakukan untuk membuat pengujian menjadi nyata: semua tindakan atau interaksi yang Anda lakukan dalam pengujian. |
| Hasil yang diharapkan | Apa yang harus terjadi dan ekspektasi mana yang harus dipenuhi. |
| Hasil sebenarnya | Apa yang sebenarnya terjadi. |
Dalam pengujian otomatis, Anda tidak perlu mendokumentasikan semua kasus pengujian ini dengan cara yang diperlukan oleh penguji, meskipun hal ini tidak diragukan lagi sangat membantu. Anda dapat menemukan semua informasi ini dalam pengujian jika Anda memperhatikan. Jadi, mari kita terjemahkan kasus pengujian klasik ini menjadi pengujian otomatis.
| Informasi | Terjemahan ke otomatisasi pengujian |
|---|---|
| Prasyarat | Semua hal yang Anda perlukan, mengatur pengujian, dan memikirkan apa yang diberikan untuk mewujudkan skenario pengujian Anda. |
| Objek yang sedang diuji | "Objek" ini bisa berupa berbagai hal: aplikasi, alur, unit, atau komponen yang sedang diuji. |
| Data input | Nilai parameter. |
| Langkah-langkah yang akan dijalankan | Semua tindakan dan perintah yang dieksekusi dalam pengujian Anda, hal-hal yang Anda tindak lanjuti, dan mencari tahu apa yang terjadi jika Anda melakukan hal-hal tertentu. |
| Hasil yang diharapkan | Pernyataan yang Anda gunakan untuk memvalidasi aplikasi, hal-hal yang Anda nyatakan dalam aplikasi. |
| Hasil sebenarnya | Hasil pengujian otomatis Anda. |