Sistem Informasi

Manajemen Kekayaan Negara

Pengajar: Emma Suryani
Minggu ke-13
20 Januari 2022
Minggu-13

Pokok bahasan: Pengujian Sistem Informasi

a) Terminologi pengujian sistem informasi

b) Strategi pengujian sistem informasi
c) Jenis pengujian sistem informasi
d) Gambaran umum strategi dan pelaksanaan pengujian sistem informasi di DJKN
Pengujian Perangkat Lunak (1)

Pengujian/Testing adalah proses dan kegiatan untuk menemukan kesalahan (errors, bugs, defects) yang
merupakan tinjauan akhir dari spesifikasi, desain, dan code. Tujuan dari pengujian adalah untuk menjamin
bahwa semua elemen dari aplikasi dengan benar, berfungsi seperti yang diharapkan, dan memenuhi kriteria
kinerja.

Pengujian/Testing Perangkat Lunak adalah proses menjalankan program atau sistem dengan tujuan
menemukan kesalahan. Kegiatan ini melibatkan aktivitas apa pun yang ditujukan untuk mengevaluasi
atribut atau kemampuan program atau sistem dan menentukan apakah memenuhi hasil yang diperlukan
atau belum.

Tidak seperti kebanyakan sistem/produk fisik, pada perangkat lunak, sebagian besar kesalahan/cacat pada
perangkat lunak adalah karena kesalahan desain, bukan cacat manufaktur. Perangkat lunak tidak
mengalami korosi, keausan, umumnya tidak akan berubah sampai user melakukan upgrade, atau sampai
usang. Jadi setelah perangkat lunak dikirimkan/ di release, cacat desain, atau bug, akan terkubur dan tetap
tersembunyi hingga aktivasi, hingga user mengoperasikan sistem dan hingga aktivitas user mentrigger
error tersebut.
Pengujian Perangkat Lunak (2)

Bug perangkat lunak hampir selalu ada di modul perangkat lunak apa pun dalam ukuran yang moderate: bukan
karena programmer/ tim developer ceroboh atau tidak bertanggung jawab, tetapi karena kompleksitas perangkat
lunak umumnya tidak mudah dikontrol, dan manusia hanya memiliki kemampuan terbatas untuk mengelola
kompleksitas. Dan untuk setiap sistem yang kompleks, cacat desain tidak pernah dapat sepenuhnya
dikesampingkan/dikecualikan.

Komplikasi pengujian seringkali berkaitan dengan sifat dinamis dari program perangkat lunak. Biasanya tim penguji
sudah menyiapkan skenario pengujian. Dan misal pada masa sebelum testing, dari tim developer sudah mengubah
code atau mendeteksi error lalu mengubah code yang menyebabkan scenario menjadi tidak relevan lagi, maka tim
testing perlu memikirkan scenario testing terhadap perubahan yang dilakukan tersebut. Karena pada dasarnya
setiap perubahan juga memiliki potensi munculnya error.

Terlepas dari keterbatasan-keterbatasan, pengujian merupakan bagian integral dalam pengembangan perangkat
lunak. Pengujian digunakan secara luas di setiap fase dalam siklus pengembangan perangkat lunak. Biasanya,
secara ideal, lebih dari 50% persen waktu pengembangan dihabiskan untuk pengujian. Pengujian biasanya dilakukan
untuk tujuan berikut:
1. Untuk meningkatkan kualitas
2. Untuk Verifikasi & Validasi (V&V)
3. Untuk estimasi keandalan
Tujuan Pengujian (1)

1. Untuk meningkatkan kualitas

Untuk produk perangkat lunak yang digunakan dalam lingkup kritikal, seperti software untuk pesawat, rumah
sakit, maka error atau bug dapat berakibat fatal jika luput dari pengujian dan perbaikan. Bug dalam sistem
kritis telah menyebabkan kecelakaan pesawat, memungkinkan misi pesawat ulang-alik menjadi salah target,
menghentikan perdagangan di pasar saham, dan banyak lagi scenario buruk yang disebabkan karena error
perangkat lunak. Kualitas dan keandalan perangkat lunak seringkali adalah masalah hidup dan mati.

