Anda di halaman 1dari 31

DOKUMEN PENGUJIAN PERANGKAT LUNAK

SISTEM INVENTARIS PT. ANTAR SURYA MEDIA

Disusun Oleh :
Rasita Alfiyah R.

(115060807111105)

Rinadewi Astuti

(115060807111028)

Vina Angelia

(115060801111079)

Jakti Kinayung Prasojo

(115060807111052)

Luluk Setiawati Hartono

(115060801111056)

Dosen Pengampu :
Aditya Rachmadi, S.ST., M.TI

PROGRAM TEKNOLOGI INFORMASI DAN ILMU KOMPUTER


PROGRAM STUDI ILMU KOMPUTER
UNIVERSITAS BRAWIJAYA
MALANG
2014

TEST PLAN
1.

Test Plan Identifier


Pada pengujian perangkat lunak ini akan diuji sistem Inventaris PT. Antar

Surya Media. Sistem ini dibuat dengan tujuan untuk memudahkan pegawai untuk
inventaris barang pada PT Antar Surya Media. Pengujian ini akan dilakukan pada
fitur permintaan barang untuk memastikan semua fungsi sistem dapat diakses
dengan baik oleh user. Pada fitur Permintaan Barang, user dapat melihat detail
permintaan barang, mengedit permintaan barang, menghapus permintaan barang,
mencetak permintaan barang, dan menambah data permintaan baru. Tahapan
pengujian yang akan dilakukan yaitu dengan State Transition dan Basis Path.
2.

Introduction
Introduction terdiri dari objectives, background, scope, dan references dari

test plan PT. Antar Surya Media.


2.1

Objectives
Test plan sistem Inventaris PT. Antar Surya Media dibuat untuk mendukung

tujuan sebagai berikut:


Untuk detail kegiatan yang diperlukan untuk mempersiapkan dan
melakukan test plan, termasuk menentukan jadwal pengujian
Untuk berkomunikasi dengan semua pihak yang bertanggung jawab
kepada setiap tugas.
Untuk menentukan alat uji dan environment yang dibutuhkan untuk
melakukan test sistem.
Untuk menentukan sumber informasi yang digunakan untuk menyiapkan
plan
Untuk mengidentifikasi testing task yang akan dilakukan, dan fitur yang
akan diuji
Untuk mengidentifikasi resiko yang terkait dengan plan
2.2

Background

Semua aktivitas inventaris barang yang ada pada PT. Antar Surya Media
masih dilakukan dengan manual menggunakan kertas dan microsoft excel.
Dengan sistem perangkat lunak ini dapat menghemat efisiensi dari proses
penambahan permintaan barang, dan rekap laporan data permintaan barang yang
ada di PT. Antar Surya Media. Adapun lingkup testing yang akan di jalankan
antara lain meliputi komponen sistem, software aplikasi, desain interface,
arsitektur program aplikasi serta penggunaan dari software. Pengujian dilakukan
untuk mengurangi terjadinya kesalahan dan software dapat berjalan sesuai dengan
yang diharapkan.
2.3

Scope
Ruang lingkup dari test plan yang akan di jalankan meliputi pengujian source

code, fungsi dari masing-masing halaman program, desain interface dan


performance program. Dalam pengujian program menggunakan metode basis
path, decision table, equivalent partitioning dan state transition.
2.4

References

Sumber dokumen yang digunakan untuk membuat test plan, antara lain:
- IEEE Standard for Software Test Documentation
- Laporan KKN-P Sistem Inventaris PT. Antar Surya Media
3. Test items
Test item berisi kebutuhan-kebutuhan fungsional dan non-fungsional, antara
lain sebagai berikut :
3.1

Kebutuhan Fungsional

1.

Website mampu menambahkan daftar barang yang telah di inputkan user

2.

Website mampu menambahkan data permintaan barang

3.

Website mampu menampilkan halaman laporan permintaan barang semua


karyawan PT Antar Surya Media

4.

Website dapat mencetak data permintaan barang sesuai yang diinputkan


oleh user

5.

Website dapat mencetak laporan permintaan barang.


Kebutuhan fungsional di atas dapat digambarkan dalam usecase diagram

berikut ini.

3.2

Kebutuhan Non Fungsional

1.

Availibility : sistem harus mampu digunakan dalam jangka waktu 24 jam


sehari. 7 hari seminggu.

2.

Usability : sistem ini dapat digunakan dengan mudah oleh pengguna yang
ingin menggunakan sistem Inventaris PT Antar Surya Media.

3.

User Friendly : membangun sistem agar user friendly agar mudah


digunakan oleh pengguna.

4. Features to be tested
Specification number

Description

AS-F -01

Fitur Login

AS-F-07

Fitur Tambah Permintaan Barang

AS-F -04

Fitur Tambah Barang

AS-F- 12

Fitur Laporan Detail

5. Features not to be tested

Specification number

Description

AS-F -02

Fitur Lihat Daftar Barang

AS-F -03

Fitur Lihat Permintaan Barang

AS-F -05

Fitur Edit Barang

AS-F -06

Fitur Edit Permintaan

AS-F -08

