Contoh LAPORAN PENGUJIAN IMPLEMENTASI

LAPORAN PENGUJIAN IMPLEMENTASI
PADA SISTEM INFORMASI PENGARSIPAN SURAT PADA

SDN 1 KARANGKLESEM
Disusun Oleh :
Kelompok 1 :
1. Mathias Blasius Boliona (201901018)
2. Adrianus Ardi (201901001)
3. Maria Lusia Bengang (201901008)
Dosen Pengampu :
Endang Setyawati, M.Kom.
SISTEM INFORMASI
SEKOLAH TINGGI ILMU KOMPUTER YOS SUDARSO

PURWOKERTO
2022
A. Latar Belakang
Salah satu lembaga pendidikan yang perlu menerapkan teknologi informasi
adalah SDN 1 Karangklesem. Di SDN 1 Karangklesem, prosedur yang diterapkan
pada pengarsipan surat dimulai dari pembuatan, penerimaan, penyimpanan atau
pendokumentasian surat masuk dan surat keluar dan keluar hanya berupa penulisan
pada buku besar dan untuk penyimpanannya masih dalam bentuk hardcopy. Selain itu
pada pencarian dokumen lama juga mengalami kesulitan, sebab harus membuka
terlebih dahulu data-data lama dan mencarinya satu persatu. Begitu juga dengan
pelaporan surat masuk dan surat keluar dan surat keluar dalam periode waktu tertentu,
juga proses disposisi surat. Semua kegiatan-kegiatan diatas masih dilakukan secara
manual atau belum menerapkan sistem informasi yang lebih memadai. Dan hal itu
sangat mempengaruhi kerja admin, karena harus mencatatat semuanya satu per satu
pada buku besar tersebut, dan harus membuat struktur laporan surat masuk dan surat
keluar dan surat keluar tesebut.
Penggunaan arsip di SDN 1 Karangklesem masih menggunakan arsip kertas,
sehingga hal ini menyebabkan banyaknya volume arsip yang bisa menimbulkan
masalah yang terkait dengan tempat penyimpanan, biaya pemeliharaan, tenaga
pengurus, fasilitas ataupun faktor lain yang bisa menyebabkan kerusakan pada arsip
tersebut.
Sistem pengolahan arsip yang baik adalah apabila ketika arsip diperlukan
dapat ditemukan dengan mudah dan cepat. Oleh karena itu kualitas sebuah arsip yang
baik sangat dibutuhkan di SDN 1 Karangklesem. Karena dilihat dari aktivitas
pengarsipan yang selama ini dilakukan, secara keseluruhan masih manual dan hal itu
sangat rentan terhadap kesalahan yang mungkin akan terjadi.
Umumnya penyimpanan arsip secara konvensional tidak dapat menyimpan
untuk jangka waktu yang lama, sebab penyimpanan secara konvesional dapat
menyebabkan penumpukan arsip dan kerusakan akibat tergerus waktu. Sehingga
penyimpanan secara konvensional tidaklah begitu efektif dan efisien. Dan seiring era
teknologi yang berkembang, memanfaatkan teknologi berbasis website
memungkinkan penyimpanan arsip surat bisa dilakukan dengan mudah, akurat dan
tidak hilang. Penyimpanan arsip tersebut bisa berupa file atau softcopy sehingga
memungkinkan kemudahan dan kenyamanan, dalam hal pencarian dan tidak rusak
dimakan waktu.
B. PIECES
Pieces adalah sebuah kerangka untuk mengidentifikasi masalah, harus
dilakukan analisis terhadap kinerja, informasi, ekonomi, keamanan aplikasi, efisiensi
dan pelayanan pengguna sistem.
No Jenis Analisis Kelemahan Sistem yang Sistem yang Dibuat

. Berjalan
1. Kinerja Pegawai tata usaha masih Proses pencatatan
harus melakukan pencatatan pengarsipan surat masuk
pengarsipan surat masuk dan dan surat keluar dan surat
surat keluar dan surat keluar keluar sudah berbasis
secara manual. online dengan
menggunakan sistem.
2. Information Pencarian arsip surat masih Dengan menggunakan
membutuhkan waktu yang sistem ini, terdapat
lama karena pengarsipan informasi yang jelas,
dilakukan secara manual. akurat dan tertata
sehingga memudahkan
user untuk melihat dan
memperoleh data secara
detail.
3. Economic Dalam penyimpanan arsip Dengan menggunakan
surat menggunakan ruangan sistem, pengarsipan surat
khusus dan memakan biaya dikelola secara otomatis
tambahan untuk tempat oleh sistem
penyimpanan arsip surat, serta memungkinkan
terjadinya penumpukan arsip. penyimpanan
arsip surat bisa dilakukan
dengan mudah, akurat dan
tidak hilang.
4. Keamanan Keamanan pengarsipan surat Dengan adanya fitur login
yang kurang dimana pada sistem ini, akses
pengaksesan arsip surat masih yang diberikan menjadi
bisa diperoleh semua pegawai. terbatas dan disesuaikan
dengan kebutuhan dan hak
akses tiap user.
5. Efisien Proses pencatatan laporan Dengan adanya system
surat masuk dan surat keluar ini, proses pencatatan
dan surat keluar yang masih laporan surat masuk dan
manual sehingga surat keluar dan surat
membutuhkan waktu lama keluar menjadi lebih
yang menyebabkan kurang efisien sehingga data yang
akuratnya perolehan dan diperoleh lebih cepat,
perincian data. akurat dan terperinci.
6. Pelayanan Untuk pengarsipan surat Dengan menggunakan
masuk dan surat keluar dan sistem ini, proses
surat keluar serta laporan pertukaran data antar
pengarsipan surat masih harus bagian tata usaha dengan
tatap muka antar bagian tata kepala sekolah menjadi
usaha dan kepala sekolah lebih akurat dan tidak
hingga memakan waktu. memakan waktu.
C. Analisis Sistem
Analisis sistem memiliki tujuan untuk mempelajari prosedur yang sedang berjalan
sekarang dan kebutuhan atau keinginan dari orang yang akan menggunakan aplikasi
atau program yang akan dikembangkan ini. Tujuan dari perancangan sistem ini sceara
garis besar adalah untuk menghasilkan bentuk perancangan yang dapat memenuhi
kebutuhan akan penyelesaian masalah secara tepat dan benar.
1. Kebutuhan Fungsional
Kebutuhan fungsional merupakan pernyataan pelayanan sistem yang harus
disediakan, bagaimana sistem bereaksi pada input tertentu dan bagaimana perilaku
sistem pada situasi tertentu. Kebutuhan fungsional yang digunakan pada sistem
informasi pengarsipan surat ini adalah :
 Fasilitas untuk mengelola data pengguna.
 Fasilitas untuk mengelola data surat masuk dan surat keluar dan surat
keluar
 Fasilitas untuk mengelola data laporan arsip surat masuk dan surat keluar
dan surat keluar.
2. Kebutuhan Non Fungsional

Kebutuhan non-fungsional merupakan batasan layanan atau fungsi yang
ditawarkan sistem seperti batasan waktu, batasan pengembangan proses,
standarisasi, dan sebagainya. Kebutuhan non-fungsional yang digunakan pada
sistem informasi pengarsipan surat ini adalah :
 Operasional – Keamanan
Penggunaan username dan password dalam form login untuk membedakan
tipe user termasuk hak akses masing-masing.
 Interface / Antar muka
Antar muka pemakai atau user interface adalah bagian penguhubung
antara program sistem informasi dengan pemakai. Kebutuhan terhadap
antar muka yang diinginkan sebaik mungkin bersifat user friendly, artinya
pengguna dapat menggunakan perangkat lunak yang dibuat dengan mudah
dan senyaman mungkin untuk mendapatkan suatu informasi yang
diinginkan oleh pengguna tersebut. Kebutuhan antar muka (interface)
untuk suatu aplikasi yang dibuat didapatkan dari hasil observasi dari
lingkungan dimana sistem akan dibangun.
D. Kualitas Software
1. McCall’s Triangle of Quality
Metode McCall merupakan salah satu model yang menjelaskan kualitas perangkat
lunak. Model faktor kualitas software, dikemukakan oleh McCall, terdiri dari 11
faktor dan mengklasifikasikan semua kebutuhan perangkat lunak ke dalam 11
faktor kualitas. Kesebelas faktor tersebut dibagi ke dalam 3 kategori terlihat pada
gambar dibawah ini:
1.1 Product Operation
Product operation adalah sifat operasional sebuah software yang berkaitan
dengan hal-hal teknis dalam pengembangan software tersebut yang perlu
diperhatikan oleh pengembang.
 Correctness : besarnya program dapat memuaskan spesifikasi dan
objektivitas dari misi pelanggan.
 Reliability : besarnya program dapat diharapkan memenuhi fungsi-fungsi
yang dikehendaki.
 Efficiency : jumlah sumber-sumber dan kode yang dibutuhkan program
untuk menjalankan fungsi-fungsi.
 Integrity : besarnya pengontrolan pengaksesan oleh seseorang yang tidak
mempunyai otorisasi terhadap perangkat lunak atau data
 Usability : effort (usaha) yang dibutuhkan untuk mempelajari,
mengoperasikan, menyiapkan input dan mengintepretasikan output
program
Hasil Pengujian :
No Indikator Ket Hasil yang diperoleh

1. Correctness V  Sistem ini menghasilkan informasi yang
(Ketepatan) akurat untuk pengarsipan surat bagi
pengguna.
 Semua fitur yang terdapat dalam sistem
berfungsi dengan baik.
 Pengelolaan data pengarsipan surat sama
dengan laporan.
2. Reliability V Setiap menu pada sistem ini telah teruji dan
(Kehandalan) berjalan dengan baik.
3. Efficiency V  Sistem ini dapat mempercepat proses
(Efisiensi) pengarsipan surat dibandingkan dengan
cara konvensional (manual).
 Sistem ini dapat memproses pengarsipan
surat dengan cepat dan tepat waktu.
 Pada sistem ini proses pengarsipan akan
disimpan dengan baik di sistem.
4. Integrity V Pada sistem ini keamanan akun pengguna
(Integritas) dapat terlindungi.
5. Usability V  Bahasa yang digunakan dalam sistem ini
(Kebergunaan) mudah dipahami dan tulisannya dapat
terbaca dengan jelas.
 Setiap tombol pada sistem ini mudah
digunakan dan sesuai dengan fungsinya.
 Pengoperasian pada sistem ini mudah
digunakan oleh setiap pengguna baru.
1.2 Product Revision

Product revision adalah seberapa jauh dan besar software yang telah berhasil
dikembangkan dapat diperbaiki
 Maintainability : usaha yang dibutuhkan untuk menempatkan dan
menetapkan suatu kesalahan pada program.
 Flexibility : usaha yang dibutuhkan untuk memodifikasi program yang
dioperasikan.
 Testability : usaha yang dibutuhkan untuk menguji program untuk
menjamin telah dijalankannya program yang diharapkan.
Hasil Pengujian :