Kualitas berarti kesesuaian dengan persyaratan desain yang ditentukan: mampu beroperasi dengan benar,
memenuhi persyaratan kualitas minimum, yaitu melakukan seperti yang dipersyaratkan dalam keadaan
tertentu.

Debugging, adalah kegiatan untuk menguji case dalam scope kecil terhadap fungsi perangkat lunak untuk
mengetahui cacat desain oleh programmer. Debugging bertujuan untuk menemukan error dan memperbaiki
dan debugging terjadi dalam fase pemrograman.
Tujuan Pengujian (2)

2. Untuk Verifikasi & Validasi (V&V)

Tujuan penting dari pengujian adalah verifikasi dan validasi. Pengujian dapat berfungsi sebagai metrik. Sehingga
tester/penguji dapat menarik kesimpulan bahwa suatu perangkat lunak berfungsi dalam situasi tertentu, atau tidak.
Penguji juga dapat membandingkan kualitas produk apakah beroperasi sama saat dijalankan pada spesifikasi yang
berbeda saat dilakukan pengujian yang sama.

Penguji tidak dapat menguji kualitas secara langsung namun mereka bisa menguji faktor-faktor apa saja yang
membuat suatu produk berkualitas. Kualitas memiliki tiga set faktor: fungsionalitas, teknik, dan kemampuan
beradaptasi. Ketiga set faktor ini dapat dianggap sebagai dimensi dalam ruang kualitas perangkat lunak. Setiap
dimensi dapat dipecah menjadi faktor dan pertimbangan komponennya pada tingkat yang lebih detail.

Functionality(exterior quality) Engineering(interior quality) Adaptability(future quality)

Correctness Efficiency Flexibility

Reliability Testability Reusability

Usability Documentation Maintainability

Integrity Structure
Tujuan Pengujian (3)

Pengujian yang baik menyediakan cara pengukuran untuk faktor-faktor tersebut secara relevan. Faktor-faktor
tersebut berbeda dari aplikasi ke aplikasi. Setiap sistem yang kritikal (mempertaruhkan nyawa manusia) harus
sangat menekankan faktor keandalan dan integritas (reliability and integrity). Dalam sistem bisnis, faktor kegunaan
dan pemeliharaan (usability and maintainability) merupakan faktor kunci. Agar proses Pengujian berjalan efektif, tim
harus mampu mengukur setiap faktor dengan pengukuran yang relevan sehingga kesempatan untuk mencapai/
mendapatkan hasil berupa produk berkualitas menjadi nyata dan mungkin dicapai.

Clean test atau positive test

Pengujian dengan tujuan untuk memvalidasi produk dapat bekerja dengan benar. Kekurangan dari positive test
adalah pengujian hanya dapat memvalidasi bahwa perangkat lunak berfungsi untuk kasus uji yang ditentukan
sebelumnya. Jumlah tes yang telah ditentukan tersebut cenderung terbatas dan tidak dapat memvalidasi bahwa
perangkat lunak dapat berfungsi untuk semua situasi. Dan, hanya membutuhkan satu scenario tes dengan hasil yang
gagal sudah cukup untuk menunjukkan/disimpulkan bahwa perangkat lunak tidak berfungsi.

Dirty test, atau negative test

Pengujian yang bertujuan merusak/membuat error perangkat lunak, atau menunjukkan bahwa produk tidak
berfungsi. Perangkat lunak harus memiliki kemampuan exception handling yang cukup untuk menahan
scenario-scenario dirty test.
Tujuan Pengujian (4)

3. Untuk estimasi keandalan

Keandalan perangkat lunak memiliki hubungan penting dengan banyak aspek, termasuk struktur dari
perangkat lunak itu sendiri, dan banyaknya jumlah pengujian yang telah dilakukan. Berdasarkan profil
operasional (perkiraan frekuensi relatif penggunaan berbagai input ke program), pengujian dapat berfungsi
sebagai metode pengambilan sampel statistik untuk mendapatkan data kegagalan untuk melakukan
estimasi keandalan.
Test Level

1. Target Pengujian
a. Pengujian unit
b. Tes integrasi
c. Pengujian sistem

2. Tujuan Pengujian
a. Tes kualifikasi
b. Pengujian instalasi
c. Pengujian alfa dan beta
d. Pencapaian dan evaluasi keandalan
e. Tes kebenaran
f. Pengujian kinerja
g. Pengujian keamanan
Test Level (1)

