9
BAB 3
PELAKSANAAN KERJA MAGANG
3.1 Kedudukan dan Koordinasi
Dalam pelaksanaan kerja magang di paola.id, penulis berkedudukan sebagai Quality Assurance Engineer (QA/ QE) Intern di bagian tim Development, dengan pembimbing lapangan langsung diawasi oleh Bayu Kresno Prasetyo, selaku CTO dalam tim Development di paola.id. Pembimbing yang bersangkutan berperan dalam mengawasi, memberi arahan, masukan, dan informasi mengenai alur kerja yang harus dikerjakan tim QA dalam melakukan proses pengujian dan mengembangkan script automated test pada situs Front Office dan Back Office paola.id.
3.2 Tugas yang Dilakukan
Cakupan kerja magang yang diberikan adalah sebagai berikut:
1) Merancang test case scenario berdasarkan user story yang telah dibuat sebelumnya.
2) Melakukan pengujian/ manual testing terhadap pembangunan situs e- commerce paola.id.
3) Membuat dan mengembangkan script automated test berdasarkan test case scenario yang telah dibuat.
4) Melakukan pelaporan jika menemukan bug dan turut berkolaborasi dengan tim development untuk menemukan sumber bug dan mencari solusi yang tepat untuk menyelesaikannya.
10 5) Mengikuti kegiatan sprint planning dan sprint review yang diadakan setiap
dua minggu sekali.
3.3 Uraian Pelaksanaan Kerja Magang 3.3.1 Proses Pelaksanaan
Dalam perancangan automated test, diperlukan beberapa perangkat lunak dan perangkat keras. Berikut adalah perangkat lunak yang digunakan dalam proses penyusunan script automated test:
1. Webstorm 2. Google sheets 3. Google chrome 4. Cypress
5. Slack 6. Trello 7. Swagger
Adapun perangkat keras yang digunakan yakni laptop dengan spesifikasi sebagai berikut:
1. Processor: AMD A12-9700P RADEON R7 2. RAM: 8GB
3. Sistem Operasi Laptop: Ubuntu 20.04 4. Sistem penyimpanan laptop: 1 TB HDD
3.3.2 Alur Kerja dan Framework yang Digunakan
Pengenalan alur kerja di paola.id dilakukan pada minggu pertama kerja magang. Pada minggu tersebut, diperkenalkan aplikasi-aplikasi pendukung kegiatan kerja perusahaan, seperti aplikasi slack untuk media komunikasi, trello sebagai media manajemen task kolaborasi kerja tim, dan sebagainya. Tim
11 development paola.id merekomendasikan untuk menggunakan Ubuntu sebagai Operating System (OS) dalam proses development. Maka dari itu, pada minggu pertama dilakukan proses instalasi Ubuntu untuk mempermudah proses pekerjaan.
Sebelum menyusun script automated test, perlu dibuat dokumen yang berisi serangkaian tes sebagai acuan untuk melakukan pengujian/ testing. Dokumen ini disebut dengan test case. Test case menggambarkan input, tindakan, atau respon yang diharapakan untuk menentukkan fitur berjalan dengan baik dan benar.
Penyusunan test case sudah mulai dilakukan di minggu pertama kerja magang.
Dalam penyusunan test case, terdapat dua skenario, yaitu positive case dan negative case. Positive case adalah cara untuk memeriksa apakah fitur melakukan sesuai yang diharapkan, dengan memberikan data yang valid sebagai input.
Sebaliknya negative case memberikan memberikan data yang tidak valid sebagai input.
Kemudian tahap selanjutnya adalah penyusunan script automated test.
Framework yang digunakan untuk automated test di paola.id adalah Cypress dengan bahasa pemrograman berbasis Javascript.
Cypress adalah salah satu perangkat lunak yang digunakan untuk automation testing yang bersifat open source. Jenis pengujian yang dapat dilakukan oleh cypress adalah end to end tests, integration test, serta unit test. Cypress dapat memudahkan QA dalam mengatur skenario tes, menyusun tes, serta menjalankan tes menjadi lebih cepat, mudah, dan handal.
Script automated test digunakan untuk keperluan regression test di paola.id.
Regression test yang dijalankan bertujuan untuk memastikan agar semua fitur yang telah diintegrasikan, berjalan dengan baik dan benar. Dikarenakan semakin
12 banyaknya fitur-fitur baru yang dikembangkan, proses pengujian yang dilakukan akan semakin banyak, dan akan memakan banyak waktu jika dilakukan pengujian secara manual. Maka dari itu, paola.id menggunakan Cypress untuk mempermudah dan mempercepat proses pengujian secara otomatis.
3.3.3 Perancangan Sistem A. Flowchart
Selama periode empat bulan kerja magang, terdapat 16 script automated test yang telah dirancang. Berikut merupakan daftar gambar flowchart dari rangkaian script automated test yang telah dirancang.
A.1 Registrasi
Setiap akun yang akan digunakan untuk melakukan pengujian merupakan akun palsu menggunakan layanan email sekali pakai, yaitu malinator. Kemudian nama dari email tersebut akan dibuat secara acak dan otomatis menggunakan npm faker. Setelah email sudah dibuat, maka akan menghasilkan email yang valid untuk dilakukan registrasi. Untuk kata sandi telah ditetapkan secara konstan, sehingga tidak perlu dibuat acak oleh npm faker.
Setelah registrasi sukses, kunjungi mailinator untuk melakukan aktivasi akun. Lakukan pengecekan terhadap body email, apakah email sudah sesuai dengan akun yang telah diregistrasi. Kemudian klik button aktivasi dengan cara melakukan request melalui cypress. Cek apakah akun sudah berhasil teraktivasi dengan cara melihat feedback dari sistem yang menandakan akun sudah diaktivasi.
13 Skenario ini merupakan positive case dari pengujian register, yang dapat dilihat pada Gambar 3.1. Sementara negative case terdapat pada Gambar 3.2 dan Gambar 3.3.
Gambar 3. 1 Flowchart positive case registrasi
14 Gambar 3. 2 Flowchart negative case
invalid email dan kata sandi Gambar 3. 3 Flowchart
negative case input dengan email yang terverifikasi
15 A.2 Masuk Akun
Akun yang telah diregistrasi sebelumnya akan disimpan ke dalam file accounts.json yang telah di buat di dalam folder cypress. Masuk akun untuk pengujian ke situs paola.id, menggunakan email dan kata sandi yang didapatkan dari file tersebut. Berikut flowchart automated test untuk masuk akun.
Pada gambar 3.4, terdapat tiga flowchart yang merupakan skenario negative case dari automated test masuk akun. Ketiga skenario tersebut diharapkan akan menghasilkan toast error dan pengguna tidak dapat masuk akun.
Gambar 3.4 bagian (a), menunjukkan skenario dimana automated test melakukan input format email yang salah, seperti format email tanpa ‘@’ atau tanpa domain, dan input valid pada kata sandi dengan input enam karakter. Skenario ini diharapkan akan muncul toast error dan pengguna tidak dapat masuk akun. Gambar 3.4 bagian (b), menunjukkan skenario dimana automated test melakukan input format email yang benar dan input kata sandi yang salah untuk email tersebut.
Gambar 3.4 bagian (c), menunjukkan skenario dimana automated test melakukan input yang salah pada email dan kata sandi.
16 Gambar 3. 5 Flowchart positive
case masuk akun Gambar 3. 4 Flowchart negative case input
invalid email dan kata sandi (a
)
(b) (c)
17 A.3 Navigasi Kategori
Dalam situs paola.id, terdapat navigasi kategori atau navigation bar yang berisi daftar dari parent kategori yang ada. Pengujian dilakukan dengan melakukan perulangan untuk klik setiap kategori, dan mengecek apakah href dari kategori tersebut sudah sesuai atau belum. Untuk menampilkan child kategori, perlu menggerakan kursor ke arah navigation bar. Jika terdapat child kategori, maka container untuk daftar child kategori akan muncul. Jika tidak terdapat child, maka container tidak akan muncul.
Gambar 3. 6 Flowchart modul navigasi kategori
Gambar 3. 7 Flowchart navigasi kategori
Start
End Start
18 A.4 Header
Header adalah bagian teratas di situs paola.id. Header berisi fitur pencarian produk, keranjang belanja, serta username dropdown yang berisikan profil, daftar alamat, daftar riwayat pesanan, wishlist, dan button untuk keluar.
Terdapat tiga flowchart di dalam automated test header pada gambar 3.8.
Pada gambar 3.8 bagian (a), menunjukkan skenario dimana pengguna masuk akun terlebih dahulu dan kemudian klik keranjang belanja. Hasilnya diharapkan pengguna dapat menuju ke halaman keranjang belanja, dan apabila user klik button home, maka pengguna dapat diarahkan ke halaman utama.
Gambar 3.8 bagian (b), menunjukkan skenario dimana pengguna tidak masuk akun terlebih dahulu, dan klik keranjang belanja. Hasilnya diharapkan pengguna tidak dapat langsung masuk ke halaman keranjang belanja, dan modal untuk masuk akun akan muncul.
Gambar 3.8 bagian (c), menunjukkan skenario dimana pengguna menambahkan produk ke keranjang belanja. Dalam automated test, dilakukan pembuatan produk terlebih dahulu yang dikhususkan untuk dilakukan pengujian.
Pembuatan produk dapat dilakukan di bagian Back Office/ halaman admin.
Pembuatan produk menggunakan function yang disebut dengan doAddProduct(productName) yang terdapat pada gambar 3.11. Setelah produk dibuat, kemudian mengunjungi halaman Front Office dan masuk akun terlebih dahulu untuk mengakses halaman keranjang belanja. Script kemudian melakukan pencarian terhadap produk yang telah dibuat dengan function doSearchAndVerifyFound(productName) yang terdapat pada gambar 3.13.
Selanjutnya menambahkan produk ke dalam keranjang, dan diharapkan toast
19 success akan muncul, yang menandakan produk sukses ditambahkan ke keranjang belanja. Terakhir, produk yang sebelumnya telah dibuat untuk pengujian, akan dihapus dengan mengunjungi Back Office dan script menjalankan function doDeleteProduct(productName).
Gambar 3. 8 Flowchart header bagian keranjang belanja (a)
(b)
(c) (b)
(c)
20 Gambar 3.9 menunjukkan skenario dimana script automated test mengakses seluruh menu yang ada di username dropdown. Diharapkan seluruh menu dapat diakses dan memiliki url yang benar.
Gambar 3. 9 Flowchart username dropdown
21 Gambar 3.10 menunjukkan skenario dimana script automated test menambahkan produk ke dalam wishlist. Seperti pada flowchart pada gambar 3.8 bagian (c), produk yang akan dilakukan pengujian dibuat terlebih dahulu di Back Office dengan function doAddProduct(productName). Kemudian mengunjungi halaman Front Office dan menambahkan produk ke wishlist. Diharapkan produk tersebut tersedia di halaman wishlist.
Gambar 3. 10 Flowchart wishlist
22
Gambar 3.11 menunjukkan flowchart function
doAddProduct(productName) untuk menambahkan produk di Back Office/
halaman admin. Function ini memiliki parameter productName yang berfungsi untuk parameter input nama produk yang akan dibuat. Script akan klik menu untuk ke halaman produk dan menambahkan produk dengan input informasi produk seperti nama, harga, jumlah stok, dan berat produk. Diharapkan button submit akan menyala/ enabled, dan ketika diklik, akan muncul toast success yang menandakan jika produk telah berhasil dibuat.
Gambar 3. 11 Flowchart function doAddProduct(productName)
Start
End Start Start
23
Gambar 3.12 menunjukkan flowchart function
doDeleteProduct(productName) untuk menghapus produk di Back Office. Function ini memiliki parameter productName yang berfungsi untuk parameter input nama produk yang akan dibuat. Daftar produk ditampilkan dengan tabel, sehingga jika ingin menghapus produk, maka script akan mencari produk tersebut dan menyimpan jumlah kolom di tabel yang berisi nama produk yang dicari. Jumlah kolom dari produk yang dicari, kemudian akan dijadikan acuan untuk dilakukan perulangan dalam menghapus produk. Diharapkan semua produk telah terhapus dan sudah tidak tersedia.
Gambar 3. 12 Flowchart function doDeleteProduct(productName)
Start
End Start
Start
24
Gambar 3.13 menunjukkan flowchart function
doSearchAndVerifyFound(productName) untuk mencari produk yang ada di halaman Front Office. Function ini memiliki parameter productName yang berfungsi untuk parameter input nama produk yang akan dicari. Ketika input nama produk yang akan dicari, maka script akan menyimpan semua nama produk yang tersedia dan menghasilkan $element dari produk yang ada. Jika $element yang ada sama dengan produk yang dicari, maka script harus memastikan kembali bahwa
$element tersebut sama dengan nama yang dicari. Jika tidak sama, maka akan menghasilkan log bahwa produk tidak ditemukan/ $element yang ada tidak sama dengan nama produk.
Gambar 3. 13 Flowchart function doSearchAndVerifyFound(productName)
Start
End Start Start
25 A.5 Incomplete Origin
Dalam membuat suatu produk yang memiliki origin, wajib input provinsi, kota, dan kecamatan dari produk tersebut. Pengujian ini merupakan skenario untuk negative case, dimana automated test disusun hanya melakukan input provinsi dan kota saja sehingga diharapkan toast error akan muncul.
Pada gambar 3.14 terdapat tiga bagian dari flowchart incomplete origin.
Bagian (a) menunjukkan flowchart ketika membuat produk dengan hanya input provinsi untuk origin. Bagian (b) menunjukkan flowchart ketika membuat produk dengan hanya input provinsi dan kota untuk origin. Terakhir, bagian (c) menunjukkan flowchart ketika mengubah produk yang sudah ada origin, dengan menghapus kecamatan dari produk tersebut.
26 Gambar 3. 14 Flowchart incomplete origin
(a) (b)
(c)
27 A.6 Hapus Origin Produk
Pengujian ini akan menyunting produk yang memiliki origin, untuk kemudian dihapus origin dari produk tersebut. Origin untuk produk di paola.id bersifat opsional, sehingga jika origin dihapus, tidak akan muncul error.
Gambar 3. 15 Flowchart hapus origin
28 A.7 Multi Origin
Produk-produk yang ditawarkan di situs paola.id berasal dari berbagai macam wilayah. Produk tersebut tentunya memiliki biaya ongkos kirim berdasarkan wilayah, dan sesuai dengan pilihan layanan kurir yang dipilih. Dalam flowchart di bawah ini akan melakukan pengujian untuk melakukan pesanan dua produk dari wilayah yang berbeda. Diharapkan biaya ongkos kirim benar dan sesuai dengan biaya yang telah ditetapkan.
Gambar 3. 16 Flowchart multi origin
29 A.8 Subkategori
Pengujian ini akan membuat parent kategori. Kemudian suatu parent kategori dapat memiliki subkategori. Jika parent kategori memiliki subkategori, maka expand button akan muncul, yang dimana jika diklik akan menampilkan daftar subkategori yang ada.
Gambar 3. 17 Flowchart subkategori
30 A.9 Kupon
Kupon di paola.id dapat dibuat khusus untuk beberapa pengguna. Jika pengguna menggunakan kupon untuk pembeliannya, maka harga produk akan berkurang otomatis sesuai dengan potongan diskon yang telah ditentukan pada kupon tersebut. Perlu diperhatikan bahwa, selama pembuatan kupon, diharapkan terdapat warning berupa error toast jika admin input harga minimal produk lebih besar dari harga diskon.
Pada gambar 3.18 merupakan gambaran flowchart untuk kupon yang terbagi menjadi empat bagian. Bagian (a) merupakan skenario dimana script membuat kupon di Back Office, dan dibuat khusus untuk satu pengguna. Kemudian mengunjungi halaman Front Office, dan melakukan checkout order dengan menggunakan kupon untuk akun pengguna yang tersebut. Diharapkan kupon berhasil untuk diterapkan.
Bagian (b), (c), dan (d) menjukkan skenario negative case. Pada bagian (b), script akan melakukan input harga minimal diskon lebih besar dari minimal harga pembelian. Hasilnya diharapkan kupon gagal dibuat dan error toast akan muncul.
Bagian (c) menunjukkan skenario dimana kupon dibuat dengan syarat minimal pembelian dengan harga 100 ribu dan melakukan checkout order dengan produk seharga 10 ribu. Diharapkan kupon tidak bisa digunakan dan error toast akan muncul.
Terakhir, bagian (d) menunjukkan skenario dimana kupon dibuat dengan stok nol. Sehingga ketika kupon diterapkan ketika checkout order, maka error toast akan muncul dan kupon tidak bisa digunakan.
31 Gambar 3. 18 Flowchart kupon
(a)
(b) (c) (d)
32 A.10 Laporan Keuangan
Pada halaman admin di situs back office paola.id, terdapat ringkasan mengenai laporan keuangan. Admin dapat mengunduh file laporan penjualan, serta dapat melihat grafik penjualan. Grafik penjualan dapat diatur berdasarkan bulan dan tahun, dan dapat melihat nilai penjualan per minggu. Dalam automated test di bawah ini akan mengunduh file laporan keuangan dengan cara melakukan request melalui API.
Pada gambar 3.19 merupakan gambaran flowchart yang terbagi menjadi dua bagian. Bagian (a) merupakan skenario dimana script mengunduh file laporan keuangan. Dalam laporan keuangan, terdapat button yang digunakan untuk mengunduh file laporan. Button tersebut memiliki data-url yang berisi url file yang akan berguna untuk request ke API. Untuk melakukan request ke API, diperlukan masuk akun admin terlebih dahulu untuk mendapatkan token. Kemudian jika API merespon dengan status 200, request mengunduh file dengan memberikan payload berupa data-url yang telah disimpan. File tersebut kemudian dicek ukurannya harus lebih besar dari 0 MB dan cek file tersebut harus tidak boleh kosong.
Pada bagian (b) menunjukkan skenario untuk mengecek grafik penjualan.
Script pada awalnya harus mengecek apakah terdapat penjualan pada bulan ini. Jika terdapat penjualan, maka akan mengecek apakah pada bulan minggu ini terdapat penjualan atau tidak. Jika pada minggu ini terdapat penjualan, maka script akan menyimpan total penjualan yang ada, dan akan melakukan checkout order.
Diharapkan jika telah melakukan order, maka jumlah total penjualan akan bertambah. Jika bulan ini atau minggu ini tidak tersedia, maka script akan
33 mengarahkan langsung untuk melakukan checkout order. Diharapkan jumlah total penjualan akan bertambah.
Gambar 3. 19 Flowchart laporan keuangan
(a) (b)
34 A.11 Kurir Paxel
Salah satu layanan kurir yang disediakan oleh situs e-commerce paola.id adalah Paxel. Dalam automated test ini menggunakan API untuk mengecek apakah biaya ongkos kirim dan total biaya yang dikirimkan dari API oleh Back End, telah sesuai dengan yang ditampilkan oleh Front End di Front Office. Tahapan dari awal sampai melakukan checkout memiliki urutan yang telah dirancang oleh Back End dan dapat dilihat di Swagger.
Tahapan awal adalah melakukan request masuk akun admin melalui API.
Kemudian membuat tiga produk dengan origin Jakarta, Tangerang, dan Bogor. Jika status menandakan 200, maka akan menghasilkan id dari masing-masing produk tersebut. Selanjutnya melakukan request untuk masuk akun sebagai kustomer.
Masukkan ketiga produk yang sudah dibuat dengan request API dengan payload id ketiga produk tersebut. Setelah sukses, request untuk menambahkan alamat baru dan akan menghasilkan id untuk digunakan sebagai alamat pengiriman.
Tahap selanjutnya memiliki kurir paxel sebagi layanan kurir, dan akan menghasilkan biaya ongkos kirim dan total harga produk. Tahapan sampai ini merupakan tahapan untuk pengujian API, selanjutnya akan melakukan pengujian secara tampilan, dengan mengakses Front Office untuk mengecek kesesuaian harga ongkos kirim dan total harga yang tertera. Kemudian melakukan request API lagi untuk melakukan checkout.
35 Gambar 3. 20 Flowchart kurir paxel
36 A.12 Produk Slug
Untuk meningkatkan kualitas Optimisasi mesin pencari atau Search Engine Optimization (SEO), situs paola.id menghadirkan fitur produk slug. Dimana jika pengguna klik produk detail, URL dari produk tersebut berdasarkan slug dari nama produk. Misalnya, jika nama produk adalah Hampers Kesehatan, maka slug dan URL dari produk tersebut adalah ‘/product/hampers-kesehatan’. Pada gambar 3.21 bagian (a) menunjukkan flowchart dalam pembuatan produk, dan untuk mengkonversikan nama produk ke dalam huruf kecil, dan menggantikan spasi dan karakter dengan tanda strip (‘-‘). Jika terdapat produk yang sama, maka slug akan menambahkan postfix ‘-2’, seperti ‘/product/hamperssanity-kesehatan-2’ yang digambarkan pada flowchart gambar 3.21 bagian (b).
Gambar 3. 21 Flowchart produk slug
(a) (b)
37 A.13 Tampilan Mobile
Dalam membangun sebuah situs, paola.id memperhatikan kualitas responsive dari situs yang dikembangkan. Berikut merupakan flowchart yang menggambarkan tampilan mobile untuk logo media sosial dan banner. Semua logo media sosial dibagian bawah situs harus ditampilkan, dan memastikan URL dari masing-masing logo tersebut benar. Sementara banner di tampilan mobile, harus memiliki ratio 3.22340425532.
Gambar 3. 22 Flowchart tampilan mobile
38 A.14 Produk Preorder
Beberapa produk yang dijual di situs paola.id memiliki status preorder.
Produk yang memiliki status preorder wajib memiliki keterangan mengenai durasi preorder yang menggambarkan durasi hari sampai produk tersebut akan siap dikirim. Stok untuk produk preorder bersifat tak terhingga, sehingga automated test menyusun skenario dimana melakukan order dengan kuantitas produk yang cukup banyak.
Gambar 3. 23 Flowchart produk preorder
39 A.15 Zoom Image Gallery
Situs paola.id memiliki fitur untuk memperbesar atau zoom-in gambar di galeri produk. Berikut flowchart untuk automated test zoom galeri produk.
Gambar 3. 24 Flowchart zoom image gallery
40 A.16 Service Fee
Salah satu metode pembayaran yang disediakan oleh situs e-commerce paola.id adalah metode pembayaran dengan sistem verifikasi otomatis. Jika pengguna memilih jenis metode ini, maka akan terdapat biaya tambahan berupa biaya layanan (service fee). Biaya layanan ini sudah ditentukan, dan dilakukan perhitungan oleh Back End. Automated test akan melakukan pengecekan apakah biaya layanan yang dikirimkan sesuai dengan ketentuan.
Gambar 3. 25 Flowchart service fee
41 B. Test Case
Berikut merupakan potongan beberapa test case yang telah disusun sebelum script automated test. Test case yang ditampilkan di bawah ini hanya sebagian dari keseluruhan test case yang telah dibuat.
B.1 Registrasi
Dibawah ini terdapat test case untuk registrasi dengan potongan dua skenario test case. Skenario pertama menunjukan positive case diamana melakukan registrasi dengan input yang valid. Skenario dua menunjukkan negative scenario untuk input format email yang salah. Hasil yang diharapkan berada pada kolom expected result. Jika hasil sudah sesuai, maka akan ditulis as expected pada kolom actual result dan warnai kolom test result dengan warna hijau.
Gambar 3. 26 Potongan test case untuk registrasi
42 B.2 Masuk Akun
Di bawah ini terdapat test case untuk masuk akun dengan potongan dua skenario test case. Skenario pertama menunjukan positive case diamana masuk akun dengan input yang valid. Skenario dua menunjukkan negative scenario untuk input format email yang salah. Hasil yang diharapkan berada pada kolom expected result. Jika hasil sudah sesuai, maka akan ditulis as expected pada kolom actual result dan warnai kolom test result dengan warna hijau.
Gambar 3. 27 Potongan test case untuk masuk akun
43 B.3 Navigasi Kategori
Di bawah ini merupakan test case dari navigasi kategori dengan hasil pengujian dinyatakan benar dan berhasil sesuai dengan harapan.
B.4 Header
Di bawah ini merupakan potongan test case dari header untuk fitur profil dan keranjang belanja. Semua hasil pengujian dinyatakan sesuai dengan ekspektasi.
Gambar 3. 28 Potongan test case untuk navigasi kategori
Gambar 3. 29 Potongan test case untuk header
44 3.3.4 Implementasi
Setiap dua minggu sekali, setelah diadakannya sprint review, QA akan menjalankan semua script automated test yang telah dirancang. Setelah semua proses pengujian telah selesai, hasil automated test akan disimpan di file mochareports.html. Apabila suatu tes berhasil, maka warna indikator akan berwarna hijau dengan tanda centang. Apabila gagal, maka warna indikator akan berwarna merah dengan tanda silang. Selain itu, terdapat keterangan waktu yang ditempuh selama automated test dijalankan.
File html ini kemudian akan dikonversikan ke dalam format pdf, yang nantinya akan dilaporkan ke tim development. Jika terdapat error, QA harus melakukan cross-check terhadap hasil automated test dengan cara melakukan pengujian ulang secara manual, dan menganalisis apakah error ini dihasilkan dari script automated test, atau memang terdapat bug di dalam sistem. Apabila bug berasal dari skrip automated test, maka harus dilakukannya bug fix code di automated test. Apabila bug berasal dari sistem, maka QA wajib melaporkan kepada tim development, bersamaan dengan keterangan jelas cara menemukan bug tersebut.
45
1. Hasil pengujian registrasi
Semua test case yang ada di automated test registrasi telah berhasil dan sesuai ekspektasi.
2. Hasil pengujian masuk akun
Semua test case yang ada di automated test masuk akun telah berhasil dan sesuai ekspektasi.
Gambar 3. 30 Log report automated test registrasi
Gambar 3. 31 Log report automated test masuk akun
46
3. Hasil pengujian Header
Semua test case yang ada di automated test header telah berhasil dan sesuai ekspektasi.
4. Hasil pengujian Navigasi Kategori
Hasil pengujian gagal karena terdapat bug pada sistem. Dimana jika diklik kategori selanjutnya, akan menampilkan URL yang tidak sesuai.
Gambar 3. 32 Log report automated test header
Gambar 3. 33 Log report automated test navigasi kategori
47
5. Hasil pengujian hapus origin
Semua test case yang ada di automated test hapus origin telah berhasil dan sesuai ekspektasi.
6. Hasil pengujian incomplete origin
Semua test case yang ada di automated test incomplete origin telah berhasil dan sesuai ekspektasi.
7. Hasil pengujian multi origin
Semua test case yang ada di automated test multi origin telah berhasil dan sesuai ekspektasi.
Gambar 3. 34 Log report automated test hapus origin
Gambar 3. 35 Log report automated test incomplete origin
Gambar 3. 36 Log report automated test multi origin
48 8. Hasil pengujian subkategori
Semua test case yang ada di automated test subkategori telah berhasil dan sesuai ekspektasi.
9. Hasil pengujian kupon
Semua test case yang ada di automated test kupon telah berhasil dan sesuai ekspektasi.
Gambar 3. 37 Log report automated test subkategori
Gambar 3. 38 Log report automated test kupon
49 10. Hasil pengujian laporan keuangan
Semua test case yang ada di automated test laporan keuangan telah berhasil dan sesuai ekspektasi.
11. Hasil pengujian kurir paxel
Terdapat hasil pengujian yang gagal, dikarenakan terdapat bug di bagian Back End untuk payload melakukan order dengan layanan kurir paxel.
Gambar 3. 39 Log report automated test laporan keuangan
Gambar 3. 40 Log report automated test kurir paxel
50 12. Hasil pengujian produk slug
Semua test case yang ada di automated test produk slug telah berhasil dan sesuai ekspektasi.
13. Hasil pengujian tampilan mobile
Semua test case yang ada di automated test tampilan mobile telah berhasil dan sesuai ekspektasi.
Gambar 3. 41 Log report automated test produk slug
Gambar 3. 42 Log report automated test tampilan mobile
51 14. Hasil pengujian produk preorder
Semua test case yang ada di automated test produk preorder telah berhasil dan sesuai ekspektasi.
15. Hasil pengujian zoom image gallery
Semua test case yang ada di automated test zoom image gallery telah berhasil dan sesuai ekspektasi.
Gambar 3. 43 Log report automated test produk preorder
Gambar 3. 44 Log report automated test zoom image gallery
52 16. Hasil pengujian service fee
Semua test case yang ada di automated test service fee telah berhasil dan sesuai ekspektasi.
3.3.5 Kendala yang Dihadapi
Selama periode empat bulan kerja magang, banyak hal baru yang dipelajari, serta terdapat beberapa rintangan dan kendala yang dihadapi. Secara keseluruhan, berikut kendala-kendala yang dihadapi:
1. Tidak ada senior khusus di bidang QA. Semua anggota tim QA diisi oleh mahasiswa magang, yang dimana belum ada keahlian khusus di bidang QA. Hal ini terkadang membuat kinerja QA kurang profesional dan banyak bagian penting yang terlewatkan.
2. Kurangnya komunikasi tim dari Back End mengenai perubahan payload API dan Front End mengenai perubahan data test id yang dijadikan acuan untuk menyusun script automated test.
3. Menjalankan semua script automated test di laptop masing-masing dengan performa yang tidak stabil dan akan memakan banyak waktu selama kurang lebih dua jam. Hal ini menjadi kendala karena jika melakukan aktivitas
Gambar 3. 45 Log report automated test service fee
53 selain menjalankan automated test, maka performa automated test menjadi tidak stabil, dan kemungkinan besar hasil tes akan gagal.
3.3.6 Solusi Atas Kendala yang Ditemukan
Berikut merupakan solusi yang ditemukan berdasarkan ketiga uraian kendala yang dihadapi selama kerja magang:
1. Solusi dari kendala pertama adalah karena belum adanya senior QA sampai saat ini, sementara anggota QA mulai berinisiatif dan mencari tahu lebih dalam aspek-aspek apa saja yang harus diperhatikan.
2. Bernisiatif untuk berdiskusi atau bertanya langsung kepada tim development jika dilihat terdapat perubahan fitur. Jika perubahan tersebut mempengaruhi payload API atau data test id, maka QA harus menanyakan bagian-bagian mana saja yang diubah atau ditambahkan.
3. Diadakannya perangkat khusus yang mendukung, untuk menjalankan seluruh automated test. Hal ini diharapkan akan membuat performa automated test berjalan dengan maksimal dan menghindari kemungkinan gagal akibat performa perangkat yang tidak stabil.
