SAP Business One dan juga IReap POS ialah 2 aplikasi yang diterapkan di daerah yang berbeda, di mana SAP Business One ditujukan membuat back- end user serta IReap POS bikin front- end user. Keduanya silih berkaitan, data- data yang dimasukkan melalui IReap POS hendak dikirimkan ke SAP Business One membuat diolah lagi. Tidak cuma itu, terdapat pula data- information yang diinput berasal 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 Info yang dimasukkan melalui SAP Business One hendak dikirimkan ke IReap POS. Secara garis besar, integrasi antara IReap POS bersama dengan SAP Business One mampu dicermati pada foto dibawah ini.
Informasi yang dikirim berasal dari SAP Business One ke SAP Business One Mengenakan format XML, begitu pula bersama dengan informasi yang dikirimkan berasal dari IReap POS ke IReap POS. Kedua aplikasi berikut bersama menciptakan file XML, namun format susunan Info yang dihasilkan tentunya berbeda. Buat membandingkan format/ template struktur Info pada kedua aplikasi berikut diperlukan sistem transformasi. Secara rinci, ada 6 proses utama di dalam integrasi antara IReap POS bersama SAP Business One. Keenam proses berikut merupakan selaku berikut:
1. Export berasal dari POS Server
2. Tranformasi 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 kala terkait proses import– export serta inbound– outbound, masih banyak sistem perinci yang dijalankan bertepatan. Buat lebih detailnya sanggup 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 membuat mencari tiap status berasal dari test case, mengetahui konfigurasi yang digunakan serta mengenali siapa yang telah melakukan 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 menggambarkan status berasal dari masing- masing test case. Bila kolom state ini kosong, sampai mengindikasikan kecuali test case selanjutnya tetap di dalam antrian membuat dicoba pengujian. Bila kolom ini memuat pass, sampai artinya jikalau pengujian membuat test case selanjutnya tidak menciptakan bug. Bila memuat fail, sampai berarti terdapat bug yang ditemui dari pengujian test case tersebut baik satu ataupun lebih.
Kolom system config memuat penjelasan identifikasi membuat mengetahui konfigurasi proses yang digunakan oleh masing- masing test case. Kolom bug id memuat bukti diri dari bug yang ditemui berasal dari hasil pengujian test case. Kolom ini yang nantinya hendak mempermudah test team membuat melacak bug berikut dan juga mereferensikannya pada bug report yang terbuat dalam bug tracking database.
Kolom by memuat nama samaran berasal dari tester yang sudah melakukan pengujian terhadap test case. Kolom comment memuat pendapat berasal dari tester ataupun data bonus menimpa standing berasal dari masing- masing test case. Kolom roll up berisi ringkasan berasal dari knowledge menimpa standing berasal dari masing- masing test case. Kolom ini dibagi jadi 3 kolom, ialah:
a) Kolom T memuat nilai 1 andaikan ialah test case.
b) Kolom F berisi nilai 1 bila standing berasal dari test case merupakan fail.
c) Kolom P berisi nilai 1 andaikan status dari test case merupakan pass.
Bug Report
Mengacu terhadap komentar Black( 2009: 146), bug report merupakan dokumen teknis yang digunakan bikin mendefinisikan bermacam indikasi maupun kegagalan yang berhubungan dengan sesuatu bug khusus secara khusus. Sesuatu dokumen bug report yang dirancang bersama dengan baik bisa membagikan knowledge yang pas untuk regu manajemen proyek menimpa bug berikut sehingga bisa mengambil alih keputusan yang pas( misalnya, apakah bug tersebut mesti lekas diperbaiki ataupun tidak). Tidak hanya itu, bug report pula mampu digunakan oleh para programmer ataupun pengembang buat mengetahui information rinci menimpa sesuatu bug agar mempermudah penyelesaian bug tersebut.
Field Bug ID berisi pengidentifikasi dari suatu hal bug yang bisa dijadikan rujukan berasal dari suatu hal test tracking spreadsheet. Field Project Name memuat data menimpa nama proyek dimana bug selanjutnya ditemui. Field Tester berisi information menimpa namatester yang menciptakan bug tersebut. Field Date Opened berisi knowledge menimpa bertepatan terhadap bug selanjutnya dimasukkan ke di dalam bug tracking database.
Field Quality Risk Category: Perinci berisi knowledge menimpa tipe rinci berasal dari quality risk yang didetetapkan secara spesifik bersumber pada bug tersebut. Field Subsystem berisi knowledge menimpa subsystem dimana bug berikut ditemui. Field Configuration berisi knowledge menimpa konfigurasi yang digunakan disaat lakukan pengujian.
Field Severity serta Priority diisi bersama skala yang mirip bersama dengan yang sudah dipaparkan terhadap bagian failure fashion and effects analysis. Field RPN terhadap bug report didapat berasal dari perkalian pada evaluasi severity serta priority. Dengan demikian, range berasal dari RPN merupakan berkisar antara 1– 25, dimana nilai 1 mengindikasikan kecuali bug selanjutnya amat beresiko dan juga nilai 25 mengindikasikan kalau bug tersebut hanya berkenaan sepele yang sanggup diabaikan.
Field summary berisi penjelasan pendek menimpa bug. Field steps to reproduce sedia kan suatu hal deskripsi yang tepat dan juga mengetahui berkenaan gimana menciptakan ulang bug tersebut. Field isolation berisi information bikin menyakinkan pengembang/ programmer jika bug yang ditemui tersebut merupakan betul- betul bug. Perihal ini bisa bersama dengan menyatakan tanda- tanda timbulnya bug selanjutnya serta sanggup pula dengan menarangkan akibat dan pemicu berasal dari munculnya bug tersebut.
Field log memuat knowledge rinci menimpa siklus hidup dari suatu hal bug menjadi dari dini selagi bug tersebut di- entry ke dalam bug tracking database. Ada pula cerminan siklus hidup berasal dari bug report sanggup dicermati pada foto di bawah ini.
State lihat menggambarkan standing bug dimana bug udah di- input ke dalam bug tracking database serta menunggu buat di- simak oleh reviewer sementara sebelum akan bug selanjutnya diinformasikan kepada segala regu proyek pengembangan. State rejected menggambarkan standing dimana bug tersebut tidak diterima oleh reviewer karena wajib riset ataupun data lebih lanjut menimpa bug tersebut. State open melukiskan standing dimana bug berikut udah di- liat dan juga dianggap relevan dengan information rinci menimpa bug selanjutnya serta di informasikan keberadaannya kepada segala regu proyek pengembangan.
State assigned melukiskan status dimana bug tersebut ditugaskan kepada pengembang buat mencari information lanjut menimpa bug berikut dan menyelesaikannya. State test melukiskan standing dimana bug berikut telah berakhir diperbaiki oleh pengembang dan harus diuji buat membenarkan terkecuali bug tersebut betul- betul udah diperbaiki.
State reopened melukiskan status di mana bug dibuka lagi membuat diperbaiki ulang oleh pengembang.
State closed melukiskan standing dimana bug telah berakhir diperbaiki serta sudah dikonfirmasi kebenarannya melalui pengujian. State deferred bisa digunakan oleh bagian regu proyek buat menunda revisi bug berikut seandainya mereka memperhitungkan jika bug tersebut membawa prioritas yang rendah.
State cancelled sanggup digunakan oleh anggota regu proyek buat membatalkan revisi terhadap bug selanjutnya gara-gara dinilai sudah tidak relevan lagi. Field Pemilik terhadap bug report menampilkan nama orang yang bertanggung jawab pada bug tersebut. Dengan ada field ini diharapkan manajer proyek sanggup bersama lebih mudah mencari ataupun mencari information yang lebih rinci lagi menimpa bug tersebut.
Field Estimated Fixed memuat knowledge menimpa ditaksir bertepatan pada bug selanjutnya berakhir diperbaiki. Field Root Cause berisi information menimpa pangkal pemicu berasal 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 dapat bersifat spesifikasi yang salah, ataupun spesifikasinya benar namun implementasinya salah, ataupun sistem berperan bersama dengan benar namun hasil pengujian berikan 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 kesimpulan perancangan sudah benar tapi anggapan ketika pelaksanaannya salah.
c) Process
Dari segi process, pangkal pemicu berasal dari sesuatu bug dapat bersifat 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 dari suatu hal bug bisa bersifat style Info yang digunakan salah, struktur informasi yang tidak benar ataupun pemicu yang lain yang berhubungan bersama informasi.
e) Code
Dari segi code, pangkal pemicu berasal dari sesuatu bug sanggup bersifat salah pengetikan pada code.
f) Documentation
Dari sisi documentation, pangkal pemicu berasal dari sesuatu bug sanggup berupa salahnya dokumentasi terhadap sistem.
gram) Standards
Dari sisi standards, pangkal pemicu dari suatu hal bug dapat berbentuk tidak terpenuhnya standar yang mestinya 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 dengan model yang terdapat.
i) Duplicate
Root cause yang ini digunakan kalau ada 2 maupun lebih bug report yang membatasi bug yang sama.
j) NAP
Dikategorikan selaku NAP( Not a Problem) seumpama bug yang dilaporkan berikut cuma karena deskripsi yang tidak benar oleh tester.
k) Bad Unit
Root cause ini digunakan bila bug tersebut terjalin kata kegagalan hardware yang tidak diprediksi.
l) RCN
RCN( Root Cause Needed) digunakan andaikata standing dari bug tersebut telah closed namun tidak terdapat yang mengetahui 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 selanjutnya dikenalkan, umumnya pada fase dini saat sebelum akan fase di mana bug tersebut teridentifikasi.
Field Phase Detected mendefinisikan fase di mana bug berikut teridentifikasi.
Field Phase Removed mendeskripsikan fase di mana bug berikut sukses diperbaiki.
Field Close Date menarangkan bertepatan terhadap di mana standing berasal dari bug selanjutnya jadi closed.
Field Resolution mengartikan gimana bug tersebut diperbaiki.
Dari seluruh bug report yang telah dimasukkan ke di dalam bug tracking database sampai mampu dibuat.
0 Komentar