Fitur Cetak Permintaan

AS-F -09

Fitur Hapus Permintaan

AS-F -10

Fitur Lihat Detail Permintaan

AS-F- 11

Fitur Laporan Header

Fitur diatas tidak termasuk ke dalam pengujian karena merupakan penunjang


dari fitur Tambah Permintaan Barang dan tidak semua fitur tersebut dapat di tes
dengan metode yang dipilih.
6.

Approach

Pendekatan yang digunakan pada testing ini adalah metode basis path, decision
table, equivalent partition, dan state transition.
1. Pengujian White Box
White Box Testing merupakan cara pengujian dengan melihat ke dalam modul
untukmeneliti kode-kode program yang ada, dan menganalisis apakah ada
kesalahan atau tidak. Jika ada modul yang menghasilkan output yang tidak sesuai
dengan proses bisnis yang dilakukan, maka baris-baris program, variabel, dan
parameter yang terlibat pada unit tersebut akan dicek satu persatu dan diperbaiki,
kemudian di-compile ulang. Teknik yang digunakan pada pengujian white box
adalah basis path testing.
a. Basis path testing
Pengujian white box yang dibuat berdasarkan ukuran tingkat kompleksitas
dari algoritma hasil perancangan
Langkah-langkah :
Mendefinisikan flow graph berdasarkan mapping dari flow chart atau struktur

dari algoritma
Menentukan ukuran kompleksitas (cyclomatic complexity)

Mendefinisikan kasus uji

2. Pengujian Black Box


Untuk memastikan bahwa fitur berjalan sesuai dengan desain kebutuhan
pengguna. Selain itu pengujian ini juga digunakan untuk memastikan bahwa fitur
dapat diakses oleh pengguna yang memiliki hak akses terhadap fitur tersebut.
Teknik pengujian blackbox yang digunakan adalah decision table dan equivalent
partition.
a. Decision table
Decision Table digunakan untuk menguji logika bisnis pada sistem, pengujian
ini termasuk black box testing, di mana terdiri dari kondisi dan actions (tindakan).
Kondisi adalah masukan yang memiliki expexted output yang benar, Tindakan
adalah bentuk-bentuk aturan yang masing-masing harus menjadi test case.
b. Equivalent Partition
Equivalent Partition adalah metode black box testing yang membagi domain
masukan dari suatu program ke dalam kelas-kelas data, dimana test cases dapat
diturunkan. Equivalence partition berdasarkan pada premis masukan dan keluaran
dari suatu komponen yang dipartisi ke dalam kelas-kelas, menurut spesifikasi dari
komponen tersebut, yang akan diperlakukan sama (ekuivalen) oleh komponen
tersebut.
7.

Item pass / fail criteria


Sistem harus memenuhi persyaratan agar metode pengujian dikatakan sukses

atau gagal dalam memenuhi kriteria yang dibutuhkan sistem.


a.
Sukses

Pengujian White Box


: jika setiap baris kode program dapat berjalan sesuai dengan

ranacangan sistem.
Gagal

: jika baris kode program menyebabkan aplikasi error atau ada baris

kode program yang tidak berjalan sebagaimana mestinya.


b. Pengujian Black Box

Sukses

: jika sistem dapat menjalankan fitur fitur dan proses bisnis yang

sesuai dengan diagram use case.


Gagal

: jika sistem menjalankan fitur yang tidak sesuai dengan diargram use

case.
8. Suspension criteria and resumption requirements
Apabila ada 2 atau lebih penguji yang berhalangan, maka pengujian

berhenti sementara karna hanya ada 5 penguji


Pengujian dilakukan jika program telah selesai dikerjakan
Menentukan kriteria yang digunakan untuk menangguhkan semua atau
sebagian dari kegiatan pengujian pada item tes yang terkait dengan plan
ini. Disini ditentukan kegiatan pengujian yang harus diulang saat
pengujian.

9.

Test deliverables
Dokumentasi test plan ini membahas mengenai rencana proses pengujian

system yang dilakukan oleh orang yang ditunjuk (tester) untuk melakukan
pengecekan terhadap modul dan fungsi yang ada pada aplikasi dan mencari error
atau bug yang ada pada sistem. Dokumen test plan ini terdiri dari hal-hal berikut
ini:
a.

Test Design Specification


Test design specification adalah pengujian tahap pertama didalam suatu

pengujian perangkat lunak. Tes ini tentang gambaran abstrak dari rancangan
software yang menjadi dasar pengujian bagi perancangan dan implementasi yang
lebih detil. Dokumen test design ini sering dilupakan karena penguji langsung
memulai test case sebelum memutuskan apa yang mereka uji yang terdapat di test
design specification.
b.

Test Case Specification :


Test Case Specification dilaksanakan setelah tahap test design specification.

Test case ini menjelaskan tujuan dari specific test, mengidentifikasi masukan yang
dibutuhkan dan hasil yang diharapkan, menyediakan prosedur langkah-demilangkah untuk melaksanakan pengujian. Test case yang baik memiliki probabilitas

yang tinggi untuk menentukan kesalahan yang belum pernah ditemukan


sebelumnya.
c.

