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