SAP Business One dan juga IReap POS ialah 2 aplikasi yang diterapkan di area yang berbeda, di mana SAP Business One bertujuan buat 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 buat diolah lagi. Tidak hanya itu, terdapat pula data- information yang diinput dari SAP Business One hendak dikirimkan ke IReap POS buat keperluan operasional.
Tidak semua informasi yang dimasukkan lewat IReap POS dikirimkan ke SAP Business One. Begitu pula kebalikannya, tidak semua informasi yang dimasukkan lewat SAP Business One hendak dikirimkan ke IReap POS. Secara garis besar, integrasi antara IReap POS bersama dengan SAP Business One bisa dilihat terhadap foto dibawah ini.
Informasi yang dikirim berasal dari SAP Business One ke SAP Business One kenakan format XML, begitu pula bersama informasi yang dikirimkan berasal dari IReap POS ke IReap POS. Kedua aplikasi selanjutnya bersama dengan menciptakan file XML, tapi format susunan Info yang dihasilkan sudah pasti berbeda. Buat membandingkan format/ template struktur Info antara kedua aplikasi berikut diperlukan proses transformasi. Secara rinci, ada 6 sistem utama di dalam integrasi antara IReap POS dengan SAP Business One. Keenam sistem selanjutnya 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 disaat terkait proses import– export dan juga inbound– outbound, tetap banyak proses perinci yang dijalankan bertepatan. Buat lebih detailnya dapat dicermati terhadap foto di bawah ini.
Test Tracking Spreadsheet
Buat mempermudah pengelolaan pada penerapan pengujian bisa digunakan suatu perlengkapan yang dinamakan selaku test tracking spreadsheet. Dengan pemakaian test tracking spreadsheet, hendak membolehkan tester membuat mencari tiap standing berasal dari test case, mengetahui konfigurasi yang digunakan dan juga mengetahui siapa yang telah laksanakan pengujian terhadap suatu hal test case.( Black, 2009: 200)
Kolom awal dari test tracking spreadsheet tersebut memuat namatest suite/ test case berasal dari sesuatu pengujian. Kolom state melukiskan status dari masing- masing test case. Bila kolom state ini kosong, hingga mengindikasikan terkecuali test case selanjutnya tetap dalam antrian buat dicoba pengujian. Bila kolom ini memuat pass, sampai artinya terkecuali pengujian membuat test case tersebut tidak menciptakan bug. Bila memuat fail, sampai berarti terdapat bug yang ditemui berasal dari pengujian test case berikut baik satu ataupun lebih.
Kolom system config berisi penjelasan identifikasi buat mengenali konfigurasi sistem yang digunakan oleh masing- masing test case. Kolom bug id berisi bukti diri berasal dari bug yang ditemui berasal dari hasil pengujian test case. Kolom ini yang nantinya hendak mempermudah test team membuat melacak bug berikut serta mereferensikannya pada bug report yang terbuat didalam bug tracking database.
Kolom by memuat nama samaran berasal dari tester yang sudah laksanakan pengujian pada test case. Kolom comment memuat pendapat dari tester ataupun knowledge 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 menjadi 3 kolom, ialah:
a) Kolom T berisi nilai 1 kalau ialah test case.
b) Kolom F memuat nilai 1 sekiranya standing dari test case merupakan fail.
c) Kolom P memuat nilai 1 andaikan standing berasal dari test case merupakan pass.
Bug Report
Mengacu terhadap komentar Black( 2009: 146), bug report merupakan dokumen teknis yang digunakan bikin mendeskripsikan bermacam indikasi maupun kegagalan yang terjalin bersama suatu hal bug tertentu secara khusus. Sesuatu dokumen bug report yang dirancang bersama baik sanggup membagikan data yang pas untuk regu manajemen proyek menimpa bug berikut agar mampu mengambil keputusan yang pas( misalnya, apakah bug selanjutnya wajib lekas diperbaiki ataupun tidak). Tidak hanya itu, bug report pula sanggup digunakan oleh para programmer ataupun pengembang bikin mengetahui information rinci menimpa sesuatu bug supaya mempermudah penyelesaian bug tersebut.
Field Bug ID berisi pengidentifikasi berasal dari suatu hal bug yang sanggup dijadikan rujukan berasal dari sesuatu test tracking spreadsheet. Field Project Name memuat information menimpa nama proyek dimana bug tersebut ditemui. Field Tester memuat information menimpa namatester yang menciptakan bug tersebut. Field Date Opened berisi information menimpa bertepatan pada bug berikut dimasukkan ke didalam bug tracking database.
Field Quality Risk Category: Perinci memuat data menimpa type rinci berasal dari quality risk yang didetetapkan secara spesifik bersumber terhadap bug tersebut. Field Subsystem berisi data menimpa subsystem di mana bug tersebut ditemui. Field Configuration memuat data menimpa konfigurasi yang digunakan kala melakukan pengujian.
Field Severity serta Priority diisi bersama skala yang mirip dengan yang telah dipaparkan pada bagian failure fashion and effects analysis. Field RPN terhadap bug report didapat dari perkalian pada evaluasi severity dan juga priority. Dengan demikian, range dari RPN merupakan berkisar pada 1– 25, di mana nilai 1 mengindikasikan jikalau bug berikut amat berbahaya dan juga nilai 25 mengindikasikan kecuali bug tersebut cuma perihal sepele yang bisa diabaikan.
Field summary berisi penjelasan pendek menimpa bug. Field steps to reproduce sedia kan sesuatu uraian yang pas dan juga sadar perihal gimana menciptakan ulang bug tersebut. Field isolation memuat data bikin menyakinkan pengembang/ programmer terkecuali bug yang ditemui berikut merupakan betul- betul bug. Perihal ini mampu dengan menyebutkan tanda- sinyal munculnya bug tersebut serta dapat pula bersama dengan menarangkan akibat dan pemicu dari munculnya bug tersebut.
Field log berisi data rinci menimpa siklus hidup berasal dari sesuatu bug terasa berasal dari dini selagi bug tersebut di- entry ke didalam bug tracking database. Ada pula cerminan siklus hidup dari bug report sanggup dicermati pada foto dibawah ini.
State simak menggambarkan status bug dimana bug udah di- input ke didalam bug tracking database dan juga menunggu membuat di- review oleh reviewer sementara sebelum akan bug tersebut diberitakan kepada segala regu proyek pengembangan. State rejected melukiskan status di mana bug berikut tidak diterima oleh reviewer gara-gara kudu riset ataupun knowledge lebih lanjut menimpa bug tersebut. State open melukiskan status dimana bug berikut sudah di- review serta di kira relevan bersama data rinci menimpa bug berikut dan juga diinformasikan keberadaannya kepada segala regu proyek pengembangan.
State assigned menggambarkan status dimana bug tersebut ditugaskan kepada pengembang buat mencari data lanjut menimpa bug berikut dan menyelesaikannya. State test melukiskan standing di mana bug berikut telah berakhir diperbaiki oleh pengembang dan harus diuji bikin membenarkan terkecuali bug berikut betul- betul telah diperbaiki.
State reopened melukiskan status dimana bug diakses ulang bikin diperbaiki lagi oleh pengembang.
State closed melukiskan standing di mana bug sudah berakhir diperbaiki dan juga telah di konfirmasi kebenarannya melalui pengujian. State deferred mampu digunakan oleh anggota regu proyek bikin menunda revisi bug berikut misalnya mereka pertimbangkan jika bug selanjutnya membawa prioritas yang rendah.
State cancelled mampu digunakan oleh anggota regu proyek buat membatalkan revisi pada bug berikut sebab dinilai telah tidak relevan lagi. Field Pemilik terhadap bug report menampilkan nama orang yang bertanggung jawab pada bug tersebut. Dengan adanya field ini diharapkan manajer proyek sanggup bersama dengan lebih ringan mencari ataupun mencari data yang lebih rinci lagi menimpa bug tersebut.
Field Estimated Fixed memuat information menimpa ditaksir bertepatan pada bug berikut berakhir diperbaiki. Field Root Cause memuat information menimpa pangkal pemicu dari terjadinya bug tersebut. Bagi Black root cause berasal dari suatu hal bug secara universal bisa berbentuk:
a) Functional
Dari sisi functional, pangkal pemicu berasal dari sesuatu bug dapat berupa spesifikasi yang salah, ataupun spesifikasinya benar tetapi implementasinya salah, ataupun proses berperan dengan benar tetapi hasil pengujian berikan paham error yang salah.
b) System
Dari sisi system, pangkal pemicu dari suatu hal bug dapat berupa gagalnya komunikasi sistem internal, gagalnya hardware, gagalnya operating system, aplikasi architecture yang terbuat salah, ataupun analisis perancangan sudah benar tapi pemikiran disaat pelaksanaannya salah.
c) Process
Dari segi process, pangkal pemicu berasal dari suatu hal bug dapat 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 model Info yang digunakan salah, struktur Info yang tidak benar ataupun pemicu yang lain yang berhubungan bersama dengan informasi.
e) Code
Dari sisi code, pangkal pemicu berasal dari sesuatu bug bisa berupa tidak benar pengetikan terhadap code.
f) Documentation
Dari segi documentation, pangkal pemicu dari suatu hal bug sanggup berwujud salahnya dokumentasi pada sistem.
gram) Standards
Dari sisi standards, pangkal pemicu berasal dari suatu hal bug sanggup berupa tidak terpenuhnya standar yang sewajarnya terhadap sistem tersebut.
h) Other
Root cause berasal dari bug dikategorikan ke didalam other kalau pangkal pemicu berasal dari bug telah dikenal namun tidak sesuai bersama dengan tipe yang terdapat.
i) Duplicate
Root cause yang ini digunakan jika tersedia 2 maupun lebih bug report yang mendefinisikan bug yang sama.
j) NAP
Dikategorikan selaku NAP( Not a Problem) seumpama bug yang dilaporkan berikut hanya sebab gambaran yang keliru oleh tester.
k) Bad Unit
Root cause ini digunakan jika bug selanjutnya terkait kata kegagalan hardware yang tidak diprediksi.
l) RCN
RCN( Root Cause Needed) digunakan seandainya status berasal dari bug berikut telah closed namun tidak terkandung yang mengenali pangkal pemicu berasal dari terbentuknya bug tersebut.
meter) Unknown
Root cause unknown digunakan andaikan tidak terdapat orang yang mengenali apa yang terkait atas bug tersebut.
Field Phase Injected mendefinisikan fase di mana bug tersebut dikenalkan, biasanya terhadap fase dini sementara sebelum fase dimana bug berikut teridentifikasi.
Field Phase Detected mendeskripsikan fase dimana bug tersebut teridentifikasi.
Field Phase Removed mendefinisikan fase dimana bug berikut berhasil diperbaiki.
Field Close Date menarangkan bertepatan terhadap di mana status dari bug selanjutnya menjadi closed.
Field Resolution membatasi gimana bug berikut diperbaiki.
Dari semua bug report yang telah dimasukkan ke di dalam bug tracking database hingga dapat dibuat.
0 Komentar