SAP Business One serta IReap POS ialah 2 aplikasi yang diterapkan di area yang berbeda, dimana SAP Business One ditujukan bikin back- end user dan juga IReap POS bikin front- end user. Keduanya silih berkaitan, data- information yang dimasukkan melalui IReap POS hendak dikirimkan ke SAP Business One membuat diolah lagi. Tidak cuma itu, terkandung pula data- data yang diinput dari SAP Business One hendak dikirimkan ke IReap POS buat kebutuhan operasional.
Tidak seluruh informasi yang dimasukkan lewat 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 pada IReap POS bersama SAP Business One mampu dicermati terhadap foto di bawah ini.
Informasi yang dikirim dari SAP Business One ke SAP Business One Mengenakan format XML, begitu pula bersama dengan Info yang dikirimkan dari IReap POS ke IReap POS. Kedua aplikasi selanjutnya bersama menciptakan file XML, tapi format struktur Info yang dihasilkan tentu saja berbeda. Buat membandingkan format/ template struktur Info pada kedua aplikasi berikut dibutuhkan proses transformasi. Secara rinci, ada 6 sistem utama didalam integrasi pada IReap POS bersama dengan SAP Business One. Keenam proses 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 terkait sistem import– export serta inbound– outbound, masih banyak sistem perinci yang ditunaikan bertepatan. Buat lebih detailnya sanggup dicermati 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 pemanfaatan test tracking spreadsheet, hendak membolehkan tester buat mencari tiap standing dari test case, mengetahui konfigurasi yang digunakan serta mengenali siapa yang telah laksanakan pengujian pada sesuatu test case.( Black, 2009: 200)
Kolom awal dari test tracking spreadsheet berikut berisi namatest suite/ test case berasal dari sesuatu pengujian. Kolom state melukiskan standing dari masing- masing test case. Bila kolom state ini kosong, hingga mengindikasikan terkecuali test case selanjutnya masih di dalam antrian membuat dicoba pengujian. Bila kolom ini berisi pass, sampai berarti kecuali pengujian bikin test case selanjutnya tidak menciptakan bug. Bila memuat fail, sampai bermakna terdapat bug yang ditemui dari pengujian test case tersebut baik satu ataupun lebih.
Kolom system config memuat penjelasan identifikasi bikin 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 buat melacak bug tersebut serta mereferensikannya pada bug report yang terbuat di dalam bug tracking database.
Kolom by berisi nama samaran dari tester yang udah laksanakan pengujian terhadap test case. Kolom comment berisi pendapat dari tester ataupun data bonus menimpa status berasal dari masing- masing test case. Kolom roll up berisi ringkasan berasal dari information menimpa status berasal dari masing- masing test case. Kolom ini dibagi menjadi 3 kolom, ialah:
a) Kolom T berisi nilai 1 jika ialah test case.
b) Kolom F berisi nilai 1 misalnya standing dari test case merupakan fail.
c) Kolom P memuat nilai 1 misalnya status berasal dari test case merupakan pass.
Bug Report
Mengacu pada komentar Black( 2009: 146), bug report merupakan dokumen teknis yang digunakan bikin mengartikan bermacam indikasi maupun kegagalan yang terjalin bersama dengan sesuatu bug tertentu secara khusus. Sesuatu dokumen bug report yang dirancang bersama baik sanggup membagikan knowledge yang tepat untuk regu manajemen proyek menimpa bug berikut agar dapat menyita ketetapan yang pas( misalnya, apakah bug berikut perlu lekas diperbaiki ataupun tidak). Tidak cuma itu, bug report pula sanggup digunakan oleh para programmer ataupun pengembang buat mengenali data rinci menimpa suatu hal bug agar mempermudah penyelesaian bug tersebut.
Field Bug ID berisi pengidentifikasi dari sesuatu bug yang mampu dijadikan rujukan berasal dari suatu hal test tracking spreadsheet. Field Project Name memuat knowledge menimpa nama proyek di mana bug tersebut ditemui. Field Tester memuat data menimpa namatester yang menciptakan bug tersebut. Field Date Opened memuat data menimpa bertepatan terhadap bug tersebut dimasukkan ke di dalam bug tracking database.
Field Quality Risk Category: Perinci berisi data menimpa model rinci dari quality risk yang didetetapkan secara tertentu bersumber pada bug tersebut. Field Subsystem berisi information menimpa subsystem dimana bug berikut ditemui. Field Configuration memuat data menimpa konfigurasi yang digunakan saat melakukan pengujian.
Field Severity serta Priority diisi dengan skala yang mirip bersama dengan yang sudah dipaparkan terhadap anggota failure fashion plus effects analysis. Field RPN terhadap bug report didapat berasal dari perkalian pada evaluasi severity dan juga priority. Dengan demikian, range dari RPN merupakan berkisar pada 1– 25, di mana nilai 1 mengindikasikan kecuali bug selanjutnya benar-benar berbahaya serta nilai 25 mengindikasikan terkecuali bug tersebut hanya berkenaan sepele yang mampu diabaikan.
Field summary berisi penjelasan pendek menimpa bug. Field steps to reproduce menyediakan sesuatu uraian yang tepat dan juga sadar berkenaan gimana menciptakan kembali bug tersebut. Field isolation memuat information bikin menyakinkan pengembang/ programmer terkecuali bug yang ditemui selanjutnya merupakan betul- betul bug. Perihal ini bisa dengan menyebutkan tanda- tanda munculnya bug berikut dan juga sanggup pula bersama dengan menarangkan akibat dan pemicu berasal dari munculnya bug tersebut.
Field log berisi knowledge rinci menimpa siklus hidup dari suatu hal bug menjadi dari dini pas bug tersebut di- entry ke dalam bug tracking database. Ada pula cerminan siklus hidup berasal dari bug report mampu dicermati terhadap foto di bawah ini.
State simak melukiskan status bug di mana bug udah di- input ke didalam bug tracking database dan juga menanti membuat di- review oleh reviewer pas sebelum akan bug berikut di informasikan kepada segala regu proyek pengembangan. State rejected menggambarkan standing di mana bug berikut ditolak oleh reviewer sebab mesti riset ataupun information lebih lanjut menimpa bug tersebut. State open menggambarkan status di mana bug berikut udah di- liat serta di kira relevan dengan data rinci menimpa bug tersebut dan juga diinformasikan keberadaannya kepada segala regu proyek pengembangan.
State assigned melukiskan status dimana bug selanjutnya ditugaskan kepada pengembang buat melacak knowledge lanjut menimpa bug selanjutnya dan menyelesaikannya. State test menggambarkan standing di mana bug berikut telah berakhir diperbaiki oleh pengembang dan wajib diuji bikin membetulkan jika bug selanjutnya betul- betul telah diperbaiki.
State reopened melukiskan standing di mana bug dibuka ulang membuat diperbaiki kembali oleh pengembang.
State closed menggambarkan status dimana bug udah berakhir diperbaiki serta sudah dilakukan konfirmasi kebenarannya lewat pengujian. State deferred sanggup digunakan oleh bagian regu proyek buat menunda revisi bug berikut jikalau mereka pertimbangkan jikalau bug berikut mempunyai prioritas yang rendah.
State cancelled sanggup digunakan oleh anggota regu proyek bikin membatalkan revisi pada bug berikut gara-gara 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 dapat bersama dengan lebih enteng melacak ataupun melacak information yang lebih rinci lagi menimpa bug tersebut.
Field Estimated Fixed memuat knowledge menimpa ditaksir bertepatan terhadap bug tersebut berakhir diperbaiki. Field Root Cause berisi information menimpa pangkal pemicu berasal dari terjadinya bug tersebut. Bagi Black root cause berasal dari sesuatu bug secara universal sanggup berbentuk:
a) Functional
Dari segi functional, pangkal pemicu dari sesuatu bug bisa berupa spesifikasi yang salah, ataupun spesifikasinya benar namun implementasinya salah, ataupun proses berperan bersama benar namun hasil pengujian berikan paham error yang salah.
b) System
Dari sisi system, pangkal pemicu berasal dari sesuatu bug sanggup berbentuk gagalnya komunikasi sistem internal, gagalnya hardware, gagalnya operating system, aplikasi architecture yang terbuat salah, ataupun anggapan perancangan udah benar namun asumsi dikala pelaksanaannya salah.
c) Process
Dari sisi process, pangkal pemicu berasal dari suatu hal bug mampu berwujud 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 berasal dari sesuatu bug dapat bersifat tipe Info yang digunakan salah, susunan informasi yang salah ataupun pemicu yang lain yang terkait dengan informasi.
e) Code
Dari segi code, pangkal pemicu dari sesuatu bug bisa berupa tidak benar pengetikan terhadap code.
f) Documentation
Dari segi documentation, pangkal pemicu dari suatu hal bug mampu berwujud salahnya dokumentasi terhadap sistem.
gram) Standards
Dari segi standards, pangkal pemicu berasal dari sesuatu bug bisa bersifat tidak terpenuhnya standar yang mestinya terhadap sistem tersebut.
h) Other
Root cause berasal dari bug dikategorikan ke di dalam other apabila pangkal pemicu berasal dari bug telah dikenal tetapi tidak sesuai bersama type yang terdapat.
i) Duplicate
Root cause yang ini digunakan apabila ada 2 maupun lebih bug report yang mendeskripsikan bug yang sama.
j) NAP
Dikategorikan selaku NAP( Not a Problem) andaikan bug yang dilaporkan berikut hanya gara-gara uraian 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 andaikan status berasal dari bug tersebut sudah closed tapi tidak terkandung yang mengetahui pangkal pemicu dari terbentuknya bug tersebut.
meter) Unknown
Root cause unknown digunakan sekiranya tidak terdapat orang yang mengetahui apa yang terkait atas bug tersebut.
Field Phase Injected mendefinisikan fase dimana bug berikut dikenalkan, umumnya pada fase dini sementara sebelum akan fase di mana bug tersebut teridentifikasi.
Field Phase Detected mendefinisikan fase dimana bug selanjutnya teridentifikasi.
Field Phase Removed mendefinisikan fase di mana bug berikut sukses diperbaiki.
Field Close Date menarangkan bertepatan pada di mana standing dari bug tersebut jadi closed.
Field Resolution mendeskripsikan gimana bug selanjutnya diperbaiki.
Dari semua bug report yang telah dimasukkan ke dalam bug tracking database hingga bisa dibuat.
0 Komentar