SAP Business One dan juga IReap POS ialah 2 aplikasi yang diterapkan di tempat yang berbeda, di mana SAP Business One dimaksudkan 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 bikin diolah lagi. Tidak hanya itu, terdapat pula data- information yang diinput dari SAP Business One hendak dikirimkan ke IReap POS membuat kebutuhan operasional.
Tidak seluruh Info yang dimasukkan melalui 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 antara 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 Info yang dikirimkan dari IReap POS ke IReap POS. Kedua aplikasi berikut bersama dengan menciptakan file XML, tapi format susunan informasi yang dihasilkan tentunya berbeda. Buat membandingkan format/ template struktur informasi antara kedua aplikasi selanjutnya diperlukan sistem transformasi. Secara rinci, ada 6 proses utama di 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 berasal dari SAP Business One
5. Transformasi dari dokumen SAP Business One ke dokumen IReap POS
6. Import ke POS Server
Pada ketika berhubungan proses import– export serta inbound– outbound, tetap banyak proses perinci yang dikerjakan bertepatan. Buat lebih detailnya sanggup diamati terhadap foto di bawah ini.
Test Tracking Spreadsheet
Buat mempermudah pengelolaan terhadap penerapan pengujian dapat digunakan suatu perlengkapan yang dinamakan selaku test tracking spreadsheet. Dengan penggunaan test tracking spreadsheet, hendak membolehkan tester membuat melacak tiap standing berasal dari test case, mengenali konfigurasi yang digunakan serta mengenali siapa yang udah melaksanakan pengujian terhadap suatu hal test case.( Black, 2009: 200)
Kolom awal dari test tracking spreadsheet berikut memuat namatest suite/ test case dari suatu hal pengujian. Kolom state menggambarkan standing berasal dari masing- masing test case. Bila kolom state ini kosong, sampai mengindikasikan terkecuali test case tersebut tetap dalam antrian bikin dicoba pengujian. Bila kolom ini berisi pass, hingga artinya kalau pengujian membuat test case berikut tidak menciptakan bug. Bila berisi fail, hingga artinya terkandung bug yang ditemui dari pengujian test case tersebut baik satu ataupun lebih.
Kolom system config memuat penjelasan identifikasi bikin 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 membuat melacak bug berikut serta mereferensikannya pada bug report yang terbuat di dalam bug tracking database.
Kolom by berisi nama samaran berasal dari tester yang sudah laksanakan pengujian terhadap test case. Kolom comment memuat pendapat dari tester ataupun data bonus menimpa status dari masing- masing test case. Kolom roll up berisi ringkasan dari knowledge menimpa status dari masing- masing test case. Kolom ini dibagi menjadi 3 kolom, ialah:
a) Kolom T memuat nilai 1 kalau ialah test case.
b) Kolom F memuat nilai 1 misalnya standing berasal dari test case merupakan fail.
c) Kolom P memuat nilai 1 andaikata status berasal dari test case merupakan pass.
Bug Report
Mengacu terhadap komentar Black( 2009: 146), bug report merupakan dokumen tehnis yang digunakan membuat mendeskripsikan bermacam indikasi maupun kegagalan yang terjalin bersama dengan suatu hal bug tertentu secara khusus. Sesuatu dokumen bug report yang dirancang dengan baik mampu membagikan information yang tepat untuk regu manajemen proyek menimpa bug selanjutnya sehingga sanggup mengambil ketentuan yang pas( misalnya, apakah bug selanjutnya wajib lekas diperbaiki ataupun tidak). Tidak cuma itu, bug report pula bisa digunakan oleh para programmer ataupun pengembang membuat mengenali data rinci menimpa suatu hal bug sehingga mempermudah penyelesaian bug tersebut.
Field Bug ID memuat pengidentifikasi berasal dari suatu hal bug yang mampu dijadikan rujukan dari sesuatu test tracking spreadsheet. Field Project Name berisi information menimpa nama proyek di mana bug selanjutnya ditemui. Field Tester berisi data menimpa namatester yang menciptakan bug tersebut. Field Date Opened berisi data menimpa bertepatan pada bug tersebut dimasukkan ke didalam bug tracking database.
Field Quality Risk Category: Perinci berisi data menimpa model rinci dari quality risk yang didetetapkan secara khusus bersumber terhadap bug tersebut. Field Subsystem berisi knowledge menimpa subsystem dimana bug selanjutnya ditemui. Field Configuration memuat data menimpa konfigurasi yang digunakan disaat melaksanakan pengujian.
Field Severity serta Priority diisi bersama dengan skala yang serupa bersama dengan yang sudah dipaparkan pada bagian failure fashion and effects analysis. Field RPN pada bug report didapat berasal dari perkalian antara evaluasi severity serta priority. Dengan demikian, range dari RPN merupakan berkisar antara 1– 25, dimana nilai 1 mengindikasikan kalau bug berikut amat berbahaya serta nilai 25 mengindikasikan kecuali bug tersebut hanya perihal sepele yang dapat diabaikan.
Field summary memuat penjelasan pendek menimpa bug. Field steps to reproduce menyediakan suatu hal uraian yang tepat dan juga jelas mengenai gimana menciptakan lagi bug tersebut. Field isolation berisi information bikin menyakinkan pengembang/ programmer kalau bug yang ditemui selanjutnya merupakan betul- betul bug. Perihal ini bisa bersama dengan menyebutkan tanda- sinyal munculnya bug selanjutnya serta mampu pula bersama dengan menarangkan akibat dan pemicu berasal dari munculnya bug tersebut.
Field log berisi data rinci menimpa siklus hidup dari sesuatu bug mulai berasal dari dini saat bug selanjutnya di- entry ke didalam bug tracking database. Ada pula cerminan siklus hidup berasal dari bug report dapat dilihat terhadap foto dibawah ini.
State lihat menggambarkan status bug dimana bug telah di- input ke didalam bug tracking database dan juga menunggu bikin di- liat oleh reviewer sementara sebelum bug berikut diberitakan kepada segala regu proyek pengembangan. State rejected menggambarkan standing dimana bug berikut ditolak oleh reviewer karena perlu riset ataupun data lebih lanjut menimpa bug tersebut. State open menggambarkan status dimana bug selanjutnya udah di- lihat serta dianggap relevan dengan knowledge rinci menimpa bug selanjutnya serta di informasikan keberadaannya kepada segala regu proyek pengembangan.
State assigned melukiskan status dimana bug selanjutnya ditugaskan kepada pengembang bikin mencari data lanjut menimpa bug tersebut dan menyelesaikannya. State test menggambarkan standing dimana bug tersebut udah berakhir diperbaiki oleh pengembang dan mesti diuji bikin membetulkan terkecuali bug tersebut betul- betul telah diperbaiki.
State reopened menggambarkan standing dimana bug diakses kembali buat diperbaiki kembali oleh pengembang.
State closed menggambarkan status di mana bug telah berakhir diperbaiki dan juga sudah dikonfirmasi kebenarannya melalui pengujian. State deferred sanggup digunakan oleh bagian regu proyek buat menunda revisi bug selanjutnya andaikan mereka pertimbangkan kalau bug tersebut membawa prioritas yang rendah.
State cancelled dapat digunakan oleh anggota regu proyek bikin membatalkan revisi terhadap bug berikut dikarenakan dinilai telah tidak relevan lagi. Field Pemilik pada bug report menampilkan nama orang yang bertanggung jawab pada bug tersebut. Dengan adanya field ini diinginkan manajer proyek mampu bersama dengan lebih enteng melacak ataupun melacak knowledge yang lebih rinci kembali menimpa bug tersebut.
Field Estimated Fixed berisi knowledge menimpa ditaksir bertepatan pada bug tersebut berakhir diperbaiki. Field Root Cause berisi knowledge menimpa pangkal pemicu dari terjadinya bug tersebut. Bagi Black root cause berasal dari sesuatu bug secara universal bisa berbentuk:
a) Functional
Dari segi functional, pangkal pemicu berasal dari suatu hal bug sanggup berwujud spesifikasi yang salah, ataupun spesifikasinya benar namun implementasinya salah, ataupun proses berperan bersama benar tetapi hasil pengujian memberi paham error yang salah.
b) System
Dari sisi system, pangkal pemicu dari suatu hal bug dapat berbentuk gagalnya komunikasi sistem internal, gagalnya hardware, gagalnya operating system, aplikasi architecture yang terbuat salah, ataupun pemikiran perancangan sudah benar tetapi asumsi kala pelaksanaannya salah.
c) Process
Dari sisi process, pangkal pemicu dari suatu hal bug bisa berupa salahnya operasional aritmatika yang diterapkan, proses inisialisasi yang salah, control ataupun sequence yang salah, maupun error didalam pemrosesan.
d) Data
Dari segi informasi, pangkal pemicu berasal dari sesuatu bug mampu berbentuk style Info yang digunakan salah, struktur informasi yang tidak benar ataupun pemicu yang lain yang terjalin bersama dengan informasi.
e) Code
Dari segi code, pangkal pemicu berasal dari suatu hal bug bisa berbentuk salah pengetikan pada code.
f) Documentation
Dari sisi documentation, pangkal pemicu dari sesuatu bug dapat berwujud salahnya dokumentasi pada sistem.
gram) Standards
Dari segi standards, pangkal pemicu berasal dari suatu hal bug mampu bersifat tidak terpenuhnya standar yang selayaknya pada sistem tersebut.
h) Other
Root cause berasal dari bug dikategorikan ke didalam other misalnya pangkal pemicu dari bug sudah dikenal tapi tidak sesuai bersama tipe yang terdapat.
i) Duplicate
Root cause yang ini digunakan sekiranya tersedia 2 maupun lebih bug report yang mendeskripsikan bug yang sama.
j) NAP
Dikategorikan selaku NAP( Not a Problem) misalnya bug yang dilaporkan berikut cuma dikarenakan gambaran yang salah oleh tester.
k) Bad Unit
Root cause ini digunakan jikalau bug selanjutnya terkait kata kegagalan hardware yang tidak diprediksi.
l) RCN
RCN( Root Cause Needed) digunakan seandainya status berasal dari bug berikut udah closed tetapi tidak terkandung yang mengetahui pangkal pemicu dari terbentuknya bug tersebut.
meter) Unknown
Root cause unknown digunakan andaikan tidak terdapat orang yang mengetahui apa yang berhubungan atas bug tersebut.
Field Phase Injected mendefinisikan fase di mana bug selanjutnya dikenalkan, kebanyakan pada fase dini waktu sebelum akan fase di mana bug tersebut teridentifikasi.
Field Phase Detected membatasi fase di mana bug tersebut teridentifikasi.
Field Phase Removed mendefinisikan fase di mana bug selanjutnya sukses diperbaiki.
Field Close Date menarangkan bertepatan pada di mana status dari bug berikut menjadi closed.
Field Resolution mendefinisikan gimana bug berikut diperbaiki.
Dari semua bug report yang sudah dimasukkan ke di dalam bug tracking database hingga bisa dibuat.
0 Komentar