Software testing

Dalam rekayasa perangkat lunak banyak sekali hal yang harus diperhatikan untuk memproduksi sebuah
sistem. Semakin besar atau semakin kompleks sebuah sistem akan semakin banyak hal yang harus
diperhatikan dan diperhitungkan, seperti apakah sudah sesuai dengan requirements, bagaimana jika di
masa yang akan datang dilakukan pengembangan, berapa besar biaya yang diperlukan (biaya
perancangan, produksi, dan maintenance) dan kualitas produk.

Untuk kualitas dari sebuah software, ada beberapa atribut yang penting dan semua atribut itu digunakan
untuk mengukur dan menguji kualitas software. Macam-macam atribut itu seperti: atribut fungsional,
atribut operasional, atribut bisnis, atribut usability, dan atribut struktural. Software dikatakan mempunyai
kualitas bagus ketika waktu diuji software tersebut memenuhi keseluruhan atribut. Software itu terbukti
kebenenarannya ketika informasi yang diberikan sesuai dan tidak kurang sedikitpun, bagaimana software
itu berjalan atau memproses suatu input dalam segala kondisi, bagaimana keamanan data rahasia pada
sistem (mudah diserang oleh pihak luar) sehingga perlu adanya user authorization, dan mudah tidaknya
pengembangan software tersebut untuk masa yang akan datang.

Selain semua itu, penting juga memperhatikan fault, error, dan fault dari sebuah program. Fault masih
bisa ditoleransi karena kesalahan ini masih memungkinkan program berjalan dengan memproses input
dan menghasilkan output yang sesuai meskipun caranya berbeda dari yang seharusnya. Tetapi hal
tersebut akan berdampak pada baris program selanjutnya sehingga program tersebut dikatakan error
karena tidak semua input akan menghasilkan output yang sesuai jika prosesnya berbeda dari yang
seharusnya. Terakhir yaitu failure, kondisi dimana eksekusi program awal melanggar spesifikasi. Meskipun
tidak semua kesalahan menghasilkan kegagalan, ada beberapa cara untuk mengatasi kesalahan tersebut:
fault avoidance, fault removal, dan fault tolerance.

Mili, Ali and Tchier, Fairouz, “Software Testing Concepts and Operations”, Wiley, 2015.

El-Hadary, Hassan and El-Kassas Sherif, “Capturing Security Requirements for Software Systems”, Journal
of advanced research 5, 463-472, 2015.

Software engineering
Ada dua tipe dalam dependability dan security requirements:

1. Functional requirements, yang menentukan fasilitas pemeriksaan dan pemulihan yang harus
dimasukkan dalam sistem dan fitur yang memberikan perlindungan terhadap kegagalan sistem
dan serangan eksternal.

2. Non-functional requirements, yang menentukan keandalan dan ketersediaan yang dibutuhkan

sistem.

Dependability dan security requirements dapat dianggap sebagai protection requirement. Ini
menentukan bagaimana sistem harus melindungi dirinya dari kesalahan internal, menghentikan
kegagalan sistem yang menyebabkan kerusakan pada lingkungannya, menghentikan kecelakaan atau
serangan dari lingkungan sistem yang merusak sistem, dan memfasilitasi pemulihan jika terjadi kegagalan.

Proses umum risk-driven specification melibatkan pemahaman risiko yang dihadapi oleh sistem,
menemukan akar penyebabnya, dan menghasilkan persyaratan untuk mengelola risiko-risiko ini. Tahapan
dalam proses ini adalah:

■ Risk identification, Potensi risiko ke sistem diidentifikasi.

■ Risk analysis and classification, Setiap risiko dianggap terpisah (serius dan tidak masuk akal).

■ Risk decomposition, Setiap risiko dianalisis untuk menemukan akar penyebab potensial dari risiko
tersebut.

■ Risk reduction, Proposal untuk cara-cara di mana risiko yang teridentifikasi dapat dikurangi atau
dihapuskan dibuat.

Manajemen risiko telah diadopsi oleh organisasi untuk menghindari atau mengurangi terjadinya peristiwa
yang tidak diinginkan yang mungkin mempengaruhi proyek. Risiko pada proyek perangkat lunak
mengancam kelayakannya. Dengan kata lain, kapan pun risiko menjadi nyata, mereka dapat sangat
mempengaruhi pelaksanaan proyek atau bahkan mengarah pada pembatalannya. Kategori risiko yang
menonjol adalah risiko proyek (yang merenungkan risiko pengembangan), karena dapat mempengaruhi
jadwal proyek atau sumber daya yang diperlukan untuk pengembangan perangkat lunak (misalnya
perputaran pengembang).

Evaluasi risiko biasanya dilakukan menggunakan model kualitatif [3]. Namun demikian, model kuantitatif
dapat membantu manajer proyek untuk memperkirakan terjadinya risiko (mis. Perkiraan probabilitas),
dan, dengan demikian, manajer dapat melakukan perencanaan yang lebih baik untuk menghindari risiko
yang melekat dalam proyek perangkat lunak.

Sommerville, Ian, “Software Engineering 9th Edition” , Addison-Wesley, 2011.

Melo, Alexsandro, et al, “Dependability Approach for Evaluating Software Development Risks”, The
Institution of Engineering and Technology, vol 9, 2015.