SAP Business One serta IReap POS ialah 2 aplikasi yang diterapkan di tempat yang berbeda, dimana SAP Business One dimaksudkan buat back- end user dan juga IReap POS buat front- end user. Keduanya silih berkaitan, data- data yang dimasukkan lewat IReap POS hendak dikirimkan ke SAP Business One bikin diolah lagi. Tidak cuma itu, terkandung pula data- information yang diinput dari SAP Business One hendak dikirimkan ke IReap POS bikin kebutuhan operasional.
Tidak seluruh informasi yang dimasukkan lewat IReap POS dikirimkan ke SAP Business One. Begitu pula kebalikannya, tidak seluruh informasi yang dimasukkan lewat SAP Business One hendak dikirimkan ke IReap POS. Secara garis besar, integrasi antara IReap POS bersama SAP Business One sanggup diamati pada foto di bawah 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 berikut dengan menciptakan file XML, tapi format susunan informasi yang dihasilkan sudah pasti berbeda. Buat memperbandingkan format/ template struktur Info antara ke-2 aplikasi berikut dibutuhkan proses transformasi. Secara rinci, ada 6 sistem utama dalam integrasi pada IReap POS bersama dengan SAP Business One. Keenam sistem berikut merupakan selaku berikut:
1. Export berasal 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 terjalin sistem import– export dan juga inbound– outbound, tetap banyak proses perinci yang dikerjakan bertepatan. Buat lebih detailnya mampu dicermati terhadap foto di bawah ini.
Test Tracking Spreadsheet
Buat mempermudah pengelolaan pada penerapan pengujian dapat digunakan suatu perlengkapan yang dinamakan selaku test tracking spreadsheet. Dengan penggunaan test tracking spreadsheet, hendak membolehkan tester buat mencari tiap status berasal dari test case, mengenali konfigurasi yang digunakan serta mengenali siapa yang udah melaksanakan pengujian pada suatu hal test case.( Black, 2009: 200)
Kolom awal dari test tracking spreadsheet berikut berisi namatest suite/ test case berasal dari sesuatu pengujian. Kolom state menggambarkan standing dari masing- masing test case. Bila kolom state ini kosong, hingga mengindikasikan jika test case tersebut tetap di dalam antrian buat dicoba pengujian. Bila kolom ini memuat pass, sampai artinya kalau pengujian membuat test case berikut tidak menciptakan bug. Bila memuat fail, hingga bermakna terkandung bug yang ditemui dari pengujian test case tersebut baik satu ataupun lebih.
Kolom system config berisi penjelasan identifikasi bikin mengetahui konfigurasi proses yang digunakan oleh masing- masing test case. Kolom bug id memuat bukti diri berasal dari bug yang ditemui berasal dari hasil pengujian test case. Kolom ini yang nantinya hendak mempermudah test team bikin mencari bug berikut serta mereferensikannya pada bug report yang terbuat didalam bug tracking database.
Kolom by berisi nama samaran dari tester yang udah jalankan pengujian pada test case. Kolom comment memuat pendapat dari tester ataupun information bonus menimpa standing berasal dari masing- masing test case. Kolom roll up berisi ringkasan dari knowledge menimpa standing dari masing- masing test case. Kolom ini dibagi menjadi 3 kolom, ialah:
a) Kolom T berisi nilai 1 misalnya ialah test case.
b) Kolom F memuat nilai 1 seumpama status dari test case merupakan fail.
c) Kolom P memuat nilai 1 seandainya standing berasal dari test case merupakan pass.
Bug Report
Mengacu terhadap komentar Black( 2009: 146), bug report merupakan dokumen tekhnis yang digunakan buat mendefinisikan berbagai indikasi maupun kegagalan yang terjalin bersama dengan suatu hal bug spesifik secara khusus. Sesuatu dokumen bug report yang dirancang bersama dengan baik mampu membagikan data yang tepat untuk regu manajemen proyek menimpa bug tersebut agar bisa menyita ketentuan yang pas( misalnya, apakah bug berikut perlu lekas diperbaiki ataupun tidak). Tidak cuma itu, bug report pula dapat digunakan oleh para programmer ataupun pengembang membuat mengenali data rinci menimpa sesuatu bug supaya mempermudah penyelesaian bug tersebut.
Field Bug ID memuat pengidentifikasi dari sesuatu bug yang sanggup dijadikan rujukan 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 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 terhadap bug tersebut. Field Subsystem berisi information menimpa subsystem dimana bug berikut ditemui. Field Configuration memuat information menimpa konfigurasi yang digunakan disaat melakukan pengujian.
Field Severity dan juga Priority diisi bersama dengan skala yang sama dengan yang udah dipaparkan pada bagian failure fashion plus effects analysis. Field RPN pada 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 kecuali bug berikut benar-benar berbahaya serta nilai 25 mengindikasikan jikalau bug tersebut cuma berkenaan sepele yang bisa diabaikan.
Field summary memuat penjelasan pendek menimpa bug. Field steps to reproduce sedia kan sesuatu uraian yang tepat dan juga jelas berkenaan gimana menciptakan lagi bug tersebut. Field isolation berisi information membuat menyakinkan pengembang/ programmer kalau bug yang ditemui berikut merupakan betul- betul bug. Perihal ini bisa bersama menyatakan tanda- isyarat timbulnya bug selanjutnya serta bisa pula dengan menarangkan akibat dan pemicu berasal dari timbulnya bug tersebut.
Field log berisi knowledge rinci menimpa siklus hidup berasal dari suatu hal bug jadi berasal dari dini sementara bug tersebut di- entry ke di dalam bug tracking database. Ada pula cerminan siklus hidup berasal dari bug report dapat dilihat pada foto dibawah ini.
State review menggambarkan status bug di mana bug telah di- input ke dalam bug tracking database dan juga menanti buat di- review oleh reviewer selagi sebelum saat bug selanjutnya diberitakan kepada segala regu proyek pengembangan. State rejected menggambarkan status dimana bug tersebut ditolak oleh reviewer karena mesti riset ataupun data lebih lanjut menimpa bug tersebut. State open melukiskan status dimana bug berikut telah di- liat dan juga dikira relevan dengan knowledge rinci menimpa bug berikut serta di informasikan keberadaannya kepada segala regu proyek pengembangan.
State assigned melukiskan standing dimana bug selanjutnya ditugaskan kepada pengembang membuat mencari information lanjut menimpa bug selanjutnya dan menyelesaikannya. State test menggambarkan status di mana bug berikut telah berakhir diperbaiki oleh pengembang dan kudu diuji buat membenarkan kalau bug berikut betul- betul telah diperbaiki.
State reopened menggambarkan standing di mana bug dibuka ulang membuat diperbaiki lagi oleh pengembang.
State closed melukiskan standing dimana bug sudah berakhir diperbaiki dan juga udah dikonfirmasi kebenarannya melalui pengujian. State deferred mampu digunakan oleh anggota regu proyek membuat menunda revisi bug selanjutnya bila mereka memperhitungkan jikalau bug berikut membawa prioritas yang rendah.
State cancelled bisa digunakan oleh anggota regu proyek bikin membatalkan revisi pada bug tersebut dikarenakan dinilai telah tidak relevan lagi. Field Pemilik terhadap bug report menampilkan nama orang yang bertanggung jawab pada bug tersebut. Dengan terdapatnya field ini diharapkan manajer proyek dapat dengan lebih enteng melacak ataupun melacak data yang lebih rinci kembali menimpa bug tersebut.
Field Estimated Fixed memuat data menimpa ditaksir bertepatan pada bug tersebut berakhir diperbaiki. Field Root Cause berisi information menimpa pangkal pemicu dari terjadinya bug tersebut. Bagi Black root cause berasal dari suatu hal bug secara universal bisa berbentuk:
a) Functional
Dari segi functional, pangkal pemicu berasal dari suatu hal bug mampu berwujud spesifikasi yang salah, ataupun spesifikasinya benar namun implementasinya salah, ataupun sistem berperan dengan benar namun hasil pengujian berikan jelas error yang salah.
b) System
Dari sisi system, pangkal pemicu berasal dari suatu hal bug mampu bersifat gagalnya komunikasi proses internal, gagalnya hardware, gagalnya operating system, aplikasi architecture yang terbuat salah, ataupun analisis perancangan sudah benar namun analisis ketika pelaksanaannya salah.
c) Process
Dari segi process, pangkal pemicu berasal dari suatu hal bug sanggup berwujud salahnya operasional aritmatika yang diterapkan, proses inisialisasi yang salah, control ataupun sequence yang salah, maupun error didalam pemrosesan.
d) Data
Dari sisi informasi, pangkal pemicu dari suatu hal bug sanggup bersifat tipe Info yang digunakan salah, susunan Info yang keliru ataupun pemicu yang lain yang terkait dengan informasi.
e) Code
Dari segi code, pangkal pemicu berasal dari sesuatu bug mampu berwujud keliru pengetikan terhadap code.
f) Documentation
Dari segi documentation, pangkal pemicu dari suatu hal bug mampu berwujud salahnya dokumentasi pada sistem.
gram) Standards
Dari sisi standards, pangkal pemicu berasal dari sesuatu bug dapat berbentuk tidak terpenuhnya standar yang sepatutnya pada proses tersebut.
h) Other
Root cause dari bug dikategorikan ke dalam other bila pangkal pemicu dari bug udah dikenal tetapi tidak cocok bersama type yang terdapat.
i) Duplicate
Root cause yang ini digunakan jika ada 2 maupun lebih bug report yang mengartikan bug yang sama.
j) NAP
Dikategorikan selaku NAP( Not a Problem) misalnya bug yang dilaporkan selanjutnya cuma sebab gambaran yang keliru oleh tester.
k) Bad Unit
Root cause ini digunakan bila bug berikut berhubungan kata kegagalan hardware yang tidak diprediksi.
l) RCN
RCN( Root Cause Needed) digunakan andaikan status berasal dari bug selanjutnya udah closed namun tidak terdapat yang mengenali pangkal pemicu dari terbentuknya bug tersebut.
meter) Unknown
Root cause unknown digunakan sekiranya tidak terkandung orang yang mengenali apa yang terkait atas bug tersebut.
Field Phase Injected mengartikan fase di mana bug tersebut dikenalkan, kebanyakan terhadap fase dini pas sebelum fase di mana bug tersebut teridentifikasi.
Field Phase Detected mendefinisikan fase dimana bug berikut teridentifikasi.
Field Phase Removed mengartikan fase dimana bug berikut sukses diperbaiki.
Field Close Date menarangkan bertepatan pada di mana standing berasal dari bug berikut jadi closed.
Field Resolution mendeskripsikan gimana bug selanjutnya diperbaiki.
Dari seluruh bug report yang udah dimasukkan ke di dalam bug tracking database hingga dapat dibuat.
0 Komentar