1. Maintainability V Perlunya dilakukan pengembangan sistem
seiring dengan perkembangan kebutuhan
sistem dari waktu ke waktu.
2. Flexibility V Sistem ini bisa di modifikasi lagi oleh
pengembang selanjutnya yang akan
mengembangkan sistem ini.
3. Testability V Pengujian aplikasi dilakukan pada
kebutuhan fungsional maupun non-
fungsional, dapat disimpulkan bahwa
aplikasi telah memenuhi aspek ini.
1.3 Product Transition

Kemampuan penyesuaian sebuah software pada lingkungan yang baru atau
beberapa platform.
 Portability : usaha yang dibutuhkan untuk mentransfer program dari
lingkungan sistem perangkat lunak dan perangkat keras ke lingkungan
lain
 Reusability : besarnya program dapat digunakan oleh aplikasi lain
 Interoperability : usaha yang dibutuhkan untuk memasang-kan satu
sistem dengan yang lain.
Hasil Pengujian :

1. Portability V Sistem bisa dioperasikan selama masih
menggunakan web browser.
2. Reusability V Modul sistem dapat diterapkan pada
aplikasi lain karena sistem ini
mempunyai ruang lingkup yang kecil.
3. Interoperability V Sistem dapat berinteraksi dengan baik
dengan perangkat lunak lainnya.
Pengukuran kualitas PL diharapkan program memiliki :
 Auditability : mudah untuk dicek mengenai konfirmansi standar
 Accuracy : presisi komputasi dan pengontrolan
 Communication commonality : derajat pengunaan interface, protokol dan
bandwidth yang standar
 Completeness : derajat pencapaian implementasi full dari fungsi-fungsi
yang dibutuhkan
 Conciseness : kepadatan program dalam lines of code
 Consistency : penggunaan teknik dokumentasi dan perancangan yang
seragam
 Data commonality : penggunaan struktur dan tipe data standar
 Error tolerance : akibat yang timbul pada saat program menemui kesalahan
 Execution efficiency : kinerja waktu eksekusi pada program
 Expandability : derajat dimana perancangan terprosedur, data dan
arsitektur dapat diperluas
 Generality : kelonggaran aplikasi dari komponen program
 Hardware independence : derajat dimana perangkat lunak dipisahkan dari
perangkat keras atau yang mengoperasikannya
 Instrumentation : derajat dimana program memonitor operasinya sendiri
dan mengindentifikasikan kesalahan-kesalahan yang timbul
 Modularity : kemandirian fungsional dari komponen program
 Operability : kemudahan pengoperasian program
 Security : ketersediaan mekanisme yang mengontrol atau memproteksi
program dan data
 Self-documentation : derajat dimana source code menyediakan
dokumentasi yang berarti
 Simplicity : derajat dimana program dapat dimengerti dengan mudah
 Software system independence : derajat dimana program berdiri sendiri
dari fitur bahasa pemrograman, karakteristik sistem pengoperasian dan
batasan lainnya yang tidak standar
 Traceability : kemampuan untuk menelusuri representasi perancangan atau
komponen program aktual, kembali ke kebutuhan
 Training : derajat dimana perangkat lunak dapat membantu pengguna yang
baru dalam mengaplikasikan sistem
Hasil Pengujian :
Faktor/ Tolak Ket Alasan

Ukur
Audtiability X Karena beberapa fungsi dari sistem ini tidak
berjalan dengan baik dan benar.
Accuracy V Karena informasi yang tersedia dalam sistem
sudah cukup akurat.
Communication V Dilihat dari sistemnya, derajat interface pasti
Commonality ada dan sangat dibutuhkan juga. Dan untuk
protokol dan bandwitnya yang masih standar,
karena bisa dibilang sistem ini cukup simpel.
Completeness X Karena sistem ini masih kurang lengkap :
Tidak bisa mengubah username.
Conciseness V Jumlah baris kode program pada sistem ini
cukup padat
Consistency V Karena sistem ini konsisten mulai dari
perancangan sampai sistemnya berjalan.
Data Commonality V Karena sistem ini menggunakan tipe dan
struktur data yang standar.
Error Tolerance V Karena jika terjadi kesalahan/error, sistem ini
akan memberikan pemberitahuan. Seperti data
berhasil diinput atau gagal diinput.
Execution V Kinerja sistem ini cukup baik, dapat berjalan
Efficiency dengan cepat.
Expandability V Dari sistem yang kami lihat dan uji ini, dapat
dikatakan bahwa sistem ini dapat diperluas
arsitekturnya. Karena sistem ini dapat dibilang
masih sederhana atau simpel.
Generality X Karena ditemukan beberapa masalah seperti
pada saat input username dan password pada
bagian login, karena tidak ada batasan panjang
karakter
Hardware V Sistem ini dapat digunakan dan diakses di
Independence semua web browser.
Instrumentation V Karena sistem ini dapat mengidentifikasi
kesalahan-kesalahan yang timbul.
Operability V Karena sistem ini cukup mudah dioperasikan.
Security V Sistem ini memiliki keamanan tambahan dari
hosting yang ada.
Self X Kurangnya informasi untuk setiap kode yang
Documentation ada
Simplicity V Karena sistem ini mudah dipahami/ dimengerti.
Traceability V Sistem sudah memenuhi keingginan dan
kebutuhan dari pelanggan.
Training V Karena software ini cukup mudah dioperasikan,
termasuk untuk pengguna baru.
2. ISO 9126
ISO 9126 adalah standar terhadap kualitas perangkat lunak yang diakui secara
internasional. ISO 9126 mendefinisikan kualitas produk perangkat lunak, model,
karakteristik mutu, dan metrik terkait yang digunakan untuk mengevaluasi dan
menetapkan kualitas sebuah produk software. Selain itu, standar ISO juga harus
dipenuhi dari sisi manajemen. Jika manajemennya tidak memenuhi standar ISO
maka hasil kerjanya pun tidak dapat diberikan sertifikat standar ISO.
Faktor kualitas menurut ISO 9126 meliputi enam karakteristik kualitas sebagai
berikut:
1) Functionality (Fungsionalitas) : Kemampuan perangkat lunak untuk
menyediakan fungsi sesuai kebutuhan user dan memuaskan user.
Menunjukkan eksistensi sekumpulan fungsi dan sifat-sifatnya masing-
masing. Dimana fungsi memenuhi kebutuhan yang dinyatakan atau
diimplementasikan.
2) Reliability (Kehandalan) : Kemampuan perangkat lunak untuk
mempertahankan tingkat kinerja tertentu/ performance dari software
(ex: akurasi, konsistensi, kesederhanaan, toleransi kesalahan).
3) Usability (Kebergunaan) : Kemampuan perangkat lunak untuk
dipahami, dipelajari, digunakan, dan menarik bagi pengguna. Atribut-
atribut yang menentukan upa yang diperlukan untuk penggunaan dan
penilaian penggunaan oleh sekumpulan pengguna.
4) Efficiency (Efisiensi). Kemampuan perangkat lunak untuk
memberikan kinerja yang sesuai dan relatif terhadap jumlah sumber
daya yang digunakan pada saat keadaan tersebut (ex: efisiensi
penyimpanan). Diartikan juga sebagai hubungan antara tingkat kinerja
software dan jumlah sumberdaya yang dibutuhkan dibawah kondisi-
kondisi tertentu.
5) Maintainability (Pemeliharaan). Kemampuan perangkat lunak untuk
dimodifikasi. Modifikasi meliputi koreksi, perbaikan atau adaptasi
terhadap perubahan lingkungan, persyaratan, dan spesifikasi fungsional
(ex: konsistensi). Diartikan juga sebagai upaya yang diperlukan untuk
melakukan perubahan-perubahan tertentu.
6) Portability (Portabilitas). Kemampuan perangkat lunak untuk ditransfer
dari satu lingkungan ke lingkungan lain atau kemampuan software
beradaptasi saat digunakan di area tertentu (ex: self documentation,
teratur). Dengan kata lain adalah kemampuan software untuk
ditransformasikan dari satu lingkungan ke lingkungan lainnya.
Masing-masing karakteristik kualitas perangkat lunak model ISO 9126 dibagi

menjadi beberapa sub-karakteristik kualitas, yaitu:
(a) ISO 9126-Functionality.
Hasil Pengujian :

1. Suitability V Fungsi-fungsi yang ada didalam sistem
sudah berjalan dengan mudah dan tepat
sasaran.
2. Accuracy V Sistem dapat memberikan hasil pengolahan
data yang tepat sesuai dengan kebutuhan.
3. Security V Menjaga kerahasiaan informasi termasuk
prosedur login, perlindungan kata sandi,
dan hak akses istimewa pengguna
4. Interoperabilit V Sistem dapat berinteraksi dengan baik
y dengan
perangkat lunak lainnya.
5. Compliance V Sistem ini telah mengikuti standar aplikasi
atau regulasi hukum yang berlaku
mengenai fungsionalitas aplikasi.
(b) ISO 9126-Reliability.
Hasil Pengujian :

1. Maturity V Sistem dapat menghindari kegagalan yang
berasal dari kesalahan perangkat lunak
dengan baik.
2. Fault V Sistem dapat mempertahankan kinerjanya
Tolerance dengan baik ketika terjadi kesalahan yang
berasal dari aplikasi itu sendiri.
3. Recoverability V Perangkat lunak mampu untuk
membangun kembali tingkat kinerja ketika
terjadi kegagalan sistem, termasuk koneksi
jaringan
(c) ISO 9126-Usability.
Hasil Pengujian :

1. Understandibility V Sistem mudah untuk dipahami.
2. Learnability V Setiap pengguna baru dapat dengan
mudah mempelajari mengoperasikan
sistem.
3. Operability V Setiap tombol dan menu atau fungsi
yang ada pada sistem mudah untuk
digunakan / dioperasikan.
4. Attractiveness V Tampilan visual (User Interface) dari
sistem ini masih kurang menarik.
(d) ISO 9126-Efficiency.
Hasil Pengujian :

1. Time Behavior V Pada saat pengoperasian fungsi-fungsi
yang ada, sistem masih kurang cepat
dalam merespon perintah user.
2. Resource V Memory dan penyimpanan data yang
Behavior terpakai tidak besar kapasitasnya.
(e) ISO 9126-Maintainability.
Hasil Pengujian :

1. Analyzability V Sistem dapat mendiagnosis error atau
kesalahan yang terdapat pada sistem
pengarsipan surat ini dapat diidentifikasi
dengan mudah.
2. Changeability V Sistem ini dapat dilakukan perbaikan dan
di modifikasi lagi oleh pengembang
selanjutnya yang akan mengembangkan
sistem ini.
3. Stability V Sistem tetap stabil setelah dilakukan
perubahan/modifikasi pada sistem.
4. Testability V Sistem dapat dilakukan validasi atau
pengujian pada modifikasi sistem
yang telah dilakukan dengan mudah.
(f) ISO 9126-Portability

Hasil Pengujian :

