Testing pada Implementasi ERP HCMS modul
Business Trip pada FIF Group
Jayatri Puspa Dewi
Universitas Bina Nusantara, 081280271899, [email protected]
Woro Tanting Hesti
Universitas Bina Nusantara, 081318281418, [email protected]
Yonasto Lajar
Universitas Bina Nusantara, 083875265884, [email protected]
Win Ce
Universitas Bina Nusantara, 08161820120, [email protected]
Abstrak
Kegagalan di dalam impelementasi sistem banyak kita temukan di Indonesia sehingga dirasa perlu dalam hal melakukan pengujian / testing pada suatu sistem sebelum masuk ke tahapan go live. Departemen Information Technology FIF GROUP tengah melaksanakan suatu proyek pembuatan sistem baru yang diberi nama Human Capital Management Systems (HCMS) yang sebelumnya bernama Human Resources Management Systems (HRMS) yang akan digunakan oleh departemen Human Capital, sebelum sistem yang baru masuk ke tahapan go live maka perlu dilakukan testing untuk memastikan bahwa sistem baru ini dapat berjalan sesuai dengan kebutuhan departemen Human Capital pada FIF GROUP. Testing yang dilakukan adalah functionality testing yang menggunakan metode black box testing. Functionality testing ini dibagi kedalam 4 bagian untuk mempermudah di dalam melakukan testing yang teridiri dari setup testing, functional testing, integration testing dan report testing. Agar penulisan semakin fokus dan mendalam maka modul Business Trip dipilih sebagai bahan penulisan karena proses bisnisnya yang kompleks. Hasil dari testing ini menunjukkan bahwa modul Business Trip masih belum layak masuk ke tahapan go live dikarenakan beberapa sub modul Business Trip belum melalui minimal satu test cycle tanpa ditemukan bug setelah semua bug pada test cycle sebelumnya telah diselesaikan. Berdasarkan root cause charts hasil testing modul Business Trip menunjukkan bahwa 57.5% bug disebabkan oleh kesalahan code dan berdasarkan subsystem charts menunjukkan bahwa
bug paling banyak ditemukan pada subsystem Business Trip Request sebanyak 27.9%. (JP)(WT)(YL).
Kata kunci : Pengujian / Testing, go live, functionality testing, black box testing, business trip, test cycle, bug, root cause charts, code, subsystems charts.
PENDAHULUAN
Kegagalan di dalam implementasi sistem ERP sangat besar dan oleh sebab itu maka sangat diperlukan dilakukannya testing / pengujian untuk menekan angka kegagalan di dalam implementasi sistem ERP. Pengujian ini nanti sangat berguna dan menguntungkan bagi pihak yang berkepentingan atas implementasi sistem ERP untuk menekan biaya. Thakare, Chavan, dan Chawan menyatakan bahwa “ Testing adalah serangkaian kegiatan yang dapat direncanakan terlebih dahulu dan dilakukan secara sistematis.” Kemudian, Ahamed juga menyatakan bahwa “ Tujuan utama atas suatu testing adalah untuk menemukan error dengan mengeksekusi program yang telah dibuat. Selain itu, tujuan
testing adalah untuk memastikan apakah rancangan software sudah memenuhi spesifikasi yang
dibutuhkan customer. “ Testing yang kami lakukan memiliki nilai lebih di dalam hal integration
testing yaitu bagaimana menentukan jumlah test case pada integration testing.
Penentuan jumlah test case pada integration testing terlihat lebih sulit karena pengujian yang dilakukan lebih kompleks ketimbang setup testing dan functional testing, oleh sebab itu penting menemukan cara menentukan jumlah test case yang akan dilakukan terhadap integration testing dan kami menemukan cara menentukan jumlah test case pada integration testing ini. Tujuan dari testing pada implementasi ERP HCMS modul Business Trip pada FIF Group adalah :
1. Menyiapkan test scenario dan melakukan testing pada Human Capital Management Systems modul Business Trip untuk menemukan error atau bug pada saat aplikasi atau program dijalankan.
2. Memeriksa apakah rancangan Human Capital Management Systems modul Business Trip telah sesuai dengan requirement yang sudah pada functional systems design yang diperlukan oleh departemen Human Capital pada Federal Internatonal Finance Group.
3. Mendokumentasikan hasil testing yang dilakukan terhadap Human Capital Management Systems modul Business Trip pada Federal International Finance Group.
4. Memberikan rekomendasi kepada Federal International Finance Group atas hasil testing pada
Human Capital Management Systems modul Business Trip.
METODE TESTING
Di dalam melakukan testing atau pengujian aplikasi memiliki beberapa metodologi yaitu black
box testing, gray box testing dan white box testing. Pada saat melakukan pengujian Human Capital Management Systems modul Business Trip pada Federal International Finance Group kami
menggunakan metodologi black box testing atau sering juga disebut functionality testing.
Black-box testing yang disebut juga dengan behavioral testing atau functional testing adalah proses testing
berdasarkan pada apa yang seharusnya program lakukan, dan digunakan untuk menemukan bugs dalam high-level operations (Black, 2009). Ahamed (2009) berpendapat bahwa black-box testing merupakan jenis testing yang dilakukan dengan membandingkan antara fungsi aktual dari program dengan persyaratan fungsi yang terdapat pada dokumen spesifikasi program. Dalam black-box testing, kondisi testing dikembangkan berdasarkan fungsionalitas dari sistem, dengan kata lain, tester membutuhkan informasi tentang data input dan output yang diamati, tetapi tidak mengetahui bagaimana program atau sistem bekerja, dengan arti bahwa functional testing dapat tetap dilakukan tanpa perlu bagi tester untuk mengetahui struktur internal dari program (Lewis, 2009). Berdasarkan beberapa definisi tersebut, maka dapat disimpulkan bahwa black-box testing merupakan teknik pengujian sistem untuk menilai apakah sistem sudah bekerja sesuai dengan persyaratan dan spesifikasi yang telah ditentukan, dengan proses testing yang berfokus pada fungsionalitas dari sistem tanpa melihat cara kerja dan struktur internal dari sistem.
Gambar 1: Representasi Black-Box Testing
Sumber: Khan dan Khan (2012: 13)
Testing yang kami lakukan menggunakan metode black-box testing yang memperhatikan
beberapa key element (Black, 2009) yaitu: 1. Test planning
Perencanaan testing akan dilakukan dengan menganalisa General Process HCMS dan modul
Business Trip dengan menggunakan Unified Modelling Language (UML) yaitu Activity Diagram
yang akan digunakan dalam perancangan Failure Mode and Effects Analysis (FMEA), test
scenario dan test case. Kemudian menyiapkan setting testing, milestones, transition, test configuration, test system development, test suite, test cycle dan test resource.
2. Test execution
Melakukan testing dengan menggunakan test scenario, test case dan test suite yang telah di rancang pada key element test planning yang terdiri dari tiga fase, yaitu:
a) Functionality testing
Pada tahap ini akan dilakukan pengujian terhadap submodul-submodul sesuai dengan test
scenario functionality testing modul Business Trip.
b) Integration testing
Pada tahap ini akan dilakukan testing pada seluruh submodul secara utuh dan bersamaan untuk melihat hubungan antar submodul dengan menggunakan test scenario integration
testing.
c) Report testing
Pada tahap ini akan menguji kelengkapan dan kebenaran dari laporan-laporan pada modul
Business Trip dengan menggunakan test scenario report testing.
3. Test evaluation
Menyiapkan bug report atas hasil testing dan menghasilkan test tracking spreadsheet,
opened/closed charts, root cause charts dan subsystem charts serta memberikan rekomendasi
hasil testing kepada Federal International Finance GROUP.
Berdasarkan key element ini maka kami membuat kerangka pikir yang kami gunakan pada saat melakukan testing. Kerangka pikir ini merupakan panduan kami di dalam melakukan testing.
Test Planning
1. General Process berisikan fungsi-fungsi yang terdapat pada Human Capital Management Systems (HCMS) yang terdapat di lebih dari 1 modul. Pada tahap ini test team memahami dan
mendefinisikan proses-proses umum yang ada pada HCMS Federal International Finance (FIF) GROUP yang terkait dengan modul business trip.
2. Modul Business Trip dilakukan untuk memahami dan mendefinisikan proses-proses spesifik yang ada pada modul Business Trip.
3. Merancang test plan menghasilkan FMEA, setting testing, milestones, transition, test
configuration, test sytem development, scenario test, test case, test suite, test cycle dan test resource yang digunakan pada saat test execution.
Test Execution
4. Functionality Testing merupakan pengujian terhadap suatu submodul berdasarkan test scenario
yang telah ditentukan.
5. Integration Testing merupakan pengujian terhadap submodul–submodul secara terintegrasi dan
pada waktu yang berurutan.
6. Report Testing merupakan pengujian terhadap laporan penting dimana test case dari report testing yang diambil dari integration testing.
7. Bugs Report merupakan dokumen teknis yang menjelaskan berbagai macam gejala atau pola
kegagalan yang terkait dengan sebuah bug, dan merupakan hasil yang paling nyata dari proses
testing yang dapat memberikan informasi yang jelas bagi tim proyek untuk membuat keputusan
guna meningkatkan kualitas dari sistem. Bug report ini nantinya akan menghasilkan test
tracking spreadsheet, opened/closed charts, root cause charts dan subsystems charts yang
digunakan untuk melakukan evaluasi hasil testing.
8. Rekomendasi hasil testing berisi solusi-solusi yang disarankan untuk mencegah, menyelesaikan dan meminimalisir dampak dari bugs yang ditemukan dalam proses testing. Gambar Kerangka piker dapat dilihat pada gambar 2.
Gambar 2: Kerangka Pikir
KERANGKA PIKIR
Test Planning
Modul Business Trip
Merancang Test Plan
General Process HCMS
Test Evaluation
Test Execution
Functionality Testing
Integration Testing
Report Testing
Bugs Report
HASIL DAN BAHASAN
FMEA yang kami hasilkan terdiri dari menunjukkan system function or feature pada modul
business trip apa saja yang akan diuji / dilakukan testing dan mana yang tidak dilakukan testing
berdasarkan nilai RPN yang dihasilkan.
Tabel 1: FMEA
System Function or Feature Severity Priority Likelihood RPN Test
Test Setup – Expense Type
Search Expense Type 2 1 1 2 YES
Add New Setup Expense Type 2 2 1 4 YES
Add New Version Expense Type 2 2 1 4 YES
Edit Effective Date To Current
Version Expense Type 2 2 1 4 YES Edit Future Version Expense Type 2 2 1 4 YES
View Expense Type 3 4 4 48 NO
Delete Expense Type 2 2 1 4 YES
Search Upload Expense Plafond 2 3 2 12 YES
Download Expense Plafond 2 2 4 16 YES
Upload Expense Plafond 2 2 1 4 YES
View Detail Upload Expense
Plafond 3 3 4 36 NO
Download Failed Record of
Upload Expense Plafond 2 3 3 18 NO Cancel Upload Expense Plafond 3 3 4 36 NO
Close Batch Upload Expense
Plafond 2 2 2 8 YES
Test Setup – Purpose Type
Search Purpose Type 2 1 1 2 YES
Add New Setup Purpose Type 2 2 1 4 YES
Add New Version Purpose Type 2 2 1 4 YES
Edit Effective Date To Current
Version Purpose Type 2 2 1 4 YES Edit Future Version Purpose Type 2 2 1 4 YES
View Purpose Type 3 4 4 48 NO
Delete Purpose Type 2 2 1 4 YES
Test Functional - Business Trip Request dan Business Trip Settlement Search Business Trip Request &
Business Trip Settlement 2 1 1 2 YES Business Trip Request 2 1 1 2 YES
Resubmit Business Trip (by Other
Employee) 2 1 1 2 YES
Businee Trip Settlement 2 1 1 2 YES
View Business Trip
Request-Settlement Detail 2 3 1 6 YES BTR Approval 2 1 1 2 YES
BTS Approval 2 1 1 2 YES
Test Functional – Ticket Booking
Search Ticket Booking 2 1 1 2 YES
Entry Ticket Booking 2 1 1 2 YES
Search Ticket Booking Invoice 2 1 1 2 YES
Entry Ticket Booking Invoice. 2 1 1 2 YES
Ticket Booking Invoice Approval. 2 1 1 2 YES
Test Functional – Voucher Booking
Search Voucher Booking 2 1 1 2 YES
Entry Voucher Booking 2 1 1 2 YES
Search Voucher Booking Invoice 2 1 1 2 YES
Entry Voucher Booking Invoice. 2 1 1 2 YES
System Function or Feature Severity Priority Likelihood RPN Test
Approval.
Integration Testing
Business Trip Kosong. 2 2 2 8 YES
Business Trip with Prepayment. 2 2 2 8 YES
Business Trip with Other
Employee. 2 2 2 8 YES
Business Trip with Ticket. 2 2 2 8 YES
Business Trip with Voucher. 2 2 2 8 YES
Business Trip with Prepayment and
Other Employee. 4 4 3 48 NO Business Trip with Prepayment and
Ticket. 2 2 2 8 YES
Business Trip with Prepayment and
Voucher. 2 2 2 8 YES
Business Trip with Other Employee
and Ticket. 4 4 3 48 NO Business Trip with Others
Employee and Voucher. 4 4 3 48 NO Business Trip with Ticket and
Voucher. 2 2 2 8 YES
Business Trip with Prepayment,
Other Employee and Ticket. 4 4 3 48 NO Business Trip with Prepayment,
Other Employee and Voucher. 4 4 3 48 NO Business Trip with Prepayment,
Ticket and Voucher. 2 2 2 8 YES Business Trip with Other
Employee, Ticket and Voucher. 4 4 3 48 NO Business Trip with Prepayment,
Other Employee, Ticket and Voucher.
4 4 3 48 NO
Report Testing
Ticket Reservation Report 2 2 4 16 YES
Business Trip Monitoring Report 2 2 4 16 YES
Business Trip Settlement Report 2 2 4 16 YES
Budget Balance of Business Trip Report
2 2 4 16 YES
Business Trip Ticketing Report 2 2 4 16 YES
Nilai tambah dari testing yang kami lakukan adalah cara menentukan test case pada integration testing yang dapat dilakukan dengan cara sebagai berikut :
1. Identifikasi tahapan siklus transaksi.
Pada tahap ini kita menentukan pada satu cycle transaksi terdapat tahapan apa saja. Misalnya pada transaksi Business Trip terdapat tahapan Business Trip Request, Business Trip Request
Approval, Business Trip Settlement, Business Trip Settlement Approval.
2. Identifikasi case pada masing-masing tahapan.
Pada tahap ini kita menentukan case apa saja yang terdapat pada masing-masing tahapan yang telah kita identifikasi. Misalkan pada tahap Business Trip Request terdapat Business Trip
Request with Prepayment. BTR Approval dapat di-reject, approve atau approve dengan mengubah
jumlah prepayment. Sedangkan BTS Approval dapat reject dan approve, jika BTS Approval
di-reject maka harus melakukan BTS kembali. Dalam kasus ini BTS tidak memiliki case di dalamnya.
3. Buat diagram cycle transaksi.
Dari 2 tahapan diatas maka kita dapat membuat diagram siklus dari transaksi tersebut :
Gambar 4: Contoh Siklus Transaksi
4. Hitung jumlah test case.
Dari gambar pada tahap ke-3 kita dapat menentukan jumlah test case yang dibutuhkan untuk melakukan testing. Caranya adalah dengan menghitung jumlah test case pada case paling ujung dari siklus transaksi dalam kasus ini adalah BTS Approved dan BTS Rejected.
Pada case BTS Approved dan BTS Rejected masing-masing membutuhkan 2 test case untuk memenuhi kebutuhan BTR Approved dan BTR Approved with change Prepayment
Amount. Kemudian kita mundur 1 case yaitu BTS. Karena BTS Approved dan BTS Rejected
masing-masing 2 test case maka BTS harus menyediakan test case sebanyak jumlah dari test
case sesudahnya yaitu sebanyak 4 buah test case BTS. Kemudian kita mundur lagi satu case
setelah BTS yaitu ada BTR Approved dan BTR Approved with change Prepayment Amount maka jumlah masing-masing test case-nya adalah jumlah test case pada BTS dibagi 2 maka masing-masing BTR Approved dan BTR Approved with change Prepayment Amount 2 test
case hasil dari 4 test case pada BTS dibagi 2. Kemudian kita mundur 1 case lagi yaitu BTR with Prepayment, test case yang dibutuhkan adalah total dari jumlah test case pada case
sesudahnya yaitu BTR Approved, BTR Rejected dan BTR Approved with change Prepayment
Amount sebanyak 5 test case untu BTR with Prepayment. Dengan cara ini maka kita dapat
menemukan jumlah test case untuk measing-masing case pada saat integration testing. Dari perhitungan ini maka kita dapat menentukan jumlah test case untuk siklus transaksi ini : 2 2 4 2 2 1 5
Tabel 2: Contoh Penentuan Jumlah Test Case untuk Integration Testing
Nama Test Case Jumlah Test Case
BTR with Prepayment 5
BTR Approved 2
BTR Rejected 1
BTR Approved with change Prepayment Amount 2
BTS 4
BTS Approved 2
BTS Rejected 2
Berdasarkan hasil testing yang kami lakukan terhadap Human Capital Management Systems modul Business Trip memberikan hasil sebagai berikut :
1. Opened / Closed Chart.
Gambar 5: Opened / Closed Charts
Pada gambar 5 diagram yang menggambarkan mengenai status opened dan status closed atas
bugs yang ditemukan atas semua testing phase. Pada diagram tersebut terlihat bahwa semua bug yang
ditemukan oleh test team telah diselesaikan oleh developer. Jika dilihat pada garis cumulative opened terlihat bahwa kebanyakan bug ditemukan pada test cycle 1 dan pada test cycle 2 dan pada test cycle 3 terus berkurang. Hal inilah yang menyebabkan kebanyakan garis cumulative opened menjadi mendatar.
Jika dilihat pada garis cumulative closed pada awal-awal testing, developer belum menyelesaikan bug yang ditemukan oleh test team. Barulah pada tanggal test cycle 2 bugs yang ditemukan oleh test team diselesaikan oleh developer. Dari garis ini juga terlihat bahwa developer menyelesaikan bugs yang ditemukan secara cumulative. Ada banyak garis mendatar lalu tiba-tiba menanjak dengan terjal yang menunjukkan bahwa pada beberapa saat developer tidak menyelesaikan
bugs dan pada saat tertentu developer menyelesaikan bugs dengan jumlah yang besar. Ada
kemungkinan bahwa ketika masalah status bugs yang masih opened ditanyakan oleh Project Manager barulah developer menyelesaikan bugs tersebut. Hal ini tentu kurang bagus dalam penyelesaian suatu
bugs yang tentu saja kualitas dari developer menjadi dipertanyakan.
Gambar 6 : Root Cause Charts modul Business Trip
Dari gambar di atas dapat disimpulkan bahwa akar kerusakan penyebab bug yang paling banyak ditemukan pada modul Business Trip ini adalah Code dimana kesalahan terletak pada pemrograman sehingga menyebabkan kegagalan dalam memenuhi requirements. Dengan bug yang ditemukan sebesar 35 bug dan persentase sebesar 57.5%. Kemudian ditemukan pula akar kerusakan yang paling sedikit terletak pada process–Arithmetic. Dengan 1 bug, dan persentase sebesar 1.6%.
3. Subsystems Charts
Gambar 7 : Subsystem Charts Modul Business Trip HCMS
Dari gambar tersebut dapat disimpulkan bahwa subsystem yang paling banyak terdapat bug adalah Business Trip Request (BTR) dengan jumlah bug 17 bug dan persentase 27.9% dari keseluruhan bug yang ditemukan pada modul Business Trip yaitu 61 bug. Dan ditemukan pula bahwa
subsystem Ticket Invoice Approval tidak memiliki bug.
4. Test Recommendation
Tabel 2 : Jumlah Bugs pada Test Cycle
Test Phase Test Cycle Num of Bugs Opened Num of Bugs Closed
Test Setup I 13 0 II 0 13 III 0 0 Test Functionality I 27 3 II 7 19 III 0 12 Test Integration I 9 0 II 3 9 III 0 3
Test Phase Test Cycle Num of Bugs Opened Num of Bugs Closed Test Report
I 2 0
II 0 2
III 0 0
Dari tabel 2 dapat dilihat bahwa dari 61 bugs yang ditemukan oleh test team pada saat melakukan pengujian kesemuanya telah berstatus closed. Namun berdasarkan tabel 2 test phase untuk
test setup dan test report telah berhasil masing-masing 1 kali test cycle tanpa ditemukan error setelah
semua bug yang ditemukan pada test cycle sebelumnya telah diselesaikan oleh developer. Namun test
phase functionality dan integration belum menyelesaikan 1 pun test cycle setelah bugs pada test cycle
sebelumnya telah diselesaikan seluruhnya. Hal ini menunjukkan bahwa test functionality dan test
integration harus dilakukan pengujian kembali untuk memastikan bahwa tidak ada bugs lagi yang
muncul setelah semua bugs yang ditemukan pada test cycle sebelumnya telah diselesaikan.
SIMPULAN DAN SARAN
Berikut ini adalah simpulan dan saran yang kami buat atas hasil testing dari Human Capital
Management Systems modul Business Trip pada Federal International Finance Group :
5.1 Simpulan
Berdasarkan hasil pengujian yang telah dilakukan pada saat internship dan telah dipaparkan pada bab 4 maka dapat ditarik kesimpulan atas pengujian modul Business Trip, Human Capital
Management Systems (HCMS) pada Federal International Finance (FIF) GROUP adalah sebagai
berikut:
1) Berdasarkan pada bug report sub bab 4.1 bahwa masih banyak ditemukan bug/error pada test
setup, test functionality, test integration dan test report. Dimana bug/error merupakan masalah
yang muncul ketika melakukan pengujian pada sistem HCMS modul Business Trip, dan merupakan kondisi yang tidak memenuhi persyaratan/spesifikasi pada software atau harapan
end user. Hal ini menunjukkan bahwa pada saat pengujian Human Capital Management Systems (HCMS) modul Business Trip pada FIF GROUP masih belum memenuhi spesifikasi
yang diinginkan oleh end user. Ditemukan sebanyak 61 bug dengan rentang Risk Priority
Number (RPN) sebesar 1 sampai 6. Dimana rentang RPN itu harus dilakukan perbaikan
sebelum samai ke tangan end user dan harus dilakukan pengujian ulang sebagai pengujian konfirmasi setelah dilakukannya perbaikan oleh tim developer untuk memastikan apakah perbaikan tersebut membuat sistem telah sesuai dengan spesifikasi yang telah ditentukan sebelumnya yang tertuang dalam Functional System Design (FSD) dan untuk melihat apakah perbaikan yang dilakukan pada sistem tersebut menimbulkan efek-efek error/kegagalan kepada fungsi yang lainnya.
2) Hasil dari proses testing juga terdapat pada test tracking spreedsheet, dimana test tracking
spreedsheet merupakan to-do list yang digunakan untuk membantu memudahkan di dalam
pelaksanaan proses testing HCMS modul Business Trip dengan kemampuan melacak status
bug pada case yang telah diuji, dapat melihat konfigurasi test yang dijalankan dan siapa yang
menjalankan test tersebut serta merupakan dokumen yang menyatakan rangkuman dari hasil proses testing yang dipaparkan secara numerik. Test Tracking Spreedsheet memaparkan status
bug dalam proses testing yang dilakukan pada setiap cycle. Dimana test cycle merupakan
proses eksekusi satu, beberapa atau seluruh test suite yang sudah dirancang untuk fase-fase tertentu. Dan terdapat tiga cycle dalam melakukan ke-empat fase testing. Ke-empat fase itu adalah test setup, test functionality, test integration dan test report. Jadi, setiap fase testing yang dilakukan melewati 3 test cycle. Dimana dapat dilihat pada fase test setup, cycle pertama menemukan 13 bugs dan developer belom menyelesaikan bugs tersebut pada cycle pertama. Pada cycle kedua, tidak ditemukan bug sama sekali, tim developer menyelesaikan seluruh bug yang telah ditemukan, kemudian pada cycle terakhir tidak ada bug yang ditemukan dan tidak adanya aktivitas penyelesaian bug karena bug sudah diselesaikan pada cycle kedua.
Fase test functonality ditemukan 27 bugs pada cycle pertama. Dan tim developer baru menyelesaikan 3 bugs pada cycle pertama. Kemudian pada cycle kedua ditemukan 7 bugs kembali, dari total bugs yang ditemukan tim developer baru menyelesaikan 19 bugs pada cycle kedua. Dan pada cycle terakhir tidak ditemukan bug sama sekali namun di cycle ketiga ini semua bug baru terselesaikan oleh developer, yaitu 12 bugs sisanya yang belom terselesaikan pada cycle kedua terselesaikan di cycle terakhir ini.
Fase test integration ditemukan 9 bugs pada cycle pertama, dan tim developer tidak menyelesaikan bugs tersebut di cycle pertama. Pada cycle kedua ditemukan bug kembali
sebanyak 3 bugs dan tim developer baru selesai melakukan perbaikan 9 bugs pada cycle kedua ini. Kemudian, pada cycle ketiga tidak ditemukan bug sama sekali namun sisa bug sebanyak 3
bugs yang belom berstatus closed baru diselesaikan pada cycle terakhir.
Fase yang terakhir yaitu test report, pada cycle pertama ditemukan bug sebanyak 2 bugs. Dan tim developer tidak melakukan perbaikan pada bug tersebut di cycle pertama. Kemudian, cycle kedua tidak ditemukan bug dan developer telah memperbaiki semua bug yang ditemukan. Pada
cycle ketiga tidak ditemukan bug sama sekali sehingga tidak adanya aktivitas penyelesaian bugs yang dilakukan oleh developer di cycle terakhir.
3) Hasil dari bug report tersebut dibuatlah opened/closed charts dimana ini merupakan chart dasar yang digunakan untuk analisa defect dengan mengelompokkan seluruh total bugs yang masih berstatus open atau belom diselesaikan terhadap total bugs yang telah diselesaikan oleh tim developer dan kurun waktu satu hari dalam testing yang dilakukan oleh tim tester pada modul Business Trip. Berdasarkan opened/closed charts dapat ditarik kesimpulan bahwa semua bug yang ditemukan telah diselesaikan oleh developer dimana tidak ada perbedaan yang mendalam antara garis cumulative opened dan cumulative closed pada opened/closed charts. Dari chart itu juga dapat disimpulkan bahwa kinerja dari tim developer kurang baik terhadap penanganan bugs. Terdapat kondisi dimana penanganan bugs tidak dilakukan secara segera. 4) Berdasarkan root cause charts, dimana ini merupakan chart yang digunakan untuk
menjelaskan akar kerusakan penyebab bug digambarkan bahwa bug paling banyak ditemukan disebabkan oleh kesalahan code, total bug sebanyak 35 bugs dengan persentase sebesar 57.5% dan yang paling sedikit disebabkan oleh process-arithmetic dengan total bug sebanyak 1 bug dan persentase sebesar 1.6%. Berdasarkan angka ini dapat diartikan bahwa bug terbanyak disebabkan karena kesalahan developer dalam proses pembuatan code. Dimana kesalahan terdapat pada kesalahan pengetikan, ejaan, stilistik atau variasi gaya bahasa dan penggunaannya serta kesalahan pada coding yang terjadi sehingga menimbulkan kegagalan. Selain itu akar kerusakan penyebab bug juga ditemukan pada initialiation,
process-other, documentation, standards dan other. Dimana process-initialization merupakan gagal
pada saat pengoperasian pertama kali, process-other merupakan aliran kontrol dan numculnya
error yang tidak sesuai dengan pemrosesan, documentation merupakan kesalahan seperti
dokumentasi sistem tidak X pada kondisi Y, tetapi kenyataannya sistem melakukan Z sebagai tindakannya, standards merupakan gagal memenuhi standard yang ditetapkan seperti gagal memenuhi standard code, dan other yang merupakan akar penyebab masalah diketahui tetapi tidak satupun yang cocok dengan kategori sebelumnya.
5) Dari bug report maka dapat pula dibuat subsystem charts, dimana ini merupakan chart yang menggambarkan subsytem pada modul Business Trip mana yang paling banyak terdapat bug. penemuan bug paling banyak adalah pada subsystem Business Trip Request (BTR) dengan bug sebanyak 17 bugs, persentase sebesar 27.9% dan yang paling sedikit terdapat pada subsystem
Ticket Invoice Approval dengan persentase sebesar 0% yang berarti tidak ditemukan bug sama
sekali pada subsytem tersebut. Kemudian di dalam modul Business Trip terdapat subsytem lainnya yaitu pada setup terdiri dari Expense Type, Purpose Type. Kemudian pada transaksi atau functionality terdapat BTR Approval, Business Trip Settlement (BTS), BTS Approval,
Ticket, Voucher, Voucher Invoice Approval, dan Report. Dimana ditemukan bug pula pada ke
sembilan subsytem tersebut.
6) Berdasarkan apa yang sudah dipaparkan pada simpulan point kedua, dimana dari hasil testing tersebut disimpulkan bahwa test setup dan test report telah berhasil melalui 1 test cycle dengan kondisi dimana tidak ditemukan satu bug pun pada sistem, dan semua bug yang ditemukan telah diselesaikan semuanya pada cycle kedua. Pada cycle terakhir tidak adanya aktivitas penemuan dan perbaikan bugs. Dengan begitu dapat diartikan bahwa submodul setup dan
report sudah layak untuk implementasi.
7) Kemudian, berdasarkan pula pada apa yang sudah dipaparkan pada simpulan point kedua, test functionality dan integration belum melalui 1 test cycle dengan kondisi dimana tidak
ditemukan satu bug pun pada sistem, dan aktivitas penyelesaian bug baru selesai dilakukan pada cycle ketiga/terakhir. Dengan begitu dapat diartikan bahwa submodul functionality dan
integration belum layak untuk implementasi.
5.2 Saran
Untuk dapat memberikan hasil yang lebih baik setelah pelaksanaan proses pengujian
Human Capital Management Systems (HCMS), submodul Business Trip pada FIF GROUP, maka
1) Setelah seluruh bug yang ada telah diperbaiki, diperlukan proses pengujian ulang sebagai pengujian konfirmasi, khususnya dilakukan pengujian ulang pada functionality dan integration minimal 1 test cycle lagi dengan tidak ditemukan bug dan tidak adanya aktivitas penyelesaian
bug untuk memasikan bahwa sistem layak untuk implementasi/go-live.
2) Apabila ditemukan bug kembali maka diperlukan perbaikan segera pada bug sesuai dengan bug
report yang ada dan diperlukan perbaikan yang didasarkan oleh prioritas penanganan bug yang
sebelumnya telah ditetapkan di dalam bug report.
3) Diperlukan pengawasan dan standar khusus ketika proses testing berlangsung,
khususnya pada tim developer, karena berdasarkan data pada Root Cause Charts terlihat bahwa penyebab utama adanya bug adalah kesalahan pada code yaitu sebesar 57.5%, yang menyebabkan requirement dari user tidak dapat terpenuhi.
4) Diperlukan pengawasan dan standar khusus pada saat dilakukannya testing kembali khususnya pada subsystem Business Trip Request (BTR) yang memiliki persentase ditemukannya bug paling banyak berdasarkan data yang diperoleh dari Subsystem Charts yaitu sebesar 27,9%.
REFERENSI
Ahamed, S. (2009). Studying The Feasibility and Importance of Software : an Analysis. International
Journal of Engineering Science and Technology, 1(3), 119, 122. Retrieved: September 15,
2013, from http://arxiv.org/ftp/arxiv/papers/1001/1001.4193.pdf
Black, R. (2009). Managing The Testing Process (3rd edition). Indianapolis: Wiley Publishing, Inc. Lewis, W. E. (2009). Software Testing and Continous Quality Improvement (3rd edition). London:
Taylor & Francis Group.
Thakare, S., Chavan, S., & Chawan, P. M. (2012). Software Testing Strategies and Techniques.
International Journal of Emerging Technology and Advanced Engineering, 2(4), 6, 8, 2. Retrieved: September 20, 2013, from
www.ijetae.com/files/Volume2Issue4/IJETAE_0412_116.pdf.
RiIWAYAT PENULIS
Jayatri Puspa Dewi lahir di Jakarta pada 04 Januari 1991. Penulis menamatkan pendidikan S1 di
Universitas Bina Nusantara dalam bidang Sistem Informasi Program Studi Komputerisasi Akuntansi pada 2014.
Woro Tanting Hesti lahir di Palembang pada 13 Maret 1992. Penulis menamatkan pendidikan S1 di
Universitas Bina Nusantara dalam bidang Sistem Informasi Program Studi Komputerisasi Akuntansi pada 2014
Yonasto Lajar lahir di Palu Rejo pada 04 Juli 1993. Penulis menamatkan pendidikan S1 di
Universitas Bina Nusantara dalam bidang Sistem Informasi Program Studi Komputerisasi Akuntansi pada 2014.
Win Ce lahir di kota Pangkalpinang pada tanggal 28 September 1979. Penulis menamatkan
pendidikan S1 di Universitas Bina Nusantara dalam bidang Ilmu Komputer pada 2001 dan pendidikan S2 di Prasetya Mulya Business School Spesialisasi di Manajemen Keuangan pada 2004. Saat ini bekerja sebagai Software Laboratory Center Manager dan sekaligus menjadi dosen School of Information System di Universitas Bina Nusantara.
