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