SAP Business One serta IReap POS ialah 2 aplikasi yang diterapkan di daerah yang berbeda, di mana SAP Business One bertujuan membuat back- end user serta IReap POS buat front- end user. Keduanya silih berkaitan, data- knowledge yang dimasukkan lewat IReap POS hendak dikirimkan ke SAP Business One membuat diolah lagi. Tidak cuma itu, terkandung pula data- knowledge 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 semua Info yang dimasukkan melalui SAP Business One hendak dikirimkan ke IReap POS. Secara garis besar, integrasi antara IReap POS bersama SAP Business One mampu diamati pada foto dibawah ini.
Informasi yang dikirim berasal dari SAP Business One ke SAP Business One Mengenakan format XML, begitu pula bersama dengan informasi yang dikirimkan berasal dari IReap POS ke IReap POS. Kedua aplikasi tersebut bersama menciptakan file XML, tetapi format susunan Info yang dihasilkan sudah pasti berbeda. Buat membandingkan format/ template susunan Info antara ke dua aplikasi tersebut dibutuhkan proses transformasi. Secara rinci, tersedia 6 proses utama didalam integrasi antara IReap POS bersama dengan SAP Business One. Keenam sistem tersebut merupakan selaku berikut:
1. Export berasal 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 disaat terjalin proses import– export serta inbound– outbound, masih banyak proses perinci yang dilaksanakan bertepatan. Buat lebih detailnya dapat dicermati terhadap foto dibawah ini.
Test Tracking Spreadsheet
Buat mempermudah pengelolaan terhadap penerapan pengujian dapat digunakan suatu perlengkapan yang dinamakan selaku test tracking spreadsheet. Dengan penggunaan test tracking spreadsheet, hendak membolehkan tester buat melacak tiap status berasal dari test case, mengenali konfigurasi yang digunakan dan juga mengenali siapa yang sudah laksanakan pengujian terhadap sesuatu test case.( Black, 2009: 200)
Kolom awal dari test tracking spreadsheet selanjutnya memuat namatest suite/ test case dari sesuatu pengujian. Kolom state menggambarkan standing berasal dari masing- masing test case. Bila kolom state ini kosong, hingga mengindikasikan jikalau test case selanjutnya masih didalam antrian membuat dicoba pengujian. Bila kolom ini berisi pass, hingga berarti jikalau pengujian membuat test case selanjutnya tidak menciptakan bug. Bila memuat fail, sampai berarti terkandung bug yang ditemui berasal dari pengujian test case tersebut baik satu ataupun lebih.
Kolom system config memuat penjelasan identifikasi membuat mengenali konfigurasi proses yang digunakan oleh masing- masing test case. Kolom bug id berisi bukti diri dari bug yang ditemui berasal dari hasil pengujian test case. Kolom ini yang nantinya hendak mempermudah test team buat melacak bug selanjutnya dan juga mereferensikannya terhadap bug report yang terbuat didalam bug tracking database.
Kolom by memuat nama samaran berasal dari tester yang telah melakukan pengujian terhadap test case. Kolom comment berisi pendapat berasal dari tester ataupun information bonus menimpa standing 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 memuat nilai 1 seumpama ialah test case.
b) Kolom F berisi nilai 1 andaikata standing berasal dari test case merupakan fail.
c) Kolom P memuat nilai 1 jikalau standing berasal dari test case merupakan pass.
Bug Report
Mengacu terhadap komentar Black( 2009: 146), bug report merupakan dokumen tehnis yang digunakan membuat mendeskripsikan berbagai indikasi maupun kegagalan yang terjalin dengan sesuatu bug khusus secara khusus. Sesuatu dokumen bug report yang dirancang bersama baik bisa membagikan information yang tepat untuk regu manajemen proyek menimpa bug selanjutnya supaya bisa menyita ketentuan yang pas( misalnya, apakah bug berikut harus lekas diperbaiki ataupun tidak). Tidak hanya itu, bug report pula mampu digunakan oleh para programmer ataupun pengembang bikin mengetahui information rinci menimpa sesuatu bug sehingga mempermudah penyelesaian bug tersebut.
Field Bug ID memuat pengidentifikasi dari sesuatu bug yang sanggup dijadikan rujukan berasal dari sesuatu test tracking spreadsheet. Field Project Name memuat knowledge menimpa nama proyek dimana bug berikut ditemui. Field Tester memuat data menimpa namatester yang menciptakan bug tersebut. Field Date Opened memuat information menimpa bertepatan terhadap bug tersebut dimasukkan ke di dalam bug tracking database.
Field Quality Risk Category: Perinci berisi knowledge menimpa tipe rinci berasal dari quality risk yang didetetapkan secara khusus bersumber terhadap bug tersebut. Field Subsystem memuat information menimpa subsystem di mana bug selanjutnya ditemui. Field Configuration berisi information menimpa konfigurasi yang digunakan saat laksanakan pengujian.
Field Severity dan juga Priority diisi bersama dengan skala yang serupa bersama dengan yang sudah dipaparkan pada anggota failure fashion plus effects analysis. Field RPN pada bug report didapat berasal dari perkalian pada evaluasi severity serta priority. Dengan demikian, range berasal dari RPN merupakan berkisar antara 1– 25, di mana nilai 1 mengindikasikan jikalau bug tersebut terlampau beresiko dan juga nilai 25 mengindikasikan terkecuali bug selanjutnya hanya perihal sepele yang sanggup diabaikan.
Field summary memuat penjelasan pendek menimpa bug. Field steps to reproduce sediakan suatu hal uraian yang tepat dan juga mengerti berkenaan gimana menciptakan lagi bug tersebut. Field isolation memuat data buat menyakinkan pengembang/ programmer jikalau bug yang ditemui selanjutnya merupakan betul- betul bug. Perihal ini mampu bersama dengan menyebutkan tanda- isyarat timbulnya bug berikut dan juga sanggup pula bersama menarangkan akibat dan pemicu dari timbulnya bug tersebut.
Field log berisi knowledge rinci menimpa siklus hidup berasal dari suatu hal bug menjadi dari dini sementara bug berikut di- entry ke didalam bug tracking database. Ada pula cerminan siklus hidup berasal dari bug report bisa dicermati pada foto dibawah ini.
State simak menggambarkan standing bug di mana bug telah di- input ke didalam bug tracking database serta menanti buat di- simak oleh reviewer selagi sebelum saat bug berikut diberitakan kepada segala regu proyek pengembangan. State rejected melukiskan status di mana bug tersebut ditolak oleh reviewer dikarenakan wajib riset ataupun knowledge lebih lanjut menimpa bug tersebut. State open melukiskan standing dimana bug berikut udah di- review serta dianggap relevan bersama knowledge rinci menimpa bug selanjutnya serta di informasikan keberadaannya kepada segala regu proyek pengembangan.
State assigned menggambarkan status di mana bug selanjutnya ditugaskan kepada pengembang bikin melacak information lanjut menimpa bug selanjutnya dan menyelesaikannya. State test menggambarkan status dimana bug tersebut sudah berakhir diperbaiki oleh pengembang dan perlu diuji bikin membetulkan jika bug tersebut betul- betul udah diperbaiki.
State reopened melukiskan status dimana bug diakses ulang membuat diperbaiki kembali oleh pengembang.
State closed melukiskan standing di mana bug telah berakhir diperbaiki serta udah di konfirmasi kebenarannya lewat pengujian. State deferred sanggup digunakan oleh bagian regu proyek bikin menunda revisi bug tersebut misalnya mereka memperhitungkan jikalau bug tersebut mempunyai prioritas yang rendah.
State cancelled mampu digunakan oleh bagian regu proyek membuat membatalkan revisi terhadap bug selanjutnya karena dinilai telah tidak relevan lagi. Field Pemilik terhadap bug report menampilkan nama orang yang bertanggung jawab terhadap bug tersebut. Dengan ada field ini dikehendaki manajer proyek mampu bersama lebih gampang melacak ataupun melacak knowledge yang lebih rinci lagi menimpa bug tersebut.
Field Estimated Fixed berisi knowledge menimpa ditaksir bertepatan terhadap bug tersebut berakhir diperbaiki. Field Root Cause memuat knowledge menimpa pangkal pemicu berasal dari terjadinya bug tersebut. Bagi Black root cause dari suatu hal bug secara universal dapat berbentuk:
a) Functional
Dari sisi functional, pangkal pemicu dari suatu hal bug bisa berwujud spesifikasi yang salah, ataupun spesifikasinya benar tapi implementasinya salah, ataupun sistem berperan bersama benar tetapi hasil pengujian berikan tahu error yang salah.
b) System
Dari sisi system, pangkal pemicu berasal dari suatu hal bug dapat berupa gagalnya komunikasi proses internal, gagalnya hardware, gagalnya operating system, aplikasi architecture yang terbuat salah, ataupun anggapan perancangan sudah benar namun pemikiran ketika pelaksanaannya salah.
c) Process
Dari segi process, pangkal pemicu berasal dari suatu hal bug sanggup berupa salahnya operasional aritmatika yang diterapkan, proses inisialisasi yang salah, control ataupun sequence yang salah, maupun error di dalam pemrosesan.
d) Data
Dari segi informasi, pangkal pemicu dari suatu hal bug sanggup berupa type informasi yang digunakan salah, susunan Info yang keliru ataupun pemicu yang lain yang terjalin dengan informasi.
e) Code
Dari sisi code, pangkal pemicu dari sesuatu bug dapat berbentuk tidak benar pengetikan pada code.
f) Documentation
Dari sisi documentation, pangkal pemicu berasal dari suatu hal bug sanggup bersifat salahnya dokumentasi terhadap sistem.
gram) Standards
Dari sisi standards, pangkal pemicu dari sesuatu bug sanggup berupa tidak terpenuhnya standar yang sewajarnya pada proses tersebut.
h) Other
Root cause dari bug dikategorikan ke di dalam other jika pangkal pemicu berasal dari bug udah dikenal tapi tidak cocok bersama dengan jenis yang terdapat.
i) Duplicate
Root cause yang ini digunakan seandainya tersedia 2 maupun lebih bug report yang mendeskripsikan bug yang sama.
j) NAP
Dikategorikan selaku NAP( Not a Problem) seandainya bug yang dilaporkan selanjutnya cuma sebab uraian yang tidak benar oleh tester.
k) Bad Unit
Root cause ini digunakan kalau bug tersebut terkait kata kegagalan hardware yang tidak diprediksi.
l) RCN
RCN( Root Cause Needed) digunakan bila status berasal dari bug tersebut udah closed tetapi tidak terdapat yang mengetahui pangkal pemicu berasal dari terbentuknya bug tersebut.
meter) Unknown
Root cause unknown digunakan seandainya tidak terdapat orang yang mengetahui apa yang terjalin atas bug tersebut.
Field Phase Injected mendeskripsikan fase di mana bug tersebut dikenalkan, kebanyakan pada fase dini waktu sebelum fase di mana bug tersebut teridentifikasi.
Field Phase Detected mendeskripsikan fase di mana bug berikut teridentifikasi.
Field Phase Removed mengartikan fase di mana bug berikut berhasil diperbaiki.
Field Close Date menarangkan bertepatan pada di mana status berasal dari bug selanjutnya menjadi closed.
Field Resolution mengartikan gimana bug selanjutnya diperbaiki.
Dari semua bug report yang sudah dimasukkan ke di dalam bug tracking database hingga sanggup dibuat.
0 Komentar