1. Adaptability V Sistem dapat diadaptasikan pada
lingkungan yang berbeda, namun memiliki
kekurangan pada bagian tampilan yang
kurang memuaskan.
2. Instalability V Sistem dapat diintal atau dijalankan dengan
mudah.
3. Coexistence V Sistem ini dapat hidup berdampingan
dengan baik dengan perangkat lunak
independen lainnya pada lingkungan yang
sama.
4. Replaceability V Sistem dapat diperbarui dengan versi yang
terbaru.
3. ISO 25010
ISO/IEC 25010 merupakan salah satu standar ISO yang muncul pada tahun
2007. ISO 25010 merupakan standar berdasarkan ISO/IEC 9126 dan salah satu
tujuan utamanya adalah untuk memandu dalam pengembangan produk perangkat
lunak dengan spesifikasi dan evaluasi persyaratan kualitas.
ISO/IEC 25010 merupakan model kualitas sistem dan perangkat lunak yang
menggantikan ISO/IEC 9126 tentang software engineering. Product quality ini
juga digunakan untuk tiga model kualitas yang berbeda untuk produk perangkat
lunak antara lain:
 Kualitas dalam model penggunaan.
 Model kualitas produk.
 Data model kualitas.
Penggunaan ISO/IEC 25010 dalam perancangan suatu perangkat lunak juga

telah banyak dilakukan untuk menghasilkan perangkat lunak atau sistem yang
berkualitas. Penggunaan model ini juga dapat membantu untuk memberikan
rekomendasi kepada evaluator dalam melakukan peningkatan kualitas perangkat
lunak yang digunakan.
Karakteristik model ISO/IEC 25010 antara lain :
No Karakteristik Sub Karakteristik Deskripsi

1. Functional  Functional Karakteristik ini
Suitability completeness mempresentasikan tentang
 Functional sejauh mana suatu sistem
correctness menyediakan fungsi-fungsi yang
 Functional telah ditetapkan dan memenuhi
appropriateness kebutuhan.
2. Performance  Time Behavior Karakteristik ini
Effeciency  Resource mempresentasikan kinerja relatif
Utilization terhadap jumlah sumber daya
 Capasity yang digunakan di bawah
ketentuan yang ditetapkan
3. Compatibility  Co-existence Karakteristik ini
 Interoperability mempresentasikan sejauh mana
suatu produk, sistem
atau komponen dapat bertukar
informasi dengan produk, sistem
atau komponen lain, dan / atau
melakukan fungsi yang
diperlukan, sambil berbagi
perangkat keras atau perangkat
lunak yang sama lingkungan.
4. Usability  Appropriateness Karakteristik ini
recognizability mempresentasikan sejauh mana
 Learnability suatu produk atau
 Operability sistem dapat digunakan oleh
 User error pengguna tertentu untuk
protection mencapai tujuan tertentu dengan
 User interface efektivitas, efisiensi dan
aesthetics kepuasan dalam konteks
 Accessibility penggunaan yang ditentukan.
5. Reliability  Maturity Karakteristik ini
 Availability mempresentasikan sejauh mana
 Fault tolerance suatu sistem, produk atau
 Recoverability komponen melakukan fungsi
tertentu dalam kondisi yang
ditentukan untuk jangka waktu
tertentu.
6. Security  Confidentiality Sejauh mana produk dapat
 Integrity memproteksi informasi atau data
 Non-repudiation sehingga orang, produk lain atau
 Accountability sistem memiliki tingkat akses
 Authenticity data yang sesuai dengan jenis
dan tingkat otorisasi mereka.
7. Maintainability  Modularity Karakteristik ini
 Reusability mempresentasikan tingkat
 Analysability efektivitas dan efisiensi
 Modifiability dengan mana suatu produk atau
 Testability sistem dapat dimodifikasi oleh
pengelola yang dimaksud.
8. Portability  Adaptabiliti Karakteristik ini
 Installability mempresentasikan tingkat
 Replaceability efektivitas dan efisiensi
dengan mana suatu sistem,
produk atau komponen dapat
ditransfer dari satu perangkat
keras, perangkat lunak atau
lingkungan operasional atau
penggunaan lainnya ke yang lain.
Hasil Pengujian :
No. Indikator Ke Hasil yang diperoleh

t
1. Functional V Sistem pengarsipan surat ini dinyatakan baik,
suitability karena semua fungsi yang dirancang berhasil
implementasikan.
2. Performance V Sistem pengarsipan surat ini dinyatakan
Effeciency cukup baik, karena tidak memakan waktu
terlalu lama untuk merespon.
3. Compatibility V Sistem kompatibel atau dapat dijalankan
selama masih menggunakan web browser.
4. Usability V Sistem mudah untuk dipahami. Karena Setiap
pengguna baru dapat dengan mudah
mempelajari mengoperasikan sistem. Serta
setiap tombol dan menu atau fungsi yang ada
pada sistem mudah untuk digunakan /
dioperasikan.
5. Reliability V Setiap menu pada sistem ini telah teruji
dengan baik.
6. Security V Sistem ini memiliki keamanan tambahan dari
hosting yang ada.
7. Maintainability V  Sistem ini bisa di modifikasi lagi oleh
pengembang selanjutnya yang akan
mengembangkan sistem ini.
 Sistem tetap stabil setelah dilakukan
perubahan/modifikasi pada sistem.
8. Portability V Sistem dapat dijalankan di beberapa browser
tanpa ada kesalahan pada tampilan maupun
fungsionalitas.
E. PENGUJIAN UNIT
UNIT TESTING adalah jenis pengujian perangkat lunak di mana masing-
masing unit atau komponen suatu perangkat lunak diuji. Tujuannya adalah untuk
memvalidasi bahwa setiap unit kode perangkat lunak melakukan seperti yang
diharapkan. Unit Testing dilakukan selama pengembangan (fase pengkodean) aplikasi
oleh pengembang. Unit testing mengisolasi bagian kode dan memverifikasi
kebenarannya. Unit dapat berupa fungsi, metode, prosedur, modul, atau objek
individual.
Beberapa alasan mengapa unit testing penting adalah:

 Membantu memperbaiki bug di awal siklus software development dan
menghemat biaya.
 Membantu developer untuk memahami basis kode dan memungkinkan
mereka membuat perubahan dengan cepat.
 Berfungsi sebagai dokumentasi proyek.
 Membantu penggunaan kembali kode pada proyek yang baru.
Dalam pengujian kali ini metode yang digunakan adalah metode prototype. Salah
satu metode siklus hidup sistem yang didasarkan pada konsep model bekerja (working
model). Tujuannya adalah mengembangkan model menjadi sistem final. Artinya
system akan dikembangkan lebih cepat dari pada metode tradisional dan biayanya
menjadi lebih rendah.
 Pengumpulan kebutuhan :
Mengidentifikasi seluruh perangkat dan permasalahan.
 Membangun prototype :
Membangun prototipe yang berfokus pada penyajian pelanggan. Misalkan
membuat input dan output hasil system.
 Evaluasi protoptype :
Ketika langkah 1, dan 2 ada yang kurangatau salah kedepannya akan sulit
sekali melanjutkan langkah selanjutnya.
 Mengkodekan system :
Sebelum pengkodean atau biasanya kita sebut proses koding, perlu kita
ketahui terlebih dahulu pengkodingan menggunakan Bahasa pemograman.
 Menguji system :
Testing dapat Menggunakan white box berarti menguji kodingan sedangkan
black box menguji fungus-fungsi tampilan apakah sudah benar dengan
aplikasinya atau tidak.
 Evaluasi Sistem :
Mengevaluasi dari semua langkah yang pernah di lakukan. Sudah sesuai
dengan kebutuhan atau belum.
 Penggunaan system :
System sudah selesai dan siap di serahkan kepada pelanggan.
1. Use Case Diagram
Use case diagram merupakan model diagram UML yang digunakan untuk
menggambarkan requirement fungsional yang diharapkan dari sebuah sistem. Use
case diagram adalah diagram usecase yang digunakan untuk menggambarkan
secara ringkas siapa yang menggunakan sistem dan apa saja yang bisa
dilakukannya.
1.1 Use Case Diagram Umum
1.2 Use Case Diagram Admin

1.3 Use Case Diagram Kepala Sekolah
2. Sequence Diagram
Sequence diagram atau diagram urutan adalah sebuah diagram yang digunakan
untuk menjelaskan dan menampilkan interaksi antar objek-objek dalam sebuah
sistem secara terperinci. Selain itu sequence diagaram juga akan menampilkan
pesan atau perintah yang dikirim, beserta waktu pelaksanaannya.
1) Sequence Diagram Login
2) Sequence Diagram Logout
3) Sequence Diagram Input Surat masuk dan surat keluar

4) Sequence Diagram Input Surat Keluar
5) Sequence Diagram Tambah Kode Surat

6) Sequence Diagram Tambah User
7) Sequence Diagram Ubah Profil Instansi

8) Sequence Diagram Ubah Data Surat
9) Sequence Diagram Hapus Surat
10) Sequence Diagram Melihat Data Surat

3. Pengujian Unit Pada Sistem
3.1 Use Case Login
3.1.1 Mendeskripsikan usecase kedalam teks
Basic Flow
1. User mengakses form login
2. User memasukan username
3. User memasukan password
4. User menekan tombol login
5. Sistem akan melakukan validasi login
Alternate Flow
1. Quit
User tidak melakukan login dengan meninggalakan sistem,
maka sistem tidak akan melakukan action apapun.
2. Tidak memasukan username atau password.

User melakukan login dengan memasukan username atau
password yang salah, maka sistem akan menampilkan pesan
kesalahan.
3. Tidak memasukan username dan password

User tidak memasukan username dan password atau tidak
memasukan salah satunya maka sistem akan menampilkan
pesan peringatan untuk mengisi form yang belum terisi.
3.1.2 Generate Scenario
Scenario Name Starting Alternate

Flow
Scenario I – Login Berhasil Basic Flow
Scenario II – User salah memasukan Basic Flow A1

username atau password
Scenario III – User tidak mengisi Basic Flow A2
username atau password
3.1.3 Identify Test Case
Test Input Hasil yang

Case Scenario/Condition Form Login Diharapkan
Id Login
RC1 Login berhasil V V Login berhasil
dan masuk ke
beranda
RC2 Username / password V X Pesan kesalahan
salah dan kembali ke
form login
RC3 Username dan X X Peringatan untuk
password kosong mengisi form
yang kosong
3.1.4 Identify Data Value
Data
Test
Case Scenario/Condition Input Hasil yang
Id Form Login Diharapkan
Login
RC1 Login berhasil 25 500 Login berhasil
dan masuk ke
beranda
RC2 Username / password 25 4000 Pesan login
salah NB : False gagal dan
: 3500 kembali ke form
login
RC3 Username / password 25 Empty Peringatan untuk
kosong mengisi form
yang kosong
** Untuk pengujian unit pada bagian login tidak ditemukan kesalahan.
3.2 Use Case Admin - Mengelola Data Surat

3.2.1 Menambah data surat masuk
 Mendeskripsikan usecase kedalam teks
Basic Flow
1. Admin memilih menu transaksi
2. Admin memilih sub menu surat masuk
3. Admin melakukan penginputan data surat masuk
4. Admin menekan tombol simpan.
5. Sistem menyimpan perubahan atau menambahkan data
kedalam database.
Alternate Flow
1. Batal.
Admin meninggalkan halaman form tambah surat masuk
dengan memilih tombol batal. Sistem akan kembali ke
halaman daftar surat masuk.
2. Menambahkan surat dengan lampiran dokumen

