SAP Business One serta IReap POS ialah 2 aplikasi yang diterapkan di tempat yang berbeda, dimana SAP Business One bertujuan buat back- end user dan juga IReap POS buat front- end user. Keduanya silih berkaitan, data- information yang dimasukkan lewat IReap POS hendak dikirimkan ke SAP Business One buat diolah lagi. Tidak cuma itu, terkandung pula data- data yang diinput dari SAP Business One hendak dikirimkan ke IReap POS bikin kebutuhan operasional.
Tidak semua Info yang dimasukkan melalui IReap POS dikirimkan ke SAP Business One. Begitu pula kebalikannya, tidak seluruh Info yang dimasukkan lewat SAP Business One hendak dikirimkan ke IReap POS. Secara garis besar, integrasi antara IReap POS bersama SAP Business One sanggup dilihat pada foto dibawah ini.
Informasi yang dikirim berasal dari SAP Business One ke SAP Business One kenakan format XML, begitu pula bersama Info yang dikirimkan berasal dari IReap POS ke IReap POS. Kedua aplikasi berikut dengan menciptakan file XML, tetapi format susunan informasi yang dihasilkan tentu saja berbeda. Buat memperbandingkan format/ template susunan Info antara ke dua aplikasi selanjutnya diperlukan proses transformasi. Secara rinci, tersedia 6 sistem utama di dalam integrasi pada IReap POS bersama dengan SAP Business One. Keenam sistem tersebut merupakan selaku berikut:
1. Export 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 dikala terkait proses import– export dan juga inbound– outbound, masih banyak proses perinci yang dilakukan bertepatan. Buat lebih detailnya bisa dilihat terhadap foto di bawah 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 membuat mencari tiap status berasal dari test case, mengenali konfigurasi yang digunakan dan juga mengenali siapa yang udah laksanakan pengujian terhadap suatu hal test case.( Black, 2009: 200)
Kolom awal dari test tracking spreadsheet tersebut berisi namatest suite/ test case dari sesuatu pengujian. Kolom state menggambarkan status berasal dari masing- masing test case. Bila kolom state ini kosong, sampai mengindikasikan jikalau test case tersebut tetap di dalam antrian buat dicoba pengujian. Bila kolom ini berisi pass, hingga bermakna jikalau pengujian bikin test case berikut tidak menciptakan bug. Bila berisi fail, sampai artinya terdapat bug yang ditemui berasal dari pengujian test case tersebut baik satu ataupun lebih.
Kolom system config berisi penjelasan identifikasi buat mengetahui konfigurasi sistem 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 mencari bug selanjutnya serta mereferensikannya terhadap bug report yang terbuat didalam bug tracking database.
Kolom by memuat nama samaran dari tester yang udah lakukan pengujian terhadap test case. Kolom comment berisi pendapat berasal dari tester ataupun knowledge bonus menimpa status dari masing- masing test case. Kolom roll up memuat ringkasan dari information menimpa status dari masing- masing test case. Kolom ini dibagi jadi 3 kolom, ialah:
a) Kolom T memuat nilai 1 andaikata ialah test case.
b) Kolom F memuat nilai 1 bila status berasal dari test case merupakan fail.
c) Kolom P berisi nilai 1 misalnya status berasal dari test case merupakan pass.
Bug Report
Mengacu pada komentar Black( 2009: 146), bug report merupakan dokumen tekhnis yang digunakan bikin mendefinisikan berbagai indikasi maupun kegagalan yang terjalin bersama sesuatu bug spesifik secara khusus. Sesuatu dokumen bug report yang dirancang bersama dengan baik mampu membagikan knowledge yang pas untuk regu manajemen proyek menimpa bug berikut supaya dapat mengambil keputusan yang pas( misalnya, apakah bug tersebut wajib lekas diperbaiki ataupun tidak). Tidak cuma itu, bug report pula mampu digunakan oleh para programmer ataupun pengembang membuat mengetahui data rinci menimpa suatu hal bug sehingga mempermudah penyelesaian bug tersebut.
Field Bug ID memuat pengidentifikasi dari sesuatu bug yang dapat dijadikan rujukan dari suatu hal test tracking spreadsheet. Field Project Name memuat knowledge menimpa nama proyek dimana bug berikut ditemui. Field Tester memuat knowledge menimpa namatester yang menciptakan bug tersebut. Field Date Opened memuat data menimpa bertepatan pada bug berikut dimasukkan ke didalam bug tracking database.
Field Quality Risk Category: Perinci memuat knowledge menimpa jenis rinci dari quality risk yang didetetapkan secara khusus bersumber terhadap bug tersebut. Field Subsystem berisi knowledge menimpa subsystem di mana bug selanjutnya ditemui. Field Configuration memuat knowledge menimpa konfigurasi yang digunakan ketika laksanakan pengujian.
Field Severity serta Priority diisi bersama dengan skala yang serupa dengan yang telah dipaparkan pada bagian failure fashion plus effects analysis. Field RPN pada bug report didapat dari perkalian pada evaluasi severity serta priority. Dengan demikian, range berasal dari RPN merupakan berkisar pada 1– 25, di mana nilai 1 mengindikasikan jika bug selanjutnya amat beresiko dan juga nilai 25 mengindikasikan kecuali bug selanjutnya cuma perihal sepele yang dapat diabaikan.
Field summary memuat penjelasan pendek menimpa bug. Field steps to reproduce sedia kan suatu hal gambaran yang pas dan juga sadar perihal gimana menciptakan lagi bug tersebut. Field isolation berisi knowledge bikin menyakinkan pengembang/ programmer terkecuali bug yang ditemui tersebut merupakan betul- betul bug. Perihal ini mampu dengan menyebutkan tanda- sinyal timbulnya bug berikut serta sanggup pula dengan menarangkan akibat dan pemicu dari timbulnya bug tersebut.
Field log memuat information rinci menimpa siklus hidup berasal dari suatu hal bug jadi berasal dari dini pas bug berikut di- entry ke di dalam bug tracking database. Ada pula cerminan siklus hidup dari bug report bisa dilihat pada foto di bawah ini.
State liat melukiskan status bug di mana bug udah di- input ke di dalam bug tracking database dan juga tunggu buat di- simak oleh reviewer waktu sebelum saat bug selanjutnya diinformasikan kepada segala regu proyek pengembangan. State rejected menggambarkan standing dimana bug selanjutnya tidak diterima oleh reviewer dikarenakan perlu riset ataupun data lebih lanjut menimpa bug tersebut. State open melukiskan standing di mana bug tersebut sudah di- simak dan juga dikira relevan bersama information rinci menimpa bug selanjutnya serta diberitakan keberadaannya kepada segala regu proyek pengembangan.
State assigned menggambarkan status dimana bug selanjutnya ditugaskan kepada pengembang membuat mencari information lanjut menimpa bug berikut dan menyelesaikannya. State test melukiskan status dimana bug selanjutnya udah berakhir diperbaiki oleh pengembang dan kudu diuji buat membenarkan terkecuali bug berikut betul- betul udah diperbaiki.
State reopened menggambarkan standing di mana bug diakses kembali buat diperbaiki kembali oleh pengembang.
State closed melukiskan standing dimana bug telah berakhir diperbaiki dan juga udah dikonfirmasi kebenarannya melalui pengujian. State deferred dapat digunakan oleh bagian regu proyek bikin menunda revisi bug selanjutnya seandainya mereka memperhitungkan jikalau bug selanjutnya membawa prioritas yang rendah.
State cancelled dapat digunakan oleh anggota regu proyek membuat membatalkan revisi pada bug tersebut gara-gara dinilai sudah tidak relevan lagi. Field Pemilik pada bug report menampilkan nama orang yang bertanggung jawab pada bug tersebut. Dengan ada field ini dikehendaki manajer proyek mampu bersama lebih gampang melacak ataupun mencari data yang lebih rinci kembali menimpa bug tersebut.
Field Estimated Fixed memuat information menimpa ditaksir bertepatan terhadap bug berikut berakhir diperbaiki. Field Root Cause memuat data menimpa pangkal pemicu dari terjadinya bug tersebut. Bagi Black root cause berasal dari sesuatu bug secara universal mampu berbentuk:
a) Functional
Dari sisi functional, pangkal pemicu dari suatu hal bug dapat bersifat spesifikasi yang salah, ataupun spesifikasinya benar tapi implementasinya salah, ataupun sistem berperan bersama dengan benar tapi hasil pengujian memberi tahu error yang salah.
b) System
Dari sisi system, pangkal pemicu dari sesuatu bug dapat berupa gagalnya komunikasi sistem internal, gagalnya hardware, gagalnya operating system, aplikasi architecture yang terbuat salah, ataupun analisis perancangan sudah benar tapi anggapan kala pelaksanaannya salah.
c) Process
Dari sisi process, pangkal pemicu berasal dari suatu hal bug dapat berwujud 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 dari suatu hal bug sanggup berbentuk jenis informasi yang digunakan salah, struktur informasi yang tidak benar ataupun pemicu yang lain yang terjalin dengan informasi.
e) Code
Dari sisi code, pangkal pemicu dari suatu hal bug bisa berbentuk keliru pengetikan pada code.
f) Documentation
Dari segi documentation, pangkal pemicu dari sesuatu bug dapat berupa salahnya dokumentasi pada sistem.
gram) Standards
Dari sisi standards, pangkal pemicu dari suatu hal bug dapat bersifat tidak terpenuhnya standar yang mestinya pada sistem tersebut.
h) Other
Root cause dari bug dikategorikan ke didalam other apabila pangkal pemicu berasal dari bug telah dikenal namun tidak sesuai dengan jenis yang terdapat.
i) Duplicate
Root cause yang ini digunakan misalnya ada 2 maupun lebih bug report yang mengartikan bug yang sama.
j) NAP
Dikategorikan selaku NAP( Not a Problem) seumpama bug yang dilaporkan tersebut hanya karena deskripsi yang keliru oleh tester.
k) Bad Unit
Root cause ini digunakan andaikan bug tersebut terjalin kata kegagalan hardware yang tidak diprediksi.
l) RCN
RCN( Root Cause Needed) digunakan bila standing dari bug berikut udah closed tetapi tidak terkandung yang mengetahui pangkal pemicu berasal dari terbentuknya bug tersebut.
meter) Unknown
Root cause unknown digunakan kalau tidak terkandung orang yang mengetahui apa yang berhubungan atas bug tersebut.
Field Phase Injected mendefinisikan fase di mana bug selanjutnya dikenalkan, biasanya pada fase dini waktu sebelum saat fase di mana bug berikut teridentifikasi.
Field Phase Detected mengartikan fase dimana bug tersebut teridentifikasi.
Field Phase Removed mengartikan fase dimana bug tersebut sukses diperbaiki.
Field Close Date menarangkan bertepatan terhadap di mana standing berasal dari bug selanjutnya jadi closed.
Field Resolution mendefinisikan gimana bug selanjutnya diperbaiki.
Dari semua bug report yang udah dimasukkan ke didalam bug tracking database sampai dapat dibuat.
0 Komentar