SAP Business One dan IReap POS merupakan dua aplikasi yang diterapkan di lingkungan yang berbeda, dimana SAP Business One dimaksudkan untuk back-end user dan IReap POS untuk front-end user. Keduanya saling berkaitan, data-data yang dimasukkan melalui IReap POS akan dikirimkan ke SAP Business One untuk diolah lagi. Selain itu, ada juga data-data yang diinput dari SAP Business One akan dikirimkan ke IReap POS untuk kebutuhan operasional.
Tidak semua data yang dimasukkan melalui IReap POS dikirimkan ke SAP Business One. Begitu juga sebaliknya, tidak semua data yang dimasukkan melalui SAP Business One akan dikirimkan ke IReap POS. Secara garis besar, integrasi antara IReap POS dengan SAP Business One dapat dilihat pada gambar dibawah ini.
Data yang dikirim dari SAP Business One ke SAP Business One menggunakan format XML, begitu juga dengan data yang dikirimkan dari IReap POS ke IReap POS. Kedua aplikasi tersebut sama-sama menghasilkan file XML, tetapi format struktur data yang dihasilkan tentunya berbeda. Untuk menyamakan format/ template struktur data antara kedua aplikasi tersebut dibutuhkan proses transformasi. Secara rinci, terdapat enam proses utama dalam integrasi antara IReap POS dengan SAP Business One. Keenam proses tersebut adalah sebagai berikut:
1. Export dari POS Server
2. Tranformasi dari dokumen IReap POS ke dokumen SAP Business One
3. Inbound ke SAP Business One
4. Outbound dari SAP Business One
5. Transformasi dari dokumen SAP Business One ke dokumen IReap POS
6. Import ke POS Server
Pada saat terjadi proses import – export dan inbound – outbound, masih banyak proses detail yang dijalankan bersamaan. Untuk lebih detailnya dapat dilihat pada gambar dibawah ini.
Test Tracking Spreadsheet
Untuk memudahkan pengelolaan terhadap pelaksanaan pengujian dapat digunakan sebuah alat yang dinamakan sebagai test tracking spreadsheet. Dengan penggunaan test tracking spreadsheet, akan memungkinkan tester untuk melacak setiap status dari test case, mengetahui konfigurasi yang digunakan dan mengetahui siapa yang telah melaksanakan pengujian terhadap suatu test case. (Black, 2009: 200)
Kolom pertama dari test tracking spreadsheet tersebut berisi namatest suite/ test case dari suatu pengujian. Kolom state menggambarkan status dari tiap test case. Jika kolom state ini kosong, maka mengindikasikan bahwa test case tersebut masih dalam antrian untuk dilakukan pengujian. Jika kolom ini berisi pass, maka berarti bahwa pengujian untuk test case tersebut tidak menemukan bug. Jika berisi fail, maka berarti ada bug yang ditemukan dari pengujian test case tersebut baik satu maupun lebih.
Kolom system config berisi keterangan identifikasi untuk mengetahui konfigurasi sistem yang digunakan oleh tiap test case. Kolom bug id berisi identitas dari bug yang ditemukan dari hasil pengujian test case. Kolom ini yang nantinya akan memudahkan test team untuk melacak bug tersebut dan mereferensikannya terhadap bug report yang dibuat dalam bug tracking database.
Kolom by berisi inisial dari tester yang telah melakukan pengujian terhadap test case. Kolom comment berisi komentar dari tester atau informasi tambahan mengenai status dari tiap test case. Kolom roll up berisi ringkasan dari informasi mengenai status dari tiap test case. Kolom ini terbagi menjadi tiga kolom, yaitu:
a) Kolom T berisi nilai 1 jika merupakan test case.
b) Kolom F berisi nilai 1 jika status dari test case adalah fail.
c) Kolom P berisi nilai 1 jika status dari test case adalah pass.
Bug Report
Mengacu pada pendapat Black (2009: 146), bug report adalah dokumen teknis yang digunakan untuk mendeskripsikan berbagai gejala ataupun kegagalan yang berhubungan dengan suatu bug tertentu secara spesifik. Suatu dokumen bug report yang dirancang dengan baik dapat memberikan informasi yang tepat bagi tim manajemen proyek mengenai bug tersebut sehingga dapat mengambil keputusan yang tepat (misalnya, apakah bug tersebut harus segera diperbaiki atau tidak). Selain itu, bug report juga dapat digunakan oleh para programmer atau developer untuk mengetahui informasi rinci mengenai suatu bug sehingga memudahkan penyelesaian bug tersebut.
Field Bug ID berisi pengidentifikasi dari suatu bug yang dapat dijadikan referensi dari suatu test tracking spreadsheet. Field Project Name berisi informasi mengenai nama proyek dimana bug tersebut ditemukan. Field Tester berisi informasi mengenai namatester yang menemukan bug tersebut. Field Date Opened berisi informasi mengenai tanggal bug tersebut dimasukkan ke dalam bug tracking database.
Field Quality Risk Category: Detail berisi informasi mengenai kategori rinci dari quality risk yang ditentukan secara spesifik berdasarkan bug tersebut. Field Subsystem berisi informasi mengenai subsystem dimana bug tersebut ditemukan. Field Configuration berisi informasi mengenai konfigurasi yang digunakan saat melakukan pengujian.
Field Severity dan Priority diisi dengan skala yang sama dengan yang telah dijelaskan pada bagian failure mode and effects analysis. Field RPN pada bug report didapat dari perkalian antara penilaian severity dan priority. Dengan demikian, range dari RPN adalah berkisar antara 1 – 25, dimana nilai 1 mengindikasikan bahwa bug tersebut sangat berbahaya dan nilai 25 mengindikasikan bahwa bug tersebut hanya hal sepele yang dapat diabaikan.
Field summary berisi uraian singkat mengenai bug. Field steps to reproduce menyediakan suatu deskripsi yang tepat dan jelas tentang bagaimana menghasilkan kembali bug tersebut. Field isolation berisi informasi untuk menyakinkan developer/ programmer bahwa bug yang ditemukan tersebut adalah benar-benar bug. Hal ini bisa dengan menyebutkan gejala-gejala timbulnya bug tersebut dan bisa juga dengan menjelaskan dampak serta penyebab dari timbulnya bug tersebut.
Field log berisi informasi rinci mengenai siklus hidup dari suatu bug mulai dari awal ketika bug tersebut di-entry ke dalam bug tracking database.Adapun gambaran siklus hidup dari bug report dapat dilihat pada gambar dibawah ini.
State review menggambarkan status bug dimana bug telah di-input ke dalam bug tracking database dan menunggu untuk di-review oleh reviewer sebelum bug tersebut diinformasikan kepada seluruh tim proyek pengembangan. State rejected menggambarkan status dimana bug tersebut ditolak oleh reviewer karena butuh penelitian atau informasi lebih lanjut mengenai bug tersebut. State open menggambarkan status dimana bug tersebut telah di-review dan dianggap relevan dengan informasi rinci mengenai bug tersebut dan diinformasikan keberadaannya kepada seluruh tim proyek pengembangan.
State assigned menggambarkan status dimana bug tersebut ditugaskan kepada developer untuk mencari informasi lanjut mengenai bug tersebut serta menyelesaikannya. State test menggambarkan status dimana bug tersebut telah selesai diperbaiki oleh developer serta harus diuji untuk memastikan bahwa bug tersebut benar-benar sudah diperbaiki.
State reopened menggambarkan status dimana bug dibuka kembali untuk diperbaiki lagi oleh developer. State closed menggambarkan status dimana bug telah selesai diperbaiki dan telah dikonfirmasi kebenarannya melalui pengujian. State deferred dapat digunakan oleh anggota tim proyek untuk menunda perbaikan bug tersebut jika mereka menilai bahwa bug tersebut memiliki prioritas yang rendah.
State cancelled dapat digunakan oleh anggota tim proyek untuk membatalkan perbaikan terhadap bug tersebut karena dinilai sudah tidak relevan lagi. Field Owner pada bug report menunjukkan nama orang yang bertanggung jawab terhadap bug tersebut. Dengan adanya field ini diharapkan manajer proyek dapat dengan lebih mudah melacak atau mencari informasi yang lebih rinci lagi mengenai bug tersebut.
Field Estimated Fixed berisi informasi mengenai perkiraan tanggal bug tersebut selesai diperbaiki. Field Root Cause berisi informasi mengenai akar penyebab dari terbentuknya bug tersebut. Menurut Black root cause dari suatu bug secara umum dapat berupa:
a) Functional
Dari sisi functional, akar penyebab dari suatu bug dapat berupa spesifikasi yang salah, atau spesifikasinya benar tetapi implementasinya salah, atau sistem berfungsi dengan benar tetapi hasil pengujian melaporkan error yang salah.
b) System
Dari sisi system, akar penyebab dari suatu bug dapat berupa gagalnya komunikasi sistem internal, gagalnya hardware, gagalnya operating system, software architecture yang dibuat salah, atau asumsi perancangan sudah benar tetapi asumsi saat penerapannya salah.
c) Process
Dari sisi process, akar penyebab dari suatu bug dapat berupa salahnya operasional aritmatika yang diterapkan, proses inisialisasi yang salah, control atau sequence yang salah, ataupun error dalam pemrosesan.
d) Data
Dari sisi data, akar penyebab dari suatu bug dapat berupa tipe data yang digunakan salah, struktur data yang salah atau penyebab lainnya yang berhubungan dengan data.
e) Code
Dari sisi code, akar penyebab dari suatu bug dapat berupa salah pengetikan pada code.
f) Documentation
Dari sisi documentation, akar penyebab dari suatu bug dapat berupa salahnya dokumentasi terhadap sistem.
g) Standards
Dari sisi standards, akar penyebab dari suatu bug dapat berupa tidak terpenuhnya standar yang seharusnya terhadap sistem tersebut.
h) Other
Root cause dari bug dikategorikan ke dalam other jika akar penyebab dari bug telah diketahui tetapi tidak sesuai dengan kategori yang ada.
i) Duplicate
Root cause yang ini digunakan jika terdapat dua ataupun lebih bug report yang mendeskripsikan bug yang sama.
j) NAP
Dikategorikan sebagai NAP (Not a Problem) jika bug yang dilaporkan tersebut hanya karena pemahaman yang salah oleh tester.
k) Bad Unit
Root cause ini digunakan jika bug tersebut terjadi kata kegagalan hardware yang tidak diduga.
l) RCN
RCN (Root Cause Needed) digunakan jika status dari bug tersebut sudah closed tetapi tidak ada yang mengetahui akar penyebab dari terjadinya bug tersebut.
m) Unknown
Root cause unknown digunakan jika tidak ada orang yang mengetahui apa yang terjadi atas bug tersebut.
- Field Phase Injected mendeskripsikan fase dimana bug tersebut dikenalkan, biasanya pada fase awal sebelum fase dimana bug tersebut teridentifikasi.
- Field Phase Detected mendeskripsikan fase dimana bug tersebut teridentifikasi.
- Field Phase Removed mendeskripsikan fase dimana bug tersebut berhasil diperbaiki.
- Field Close Date menjelaskan tanggal dimana status dari bug tersebut menjadi closed.
- Field Resolution mendeskripsikan bagaimana bug tersebut diperbaiki.
Dari semua bug report yang telah dimasukkan ke dalam bug tracking database maka dapat dibuatkan grafik-grafik yang mendukung sebagai laporan terhadap manajer proyek.
No comments:
Post a Comment