Bab 10: Test Case

Dalam melakukan testing, seorang QA tidak akan terlepas dari yang namanya test case. Di mana test case merupakan sebuah dokumentasi yang berisi kumpulan skenario dan langkah-langkah yang akan digunakan untuk mengetes sebuah software. Standarisasi test case juga dibahas dalam ISO/IEC/IEEE 29119 yang dirilis pada tahun 2013. Tujuan dari dibuatnya test case adalah untuk mempermudah seorang QA dalam melakukan pengetesan, sehingga area pengetesan bisa terfokus dan tidak melebar.

A. Komponen Test Case

Pada prakteknya, format penulisan test case bisa berbeda-beda tergantung kebutuhan dari perusahaan. Di mana secara umum sebuah test case harus memiliki beberapa informasi berikut ini. Untuk memperjelas maksud dari setiap komponen test case, kita akan menggunakan studi kasus login di Facebook. Adapun informasi yang dibutuhkan adalah sebagai berikut.

1. Description

Informasi ini dibutuhkan untuk mendeskripsikan skenario apa yang akan dites. Contoh description untuk kasus ini adalah “User login ke Facebook lewat mobile web”.

2. Type

Secara alur pengetesan, test case dibagi ke dalam 2 tipe skenario, yaitu Positif & Negatif. Skenario Positif adalah skenario yang dibuat sesuai dengan bagaimana software seharusnya bekerja, seperti contoh skenario “User login ke Facebook lewat mobile web”. Sedangkan Skenario Negatif adalah sebuah skenario “what if” yang berlawanan dengan flow utama suatu software, di mana jika dites diharapkan akan menghasilkan kegagalan. Contohnya adalah “User login ke Facebook lewat mobile web tanpa mengisi password”.

3. Pre Requisite

Point ini merupakan kondisi prasyarat yang harus dipenuhi sebelum mulai menjalani testing pada skenario terkait. Contoh pre requisite yang bisa digunakan adalah “User sudah berada di halaman mobile.facebook.com”, “User sudah memiliki akun Facebook”, dan informasi yang yang dapat melengkapi.

4. Test Step

Test step merupakan langkah-langkah yang menjadi acuan QA untuk mengeksekusi pengetesan. Contohnya: 1. Isi email > 2. Isi password > Klik tombol “Login”.

5. Test Data

Informasi ini diperlukan jika memang terdapat data yang harus diinput untuk mendapatkan hasil tes yang diinginkan. Contoh test data yang digunakan dalam kasus ini adalah email & password.

6. Expectation

Merupakan hasil akhir tes yang diharapkan. Contoh dari case ini adalah “User berhasil login ke Facebook dan diarahkan ke halaman Beranda”.

7. Actual Result

Point ini merupakan informasi pamungkas yang berisikan hasil real dari pengetesan, apakah sudah sesuai dengan yang diharapkan atau terjadi kesalahan pada skenario tersebut.

8. Test Status

Informasi ini diperlukan sebagai penanda apakah skenario yang telah dites lolos uji, atau terjadi hal di luar dugaan. Jika skenario lolos uji, maka bisa diberikan status “Pass”. Selain lolos uji yang normal, ada juga status lolos uji bersyarat, yang biasanya diakibatkan faktor-faktor yang tidak memungkinkan untuk dilakukan di environment testing. Jenis lolos uji ini biasa disebut dengan “Pass with Note”. Jika terjadi bug, maka bisa menggunakan status “Failed”. Jika pada suatu skenario tidak dapat dites akibat terdampak bug di skenario yang lain, maka bisa diberikan status “Blocked”. Jika skenario yang sudah ditulis tidak ditemukan pada software yang akan dites, maka bisa menggunakan status “N/A (Not Available)”.

Umumnya, test case disusun dalam format tabel. Jika ditulis dalam 2 contoh skenario, maka kurang lebih akan menjadi seperti ini:

Untuk membuat test case, sebenarnya sudah cukup jika menggunakan tool sederhana seperti Microsoft Excel atu Google Sheets. Namun, saat ini sudah ada online test case management tools yang bisa jadi pilihan, seperti TestRail, QASE, dll.

B. Prinsip Dalam Membuat Test Case

Dalam membuat test case, ada beberapa hal yang perlu diperhatikan agar menghasilkan test case yang efektif dan berkualitas, antara lain sebagai berikut:

1. Test case harus dibuat sesimpel mungkin.

Penggunaan bahasa yang ringkas, terstruktur dan konsisten akan membantu QA untuk melakukan pengetesan lebih cepat, karena test case lebih mudah dipahami.

2. Jangan mudah membuat asumsi.

Ketika membuat test case, diusahakan untuk menuliskan ekspektasi yang sesuai dengan dokumen requirement, dan tidak berusaha membuat penafsiran sendiri ketika menemukan skenario yang masih kurang jelas. Segera diskusikan dengan Project Manager dan tim Developer untuk mendapatkan ekspektasi yang pasti.

3. Test case harus berorientasi kepada perilaku end user.

Menempatkan diri seorang QA sebagai layaknya seorang end user adalah hal yang penting. Hal ini bertujuan untuk mencegah penilaian secara subjektif terhadap hasil testing.

4. Usahakan untuk tidak membuat skenario yang berulang dalam test case.

Setiap skenario yang ada harus bersifat unik untuk mencegah pengulangan test yang tidak perlu.

5. Test case harus dibuat reusable.

Artinya, jika skenario yang sama dites berulang kali terhadap sebuah software oleh tester yang berbeda, maka akan selalu menghasilkan result yang sama, selama belum ada perubahan yang diterapkan pada software tersebut.

6. Pastikan test case dipahami oleh semua orang.

Pada akhirnya, test case tidak hanya akan dibaca oleh QA, tapi juga akan dibaca oleh Product Manager, Developer, atau bahkan client yang memiliki project tersebut. Karena test case juga bisa difungsikan sebagai dokumen guideline, maka penting untuk menggunakan bahasa yang dapat dipahami oleh semua orang, bahkan orang awam sekalipun.

7. Pembuatan test case harus meng-cover seluruh fitur yang akan dites.

Hal ini bertujuan untuk mencegah terjadinya bug yang terlewat setelah software tersebut dirilis ke publik.

8. Lakukan review bersama tim setelah membuat test case.

Daya pikir manusia yang terbatas membuat kemungkinan adanya kesalahan atau skenario yang terlewat bisa saja terjadi. Boleh jadi ada skenario yang terpikir oleh Project Manager, namun belum kita cantumkan ke dalam test case.