Test Procedure Specification :


Sebuah detail tentang prosedur bagaimana seorang tester akan melakukan

pengujian, pengaturan yang diperlukan, dan langkah-langkah prosedur yang harus


diikuti.
d.

Test Summary Reports


Laporan yang berisikan tentang hasil kesimpulan dari keseluruhan

pengujian yang telah dilakukann terhadap modul yang dipilih, yaitu Permintaan
Barang.
10.

Testing tasks
Tasks

Day

Test design
Test case
Test plan
Test procedure
Module Driver Development
Test Execution
Module Revision
Test Reporting
11.

Environmental needs
Pada bagian ini akan menjelaskan mengenai brainware, software maupun

hardware dari system yang diteliti.


a.

Brainware
Staff divisi dalam PT Antar Surya Media

b.

Hardware
Pembuatan sistem aplikasi inventaris PT. Antar Surya Media dikerjakan

dengan menggunakan laptop dengan spesifikasi standart sebagai berikut :


-

Processor

: Intel(R) Core(TM) i3 CPU M350 2,27 GHz

Memory

: 2048 Mb

VGA

: 1024 Mb

Harddisk

: 500 Gb

c.

Software
Pembuatan

sistem

aplikasi

inventaris

PT.

Antar

Surya

Media

membutuhkan beberapa software utama yang diperlukan untuk kepentingan


aplikasi, selain itu juga membutuhkan beberapa software pendukung untuk
dokumentasi dan perancangan. Perangkat lunak yang dibutuhkan adalah sebagai
berikut :
1. Notepad++
2. Corel Draw X6
3. XAMPP
4. Browser (Google Chrome, Mozilla Firefox)
d.

Sistem operasi
Sistem Operasi yang digunakan adalah Multi Platform (Windows dan Linux)

e.

Bahasa Pemrograman
Dalam membangun sistem inventaris PT. Antar Surya Media ini

menggunakan beberapa bahasa pemrograman agar aplikasi sistem memiliki


performa yang bagus. Bahasa pemrograman tersebut antara lain :
1. HTML
2. PHP
3. Javascript
4. Ajax
12.
a.
b.
c.
d.
e.

Responsibilities
Rasita Alfiyah Rochmawati : Project Manager, Test Plan
Vina Angelia
: Test Plan, Test Summary
Rinadewi Astuti
: Test Design, Test Procedure
Jakti Kinayung Prasojo
: Test Procedure, Test Summary
Luluk Setiawati Hartono
: Test Plan, Test Summary

TEST DESIGN SPECIFICATION


1.

Test design specification identifier


Pengujian yang dilakukan menggunakan white box testing dan black box

testing pada sistem inventaris PT Surya ini adalah proses login, penambahan
barang, penambahan permintaan barang dan laporan detail. Pengujian ini
dilakukan pada fitur login untuk memastikan semua fungsi sistem dapat diakses
oleh divisi-divisi yang melakukan fitur penambahan barang, penambahan
permintaan barang dan laporan detail dalam sistem.
2.

3.

4.

Features to be tested
Specification number

Description

AS-F -01

Fitur Login

AS-F-07

Fitur Tambah Permintaan Barang

AS-F -04

Fitur Tambah Barang

AS-F- 12

Fitur Laporan Detail

Features not to be tested


Specification number

Description

AS-F -02

Fitur Lihat Daftar Barang

AS-F -03

Fitur Lihat Permintaan Barang

AS-F -05

Fitur Edit Barang

AS-F -06

Fitur Edit Permintaan

AS-F -08

Fitur Cetak Permintaan

AS-F -09

Fitur Hapus Permintaan

AS-F -10

Fitur Lihat Detail Permintaan

AS-F- 11

Fitur Laporan Header

Approach refinements
Pemilihan metode pada pengujian ini adalah :

Pendekatan yang digunakan pada testing ini adalah metode basis path, decision
table, equivalent partition, dan state transition.

10

10

1.

Pengujian White Box


White Box Testing merupakan cara pengujian dengan melihat ke dalam modul

untukmeneliti kode-kode program yang ada, dan menganalisis apakah ada


kesalahan atau tidak. Jika ada modul yang menghasilkan output yang tidak sesuai
dengan proses bisnis yang dilakukan, maka baris-baris program, variabel, dan
parameter yang terlibat pada unit tersebut akan dicek satu persatu dan diperbaiki,
kemudian di-compile ulang. Teknik yang digunakan pada pengujian white box
adalah basis path testing.
a. Basis path testing
Pengujian white box yang dibuat berdasarkan ukuran tingkat kompleksitas
dari algoritma hasil perancangan
Langkah-langkah :
Mendefinisikan flow graph berdasarkan mapping dari flow chart atau struktur

2.

dari algoritma
Menentukan ukuran kompleksitas (cyclomatic complexity)
Mendefinisikan kasus uji
Pengujian Black Box
Untuk memastikan bahwa fitur berjalan sesuai dengan desain kebutuhan