1. Target Pengujian
Pengujian perangkat lunak biasanya dilakukan pada tingkat yang berbeda sepanjang proses pengembangan
dan pemeliharaan. Artinya, target pengujian dapat bervariasi: satu modul, sekelompok modul-modul (yang
saling terkait berdasarkan tujuan, penggunaan, perilaku, atau struktur), atau keseluruhan sistem. Tiga tahap
pengujian dapat dibedakan secara konseptual, yaitu Unit, Integrasi, dan Sistem.

a. Pengujian unit
Pengujian unit memverifikasi fungsi dengan melakukan isolasi bagian perangkat lunak yang dapat diuji
secara terpisah. Tergantung pada konteksnya, unit bisa berupa subprogram individu atau komponen yang
lebih besar yang terbuat dari unit-unit yang saling terkait. Unit pengujian didefinisikan lebih tepat dalam
Standar IEEE untuk Pengujian Unit Perangkat Lunak (IEEE1008-87), yang juga menjelaskan pendekatan
terpadu untuk pengujian unit yang sistematis dan terdokumentasi. Biasanya, pengujian unit terjadi dengan
akses ke kode yang sedang diuji dan dengan dukungan alat debugging, dan seringkali melibatkan
programmer yang menulis kode.
Test Level (2)

b. Tes integrasi
Pengujian integrasi adalah proses memverifikasi interaksi antara komponen perangkat lunak. Strategi
pengujian integrasi antara lain, seperti top-down atau bottom-up, digunakan untuk perangkat lunak
tradisional yang terstruktur secara hierarkis. Strategi integrasi sistematis modern lebih berorientasi pada
arsitektur, yang menyiratkan pengintegrasian komponen atau subsistem perangkat lunak berdasarkan atas
fungsionalitasnya.

c. Pengujian sistem
Pengujian sistem berkaitan dengan perilaku sistem secara keseluruhan. Mayoritas kegagalan fungsional
seharusnya sudah diidentifikasi selama pengujian unit dan integrasi. Pengujian sistem biasanya dilakukan
untuk membandingkan sistem dengan persyaratan sistem non-fungsional, seperti keamanan, kecepatan,
akurasi, dan keandalan. Antarmuka eksternal ke aplikasi lain, utilitas, perangkat keras, atau lingkungan
operasi juga dievaluasi pada tingkat ini.
Test Level (3)

2. Tujuan Pengujian
Tujuan pengujian sebaiknya dituangkan secara eksplisit dan kuantitatif sehingga memungkinkan kontrol
terhadap proses dan skenario pengujian.

Pengujian dapat ditujukan untuk memverifikasi properti yang berbeda. Kasus uji (test case) dapat dirancang
untuk memeriksa bahwa spesifikasi fungsional telah diterapkan dengan benar, yaitu meliputi pengujian
kesesuaian, pengujian kebenaran, atau pengujian fungsionalitas. Namun, beberapa properti nonfungsional
lainnya dapat diuji juga, termasuk kinerja, keandalan, dan kegunaan, dan lain-lain.

Tujuan penting lainnya untuk pengujian termasuk (tetapi tidak terbatas pada) pengukuran keandalan,
evaluasi kegunaan, dan penerimaan, yang menggunakan pendekatannya berbeda. Perhatikan bahwa tujuan
pengujian bervariasi dengan target pengujian: artinya secara umum, tujuan akan berbeda tergantung pada
tingkat pengujian yang dijalankan.
Test Level (4)

Beberapa tujuan pengujian antara lain

