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