pengguna. Selain itu pengujian ini juga digunakan untuk memastikan bahwa fitur
dapat diakses oleh pengguna yang memiliki hak akses terhadap fitur tersebut.
Teknik pengujian blackbox yang digunakan adalah decision table dan equivalent
partition.
a. Decision table
Decision Table digunakan untuk menguji logika bisnis pada sistem, pengujian
ini termasuk black box testing, di mana terdiri dari kondisi dan actions (tindakan).
Kondisi adalah masukan yang memiliki expexted output yang benar, Tindakan
adalah bentuk-bentuk aturan yang masing-masing harus menjadi test case.
b. Equivalent Partition
Equivalent Partition adalah metode black box testing yang membagi domain
masukan dari suatu program ke dalam kelas-kelas data, dimana test cases dapat
diturunkan. Equivalence partition berdasarkan pada premis masukan dan keluaran
dari suatu komponen yang dipartisi ke dalam kelas-kelas, menurut spesifikasi dari

11

komponen tersebut, yang akan diperlakukan sama (ekuivalen) oleh komponen


tersebut.
5.

Test identification
- Login, user memasukkan username dan password ke form login, jika
-

berhasil maka masuk ke halaman tampilan awal


Lihat daftar barang, usir dapat melihat daftar barang yang ada di kantor
Surya, pada menu daftar barang terdapat submenu yaitu tambah barang

dan edit barang.


Lihat permintaan barang, pada menu ini terdapat list dari permintaan
barang oleh user untuk melihat semua permintaan barang. Terdapat
submenu yaitu tambah edit permintaan barang untuk mengedit permintaan
yang telah diiputkan. Selain itu hapus permintaan barang untuk

menghapus permintaan barang, selain itu terdapat submenu


Tambah permintaan untuk menambahkan permintaan barang
Cetak permintaan untuk mencetak permintaan yang diisi secara otomatis
Hapus permintaan untuk membatalkan permintaan barang
Lihat detail permintaan untuk melihat secara detail nama barang jumlah
unit semua yang mengenai tentang permintaan barang

6.

Feature pass / fail criteria

Dalam melakukan pengujian pada parameter sukses yang digunakan adalah:


1. Pengujian Fungsionalitas
Sukses
Jika fitur yang diuji dapat berjalan dengan benar sesuai dengan dokumen use
case.
Error
Jika terdapat beberapa fungsi yang tidak berjalan sehingga menggangu
operasi dalam memenuhi kebutuhan.
2. Pengujian Validasi Data
Parameter yang digunakan dalam pengujian validasi data adalah :
Sukses
Jika data yang diuji adalah data yang valid dan sesuai dengan sistem database
kantor.
Gagal
Jika data yang ditampilkan aplikasi tidak sesuai dengan data yang ada di
database atau dengan data yang sesunggunya.

12

3. Pengujian Robustness
Parameter yang digunakan dalam pengujian robustness adalah:
Sukses
Jika pengguna dapat memasukkan data dengan format dan tipe yang benar
sesuai dengan form input. Jika data yang dimasukkan salah maka sistem
dapat melakukan peringatan.
Gagal
Ketika pengguna memasukkan data dengan format dan tipe yang salah, maka
sistem tidak dapat memberikan peringatan.

TEST CASE SPECIFICATION


1.

Test case specification identifier


Pengujian yang dilakukan menggunakan white box testing dan black box

testing pada sistem inventaris PT Surya ini adalah proses login, penambahan
barang, penambahan permintaan barang dan laporan detail. Pada test case
specification ini akan dibahas case-case yang berhubungan dengan fitur yang akan
diuji.
2.

Test items
Test item berisi kebutuhan-kebutuhan fungsional dan non-fungsional, antara

lain sebagai berikut :


2.1 Kebutuhan Fungsional
1.

Website mampu menambahkan daftar barang yang telah di


inputkan user

2.

Website mampu menambahkan data permintaan barang

3.

Website mampu menampilkan halaman laporan permintaan


barang semua karyawan PT Antar Surya Media

4.

Website dapat mencetak data permintaan barang sesuai yang


diinputkan oleh user

5.

Website dapat mencetak laporan permintaan barang.

2.2 Kebutuhan Non Fungsional


1.

Availibility : sistem harus mampu digunakan dalam


jangka waktu 24 jam sehari. 7 hari seminggu.

2.

Usability : sistem ini dapat digunakan dengan


mudah oleh pengguna yang ingin menggunakan sistem Inventaris PT Antar
Surya Media.

3.

User Friendly : membangun sistem agar user


friendly agar mudah digunakan oleh pengguna.

3.

Input specifications
a. Fitur Login

14

14

No.

Test Item

Skenario Pengujian

Valid Value

Username Masukkan angka

Memasukkan huruf

Username Masukkan huruf

Memasukkan huruf

Password

Memasukkan
Memasukkan
kombinasi
angka kombinasi
angka
dengan huruf
dengan huruf

Password

Memasukkan huruf

Memasukkan huruf

Password

Memasukkan angka

Memasukkan angka

b. Fitur Tambah Permintaan Barang

4.

No.

Test Item

Skenario Pengujian

Valid Value

Daftar
Barang

Memilih barang yang Memilih


barang
ada pada list barang
yang ada pada list
barang

