SAP Business One dan juga IReap POS ialah 2 aplikasi yang diterapkan di daerah yang berbeda, dimana SAP Business One dimaksudkan bikin back- end user serta 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 cuma itu, terdapat pula data- data yang diinput dari SAP Business One hendak dikirimkan ke IReap POS buat keperluan operasional.
Tidak seluruh Info yang dimasukkan melalui IReap POS dikirimkan ke SAP Business One. Begitu pula kebalikannya, tidak seluruh informasi yang dimasukkan melalui SAP Business One hendak dikirimkan ke IReap POS. Secara garis besar, integrasi antara IReap POS bersama dengan SAP Business One mampu dicermati terhadap foto dibawah ini.
Informasi yang dikirim berasal dari SAP Business One ke SAP Business One memakai format XML, begitu pula bersama informasi yang dikirimkan dari IReap POS ke IReap POS. Kedua aplikasi tersebut dengan menciptakan file XML, namun format struktur informasi yang dihasilkan sudah pasti berbeda. Buat memperbandingkan format/ template susunan Info pada ke dua aplikasi tersebut diperlukan sistem transformasi. Secara rinci, ada 6 sistem utama didalam integrasi antara IReap POS bersama dengan SAP Business One. Keenam sistem berikut merupakan selaku berikut:
1. Export dari POS Server
2. Tranformasi dari dokumen IReap POS ke dokumen SAP Business One
3. Inbound ke SAP Business One
4. Outbound dari SAP Business One
5. Transformasi dari dokumen SAP Business One ke dokumen IReap POS
6. Import ke POS Server
Pada kala terjalin sistem import– export dan juga inbound– outbound, tetap banyak proses perinci yang dilaksanakan bertepatan. Buat lebih detailnya dapat diamati pada foto dibawah ini.
Test Tracking Spreadsheet
Buat mempermudah pengelolaan pada penerapan pengujian sanggup digunakan suatu perlengkapan yang dinamakan selaku test tracking spreadsheet. Dengan penggunaan test tracking spreadsheet, hendak membolehkan tester bikin mencari tiap status berasal dari test case, mengenali konfigurasi yang digunakan serta mengetahui siapa yang udah lakukan pengujian pada suatu hal test case.( Black, 2009: 200)
Kolom awal berasal dari test tracking spreadsheet selanjutnya 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 masih di dalam antrian buat dicoba pengujian. Bila kolom ini memuat pass, hingga artinya kalau pengujian membuat test case tersebut tidak menciptakan bug. Bila memuat fail, hingga berarti terdapat bug yang ditemui berasal dari pengujian test case tersebut baik satu ataupun lebih.
Kolom system config berisi penjelasan identifikasi membuat mengenali 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 bikin melacak bug tersebut dan juga mereferensikannya terhadap bug report yang terbuat dalam bug tracking database.
Kolom by berisi nama samaran berasal dari tester yang sudah lakukan pengujian pada test case. Kolom comment berisi pendapat dari tester ataupun information 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 jadi 3 kolom, ialah:
a) Kolom T berisi nilai 1 misalnya ialah test case.
b) Kolom F berisi nilai 1 kalau status berasal dari test case merupakan fail.
c) Kolom P memuat nilai 1 seandainya standing 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 suatu hal bug tertentu secara khusus. Sesuatu dokumen bug report yang dirancang dengan baik sanggup membagikan information yang pas untuk regu manajemen proyek menimpa bug tersebut supaya dapat menyita keputusan yang pas( misalnya, apakah bug selanjutnya harus lekas diperbaiki ataupun tidak). Tidak cuma itu, bug report pula bisa 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 suatu hal bug yang dapat dijadikan rujukan dari suatu hal test tracking spreadsheet. Field Project Name memuat information menimpa nama proyek di mana bug tersebut ditemui. Field Tester berisi data menimpa namatester yang menciptakan bug tersebut. Field Date Opened berisi knowledge menimpa bertepatan pada bug berikut dimasukkan ke didalam bug tracking database.
Field Quality Risk Category: Perinci berisi knowledge menimpa tipe rinci berasal dari quality risk yang didetetapkan secara spesifik bersumber terhadap bug tersebut. Field Subsystem memuat information menimpa subsystem di mana bug selanjutnya ditemui. Field Configuration berisi information menimpa konfigurasi yang digunakan dikala lakukan pengujian.
Field Severity dan juga Priority diisi dengan skala yang sama dengan yang sudah dipaparkan pada anggota failure fashion and effects analysis. Field RPN pada bug report didapat berasal dari perkalian pada evaluasi severity dan juga priority. Dengan demikian, range dari RPN merupakan berkisar pada 1– 25, dimana nilai 1 mengindikasikan kecuali bug selanjutnya benar-benar berbahaya dan juga nilai 25 mengindikasikan jika bug berikut cuma berkenaan sepele yang mampu diabaikan.
Field summary berisi penjelasan pendek menimpa bug. Field steps to reproduce menyediakan sesuatu gambaran yang tepat serta tahu mengenai gimana menciptakan kembali bug tersebut. Field isolation memuat information membuat menyakinkan pengembang/ programmer jikalau bug yang ditemui selanjutnya merupakan betul- betul bug. Perihal ini bisa bersama menyebutkan tanda- isyarat timbulnya bug selanjutnya serta sanggup pula bersama dengan menarangkan akibat dan pemicu berasal dari munculnya bug tersebut.
Field log berisi knowledge rinci menimpa siklus hidup berasal dari suatu hal bug jadi berasal dari dini pas bug tersebut di- entry ke dalam bug tracking database. Ada pula cerminan siklus hidup berasal dari bug report bisa diamati terhadap foto di bawah ini.
State liat melukiskan standing bug dimana bug sudah di- input ke didalam bug tracking database serta menunggu membuat di- review oleh reviewer sementara sebelum akan bug tersebut diberitakan kepada segala regu proyek pengembangan. State rejected melukiskan standing di mana bug selanjutnya ditolak oleh reviewer gara-gara harus riset ataupun information lebih lanjut menimpa bug tersebut. State open melukiskan standing di mana bug tersebut udah di- liat dan juga di anggap relevan bersama data rinci menimpa bug berikut serta diberitakan keberadaannya kepada segala regu proyek pengembangan.
State assigned menggambarkan status di mana bug berikut ditugaskan kepada pengembang buat melacak knowledge lanjut menimpa bug tersebut dan menyelesaikannya. State test menggambarkan standing dimana bug berikut sudah berakhir diperbaiki oleh pengembang dan perlu diuji bikin membenarkan jika bug selanjutnya betul- betul sudah diperbaiki.
State reopened menggambarkan standing di mana bug diakses ulang membuat diperbaiki ulang oleh pengembang.
State closed melukiskan standing dimana bug sudah berakhir diperbaiki dan juga udah dikonfirmasi kebenarannya melalui pengujian. State deferred mampu digunakan oleh anggota regu proyek bikin menunda revisi bug selanjutnya andaikan mereka mempertimbangkan jikalau bug tersebut mempunyai prioritas yang rendah.
State cancelled mampu digunakan oleh anggota regu proyek buat membatalkan revisi terhadap bug selanjutnya gara-gara dinilai udah tidak relevan lagi. Field Pemilik pada bug report menampilkan nama orang yang bertanggung jawab pada bug tersebut. Dengan terdapatnya field ini diharapkan manajer proyek dapat bersama lebih mudah melacak ataupun melacak data yang lebih rinci ulang menimpa bug tersebut.
Field Estimated Fixed memuat knowledge menimpa ditaksir bertepatan pada bug tersebut berakhir diperbaiki. Field Root Cause berisi knowledge menimpa pangkal pemicu berasal dari terjadinya bug tersebut. Bagi Black root cause dari suatu hal bug secara universal dapat berbentuk:
a) Functional
Dari segi functional, pangkal pemicu berasal dari sesuatu bug bisa berupa spesifikasi yang salah, ataupun spesifikasinya benar tetapi implementasinya salah, ataupun proses berperan bersama benar tapi hasil pengujian memberi mengerti error yang salah.
b) System
Dari sisi system, pangkal pemicu berasal dari sesuatu bug mampu berupa gagalnya komunikasi proses internal, gagalnya hardware, gagalnya operating system, aplikasi architecture yang terbuat salah, ataupun analisis perancangan sudah benar namun analisis ketika pelaksanaannya salah.
c) Process
Dari sisi process, pangkal pemicu dari suatu hal 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 suatu hal bug bisa bersifat jenis informasi yang digunakan salah, susunan informasi yang keliru ataupun pemicu yang lain yang terjalin dengan informasi.
e) Code
Dari segi code, pangkal pemicu dari sesuatu bug dapat bersifat keliru pengetikan terhadap code.
f) Documentation
Dari segi documentation, pangkal pemicu dari sesuatu bug mampu berwujud salahnya dokumentasi terhadap sistem.
gram) Standards
Dari sisi standards, pangkal pemicu dari sesuatu bug dapat bersifat tidak terpenuhnya standar yang sewajarnya pada sistem tersebut.
h) Other
Root cause dari bug dikategorikan ke di dalam other kalau pangkal pemicu berasal dari bug sudah dikenal tetapi tidak cocok dengan jenis yang terdapat.
i) Duplicate
Root cause yang ini digunakan kalau ada 2 maupun lebih bug report yang membatasi bug yang sama.
j) NAP
Dikategorikan selaku NAP( Not a Problem) seumpama bug yang dilaporkan selanjutnya hanya karena uraian yang tidak benar oleh tester.
k) Bad Unit
Root cause ini digunakan apabila bug selanjutnya berhubungan kata kegagalan hardware yang tidak diprediksi.
l) RCN
RCN( Root Cause Needed) digunakan jikalau status berasal dari bug berikut sudah closed namun tidak terdapat yang mengenali pangkal pemicu dari terbentuknya bug tersebut.
meter) Unknown
Root cause unknown digunakan kalau tidak terdapat orang yang mengetahui apa yang berhubungan atas bug tersebut.
Field Phase Injected membatasi fase di mana bug tersebut dikenalkan, kebanyakan pada fase dini sementara sebelum akan fase dimana bug selanjutnya teridentifikasi.
Field Phase Detected membatasi fase di mana bug berikut teridentifikasi.
Field Phase Removed mendeskripsikan fase dimana bug selanjutnya berhasil diperbaiki.
Field Close Date menarangkan bertepatan terhadap di mana standing dari bug tersebut jadi closed.
Field Resolution mendefinisikan gimana bug selanjutnya diperbaiki.
Dari seluruh bug report yang sudah dimasukkan ke di dalam bug tracking database hingga bisa dibuat.
0 Komentar