surat yang tidak sesuai.
Admin menambah data surat masuk dengan lampiran
dokumen surat yang tidak terdaftar. Sistem tidak akan
menerima inputan file yang tidak sesuai ketentuan.
3. Tidak memasukan lampiran dokumen surat.

Admin memasukan data surat masuk tanpa melampirkan
file dokumen surat. Sistem akan menampilkan pesan
kesalahan dan kembali ke halaman form tambah data
surat masuk.
 Generate Scenario
Starting
Scenario Name Alternate
Flow
Scenario I – Tambah surat masuk Basic Flow
berhasil
Scenario II – Format file lampiran Basic Flow A1
tidak sesuai
Scenario III – Lampiran file Kosong Basic Flow A2
 Identify Test Case
Test Form
Hasil yang
Case Input Input
Scenario/Condition Diharapkan
Id Surat
Data berhasil
ditambahkan
Tambah data surat dan ditampilkan
RC1 V V
masuk berhasil di halaman
daftar surat
masuk
Pesan format
file tidak sesuai
Format file lampiran
RC2 V X dan kembali ke
surat tidak sesuai
form tambah
surat.
Peringatan untuk
Lampiran file surat mengisi
RC3 V X
kosong lampiran file
surat
 Identify Data Value
Data
Test
Case Form Hasil yang
Id Scenario/Condition Input Input Diharapkan
Surat
Data berhasil
ditambahkan dan
Tambah data surat
RC1 25 500 ditampilkan di
masuk berhasil
halaman daftar surat
masuk
4000 Pesan format file
Lampiran surat NB : tidak sesuai dan
RC2 25
salah False kembali ke form
: 3500 tambah surat.
Peringatan untuk
Lampiran surat
RC3 25 Empty mengisi lampiran
kosong
file surat
** Hasil yang kami peroleh dimana proses penambahan data surat

tetap berhasil walaupun tidak menginputkan lampirkan file surat
masuknya.
3.2.2 Menambah data surat keluar

Basic Flow
1. Admin memilih menu transaksi
2. Admin memilih sub menu surat keluar
3. Admin melakukan penginputan data surat keluar
5. Sistem menyimpan perubahan atau menambahkan data
kedalam database.
Alternate Flow
1. Batal.
Admin meninggalkan halaman form tambah surat masuk
halaman daftar surat keluar.
2. Menambahkan surat dengan lampiran dokumen

surat yang tidak sesuai.
Admin menambah data surat keluar dengan lampiran
dokumen surat yang tidak terdaftar. Sistem tidak akan
menerima inputan file yang tidak sesuai ketentuan.
3. Tidak memasukan lampiran dokumen surat.

Admin memasukan data surat masuk tanpa melampirkan
file dokumen surat. Sistem akan menampilkan pesan
kesalahan dan kembali ke halaman form tambah data
surat keluar.
Starting
Flow
Scenario I – Tambah surat keluar Basic Flow
berhasil
Scenario II – Format file lampiran Basic Flow A1
tidak sesuai
Scenario III – Lampiran file Kosong Basic Flow A2
Test Form
Hasil yang
Case Input Input
Id Surat
Data berhasil
ditambahkan
Tambah data surat dan ditampilkan
RC1 V V
keluar berhasil di halaman
daftar surat
keluar
Pesan format
file tidak sesuai
Format file lampiran
surat tidak sesuai
form tambah
surat.
Peringatan untuk
Lampiran file surat mengisi
RC3 V X
kosong lampiran file
surat
Data
Test
Case Form Hasil yang
Id Scenario/Condition Input Input Diharapkan
Surat
Data berhasil
ditambahkan dan
Tambah data surat
keluar berhasil
keluar
4000 Pesan format file
Lampiran surat NB : tidak sesuai dan
RC2 25
salah False kembali ke form
: 3500 tambah surat.
RC3 Lampiran surat 25 Empty Peringatan untuk
kosong mengisi lampiran
file surat
** Hasil yang kami peroleh dimana proses penambahan data surat

tetap berhasil walaupun tidak menginputkan lampirkan file surat
keluarnya.
3.2.3 Mengubah data surat masuk.

Basic Flow
1. Admin mengakses form edit surat masuk.
2. Admin melakukan perubahan data surat masuk.
4. Sistem menyimpan perubahan atau mengupdate data didalam
database.
Alternate Flow
1. Batal
Admin meninggalkan halaman form edit surat masuk dan
surat keluar dengan memilih tombol batal. Sistem akan
kembali ke halaman daftar surat masuk.
2. Mengubah kode surat dengan kode surat yang tidak

terdaftar.
Admin mengubah data surat masuk dengan kode surat yang
tidak terdaftar. Sistem akan menyimpan data surat dengan
kode yang sudah terdaftar sebelumnya dan kembali ke
halaman form tambah data surat masuk.
3. Tidak melakukan perubahan apapun.

Admin tidak melakukan perubahan data surat sama sekali
namun mengklik tombol simpan. Sistem akan krmabli ke
halaman daftar surat masuk.
Starting
Flow
Scenario I – Edit surat masuk berhasil Basic Flow
Scenario II – Kode surat tidak sesuai Basic Flow A1
Scenario III – Tidak melakukan
Basic Flow A2
perubahan data
Test Form
Hasil yang
Case Edit Edit
Id Surat
Data berhasil
diubah dan
Edit data surat masuk
RC1 V V ditampilkan di
berhasil
halaman daftar
surat masuk
Pesan format file
Kode surat tidak tidak sesuai dan
RC2 V X
sesuai kembali ke form
tambah surat.
Data tersimpan
Tidak melakukan
perubahan data
daftar surat keluar
Data
Test Form Hasil yang
Scenario/Condition
Case Edit Edit Diharapkan
Id Surat
Data berhasil
ditambahkan dan
Edit data surat
masuk berhasil
masuk
4000 Pesan kode surat
Kode surat tidak NB : tidak sesuai dan
RC2 25
sesuai False kembali ke form
: 3500 edit surat.
Data tersimpan dan
Tidak melakukan kembali ke daftar
RC3 25 Empty
perubahan data surat masuk dan
surat keluar
** Hasil yang kami peroleh dimana saat kita mengubah kode surat
dengan kode surat yang tidak terdaftar tidak ada pesan kesalahan
dari sistem namun data tetap tersimpan pada sistem dengan kode
surat sebelumnya.
3.2.4 Mengubah data surat keluar

Basic Flow
1. Admin mengakses form edit surat keluar.
2. Admin melakukan perubahan data surat keluar.
4. Sistem menyimpan perubahan atau mengupdate data didalam
database.
Alternate Flow
1. Batal
Admin meninggalkan halaman form edit surat masuk dan
surat keluar dengan memilih tombol batal. Sistem akan
kembali ke halaman daftar surat keluar.
2. Mengubah kode surat dengan kode surat yang tidak
terdaftar.
Admin mengubah data surat keluar dengan kode surat yang
tidak terdaftar. Sistem akan menyimpan data surat dengan
kode yang sudah terdaftar sebelumnya dan kembali ke
halaman form tambah data surat keluar.
3. Tidak melakukan perubahan apapun.

Admin tidak melakukan perubahan data surat sama sekali
namun mengklik tombol simpan. Sistem akan krmabli ke
halaman daftar surat keluar.
Starting
Flow
Scenario I – Edit surat keluar berhasil Basic Flow
Scenario II – Kode surat tidak sesuai Basic Flow A1
Scenario III – Tidak melakukan
Basic Flow A2
perubahan data
Test Form
Hasil yang
Case Edit Edit
Id Surat
Data berhasil
diubah dan
Edit data surat keluar
RC1 V V ditampilkan di
berhasil
halaman daftar
surat keluar.
RC2 Kode surat tidak V X Pesan format file
sesuai tidak sesuai dan
kembali ke form
tambah surat.
Data tersimpan
Tidak melakukan
perubahan data
daftar surat keluar
Data
Scenario/Condition
Id Surat
Data berhasil
ditambahkan dan
Edit data surat
keluar berhasil
keluar
4000 Pesan kode surat
Kode surat tidak NB : tidak sesuai dan
RC2 25
sesuai False kembali ke form
: 3500 edit surat.
Data tersimpan dan
Tidak melakukan
RC3 25 Empty kembali ke daftar
perubahan data
surat keluar
** Hasil yang kami peroleh dimana saat kita mengubah kode surat
dengan kode surat yang tidak terdaftar tidak ada pesan kesalahan
dari sistem namun data tetap tersimpan pada sistem dengan kode
surat sebelumnya.
3.2.5 Menghapus data surat keluar.

Basic Flow
1. Admin mengakses form hapus surat masuk.
2. Admin melihat data surat masuk yang ingin dihapus
3. Admin menekan tombol hapus.
4. Sistem akan menghapus data surat yang ingin dihapus.
Alternate Flow
1. Batal
Admin meninggalkan halaman form hapus surat masuk
halaman daftar surat masuk dan surat keluar.
2. Melihat file lampiran surat yang ingin dihapus

Admin melihat file surat masuk yang akan dihapus. Sistem
akan menampilakn file surat yang ingin dihapus.
3. Mendownload file lampiran surat

Admin mendownload file surat masuk yang akan dihapus
sebelum dihapusnya Sistem akan menampilakan file surat
yang ingin dihapus.
Starting
Flow
Scenario I – Hapus surat masuk
Basic Flow
berhasil
Scenario II – Lihat file surat Basic Flow A1
Scenario III – Download surat Basic Flow A2
Test Form
Hasil yang
Case Hapus Hapus
Id Surat
RC1 Hapus data surat V V Data berhasil
masuk berhasil dihapus dan
kembali ke
halaman daftar
surat masuk.
Menampilkan
RC2 Lihat file surat V V
surat.
Berhasil
RC3 Download surat V V mendownload
surat
Data
Scenario/Condition
Id Surat
Data berhasil
Hapus data surat dihapus dan kembali
RC1 25 500
masuk berhasil ke halaman daftar
surat masuk.
RC2 Lihat file surat 25 500 Menampilkan surat.
Berhasil
RC3 Download surat 25 500
mendownload surat
** Tidak ada kegagalan pada proses mengahapus data surat
3.2.6 Menghapus data surat keluar.

Basic Flow
1. Admin mengakses form hapus surat keluar.
2. Admin melihat data surat keluar yang ingin dihapus
3. Admin menekan tombol hapus.
4. Sistem akan menghapus data surat yang ingin dihapus.
Alternate Flow
1. Batal
Admin meninggalkan halaman form hapus surat keluar
halaman daftar surat masuk dan surat keluar.
2. Melihat file lampiran surat yang ingin dihapus

Admin melihat file surat keluar yang akan dihapus. Sistem
akan menampilakn file surat yang ingin dihapus.
3. Mendownload file lampiran surat

