15
BAB III
PELAKSANAAN KERJA MAGANG
3.1 Kedudukan dan Koordinasi
Dalam PT Omni Digitama Internusa, penulis sebagai quality assurance berada dibawah divisi tech/IT yang dipimpin oleh Chief Technology Officer (CTO) dibawah pimpinan Bapak Ronny Winoto. Team Quality Assurance (QA) merupakan bagian dari product team ruparupa yang dipimpin oleh Hendro Surono selaku senior product lead. Sedangkan divisi QA sendiri berada dibawah dibawah pimpinan Jefri Susiono selaku QA/QC lead ruparupa.
Team atau divisi QA terdiri dari 9 orang dimana 7 orang merupakan QA/QC squad dan 2 orang QA/QC squad intern termasuk penulis. Koordinasi di divisi QA dipimpin oleh Jefri Susiono sebagai QA/QA lead dengan memberikan arahan dan task yang akan dilaksanakan oleh para anggota QA/QA squad dan melakukan diskusi dan sharing ilmu terkait pengujian. Task yang diberikan adalah melakukan testing atau pengujian untuk memastikan software/fitur yang sudah selesai dikembangkan oleh para developer dari ruparupa sudah sesuai dengan hasil yang diharapkan dan tidak terdapat bugs/error.
Dalam mendukung proses dari pengujiaan tersebut, penulis melakukan koordinasi dengan anggota tim dari divisi lain seperti divisi backend yang dipimpin oleh Iman Suhardiman, divisi frontend yang dipimpin oleh Iwan Sugiarto, dan divisi lainnya terkait dengan cara pengujian, alur pengujian dan apa saja yang hasil output yang diharapkan dari fitur yang telah dikembangkan.
16 3.2 Tugas yang Dilakukan
Dalam perlaksanaan kerja magang selama 9 minggu, tugas-tugas yang dilakukan oleh penulis adalah untuk melakukan software testing baik dalam bentuk mobile apps, website maupun mobile web. Software testing yang dilakukan oleh penulis mencakup bisnis unit yang berada dibawah naungan kawan lama group seperti Rupa-rupa, Ace Hardware, Informa dan Toys Kingdom.
Dalam mendukung dan membantu penulis dalam melakukan pengujian sebagai seorang QA, penulis menggunakan beberapa tools yang disesuaikan juga dengan ketentuan dari team. Adapun tools yang digunakan penulis adalah sebagai berikut:
1. Coda.io
Gambar 3. 1. Logo Coda
17 Gambar 3. 2. Contoh tampilan Coda.io
Gambar 3.1 merupakan logo dari Coda.io. Coda.io adalah sebuah cloud-based document editor. Pada team QA, Coda. Digunakan untuk daily scrum dengan menginput task yang sedang dikerjakan pada pagi hari, target dan update progress dari task yang dikerjakan pada sore hari seperti yang ditampilkan pada gambar 3.2.
2. Jira
Gambar 3. 3. Logo Jira
Gambar 3.3 adalah logo dari Jira Software. Jira adalah sebuah tools yang digunakan dalam membantu project management. Jira digunakan oleh tim tech ruparupa dalam melakukan tracking dan memanage seluruh project yang sedang dikerjakan. Segala jenis pelaporan dan update progress dari projek yang sedang dikerjakan dapat dilihat pada tools jira ini sehingga setiap tim yang terlibat dapat mengetahui tugas apa yang
18 harus dikerjakan, sudah sampai mana projek tersebut dikerjakan dan terdapat issue apa yang harus diperbaiki.
3. App center
Gambar 3. 4. Logo App Center
Gambar 3.4 merupakan logo dari Visual Studio App Center. App center adalah sebuah integrated mobile development lifecycle solution untuk aplikasi-aplikasi Android, iOS, Windows dan macOS. Center Apps digunakan oleh penulis sebagi tools untuk melakukan pengujian/testing terhadap mobile apps pada platform Android dan iOS yang dikembangkan oleh developer sebelum akhirnya dideploy untuk digunakan oleh user.
4. Google Sheets
Gambar 3. 5. Logo Google Sheets
Gambar 3.5 merupakan logo dari google sheets.
Google Sheets adalah sebuah tools spreadsheet program seperti layaknya microsoft excel. Google sheets
19 digunakan oleh QA untuk membuat dokumen test case dari pengujian sebuah project. Dikarenakan google sheets berbasis cloud, maka test case yang dibuat oleh QA dapat di share kepada tim lain dari tech ruparupa yang terlibat dalam pembuatan project dan dapat menambahkan catatan kepada tim mengenai apa saja yang harus dikerjakan atau yang harus diperbaiki lagi.
5. Google Meet
Gambar 3. 6. Logo Google Meet
Gambar 2.6 adalah logo dari google meet. Google meet adalah sebuah video-communication service yang dikembangkan oleh google. Google meet merupakan tools yang sangat berguna dalam melakukan komunikasi dengan team selama masa pandemi Covid-19. Google meet digunakan oleh penulis untuk berinteraksi dengan team dari QA maupun dengan team teach lain dari ruparupa untuk scrum meeting, project meeting, dan berinteraksi satu sama lain.
20 3.3 Uraian Pelaksanaan Magang
3.3.1 Minggu Pertama: PEO, Briefing Endpoint Get Refund, Testing dan membuat testcase mobile apps ruparupa v2 (android)
Pelaksanaan kerja magang dimulai pada hari senin tanggal 15 Februari 2021. Pada hari pertama pelaksanaan kerja magang, penulis mengikuti kegiatan PEO (Personal Employee Orientation). PEO adalah kegiatan pengenalan antar karyawan dan personel yang baru bergabung ke dalam perusahaan dibawah kawan lama group. PEO dimulai pada pukul 08.30 dan dipandu oleh perwakilan HRD. Pada kegiatan tersebut para personel yang baru bergabung memperkenalkan diri masing-masing beserta latar belakang, posisi, dan pada bisnis unit mana para personel di tempatkan.
Setelah mengenal satu sama lain, perwakilan HRD mulai menjelaskan sejarah perusahaan, fasilitas yang didapatkan, benefit, dan hal-hal administrasi lainnya.
Setelah selesai kegiatan PEO, penulis diberi task untuk mencoba melakukan testing untuk modul endpoint get refund list for store and dc dan penambahan validasi no hp untuk proses refund. Penulis sempat melakukan briefing melalui google meet dengan developer terkait modul tersebut, dikarenakan ditemukan bugs, dimana saat memilih alasan melakuka refund, halaman website menjadi blank. Setelah melakukan beberapa test, pada akhirnya task tersebut diserahkan kepada anggota QA lain dikarenakan anggota QA tersebut sedang melakukan testing terkait refund.
21 Task lain yang diberikan kepada penulis adalah membantu dalam melakukan testing dan membuat test case untuk mobile apps ruparupa v2 (Android). Rupa rupa V2 adalah versi terbaru dari mobile apps rupa-rupa yang akan diluncurkan pada masa mendatang. Pada mobile apps ruparupa v2, terdapat beberapa fitur dan tampilan baru juga dibandingkan dengan versi sebelumnya.
Gambar 3. 7. Perbandingan Mobile Apps Ruparupa V1 (Kiri) dan V2 (Kanan)
Gambar 3.7 merupakan contoh perbandingan tampilan antara mobile apps ruparupa v1 dengan v2. Dalam apps versi terbaru, terdapat beberapa penambahan fitur-fitur baru dan tampilan yang memiliki fungsi yang lebih
22 bermanfaat dan lebih baik bagi customer. Pada pengujian mobile apps ruparupa v2, penulis melakukan testing pada platform/device android.
Gambar 3. 8. Tampilan Daftar Fitur/Modul testing V2
Gambar 3.8 merupakan contoh tampilan dari google sheets yang berisi daftar fitur dan modul yang akan dilakukan pengujian oleh QA.
Google sheets tersebut dapat diakses oleh team yang terlibat dalam pengembangan mobile apps ruparupa v2, mulai dari frontend,backend,project manager, dan QA. Tujuan dibuatnya google sheets tersebut adalah untuk mempermudah seluruh anggota tim yang terlibat dalam koordinasi dan memantau progress dari project.
Google sheets diatas dibagi kedalam beberapa bagian seperti Doing, Done, Done Testing. Doing adalah daftar fitur yang akan sudah selesai dikembangkan dan sudah di fix bugs oleh tim developer, Done adalah status dari fitur tersebut apakah sudah selesai dikembangkan atau saudah diperbaiki bugs nya. Sedangkan Done Testing adalah daftar fitur yang sudah selesai di lakukan pengujian. Jika terdapat fitur yang mengalami error atau ditemukan bugs, maka akan dituliskan pada google sheets ini dan
23 melakukan follow up ke developer untuk menginformasikan hasil temuan pada proses testing.
3.3.2 Minggu Kedua: Testing handling fee mini cart untuk website, mobile web, mobile apps ruparupa, dan mobile apps miss ace.
Pada minggu kedua, penulis mendapatkan tugas untuk melakukan testing handling fee mini cart untuk website ruparupa.com. handling fee minicart adalah sebuah tampilan dimana ketika customer melakukan pembelian produk, dan produk tersebut dikenakan biaya layanan, maka pada mini cart akan muncul harga produk dan biaya layanannya. Awalnya produk yang dikenakan handling fee akan memunculkan tampilan handling fee pada saat customer melakukan checkout. Sebagai peningkatan, maka tampilan handling fee juga ingin ditampilkan pada mini cart agar customer tidak kebingungan saat melakukan checkout. Pada dasarnya tidak semua produk dikenakan handling fee. Handling fee akan dibebankan kepada customer ketika produk pada store lain di wilayah Indonesia memiliki perbedaan harga dengan store pusat yang terdapat di jakarta.
Testing handling fee minicart pada website ruparupa.com dilakukan pada multistaging yang telah ditentukan dengan tujuan agar tidak mengganggu website dari ruparupa yang digunakan oleh customer. Setelah pengujian yang dilakukan di multistaging telah selesai dan tidak terdapat bugs atau error, maka fitur yang diuji akan dinaikkan ke tahap production, dimana production adalah tahap dimana fitur tersebut sudah dapat diakses oleh end user / customer.
24 Gambar 3. 9. Tampilan Stagging Website Ruparupa.com
Gambar 3.9 merupakan tampilan dari stagging yang digunakan untuk pengujian website ruparupa.com. Secara UI tampilan dari stagging hampir sama dengan tampilan website sebenarnya dari ruparupa.com, namun pada beberapa kasus terdapat perbedaan tergantung fitur atau tampilan apa yang mau di testing.
Gambar 3. 10. Tampilan Handling Fee Minicart di Website Ruparupa.com
Gambar 3.10 merupakan tampilan dari handling fee atau biaya layanan yang akan muncul pada halaman mini cart ketika sebuah produk dikenakan biaya layanan yang akan dibebankan kepada customer. Jika sebuah produk tidak dikenakan biaya layanan / handling fee, maka tampilan
25 biaya layanan tidak akan muncul di halaman mini cart dan hanya akan muncul pada saat halaman checkout.
Gambar 3. 11. Tampilan Stagging Mobile Web Ruparupa
Gambar 3.11 merupakan contoh tampilan dari stagging yang digunakan untuk testing fitur / tampilan handling fee minicart di mobile web ruparupa.
26 Gambar 3. 12. Tampilan Handling Fee pada Halaman Mini Card di Mobile
Web Ruparupa
Gambar 3.12 merupakan contoh tampilan dari handling fee yang akan muncul jika customer membeli produk yang dikenakan biaya layanan.
Secara konsep, biaya layanan pada mobile web sama seperti yang sudah dijelaskan pada bagian website.
27 Gambar 3. 13. Tampilan Stagging Apps Ruparupa
Gambar 3.13 merupakan contoh tampilan dari stagging yang digunakan untuk testing fitur / tampilan handling fee minicart di mobile apps ruparupa.
28 Gambar 3. 14. Tampilan Stagging Apps Miss Ace
Gambar 3.14 merupakan contoh tampilan dari stagging yang digunakan untuk testing fitur / tampilan handling fee minicart di mobile apps miss ace.
29 Dalam melakukan testing, penulis juga membuat sebuah dokumen test case seperti yang ditunjukkan pada gambar 3.15 – 3.18 gambar yang didalamnya terdapat penjelasan mengenai fitur apa yang akan dilakukan pengujian, langkah-langkah, data yang digunakan dalam pengujian, hasil yang diharapkan dan apa hasil aktual yang didapatkan setelah melakukan pegujian. Terdapat 16 test cases yang dibuat oleh penulis dengan berbagai macam skenario mulai dari memilih produk, memilih pickup location, order, checkout sampai ke pembayaran dan pengecekan order yang masuk pada dashboard admin.
Gambar 3. 15. Test Case Handling Fee Mini Cart
Gambar 3. 16. Test Case Handling Fee Mini Cart
30 Gambar 3. 17. Test Case Handling Fee Mini Cart
Gambar 3. 18. Test Case Handling Fee Mini Cart
Testing tidak hanya dilakukan pada sisi user/customer tetapi juga dilakukan pada sisi admin yang menangani order di dashboard OMS (Order Management System). Tujuan dilakukan pengetesan pada sisi admin OMS adalah untuk membandingkan harga produk, biaya layanan dan produk yang diorder oleh customer telah sesuai dengan pencatatan di dashboard OMS.
31 Gambar 3. 19. Tampilan Dashboard OMS
Gambar 3.19 merupakan contoh tampilan dari OMS (Order Management System). Pada dashboard ini, admin dapat melihat dan memproses segala produk yang diorder oleh customer.
Gambar 3. 20. Test Case Handling Fee Mini Cart (Admin)
32 Gambar 3. 21. Test Case Handling Fee Mini Cart (Admin)
Gambar 3. 22. Test Case Handling Fee Mini Cart (Admin)
Gambar 3. 23. Test Case Handling Fee Mini Cart (Admin)
Gambar 3.20 – gambar 3.23 merupakan test case dari testing handling fee mini cart. Pada test case tersebut terdapat 12 skenario pengujian yang dilakukan oleh penulis seperti membandingkan harga, memproses order, dan lainnya.
Dalam proses testing fitur/tampilan handling fee mini cart, ditemukan beberapa issue seperti tampilan handling fee tidak muncul, order
33 mengalami blocking pada proses pembayaran, dan issue pada SKU. Solusi yang dilakukan oleh penulis adalah membuat bugs notes dan berkomunikasi dengan developer yang terkait. Setelah dikomunikasikan, dan diperbaiki, kemudian dilakukan re-testing untuk memastikan bugs tersebut telah diperbaiki.
3.3.3 Minggu Ketiga : Testing Pop Up Image Dashboard TAHU Mobile Apps Ruparupa
Pada minggu ketiga, penulis mendapatkan task untuk melakukan pengujian fitur PopUp Image Dashboard TAHU. Pada modul ini, developer ruparupa membuat sebuah dashboard untuk mengakomodasi sebuah fitur untuk menampilkan popup image dari promosi yang akan muncul pada halaman utama mobile apps, mobile web, maupun website ruparupa.com saat pertama kali dibuka. Oleh karena itu penulis akan melakukan pengujian untuk memastikan fitur baru ini telah sesuai dengan output yang diharapkan dan terbebas dari error dan bugs.
Penulis melakukan pengujian fitur ini pada stagging yang dapat digunakan untuk mengakses dashboard TAHU (Template Application Heuristic Utilization) seperti pada gambar 3.24. Pada Dashboard TAHU ini, tim dari divisi lain seperti marketing atau konten dapat saling berkolaborasi dalam membuat landing page untuk mobile apps, mobile web, dan website dari ruparupa.com.
34 Gambar 3. 24. Tampilan Template Application Heuristic Utilization (TAHU)
Gambar 3. 25. Tampilan Dashboard Popup Image TAHU
Gambar 3.25 merupakan tampilan dashboard live popup image TAHU. Dashboard ini terbagi menjadi 2 bagian, yaitu live popup image dan image popup. Pada bagian live popup image, penulis melakukan pengujian apakah popup image yang dibuat sudah tampil pada bagian priview popup image sesuai dengan jam dan dan tanggal yang sudah ditentukan.
35 Sedangkan pada bagian image popup, penulis dapat melihat daftar popup image yang sudah yang dibuat dan melakukan input image popup.
Gambar 3. 26. Tampilan Popup Image pada Mobile Apps
Gamber 3.26 merupakan contoh dari popup image pada mobile apps ruparupa. popup image ini akan muncul pada jam dan tanggal yang sudah ditentukan dan akan berpindah ke halaman yang sudah diatur oleh user pada TAHU. Penulis melakukan pengujian untuk memastikan bahwa popup image tersebut telah sesuai dengan hasil yang diharapkan dari berbagai skenario pengujian berdasarkan test case yang telah dibuat oleh penulis seperti pada gambar 3.27-3.29.
36 Gambar 3. 27. Test Case Popup TAHU
Gambar 3. 28. Test Case Popup TAHU
Gambar 3. 29. Test Case Popup TAHU
Gambar 3.27 - 3.29, merupakan test case yang dibuat oleh penulis untuk pengujian popup TAHU. test case yang dibuat oleh penulis terdiri dari 24 skenario pengujian. Dari hasil pengujian yang dilakukan oleh penulis, ditemukan beberapa skenario yang tidak sesuai dengan expected
37 result, namun penulis langsung melaporkan bugs kepada developer untuk segera dilakukan perbaikan. Setelah developer memperbaiki bugs, developer akan mengisi status bugs fix dengan “Done” pada test case.
Penulis melakukan sanity testing atau pengujian kembali fitur yang sudah diperbaiki oleh developer. Hasil dari pengujian yang dituangkan pada dokumen test case, 12 skenario pass yang ditandai dengan warna hijau dan 12 skenario pass with note yang ditandai dengan warna kuning. Status pass with note menandakan skenario pengujian tersebut sudah sesuai dengan hasil yang diharapkan namun ada catatan yang harus diperhatikan oleh developer/user.
3.3.4 Minggu Keempat : Testing Improvement TAHU- Custom Meta Tag & Testing Improvement on Pagination TAHU Campaign
Pada minggu keempat, penulis masih melakukan monitoring terhadap popup image dashboard TAHU untuk memastikan bugs tidak terjadi. Selain melakukan monitoring, penulis mendapatkan 2 task untuk melakukan pengujian terhadap:
38 a. Testing Improvement TAHU - Custom Meta Tag
Custom meta tag adalah sebuah fitur yang dibuat agar kedepannya meta tag pada halaman promo atau halaman yang dibuat di TAHU dapat di custom atau di edit oleh tim SEO, tim konten atau tim lainnya sehingga tidak perlu dilakukan edit dari hardcode.
Gambar 3. 30. Tampilan Form Landing Page Meta Tag
Gambar 3.30 adalah contoh dari form landing page, yang dimana pada form tersebut nantinya tim dari konten maupun SEO dapat melakukan input data untuk promosi termasuk meta tag yang terdiri dari meta title dan meta description.
39 Gambar 3. 31. Tampilan Inspect Element
Gambar 3.31 merupan tampilan dari inspect element yang terdapat pada developer tools. Meta tag yang sudah dibuat oleh penulis pada dashboard TAHU dapat diperiksa pada bagian head dari inspect element seperti yang sudah diberi tanda kotak bewarna oranye pada gambar 3.31. Jika Meta tag berhasil di input dan terdeteksi pada webiste dan mobile web maka meta title dan meta description akan muncul dalam format code seperti pada gambar 3.32.
<title>%Custom Title%</title>
<meta name=”title” content=”%Custom Title%”/>
<meta name=”description” content=”%Custom Description%”/>
Gambar 3. 32. Format Code Custom Meta Tag
40 Selain melakukan pengujian untuk custom meta tag, penulis juga melakukan pengujian terhadap meta og dan twitter card, dimana isi / input dari kedua komponen tersebut dibuat sama dengan meta description dan meta tag. Tujuan dibuat sama adalah, agar ketika dilakukan share link dari suatu halaman promosi, maka judul dan deskripsinya sesuai dan muncul popup meta og atau twitter card. Langkah pengujian yang dilakukan oleh penulis, sama dengan langkah yang dilakukan pada pengujian custom meta tag. Format code dari pengujian ini terdapat pada gambar 3.33.
<meta property=”og:title” content=”%Custom Title%”/>
<meta property=”og:description” content=”%Custom Description%”/>
<meta property=”og:description” content=”%Custom Description%”/>
<meta name=”twitter:title” content=”%Custom Title%”/>
<meta name=”twitter:description”content=”%Custom Description%”/>
Gambar 3. 33. Format Code Meta Og & Twitter Card
Penulis membuat dokumen test case dari hasil pengujian terhadap modul diatas. Dokumen test case dari pengujian diatas adalah sebagai berikut.
41 Gambar 3. 34. Test Case Custom Meta Tag
Gambar 3. 35. Test Case Custom Meta Tag
Gambar 3. 36. Test Case Custom Meta Tag
Gambar 3.34-3.36 merupakan dokumen test case yang dibuat oleh penulis sebagai QA yang melakukan pengujian terhadap modul custom meta tag. Dokumen
42 test case tersebut terdiri dari 18 skenario pengujian dengan hasil 15 skenario berstatus “pass” dan 3 skenario berstatus “fail”.
b. Testing Improvement on Pagination TAHU Campaign Pada task ini, penulis melakukan pengujian terhadap modul pagination TAHU campaign. Permasalahan yang dialami sebelumnya pada modul ini adalah pada saat mengunjungi halaman dashboard TAHU, campaign yang sudah dibuat, dimuat atau ditampilkan dalam waktu yang sangat lambat (slow loaded), sehingga permasalahan ini memberikan impact (dampak) pada kinerja dari website dan juga backend.
Menurut tim backend yang bekerja sama dengan penulis dalam task ini, akar masalah dari permasalahan diatas dikarenakan API request yang tidak menggunakan pagination (offset, limit) sehingga semua campaign yang sudah dibuat dimuat dalam satu waktu sehingga membutuhkan waktu yang lebih lama.
Berdasarkan masalah diatas, maka solusi yang dilakukan adalah dengan membuat dan mengolah ulang permintaan penomoran halaman (pagination) dengan menggunakan batas offset ke API backend, daripada meminta semua record dalam satu permintaan. Selain itu
43 setiap kali halaman dinavigasi, akan diambil nilai halaman saat ini ke API.
Dari penjelasan diatas, maka penulis akan melakukan pengujian terhadap modul pagination TAHU campaign untuk memastikan solusi diatas telah berjalan sesuai dengan yang diharapkan dan terhindar dari bugs dan error.
Gambar 3. 37. Tampilan Dashboard TAHU
Gambar 3.37 adalah tampilan dari TAHU Dashboard dimana user nantinya dapat membuat campaign untuk promosi. Penulis melakukan pengujian terhadap halaman dasboard ini berdasarkan penjelasan diatas yaitu untuk memastikan waktu memuat (load time) dari
44 halaman dashboard ini tidak lambat, selain itu penulis juga menguji pagination yang diletakkan dibawah dashboard dengan mencoba berpindah halaman campaign dan menghitung waktunya.
Gambar 3. 38. Tampilan Developer Tools
Gambar 3.38 merupakan tampilan dari developer tools yang terdapat pada google chrome. Penulis menggunakan developer tools untuk melalukan perhitungan terhadap load time dan jumlah waktu yang diperlukan untuk memuat sebuah halaman dashboard TAHU. perhitungan waktu tidak hanya dilakukan pada saat pertama kali membuka halaman TAHU, tetapi juga
45 menghitung waktu yang diperlukan untuk menampilkan campaign pada halaman lain, platform (mobile webiste, mobile apps android, mobile apps Ios, desktop website) lain dan juga waktu yang diperlukan untuk manampilkan caimpaign dengan keyword tertentu. Penulis mendokumentasikan hasil dari pengujian dan skenario pengujian pada dokumen test case seperti yang terdapat pada gambar 3.33 dan gambar 3.34.
Gambar 3. 39. Test Case Pagination TAHU Campaign
Gambar 3. 40. Test Case Pagination TAHU Campaign
46 Gambar 3.39 merupakan dokumen test case yang berisikan skenario pengujian terhadap pagination TAHU campaign. Terdapat 8 seknario pengujian yang dibuat oleh penulis dengan hasil 5 dari 8 skenario berstatus
”pass” dan 3 skenario bertatus “fail”. Hasil pengujian dibagikan dengan developer yang menangani task dan penulis melakukan komunikasi terkait bugs yang ditemukan dari hasil pengujian untuk segera dilakukan perbaikan.
Gambar 3.40 merupakan dokumen test case yang berisikan catatan dari waktu untuk memuat campaign di TAHU (load time). Catatan waktu ini terdiri dari berbagai skenario seperti pengujian load time terhadap campaign tanpa keyword di berbagai platform, dan pengujian load time dengan menggunakan keyword di berbagai platform. Selain itu terdapat keterangan mengenai parameter dan acuan waktu yang baik, sehingga penulis sebagai penguji dapat mengetahui apakah waktu aktual dari hasil pengujian sudah sesuai dengan waktu yang diharapkan.
47 3.3.5 Minggu Kelima : Testing Popup Image Website Ruparupa, Testing Mobile Apps Development-PCP Matras, Testing PDP Geolocation, & Support Ruparupa Mobile Apps V2
Pada minggu kelima dalam kegiatan magang, penulis masih melanjutkan testing yang belum selesai dari minggu sebelumnya seperti testing improvement TAHU-custom meta tag dan testing improvement on pagination TAHU campaign. Progress dari kedua task tersebut belum mengalami peningkatan yang pesat dikarenakan penulis masih menunggu developer untuk memperbaiki bugs yang ada.
Penulis melakukan pengujian terhadap beberapa task lain yang diberikan seperti:
a. Testing Popup Image Dashboard TAHU-Website Pengujian terhadap modul ini pada dasarnya penulis hanya melanjutkan dan sama seperti yang sudah dilakukan oleh penulis pada minggu ke 3 dan minggu ke 4 sebelumnya. Pada task ini, penulis melakukan pengujian pada website dari ruparupa.com. Dokumen test case dan Tools yang digunakan juga sama dengan hasil dari pengujian pada mobile apps.
b. Testing Mobile Apps Development – PCP Matras Pada task ini, penulis hanya melakukan pengujian terhadap user interface (UI) dari mobile apps ruparupa untuk memastikan tampilan dari category page matras
48 sudah sama dengan tampilan di website & mobile web ruparupa.com. Pengujian ini dilakukan dikarenakan sebelumnya category page matras di website & mobile web ruparupa.com yang di custom hard code dan halaman yang terdapat pada hard code belum dapat diakses di mobile apps sehingga tampilannya berbeda, sehingga tim developer menyamakan tampilan dari kedua platform tersebut.
Dalam melakukan pengujian, penulis menggunakan tools app center yang didalamnya terdapat APK yang bisa di unduh oleh penulis untuk melakukan pengujian.
Gambar 3. 41. Tampilan PCP Matras Mobile Web (Kiri) dan Webiste (Kanan)
49 Gambar 3. 42. Tampilan Mobile Apps PCP Matras Setelah Disamakan
Gambar 3.41 merupakan contoh tampilan dari PCP matras pada website dan mobile web yang tampilannya harus disamakan kepada mobile apps ruparupa. Gambar 3.42 merupakan tampilan dari mobile apps ruparupa yang telah disamakan dengan versi web dan mobile web.
50 Gambar 3. 43. Test Case Category Page Matras
Gambar 3.43 merupakan dokumen test case dari pengujian tampilan PCP matras. Terdapat 8 skenario pengujian yang dibuat oleh penulis untuk membandingkan persamaan tampilan UI. Berdasarkan hasil pengujian yang dilakukan oleh penulis, hasil dari tampilan PCP matras di mobile apps sudah sesuai dengan tampilan pada website dan mobile web ruparupa.
c. Testing PDP Geolocation
Pada task ini, penulis melakukan pengujian terhadap modul PDP geolocation. pada modul PDP geolocation ini, developer memasangkan default geolocation pada metode selfpickup yang didasarkan pada kecamatan yang dipilih oleh customer. Penulis melakukan pengujian modul ini untuk website dan mobile website ruparupa.
Cara kerja dari PDP geolocation adalah ketika customer
51 mengjinkan (allow) webiste/mobile web ruparupa untuk mengakses lokasi dari customer, maka metode selfpickup akan menampilkan lokasi toko yang terdekat dengan lokasi dari customer saat ini dan jaraknya sebagai default location. Jika customer tidak mengijinkan (deny) website/mobile web ruparupa untuk mengakses lokasi dari customer, maka metode selfpickup akan mengambil lokasi terdekat dari lokasi ketersediaan pengiriman yang di input oleh customer.
Gambar 3. 44. Selfpickup PDP Geolocation (Allow Location)
Gambar 3.44 merupakan contoh tampilan PDP geolocation dari metode selfpickup jika customer mengijinkan akses ke lokasi terkini. Untuk pengujian ini, lokasi penulis berada di daerah Cengkareng, Jakarta Barat, sehingga secara otomatis default location adalah lokasi penulis saat ini. Berdasarkan lokasi ini, maka selfpickup akan menampilkan lokasi toko yang terdekat
52 dari penulis, yaitu di (Jakarta Barat-Ace Hardware) Mall Daan Mogot dengan jarak 0.34 km dan seterusnya.
Gambar 3. 45. Selfpickup PDP Geolocation (Deny Location)
Gambar 3.45 merupakan tampilan PDP geolocation dari metode selfpickup jika customer tidak mengijinkan akses ke lokasi terkini. Dikarenakan penulis tidak mengijinkan website/mobile web ruparupa untuk mengakses lokasi terkini dari penulis, maka secara otomatis akan diambil lokasi toko terdekat dari lokasi ketersediaan pengiriman. Dalam pengujian ini, penulis mengatur lokasi pengiriman di Provinsi Banten, Kabupaten Tangerang Selatan dan Kecamatan Serpong.
Berdasarkan lokasi tersebut, maka selfpickup akan menampilkan lokasi toko terdekat, yaitu (Tangerang- Ace Hardware) Aeon BSD dan seterusnya.
53 Gambar 3. 46. Test Case Geolocation PDP Selfpickup
Gambar 3.46 adalah dokumen test case dari geolocation PDP selfpickup. Pada dokumen test case ini terdapat 4 skenario pengujian yang dibuat dan diuji oleh penulis yang mencakup pengujian dengan mengijinkan akses lokasi, tidak mengijinkan akses lokasi. Hasil dari pengujian tersebut menunjukkan bahwa geolocation sudah berhasil mendeteksi lokasi dari customer dan lokasi dari ketersediaan pengiriman namun ada beberapa kecamatan yang belum tersedia lokasinya. Selain itu terdapat notes atau catatan dari penulis pada skenario poin ke 2 yaitu melihat toko terdekat dengan metode selfpickup dengan mengijinkan akses lokasi. Pada skenario tersebut terdapat inkonsistensi dari titik lokasi terdeteksi oleh GPS, dimana titik lokasi GPS tersebut terkadang tidak akurat dan tidak sesuai dengan lokasi sebenarnya. Penjelasan dari masalah tersebut
54 dikarenakan kesalahan dari provider third party yang menjadi penyedia layanan pelacak lokasi.
d. Support Ruparupa Mobile Apps V2
Penulis diberikan task untuk kembali membantu melakukan pengujian terhadap mobile apps ruparupa V2 yang akan diluncurkan di masa mendatang. Sebagai support QA, penulis membantu main QA dalam melakukan pengujian ulang terhadap skenario yang sudah dilakukan perbaikan oleh mobile developer. Selain melanjutkan dan melakukan pengujian ulang terhadap skenario yang sudah diperbaiki, penulis juga menguji fitur-fitur lainnya. Dari hasil pengujian penulis terhadap mobile apps ruparupa v2, terdapat beberapa bugs yang ditemukan.
Gambar 3. 47. Test Case Mobile Apps V2
55 Gambar 3. 48. Bugs Found Mobile Apps V2
Gambar 3.47 merupakan dokumen test case dari support mobile apps V2. Dalam dokumen test case ini, penulis mendokumentasikan skenario, data dan hasil dari pengujian ulang terhadap skenario dan fitur-fitur yang telah diperbaiki oleh developer. Dalam dokumen test case tersebut juga mencakup hasil dari pengujian fitur-fitur lainnya yang dilakukan atas inisiatif dari penulis sendiri.
Berdasarkan hasil dari pengujian fitur yang dilakukan oleh penulis, ditemukan beberapa bugs lain yang didokumentasikan oleh penulis seperti pada gambar3.48. Dokumentasi tersebut dibuat dalam bentuk screenshot dari bugs beserta deskripsinya untuk membantu developer dalam memahami maksud dari penulis.
56 3.3.6 Minggu Keenam : Follow Up Testing Improvement TAHU-
Custom Meta Tag, Add New Scenario For Testing Improvement on Pagination TAHU Campaign, Support Mobile Ruparupa V2 Merge
a. Follow Up Testing Improvement TAHU-Custom Meta Tag Pada minggu keenam, penulis belum diberikan task baru dan hanya melanjutkan task dari minggu sebelumnya. Untuk pengujian terhadap modul custom meta tag, penulis masih melakukan follow up progress dari perbaikan dari error di minggu sebelumnya. Dari hasil follow up, sudah ada error yang diperbaiki, namun masih terdapat skenario yang masih belum bisa diperbaiki segera dikarenakan adanya issue yang disebabkan oleh adanya clash antar pekerjaan developer sehingga menyebabkan code custom meta tag menjadi terduplikat/double.
b. Add New Scenario For Testing Improvement On Pagination TAHU Campaign
Pada Task testing improvement on pagination TAHU campaign, penulis melakukan pertemuan melalui google meet untuk membahas skenario yang perlu dilakukan perbaikan dan improvement lainnya.
Dari hasil pertemuan tersebut, penulis dan developer sepakat untuk menambah sebuah skenario test case untuk pengujian waktu load saat user men-create dan publish campaign baru. Dari hasil pengujian tersebut, didapatkan hasil bahwa load time saat publish
57 campaign sudah sesuai seperti pada gambar 3.49, namun campaign yang di publish tidak muncul di dashboard, dikarenakan dashboard mengalami infinite loop sehingga diperlukan perbaikan.
Gambar 3. 49. Hasil Pengujian Load Time Publish Campaign
c. Support Ruparupa Mobile Apps V2 Merge
Pada minggu ke keenam, penulis masih bertanggung jawab sebagai QA support untuk pengujian ruparupa mobile apps yang sudah dilakukan merging dengan v1. Pada pengujian ini, mobile apps v2 dihubungkan dan menggunakan data dari production atau data sebenarnya yang digunakan oleh ruparupa untuk transaksi penjualan dan pembelian. Tujuan menggunakan data dari production adalah untuk mengetahui apakah terjadi crash jika mobile apps v2 menggunakan data dari production.
58 Hasil pengujian yang dilakuakn oleh penulis didokumentasikan kedalam test case yang terdiri dari 20 skenario seperti yang terdapat pada gambar 3.50
Gambar 3. 50. Test Case Mobile Apps V2 Merge
Gambar 3. 51. Test Case Mobile Apps V2 Merge
59 Gambar 3.50 dan 3.51 merupakan dokumen test case dari mobile apps v2 merge. Dari test case tersebut terdapat beberapa skenario yang masih terdapat bugs yang diberi tanda merah yang harus diperbaiki oleh developer. Disaat yang bersamaan penulis melakukan komunikasi dengan developer untuk menjelaskan apa saja yang harus diperbaiki. Penulis juga mendokumetasikan bugs dalam bentuk screenshot di spreadsheets seperti gambar 3.52 dan 3.53.
Gambar 3. 52. List Bugs Mobile Apps V2 Merge
Gambar 3. 53. List Bugs Mobile Apps V2 Merge
Berdasarkan list bugs diatas, developer langsung melakukan perbaikan dan memberitahukan kepada penulis jika bugs sudah
60 selesai diperbaiki untuk segera dilakukan pengujian ulang.
Berdasarkan hasil pengujian ulang terhadap bugs yang sudah diperbaiki, hasil yang didapatkan adalah pass.
3.3.7 Minggu Ketujuh : UAT Ruparupa Mobile Apps V2, Miss Ace Transaction History, Miss Ace Upgrade Member.
a. UAT Ruparupa Mobile Apps v2
Minggu ketujuh dalam periode kerja magang di PT Omni Digitama Internusa atau ruparupa, penulis sebagai QA support membantu main QA dalam menyusun dan mempersiapkan dokumen User Acceptance Test (UAT) Untuk mobile apps ruparupa v2 seperti yang ditunjukkan oleh gambar 3.54. Pada saat pertemuan UAT, main QA menjelaskan hasil dari pengujuan terhadap test case dan skenario-skenario dari mobile apps ruparupa v2 kepada para user untuk menentukan apakah hasil pengujian sudah sesuai dengan requirements yang diharapkan oleh users. Dalam pertemuan UAT, penulis membantu main QA dalam mencatat setiap feedback dan masukan yang diberikan oleh users sebagai catatan terhadap hal apa saja yang perlu diperbaiki, diubah atau ditingkatkan.
61 Gambar 3. 54. Tampilan Dokumen UAT Ruparupa V2
b. Miss Ace Transaction History
Pada minggu ketujuh, penulis bergabung dengan project Miss Ace. Miss Ace sendiri merupakan mobile apps dari Ace Hardware Indonesia. Dalam project ini, penulis diberikan task untuk melakukan testing terhadap sebuah fitur baru yang dinamakan transaction history. Fitur tersebut memiliki fungsi untuk mencatat
62 histori transaksi pembelian dan poin yang didapatkan oleh customer baik di toko offline maupun online Ace.
Gambar 3. 55. Contoh Tampilan History Transaction ACE Store Gambar 3.55 adalah contoh tampilan dari history transaksi dari Ace store. Halaman tersebut terdapat pada tab order/pesanan saya.
ACE Store mencatat setiap transaksi yang dilakukan di toko-toko offline dari Ace Hardware Indonesia yang didalamnya terdiri dari
63 lokasi toko tempat transaksi terjadi, tanggal dan waktu transaksi, jumlah transaksi dan juga poin yang didapaykan dari transaksi tersebut. Transaksi pembelanjaan ini tercatat jika customer melakukan pembelanjaan dengan menggunakan nomor member dari ACE Hardware Indonesia.
Gambar 3. 56. Contoh Tampilan History Transaction Ace Online
64 Gambar 3.56 merupakan contoh tampilan dari history transaction di ace online. Halaman ini mencatat setiap transaksi pembelian yang dilakukan oleh customer di aplikasi mobile miss ace. Cara kerja dari pencatatan ace online ini sama seperti ace offline atau ace store dimana setiap transaksi yang dilakukan oleh customer di aplikasi miss ace akan langsung tercatat kode transaksinya, tanggal dan waktu transaksi, jumlah harga, poin yang didapat saat transaksi selesai dan status order dari customer.
Gambar 3. 57. Contoh Tampilan Halaman Poin
65 Gambar 3.57 merupakan contoh dari tampilan dari halaman poin yang didapatkan oleh ocustomer. Halaman poin ini mencatat seluruh aktivitas dari poin baik dari tanggal dan waktu yang didapatkan dari transaksi pembelanjaan yang dilakukan oleh customer baik di toko offline dan online maupun mencatat penggunaan/pengurangan poin untuk digunakan berbelanja ataupun untuk diganti dengan merchandise, namun untuk saat ini halaman poin hanya bisa melakukan pencatatan terhadap penambahan poin saja sedangkan untuk pengurangan poin akan dikembangkan di masa yang akan mendatang.
Gambar 3. 58. Test Case Miss Ace History Transaction
Gambar 3.85 merupakan test dari testing miss ace history transaction. Test case diatas terdiri dari 7 skenario, dan pengujian terhadap fitur ini belum selesai dilakukan oleh penulis dikarenakan ada penambahan dan perubahan yang dilakukan terhdap fitur ini, sehingga penulis masih menunggu informasi lebih lanjut untuk fitur ini.
66 c. Miss Ace Upgrade Member
Miss ace upgrade member merupakan fitur yang masih termasuk kedalam project miss ace. Pada fitur ini, penulis melakukan pengujian untuk memastikan customer dapat melakukan registrasi/upgrade member ace di aplikasi miss ace. Untuk melakukan upgrade member, customer melakukan pembelian member ace reward di halaman profile di aplikasi miss ace, lalu setelah melakukan pembayaran, permintaan upgrade member akan langsung diproses dan setelah terupdate, maka nomor status member ace customer akan berubah dari TAM menjadi AR (Ace Reward).
Pada pengujian ini, penulis melakukan komunikasi dengan backend developer dan mobile developer dikarenakan member tidak dapat ter-upgrade setelah dilakukan pembelian.
67 3.3.8 Minggu Kedelapan : Miss Ace Transaction History, Internal
Testing RupaRupa Moapps V2 & Internal Testing Miss Ace a. Miss Ace Transaction History
Pada minggu kedelapan, penulis masih melanjutkan pengujian miss ace transaction history. Terdapat beberapa skenario pengujian yang ditambahkan oleh penulis seiring dengan testing yang dilakukan oleh penulis seperti yang ditunjukkan pada gambar 3.59.
Gambar 3. 59. Test Case Ace Transaction History
Gambar 3.59 merupakan gambar dari update test case miss ace transaction history. Pada update test case ini, terdapat skenario pengujian baru berupa penambahan status-status order yang akan berubah sesuai dengan progress dari toko. Tujuan penambahan status baru ini adalah untuk memberikan informasi kepada customer mengenai sudah sejauh mana order dari customer telah diproses oleh pihak toko ace hardware.
68 b. Internal Testing RupaRupa Moapps V2
Pada minggu kedelapan, penulis melakukan internal testing terhadap aplikasi ruparupa V2 yang telah dilakukan UAT pada minggu sebelumnya, yakni minggu ketujuh. Tujuan dilakukannya internal testing adalah untuk memastikan ruparupa moapps telah bebas dari bugs dan errors sebelum akhirnya dideploy ke playstore dan appstore. Pengujian ini dilakukan bersama dengan pihak dari mobile developer dengan metode live testing sehingga jika ditemukan bugs atau error, maka akan dilakukan perbaikan secara langsung.
Dalam melakukan internal testing ini, mobile developer mendaftarkan email dari pihak-pihak yang terlibat dalam testing ini lalu penulis diberikan sebuah link yang akan diarahkan untuk menginstall aplikasi ruparupa di playstore atau appstore sebagai internal testing beta.
Hasil dari pengujian tersebut adalah dtidak ditemukan bugs dan error pada update v2, dan feedback dari UAT pada minggu sebelumnya juga sudah ditambahkan, sehingga siap dilakukan deployment pada malam harinya.
69 c. Internal Testing Miss Ace
Pada minggu kedelapan ini, penulis melakukan internal testing terhadap aplikasi miss ace di android. Secara tahapan pengujian, hampir sama dengan internal testing untuk aplikasi ruparupa v2, namun dipengujian kali ini berfokus pada fitur push notification.
Pada pengujian ini, pihak mobile developer akan mengirimkan push notification ke aplikasi internal testing miss ace yang sudah didaftarkan email penulis didalamnya, dan penulis memastikan bahwa push notofication tersebut masuk dan isi dari notifikasi tersebut sesuai dengan apa yang dikirimkan. Selain itu, penulis akan klik notifikasi tersebut dan memastikan notifikasi tersebut diarahkan ke halaman yang telah diatur oleh tim mobile developer.
Hasil dari pengujian ini adalah semua push notification yang dikirimkan sudah berhasil diterima dan halaman yang dibuka dari notifikasi tersebut sudah sesuai dengan pengaturan dari tim mobilr developer.
3.3.9 Minggu Kesembilan : Testing & Deployment Ruparupa 5th Anniversary, Popup Image V2
Pada minggu kesembilan, penulis mendapatkan 3 task testing dimana 2 diantaranya berfokus pada persiapan ulang tahun ruparupa ke 5.
Adapaun task tersebut terdiri dari:
70 a. Testing Ruparupa 5th Anniversary
Pada minggu kesembilan, penulis diberikan task untuk melakukan pengujian terhadap landing page ruparupa 5th anniversary. Pengujian dilakukan oleh penulis pada platform android dan mobile web untuk memastikan setiap banner, voucher, CMS block pada landing page ruparupa 5th anniversary sudah diarahkan ke halaman yang benar.
Gambar 3. 60. Landing Page Ruparupa 5th Anniversary
Gambar 3.60 merupakan tampilan dari landing page ruparupa 5th anniversary pada mobile web. Dari halaman
71 landing page tersebut, penulis memastikan setiap banner dapat di click dan diarahkan ke halaman yang seharusnya. Selain itu, penulis juga mamastikan setiap voucher dapat disalin oleh customer untuk digunakan nanti. Pengujian dilakukan beberapa hari sebelum tanggal 13 dan 14 April sebelum nantinya diluncurkan pada seluruh platform ruparupa.
Gambar 3. 61. Test Case Ruparupa 5th Anniversary
Gambar 3.61 merupakan test case dari testing ruparupa 5th anniversary. Pada test case tersebut penulis dibantu oleh personel QA lainnya dan berfokus pada bugs dan errors yang ditemukan dengan tujuan untuk mempersingkat waktu dan mengejar deadline. Pada dokumen test case tersebut, terdapat informasi mengenai nama banner yang terdapat issue, link banner, deskripsi
72 issue, platform, dan keterangan untuk mengetahui apakah issue tersebut telah diperbaiki oleh developer.
Gambar 3. 62. List Bugs & Errors
Gambar 3.62 merupakan tampilan dari daftar bugs dan errors dari test case. Penulis membuat daftar ini untuk mempermudah tim developer untuk mengetahui pada bagian mana bugs dan errors terjadi. Dalam daftar tersebut, penulis lampirkan screenshot, link video dan deskripsi terkait issue yang ditemukan.
b. Deployment Ruparupa 5th Anniversary
Pada minggu kesembilan, penulis sebagi tim QA bersama dengan tim front end dan mobile bersama-sama melakukan deployment landing page ruparupa 5th anniversary yang dilakukan pada tanggal 13 april atau 1 hari sebelum hari ulang tahun ruparupa yang ke-lima pada tanggal 14 April. Diployment dilakukan pada
73 malam hari, dan rencanakan landing page tersebut akan muncul pada pukul 08:00 pada tanggal 14 April 2021.
Setelah itu penulis melakukan monitoring terhadap landing page tersebut pada hari berikutnya.
c. Popup Image V2
Pada Minggu kesembilan, penulis melakukan pengujian terhadap popup image untuk aplikasi ruparupa v2. Pengujian ini pada dasarnya sama seperti pengujian popup image yang dilakukan oleh penulis pada minggu ketiga, namun pada pengujian kali ini penulis melakukan testing untuk mobile apps ruparupa version 2.0.
3.4 Kendala
Selama penulis melaksanakan proses kerja magang sebagai Quality Assurance intern di PT Omni Dogitama Internusa (Ruparupa), terdapat beberapa kendala yang dihadapi oleh penulis seperti:
1. Terkendala-nya kegiatan kerja magang dalam hal interaksi, komunikasi dan pemahaman sesama tim dalam kegiatan pengujian sebuah project dikarenakan tidak ada tatap muka secara langsung akibat adanya pandemi COVID-19.
2. Device yang didapatkan oleh penulis dalam pengujian mobile masih berupa device android sehingga penulis mengalami kesulitan dalam melakukan pengujian untuk fitur di ios.
74 3. Belum tersedianya dokumentasi terkait alur dan proses kerja dari sebuah fitur dan pengujian sehingga penulis kesulitan dalam memahami alur kerja sebuah fitur selama proses testing.
3.5 Solusi Atas Kendala
Berdasarkan penjabaran dan penjelasan diatas, maka solusi dari kendala- kendala tersebut adalah sebagai berikut:
1. Setiap seminggu sekali penulis pergi ke HO (Head Office) dari PT Omni Digitama Internusa (tentatif) untuk berkumpul dan bekerja besama tim QA/QC Squad dan menggunakan media komunikasi dalam bentuk teks maupun video conferencing seperti whatsapp, discord dan google meet dalam berkomunikasi dan melakukan briefing antara penulis dan tim lain yang terlibat dalam sebuah project.
2. Berkoordinasi dengan personel QA lain yang memiliki device ios dalam pengujian fitur-fitur yang memerlukan device ios.
3. Aktif bertanya kepada tim-tim yang terlibat dalam sebuah project seperti product manager/product specialist, mobile developer, backend, frontend, infrastructur, dan QA lead terkait proses dan alur kerja dan bagaimana cara pengujian sebuah fitur yang akan dilakukan testing.