a. Tes kualifikasi
Pengujian kualifikasi memeriksa perilaku sistem terhadap persyaratan yang ditentukan di user requirement,
di mana user menjalankan program dan menentukan tugas-tugas untuk memeriksa bahwa persyaratan
mereka telah dipenuhi. Aktivitas pengujian ini mungkin atau mungkin tidak melibatkan pengembang sistem.
b. Pengujian instalasi
Biasanya setelah selesai pengujian penerimaan perangkat lunak (software acceptance testing), perangkat
lunak dapat diverifikasi pada saat instalasi di target environment yang telah ditentukan. Pengujian instalasi
dapat dilihat sebagai pengujian sistem yang dilakukan sekali lagi untuk memenuhi persyaratan konfigurasi
perangkat keras.
c. Pengujian alfa dan beta
Sebelum perangkat lunak dirilis, seringkali perangkat lunak diberikan kepada sekelompok kecil pengguna
potensial yang mampu mewakili untuk percobaan penggunaan, baik internal (pengujian alfa) atau eksternal
(pengujian beta). Pengguna ini melaporkan masalah dengan produk. Penggunaan alfa dan beta sering kali
tidak terkontrol sehingga mampu memberikan feedback yang tidak terduga yang membantu penyempurnaan
produk.
Test Level (5)

d. Pencapaian dan evaluasi keandalan

Selain membantu mengidentifikasi kesalahan, pengujian juga merupakan sarana untuk meningkatkan
keandalan.

Keandalan perangkat lunak mengacu pada kemungkinan operasi sistem yang bebas dari error. Pengujian
perangkat lunak (biasanya pengujian black box) dapat digunakan untuk mendapatkan data kegagalan, dan
sehingga data tersebut dapat digunakan untuk estimasi lebih lanjut untuk menganalisis dan memperkirakan
keandalan saat ini dan memprediksi keandalan di masa mendatang. Oleh karena itu, berdasarkan estimasi,
pengembang dapat memutuskan apakah akan merilis perangkat lunak, dan pengguna dapat memutuskan
apakah akan mengadopsi dan menggunakan perangkat lunak tersebut. Risiko menggunakan perangkat
lunak juga dapat dinilai berdasarkan informasi keandalan.

Stress testing, atau load testing, sering digunakan untuk menguji seluruh sistem dengan cara menguji
perangkat lunak dengan beban di luar batas yang ditentukan. Stres test meliputi pengujian kelelahan sumber
daya, ledakan aktivitas, dan beban tinggi yang berkelanjutan.
Test Level (6)

e. Tes kebenaran
Kebenaran adalah persyaratan minimum perangkat lunak, yang merupakan tujuan penting dari pengujian. Pengujian kebenaran
akan membutuhkan beberapa jenis pengukuran, untuk memberi tahu perilaku yang benar dan yang salah. Penguji mungkin atau
mungkin tidak mengetahui detail bagian dalam modul perangkat lunak yang sedang diuji, mis. aliran kontrol, aliran data, dll.

Black box testing

Black box testing adalah metode pengujian di mana data pengujian diturunkan dari persyaratan fungsional yang ditentukan tanpa
memperhatikan struktur program akhir. Ini juga disebut pengujian berbasis data, input/output, atau berbasis persyaratan. Black
box testing juga terutama mengacu pada pengujian fungsional - metode pengujian yang menekankan pada pelaksanaan fungsi
dan pemeriksaan data input dan output. Penguji memperlakukan perangkat lunak yang diuji sebagai kotak hitam - hanya input,
output, dan spesifikasi yang terlihat, dan fungsionalitasnya ditentukan dengan mengamati output ke input yang sesuai. Dalam
pengujian, berbagai input dilakukan dan output dibandingkan dengan spesifikasi untuk memvalidasi kebenarannya. Semua test
case/ scenario diturunkan dari spesifikasi. Pengujian ini tidak mempertimbangkan detail implementasi kode.

Pengujian kotak putih

White box testing menguji struktur dan aliran kerja perangkat lunak yang dapat dilihat oleh penguji. Rencana pengujian dibuat
sesuai dengan detail implementasi perangkat lunak, seperti bahasa pemrograman, logika, dan gaya. Test case diturunkan dari
struktur program. Pengujian kotak putih juga disebut pengujian glass box, pengujian berbasis logika, atau pengujian berbasis
desain.
Test Level (7)

f. Pengujian kinerja
Tidak semua sistem perangkat lunak memiliki spesifikasi kinerja secara eksplisit. Namun setiap sistem akan
memiliki persyaratan kinerja implisit. Perangkat lunak idealnya tidak menghabiskan waktu dan resource yang
tidak terbatas untuk mengeksekusi suatu fungsi. "Performance Bug" terkadang digunakan untuk merujuk
pada masalah desain dalam perangkat lunak yang menyebabkan kinerja sistem menurun.