Daftar
Barang

Tidak
memilih Memilih
barang
barang yang ada yang ada pada list
pada list barang
barang

Jumlah
Pengadaa
n

Memasukkan huruf

Jumlah
pengadaa
n

Memasukkan
Memasukkan angka
kombinasi angka dan
huruf

Jumlah
Pengadaa
n

Masukkan angka

Memasukkan angka

Skenario Pengujian

Hasil
diharapkan

Memasukkan angka

Output specifications
a. Fitur Login
No.

Test Item

Username Masukkan angka

Keluaran angka

Username Masukkan huruf

Keluaran huruf

Password

yang

Memasukkan
Keluaran
symbol
kombinasi
angka bulat
yang
di

15

dengan huruf

enkripsi

Password

Memasukkan huruf

Keluaran
symbol
bulat
yang
di
enkripsi

Password

Memasukkan angka

Keluaran
symbol
bulat
yang
di
enkripsi

b. Fitur Tambah Permintaan Barang

5.

No.

Test Item

Skenario Pengujian

Hasil
diharapkan

yang

Daftar
Barang

Memilih barang yang Aplikasi


ada pada list barang
menampilkan pilihan
barang dan form
tambah barang yang
akan dipilih

Daftar
Barang

Tidak
memilih Aplikasi
tidak
barang yang ada menampilkan pilihan
pada list barang
barang dan form
tambah barang yang
akan dipilih

Jumlah
Pengadaa
n

Memasukkan huruf

Jumlah
pengadaa
n

Memasukkan
Aplikasi
tidak
kombinasi angka dan menyimpan
data
huruf
pengadaan barang

Jumlah
Pengadaa
n

Masukkan angka

Aplikasi
tidak
menyimpan
data
pengadaan barang

Aplikasi menyimpan
data
pengadaan
barang

Environmental needs
Pada bagian ini akan menjelaskan mengenai brainware, software maupun

hardware dari system yang diteliti.


a.

Brainware
Staff divisi dalam PT Antar Surya Media

b.

Hardware

16

Pembuatan sistem aplikasi inventaris PT. Antar Surya Media dikerjakan


dengan menggunakan laptop dengan spesifikasi standart sebagai berikut :

c.

Processor

: Intel(R) Core(TM) i3 CPU M350 2,27 GHz

Memory

: 2048 Mb

VGA

: 1024 Mb

Harddisk

: 500 Gb

Software
Pembuatan

sistem

aplikasi

inventaris

PT.

Antar

Surya

Media

membutuhkan beberapa software utama yang diperlukan untuk kepentingan


aplikasi, selain itu juga membutuhkan beberapa software pendukung untuk
dokumentasi dan perancangan. Perangkat lunak yang dibutuhkan adalah sebagai
berikut :
1.

Notepad++

2.

Corel Draw X6

3.

XAMPP

4.

Browser (Google Chrome, Mozilla Firefox)

d. Sistem operasi

Sistem Operasi yang digunakan adalah Multi Platform (Windows dan Linux)
e. Bahasa Pemrograman
Dalam membangun sistem inventaris PT. Antar Surya Media ini
menggunakan beberapa bahasa pemrograman agar aplikasi sistem memiliki
performa yang bagus. Bahasa pemrograman tersebut antara lain :
1.

HTML

2.

PHP

3.

Javascript

4.

Ajax

TEST PROCEDURE SPECIFICATION


1.

Test Procedure Specification Identifier


Pengujian yang dilakukan menggunakan white box testing dan black box

testing pada sistem inventaris PT Surya ini adalah proses login, penambahan
barang, penambahan permintaan barang dan laporan detail. Pada test procedure
specification ini akan dibahas mengenai procedure dari fitur yang diuji.
2.

Purpose

Untuk membantu user dalam melakukan permintaan barang yang


dibutuhkan

Untuk mempermudah super user dalam dokumentasi permintaan barang


inventaris

3.

Special requirement

Mempunyai akun di web system inventaris PT Surya Media

Data yang diminta harus relevan

Barang yang diminta, jika belum ada harus didaftarkan dulu di daftar
barang

4.

Procedure steps
Login
Aksi Aktor

Sistem

1. Masuk ke halaman awal system


2. Mengisi
username
dan
password

3. Cek validasi data


4. Jika benar, user masuk ke
halaman user.
5. Jika
salah,
user
harus
menginputkan ulang username
dan password

Tambah Barang
Aksi Aktor

Sistem

18

18

5.

Pilih menu Barang


Memilih menu tambah data
Input nama barang yang diminta
Input kisaran harga barang

6.

Klik tombol save

1.

2.
4.

3. Tampil form tambah barang

7. Keluar

dari halaman tambah


barang, dan kembali ke list daftar
barang

Tambah Permintaan Barang


Aksi Aktor

Sistem

1.
2.
4.

Pilih menu permintaan barang


Memilih menu tambah data
Memilih menu tambah permintaan

3.
5.

6.

Input nama barang yang diminta

7.
8.

9.

Tampil halaman tambah permintaan


Menampilkan halamanajax tambah
barang
Mengambil data dari database tabel
barang
Menampilkan
data
barang
keseluruhan pada tabel

