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