SAP Business One dan juga IReap POS ialah 2 aplikasi yang diterapkan di area yang berbeda, di mana SAP Business One bertujuan bikin back- end user dan juga IReap POS membuat front- end user. Keduanya silih berkaitan, data- knowledge yang dimasukkan lewat IReap POS hendak dikirimkan ke SAP Business One bikin diolah lagi. Tidak hanya itu, terdapat pula data- knowledge yang diinput berasal dari SAP Business One hendak dikirimkan ke IReap POS membuat kebutuhan operasional.
Tidak seluruh informasi yang dimasukkan lewat IReap POS dikirimkan ke SAP Business One. Begitu pula kebalikannya, tidak semua informasi yang dimasukkan lewat SAP Business One hendak dikirimkan ke IReap POS. Secara garis besar, integrasi pada IReap POS bersama SAP Business One mampu dilihat pada foto dibawah ini.
Informasi yang dikirim dari SAP Business One ke SAP Business One memakai format XML, begitu pula dengan Info yang dikirimkan berasal dari IReap POS ke IReap POS. Kedua aplikasi selanjutnya dengan menciptakan file XML, namun format susunan Info yang dihasilkan pastinya berbeda. Buat memperbandingkan format/ template struktur informasi antara kedua aplikasi tersebut diperlukan proses transformasi. Secara rinci, tersedia 6 sistem utama dalam integrasi antara IReap POS bersama dengan SAP Business One. Keenam sistem tersebut merupakan selaku 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 kala terjalin sistem import– export serta inbound– outbound, masih banyak sistem perinci yang dilakukan bertepatan. Buat lebih detailnya mampu dilihat terhadap foto dibawah ini.
Test Tracking Spreadsheet
Buat mempermudah pengelolaan terhadap penerapan pengujian bisa digunakan suatu perlengkapan yang dinamakan selaku test tracking spreadsheet. Dengan pemanfaatan test tracking spreadsheet, hendak membolehkan tester membuat melacak tiap standing berasal dari test case, mengenali konfigurasi yang digunakan serta mengetahui siapa yang sudah melakukan pengujian pada sesuatu test case.( Black, 2009: 200)
Kolom awal berasal dari test tracking spreadsheet selanjutnya memuat namatest suite/ test case dari sesuatu pengujian. Kolom state melukiskan status berasal dari masing- masing test case. Bila kolom state ini kosong, sampai mengindikasikan jika test case tersebut tetap dalam antrian bikin dicoba pengujian. Bila kolom ini memuat pass, sampai berarti kalau pengujian buat test case tersebut tidak menciptakan bug. Bila berisi fail, hingga bermakna terkandung bug yang ditemui berasal dari pengujian test case berikut baik satu ataupun lebih.
Kolom system config memuat penjelasan identifikasi buat mengetahui konfigurasi proses yang digunakan oleh masing- masing test case. Kolom bug id berisi bukti diri berasal dari bug yang ditemui dari hasil pengujian test case. Kolom ini yang nantinya hendak mempermudah test team buat melacak bug tersebut serta mereferensikannya pada bug report yang terbuat di dalam bug tracking database.
Kolom by berisi nama samaran dari tester yang sudah melakukan pengujian terhadap test case. Kolom comment berisi pendapat dari tester ataupun data bonus menimpa standing dari masing- masing test case. Kolom roll up berisi ringkasan dari knowledge menimpa status dari masing- masing test case. Kolom ini dibagi menjadi 3 kolom, ialah:
a) Kolom T berisi nilai 1 seumpama ialah test case.
b) Kolom F memuat nilai 1 seumpama status berasal dari test case merupakan fail.
c) Kolom P memuat nilai 1 kalau status dari test case merupakan pass.
Bug Report
Mengacu pada komentar Black( 2009: 146), bug report merupakan dokumen tekhnis yang digunakan buat mendeskripsikan beragam indikasi maupun kegagalan yang terkait bersama dengan suatu hal bug khusus secara khusus. Sesuatu dokumen bug report yang dirancang bersama dengan baik bisa membagikan data yang tepat untuk regu manajemen proyek menimpa bug tersebut sehingga sanggup mengambil alih ketentuan yang pas( misalnya, apakah bug berikut mesti lekas diperbaiki ataupun tidak). Tidak cuma itu, bug report pula sanggup digunakan oleh para programmer ataupun pengembang membuat mengetahui data rinci menimpa suatu hal bug agar mempermudah penyelesaian bug tersebut.
Field Bug ID berisi pengidentifikasi berasal dari sesuatu bug yang sanggup dijadikan rujukan dari suatu hal test tracking spreadsheet. Field Project Name berisi information menimpa nama proyek di mana bug berikut ditemui. Field Tester memuat information menimpa namatester yang menciptakan bug tersebut. Field Date Opened memuat information menimpa bertepatan pada bug selanjutnya dimasukkan ke didalam bug tracking database.
Field Quality Risk Category: Perinci berisi knowledge menimpa tipe rinci berasal dari quality risk yang didetetapkan secara tertentu bersumber pada bug tersebut. Field Subsystem memuat knowledge menimpa subsystem di mana bug selanjutnya ditemui. Field Configuration memuat knowledge menimpa konfigurasi yang digunakan dikala lakukan pengujian.
Field Severity serta Priority diisi bersama dengan skala yang serupa bersama dengan yang sudah dipaparkan terhadap anggota failure fashion plus effects analysis. Field RPN pada bug report didapat dari perkalian pada evaluasi severity serta priority. Dengan demikian, range berasal dari RPN merupakan berkisar pada 1– 25, dimana nilai 1 mengindikasikan kecuali bug tersebut amat beresiko dan juga nilai 25 mengindikasikan kecuali bug berikut cuma berkenaan sepele yang mampu diabaikan.
Field summary memuat penjelasan pendek menimpa bug. Field steps to reproduce menyediakan suatu hal gambaran yang tepat serta jelas perihal gimana menciptakan ulang bug tersebut. Field isolation berisi data buat menyakinkan pengembang/ programmer kecuali bug yang ditemui selanjutnya merupakan betul- betul bug. Perihal ini dapat bersama menjelaskan tanda- tanda timbulnya bug tersebut serta sanggup pula dengan menarangkan akibat dan pemicu dari timbulnya bug tersebut.
Field log berisi knowledge rinci menimpa siklus hidup berasal dari suatu hal bug merasa berasal dari dini pas bug berikut di- entry ke dalam bug tracking database. Ada pula cerminan siklus hidup dari bug report mampu dicermati pada foto dibawah ini.
State lihat menggambarkan standing bug dimana bug telah di- input ke didalam bug tracking database serta menunggu buat di- simak oleh reviewer waktu sebelum bug selanjutnya diinformasikan kepada segala regu proyek pengembangan. State rejected melukiskan standing di mana bug selanjutnya ditolak oleh reviewer gara-gara perlu riset ataupun information lebih lanjut menimpa bug tersebut. State open menggambarkan status dimana bug berikut udah di- lihat serta di anggap relevan dengan information rinci menimpa bug berikut serta diberitakan keberadaannya kepada segala regu proyek pengembangan.
State assigned menggambarkan standing di mana bug tersebut ditugaskan kepada pengembang buat mencari information lanjut menimpa bug selanjutnya dan menyelesaikannya. State test menggambarkan standing di mana bug tersebut telah berakhir diperbaiki oleh pengembang dan kudu diuji membuat membenarkan kalau bug berikut betul- betul udah diperbaiki.
State reopened melukiskan status dimana bug diakses ulang buat diperbaiki lagi oleh pengembang.
State closed melukiskan status dimana bug sudah berakhir diperbaiki dan juga sudah di konfirmasi kebenarannya melalui pengujian. State deferred mampu digunakan oleh bagian regu proyek buat menunda revisi bug tersebut andaikata mereka perhitungkan terkecuali bug tersebut mempunyai prioritas yang rendah.
State cancelled bisa digunakan oleh anggota regu proyek buat membatalkan revisi pada bug selanjutnya karena dinilai sudah tidak relevan lagi. Field Pemilik pada bug report menampilkan nama orang yang bertanggung jawab terhadap bug tersebut. Dengan ada field ini dikehendaki manajer proyek mampu bersama lebih ringan melacak ataupun melacak knowledge yang lebih rinci ulang menimpa bug tersebut.
Field Estimated Fixed berisi knowledge menimpa ditaksir bertepatan pada bug selanjutnya berakhir diperbaiki. Field Root Cause memuat knowledge menimpa pangkal pemicu berasal dari terjadinya bug tersebut. Bagi Black root cause dari sesuatu bug secara universal sanggup berbentuk:
a) Functional
Dari segi functional, pangkal pemicu dari suatu hal bug sanggup berbentuk spesifikasi yang salah, ataupun spesifikasinya benar tapi implementasinya salah, ataupun sistem berperan dengan benar tetapi hasil pengujian berikan tahu error yang salah.
b) System
Dari sisi system, pangkal pemicu dari suatu hal bug bisa berwujud gagalnya komunikasi proses internal, gagalnya hardware, gagalnya operating system, aplikasi architecture yang terbuat salah, ataupun pemikiran perancangan sudah benar tapi analisis kala pelaksanaannya salah.
c) Process
Dari segi process, pangkal pemicu dari sesuatu bug dapat bersifat salahnya operasional aritmatika yang diterapkan, proses inisialisasi yang salah, control ataupun sequence yang salah, maupun error di dalam pemrosesan.
d) Data
Dari segi informasi, pangkal pemicu berasal dari sesuatu bug sanggup berupa tipe informasi yang digunakan salah, struktur informasi yang keliru ataupun pemicu yang lain yang berhubungan dengan informasi.
e) Code
Dari sisi code, pangkal pemicu berasal dari sesuatu bug sanggup bersifat keliru pengetikan pada code.
f) Documentation
Dari segi documentation, pangkal pemicu dari suatu hal bug sanggup berwujud salahnya dokumentasi terhadap sistem.
gram) Standards
Dari sisi standards, pangkal pemicu berasal dari sesuatu bug mampu berupa tidak terpenuhnya standar yang semestinya pada proses tersebut.
h) Other
Root cause berasal dari bug dikategorikan ke didalam other seumpama pangkal pemicu dari bug sudah dikenal tapi tidak cocok bersama dengan jenis yang terdapat.
i) Duplicate
Root cause yang ini digunakan jika tersedia 2 maupun lebih bug report yang mengartikan bug yang sama.
j) NAP
Dikategorikan selaku NAP( Not a Problem) seandainya bug yang dilaporkan tersebut cuma gara-gara uraian yang salah oleh tester.
k) Bad Unit
Root cause ini digunakan seumpama bug berikut terkait kata kegagalan hardware yang tidak diprediksi.
l) RCN
RCN( Root Cause Needed) digunakan misalnya status berasal dari bug berikut telah closed namun tidak terdapat yang mengetahui pangkal pemicu dari terbentuknya bug tersebut.
meter) Unknown
Root cause unknown digunakan andaikata tidak terdapat orang yang mengenali apa yang terkait atas bug tersebut.
Field Phase Injected mengartikan fase di mana bug berikut dikenalkan, umumnya terhadap fase dini kala sebelum saat fase dimana bug selanjutnya teridentifikasi.
Field Phase Detected membatasi fase di mana bug berikut teridentifikasi.
Field Phase Removed mendefinisikan fase di mana bug selanjutnya berhasil diperbaiki.
Field Close Date menarangkan bertepatan pada di mana status dari bug tersebut jadi closed.
Field Resolution membatasi gimana bug berikut diperbaiki.
Dari seluruh bug report yang udah dimasukkan ke didalam bug tracking database sampai bisa dibuat.
0 Komentar