Input jumlah pengadaan barang

10. Klik tombol simpan


13. Klik tombol save

11. Tampilan ajax keluar


12. Menampilkan permintaan barang
yang sudah disimpan
14. Keluar dari halaman permintaan
barang, kembali ke halaman
permintaan user
15. Tampil data permintaan yang sudah
diinputkan user

Laporan detail

Aksi Aktor
1. Pilih menu Laporan Detail

Sistem
2. Menampilkan halaman search
detail laporan

3. Input bulan
4. Input tahun
5. Klik tombol cetak

5. Pengujian

6. Menampilkan detail laporan


sesuai bulan dan tahun yang siap
untuk dicetak

19

Fitur login akan diuji menggunakan metode whitebox tepatnya menggunakan


state transition. Berikut adalah penjelasannya :
5.1 State Transition

Test case dari gambar state transition diatas adalah sebagai berikut :
No.

Test
Item

Skenario
Pengujian

Hasil yang
diharapkan

Hasil pengujian

Status

R1

Input username dan Sistem masuk ke


password
terisi halaman awal user
benar
sesuai level user

Sistem masuk ke
halaman awal user
sesuai level user

Valid

R2

Username kosong Tidak dapat masuk


dan password terisi ke dalam sistem

Tidak dapat masuk


ke dalam system

Valid

R3

Username terisi dan


password kosong

Tidak dapat masuk


ke dalam sistem

Tidak dapat masuk


ke dalam system

Valid

R4

Username dan
password kosong

Tidak dapat masuk


ke dalam sistem

Tidak dapat masuk


ke dalam system

Valid

R5

Username salah
dan password benar

Tidak dapat masuk


ke dalam sistem

Tidak dapat masuk


ke dalam system

Valid

R6

Username benar
dan password salah

Tidak dapat masuk


ke dalam system

Tidak dapat masuk


ke dalam system

Valid

20

R7

Username dan
Password terisi
salah

Tidak dapat masuk


ke dalam sistem

Tidak dapat masuk


ke dalam system

Valid

Fitur tambah permintaan barang akan diuji dengan menggunkaan metode


basis path. Penjelasannya dapat dilihat pada langkah berikut :
5.2 Basis Path
Source code fungsi untuk Tambah Permintaan Barang
function tambah_permintaan(){

$d_header['kd_penjualan'] = $this->model_app->getKodePenjualan();
$temp = $d_header['kd_penjualan'];

$d_header['kd_pegawai'] = $this->session->userdata('ID');
$d_header['divisi'] = $this->session->userdata('DIVISI');

4
5

$d_header['tanggal_penjualan'] = date("Y-m-d",strtotime($this->input
>post('tanggal_penjualan')));
$this->model_app->insertData("tbl_penjualan_header",$d_header);
foreach($this->cart->contents() as $items){

$d_detail['kd_penjualan'] = $temp;

$d_detail['kd_barang'] = $items['id'];

$d_detail['qty'] = $items['qty'];
$d_detail['satuan'] = $items['satuan'];

1
12

$this->model_app->insertData("tbl_penjualan_detail",$d_detail);

13

$d_u['stok'] = $this->model_app >getTambahStok($d_detail['kd_barang'],


$d_detail['qty']);
14
$key['kd_barang'] = $d_detail['kd_barang'];

$this->model_app->updateData("tbl_barang",$d_u,$key);
}

$this->session->unset_userdata('limit_add_cart');
$this->cart->destroy();
redirect('permintaan');
}

1
2

18

21

Dari source code di atas, dapat di gambarkan flow graph sebagai berikut :

Perhitungan Kompleksitas
E(edges) = 6
N(nodes) = 4
P(predicate node) = 1
R(region) = 2
V(G) = E N + 2 = 6 6 +2 = 2
V(G) = P + 1 = 1 + 1 = 2
V(G) = R = 2 regions
Kesimpulannya Complexity number nya 2 maka:

22

- Kode terstruktur dan ditulis dengan baik


- Testability tinggi
- Upaya kurang
Jalur Independen Path nya :
-

Jalur 1 : 1-2-3-4-5-6-7-8-9-10-11-12-13-14-15-16-17-18-19-20

Jalur 2 : 1-2-3-4-5-6-7-8-9-10-11-12-13-14-15-16-17-8-9-10-11-12-13-1415-16-17-18-19-20

Case :
1. Menguji jika hanya melakukan tambah satu jenis barang pada satu form
permintaan barang
2. Menguji jika melakukan tambah tambah barang lebih dari satu jenis barang
pada satu form permintaan barang (melakukan perulangan dengan foreach)
Fitur laporan detail diuji menggunakan metode decision table. Penjelasannya
dapat dilihat sebagai berikut :
5.3 Decision Table
Metode ini digunakan untuk menguji fitur laporan detail. Pada fitur laporan
detail masuk terdapat dua jenis kondisi maka rule yang dibuat dari kondisi adalah
2x dengan x adalah kondisi sehingga rule yang digunakan adalah 4.

Kondisi

Input bulan laporan