g. Pengujian keamanan
Cacat dalam perangkat lunak dapat dimanfaatkan oleh penyusup untuk membuka lubang keamanan.
Dengan perkembangan Internet, masalah keamanan perangkat lunak merupakan hal yang makin kritis.

Banyak aplikasi dan layanan perangkat lunak mengintegrasikan langkah-langkah keamanan terhadap
serangan dan ancaman. Tujuan pengujian keamanan sistem ini termasuk mengidentifikasi dan menghapus
kelemahan perangkat lunak yang berpotensi menyebabkan kelemahan keamanan, dan memvalidasi
efektivitas langkah-langkah keamanan. Dalam pengujian, simulasi serangan keamanan dapat dilakukan
untuk menemukan kerentanan sistem.
Otomatisasi pengujian

Pengujian perangkat lunak dapat mengeluarkan sumber daya besar dan bisa sangat mahal. Otomatisasi
adalah cara yang baik untuk menghemat waktu dan biaya. Alat dan teknik pengujian perangkat lunak
biasanya memiliki kekurangan dalam penerapan dan skalabilitas. Untuk mengotomatisasi proses, tim harus
memiliki beberapa cara untuk menguji spesifikasi sistem, dan menghasilkan test case untuk menguji target.
Hingga saat ini belum ada sistem pengujian otomatis secara utuh. Sejumlah besar pengujian tetap
membutuhkan intervensi manusia. Tingkat otomatisasi biasanya pada tingkat script.
Kapan pengujian dapat dihentikan?

Pengujian memiliki potensi keberlangsungan yang panjang dan cenderung tidak ada selesainya. Namun tim
penguji tidak dapat menguji sampai semua cacat digali dan dihilangkan - karena hal tersebut tidak mungkin.
Pada titik tertentu, tim penguji harus menghentikan pengujian dan mengirimkan perangkat lunak untuk dirilis.
Pertanyaannya adalah kapan.

Secara realistis, pengujian merupakan bagian dari SDLC yang memiliki constraint/ batasan antara lain
anggaran, waktu, dan kualitas. Oleh karena batasan tersebut, seringkali pengujian dihentikan ketika
keandalan telah dapat memenuhi persyaratan yang ditetapkan.
Teknik Pengujian

Salah satu tujuan pengujian adalah untuk mendapatkan sebanyak mungkin potensi kegagalan. Beragam
teknik telah dikembangkan untuk melakukan pengujian. Prinsip utama yang mendasari teknik tersebut
adalah proses yang sistematik yang mungkin dapat mengidentifikasi perilaku program yang cukup mewakili;
misalnya, mempertimbangkan subkelas dari domain input, skenario, status, dan aliran data.

Jenis-jenis teknik pengujian

a. Berdasarkan intuisi dan pengalaman developer
b. Teknik berbasis spesifikasi/ Specification-based techniques
c. Teknik berbasis kode/ Code-based techniques
d. Teknik berbasis kesalahan/ Fault-based techniques
e. Teknik berbasis penggunaan/ Usage-based techniques
f. Memilih dan menggabungkan teknik
Teknik Pengujian (1)

a. Berdasarkan intuisi dan pengalaman developer

Pengujian ad hoc
Scenario tes datang dari keterampilan, intuisi, dan pengalaman developer untuk program serupa. Pengujian
ad hoc dapat berguna untuk mengidentifikasi tes khusus yang tidak mudah ditangkap oleh teknik formal.

Pengujian eksplorasi
Pengujian eksplorasi didefinisikan sebagai pembelajaran simultan, desain pengujian, dan pelaksanaan
pengujian; yaitu, pengujian tidak didefinisikan sebelumnya dalam rencana pengujian yang ditetapkan, tetapi
dirancang, dijalankan, dan dimodifikasi secara dinamis. Efektivitas pengujian eksplorasi bergantung pada
pengetahuan developer perangkat lunak, yang dapat diturunkan dari berbagai sumber: perilaku produk yang
diamati selama pengujian, familiaritas terhadap aplikasi, platform, proses kegagalan, jenis kemungkinan
kesalahan dan kegagalan, risiko yang terkait dengan produk tertentu, dan sebagainya.
Teknik Pengujian (2)

