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