Input tahun laporan
Tindakan Menampilkan halaman print
laporan detail permintaan
barang yang berisi detail
permintaan
Menampilkan halaman print
laporan detail permintaan
barang kosong

1
Y
Y
X

2
Y
N
-

Rule
3
N
Y
-

4
N
N
-

Test case pada decision table di atas adalah sebagai berikut :

23

No.

Test
Item

Skenario
Pengujian

Hasil yang
diharapkan

Hasil pengujian

Status

R1

Input bulan dan Sistem menampilkan


tahun laporan
laporan detail sesuai
dengan bulan dan
tahun diinputkan

Sistem
menampilkan
laporan detail sesuai
dengan bulan dan
tahun diinputkan

Valid

R2

Input bulan tetapi Sistem menampilkan


tidak input tahun
laporan detail sesuai
dengan bulan dari
semua tahun

Sistem
menampilkan
laporan detail
kosong

Tidak
Valid

R3

Input tahun tetapi


tidak input bulan

Sistem menampilkan
semua laporan detail
dari tahun yang
diinputkan

Sistem
menampilkan
laporan detail
kosong

Tidak
Valid

R4

Tidak input bulan


dan tahun

Sistem menampilkan
semua laporan detail
yang ada

Sistem
menampilkan
laporan detail
kosong

Tidak
Valid

5.4 Equivalen Partition


Metode ini digunakan untuk menguji fitur penambahan barang dan
penambahan permintaan barang. Rinciannya dapat dilihat sebagai berikut :
a.

Fitur Penambahan Barang

Input Nama Barang


Invalid

Valid

Input nama barang yang ingin


ditambahkan

Input nama barang yang ingin


ditambahkan

Test Case :
TC1 : abc
TC2 : 123
TC3 : a1b2
Input Kisaran Harga : integer
Invalid

Valid

24

Input selain angka

Input Angka

Test Case :
TC4 : huruf
TC5 : 125
Input Satuan
Valid
Input option satuan
Test Case :
TC6 : memilih option satuan buah
TC7 : memilih option satuan rim
TC8 : memilih option satuan kg
TC9 : memilih option satuan pak
Test case dari partisi-partisi diatas adalah berikut ini.
No Test
item

Skenario
pengujian

Hasil yang
diharapkan

Hasil Pengujian

Status

Nama
Barang

Memasukkan
Huruf

Aplikasi mau
menerima inputan
huruf dan
menyimpan nama
barang

Aplikasi mau
menerima inputan
huruf dan
menyimpan nama
barang

Valid

Nama
Barang

Memasukkan
Angka

Aplikasi tidak mau


menerima inputan
angka dan
menyimpan nama
barang

Aplikasi mau
menerima inputan
angka dan
menyimpan nama
barang

Tidak
Valid

Nama
Barang

Memasukkan
kombinasi
huruf dengan
angka

Aplikasi mau
menerima input
nama barang dan
menyimpan nama
barang

Aplikasi mau
menerima input
nama barang dan
menyimpan nama
barang

Valid

Kisaran

Memasukkan

Aplikasi tidak mau

Aplikasi mau

Tidak

25

Harga

Huruf

menerima inputan
huruf dan data
disimpan

menerima inputan
huruf dan data
disimpan

Valid

Kisaran
Harga

Memasukkan
Angka

Aplikasi mau
menerima inputan
angka dan
menyimpan
kisaran harga

Aplikasi mau
menerima inputan
angka dan
menyimpan
kisaran harga

Valid

Satuan

Dipilih option Aplikasi


satuan buah
menginputkan
option satuan buah

Aplikasi
menginputkan
option satuan buah

Valid

Satuan

Dipilih option Aplikasi


satuan rim
menginputkan
option satuan rim

Aplikasi
menginputkan
option satuan rim

Valid

Satuan

Dipilih option
satuan kg

Aplikasi
menginputkan
option satuan kg

Aplikasi
menginputkan
option satuan kg

Valid

Satuan

Dipilih option
satuan pak

Aplikasi
menginputkan
satuan pak

Aplikasi
menginputkan
satuan pak

Valid

Metode ini juga digunakan untuk menguji fitur tambah permintaan barang.
user memilih barang yang ada pada database kemudian memasukkan jumlah
pengadaan. Di dalam satu form user bisa memasukkan beberapa jenis barang.
Input Daftar Barang
Invalid

Valid

Input selain yang ada di database


barang

Input barang yang ada di database


barang

Test Case :
TC1 : g4j4h (Barang yang diinputkan tidak ada pada daftar barang)
TC2 : meja (Daftar barang tampil)
Input Jumlah pengadaan : integer
Invalid

Valid

26

Input selain angka

Input Angka

Test Case :
TC3 : hd
TC4 : 10

Jenis Barang
Valid

Valid

Invalid

Jenis Barang < 8

Jenis Barang ada 8

Jenis Barang > 8

Test Case :
TC5 : menginputkan jenis barang kurang dari 8 jenis
TC6 : menginputkan 8 jenis barang
TC7 : menginputkan jenis barang lebih dari 8 jenis
No Test Item

Skenario
Pengujian