Admin mendownload file surat keluar yang akan dihapus
sebelum dihapusnya Sistem akan menampilakan file surat
yang ingin dihapus.
Starting
Flow
Scenario I – Hapus surat keluar
Basic Flow
berhasil
Scenario II – Lihat file surat Basic Flow A1
Scenario III – Download surat Basic Flow A2
Test Form
Hasil yang
Case Hapus Hapus
Id Surat
Data berhasil
dihapus dan
Hapus data surat
RC1 V V kembali ke
keluar berhasil
halaman daftar
surat keluar.
Menampilkan
RC2 Lihat file surat V V
surat.
Berhasil
RC3 Download surat V V mendownload
surat
Data
Scenario/Condition
Id Surat
Data berhasil
Hapus data surat dihapus dan kembali
RC1 25 500
keluar berhasil ke halaman daftar
surat keluar.
RC2 Lihat file surat 25 500 Menampilkan surat.
Berhasil
RC3 Download surat 25 500
mendownload surat
** Tidak ada kegagalan pada proses mengahapus data surat
3.3 Use Case Admin - Mengelola Laporan Surat Masuk.

Basic Flow
1. Admin mengakses halaman laporan surat masuk.
2. Admin memasukan tanggal yang digunakan untuk melihat
laporan surat masuk berdasarkan rentang waktu tertentu.
3. Sistem akan menampilkan daftar surat dengan rentang
waktu tersebut.
Alternate Flow
1. Logout
Admin meninggalkan halaman laporan surat masuk dengan
memilih tombol logout. Sistem akan kembali ke halaman
laporan surat masuk dan surat keluar.
2. Memasukan rentang tanggal surat masuk yang tidak

sesuai.
Admin melihat laporan surat masuk dengan rentang tanggal
yang tidak ada data suratnya. Sistem akan menampilakan
pesan tidak ada laporan surat pada renatng waktu tersebut.
3. Tidak memasukan rentang tanggal surat masuk.

Admin tidak memasukan rentang waktu dan lamgsung
menekan tombol tampilkan. Sistem akan menampilakan
pesan untuk mengisi tanggal terlebih dahulu.
Starting
Flow
Scenario I – Melihat Laporan surat
Basic Flow
masuk berhasil
Scenario II – Tanggal tidak sesuai Basic Flow A1
Scenario III – Tanggal kosong Basic Flow A2
Test Form
Lapora Hasil yang
Case input
Scenario/Condition n Diharapkan
Id tanggal
Lihat laporan Laporan surat
RC1 V V
berhasil ditampilkan.
RC2 Tanggal tidak sesuai V X Menampilkan
pesan tidak ada
laporan pada
rentang waktu
tersebut.
Pesan peringatan
untuk meninputkan
tanggal dan
RC3 Tanggal kosong V X
kembali ke form
input tanggal
laporan
Data
Test Scenario/ Form Hasil yang
Lapora
Case Condition Input Diharapkan
n
Id Tanggal
Data berhasil dihapus
Lihat laporan dan kembali ke
RC1 25 500
berhasil halaman daftar surat
masuk
4000 Menampilkan pesan
Tanggal tidak NB : tidak ada laporan
RC2 25
sesuai False pada rentang waktu
: 3500 tersebut.
Pesan peringatan
untuk meninputkan
Tanggal
RC3 25 Empty tanggal dan kembali
kosong
ke form input tanggal
laporan
***Hasil yang kami peroleh dimana pada pencarian laporan

surat ini surat yang ditampilkan bukan berdasarkan tanggal
surat melainkan berdasarkan tanggal surat diinput kesistem.
3.4 Use Case Admin – Mengelola Laporan Surat Keluar.
Basic Flow
1. Admin mengakses halaman laporan surat keluar.
2. Admin memasukan tanggal yang digunakan untuk
melihat laporan surat keluar berdasarkan rentang waktu
tertentu.
3. Sistem akan menampilkan daftar surat dengan rentang
waktu tersebut.
Alternate Flow
1. Logout
Admin meninggalkan halaman laporan surat keluar dengan
memilih tombol logout. Sistem akan kembali ke halaman
laporan surat masuk dan surat keluar.
2. Memasukan rentang tanggal surat keluar yang tidak

sesuai.
Admin melihat laporan surat keluar dengan rentang tanggal
yang tidak ada data suratnya. Sistem akan menampilakan
pesan tidak ada laporan surat pada renatng waktu tersebut.
3. Tidak memasukan rentang tanggal surat keluar.

Admin tidak memasukan rentang waktu dan langsung
menekan tombol tampilkan. Sistem akan menampilakan
pesan untuk mengisi tanggal terlebih dahulu.
Starting
Flow
Scenario I – Melihat Laporan surat
Basic Flow
keluar berhasil
Scenario II – Tanggal tidak sesuai Basic Flow A1
Test Form
Lapora Hasil yang
Case input
Scenario/Condition n Diharapkan
Id tanggal
Lihat laporan Laporan surat
RC1 V V
berhasil ditampilkan.
Menampilkan
pesan tidak ada
RC2 Tanggal tidak sesuai V X laporan pada
rentang waktu
tersebut.
Pesan peringatan
untuk meninputkan
tanggal dan
RC3 Tanggal kosong V X
kembali ke form
input tanggal
laporan
Data
Test Scenario/ Form Hasil yang
Lapora
Case Condition Input Diharapkan
n
Id Tanggal
Data berhasil dihapus
Lihat laporan dan kembali ke
RC1 25 500
berhasil halaman daftar surat
surat keluar
4000 Menampilkan pesan
Tanggal tidak NB : tidak ada laporan
RC2 25
sesuai False pada rentang waktu
: 3500 tersebut.
Pesan peringatan
untuk meninputkan
Tanggal
RC3 25 Empty tanggal dan kembali
kosong
ke form input tanggal
laporan
***Hasil yang kami peroleh dimana pada pencarian laporan
surat ini surat yang ditampilkan bukan berdasarkan tanggal
surat melainkan berdasarkan tanggal surat diinput kesistem.
3.5 Use Case Admin - Mengelola Galeri

3.5.1 Lihat file surat masuk
 Mendeskripsikan use case kedalam teks.
Basic Flow
1. Admin mengakses galeri file.
2. Admin mengklik pilihan surat masuk.
3. Sistem akan menampilkan data surat yang sudah
terarsip.
Alternate Flow
1. Kembali ke laman utama
Admin mengklik menu bar beranda saja maka sistem
akan langsung kembali mengarahakan admin kepada
laman beranda.
2. Melihat detail surat.

Admin mengklik salah satu surat yang telah terarsip di
galeri sistem dan sistem akan menampilkan detail surat
yang di perlukan oleh admin dengan membuka tab baru.
3. Mendownload surat dari laman detail surat masuk.
Admin melakukan klik button download pada detail
surat masuk maka sistem akan mengakses file eksplorer
dan mengarahkan admin untuk memilih lokasi
menyimpan surat yang akan di download.
Starting
Flow
Scenario I – melihat arsip surat
Basic Flow
masuk
Scenario II – melihat detail surat Basic Flow A1
Scenario III – Mendownload
Basic Flow A2
surat
Test Galeri Hasil yang

View
Case Scenario/ surat Diharapkan
Id Condition
Melihat arsip surat Menampilkan arsip
RC1 V V
masuk berhasil surat masuk
Sistem akan
menampilkan detail
RC2 Melihat detail surat V V
surat yang di klik
oleh admin.
RC3 Mendownload surat V V sistem akan
mengakses file
eksplorer dan
mengarahkan admin
untuk memilih
lokasi menyimpan
surat yang akan di
download
Data
Test Hasil yang
Case Scenario/Condition Galeri View Diharapkan
Id surat
melihat arsip surat Menampilkan arsip
RC1 25 500
masuk surat masuk
Sistem akan
menampilkan detail
RC2 Melihat detail surat 25 500
surat yang di klik
oleh admin.
sistem akan
mengakses file
eksplorer dan
mengarahkan admin
RC3 Mendownload surat 25 500
untuk memilih lokasi
menyimpan surat
yang akan di
download
**Tidak ada kesalahan
3.5.2 Lihat file surat keluar

 Mendeskripsikan use case kedalam teks.
Basic Flow
1. Admin mengakses galeri file.
2. Admin mengklik pilihan surat keluar.
3. Sistem akan menampilkan data surat yang sudah
terarsip.
Alternate Flow
1. Kembali ke laman utama
Admin mengklik menu bar beranda saja maka sistem
akan langsung kembali mengarahakan admin kepada
laman beranda.
2. Melihat detail surat.

Admin mengklik salah satu surat yang telah terarsip di
galeri sistem dan sistem akan menampilkan detail surat
yang di perlukan oleh admin dengan membuka tab baru.
3. Mendownload surat dari laman detail surat masuk.

Admin melakukan klik button download pada detail
surat masuk maka sistem akan mengakses file eksplorer
dan mengarahkan admin untuk memilih lokasi
menyimpan surat yang akan di download.
Starting
Flow
Scenario I – melihat arsip surat
Basic Flow
keluar
Scenario II – melihat detail surat Basic Flow A1
Scenario III – Mendownload
Basic Flow A2
surat
Test Galeri Hasil yang

View
Case Scenario/ surat Diharapkan
Id Condition
Melihat arsip surat Menampilkan arsip
RC1 V V
keluar berhasil surat keluar
RC2 Melihat detail surat V V Sistem akan
menampilkan detail
surat yang di klik
oleh admin.
sistem akan
mengakses file
eksplorer dan
mengarahkan admin
RC3 Mendownload surat V V
untuk memilih
lokasi menyimpan
surat yang akan di
download
Data
Test Hasil yang
Case Scenario/Condition Galeri View Diharapkan
Id surat
melihat arsip surat Menampilkan arsip
RC1 25 500
keluar surat keluar
Sistem akan
menampilkan detail
RC2 Melihat detail surat 25 500
surat yang di klik
oleh admin.
sistem akan
mengakses file
eksplorer dan
mengarahkan admin
RC3 Mendownload surat 25 500
untuk memilih lokasi
menyimpan surat
yang akan di
download
3.6 Use Case Admin - Mengelola Master Data
3.6.1 Menambahkan kode surat
Basic Flow
1. Admin mengakses master data.
2. Admin mengklik pilihan kode surat.
3. Admin menambahkan data kode surat yang akan di
input.
4. Admin klik button simpan
5. Sistem akan menyimpan data kode surat.
Alternate Flow
1. Batal
Admin mengklik button batal maka sistem akan kembali
ke laman data kode surat.
2. Hanya Menginputkan 1 kolom.
Admin hanya mengisi kolom kode tanpa mengisi uraian
lalu menekan button simpan, maka sistem akan
memberikan pesan peringatan untuk mengisi data
dengan lengkap terlebih dahulu sebelum menyimpan.
3. Tidak menginputkan karakter apapun.
Admin menekan tombol simpan tanpa menginputkan
apapun, maka sistem akan memberikan pesan
peringatan untuk mengisi data terlebih dahulu sebelum
menyimpan.
 Generate scenario
Starting
Flow
Scenario I – Menambah kode surat Basic Flow
Scenario II – Hanya Menginputkan 1
Basic Flow A1
kolom
Scenario III – Tidak menginputkan
Basic Flow A2
karakter apapun
Test Master Hasil yang

