SAP Business One serta IReap POS ialah 2 aplikasi yang diterapkan di area yang berbeda, di mana SAP Business One ditujukan bikin 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 bikin diolah lagi. Tidak cuma itu, terdapat pula data- information yang diinput dari SAP Business One hendak dikirimkan ke IReap POS membuat keperluan 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 pada IReap POS bersama SAP Business One mampu dicermati terhadap foto di bawah ini.
Informasi yang dikirim berasal dari SAP Business One ke SAP Business One memakai format XML, begitu pula bersama Info yang dikirimkan berasal dari IReap POS ke IReap POS. Kedua aplikasi tersebut bersama menciptakan file XML, tapi format susunan Info yang dihasilkan tentunya berbeda. Buat memperbandingkan format/ template struktur informasi pada ke dua aplikasi selanjutnya dibutuhkan sistem transformasi. Secara rinci, tersedia 6 sistem utama didalam integrasi pada IReap POS dengan SAP Business One. Keenam proses tersebut 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 berasal 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 sistem perinci yang dikerjakan bertepatan. Buat lebih detailnya sanggup dicermati terhadap foto dibawah ini.
Test Tracking Spreadsheet
Buat mempermudah pengelolaan pada penerapan pengujian sanggup digunakan suatu perlengkapan yang dinamakan selaku test tracking spreadsheet. Dengan penggunaan test tracking spreadsheet, hendak membolehkan tester bikin melacak tiap status dari test case, mengenali konfigurasi yang digunakan serta mengenali siapa yang udah laksanakan pengujian pada sesuatu test case.( Black, 2009: 200)
Kolom awal berasal dari test tracking spreadsheet selanjutnya berisi namatest suite/ test case berasal dari suatu hal pengujian. Kolom state melukiskan standing berasal dari masing- masing test case. Bila kolom state ini kosong, hingga mengindikasikan kalau test case selanjutnya masih didalam antrian buat dicoba pengujian. Bila kolom ini berisi pass, hingga berarti kalau pengujian buat test case tersebut tidak menciptakan bug. Bila berisi fail, sampai artinya terkandung bug yang ditemui dari pengujian test case berikut baik satu ataupun lebih.
Kolom system config memuat penjelasan identifikasi buat mengetahui 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 bikin melacak bug tersebut dan juga mereferensikannya terhadap bug report yang terbuat di dalam bug tracking database.
Kolom by memuat nama samaran berasal dari tester yang udah jalankan pengujian pada test case. Kolom comment berisi pendapat berasal dari tester ataupun data bonus menimpa standing dari masing- masing test case. Kolom roll up memuat ringkasan berasal dari information menimpa status berasal dari masing- masing test case. Kolom ini dibagi menjadi 3 kolom, ialah:
a) Kolom T memuat nilai 1 jikalau ialah test case.
b) Kolom F memuat nilai 1 jika standing berasal dari test case merupakan fail.
c) Kolom P memuat nilai 1 jika status berasal dari test case merupakan pass.
Bug Report
Mengacu terhadap komentar Black( 2009: 146), bug report merupakan dokumen tehnis yang digunakan buat mengartikan berbagai indikasi maupun kegagalan yang terjalin bersama dengan sesuatu bug spesifik secara khusus. Sesuatu dokumen bug report yang dirancang dengan baik bisa membagikan data yang tepat untuk regu manajemen proyek menimpa bug selanjutnya agar dapat mengambil ketetapan yang pas( misalnya, apakah bug selanjutnya kudu lekas diperbaiki ataupun tidak). Tidak cuma itu, bug report pula dapat digunakan oleh para programmer ataupun pengembang buat mengenali data rinci menimpa suatu hal bug supaya mempermudah penyelesaian bug tersebut.
Field Bug ID berisi pengidentifikasi berasal dari suatu hal bug yang bisa dijadikan rujukan dari sesuatu test tracking spreadsheet. Field Project Name berisi information menimpa nama proyek dimana bug selanjutnya ditemui. Field Tester berisi information menimpa namatester yang menciptakan bug tersebut. Field Date Opened berisi knowledge menimpa bertepatan pada bug tersebut dimasukkan ke di dalam bug tracking database.
Field Quality Risk Category: Perinci memuat information menimpa tipe rinci dari quality risk yang didetetapkan secara tertentu bersumber terhadap bug tersebut. Field Subsystem berisi data menimpa subsystem dimana bug tersebut ditemui. Field Configuration memuat data menimpa konfigurasi yang digunakan dikala melaksanakan pengujian.
Field Severity serta Priority diisi bersama skala yang mirip dengan yang udah dipaparkan pada anggota failure fashion plus effects analysis. Field RPN terhadap bug report didapat dari perkalian antara evaluasi severity dan juga priority. Dengan demikian, range dari RPN merupakan berkisar antara 1– 25, dimana nilai 1 mengindikasikan jika bug tersebut sangat berbahaya serta nilai 25 mengindikasikan jika bug berikut cuma perihal sepele yang mampu diabaikan.
Field summary berisi penjelasan pendek menimpa bug. Field steps to reproduce sedia kan suatu hal uraian yang tepat dan juga mengetahui mengenai gimana menciptakan lagi bug tersebut. Field isolation memuat information membuat menyakinkan pengembang/ programmer kecuali bug yang ditemui selanjutnya merupakan betul- betul bug. Perihal ini dapat bersama mengatakan tanda- isyarat munculnya bug selanjutnya serta sanggup pula dengan menarangkan akibat dan pemicu berasal dari timbulnya bug tersebut.
Field log berisi information rinci menimpa siklus hidup berasal dari sesuatu bug merasa dari dini saat bug tersebut di- entry ke didalam bug tracking database. Ada pula cerminan siklus hidup dari bug report sanggup diamati pada foto dibawah ini.
State simak menggambarkan standing bug dimana bug sudah di- input ke didalam bug tracking database dan juga menunggu bikin di- simak oleh reviewer saat sebelum bug berikut di informasikan kepada segala regu proyek pengembangan. State rejected melukiskan status di mana bug berikut tidak diterima oleh reviewer gara-gara mesti riset ataupun data lebih lanjut menimpa bug tersebut. State open melukiskan status di mana bug tersebut telah di- review dan juga di kira relevan bersama dengan information rinci menimpa bug tersebut serta diinformasikan keberadaannya kepada segala regu proyek pengembangan.
State assigned menggambarkan status dimana bug berikut ditugaskan kepada pengembang buat mencari information lanjut menimpa bug selanjutnya dan menyelesaikannya. State test melukiskan status dimana bug berikut udah berakhir diperbaiki oleh pengembang dan mesti diuji membuat membetulkan kecuali bug berikut betul- betul telah diperbaiki.
State reopened menggambarkan standing dimana bug dibuka ulang membuat diperbaiki lagi oleh pengembang.
State closed melukiskan status dimana bug udah berakhir diperbaiki serta udah dilakukan konfirmasi kebenarannya melalui pengujian. State deferred bisa digunakan oleh anggota regu proyek buat menunda revisi bug selanjutnya jikalau mereka pertimbangkan kecuali bug selanjutnya membawa prioritas yang rendah.
State cancelled sanggup digunakan oleh anggota regu proyek membuat membatalkan revisi pada bug tersebut karena dinilai udah tidak relevan lagi. Field Pemilik terhadap bug report menampilkan nama orang yang bertanggung jawab terhadap bug tersebut. Dengan adanya field ini diharapkan manajer proyek mampu bersama dengan lebih mudah mencari ataupun mencari information yang lebih rinci kembali menimpa bug tersebut.
Field Estimated Fixed memuat knowledge menimpa ditaksir bertepatan terhadap bug tersebut berakhir diperbaiki. Field Root Cause berisi knowledge menimpa pangkal pemicu dari terjadinya bug tersebut. Bagi Black root cause dari sesuatu bug secara universal mampu berbentuk:
a) Functional
Dari segi functional, pangkal pemicu dari suatu hal bug sanggup berupa spesifikasi yang salah, ataupun spesifikasinya benar tetapi implementasinya salah, ataupun sistem berperan bersama benar tapi hasil pengujian memberi menyadari error yang salah.
b) System
Dari segi system, pangkal pemicu berasal dari suatu hal bug bisa berbentuk gagalnya komunikasi proses internal, gagalnya hardware, gagalnya operating system, aplikasi architecture yang terbuat salah, ataupun anggapan perancangan telah benar namun analisis saat pelaksanaannya salah.
c) Process
Dari segi 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 di dalam pemrosesan.
d) Data
Dari sisi informasi, pangkal pemicu dari sesuatu bug sanggup berupa model informasi yang digunakan salah, struktur Info yang salah ataupun pemicu yang lain yang terkait dengan informasi.
e) Code
Dari segi code, pangkal pemicu berasal dari sesuatu bug bisa bersifat salah pengetikan terhadap code.
f) Documentation
Dari sisi documentation, pangkal pemicu dari suatu hal bug bisa berupa salahnya dokumentasi pada sistem.
gram) Standards
Dari segi standards, pangkal pemicu dari suatu hal bug mampu berwujud tidak terpenuhnya standar yang sewajarnya terhadap sistem tersebut.
h) Other
Root cause dari bug dikategorikan ke di dalam other misalnya pangkal pemicu dari bug sudah dikenal tapi tidak sesuai bersama type yang terdapat.
i) Duplicate
Root cause yang ini digunakan kalau tersedia 2 maupun lebih bug report yang mendeskripsikan bug yang sama.
j) NAP
Dikategorikan selaku NAP( Not a Problem) jika bug yang dilaporkan selanjutnya hanya gara-gara deskripsi yang keliru oleh tester.
k) Bad Unit
Root cause ini digunakan bila bug tersebut terkait kata kegagalan hardware yang tidak diprediksi.
l) RCN
RCN( Root Cause Needed) digunakan bila standing dari bug berikut udah closed namun tidak terdapat yang mengetahui pangkal pemicu berasal dari terbentuknya bug tersebut.
meter) Unknown
Root cause unknown digunakan jika tidak terkandung orang yang mengenali apa yang terjalin atas bug tersebut.
Field Phase Injected mendeskripsikan fase dimana bug selanjutnya dikenalkan, kebanyakan terhadap fase dini waktu sebelum saat fase di mana bug berikut teridentifikasi.
Field Phase Detected mendeskripsikan fase di mana bug selanjutnya teridentifikasi.
Field Phase Removed mendefinisikan fase di mana bug berikut sukses diperbaiki.
Field Close Date menarangkan bertepatan pada dimana standing dari bug selanjutnya jadi closed.
Field Resolution mendeskripsikan gimana bug selanjutnya diperbaiki.
Dari semua bug report yang telah dimasukkan ke di dalam bug tracking database hingga dapat dibuat.
0 Komentar