Hasil yang Hasil


diharapkan pengujian

Status

Daftar
barang

Barang yang
diinputkan tidak ada
pada daftar barang

Aplikasi
menyimpan
data barang

Aplikasi
menyimpan
data barang

Valid

Daftar
barang

User memilih
barang dan daftar
barang tampil

Aplikasi
menyimpan
data barang

Aplikasi
menyimpan
data barang

Valid

Jumlah
pengadaan

Memasukkan huruf

Aplikasi
tidak
menyimpan
data jumlah
pengadaan

Aplikasi tidak
menyimpan
data jumlah
pengadaan

Valid

Jumlah
pengadaan

Memasukkan angka

Aplikasi
menyimpan
data jumlah
pengadaan

Aplikasi
menyimpan
data umlah
pengadaan

Valid

Jenis
barang

menginputkan jenis
barang kurang dari 8
jenis

Aplikasi
menyimpan
jenis barang
kurang dari

Aplikasi
menyimpan
jenis barang
kurang dari 8

Valid

27

8 jenis

jenis

Jenis
barang

menginputkan 8
jenis barang

Aplikasi
menyimpan
8 jenis
barang

Aplikasi
menyimpan 8
jenis barang

Valid

Jenis
barang

menginputkan jenis
barang lebih dari 8
jenis

Aplikasi
tidak bisa
menyimpan
data
permintaan

Aplikasi tidak
bisa
menyimpan
data
permintaan

Valid

TEST SUMMARY
1.1

Test summary report identifier


Tujuan utama dari dokumen test summary ini adalah untuk mendeskripsikan hasil dari

aktivitas testing dan melakukan evaluasi berdasarkan hasil testing. Dokumen ini terkait
dengan dokumen test plan, test design, test procedure dan test case.
1.2

Summary
Modul Barang pada sistem Inventaris PT. Antar Surya Media ini digunakan untuk

menyimpan informasi permintaan barang pada PT. Antar Surya Media. Evaluasi pengujian
yang dilakukan pada sistem ini yaitu pengujian pada fitur tambah permintaan barang yang
telah dilakukan yaitu:

Test Plan

Test Design Specification

Test Case Specification

Test Procedure Specification


1.3 Variances
Laporan setiap varian dari test specification :

Test Plan
Pada test plan kami telah melakukan perencanaan pengujian Sistem Inventaris
PT. Antar Surya Media. Pada test plan telah dijelaskan fitur-fitur dalam masing-masing

modul yang akan diujikan.


Test Design Specification
Pada test design specification telah dijabarkan fitur-fitur yang akan diujikan

tersebut akan diuji menggunakan metode tertentu


Test Case Specification
Pada test case specification dilakukan pendefinisian skenario pengujian dan
pendefinisian hasil output yang akan diberikan sistem. Selain itu dilakukan
pendefinisian kebutuhan sistem dan prosedur yang dibutuhkan untuk dapat

menjalankan sistem.
Test Procedure Specification
Pada test procedure terdiri dari langkah-langkah pengujian sistem serta
mendokumentasikan hasil pengujian sistem yang telah dilakukan dengan menggunakan
4 metode pengujian perangkat lunak. Hasil pengujian dapat dilihat pada tabel berikut:
Tabel hasil pengujian
Metode Pengujian

Fitur
Login

29

Tambah

Tambah

Laporan

29

Basis Path
State Transition
Equivalent Partition
Decision Table

Valid
-

Barang

Permintaan

Detail

77,7%
-

Barang
Valid
Valid
-

25%

Keterangan :
Login
Tambah Barang

: Valid semua
: 7 valid dari 9 test case, sehingga hasil kevalidannya
7/9 *100% = 77,7%
Tambah Permintaan Barang : Valid semua
Laporan Detail
: 1 valid dari 4 test case, sehingga hasil kevalidannya
*100% = 25%

1.4

Comprehensive assesment
Kelengkapan proses pengujian pada tiap-tiap fitur sangat lengkap. Kelengkapan

pengujian pada masing-masing fitur dapat dilihat pada tabel berikut :


Tabel kelengkapan proses pengujian

Fitur

1.5

Approach
Login
State Transition
Tambah Barang
Equivalent Partition
Tambah
Permintaan Basis Path, Equivalent

Kelengkapan
Lengkap
Lengkap
Lengkap

Barang
Laporan Detail

Lengkap

Partition
Decision Table

Summary of result
Semua fitur lulus pengujian tanpa ada kesalahan. Pengujian dilakukan dengan beberapa

modul test yaitu: test plan, test design specification, test case specification dan test procedure
specification.
1.6

Evaluation

Modul test yang digunakan untuk pengujian dengan hasil lulus komprehensif tidak ada
kesalahan pada sistem yang dilakukan pengujian.
1.7

Summary of activities
Tasks
Test design
Test case
Test plan
Test procedure

Estimate
2 day
3 day
3 day
2 day

Actual
2 day
2 day
3 day
2 day

30

Module Driver
Development
Test Execution
Module Revision
Test Reporting

1 day

0 day

2 day
1 day
2 day
16 day

2 day
0 day
1 day
12 day