View
Case Scenario/ data Diharapkan
Id Condition
Menampilkan
pesan data berhasil
Menambah kode
RC1 V V ditambahkan dan
surat berhasil
ditampilkan di
laman kode surat.
Sistem
Hanya
memberikan pesan
RC2 Menginputkan 1 V X
agar data diisi
kolom
dengan lengkap.
Sistem
Tidak
memberikan pesan
RC3 menginputkan V X
agar data diisi
karakter apapun
dengan lengkap.
Data
Test
Cas Master View Hasil yang
Scenario/Condition
e Id data Diharapkan
Sistem menuju form
Menambah kode
RC1 25 500 penginputan kode
surat
surat
RC2 Hanya 25 4000 Sistem memberikan
Menginputkan 1 NB : pesan agar data diisi
False dengan lengkap.
kolom
: 3500
Tidak Sistem memberikan
RC3 menginputkan 25 Empty pesan agar data diisi
karakter apapun dengan lengkap.
**Hasil yang kami peroleh tidak ada kesalahan.
3.6.2 Mengubah Kode Surat

Basic Flow
1. Admin mengakses laman daftar kode surat.
2. Admin mengklik aksi edit kode surat.
3. Sistem akan menampilkan form edit data kode surat.
4. Admin melakukan perubahan data.
5. Admin mengklik button simpan.
6. Sistem akan melakukan update daftar kode surat.
Alternate Flow
1. Batal
Admin mengklik button batal dan tidak jadi mengedit.
Sistem akan kembali ke laman daftar kode surat.
2. Mengosongkan salah 1 kolom.

Admin menghapus salah 1 isian kolom, dan klik button
simpan.
3. Menyimpan kode tanpa mengedit

Admin tidak melakukan perubahan data dan langsung
klik button simpan.
 Generate scenario
Starting
Flow
Scenario I – Mengedit kode surat
Basic Flow
berhasil
Scenario II – mengosongkan 1 kolom
Basic Flow A1
isian
Scenario III – Menyimpan kode surat
Basic Flow A2
tanpa mengedit

Scenario/ View
Case data Diharapkan
Condition
Id
Kode surat di
perbaharui dan
RC1 Mengedit kode surat V V
Sistem menuju
laman kode surat
Sistem akan
memberikan pesan
Mengosongkan 1
RC2 V X peringatan untuk
kolom isian
mengisi data secara
lengkap
sistem akan tetap
menyimpan kode
Menyimpan kode surat walau tanpa
RC3 V V
tanpa mengedit di edit dan kembali
ke laman kode
surat
Data
Test
Scenario/Condition
Kode surat di
Mengedit kode surat perbaharui dan
RC1 25 500
berhasil Sistem menuju
laman kode surat
Sistem akan
4000
memberikan pesan
Mengosongkan 1 NB :
RC2 25 peringatan untuk
kolom isian False
mengisi data secara
: 3500
lengkap
sistem akan tetap
menyimpan kode
Menyimpan kode
RC3 25 500 surat walau tanpa di
tanpa mengedit
edit dan kembali ke
laman kode surat
*** Tidak ada kesalahan ditemukan
3.6.3 Menghapus kode surat

 Mendeskripsikan use case kedalam teks
Basic Flow
2. Admin mengklik aksi hapus kode surat.
3. Sistem akan menuju form konfirmasi
4. Admin klik button hapus
5. Sistem akan menampilkan update daftar kode surat.
Alternate Flow
Batal menghapus.
Admin mengklik button batal menghapus.
Starting
Flow
Scenario I – berhasil menghapus Basic Flow
Scenario II – Batal menghapus Basic Flow A1
Test Maste Hasil yang

View
Case Scenario/Condition r data Diharapkan
Id
Pesan kode surat
berhasil di hapus
Menghapus kode
RC1 V V dan Sistem
surat berhasil
menuju laman
kode surat
Sistem kembali
Batal menghapus
RC2 V V pada laman kode
kode surat
surat.
Data
Test
Cas Scenario/Condition Master View Hasil yang
Kode surat di hapus
Menghapus kode
RC1 25 500 dan Sistem menuju
surat
laman kode surat
Batal menghapus Sistem kembali pada
RC2 25 500
kode surat laman kode surat.
***Tidak ada kesalahan didapatkan
3.6.4 Menambah User

Basic Flow
2. Admin mengklik pilihan user.
3. Admin mengklik pilihan menambahkan user.
4. Sistem akan menuju ke form penginputan data user baru.
5. Admin menginputkan data user dengan lengkap dan klik
button simpan
6. Sistem akan menyimpan dan menampilkan data user.
Alternate Flow
1. Batal
Admin mengklik button batal tanpa menginputkan
apapun.
2. Tidak menginputkan data user.
Admin tidak menginput data apapun dan langsung
mengklik button simpan.
3. Admin tidak menginputkan level akun user
Admin mengisi semua data kecuali data level user.
Starting
Flow
Scenario I – Menambah user baru Basic Flow
Scenario II – tidak menginput data user Basic Flow A1
Scenario III – tidak menginputkan level
Basic Flow A2
akun

View
Id Condition
Sistem menuju
form penginputan
user, dan sistem
Menambah user
RC1 V V menyimpan data
baru
yang telah di
inputkan oleh
admin
Sistem
Tidak menginput
RC2 V X memberikan pesan
data user
peringatan.
Tidak Sistem
RC3 menginputkan level V X memberikan pesan
akun peringatan
Data
Test
Cas Maste View Hasil yang
Scenario/Condition
e Id r data Diharapkan
Sistem menuju
form
penginputan
Menambah user user, dan sistem
RC1 25 500
baru menyimpan
data yang telah
di inputkan oleh
admin
RC2 tidak menginput 25 500 Sistem
data user memberikan
pesan
peringatan.
Sistem
tidak menginputkan memberikan
RC3 25
level akun pesan
peringatan
***Hasil yang diperoleh dimana tidak ada pesan peringatan

pada saat pengisian data user namun tidak memilih level
akun.
3.6.5 Mengubah Data User

Basic Flow
1. Admin mengakses data user.
2. Admin mengklik aksi edit user.
3. Sistem akan menampilkan form edit data user.
4. Admin mengedit data user.
5. Sistem akan menampilkan update daftar user.
Alternate Flow
1. Batal mengedit
Admin mengklik button batal tanpa mengedit dan
menginputkan apapun.
2. Menyimpan user tanpa mengedit
Admin tidak mengubah data apapun dan langsung
mengklik button simpan.
Starting
Flow
Scenario I – Mengedit user dan
Basic Flow
menyimpan
Scenario II – Batal mengedit Basic Flow A1
Scenario III – Menyimpan user tanpa
Basic Flow A2
mengedit

View
Id Condition
User di perbaharui
Berhasil Mengedit
RC1 V V dan Sistem menuju
user
laman user
Sistem kembali
RC2 Batal mengedit user V V
pada laman user.
Sistem akan tetap
menyimpan user
Menyimpan kode
RC3 V V walau tanpa di edit
tanpa mengedit
dan kembali ke
laman user
Data
Test
Scenario/Condition
User di perbaharui
Berhasil Mengedit
RC1 25 500 dan Sistem menuju
user
laman user
RC2 Batal mengedit user 25 500 Sistem kembali pada
laman user.
sistem akan tetap
menyimpan user
Menyimpan user
RC3 25 500 walau tanpa di edit
tanpa mengedit
dan kembali ke
laman user
***Tidak ada kesalahan
3.6.6 Menghapus Data User

Basic Flow
2. Admin mengklik aksi hapus user.
3. Sistem akan mengarahkan di laman form konfirmasi.
4. Admin mengklik button hapus.
5. Sistem akan menampilkan update daftar user.
Alternate Flow
Batal menghapus.
Admin mengklik tombol batal.
Starting
Flow
Scenario I – Berhasil menghapus Basic Flow
Scenario II – Batal mengedit Basic Flow A1
Maste View Hasil yang

Test r data Diharapkan
Case
Scenario/Condition
Id
User di hapus
dan Sistem
RC1 Menghapus user V V
menuju laman
user
Batal menghapus Sistem kembali
RC2 V V
user pada laman user.
Data
Test
Cas Scenario/Condition Master View Hasil yang
User di hapus dan
RC1 Menghapus user 25 500 Sistem menuju
laman user
Batal menghapus Sistem kembali pada
RC2 25 500
user laman user.
3.7 Use Case Pengaturan

3.7.1 Edit Profil Instansi
Basic Flow
1. Admin mengakses pengaturan.
2. Admin mengklik profil instasi.
3. Sistem akan menampilkan laman profil instansi.
4. Admin mengedit data profil instansi.
5. Sistem mengupdate data profil instansi.
Alternate Flow
1. Menyimpan tanpa mengedit
Admin langsung mengklik button simpan tanpa melakukan
perubahan data
2. Mengosongkan 1 kolom
Admin menghapus 1 data kolom.
Starting
Flow
Scenario I – Mengedit profil instansi Basic Flow
Scenario III – Menyimpan profil tanpa
Basic Flow A1
mengedit
Scenario III – Mengosongkan 1 kolom Basic flow A2

View
Id Condition
Profil instasi di
perbaharui dan
Berhasil Mengedit Sistem
RC1 V V
profil instansi menampilkan
pesan bahwa sistem
telah di perbaharui
RC2 Menyimpan profil V V sistem akan tetap
instasi tanpa menyimpan data
mengedit profil instansi
walau tanpa di edit
dan Sistem
menampilkan
pesan bahwa sistem
telah di perbaharui
Sistem
mengosongkan 1 memberikan pesan
RC3 V V
kolom peringatan agar
melengkapi data
Data
Test
Scenario/Condition
Profil instasi di
perbaharui dan
Berhasil Mengedit
RC1 25 500 Sistem menampilkan
profil instansi
pesan bahwa sistem
telah di perbaharui
sistem akan tetap
menyimpan data
Menyimpan profil profil instansi walau
RC2 instasi tanpa 25 500 tanpa di edit dan
mengedit Sistem menampilkan
pesan bahwa sistem
telah di perbaharui
Sistem memberikan
mengosongkan 1 pesan peringatan
RC3 25 500
kolom agar melengkapi
data
**Tidak ada kesalahan ditemukan
3.8 Use Case Admin - Mengelola Profile

3.8.1 Edit Profil Admin
Basic Flow
1. Admin mengakses profil admin.
2. Admin mengklik profil admin saya.
3. Admin mengklik button edit profil admin.
4. Sistem akan menampilkan data profil admin.
Alternate Flow
1. Batal
Admin mengklik button batal maka sistem akan kembalik ke
laman profil admin.
2. Mengubah data nip menggunakan huruf

Admin memasukan huruf pada kolom nip lalu admin
menekan button simpan dan data tetap tersimpan.
3. Tidak melakukan perubahan.

Admin menekan tombol simpan tanpa melakukan perubahan
apapun, maka sistem akan menyimpan data profil user
dengan pesan data profil telah di perbaharui dan data yang
ditampilkan masih data yang lama.
Starting
Flow
Scenario I – Edit profil berhasil Basic Flow
Scenario II – input nip menggunakan
Basic Flow A1
huruf
Scenario III – edit tanpa perubahan Basic Flow A2
Form Profil Hasil yang

