Testing pada Implementasi ERP HCMS modul Business Trip pada FIF Group

Transkripsi

1 Testing pada Implementasi ERP HCMS modul Business Trip pada FIF Group Jayatri Puspa Dewi Universitas Bina Nusantara, , Woro Tanting Hesti Universitas Bina Nusantara, , Yonasto Lajar Universitas Bina Nusantara, , Win Ce Universitas Bina Nusantara, , 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

2 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.

3 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. Test Evaluation

4 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. KERANGKA PIKIR Test Planning General Process HCMS Modul Business Trip Merancang Test Plan Functionality Testing Test Evaluation Integration Testing Bugs Report Report Testing Rekomendasi Hasil Test Test Execution Gambar 2: Kerangka Pikir

5 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 YES Add New Setup Expense Type YES Add New Version Expense Type YES Edit Effective Date To Current Version Expense Type YES Edit Future Version Expense Type YES View Expense Type NO Delete Expense Type YES Search Upload Expense Plafond YES Download Expense Plafond YES Upload Expense Plafond YES View Detail Upload Expense Plafond NO Download Failed Record of Upload Expense Plafond NO Cancel Upload Expense Plafond NO Close Batch Upload Expense Plafond YES Test Setup Purpose Type Search Purpose Type YES Add New Setup Purpose Type YES Add New Version Purpose Type YES Edit Effective Date To Current YES Version Purpose Type Edit Future Version Purpose Type YES View Purpose Type NO Delete Purpose Type YES Test Functional - Business Trip Request dan Business Trip Settlement Search Business Trip Request & Business Trip Settlement YES Business Trip Request YES Resubmit Business Trip (by Other Employee) YES Businee Trip Settlement YES View Business Trip Request- Settlement Detail YES BTR Approval YES BTS Approval YES Test Functional Ticket Booking Search Ticket Booking YES Entry Ticket Booking YES Search Ticket Booking Invoice YES Entry Ticket Booking Invoice YES Ticket Booking Invoice Approval YES Test Functional Voucher Booking Search Voucher Booking YES Entry Voucher Booking YES Search Voucher Booking Invoice YES Entry Voucher Booking Invoice YES Voucher Booking Invoice YES

6 System Function or Feature Severity Priority Likelihood RPN Test Approval. Integration Testing Business Trip Kosong YES Business Trip with Prepayment YES Business Trip with Other Employee YES Business Trip with Ticket YES Business Trip with Voucher YES Business Trip with Prepayment and Other Employee. Business Trip with Prepayment and Ticket YES Business Trip with Prepayment and Voucher YES Business Trip with Other Employee and Ticket. Business Trip with Others Employee and Voucher. Business Trip with Ticket and Voucher YES Business Trip with Prepayment, Other Employee and Ticket. Business Trip with Prepayment, Other Employee and Voucher. Business Trip with Prepayment, Ticket and Voucher YES Business Trip with Other Employee, Ticket and Voucher. Business Trip with Prepayment, Other Employee, Ticket and Voucher. Report Testing Ticket Reservation Report YES Business Trip Monitoring Report YES Business Trip Settlement Report YES Budget Balance of Business Trip YES Report Business Trip Ticketing Report YES Nilai tambah dari testing yang kami lakukan adalah cara menentukan test case pada integration testing yang dapat dilakukan dengan cara sebagai berikut : Gambar 3: Tahapan menentukan test case untuk integration testing

7 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 di-reject dan di-approve, jika BTS Approval direject 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 :

8 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. 2. Roote Cause Charts

9 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 I 13 0 Test Setup II 0 13 III 0 0 I 27 3 Test Functionality II 7 19 III 0 12 I 9 0 Test Integration II 3 9 III 0 3

10 Test Phase Test Cycle Num of Bugs Opened Num of Bugs Closed I 2 0 Test Report 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

11 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 process-initialiation, processother, 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 saran yang dapat diberikan adalah sebagai berikut:

12 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 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 RiIWAYAT PENULIS Jayatri Puspa Dewi lahir di Jakarta pada 04 Januari Penulis menamatkan pendidikan S1 di Universitas Bina Nusantara dalam bidang Sistem Informasi Program Studi Komputerisasi Akuntansi pada Woro Tanting Hesti lahir di Palembang pada 13 Maret 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 Penulis menamatkan pendidikan S1 di Universitas Bina Nusantara dalam bidang Sistem Informasi Program Studi Komputerisasi Akuntansi pada Win Ce lahir di kota Pangkalpinang pada tanggal 28 September 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 Saat ini bekerja sebagai Software Laboratory Center Manager dan sekaligus menjadi dosen School of Information System di Universitas Bina Nusantara.