Testing pada Implementasi ERP HCMS modul Business Trip pada FIF Group

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

7.

8.

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

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.

System Function or Feature Search Expense Type Add New Setup Expense Type Add New Version Expense Type Edit Effective Date To Current Version Expense Type Edit Future Version Expense Type View Expense Type Delete Expense Type Search Upload Expense Plafond Download Expense Plafond Upload Expense Plafond View Detail Upload Expense Plafond Download Failed Record of Upload Expense Plafond Cancel Upload Expense Plafond Close Batch Upload Expense Plafond

Tabel 1: FMEA Severity Priority Likelihood Test Setup – Expense Type 2 1 1 2 2 1 2 2 1

RPN

Test

2 4 4

YES YES YES

2

2

1

4

YES

2 3 2 2 2 2

2 4 2 3 2 2

1 4 1 2 4 1

4 48 4 12 16 4

YES NO YES YES YES YES

3

3

4

36

NO

2

3

3

18

NO

3

3

4

36

NO

2

2

2

8

YES

Test Setup – Purpose Type Search Purpose Type 2 1 1 2 Add New Setup Purpose Type 2 2 1 4 Add New Version Purpose Type 2 2 1 4 Edit Effective Date To Current 2 2 1 4 Version Purpose Type Edit Future Version Purpose Type 2 2 1 4 View Purpose Type 3 4 4 48 Delete Purpose Type 2 2 1 4 Test Functional - Business Trip Request dan Business Trip Settlement Search Business Trip Request & 2 1 1 2 Business Trip Settlement Business Trip Request 2 1 1 2 Resubmit Business Trip (by Other 2 1 1 2 Employee) Businee Trip Settlement 2 1 1 2 View Business Trip Request2 3 1 6 Settlement Detail BTR Approval 2 1 1 2 BTS Approval 2 1 1 2 Test Functional – Ticket Booking Search Ticket Booking 2 1 1 2 Entry Ticket Booking 2 1 1 2 Search Ticket Booking Invoice 2 1 1 2 Entry Ticket Booking Invoice. 2 1 1 2 Ticket Booking Invoice Approval. 2 1 1 2 Test Functional – Voucher Booking Search Voucher Booking 2 1 1 2 Entry Voucher Booking 2 1 1 2 Search Voucher Booking Invoice 2 1 1 2 Entry Voucher Booking Invoice. 2 1 1 2 Voucher Booking Invoice 2 1 1 2

YES YES YES YES YES NO YES YES YES YES YES YES YES YES YES YES YES YES YES YES YES YES YES YES

System Function or Feature Approval. Business Trip Kosong. Business Trip with Prepayment. Business Trip with Other Employee. Business Trip with Ticket. Business Trip with Voucher. Business Trip with Prepayment and Other Employee. Business Trip with Prepayment and Ticket. Business Trip with Prepayment and Voucher. Business Trip with Other Employee and Ticket. Business Trip with Others Employee and Voucher. Business Trip with Ticket and Voucher. Business Trip with Prepayment, Other Employee and Ticket. Business Trip with Prepayment, Other Employee and Voucher. Business Trip with Prepayment, Ticket and Voucher. Business Trip with Other Employee, Ticket and Voucher. Business Trip with Prepayment, Other Employee, Ticket and Voucher. Ticket Reservation Report Business Trip Monitoring Report Business Trip Settlement Report Budget Balance of Business Trip Report Business Trip Ticketing Report

Severity

Priority

Integration Testing 2 2 2 2

Likelihood

RPN

Test

2 2

8 8

YES YES

2

2

2

8

YES

2 2

2 2

2 2

8 8

YES YES

4

4

3

48

NO

2

2

2

8

YES

2

2

2

8

YES

4

4

3

48

NO

4

4

3

48

NO

2

2

2

8

YES

4

4

3

48

NO

4

4

3

48

NO

2

2

2

8

YES

4

4

3

48

NO

4

4

3

48

NO

Report Testing 2 2 2 2 2 2 2 2

4 4 4 4

16 16 16 16

YES YES YES

2

4

16

YES

2

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

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 :

2 2

5

1

4

2 2

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 :

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

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

Test Phase Test Setup

Test Functionality

Test Integration

Tabel 2 : Jumlah Bugs pada Test Cycle Test Cycle Num of Bugs Opened 13 I 0 II III 0 27 I 7 II III 0 9 I 3 II III 0

Num of Bugs Closed 0 13 0 3 19 12 0 9 3

Test Phase Test Report

Test Cycle I II III

Num of Bugs Opened 2 0 0

Num of Bugs Closed 0 2 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

3)

4)

5)

6)

7)

5.2

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

1)

2)

3)

4)

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