Test Scenario/Condition edit Diharapkan
Case
Id
Muncul pesan
RC1 Edit profil berhasil V V berhasil
mengupdate profil
input nip Muncul pesan
RC2 V X
menggunakan huruf peringatan
Muncul pesan
edit tanpa
RC3 V V berhasil
perubahan
mengupdate profil
Data
Test Hasil yang
Cas Scenario/Condition Form Diharapkan
Profil
e Id edit
Muncul pesan
RC1 Edit profil berhasil 25 500 berhasil mengupdate
profil
4000
input nip NB : Muncul pesan
RC2 25
menggunakan huruf False peringatan
: 3500
Muncul pesan
edit tanpa
RC3 25 500 berhasil mengupdate
perubahan
profil
***Hasil yang kami peroleh dari pengujian unit edit profil

admin adalah sistem tetap melakukan perubahan pada kolom
NIP yang seharus nya diisi angka, namun ketika kami isi
dengan huruf sistem tidak mendeteksi kesalahan dan tetap
tersimpan. Serta username tidak dapat diganti.
3.8.2 Ganti Password
Basic Flow
1. Admin mengakses profil admin.
2. Admin mengklik ganti password.
3. Admin menginputkan password baru dan password lama.
4. Admin mengklik button simpan.
5. Sistem akan memperbaharui password dan memberi pesan
password di perbaharui.
Alternate Flow
1. Batal
Admin mengklik button batal maka sistem akan kembalik
ke laman profil admin.
Admin tidak menginputkan apa apa dan langsung mengklik
button simpan.
Starting
Flow
Scenario I – ganti password berhasil Basic Flow
Scenario II – ganti password tanpa
Basic Flow A1
perubahan
Test Form
Hasil yang
Case profil Profil
Id saya
RC1 Ganti password V V Muncul pesan
berhasil berhasil
mengupdate
password
Ganti password Muncul pesan
RC2 V V
tanpa perubahan peringatan
Data
Test
Cas Form Hasil yang
Scenario/Condition
e Id profil Profil Diharapkan
saya
Muncul pesan
ganti password
berhasil
profil
4000
ganti password NB : Muncul pesan
RC2 25
tanpa perubahan False peringatan
: 3500
**Tidak ada kesalahan.
3.9 Use Case Kepsek – Transaksi Surat

3.9.1 Melihat Transaksi Surat Masuk
Basic Flow
1. Kepsek mengakses menu transaksi.
2. Kepsek memilih transaksi surat masuk.
3. Sistem akan menampilkan daftar transaksi surat masuk.
Alternate Flow
1. Kembali keberanda.
Kepsek memilih menu beranda maka sistem akan kembali
ke laman beranda kepala sekolah.
2. Cari data dengan kata kunci pencarian tidak sesuai.
Kepsek mencari surat dengan fitur pencarian namun
mencari surat yang tidak tersedia, maka sistem akan
menampilkan pesan tidak ada data yang ditemukan.
3. Mencetak disposisi surat
Kepsek mencetak disposisi surat berdasarkan surat yang
dipilih dengan menekan button print, maka sistem akan
dialihkan ke laman preview print cetak diposisi surat.
Starting
Flow
Scenario I – Lihat transaksi surat
Basic Flow
masuk berhasil
Scenario II – Cari data yang tidak
Basic Flow A1
ada
Scenario II – Cetak disposisi surat Basic Flow A2
Surat
Test Hasil yang
Masu View
Case Diharapkan
Scenario/Condition k
Id
Daftar surat
Lihat transaksi surat masuk
RC1 V V
masuk berhasil ditampilkan oleh
sistem.
Muncul pesan
Cari data yang tidak
RC2 V V tidak ada data
ada
yang ditemukan
RC3 Cetak disposisi surat V V Sistem dialihkan
ke laman print
disposisi surat
Data
Test Hasil yang
Case Scenario/Condition Surat Diharapkan
View
Id Masuk
Daftar surat masuk
Lihat transaksi surat
RC1 25 500 ditampilkan oleh
masuk berhasil
sistem.
4000
Muncul pesan tidak
Cari data yang tidak NB :
RC2 25 ada data yang
ada False
ditemukan
: 3500
Sistem dialihkan ke
RC3 Cetak disposisi surat 25 500 laman print
disposisi surat
3.9.2 Melihat Transaksi Surat Keluar

Basic Flow
1. Kepsek mengakses menu transaksi.
2. Kepsek memilih transaksi surat keluar.
3. Sistem akan menampilkan daftar transaksi surat masuk.
Alternate Flow
1. Kembali keberanda.
Kepsek memilih menu beranda maka sistem akan kembali
ke laman beranda kepala sekolah.
2. Cari data dengan kata kunci pencarian tidak sesuai.
Kepsek mencari surat dengan fitur pencarian namun
mencari surat yang tidak tersedia, maka sistem akan
menampilkan pesan tidak ada data yang ditemukan.
Starting
Flow
Scenario I – Lihat transaksi surat
Basic Flow
keluar berhasil
Scenario II – Cari data yang tidak
Basic Flow A1
ada
Test Surat Vie Hasil yang

Case Keluar w Diharapkan
Scenario/Condition
Id
Daftar surat
Lihat transaksi surat keluar
RC1 V V
keluar berhasil ditampilkan oleh
sistem.
Muncul pesan
Cari data yang tidak
RC2 V V tidak ada data
ada
yang ditemukan
Data
Test
Case Surat Hasil yang
Scenario/Condition View
Id Keluar Diharapkan
Daftar surat masuk
Lihat transaksi surat
RC1 25 500 ditampilkan oleh
masuk berhasil
sistem.
RC2 Cari data yang tidak 25 500 Muncul pesan
ada tidak ada data yang
ditemukan
**Tidak ada kesalahan ditemukan
3.10 Use Case Kepsek – Laporan Surat
Basic Flow
1. Kepsek mengakses menu laporan surat
2. Kepsek memilih laporan surat masuk atau laporan surat keluar
3. Kepsek menginputkan tanggal untuk melihat laporan surat
dengan rentang waktu tertentu.
4. Kepsek mengklik button tampilkan.
5. Sistem akan menampilkan laporan data surat masuk atau surat
berdasarkan tanggal yang diinputkan.
Alternate Flow
1. Kembali ke beranda
Kepsek memilih menu beranda, maka sistem akan kembali ke
laman beranda admin.
2. Menginput tanggal yang tidak terdaftar

Kepsek menginput tanggal yang tidak ada pencatatan suratnya
maka sistem akan menampilkan pesan tidak ada laporan surat.
3. Tidak menginput tanggal

Kepsek tidak memasukan tanggal sama sekali namun lamgsuk
mengklik button tampilkan maka sistem akan menampilkan
pesan peringatan untuk mengisi tanggal yang belum terisi
terlebih dahulu.
4. Cetak Laporan
Kepsek mencetak laporan dengan rentang waktu tertentu dengan
mengklik button print, maka sistem akan dialihkan ke laman
preview print laporan.
Starting
Flow
Scenario I – Lihat laporan surat
Basic Flow
berhasil
Scenario II – Tanggal salah Basic Flow A1
Scenario II – Print Laporan Basic Flow A3
Test Lapora Hasil yang

View
Case Scenario/Condition n Diharapkan
Id
Lihat laporan surat Laporan surat
RC1 masuk dan keluar V V dtampilakan
berhasil
Muncul pesan
RC2 Tanggal Salah V V tida ada data yang
ditemukan
Pesan peringatan
untuk mengisi
RC3 Tanggal Kosong V X
tanggak terlebih
dahulu
Sistem dialihkan
RC4 Print Laporan V V ke laman print
laporan surat
Data
Test
Case Scenario/Condition Laporan View Hasil yang
Id Diharapkan
Lihat laporan surat Laporan surat
RC1 masuk dan keluar 25 500 dtampilakan
berhasil
Muncul pesan
RC2 Tanggal Salah 25 500 tida ada data
yang ditemukan
Pesan peringatan
untuk mengisi
RC3 Tanggal Kosong 25 Empty
tanggak terlebih
dahulu
Sistem dialihkan
RC4 Print Laporan 25 500 ke laman print
laporan surat
**Hasil yang diperoleh laporan data surat yang ditampilkan
berdasarkan kapan surat itu diinput bukan berdasarkan tanggal
surat.
3.11 Use Case Kepsek – Galeri Surat Masuk

Basic Flow
1. Kepsek mengakses menu galeri
2. Kepsek memilih galeri surat masuk
3. Sistem akan menampilkan file surat yang telah diinput oleh
admin.
Alternate Flow
1. Kembali keberanda
2. Melihat isi surat

Kepsek memilih salah satu surat masuk untuk dilihat isi suratnya,
maka sistem akan menampilkan surat yang dipilih tersebut.
Starting
Flow
Scenario I – Lihat galeri surat masuk
Basic Flow
berhasil
Scenario II – Lihat salah satu surat Basic Flow A1
Test Hasil yang

Galeri View
Case Scenario/Condition Diharapkan
Id
Lihat galeri surat Galeri file surat
RC1 V V
berhasil dtampilakan
Lihat salah satu Menampilkan
RC2 V X
surat surat
Data
Test Hasil yang
Galeri View
Id
RC1 25 500
RC2 25 Empty
surat surat
**Hasil yang diperoleh dimana pada galeri file surat masuk kepala
sekolah tidak dapat melihat lebih detail isi surat tersebut.
3.12 Use Case Kepsek - Galeri Surat Keluar
Basic Flow
1. Kepsek mengakses menu galeri
2. Kepsek memilih galeri surat keluar
3. Sistem akan menampilkan file surat yang telah diinput oleh
admin.
Alternate Flow
1. Kembali keberanda
2. Melihat isi surat

Kepsek memilih salah satu surat keluar untuk dilihat isi suratnya,
maka sistem akan menampilkan surat yang dipilih tersebut.
Starting
Flow
Scenario I – Lihat galeri surat keluar
Basic Flow
berhasil
Scenario II – Lihat salah satu surat Basic Flow A1
Test Hasil yang

Galeri View
Id
RC1 V V
RC2 Lihat salah satu V X Menampilkan
surat surat
Data
Test Hasil yang
Galeri View
Id
RC1 25 500
RC2 25 Empty
surat surat
**Hasil yang diperoleh dimana pada galeri file surat keluar kepala
sekolah tidak dapat melihat lebih detail isi surat tersebut.
3.13 Use Case Kepsek – Profile

1. Edit profil Kepsek
Basic Flow
1. Kepsek mengakses profil
2. Kepsek mengklik profil
3. Kepsek mengklik button edit profil
4. Sistem akan menampilkan data profil.
Alternate Flow
1. Batal
Kepsek mengklik button batal maka sistem akan kembali ke
laman profil kepsek
2. Mengubah data nip menggunakan huruf
Kepsek memasukan huruf pada kolom nip lalu kepsek
menekan button simpan dan data tetap tersimpan.
Kepsek menekan tombol simpan tanpa melakukan perubahan
apapun, maka sistem akan menyimpan data profil user
dengan pesan data profil telah di perbaharui dan data yang
ditampilkan masih data yang lama.
Starting
Flow
Scenario I – Edit profil berhasil Basic Flow
Scenario II – input nip menggunakan
Basic Flow A1
huruf
Scenario III – edit tanpa perubahan Basic Flow A2

Profil
Case edit Diharapkan
Scenario/Condition
Id
Muncul pesan
RC1 Edit profil berhasil V V berhasil
mengupdate profil
input nip Muncul pesan
RC2 V X
menggunakan huruf peringatan
Muncul pesan
edit tanpa
RC3 V V berhasil
perubahan
mengupdate profil