b. Teknik berbasis spesifikasi/ Specification-based techniques

Equivalence partitioning
Domain input dibagi menjadi kumpulan subset atau kelas yang setara, yang dianggap setara menurut
hubungan tertentu, dan satu set perwakilan tes diambil dari setiap kelas.

Boundary-value analysis
Kasus uji dipilih berdasar batas domain input variabel, karena banyak kesalahan cenderung terkonsentrasi di
dekat nilai input yang ekstrem. Perpanjangan dari teknik ini adalah pengujian ketahanan, di mana test case
juga dipilih di luar domain input variabel, untuk menguji ketahanan program terhadap input yang tidak
diharapkan atau salah.

Testing from formal specifications

Menguji berdasar spesifikasi formal untuk test case fungsionalitas yang sudah ditetapkan dalam user
requirements.

Random testing
Pengujian dihasilkan murni secara acak, dengan menguji input secara random.
Teknik Pengujian (3)

c. Teknik berbasis kode/ Code-based techniques

Control-flow-based criteria
Kriteria berbasis aliran kontrol ditujukan untuk mencakup semua pernyataan kode program atau blok
pernyataan dalam suatu program, atau kombinasi dari pernyataan-pernyataan kode program. Beberapa
kriteria seperti condition/decision coverage.
Kriteria berbasis aliran kontrol yang paling kuat adalah path testing, yang bertujuan untuk mengeksekusi
path/jalur dalam aliran kontrol masuk-ke-keluar dalam diagram alir suatu program.

Data flow-based criteria

Dalam pengujian berbasis aliran data, diagram alir kontrol dianotasi dengan informasi tentang bagaimana
variabel program didefinisikan, digunakan, dan dimatikan.

Reference models for code-based testing

Teknik pengujian berbasis kode menguji struktur kontrol program yang secara grafis diwakili dalam diagram
alur yang dihasilkan saat tahap desain sistem.
Teknik Pengujian (4)

d. Teknik berbasis kesalahan/ Fault-based techniques

Teknik pengujian berbasis kesalahan menguji sistem untuk mengungkapkan kategori kesalahan yang
mungkin atau yang telah ditentukan sebelumnya.

Error guessing
Dalam teknik error guessing, kasus uji dirancang khusus oleh developer perangkat lunak yang mencoba
mencari tahu kesalahan yang masuk akal dalam program tertentu. Developer memiliki keterampilan ini dari
pengalaman kesalahan yang ditemukan dalam proyek sebelumnya, serta keahlian engineering perangkat
lunak yang dimiliki dalam berkarir.

Mutation testing
Mutan seringkali dikaitkan dengan perubahahan/modifikasi. Mutation testing merupakan testing yang
dilakukan dengan cara dimodifikasi perilaku atau logic dari program yang sedang diuji, seperti merubah
sintaksis atau logic. Mutation testing juga dapat dikategorikan sebagai teknik berbasis kode.
Teknik Pengujian (5)

e. Teknik berbasis penggunaan/ Usage-based techniques

Operational profile
Dalam pengujian untuk evaluasi keandalan, lingkungan pengujian harus mampu mewakili/meniru lingkungan
operasional perangkat lunak sedekat mungkin. Hal ini untuk memastikan keandalan perangkat lunak di masa
depan nantinya saat digunakan secara nyata oleh pengguna.

f. Memilih dan menggabungkan teknik

Functional and structural
Teknik pengujian berbasis spesifikasi dan berbasis kode sering dianalogikan dengan pengujian fungsional
vs. struktural. Kombinasi dari teknik yang memiliki basis tersebut akan mampu meningkatkan kualitas hasil
uji.

Deterministic vs. random

Test case dapat dipilih dengan cara deterministik, dari teknik-teknik yang ada, atau diambil secara acak
untuk kebutuhan pengujian reliabilitas sistem.
TEST PROCESS

Konsep pengujian, strategi, teknik, dan ukuran perlu diintegrasikan ke dalam proses yang ditetapkan dan dikendalikan yang dijalankan
oleh tim penguji. Proses pengujian mulai dari perencanaan pengujian hingga evaluasi hasil pengujian dilakukan untuk memberikan
jaminan bahwa tujuan pengujian akan tercapai dengan biaya yang efektif.