Bagaimana testing yang benar ?
Dalam pengembangan perangkat lunak, kita membutuhkan sebuah aktifitas
untuk memastikan software yang ada, sudah sesuai perencanaan atau tidak.
Sehingga ketika software tersebut di gunakan oleh user, kita sebagai developer team menjadi confident terhadap kualitasnya.
Dan aktifitas tersebut biasa kita sebut testing. Testing sendiri menurut
Kamus Besar Bahasa Indonesia adalah pengujian (percobaan) untuk mengetahui tingkat kemampuan (pengetahuan, keterampilan seseorang, dan sebagainya).
Oleh karena itu, testing sangatlah penting dan harus sebagai mandatory
untuk pengembangan perangkat lunak.
Namun, jika kita melakukan testing tanpa pattern yang jelas bisa menyebabkan testing kita salah arah dan tidak effektif.
Sehingga kita membutuhkan attitude atau perilaku yang jelas untuk sebagai patokan atau dasar dalam implementasi testing.
Maka dari itu, di sini saya akan menjabarkan, beberapa attitude / sikap yang bisa di jadi kan mindset dasar kita untuk melakukan testing. Dan karena hal itu juga lah, tulisan ini saya beri judul Testitude.
Saya akan membagi poin-poin testitude menjadi 5F dan 2P, sengaja dibagi demikian supaya lebih mudah diingat. Yang secara filosofi F mewakili Fungsi, karena testing sendiri sebenarnya adalah sebuah fungsi dan P mewakili Perilaku atau attitude.
Testitude :
- Find Defect / menemukan kecacatan
Tujuan utama testing adalah menemukan bugs atau defect sebanyak mungkin, agar ketika software di launching di level production, end user tidak di hadapkan dengan berbagai macam bugs yang terjadi. Testing bukan sarana untuk menunjukan bahwa software bebas bugs. Dan testing bukan hanya untuk memastikan positif flow berjalan dengan lancar namun juga untuk memastikan bahwa negatif flow sudah terhandle dengan baik di sebuah software.
Jadi, sewajarnya dalam membuat skenario test, ketika harus menggali lebih dalam kemungkinan kemungkinan yang akan terjadi ketika customer menggunakanya. Baik skenario positif ataupun negatif.
Misal, ketika di hadapkan dengan case login dengan username
dan password. Positif Test Case yang bisa di buat adalah,
a) masukan valid data baik di field username & password.
Negatif test case :
a) masukan inavalid data username, valid data password
b) masukan invalid data password, valid data username
c) masukan invalid data username dan passoword
c) masukan akun yang sudah terblokir
d) masukan invalid data selama 3 kali
dan lain sebagainya.
Dari contoh case diatas, membuktikan bahwa kemungkinan akan lebih banyak negatif test case, daripada positif dalam membangun software. Dan semakin banyak kita membuat negatif test case, semakin kecil juga kemungkinan cacat yang akan terjadi di production.
2. Flock of Defect / pengelompokan kecacatan
Untuk software dengan tingkat kompleksitas rumit, cangkupan besar dan mempunyai banyak modul, penyebaran defect bisa bersumber dari berbagai titik. Namun, terkadang defect defect tersebut bersumber dari 1 atau 2 modul yang besar dan dominan.
Hal itu ada korelasi nya dengan sebuah teori yang bernama Prinsip Pareto, yang menyebutkna bahwa untuk banyak kejadian, sekitar 80% daripada efeknya disebabkan oleh 20% dari penyebabnya.
Jadi terkadang kita bisa mengelompokan fokus testing kita pada modul-modul yang menjadi penyebab defect defect di software muncul.
Misal pada aplikasi e-commerce, terdapat modul transaksi dan modul master merchant. Untuk modul transaksi berkorelasi pada report, settlement dan transaksi itu sendiri yang mencakup berbagai macam metode pembayaran. Sedangkan pada modul master merchant hanya berfokus pada data merchant.
Dengan keadaan seperti itu, kita bisa fokuskan testing kita terlebih dahulu pada modul transaksi, karena adanya bugs di modul transaksi bisa berimpact ke barbagai macam fitur yang ada.
Namun, jangan sampai ketika kita melakukan pengelompokan defect ini, kita mengabaikan modul modul kecil yang lain. Karena bisa jadi defect yang bersumber dari modul lain, tidak termitigasi dengan baik, karena terlalu fokus pada modul yang beresiko tadi.
3. Fast as Possible / dilakukan sedini mungkin
Dalam System Development Life Cycle (SDLC), biasanya ada tahapan yang berurutan dalam pengembangan perangkat lunak. Misal dalam Waterfall, kita mengenal ada tahapan requirement, design, implementation, testing, go life, maintenance.
Dan, biasanya fase testing benar benar di kerjakan ketika fase requirement, design dan implementation selesai di kerjakan.
Dan ketika banyak bugs di temukan dalam fase testing, begitu tidak efektifnya software development kita. Karena akan memakan waktu dan effort untuk bugs tersebut di perbaiki kembali.
Alangkah baiknya, kegiatan testing selalu di kerjakan di setiap fase software development. Ketika fase requirement dan design, team development bisa menganalisa requirement based on document dari stakeholder atau product owner apakah requirement tersebut bisa di impementasikan dengan baik atau tidak. Selanjutnya ketika fase implement pun demikian, seorang developer based on document yang ada bisa melaukan unit testing, untuk memastikan kode yang mereka buat sudah sesuai requirement dan logic yang di inginkan.
Sehingga ketika nanti di fase testing, seorang QA Engineer tidak menemukan terlalu banyak bugs, sehingga bisa mengeksplor hal-hal yang lain, misal stress test atau performance test, bukan hanya functioanl testing saja.
Jadi testing bukan hanya responsibility seorang QA Engineer semata. Tapi merupakan responsibility dari seluruh anggota team. Selain itu, melakukan testing sedini mungkin sangatlah penting di karenakan ada kaitanya dengan cost yang harus di keluarkan setiap kita akan fixing defect tersebut.
4. Full Testing is Imposible / testing secara menyeluruh adalah mustahil
Berkorelasi dengan poin no 1, bahwa testing adalah kegiatan untuk menemukan bugs, bukan untuk memastikan bahwa sistem tersebut zero bugs.
Maka dari itu tidak ada yang bisa memastikan bahwa skenario test yang sudah kita buat sebanyak apapun itu , sudah mencakup seluruh kemungkinan bugs yang ada.
Sehingga kita memang perlu membuat skenario test sebanyak mungkin, tapi
melalukan testing secara menyeluruh adalah sebuah keniscayaan. Karena yang di sebut menyeluruh pun tidak ada yang bisa menilai.
Maka dari itu kita harus memperhitungkan resiko dan prioritas untuk menganalisa skenario test case yang ada. Sehingga test case yang sudah di buat sangatlah efektif.
5. Fault if Not Find Fault / kesalahan jika tidak menemukan kesalahan
Ada kesalahan, jika sebuah sistem tidak di temukan kesalahan dalam fase development. Karena sebenarnya bukan sistem tidak ada kesalahan, tapi kesalahan tersebut belum di temukan.
Hal tersebut terjadi bisa jadi dikarenakan skenario test nya yang belum menyeluruh atau developer yang salah dalam mengimplementasikan requirement.
Selain itu, walupun tahapan development sudah di kerjakan dengan baik. Pembahasan requirement suda dilakukan dengan baik, unit testing sudah di kerjakan oleh developer.
Namun, ketika kita belum mengetaui bagaimana respon user ketika menggunakan aplikasi tersebut. Bisa jadi, aplikasi yang oleh team development dirasa sudah baik, belum tentu baik untuk user.
Selain itu, terkadang sebagai seorang software developer sudah merasa sangat bangga terhadap apa yang sudah mereka buat, jadi cukup puas dengan apa yang sudah di kerjakan tanpa memikirkan lebih detail skenario kondisi yang lain.
Maka dari itu, sangan memungkinkan adanya missed di dalam logic code mereka atau secara user interface nya.
Maka dari itu peran QA Engineer sangat penting disini, karena sebagai representatif seorang user yg akan menggunakan. Lebih baik bugs di ketahui oleh QA Engineer atau team development daripada oleh user.
Jadi apa yang sudah di jelaskan di poin 1 yakni testing adalah kegiatan mencari bugs, maka jika seorang QA Engineer belum berhasil menemukan bugs, belum bisa dikatakan kerjanya baik.
6. Pendent Context / bergantung pada konteks
Kegitan pengujian juga harus di lakukan berdasarkan konteks sistem yang sedang di hadapi. Ini akan berpengaruh terhadap test scenario yang di buat.
Misal kita sedang menguji sistem e-commerce,berarti kita harus make sure proses pembayaranya berjalan dengan baik. Apakah beberapa payment method sudah bisa di gunakan.
Misal di payment method virtual number, skenario yang bisa di buat misalnya :
a. bagaimana jika virtual number tersebut sudah sukses di bayar, lalu di triger pembayaran kembali
b. bagaimana jika virtual number tersebut sudah expired, lalu di triger pembayaran
c. bagaimana jika virtual number tersebut gagal dalam proses pembayaran, lalu di triger ulang
dan lain sebagainya.
Dari contoh test case diatas kita ada concern dari sisi keamanan proses pembayaran di e-commerce tersebut.
Dan resiko yang di timbulkan dalam proses pembayaran cukup tinggi, sehingga di anggap sangat perlu untuk melakukan testing.
Ini berkorelasi dengan poin 4 (full testing is imposible), semakin tinggi resiko yang bisa menimmbukan kerugian, semakin perlu kita untuk meluangkan waktu untuk melakukan testing.
7. Pesticide Paradox / paradox pestisida
Jika di persawahan terdapat hama, dan kita sebagai petani menyemprot pestisida ke sawah tersebut, mungkin untuk awal awal hama tersbut bereaksi. Namun, lama kelamaan hama tersebut akan kebal jika di semprotkan dengan jenis pestisida yang sama secara terus menerus . Itulah konsep dari Pesticide Paradox.
Begitu juga denga sistem, menjalankan serangkaian tes yang sama secara terus-menerus tidak akan terus menemukan cacat baru.
Hal ini sangat beresiko, maka dari itu kita harus menyempatkan untuk mengupgrade atau menambah skenario test yang ada, agar menemukan bugs baru yang belum muncul.
Sehingga regression test kita semakin powerful, karena mencakup
skenario test existing dan yang baru tersebut.
Sumber inspirasi dari tulisan saya diatas adalah sebuah buku yang berjudul “Software Testing An ISTQB-ISEB Foundation Guide Second Edition” by Brian Hambling (Editor), Peter Morgan, Angelina Samaroo,
Geoff Thompson and Peter Williams dan juga pengalaman pribadi sebagai QA Engineer.