Data
Test
Cas Form Hasil yang
Scenario/Condition Profil
e Id edit Diharapkan
Muncul pesan
RC1 Edit profil berhasil 25 500 berhasil mengupdate
profil
4000 Muncul pesan
input nip NB : peringatan
RC2 25
menggunakan huruf False
: 3500
Muncul pesan
edit tanpa
perubahan
profil
***Hasil yang kami peroleh dari pengujian unit edit profil
kepala sekolah adalah sistem tetap melakukan perubahan pada
kolom NIP yang seharus nya diisi angka, namun ketika kami isi
dengan huruf sistem tidak mendeteksi kesalahan dan tetap
tersimpan.
2. Ganti password
Basic Flow
1. Kepsek mengakses profil kepsek.
2. Kepsek mengklik ganti password.
3. Kepsek menginputkan password baru dan password lama.
4. Kepsek mengklik button simpan.
5. Sistem akan memperbaharui password dan memberi pesan
password di perbaharui.
Alternate Flow
1. Batal
Kepsek mengklik button batal maka sistem akan kembalik ke
laman profil admin.
Kepsek tidak menginputkan apa apa dan langsung mengklik
button simpan
Starting
Flow
Scenario I – ganti password Basic Flow
Scenario II – ganti password tanpa
Basic Flow A1
perubahan
Form
Test Hasil yang
profil Profil
Case Diharapkan
Scenario/Condition saya
Id
Muncul pesan
ganti password berhasil
RC1 V V
berhasil mengupdate
password
ganti password Muncul pesan
RC2 V V
Data
Test
Cas Form Hasil yang
e Id Scenario/Condition profil Profil Diharapkan
saya
Muncul pesan
ganti password
berhasil
profil
RC2 ganti password 25 500 Muncul pesan
Hasil Yang diperoleh dari pengujian unit :
Sistem informasi pengarsipan surat pada SDN 1 Karangklesem ini sudah cukup baik
namun masih ada kesalahan kecil, namun dapat membuat sistem menjadi kurang ufisien
dalam pemakaiannya. Berdasarkan beberapa pengujian yang kami lakukan kami menemukan
beberapa kekurangan pada sistem ini yakni :
1. Pada admin melakukan proses penginputan surat masuk dan surat keluar, hasil yang
kami peroleh dimana proses penambahan data surat tetap berhasil walaupun tidak
menginputkan lampirkan file surat masuk dan keluarnya.
2. Pada admin melakukan proses pengeditan data surat masuk dan surat, keluar hasil
yang kami peroleh dimana saat kita mengubah kode surat dengan kode surat yang
tidak terdaftar tidak ada pesan kesalahan dari sistem namun data tetap tersimpan pada
sistem dengan kode surat sebelumnya.
3. Pada admin dan kepala sekolah melakukan proses pencarian data surat masuk dan
surat keluar, hasil yang kami peroleh dimana pada pencarian laporan surat ini surat
yang ditampilkan bukan berdasarkan tanggal surat melainkan berdasarkan tanggal
surat diinput kesistem.
4. Pada saat admin menambah user, hasil yang diperoleh dimana tidak ada pesan
peringatan pada saat pengisian data user namun tidak memilih level akun.
5. Pada perubahan profil admin, Hasil yang kami peroleh dari pengujian unit edit profil
admin adalah sistem tetap melakukan perubahan pada kolom NIP yang seharus nya
diisi angka, namun ketika kami isi dengan huruf sistem tidak mendeteksi kesalahan
dan tetap tersimpan. Serta username tidak dapat diganti.
6. Hasil yang diperoleh dimana pada galeri file surat keluar kepala sekolah tidak dapat
melihat lebih detail isi surat tersebut.
7. Hasil yang kami peroleh dari pengujian unit edit profil kepala sekolah adalah sistem
tetap melakukan perubahan pada kolom NIP yang seharus nya diisi angka, namun
ketika kami isi dengan huruf sistem tidak mendeteksi kesalahan dan tetap tersimpan.
F. Pengujian Integrasi
Disini menggunakan integrasi incremental yaitu membangun program dengan cara
menguji per modul kecil atau per segmen, kemudian digabung menjadi menu utama.
Pada pengujian integrasi ini terdapat beberapa jenis atau macam yaitu :
1. TOP DOWN Integration

Adalah pengujian yang menggunakan pendekatan inkremental terhadap
Struktur program. Pengujian berlangsung dari atas ke bawah, mengikuti aliran
kontrol atau struktur arsitektur.
Keterangan :
i. Setelah user berhasil login terdapat menu utama/beranda/home
ii. Beranda, Merupakan halaman awal yang ditampilkan ketika user telah berhasil
masuk kedalam sistem / telah berhasil login.
iii. Transakasi, Merupakan halaman untuk mengolah (input, edit, hapus) surat
masuk dan surat keluar yang dilakukan oleh admin sedangkan kepala sekolah
hanya dapat hasil pengeloalahan surat tersebut.
iv. Laporan, Merupakan halaman untuk menampilkan laporan data surat masuk dan
surat keluar.
v. Master Data, Merupakan halaman untuk menngelolah data pemgguna dan kode
surat.
vi. Profil User , berisi keterangan biodata pengguna.
2. BOTTOM UP Integration
Pengujian integrasi dari bawah keatas (bottom-up integration) memulai
pengujian dari modul yang paling kecil kemodul yang lebih besar. Pengujian dari
bawah keatas sering dilakukan untuk pengembangan perangkat lunak yang tidak
menggunakan alur prototipe sehingga perangkat lunak dibangun dari modul-modul
yang kecil ke modul-modul yang besar sesuai dengan hirarki pemakainya.
Integrasi Bottom-Up, dimulai dengan pengujian modul atomik yaitu modul
program pada tingkat paling rendah pada struktur program. Karena diintegrasikan
dari bawah ke atas maka pemrosesan yang diperlukan selalu ada dan kebutuhan
script dapat dieliminasi.
3. Regresion Integrasi
Pengujian regresi merupakan eksekusi ulang untuk memastikan bahwa perubahan
tidak menimbulkan efek samping.Setiap modul baru ditambahkan sebagai bagaian
dari integrasi maka kondisi perangkat lunak menjadi berubah. Hal ini mungkin saja
menyebabkan masalah pada fungsionalitas yang sudah diuji sebelumnya. Pengujian
regresi (regression) adalah eksekusi dari beberapa subset pengujian yang sudah
terhubung atau saling terkait untuk menjamin bahwa modul yang baru masuk
pengujian tidak mengubah fungsionalitas yang sudah diuji sebelumnya.
()
4. Pengujian Smoke
Smoke Testing adalah jenis sofware testing yang dilakukan setelah software di
build/dibangun untuk memastikan bahwa fungsi penting dari program bekerja
dengan baik. Tujuannya adalah untuk reject aplikasi yang sudah rusak sejak awal
development, sehingga tim QA tidak membuang-buang waktu menginstal dan
menguji aplikasi perangkat lunak. Untuk Contoh Smoke testing adalah Memastikan
aplikasi berhasil login, GUI Responsive dll, yang bersifat dasar-dasar aplikasi.
Aplikasi ini tidak bisa berjalan tanpa internet karena semua file sudah di upload ke
hosting. Tetapi untuk saat ini, karena masa berlaku hosting sudah habis maka kami
menggunakan localhost untuk menjalankan apikasi ini sehingga bisa berjalan.Tetapi
apabila aplikasi ini sudah menggunakan hosting dan filenya semua sudah di upload
ke hosting makaapabila tidak ada internet maka aplikasi ini tidak bisa di buka.
Tujuan Integration Testing

 Memeriksa apakah aplikasi berfungsi sesuai yang dengan apa diharapkan
 Memeriksa kinerja dari aplikasi yang dihasilkan
 Mengetes kehandalan dari struktur program yang sudah dirancang sebelumnya
G. Kesimpulan

Contoh LAPORAN PENGUJIAN IMPLEMENTASI

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Contoh LAPORAN PENGUJIAN IMPLEMENTASI

Diunggah oleh

Hak Cipta:

Format Tersedia

LAPORAN PENGUJIAN IMPLEMENTASI

PADA SISTEM INFORMASI PENGARSIPAN SURAT PADA

SEKOLAH TINGGI ILMU KOMPUTER YOS SUDARSO

No Jenis Analisis Kelemahan Sistem yang Sistem yang Dibuat

2. Kebutuhan Non Fungsional

No Indikator Ket Hasil yang diperoleh

1.2 Product Revision

No Indikator Ket Hasil yang diperoleh

1.3 Product Transition

No Indikator Ket Hasil yang diperoleh

Faktor/ Tolak Ket Alasan

Masing-masing karakteristik kualitas perangkat lunak model ISO 9126 dibagi

No Indikator Ket Hasil yang diperoleh

(b) ISO 9126-Reliability.

No Indikator Ket Hasil yang diperoleh

(c) ISO 9126-Usability.

No Indikator Ket Hasil yang diperoleh

(d) ISO 9126-Efficiency.

No Indikator Ket Hasil yang diperoleh

(e) ISO 9126-Maintainability.

No Indikator Ket Hasil yang diperoleh

(f) ISO 9126-Portability

No Indikator Ket Hasil yang diperoleh

Penggunaan ISO/IEC 25010 dalam perancangan suatu perangkat lunak juga

Karakteristik model ISO/IEC 25010 antara lain :

No Karakteristik Sub Karakteristik Deskripsi

No. Indikator Ke Hasil yang diperoleh

Beberapa alasan mengapa unit testing penting adalah:

1.1 Use Case Diagram Umum

1.2 Use Case Diagram Admin

3) Sequence Diagram Input Surat masuk dan surat keluar

5) Sequence Diagram Tambah Kode Surat

7) Sequence Diagram Ubah Profil Instansi

9) Sequence Diagram Hapus Surat

10) Sequence Diagram Melihat Data Surat

2. Tidak memasukan username atau password.

3. Tidak memasukan username dan password

3.1.2 Generate Scenario

Scenario Name Starting Alternate

Scenario II – User salah memasukan Basic Flow A1

3.1.3 Identify Test Case

Test Input Hasil yang

3.1.4 Identify Data Value

3.2 Use Case Admin - Mengelola Data Surat

2. Menambahkan surat dengan lampiran dokumen

3. Tidak memasukan lampiran dokumen surat.

 Identify Test Case

** Hasil yang kami peroleh dimana proses penambahan data surat

3.2.2 Menambah data surat keluar

2. Menambahkan surat dengan lampiran dokumen

3. Tidak memasukan lampiran dokumen surat.

 Identify Test Case

 Identify Data Value

** Hasil yang kami peroleh dimana proses penambahan data surat

3.2.3 Mengubah data surat masuk.

2. Mengubah kode surat dengan kode surat yang tidak

3. Tidak melakukan perubahan apapun.

 Identify Test Case

 Identify Data Value

3.2.4 Mengubah data surat keluar

3. Tidak melakukan perubahan apapun.

 Identify Test Case

 Identify Data Value

3.2.5 Menghapus data surat keluar.