Kenal Asep?

Oke, mungkin bukan nama sebenarnya, tapi lo pasti kenal orang seperti dia, atau mungkin lo sendiri sebenarnya dia

Jadi Asep adalah seorang software tester berpengalaman 8 tahun, berkarir sejak masa keemasan dunia Startup di Indonesia, dia tipe tester yang bisa ngendus bug cuma dari sekilas baca requirement PRD, tipe yang suka bikin developer agak deg-degan pas presentasi, karena Asep pasti nemu sesuatu, “kok bisa kepikiran ya?” gumam Dev, dia tipe QA yang kalo disuruh bikin test case, malah requirement nya yang perlu di tinjau ulang.

Exploratory testing adalah jurus andalan si Asep, dia bangga dengan kemampuan itu, dan emang sudah seharusnya merasa bangga dengan keahlian di atas rata-rata QA lainnya. ketika di kantor mulai rame ngomongin AI buat testing, reaksi Asep cukup bisa ditebak:

“AI emang bisa nemuin bug yang ga ada di requirement? AI mana bisa nemuin bug aneh-aneh”

”Emang komputer punya perasaan bedain bagus dan jelek?”

Bukan dengan nada marah, bukan juga defensif, lebih ke… meremehkan sih. Kayak orang yang nguping obrolan nasi goreng mana paling enak di gofood, tapi dia tau nasi goreng mahakarya mang Udin langganannya jelas ga ada yang bisa ngalahin.

Zona nyaman yang terasa seperti sangkar

Bisa aja bilang “ga mungkin ada yang lebih enak” dari nasi goreng mang Udin, bisa jadi emang dia maen nya kurang jauh, atau emang “belum muncul” tukang nasi goreng baru eks chef hotel misalkan.

Balik lagi ke Asep, tentu punya alasan kuat untuk skeptis, karena testing itu perlu keahlian di luar paham teknis, testing butuh intuisi, butuh pemahaman bisnis, pengalaman bertahun-tahun diskusi dengan user, memahami keluhan mereka, menerjemahkan itu semua jadi skenario non-functional test.

Tentu saja nggak akan cukup dituliskan dalam jendela chatbox dengan AI.

Artificial Intelligence (AI) cuma bisa proses data, AI nggak pernah duduk di meeting sama Product Owner yang frustasi karena fitur baru bikin crash di Production.

AI nggak pernah denger komplain CEO jam 11 malem.

Gw yakin Asep bukan satu-satunya yang mikir begini.

Di dunia QA sendiri, sentimen yang sama beredar, falsafah yang banyak diyakini orang:

Manual testing itu ada seninya, sebuah craft dari hasil latihan, dan seni nggak bisa di-automate ~ceunah

Tapi ada satu kritik kecil dengan arguman ini.

Nggak ada yang bilang AI mau menggantikan seninya, yang sedang terjadi sekarang justru jauh lebih menarik dari itu

Meeting yang mengubah segalanya

Dua bulan setelah Asep nge-dismiss AI, ada review akhir tahun 2025, presentasi per tim, metrics dan achievements. Asep duduk di barisan kedua, laptop terbuka setengah, telinga terbuka penuh mendengarkan paparan Lead squad lain.

Tim Platform maju, mereka memamerkan adopsi AI-assited testing, Lead Developernya, katakanlah namanya Jajang, presentasi dengan santai, nggak dramatis, nggak heboh, cuma share data aja:

“Bug detection rate kita improve signifikan di quarter akhir ini”

Asep berhenti ngetik, menghiraukan jendela chat di Slack.

Jajang melanjutkan “Karena kita bisa explore lebih banyak area yang sebelumnya nggak sempet kita sentuh, AI bantu generate initial test scenarios dari Unit test sampe Integration test, kita tinggal refine dan explore lebih dalam mana yang harus sesuai dengan konteks feature tersebut”

Pernyataan itu nempel di kepala si Asep sepanjang sisa meeting, bukan (cuma) karena datanya mengesankan, tapi menemukan setitik celah dalam terowongan gelap yang bisa dilalui cahaya, ada gambaran visual mengenai arah yang harus dilalui

“Gimana caranya?” jadi kaset kusut dikepalanya, Jajang nggak bilang AI menggantikan manual tester di timnya, dia bilang AI bantu timnya explore lebih banyak.

Pulang kantor, Asep langsung buka laptop di meja makan, biasanya nyalain PS maen EAFC 26, tapi malam itu dia buka Google.

lalu menekan Enter

Subscribe now

Tahap Pertama: Dinding denial yang mulai retak

Belum lama nonton Netflix “Tinggal Meninggal” disitu baru denger yang namanya fase pertama dari grief itu denial. Tapi ini bukan grief, ini lebih kayak… denial yang mulai terkikis rasa penasaran

“AI generate 100 test case sekaligus? ngapain banyak-banyakan klo testnya generik dan dangkal”

Baca lagi, ternyata ada yang pakai konteks dari user story dan historical bug data.

“Oke, tapi pasti AI nggak ngerti edge case yang spesifik”

Baca lagi. Ada yang gabungin AI suggestion dengan domain knowledge tester untuk refine skenario

“Tapi tetep, sama aja boong klo ujungnya QA yang test itu manually”

Baca lagi. Ada tester yang cerita pengalamannya klo AI justru trigger intuisi testing dia, AI bisa kasih perspektif yang nggak kepikiran, kemudian bisa dia explore secara manual

“Hmm”

Asep bergumam, emang di dunia nyata ga semua tester punya skill testing yang sama sih

Setiap bantahan Asep dijawab dengan “AI ga bisa …”, tapi selalu nemu counter argument “Klo ternyata bisa diginiin …”

Malam itu, Asep nggak tidur sampai jam 2 pagi, bukan karena cemas, tapi karena penasaran!

Sesungguhnya Software Tester sejati pasti tau klo rasa penasaran itu lebih kuat dari rasa takut

Obrolan di Pantry

Esok paginya, Asep nyamperin Jajang di pantry, bukan dengan niat konfrontasi, lebih banyak ke Investigasi, tester instinct-nya nyala

“Jang, ari presentasi kamari eta teh nyaan?” maklum mereka mah urang sunda, kurleb begini translate nya “bro, was that presentation yesterday actually legit?”

Jajang tertawa “Sing cadu, Kereut ceuli aing”, biar ga cape gw terjemahin ke bahasa Indonesia langsung aja ya, “Beneran, tapi konteksnya penting cuy, Bukan berarti AI nemu lebih banyak bug sendirian, kita yang nuntun harus gimana, jadinya efort yang sama bisa cover lebih banyak area testing”

“Maksudnya?” tanya Asep dengan curios-na teh

“Jadi gini, biasanya klo ada fitur baru, tim gw dulu cuma sempet bikin test happy path, asal sesuai acceptance criteria dan beberapa negative scenario yang obvious dah cukup, karena secara waktu nggak cukup buat explore lebih dalam, sekarang AI bantu generate skenario awal, dengan jalanin claude skill di repo source codenya, dah jadi tuh barang, dia baca konteks kode lain di repo secara otomatis, emang beberapa masih generik, tapi banyak juga yang tajam dan itu jadi titik awal buat benerin dan mengasah lagi test lainnya, termasuk bikin panduan exploratory testing yang lebih terarah”

Asep diam sebentar, otaknya sedang memproses data

“Jadi AI-nya nggak testing sendiri?”

“Nggak, AI-nya nggak jalanin testi, AI-nya bantuk mikir, kayak pair programming, jadiin teman sparing, kita kasih konteks, dia kasih perspektif, terus kita yang mutusin mana yang worth dipake”

Sparring Partner

Dua kata itu klik di kepala Asep, karena selama ini, salah satu hal yang paling susah di exploratory testing adalah testing sendirian, nggak ada yang challenge perspektif lo, beda dengan pair testing, bahkan mob testing. Nggak ada yang kasih sudut pandang berbeda, kita explore berdasarkan apa yang kita tau, bahkan kadan ga konsisten setiap hari tergantung mood hari itu, dan kadang memang jelas ada blind spot.

AI sebagai test buddy, jelas beda dari pemahaman “AI yang menggantikan tester” yang selama ini Asep percayai

Gimana suka dengan gaya penulisan storytelling gini ga?

Maaf lama sekali saya vakum dalam menulis, karena berbagai alasan, dari alasan klasik dengan kesibukan kantor, sampai explorasi side job, dari fotografi dan trading saham, tapi kini saya mulai sadar akan main job saya di software testing tentu perlu diasah kembali, termasuk dari sisi keahlian bercerita.

Maka dari itu saya mulai kembali milis ini dengan cerita fiktif si Asep, yang saya yakin juga ada banyak diantara kita yang merasakan hal yang sama.

Sampai jumpa di artikel lanjutan lainnya ya, kalau ada pertanyaan jangan sungkan untuk kirim di Instagram @ngetest.id yaaa, biasanya langsung saya bales (klo ga susah pertanyaannya :D )

Beberapa kali gw tanya beberapa orang apa yang dimaksud dengan aplikasi "berkualitas"? Banyak jawab dengan “baik”, “bagus” padahal ini adalah jawaban salah!

Ber-kualitas, artinya memiliki kualitas, nah yang nilainya bisa baik atau buruk, tapi kemudian kalo gw tanya “Baik” itu apa? Banyak yang susah jawab, paling sering malah jawab pake “baik itu yang gak jelek, gak rusak, gak error”, Nah penggunaan kata "nggak" ketika menjawab hal tadi membuktikan kalo secara alami tuh lebih mudah memikirkan hal-hal negatif

Beberapa waktu yang lalu gw nemu artikel yang bahas soal "via negativa" di artikel filosofis dan produktifitas yang gw baca dan langsung aja gw kepikiran situasi di atas tadi, karena konsep via negativa ini sangat relate sama QA!

Memang “via negativa” pada awalnya dikenal sebagai sebuah teori teologis untuk menjelaskan Tuhan maha baik dengan cara menjelaskan hal apa yang tidak mungkin ada pada Tuhan.

Pada konteks software testing, dari yang gw percayai:

Kita sebagai software tester, hanya bisa membuktikan kalo bugs ditemukan di aplikasi, tapi kita ga bisa membuktikan kalo aplikasi bebas dari masalah
Aplikasi yang bagus adalah aplikasi yang bugs critical nya udah ketemu dan diperbaiki, bukan berarti ga akan ada lagi bugs

Setuju?

Gw kasih contoh hal konkrit di dunia nyata tentang penggunaan via negativa lainya biar kebayang:

Share

Eh tapi gw mau iklan dulu :D

Tulisan ini sebenarnya adalah konten yang sama dari video eksklusif membership youtube gw, yang biasanya akan gw bahas softskill yang relevan buat software tester, mulai dari Rp 9 ribuan untuk berlangganan:

Oke contoh via negativa di dunia nyata, misal untuk meningkatkan kualitas kesehatan kita bisa saja menambah jam olahraga, tapi kita juga bisa mencapainya dengan mengurangi:

• Mengurangi makanan gorengan

• Mengurangi waktu begadang

• Hindari makan minuman manis

Gimana cara bisa lebih produktif? Coba kurangi ngerjain hal-hal yang ga berdampak alias ga penting

Termasuk dengan, Gimana cara meningkatkan kualitas? Coba turunkan jumlah bugs yang bisa merusak citra, coba kurangi failures yang bikin kesel user di production

Gimana cara merawat test automation code?

• Kurangin duplikat code, DRY

• Menghindari hardcoding

Gimana biar aplikasi lebih secure?

• Hindari penggunaan library ga jelas

• Kurangin akses role user yang ga perlu

• Jangan ngirim data sensitif tanpa enkripsi di post request

Gimana cara ngetest biar lebih cepet?

• Kurangin ngetest berlebihan, fokus pada skenario yang critical dan beresiko tinggi

• Hindari ngetest pake skenario yang basi, harus terus diperbarui

• Kurangin verifikasi manual, pake tools automation biar cepet

• Hindari menguji module yang lo ga paham, nanti ga sadar ada bugs karena ga tau

Nah gimana menurut kalian, make sense kah? hehehe

Oia jangan lupa kita juga bisa ngobrol dan berinteraksi juga loh di Instagram gw di @ngetest.id gw juga ada beberapa lelucon video yang relate banget sama QA, jangan lupa di follow ya ahaha

Rasanya kita udah memasuki era lebih baik ketinggalan dompet dari pada ketinggalan hape, bisa mati gaya ga terkoneksi dunia maya, bahkan sudah lumrah satu orang punya lebih dari satu device, ada hape kerja, hape pribadi, atau bahkan punya device khusus cuma buat baca/entertainment (kindle/ipad)

Dan sebagai software tester tentu harus paham bahwa menguji mobile app memiliki tantangan tersendiri dan bisa jauh berbeda dengan menguji website, kita kuliti lapisan ini ya:

🔥 Device Fragmentation

Ada banyak sekali ragam jenis device berdasarkan merek, ukuran layar, versi operating system sampai mesin hardware yang menjadikannya hampir mustahil untuk menguji tampilan dan performa aplikasi kita di semua device, jadinya kita harus menentukan prioritas device mana yang bisa kita coba untuk diuji dilihat dari popularitas pada user aplikasi kita.

Kita bisa lihat data ini di aplikasi event tracker yang dipakai perusahaan seperti: mixpanel, clevertap, dan lain sebagainya, coba cari device manakan yang paling banyak di guanakan oleh user kita antar platform (iOS/Android) beserta

🔥 OS Version

Cara menguji iphone tentu beda dengan android, mulai dari tidak adanya tombol back pada iphone, gesture khusus di xiaomi/iphone, dan lain sebagainya
Dan di satu device populer pun bisa memiliki versi OS yang berbeda karena bisa jadi device nya sama tapi beda OS misal iPhone 15 Pro Max di iOS 17 dan iOS 18

Oia, kita pun harus aware terhadap new feature (atau bahkan deprecation) di antar OS version ini, seperti dampak notification permission di android version 13.

🔥 Kecepatan Internet

Kita ga bisa tuh berasumsi internet speed user tuh pasti ngebut seperti di Jakarta, karena hape itu bisa memiliki sambungn internet via 5G, 3G, wifi, dan modus pesawat, bahkan kondisi umum seperti koneksi internet yang drop mendadak (seperti halnya kita masuk ke dalam lift), atau saat akses internet dibatasi karena kuota sekarat, jadi speednya jadi lemot karena paket hemat
Jadinya kita juga harus mengetahui bagaimana aplikasi kita berperilaku dalam kondisi di atas tadi tentu sangat penting

Cara pengujiannya bisa menggunakan Network Conditioner seperti pada Charles Proxy atau Proxyman

🔥 Interupsi

Ya namanya handphone punya banyak fitur di dalamnya, dan aplikasi kita harus berjalan optimal mana kala ada jeda saat telepon masuk, internet drop di lift, switching app saat tergoda notifikasi aplikasi sosmed, dan saat kembali menggunakan aplikasi kita harus disuguhkan user experience yang tahan interupsi

Kebayang kan stress nya kita kalo misalkan lagi explore akun mantan, trus jadi auto like ketika ada telepon masuk

🔥 Konsumsi Baterai dan Kuota

Faktor unik lainya tuh, kita pun harus peka dampak aplikasi kita tergadap penggunaan baterai, dan kuota loh! kalo sampe terlalu rakus makan energi bisa jadi aplikasinya di kill oleh OS, jadinya push notif jadi ghaib (tidak masuk ke hape padahal udah dikirim server) atau netizen complain di twitter karena ngerasa kuota mereka jebol karena ternyata aplikasi lo konsumsi internet untuk suatu background process

🔥Cara Install Aplikasi

Tentu kita sebel kalo ada error abis upgrade versi, dan user bisa jadi ga mau install app lagi
Jadi mesti di cek upgrade scenario dari beberapa versi sebelumnya (dan last minimum version)
Ga cuma fresh install scenario, karena di app tuh ada juga local DB migration yang bisa jadi bikin crash

Nah sepertinya cukup sekian penjabaran gw, bisa jadi ada yang kurang sebenernya kayak test “deeplink” dan “maintaining multiple version in production” tapi mungkin itu akan kita bahas di lain kesempatan

Kalo ada pertanyaan silakan komen, jangan lupa juga follow instagram @ngetest.id gw karena akan selalu ada informasi menarik seputar software testing juga, eh ada give away malah di bulan Juni 2024 ini 😍

Apa kabar? Semoga hari kalian baik saja dan sehat selalu ya, dan aplikasi kita aman di production 🙏, walaupun ya kita tau user kadang nemu aja ada kesalahan di aplikasi kita 😔. Wajar sebenernya, karena kita ga akan bisa test aplikasi 100% dengan semua kombinasi datanya, jadi mungkin bisa ada beberapa bugs yang kelepasan ke production.

Tentu kita berharap, bukan bug yang parah/critical yang muncul di production, berdasarkan pengalaman gw menguji aplikasi mobile di android dan iOS sebagian besar bugs critical itu dikarenakan proses di backendnya ada yang salah, misal lupa pasang validasi data, salah perhitungan, atau bentuk data yang diberikan oleh backend yang berubah. Nah kesalahan-kesalahan backend tadi sebenernya bisa kita minimalisir banget jika kita udah punya API Test yang mumpuni, segitu pentingnya peran integration testing kan, karena ia adalah tulang punggung aplikasi kita bisa berjalan prima!

Gimana sih cara ngetest API?

Nah, ngomong-ngomong soal API, gw lagi mulai series baru di Youtube NgeTest Bareng Fachrul yang bahas secara khusus terkait dengan Belajar API testing untuk Pemula (link playlist nya), series ini masih berjalan dan akan terus ditambah oleh video penjelasan lain, sampai saat ini udah ada 3 video yang membahas:

• Apa sih API itu? kenapa disebut Interface?

• Apa artinya RESTful API?

• Konsep stateless dan stateful

• Arti dari pemodelan Test Pyramid

• dan juga gw share strategi gw kalo ngetest API tuh mesti gimana, apa yang harus di cek

Nanti di akhir gw share link videonya ya, tapi gw juga punya pengumuman penting dan spesial buat lo

Share ✅ NgeTest Bareng Fachrul 🧑🏻‍💻

🎁 Apa tuh yang Spesial?

Gw ada rencana membuat kursus online dalam waktu dekat, gw perlu bantuannya ya temen-temen untuk mengisi form ini biar bantu gw untuk memutuskan kelas mana yang akan gw bikin terlebih dahulu, minta tolong diisi di link ini ya https://bit.ly/kelas-ngetest

Terima Kasih banyak 😍

Oh iya, berikut ini adalah video Dasar Pengujian API nya, kalo ada yang mau di tanyain atau masukan gw dengan senang hati bales komen lo di video loh

Kali ini, kita akan ngobrol santai seputar salah satu jurus di dunia software testing.

Pernah dengar tentang Context Driven Testing (CDT)? Kalau belum, tenang aja, karena kita bakal kupas tuntas tentang pendekatan keren ini yang ternyata sudah diimplementasikan dengan sukses di perusahaan bernama Moolya yang gw dapet dari nonton dua youtube video, link sumbernya akan gw cantumkan di akhir tulisan ini ya, sabar :)

Apa Itu Context Driven Testing?

Nah, sebelum kita masuk lebih jauh, mari kita bahas dulu nih, apa sih Context Driven Testing itu? Singkatnya, CDT itu fokusnya ke penggunaan tools yang sesuai dengan konteks dalam sebuah proyek testing. Ibaratnya seperti tukang kebun yang punya berbagai alat untuk memangkas, memotong, menebang pohon

Makanya kita sebagai software tester itu jangan hanya sekedar mengejar bugs, tapi lebih ke memahami 'kenapa' dan 'bagaimana' bugs itu bisa muncul, biar kita bisa mencegah bugs itu lahir. Caranya? Dengan bertanya dan menggali informasi - kayak detektif gitu deh!

Sedikit ringkasan dari Poin utama Context-Driven Testing itu:

1. Apa yang bagus tergantung situasinya.

2. Ga ada cara "paling bener", semua tergantung kondisi.

3. Tim yang solid itu penting banget.

4. Kadang proyek bisa berubah ga seperti yang kita pikir.

5. Produk harus bisa jawab masalah. Kalau enggak, ya gagal deh.

6. Ngetes software itu seru dan butuh mikir.

7. Buat ngetes dengan bener, tim harus kompak dan punya skill.

Share ✅ NgeTest Bareng Fachrul 🧑🏻‍💻

Filosofi Moolya dalam Mengimplementasikan CDT

Perusahaan Moolya ini, mereka bukan cuma ngomong doang lho. Mereka benar-benar menerapkan CDT dalam praktiknya (katanya :D ). Mereka menamakannya “Scaffolding” alias struktur sederhana yang digunakan untuk membantu menopang para tukang bangunan.

Salah satu kata kuncinya dari Scaffolding framework adalah proaktif! Yup, mereka nggak cuma duduk manis menunggu masalah datang, tapi mereka aktif mencari dan mencegah bugs yang kritis sebelum bikin pusing.

Nah di bawah ini adalah 4 kuadran yang menopang si CDT di Moolya:

1. Memahami Konteks (Context Understanding) Setiap cerita (user story) memiliki latar belakangnya sendiri. Saat kita berbicara tentang pengujian software, latar belakang ini disebut dengan konteks. Memahami konteks adalah langkah pertama yang harus ditempuh.

• Sudut Pandang yang Harus Dipahami:

  • Bisnis: Apa tujuan bisnis dari fitur ini?

  • Produk: Bagaimana fitur ini berdampak pada keseluruhan produk?

  • Teknikal: Bagaimana fitur ini diimplementasikan dari sisi teknis?

• Pertanyaan Kunci Sebelum Mulai:

  • Apa yang Anda ketahui tentang tiket ini?

  • Bagaimana dampak bisnisnya? Apa harapan dari fitur ini?

  • Bagaimana klien mengelola sebelum implementasi fitur ini?

  • Mengapa kita perlu mengerjakan fitur ini sekarang? Adakah halangan atau persaingan?

2. Strategi Pengujian Setelah paham konteks, saatnya merumuskan strategi. Ini perlu di test sedalem apa.

3. Eksekusi Ini saatnya beraksi menguji aplikasi! Beberapa cara mengujian yang dilakukan sama Moolya itu seperti

• Session Based Test Management:

  • Blokir kalender tim development selama satu jam.

  • Hindari gangguan apapun

  • Mulai eksplorasi pengujian bareng-bareng, buat cari bugs sebanyak-banyaknya

• Mob Testing:

  • Keroyokan testing nya gitu, jadi satu layar akan dilihatin rame-rame dan diuji bareng

  • Jalankan ini di akhir sprint atau setelah epik selesai tapi sebelum rilis

• Dokumentasi:

  • Setelah semua selesai, buatlah catatan pengujian untuk dibagikan dengan tim

4. Mempengaruhi Stakeholders (Influencing Stakeholders) Tidak cukup hanya dengan mengerjakan. Kita juga harus berkomunikasi dengan pemangku kepentingan.

• Laporan:

  • Buat laporan di akhir sesi testing

  • Apa aja yang udah di uji

  • Tampilkan perkembangan rilisnya gimana, aman ga

  • Soroti risiko yang mungkin muncul

Dengan menjalankan Scaffolding ini Moolya bisa:

Efisiensi dan Optimalisasi

Keren lagi, Moolya ini pintar banget dalam membuat rencana yang efisien dan optimal dengan sumber daya yang terbatas. Mereka tuh kayak chef jago yang bisa bikin masakan bintang lima dari bahan-bahan sederhana. Intinya, mereka nggak buang-buang waktu atau sumber daya untuk hal yang nggak penting.

Manusia Sebagai Faktor Utama

Tapi, tau nggak, sob? Yang bikin Moolya beda adalah keyakinan mereka bahwa faktor utama dalam pengembangan software itu adalah manusia. Yup, bukan kode, bukan algoritma, tapi manusia yang mengerjakannya. Jadi, mereka nggak cuma pandai dalam hal teknis, tapi juga paham betul soal pendekatan kemanusiaan.

Pentingnya Pendekatan Kemanusiaan

Para software tester di Moolya nggak cuma jago coding, tapi juga harus bisa 'merayu' alias influencing tim development. Maksudnya, mereka harus bisa mempengaruhi tim supaya semua berjalan mulus dan efektif. Bisa menekankan bugs mana yang wajib banget di fix dan mana yang masih aman dan mungkin ga ada user yang notice sih bisa kita skip.

Kesimpulan

Jadi, buat sobat yang kerja di dunia software atau pengen terjun ke dunia testing, ada banyak pelajaran berharga nih dari cara kerja Moolya. Ingat, di dunia yang serba cepat ini, nggak cukup hanya jago teknis, tapi juga harus paham manusianya. Seperti kata pepatah, teknologi berkembang, tapi manusia tetap jadi jantungnya.

Ini dia sumber videonya:

Dan juga ini:

Apa kabar teman-teman? Semoga selalu dalam keadan baik dan sehat walafiat ya, mohon maaf yak sempat tertunda beberapa pekan tidak rilis tulisan baru, karena ada beberapa kesibukan di kantor, jadi baru sempat di pekan ini saat libur Idul Adha buat ngelarin tulisan ini 😅

Ok, kita lanjutin series “Resensi QA” merangkum hasil dari gw menyimak suatu video/buku, kali ini gw udah nulis resensi dari sebuah youtube Kuncie: Bright Opportunity of a Quality Assurance

Video ini sangat cocok buat lo yang baru lulus kuliah dan tertarik untuk memiliki karir di Software Quality Assurance, gw saranin buat nonton videonya sampe akhir ya, karena di sesi tanya jawabnya juga menarik banget!

Video rekaman webminar di atas adalah sebuah teaser dari kursus yang ditawarkan Kuncie di bulan Januari/Februari 2023 kemarin, dan Kuncie baik sekali membuat dan membagikan webminar ini sehingga kita bisa menyimaknya juga 🌟

Oke gw bahas intisari dari pembahasan Mas Tegar yang keren banget

Subscribe now

Profesi Software Quality Assurance itu sangat menjanjikan di jaman sekarang, terlebih saat AI mulai merajalela, peran QA justru semakin penting, karena gak semua bisa di kerjakan oleh AI, bahkan hasil generated kode dari AI perlu di verifikasi lagi oleh manusia, bahkan menurut Gartner yang membuat daftar skill critical dan niche di masa depan ternyata banyak irisannya dengan peran QA loh.

Tapi, jangan salah kaprah, banyak mahasiswa jurusan IT yang bilangnya mau jadi QA karena ga bisa koding, padahal faktanya, menjadi QA perlu juga keahlian koding, bahkan kalo mau menjadi QA yang “membara” harus bisa testing fitur, membantu Dev untuk bikin unit test yang efektif & efisien sampe ke membantu proses deployment ke user, QA ikut memupuk DevOps culture di perusahaan.

Di bagian selanjutnya, Mas Tegar menjabarkan kalo karir QA juga ga jauh beda dengan software engineer lainya, umumnya ada jalur karir sebagai managerial atau individual contributor, tapi yang lebih menarik adalah pagian 3 nya tentang Roadmap!

Jadi disini dijelasin klo roadmap QA itu ibarat mendaki gunung, awalnya mendaki itu gampang saat landai, tapi perjalanan tentu naik-turun sebelum sampai puncak, ketika sampai puncak pun jangan dulu puas dengan apa yang dicapai, masih ada puncak lain (phase) yang perlu ditaklukan juga

Nah poin-poin yang ada di tiap fase nya itu dijelasin lagi secara rinci di dalam video, ga mungkin gw tulis semua disini karena nanti jadi panjang ahaha, langsung di cekidot aja video sumbernya ya.

Lompat ke bagian tanya jawab, sebenernya ada berbagai pertanyaan yang umumnya ditanyakan oleh pemula, yang mungkil lo juga penasaran gitu soal karir di QA ini, tapi klo bisa gw simpulkan dari tanya jawab adalah:

Dengan adanya test automation, artificial intelligence, ChatGPT itu semua hanya tools yang akan bikin testing menjadi lebih efisien, sehingga jumlah software tester di perusahaan ga sebanyak dulu, tapi bukan berarti peran QA akan tergantikan oleh robot, justru perlu QA expert yang bisa mengendalikan tools tadi.

QA Expert ga cuma perlu keahlian koding, test infra (devops), tapi fundamental testing juga sangat perlu dilatih, dan business domain di perusahaan juga harus dimengerti juga.

Talenta software tester di Indonesia tuh ga kalah bagus kok dari luar negeri, bahkan banyak yang lebih jago, cuma untuk bisa berkarir di luar negeri harus bisa bahasa Inggris, ga mesti grammarly correct, yang penting bisa berkomunikasi dengan jelas aja, dan punya rasa curious yang tinggi dan ga malu bertanya.

Nah begitu deh resensi webminar dari Mas Tegar di channel Kuncie, silakan di cek deh, ada beberapa video lanjutan juga terkait software testing loh!

Klo ada video yang mau dibikinin resensinya, silakan komen disini ya 🙏

Share ✅ NgeTest Bareng Fachrul 🧑🏻‍💻

Apa kabarnya? mudah-mudahan sehat selalu ya guys ✨

Ini adalah tulisan pertama dari “ResensiQAn”, jadi gw bakalan nulis resensi dari sebuah karya terkait topik software testing (QA), bisa berupa video youtube, buku, ataupun lainnya, mudah-mudahan bisa memberikan tulisan singkat mengenai rangkuman isi dari konten aslinya yang panjang

Di tulisan pertama ini, gw akan nulis rangkuman dari youtube ini:

Topik ini menarik sekali, karena gw percaya bertanya itu ada seni nya, tapi banyak orang yang ragu bertanya karena takut di cap bodoh, “lah masa gitu aja ditanyain” 😱

Siapa sih beliau itu?

Video tadi dibawakan oleh Dorothy Graham, seorang penulis 5 buku dibidang software testing, dan ia juga seorang independent consultant and trainer di bidang software testing and test automation selama 50 tahun! Goks, gak heran sih, soalnya keliatan udah nenek-nenek 🙏 ga kebayang gw klo punya nenek seorang software tester 😍

Apa point penting dari video itu?

Jadi intinya beliau itu memaparkan kalo:

• Kenapa orang malu bertanya?

  • apakah takut terkesan bodoh

  • apakah dalam forum yang sama banyak orang lebih senior/lebih pintar tapi mereka terkesan ngerti aja

    • apakah lo mikir “apa cuma gw doang ini yang ga ngerti?”

  • takut diserang balik

• Kalo lo ada disitu dan lo masih ga ngerti, sebenernya besar kemungkinan orang lain juga ga ngerti loh!

  • mereka malu juga nanya

• Konsekuensi dari ga ada yang nanya adalah misunderstanding yang ujung-ujungnya bikin rugi kita sendiri, rugi waktu dan efort jadi sia-sia karena mesti ngulang dan memperbaiki semua itu

  • yang mana bisa dicegah sebenarnya andai saja ada yang membahas

• Tester mindset itu salah satunya adalah:

  • mempertanyakan (questioning)

  • meragukan (challenging)

  • menyelidiki (probing)

  • menjelajahi (exploring)

• Sayangnya sebagai Software Tester, kita ga boleh ragu, dan berasumsi sendiri tanpa konfirmasi, karena akibatnya bisa fatal, segala risiko yang diterima dari bertanya harus dihadapi oleh kita untuk kemaslahatan bersama

• Sugesstion:

  • Mulai bertanya dari mengakui “Mungkin terdengar konyol, tapi …”

  • Mulai dari pemanasan “Mungkin udah sempet dibahas sebelumnya, tapi gw masih ….”

  • Merendah dulu sebelum hantam balik “Maaf ya, gw ga yakin gw paham dengan jelas, boleh ga diulang sekali lagi bagian ini…” lalu dilanjut “nah kalo begitu ceritanya, gimana kalo ….”

• Faktanya juga banyak bukti setelah kita bertanya, orang lain jadi mulai berani juga (yang mana mereka juga sebenernya ga ngerti, cuma gengsi aja gitu)

Oh iya dimana letak seninya?

Jadi banyak yang mikir kalo bertanya itu hanya dilakukan saat lo ga ngerti, padahal bertanya itu bisa digunakan untuk mengkomunikasikan concerns lo, malah bertanya itu lebih efektif dari memberikan statement, karena bikin orang mikir seolah-olah hal itu keluar dari mulutnya mereka sendiri saat jawab, padahal lo yang nuntun mereka untuk menemukan itu

Dan quotes yang bagus dari beliau adalah:

Share ✅ NgeTest Bareng Fachrul 🧑🏻‍💻

Mantap betul kan 🤩

Menurut gw:

Seni membuat pertanyaan yang baik adalah keterampilan yang penting dalam komunikasi, yang seringkali tidak kita sadari. Pasti lo pernah ngerasa nyaman ngobrol sama orang karena nyambung kan, nah yang nyambungin obrolan itu pertanyaan loh! yekan!

Memberikan pertanyaan di waktu yang tepat pasti bisa memberikan efek yang luar biasa, nah gimana formula pertanyaan yang biasanya gw pake:

1. Jelas dan Spesifik

Pertanyaan yang baik itu harus jelas dan spesifik. Hindari pertanyaan yang terlalu umum dan luas, kek gini "Bagaimana cara kerja komputer?", coba bikin pertanyaan lo lebih spesifik, seperti, "Bagaimana prosesor dalam komputer menerjemahkan instruksi kode menjadi aksi?" wanjay

2. Terbuka, Bukan Tertutup

Apa tuh yang enaknya dibuka aja daripada di tutup? Pertanyaan lah!

Pertanyaan tertutup itu yang cuma jawab 'ya' atau 'tidak' udah cukup, sedangkan pertanyaan terbuka memicu diskusi dan pemikiran yang lebih dalam.

Misalnya, jangan tanya, "Apakah kamu suka membaca buku?", tapi tanyakan, "Buku apa yang paling berkesan buat lo dan kok bisa?"

3. Abaikan 5W1H

5W1H (What, Who, When, Where, Why, How) sering kali jadi biang kerok dan beban fikiran, di kehidupan sehari-hari kan kita ngobrol langsung dengan lawan bicara, setidaknya umurnya ga beda jauh, jadi obrolannya harusnya lebih cair (beda cerita klo ngobrol sama manager yang jauh lebih tua ya), nah karena seumuran, bertanya lebih cair aja, kayak “kalo misalnya requirement nya kayak gitu, gimana ceritanya validasi lama kok harus di disable? urusan sama tim legal gimana dah?”

4. Menghormati Penjawab

Tetep harus rispek, jangan membuat lawan bicara merasa tidak nyaman atau diserang dengan pertanyaan lo. Sebaliknya, buatlah mereka merasa dihargai dan dihormati.

5. Nada Bicara

Jika komunikasinya secara verbal, hal ini penting banget ini sih, lebih penting daripada isinya, karena bisa berefek salah presepsi dari si lawan bicara, kata “hah” aja memiliki 1000 arti tergantung dari jenis intonasi, niat dan konteks 😁

6. Tau Waktu & Tempat

Diluar teknis gimana cara bertanya, ataupun bobot pertanyaan kita, setelah dipikir kadang juga faktor kapan waktu bertanya ini penting untuk disadari loh, kita harus peka harus nanya itu, apakah saat di ruang rapat, di Direct Message, ataupun di Channel, contoh kasus: lo pasti sebel rasaanya saat mau pulang sekolah/kampus ada temen lo yang nanya terus ke guru/dosen diakhir sesi, padahal pertanyaan nya tuh ga mesti sekelas tau jawabannya karena bisa diomongin berdua padahal

jadi harus diatur sedemikian rupa agar kesannya tetep memberikan rispek ke mereka

Intinya, membuat pertanyaan yang baik bukanlah tentang mencari jawaban yang benar, tetapi tentang memahami lebih dalam, memicu diskusi, dan merangsang pemikiran kritis.

Jadi, jangan takut untuk bertanya, dan lebih penting lagi, belajarlah bagaimana cara membuat pertanyaan yang baik!

[pesan sponsor] Jangan lupa cek toko gw di https://www.tokopedia.com/ngetest-jualan

Ada baju keren dari gw ini ya, biar software tester makin keren gaes 🤩

• Keteteran kerjaan

• Sering dapet tugas dadakan

• Ga tau bisa kelar hari ini apa nggak

Sama, gw juga! ahaha, tapi jangan sedih dulu, gw akan share siasat gw dalam mengelola waktu biar lebih efisien dengan cara mengurangi waktu!!

Mengelola waktu

Sepertinya, time management (manajemen waktu) sudah menjadi sebuah skill wajib bagi software testing, karena pekerja software itu dituntut result oriented, banyak variabel yang bisa bikin waktu tempuh pengujian jadi semakin lama. Misal, klo nemu bugs tapi intermitten atau bahkan klo testnya lancar ga nemu bugs baru (malah was-was ga sih).

Karena waktu adalah sumber daya yang tidak bisa ditambah atau kurangin, bahkan ga bisa di transfer juga, jadinya keahlian mengelola waktu sangat kritikal bagi software tester, biar ga burnout saat bekerja, dan kualitas pengujian juga tetap semangat dan produktif.

Waktunya Ngaret

Sering kali perusahaan itu menempatkan software tester sebagai “Quality gate keeper”, alias si penentu rilis apa nggaknya sebuah fitur/version, akhirnya software tester (QA) menjadi bottleneck, berasa semua pada nungguin kerjaan QA kelar ga sih 😅

Dengan kek gitu, sering kali QA jadi kambing hitam saat tim harus ambil delay rilis/waktu yang ga sesuai jadwal. Karena ujung-ujungnya klo delay itu nambah cost produksi software loh, kebayang ga sih klo ada hard deadline launching produk, tapi H-1 fiturnya masih kayak zombie! klo sampe mesti delay,, beeuuuh berasa duduk di kursi panas!

Waktu Efisien

Ga selalu loh istilah “Lebih cepat, Lebih baik” berlaku di software testing, karena bisa jadi ternyata cepat dan banyak yang kelewat! ahaha, ujung-ujungnya puter balik 😂

Jadi harus cepat DAN baik, hasilnya adalah efisien, sungguh idaman setiap software tester ya untuk bisa terus efisien, nah karena kita ga bisa menambah waktu lebih dari 24 jam sehari, atau menambah waktu rilis dengan mudah, makanya gw mo share cara gw mengurangi waktu!

Oia klo mau liat versi videonya bisa diakses di youtube “NgeTest Bareng Fachrul” juga ya ini:

Mengurangi Waktu Regression Test

Regression test adalah salah satu sumber pengeluaran waktu terbesar bagi seorang software tester, jalanin regression test suite itu bisa berhari-hari (beda-beda sih tiap tim/kantor), gw pun kadang mo muntah ngeliatin testrail runner ga kelar-kelar keknya!

Nah gimana cara ngurangin waktu regression test yang biasa gw lakuin:

1. Rawatlah test suite si regression test

Lo tentu akan masukin fitur baru ke koleksi test suite, tapi apakah lo akan kurangin juga test fitur lama dari koleksi? Udah 10 rilis loh itu ga ada perubahan, aman-aman aja kan? masi tetep perlu di cek berkala? Tentu tergantung ya, klo bukan core features sih lebih baik dikurangin, atau bahkan outsource aja ke test automation

2. Test planning yang bener

Katakanlah di sprint planning udah ketahuan fitur baru apa aja yang akan di rilis, nah kita bisa rencanain tuh nanti ada dampaknya ga di regression test, klo bisa colong start, coba jalanin regression test dulu di fase feature test biar keliatan ada imbas ke regression test suite ga nya.

Atau bahkan dengan fitur baru, kita perlu persiapan lebih lama buat production testing nantinya, misal kita perlu setup akun dengan kondisi tertentu biar bisa gampang di testnya.

Dan terkait nomer 1 tadi, di planning juga prioritas test cases nya, mana yang masuk test run nanti, mana yang penting di cek duluan sebelum yang lain

3. Nyuruh Robot

Alias test automation, dengan adanya test automation, pengujian software tentu akan lebih mudah, mereka akan nurut terus disuruh ngetest kapanpun bisa, ga ada capeknya, ga bosen-bosen ngetest hal yang sama 100x sehari. Tentu, robot/automation ini ga akan menggantikan kualitas pengujian yang dijalankan oleh manusia, tapi bayangin deh kita kan klo ngetest ga bisa paralel sekaligus semuanya dikerjain barengan, nah contoh, saat kita lagi test module sign up dengan fitur baru, si test automation ini akan ngetest module login/reset password, nanti pas kita kelar test sign up tinggal liat hasilnya dulu dari yang dikerjain test automation, sebelum kita terjun lebih jauh di pengujian manual, karena kesel juga kan pas ditengah test gataunya ada error dan perbaikannya bisa bikin test kita yang udah kelar harus di-retest lagi.

4. Menggunakan jurus pengujian yang tepat

Pernah denger jurus “Kunyuk Melempar buah”? ahaha generasi 90an doang keknya yang inget!

Oke maksudnya adalah menggunakan teknik pengujian yang tepat bisa meningkatkan kualitas pengujian lebih efektif dan confidence, contohnya gini, pada suatu fitur baru untuk tambah validasi pada suatu form input, kita punya 30 macem validasi, nah kita harus tau ini validasi dari Backend apa frontend, klo tau ini validasi datengnya dari BE, jadi si 30 macem validasi kita test di level API aja, 1x di FE, buat liat tampilan errornya aja, karena konten error message nya dateng dari BE toh, jadi ga perlu deh tuh kita habisin waktu lama-lama buat ngetest semua 30 validasi tadi (atau bahkan influence dev buat cover 30 test tadi di level unit testing)

Share ✅ NgeTest Bareng Fachrul 🧑🏻‍💻

Mengurangi Waktu Debug

Gw sangat senang sama debugging, ibarat detektif yang lagi ngumpulin bukti kriminal, dan cari tau siapa dalangnya, dalam hati “ini tuh beneran error loh gaes, nih liat aja lognya, screenshot nya, video reproducenya”

Tapi semua itu perlu waktu yang ga singkat, reproduce issue deh minimal lebih dari satu kali, kadang buat mastiin ini kejadiannya cuma di kondisi A aja apa juga di kondisi B, belom lagi klo kita mau mastiin ini kejadain nya sejak di versi baru aja atau kejadian juga di production! gimana ga lama tuh waktu debuging nya ahahaa

Yang bisa kita kurangin di waktu debug adalah:

1. Error Logging sistem yang terintegrasi

Pastikan aplikasi kamu udah terkoneksi dengan logging system yang baik, minta developer manager buat pasang di aplikasi development (integration/alpha/beta) juga, ga cuma di production aja gitu, karena kan fitur baru pasti di testnya ga langsung di production donk!

Jadi mana kala muncul bugs/crash/faliures, langkah pertama kita adalah ngecek log ini, yang barusan kejadian tuh stacktrace nya kek mana, seringkali informasi ini udah cukup jelas buat dev

2. Laporan bugs yang jelas

Red flag deh klo devnya selalu nanya QA di standup/DM buat jelasin temuan bugsnya, karena itu berarti laporan bugsnya ga jelas dimengerti oleh dev (atau Devnya masih baru, atau emang pengen ngobrol sama lo aja/PDKT 🤣 )

Coba refleksi, apa yang ditanyakan dev itu, apakah step reproduce nya ga jelas? tambahin foto, klo kurang jelas juga tambahin video! apakah mungkin bugs report lo itu description nya ga jelas, ekspektasi yang ga make sense.

Intinya, ini adalah feedback dari dev agar komunikasi lo jadi lebih baik, kalaupun ga ada komentar dari Dev, coba tanyain kira-kira ada yang bisa di improve ga dari bugs report nya yang biasa dia terima? kadang ada dev yang mau juga di tambahin info device/browser detail.

Jadi devnya bisa sat-set langsun ngerjain bugsnya.

Mengurangi Waktu Nunggu

Menunggu itu pemborosan waktu, apalagi klo sambil bengong gada kuota internet, beuh mati gaya dah tuh nunggu! ehehe tapi ini bukan soal nunggu bus transjakarta gaes, kita harus identifikasi titik mana aja yang biasanya kita habiskan buat menunggu

Menunggu feature yang Ready for Testing

Di awal sprint biasanya belum ada fitur baru yang ready for testing langsung kan, coba liat apa yang bisa QA kerjain di waktu kosong ini, misalkan cek crashlytic di production, di release sebelumnya banyak error ganya, bikin test automation, entah buat automate fitur lama atau fitur yang berjalan (API sih ada kontrak response yang bisa dipake buat automate), atau ngerjain apa kek biar nanti test nya langsung sat-set-sat-set, macam prepare test data gitu

Menunggu bugs yang Ready for Testing

Nah ini sering jadi bumerang, kita udah rise issue tapi ternyata ga kunjung dikerjain developer! Mana itu bugs severity critical, bisa masalah klo dilolosin sebelum rilis! nah makanya tetep pantau terus itu bugs report kita, tiap hari di standup kita harus sundul developernya:

• bugs yang gw report udah di baca belom?

• ada yang perlu gw jelasin ga soal bugs itu?

• ke reproduce ga di tempat lo?

• apa perlu gw yang kerjain itu bugs? (ini klo bisa ya ahaha)

• gw bilangin bapak lo ya! (eskalasi)

Berikut hasilnya:

Gw jg bikinin sekalian dalam canva di bagian bawah, biar lebih cakep buat di share di instagram atau medsos lo

Share ✅ NgeTest Bareng Fachrul 🧑🏻‍💻

Jadi ceritanya ada sebuah unggahan di linkedin mengenai tech meme 9gag.com yang isinya ala-ala script untuk mengisi kopi.

Awal melihat saya berfikir ini tak nampak ada yang salah, saya hanya memikirkan bahasa pemrograman apa kira-kira ini, dan ada improvement yang bisa dibuat di inisial constructor objectnya

Namun komentar dari James Bach, yang menemukan metode "Rapid Software Testing" sangat menarik untuk disimak dan ditelaah kembali, dia berkomentar untuk menguji kode tadi, hal-hal remeh yang bisa beresiko dari spesifikasi sebuah mug untuk menampung kopi

Yang menarik dari posting dia adalah penggunaan common sense dalam pengujian dia menghasilkan banyak asumsi yang tidak jelas dan perlu klarifikasi kembali agar tidak ada kesalah pahaman, dan bagaimana cara dia menguji dengan bertanya (push back) juga menurut saya keren, karena dia tidak membuat asumsi ulang dengan ekspektasi yang seharusnya terjadi, tapi bertanya untuk membuka peluang diskusi mencari solusi terbaik.

Sugguh situasi pagi yang mind blowing buat saya hari ini.

Tak hanya dari posting beliau, ternyata sangat menarik membaca posting pengguna yang lain pula, karena mereka membagikan sudut pandang yang menarik, diluar nalar saya!

Ya gitu deh, terkadang memang kita perlu latihan berfikir kritis dan mengasah common sense

Share ✅ NgeTest Bareng Fachrul 🧑🏻‍💻

Salam,

Saya banyak mendapatkan pertanyaan di DM Instagram @penguji.id dari teman-teman yang menanyakan rekomendasi bootcamp yang bagus untuk memulai karir sebagai Quality Assurance (Software Tester). Sudah tentu saya tidak akan langsung menyebutkan yang mana yang bagus, karena saya tidak punya kapasitas untuk menilainya secara objektif, karena tidak nyobain langsung ikut semua bootcamp dan menilai mana yang bagus. Pun kalaupu ikut, bisa jadi kualitas pembelajaran di antar batch bisa berbeda dengan bootcamp yang sama, misal ada peserta yang super aktif sampe “mengkuliti” ilmu si mentor 😅, disini saya akan coba sampaikan bagai jika saya ada diposisi kamu yang sedan mencari bootcamp untuk QA. 

Saya berusaha untuk tidak menyebutkan bootcamp tertentu/mana yang terbaik, hanya membagikan sudut pandang gimana kalau saya yang newbie dulu mengevaluasi bootcamp yang ada sekarang.

Apa Kelebihan Ikut Bootcamp?

Jujur saya iri melihat berbagai pilihan bootcamp yang ada sekarang, sepertinya bisa sampai 10 lembaga yang rutin membuka gelombang pendaftaran, jaman saya dulu (2013) sih boro-boro 🥲

Oke, menurut saya kelebihan mengikuti bootcamp ini adalah:

1. Kurikulum. Sudah tentu bootcamp menawarkan pembelajaran menjadi Software Tester yang baik, terstruktur dan dipandu oleh mentor berpengalaman, sehingga tak perlu lagi kamu bingung di belantara informasi di internet

2. Mentor. Sering kali kita menemukan masalah yang unik dan sulit kita temukan jawabannya di mbah gugel, punya mentor yang bisa kita tanya tentu akan membantu kita menyelesaikan masalah, memberikan masukan bagaimana solusi terbaik dari masalah yang kita hadapi

3. Networking. Jaringan komunitas bootcamp itu sangat kuat, alumni saling berbagi informasi, karena dengan sistem referal kita jadi percaya diri akan kapasitas rekan satu bootcamp

4. Komitmen Finansial. Ada loh orang yang sengaja ikut kelas bootcamp berbayar agar bisa komit belajar, mereka ngerasa rugi klo udah bayar tapi ga serius belajar

5. Relevan. Biasanya kurikulum di bootcamp itu selalu kekinian sesuai dengan kebutuhan di dunia kerja, misal banyak yang menawarkan kelas automation test dengan Cypress yang memang lagi naik daun akhir-akhir ini

   

Cara Memilih Bootcamp-nya gimana tuh?

Jadi memilih bootcamp ini mesti teliti, karena kita harus komit bayar di depan untuk ikut kelas bootcamp (sejauh yang saya tau ya), jadi sayang betul kalo tidak sesuai dengan kebutuhan kita sendiri, jika bootcamp nya menawarkan kelas percobaan (demo) itu akan sangat membantu sekali, ga akan beli kucing dalam karung deh.

Faktor yang harus diperhatikan dalam memilih bootcamp adalah

1. Mentor

Kurikulum yang baik sekalipun kalau yang membawakan materinya kurang mahir hanyalah seperti naik bus mewah tapi supir ugal-ugalan 🤣, kamu ga akan bisa menikmati indahnya pemandangan!

Cari tahu mentornya ini siapa, apakah dia punya video youtube saat mengajar? apakah dia pernah jadi pembicara ISQA? apakah cara omongannya mudah kita pahami? (mudah-mudahan setelah ini banyak penyedia bootcamp membuat video mentornya di youtube ya)

Ini krusial, untuk tau seberapa kompeten mentor-nya nanti, cari tau dari linkedin nya, dari gugling nama dia, lihat apakah dia punya pengalaman ngajar yang baik, artikel yang dia share di linkedin.

Kita akan menginvestasikan waktu kita berhari-hari bersama dia loh, jangan sampai ada opportunity cost!

2. Kurikulum

Biasanya bootcamp yang baik akan memberi tahu silabus mereka, kita bisa lihat dan menilai sendiri:

• apakah mereka mengajarkan best practice menjadi QA?

• tools apa saja yang dipelajari nantinya?

• apakah diajari koding dari dasar?

• bahasa pemrograman apa yang nantinya dipakai?

• apakah sampai buat automation test untuk API, web, mobile? (semua atau sebagian)

• (optional) sampe ke cara cek database juga kah? performance test?

Oia dan kalo kamu punya inceran mau kerja di kantor/startup tertentu baiknya udah sekalian ikut course yang mengajarkan framework/bahasa pemrograman yang sama, biar effor untuk belajarnya bisa sekalian buat persiapan kerja, contoh: di gojek paka java, better cari course yang bahasa pemrogramannya sudah java.

3. Harga

Nominal angka di bootcamp ini relatif memang, ada yang bilang harga X itu terjangkau, ada yang perlu menyisihkan dulu beberapa kali gaji, jadi setiap rupiah yang kamu keluarkan haruslah seusai dengan budget kamu, jangan sampai pake pinjol berlebihan, karena selepas bootcamp belum tentu loh langsung kerja dengan gaji besar

4. Review

Cari alumninya di linkedin, minta pendapat jujur mereka, di website iklan/testimoni mungkin kurang jujur ya, tapi klo kita DM mungkin mereka bisa spill, tanya aja dulu mereka di mentorin sama siapa, gimana cara ngajarnya, kesannya seperti apa, dll.

5. Waktu/cara belajar

Pastikan jadwalnya cocok dengan komitment waktu kamu ya, ada yang mulai malam, ada yang akhir pekan, atau mungkin ada yang dari pagi-sore untuk beberapa hari, dan durasinya ada yang 3 bulan, ada yang 10 x pertemuan, dll.

Ada juga yang perlu offline di Jakarta, ada juga yang bisa diikuti secara online dimanapun, ada yang bentuknya videou course bisa belajar mandiri (asyncronus), ada juga yang bentuknya webminar/meeting, atau gabungan keduanya.

Cari yang paling cocok dengan jadwal kamu, yang sudah kerja, kuliah, berkeluarga tentu memiliki waktu senggang yang berbeda.

Share ✅ NgeTest Bareng Fachrul 🧑🏻‍💻

Tapi…

Bootcamps bukanlah syarat wajib berkari sebagai QA/Software tester, bahkan untuk menjadi SDET (software developer engineer in test) atau Automation Engineer sekalipun.

Hampir semua yang diperlukan mencapai itu bisa didapatkan melalui internet secara gratis, atau dengan harga yang relatif lebih murah, bisa belajar langsung dari official documentation nya bahkan. Dan youtube jadi teman belajar segala 😎

Dan saya sendiri orang yang kurang cocok buat bootcamp live webminar gitu, karena konsentrasi saya relatif pendek, mesti dicicil belajarnya, kadang bahkan video tutorial pun suka diulang >2x karena sering keskip gitu dia ngomong apa 🤣

Again, klo kamu merasa belajar di kelas (offline atau virtually), biayanya bukan masalah, dan berbagai benefit di atas bisa memicu kamu menjadi lebih siap berkarir di QA ya silakan diambil.

Tak ada pilihan mutlak, semua relatif dan kontekstual. Belajar sendiri (otodidak) perlu komitmen dan disiplin diri yang tinggi juga kan.

Tetap semangat belajarnya yaaa
Salam Bootcamp MerdeQA 

Leave a comment

Dilanjutkan membaca utas tersebut, banyak yang menimpali di berbagai perusahaan besar pun sudah tidak ada lagi jabatan QA (quality assurance), ada yang sesumbar dengan tanpa QA mereka sudah menghemat anggaran, ada pun yang bilang bahwa, tidak memiliki QA adalah sebuah pertanda kecakapan teknis pada Development tim. Lagian ngapain mesti di test sih, disaat kamu bisa kasih customer test langung!

Apa benar begitu?

Mungkin saja benar adanya, karena itu adalah kebenaran yang relatif dan subjektif, bukanlah sebuah hal yang konkrit.

Karena sesungguhnya saya pun mengakui, QA adalah jabatan yang tidak esensial, seperti halnya PM atau designer. Client bisa saja langsung menyampaikan kebutuhannya langsung kepada programmer (sendiri).

Namun dengan berkembangnya aplikasi dan meningkatnya kompleksitas pengerjaan maka diperlukan kerja sama tim delivery (product+engineer) yang menurut saya sangat mirip dengan tim sepak bola, mari saya analogikan, ada tim yang ga punya penyerang murni (false 9), ada tim yang ga punya sosok playmaker, ada tim yang bek sayapnya jadi gelandang serang, ada banyak cara bermain baru di sepak bola modern ini.

Pada musim 2008/09 tim Barcelona begitu adidaya dilapangan dengan permainan Tiki-taka mereka bisa memainkan “Sepak bola indah” dengan umpan pendek kaki ke kaki, dengan konsisten mereka selalu mencetak kemenangan.

Semua orang demam tiki-taka, banyak tim terinspirasi dan coba menerapkan permainan tiki-taka, namun tak semuanya berhasil, karena mereka tidak memiliki kapasitas pemain mumpuni seperti Barcelona, kualitas pemain yang dimiliki tim tidak bisa menyamai Messi, Iniesta, ataupun Xavi, pun mereka telah melalui proses latihan panjang sebelumnya.

Begitupun dengan tim delivery tadi, bukan tidak mungkin kita bisa memiliki tim tanpa QA, tapi pastikan segala persiapan sudah dimiliki dengan baik, seperti (menurut saya): 

• memiliki proses development yang bertanggung jawab, menjalankan secara religius TDD

• mekanisme feedback loop yang pendek

• monitoring & alerting dari production env

• dan lain sebagainya, sehingga peran dari sosok QA sudah tergantikan.

Terlebih, siapa pula yang bisa manjadi penjamin kualitas lebih baik selain si orang yang membuatnya, QA (quality assurance) hampir tidak bisa memiliki kuasa untuk merubah schedule, budget, scope, development style, dan lain-lain.

Bisa jadi juga mereka belum pernah bertemu seorang Tester Handal, sehingga menurut mereka QA tidak lagi diperlukan, memang sering sekali saya melihat QA adalah seorang programmer tanggung, atau project manager wannabe. Kita (QA/Software Tester) haruslah menjadi Investigator handal, seperti sosok detektif!

Tugas Software Tester adalah mencari informasi berharga dan akurat mengenai perkembangan dari pengerjaan fitur/project, kita tak boleh sombong mengemban tanggung jawab kualitas seluruhnya, ataupun menjadi tukang cap pass/failed, tugas kita justru membantu tim untuk bisa bertanggung jawab mengerjakan fitur/project yang berkualitas baik dan memuaskan.

Bagaimana cara kita membantu tim?

Dengan cara mendengar kebutuhan mereka, coba kamu tanyakan hal apa saja yang mereka harapkan dari kamu.

Saya coba kasih contoh dari pengalaman saya, yang dibutuhkan dari seorang QA adalah informasi:

• sebagai seorang programmer, mereka ingin tahu apakah ditemukan masalah dari perubahan kode, bagaimana cara QA menemukannya, apakah ada dampak di modul lain agar programmer bisa memperbaiki dan lebih waspada lagi kedepannya. 

• Kemudian sebagai seorang PM, mereka ingin tahu bagaimana hasil observasi/evaluasi dari QA atas product/fiturnya, apakah hasil akhir sesuai dengan ekspektasi awal, adakah perubahan yang tidak direncanakan, apakah ada dampak buruk/baik dari fitur baru, bagaimana jika dibandingkan dengan produk lain di market

• dan lain sebagainya.

Kita ini bagaikan indra tambahan pada tim, keunikan dan ke-sensitif-an kita diharapkan bisa melihat sudut pandang baru, merasakan hal yang sering kali luput dari orang lain (development tim), namun kita pun bisa saja salah, jadi kitapun harus terus skeptis akan apa yang menjadi opini kita sendiri. Layaknya instrumen alat ukur yang perlu dikalibrasi, kita pun harus bisa mengevaluasi hasil kerja kita, minta feedback dari tim secara rutin. 

Jangan lupakan eksplorasi, investigasi, dan pahami produk dan proses bisnisnya, dan coba juga aplikasi kompetitor biar tidak seperti katak dalam tempurung. Kemudian buatlah report seakurat mungkin dan sampaikan dengan baik pada tim, jangan salah duga loh, QA ga hanya bisa melaporkan temuan bugs, kita pun bisa membagikan hasil observasi dan analisa produk. Dengan begitu peran QA akan jauh dari kata checking acceptance criteria, sosok QA ga akan bisa digantikan oleh mesin (automated test) yang tidak memiliki nalar diluar assertion yang ditentukan.

Jadi

Saya yakin tim engineering masih butuh sekali QA yang handal, yang bisa ikut gotong royong memberikan fitur yang dibutuhkan pengguna melebihi harapan mereka. Selama kita bisa memberikan yang terbaik untuk tim, selama itu pula kita, Software Tester masih akan dibutuhkan oleh tim.

Share

Salam 👋,

Jadi begini ceritanya, pada suatu sore, disaat jam santuy dan teman-teman saya pada turun untuk sebat dulu, saya berdiri di samping temen Bule, lalu tiba-tiba dia cerita (saya terjemahin ke bahasa Indonesia langsung ya) “Bro, sekarang industru Tech Startup lagi susah funding kan, banyak yang saving cost dengan PHK karyawannya, di kantor lama saya tuh banyak QA yang kena PHK, menurut kamu kenapa korban paling banyak di QA? (dan yang berikut ini keknya lebih pas klo saya tuliskan bahasa Inggrisnya, karena saya bingung mencari padanan kata ini), Do you think testing does not add value to the product?”

Waduh kaget dong ditanya begitu, sebelum langsung jawab, saya minta dia jelasin dlu soal “value” yang dia maksud biar jawabannya sesuai konteksnya ya (kebiasaan QA nih, jangan sampe berasumsi, lebih baik minta elaborasi). Jadi yang dia maksud adalah karena QA masuk ke tim delivery (atau katakanlah tim engineering) harusnya “value” itu adalah “building feature”, dia melanjutkan “misal developer, PM, designer tuh akan bikin fitur atau improving the product, QA mau test sampe jungkir balik pun ga akan bikin produk jadi tambah bagus, klo business milih untuk ga fix itu temuan bugs-nya kan”. 😂

“Betul, dan ya gapapa juga kali”, jawaban saya yang pertama, dia tampak heran 🤔 dan menantikan kelanjutan penjelasan.

“Jadi klo value nya yang kamu maksud dinilai dari bikin fitur, kenapa ga sekalian aja pecat itu lead engineer, engineering manager, atau head of engineer. toh mereka ga bikin fitur, malah gajinya gede pula kan”, terkekeh dia.

Menjadi seorang QA atau Software Tester memang tidak terlibat secara langsung dalam membuat sebuah fitur, seperti yang dilakukan oleh developer dalam mengimplementasi requirement, tetapi:

Seorang Tester akan melakukan proses evaluasi dan menilai hasil sesungguhnya apakah fitur yang dibuat sudah layak untuk dirilis dengan cara melakukan berbagai pengujian, penelitian, penelusuran, percobaan, pertanyaan, penalaran termasuk melihat dari sudut pandang pengguna dengan berbagai persona. ~

Fachrul Ch

Efek sampingnya, kadang ditemukan berbagai masalah dalam fitur/aplikasi yang bisa merusak reputasi dan kepuasan pengguna, diharapkan developer bisa memperbaiki kesalahannya, yup sebuah bugs kan lahir dari celah pada kode yang mereka buat, bukan QA yang bikin sendiri, tapi kebetulan “ketemu” aja (karena bisa jadi kelolosan juga sampe user 😅).

Jadi Intinya

QA/Software Tester berperan dalam membantu tim untuk mengerti hasil pengembangan fitur/aplikasi dan menentukan apakah hasilnya sudah sesuai harapan atau mengukur risiko dari berbagai masalah yang ditemukan yang tentunya akan sangat membantu bagi orang yang mengerjakan fitur.

Tanpa testing (dalam hal apapun), kita tidak akan bisa menilai keadaan, kita hanya bisa menduga-duga seberapa baik kualitasnya (masih teori atau harapan)

Ada analogi yang pas menurut saya, seorang tester itu seperti indikator bensin pada kendaraan, si pengemudi akan dengan mudah menentukan kapan harus mampir ke pom bensin atau lanjut melaju, tanpa indikator bensin, bisa aja si pengemudi akan mengira-ngira seberapa banyak jumlah bensin saat ini, atau berhenti lalu turun langsung mengecek sendiri. Betul kan?

Tapi jangan salah dan kepedean ya, indikator bensin pun bisa saja rusak, tak memberikan informasi yang tepat, wah bisa gawat! perbaiki lah segera agar tetap dipercaya!

Mudah-mudahan bisa menghibur, silakan bebas dibagikan di sosial media kamu ya!

Share ✅ NgeTest Bareng Fachrul 🧑🏻‍💻

Menjadi Penguji

Meme dengan tema menjadi Software Tester

Ini merupakan salah mindset saya dalam menguji aplikasi, dimana tujuan kita bukan untuk breaking software tapi untuk help team to build best possible software

Siapa nih yang serius banget klo jelasin bugs dan severity nya? 😂

Ikutan merinding juga ga klo denger kalimat di atas?

Lah iya juga ya? ahaha

Maap curcol pengalaman pribadi ahaha

Kebiasaan nih emang klo lama ya bilang, kan bisa jalan-jalan dulu ke mall

Meme Test Automation

Di tema ini, saya buat meme terkait software test automation

Jangan mau dibohongi pake “QA kan ga ngoding” ahaha

Karena tuntutan QA jaman now mesti bisa juga ngoding dengan baik dan benar loh

Siapa yang baru tahu kalo katalon studio udah naekin lagi biaya layanan nya?

Saya ga ngikutin sih, cuma seliweran aja dapet info ahaha

Salah sendiri sih ini mah

Sugoi senpai!

No julid ya ini, tapi emang sering kek gini juga 😅

atau ada assertion tapi ga relevan, jadi harap di perhatikan saat review Merge Request ya

Berawal dari sebuah pertanyaan di tanya jawab instagram @penguji.id beberapa hari lalu, yang membuat saya mulai memikirkan Test Management tools yang baik itu yang seperti apa, dan bahkan seberapa penting kah test management ini, sepertinya layak untuk kita kupas lebih jauh.

Apa sih Test Mangement Tools itu?

Saya kutip pengertian dari artikel di Guru99 dengan terjemahan ala kadarnya, “Test management adalah alat yang digunakan untuk menyimpan informasi tentang bagaimana cara pengujian dilakukan, merencanakan aktivitas pengujian tertentu, dan membuat laporan yang menyeluruh tentang status aktifitas pengujian yang berlangsung”. Saya tebalkan kata kunci yang penting dari Test Management Tools ini (kita singkat penulisan menjadi TMT aja ya 😅) seperti testrails, xray, testlink, dkk.

Kenapa Harus Pakai TMT?

Balik lagi ke pertanyaan yang harus kamu jawab, masalah apa yang bisa diselesaikan oleh TMT? Kita akan coba urai dahulu, bagaimana kamu mengelola test case yang ada pada aplikasi yang kamu uji, apakah ada masalah dengan cara yang sekarang.

Kalau Saya akan ambil contoh dari di perusahaan tempat saya bekerja sekarang, maka saya akan menjawab TIDAK HARUS dan TIDAK PENTING.

Lah kok bisa begitu?

Justifikasi saya karena tim nya masih kecil, kurang lebih ada 12 engineer dan saya sebagai QA seorang diri, tidak ada kolaborasi dengan QA lain, reporting testing pun saya compile manual.

Gimana cara memanage test casenya untuk tim kecil?

Nah saya menyimpan informasi tentang test case hanya pada confluence/google docs pageless, menurut saya di sana sudah kaya fitur, saya bisa menyimpan informasi dalam bentuk tabel narasi, checklist, gambar, video/gif ataupun tiket jira/development secara langsung dan sederhana.

Pada saat menjalankan regression test, saya akan copy/duplicate page confluence tersebut dan setiap test case yang passed akan saya centrang checklistnya, kebayang kan?

Dan dengan begitu saya punya gambaran kasar, modul apa saja yang sudah diuji, dan ada berapa banyak lagi modul yang harus di-explore, reporting nya berupa grafis saya buat secara manual di canva saja, berapa persentase pengujiannya, berapa banyak bugs yang ditemukan dan estimasi penyelesaian exploratory test nya.

Terus klo timnya makin berkembang dan QA membernya makin banyak?

Kita akan ambil contoh perusahaan besar seperti Gojek deh ya, kebayang ga berapa banyak jumlah tim engineering yang terlibat di regression testing sebelum aplikasinya di submit ke playstore/app store?

Tentunya ada buanyak orang, dari QA, developer, PM yang terlibat di rilis tersebut, perlu tahu informasi seperti “Testing nya udah sampe mana?”, “Ada berapa bugs yang ketemu sekarang? ada berapa yang critical?”, “Ada tim yang keteteran dan perlu dibantu ga testing nya?” dan semua pertanyaan itu tentu akan sangat melelahkan jika hanya bisa di jawab oleh satu orang, dia pun harus bertanya dulu ke berbagai tim, “eh gofood QA, gimana status testnya?”, “klo tim gocar gimana? ada blocker issue kah”.

Kebayang donk berapa banyak waktu yang diperlukan untuk memberikan update terkini? udah gitu selau berubah pula status testing nya setiap menit.

I see, jadi disitulah pentingnya TMT ya?

Yes, salah satunya itu, karena setiap tim akan mengupdate status testingnya di aplikasi TMT (bisa diupdate secara manual, ataupun berdasarkan hasil test automation), maka bagi pengguna yang lain bisa melihat progress testing antar tim dengan lebih mudah dan realtime.

Trus gimana cara milih Test Management Tools yang bagus?

Ada banyak faktor sebenarnya yang bisa kita jadikan acuan dalam mengevaluasi TMT ini, berikut ini beberapa pertanyaan penting yang saya pakai:

1. Harga

   1. Berapa budget yang sanggup dibayar perusahaan?

   2. Apakah ada pilihan tools yang open source?

   3. Apakah bisa memilih yang Freemium? (gratis untuk sekian user atau sekian test cases)

   4. Jika berbayar, apakah mekanismenya bayar perorang atau ada kompenen tier lain

2. Produktifitas

   1. Seberapa mudah dalam membuat test cases

   2. Kemudahan menyusun TC dalam membuat test runner

   3. Migrasi TC (export/import)

   4. Kemudahaan dalam kolaborasi antar tim

3. Reporting

   1. Informasi yang ditampilkan pada Dashboard

   2. Realtime kah

   3. Aksesnya gimana? perlu login atau bisa publik

   4. Kita perlu fitur export report atau tidak

   5. Apakah menyediakan analytics seperti:

      1. test metrics

      2. most failed

      3. slow test

      4. flaky test

      5. trend

4. Integrasi

   1. apakah bisa diubah statusnya dari automation tool

   2. kemudahan integrasi dengan

      1. jira

      2. slack/email

5. Maintenance

   1. cloud / SaaS

      1. sering down ga

      2. SLA nya gimana

   2. on premise

      1. siapa yang maintenance? devops/QA?

      2. spec server seperti apa?

      3. cost nya gimana

Wah banyak juga ya yang perlu dianalisa?

Betul karena ini perlu komitmen jangka panjang, biasanya kita bisa dapat harga miring kalo bisa nego kontrak dengan vendor TMT ini untuk jangka tertentu, makanya akan sangat repot klo harus ganti TMT, bisa menjadi cost besar atau susah export/import sehingga beberapa informasi akan hilang saat migrasi

I see, jadi bisa bisikin ga TMT apa yang terbaik?

Hmm balik lagi sesuai kebutuhan kamu sih, ibarat punya Ferarri di Jakarta, ga bisa ngebut karena sering macet 😅, jadi perlu dilakukan evaluasi sendiri sesuai kebutuhan kamu, bisa pergunakan point yang saya tulis di atas tadi.

Atau bisa lihat di rujukan dari Guru99 tentang 20 Test Management Tools terbaik

Sejujurnya….

TMT tuh ga esensial loh, masih bisa dicari alternatif lain yang gratis atau bahkan ga perlu TMT.

contoh: timnya sudah memiliki test automation dengan cucumber, bisa pergunakan gherkin file sebagai catatan test case nya, reportingnya bisa gunakan saja reportportal.io , atau numpang ke grafana bareng dev, tapi memang report di awal, namun bisa jadi worthed untuk jangka panjang ketimbang pakai TMT berbayar untuk sekian banyak orang toh.

Sekian

Share ✅ NgeTest Bareng Fachrul 🧑🏻‍💻

Share ✅ NgeTest Bareng Fachrul 🧑🏻‍💻

Mungkin diantara kamu ada yang baru kenal dengan saya, ijinkan saya pada tulisan kali ini untuk memberitahukan informasi singkat mengenai akun instagram @penguji.id dimana saya sering kali membuka kolom tanya jawab di akhir pekan untuk teman-teman.

Saya akan jawab pertanyaannya berupa video komentar saya ataupun rujukan tulisan yang relevan, sehingga teman-teman yang bertanya bisa mendapatkan pemahaman yang baru.

Oia saya pun melakukan arsip jawaban pada profile highlight “tanya jawab” seperti gambar di atas ya.

Yuk kalau teman-teman ada pertanyaan seputar software testing bisa ditanyakan di instagram profil @penguji.id , tak perlu menunggu ada QnA, saya pun sering mendapatkan DM pertanyaan dan akan saya jawab segera saat saya online

Terima kasih banyak 😁

Share ✅ NgeTest Bareng Fachrul 🧑🏻‍💻

Tentu saja ini bisa jadi sangat membingungkan terutama bagi pemula dikarenakan minimnya pengalaman, namun tak jarang pula saya termui kandidat senior yang terkesan hanya "bawa diri" saja, tanpa mempersiapkan portofolio pada proses melamar pekerjaan baru juga loh!

Lalu bagaimana cara agar kamu bisa meyakinkan perusahaan bahwa kamu sudah memiliki keahlian yang dibutuhkan dan layak untuk mendapatkan kesempatan bekerja di perusahaan itu?

Jawabannya adalah dengan melampirkan pengalaman/portofolio yang relevan dengan keahlian QA sehingga membuat kamu menjadi jauh lebih menonjol dibandingkan kandidat lain, berikut ini adalah kiat mempersiapkan portofolio bagi seorang Software Quality Assurance menurut pengalaman saya pribadi

1. Test Automation Framework

Bisa membuat test automation sendiri sudah barang tentu akan membuat kamu lebih berkilau, ini menunjukan kamu memiliki keahlian koding dan cocok menjadi kandidat test engineer yang tentu dibutuhkan di perusahaan, karena di beberapa startup (khususnya unicorn) sudah mencantumkan keahlian automation sebagai skill wajib di beberapa lowongan QA/SDET.

Namun, sulit menilai seberapa baik keahlian koding automation kandidat hanya dari percakapan interview, meluangkan waktu untuk belajar dan membuat test automation framework sendiri merupakan persiapan yang layak, tapi jangan berkecil hati jika kamu baru berada pada level sebagai penguna framework yang sudah ada seperti menggunakan Serenity BDD (java), Robot Framework (python) ataupun Codeception (PHP/Javascript) untuk project automation kamu, itu sudah keren loh!

Pada Test Automation Framework ini, kamu bisa membuat pengujian backend API, web browser automation, mobile automation atau bahkan gabungan semua automation tadi, pasti keren banget!

Berangkat dari pengalaman sebagai penguji kandidat SDET (software development engineer in test), saya akan bocorkan beberapa poin penting yang akan dilihat oleh interviewer yaitu:

• Apa yang di-automation?: Kamu bebas membuat automation web/aplikasi umum/publik, seperti ecommerce, social media, CMS atau web pribadi, tetapi jangan sampai membuat test automation untuk menguji basic functionality saja seperti halaman login ya! Harap membuat test automation untuk scenario yang memiliki dengan beberapa (berbagai) halaman web/mobile.

• Clean code: Dengan membagikan kode karya kamu, semua orang bisa menilai keahlian kamu dalam menuliskan kode secara konkrit, bisa dilihat dari bagaimana kamu memilih tipe data yang efisien untuk tujuan tertentu dan bagaimana kamu menggunakan strategi reusable code pada struktur kode kamu (design pattern)

• Selector yang dipilih: Interviewer bisa melihat pengalaman kamu menggunakan selenium/appium dari cara kamu menentukan locator/selector pada element, apakah cukup unik dan kokoh, seberapa ahli dalam menggunakan xpath untuk element yang sulit, jangan pula banyak memakai xpath yang kaku ataupun css selector yang cenderung berubah

• Page Object Model: Menandakan kamu paham akan design pattern yang umum dipakai, POM yaitu mengelompokan element pada satu halaman menjadi satu object khusus, eh tapi tidak menutup kemungkinan juga kalau kamu mau menggunakan design pattern lain semacam screenplay pattern loh

• Commit Message: kita bisa melihat kedewasaan kode dari cara kamu menuliskan git commit message, seberapa deskriptiv, seberapa sering menulis kode, cara kamu membuat branch baru untuk mengerjakan fitur baru (walaupun repo sendiri sih 😅 )

Opsi tambahan yang bisa meningkatkan value automation framework kamu, khususnya untuk kandidat senior/leader :

• Parallel support: test automation kamu bisa berjalan secara paralel dan cepat

• Support multi browser/platform: pengujian mendukung untuk ios/android/chrome/firefox, portability test runner pada windows/linux/macos

• Custom Gesture: ada interaction gesture khusus seperti swiping dan pinching

• Visual automation: topik yang sedang hangat, tentu akan membuat kamu bersinar di mata penguji

• Data-driven testing: jika memungkinkan bisa mengimplementasikan penggunaan spreadsheet files dalam menjalankan test yang repetitif

• Database connection: proses setup data sebelum test dimulai, ataupun query untuk assertion process

• Performance testing: memiliki keahlian non-funcitonal testing seperti ini umumnya tidaklah wajib, tapi tentu akan membuat kamu menjadi makin cemerlang

2. Test Case/Scenario untuk Sebuah Requirement (bisa BDD spec)

Banyak perusahaan mempraktikan test automation dengan menggunakan BDD (cucumber), tentu saja kamu bisa membagikan .features files dimana kamu menulis kode gherkin untuk suatu test scenario.

Mungkin bagi kamu yang baru memulai karir QA, sedikit bingung pada bagian ini, oke saya akan jelaskan sedikit:

Test case atau test scenario adalah rancangan pengujian yang berisi informasi mengenai hal apa saja yang harus dinilai kelayakannya, lalu langkah pengujian, serta ekspektasi dari hasil yang di harapkan

Misal contoh penulisan gherkin untuk test scenario:

Given the admin is logged in
When the admin deletes a post on the blog
Then the post moved to deleted section
And a successful deleted message should display

Apa yang dinilai:

• Kejelasan penulisan scenario test: ada yang bilang .feature files adalah living documentation, dimana kamu harus bisa menuliskan test scenario yang mudah dipahami, bahkan oleh orang awam yang baru pertama kali melihat feature files ini, apakah cukup konteks yang diberikan pada step "Given", apakah suatu action dituliskan pada step "When" dst

• Standar penulisan Gherkin file: banyak yang salah kaprah dan salah menuliskan step yang harusnya pada step yang Given tapi malah menggunakan When, atau overuse keyword (given-when-then), hindari pula ketidak konsistenan sudut pandang orang pertama atau ketiga, 

• Declaratif vs Imperatif: Cenderung subjektif, tapi cara penulisan yang saya sukai adalah menuliskan test scenario secara Declarative, selain lebih singkat dengan begitu pula menjadi mudah dibaca, tinggal bagaimana nanti di implementasikan di step definition untuk menyusun blok kodenya, ada artikel yang menjadi sumber inspirasi saya disini. tetapi harap diperhatikan risiko masalah yang mungkin timbul, seringkali dengan menggunakan declarative style test step menjadi kurang detail dan informatif terkait apa yang terjadi, seimbangkan saja antara imperative (too much details) dengan declarative (not enough details) 

3. Laporan Bugs

Saya teringat kisah teman saya si Anggadirja saat interview di Sleekr HR, tempat saya bekerja dulu, di hari dia interview, sang bos besar tiba-tiba melaporkan ada seseorang bernama Angga (tau dari email yang dipakai) yang melakukan spam signup pada environmen Demo di production, karena dia membuat kurang-lebih sekitar 50 perusahaan baru bertubi-tubi, sontak saja kita konfirmasi ke si Angga saat itu sedang interview dan dia pun mengakui disertai bukti temuan issue apa saja yang telah dia dapatkan dari aktifitas tersebut! sekilas, saya melihat wajah interviewer yang saat itu geleng-geleng pun tersirat senyum kagum 😂

Memberikan laporan bugs saat interview memang sebuah kesan yang istimewa, sepanjang karir saya meng-interview kandidat QA/SDET hanya dia yang menyetorkan laporan bugs tanpa diminta, menurut saya ini adalah sebuah bukti kalau kandidat bisa bekerja sebagai QA dan memiliki keahlian yang mumpuni (tergantung dari level bugs yang ditemukan).

Disaat saya melamar kerja pun beberapa kali melampirkan hasil temuan bugs saya, dan selalu saya lihat wajah kaget dan takjub dari para interviewer (mungkin setelah ini banyak yang mengikuti jadi lumrah ahaha 🤣)

Tidak mesti kamu harus menemukan bugs baru pada aplikasi yang dibuat oleh perusahaan dimana kamu melamar, bisa juga kamu membagikan temuan bugs dari aplikasi umum, seperti temuan kamu saat menggunakan aplikasi Ojek online, ataupun issue saat kamu menggunakan instagram, yang penting adalah kamu membuat sebuah dokumentasi akan temuan kamu ini

Apa yang dinilai:

• Penulisan laporan bugs: Kamu harus memiliki struktur laporan bugs yang baik, setidaknya terdiri dari penjelasan temuan masalah dan langkah reproduce nya

• Level temuan: Seberapa critical bugs yang kamu temukan, bisa jadi issue UI, functional atau bahkan blocker, semakin parah temuan kamu maka kamu akan terlihat semakin keren (dan mungkin berfikir, ngapain aja QA internal perusahaan itu, sampai kelolosan ahaha #julidModeON )

• Saran: Sertakan ide perbaikan yang kamu harapkan, seberapa masuk akal expected result dari bugs tersebut, atau bahkan jika kamu tidak menemukan bugs/issue kamu pun bisa saja menuliskan saran perbaikan dari suatu proses

• Analisa: Sangat keren sekali apabila kamu bisa membuat analisa risiko dari temuan kamu tersebut, kamu bisa membahas risiko yang mungkin diderita pengguna dengan adanya bugs tersebut, yang sering kali luput oleh tester adalah menguji accesibility pada aplikasi, seringkali aplikasi menjadi kurang friendly untuk pengguna lanjut usia yang biasanya menggunakan font size besar, dan aplikasi menjadi tidak tersusun baik, bahkan bisa jadi tombol submit menjadi tertimbun element yang overlap

Berikut ini contoh laporan bugs:

jangan lupa sertakan juga gambar tangkapan layarnya/screenshot disertai hightlight masalahnya ya

4. Kontribusi

Kontribusi seorang QA sering kali tidak terdokumentasikan, baik itu kontribusi teknis ataupun non teknis, mungkin karena kita menganggap itu terlalu  biasa saja atau malas menuliskannya.

Saya akan membagikan contoh kasus non teknis berdasarkan pengalaman saya, jadi pada tahun 2020 dulu di Golife (waktu masih ada), dimana saya melakukan perubahan bagaimana QA status update menjadi lebih menarik dan interaktif.

Pada awalnya QA update pada periode testing berupa informasi grafik test run progress dari testrail, hanya berupa angka persentase dari jumlah total test cases berbanding dengan jumlah test case yang sudah diuji, lalu saya ubah ini menjadi status update yang berupa story telling dan ini berdampak positif, dari engagement tim yang tinggi, dengan begitu kita bisa mengetahui bahwa tim membaca dan memperhatikan progress testing yang ada.

Untuk contoh kontribusi teknis, saya akan membagikan kisah saya membuat semacam "Cheat engine" agar proses testing manual menjadi jauh lebih cepat 95% hingga mendapatkan spotlight untuk showcase di Gojek Townhall November 2021

Atau pun bisa kita tuliskan bagaimana test automation yang sudah terimplementasi CI/CD bisa membantu proses relese lebih cepat dengan menjaga kualitas aplikasi tetap tinggi disetiap build barunya, cerita bagaimana kami bisa mengurangi waktu full cycle testing, awalnya 3 hari menjadi 1,5 hari kerja.

5. Pitch deck

Saya masih ingat ketika saya membuat pitch deck saat apply sebagai QA Leader di GoMart, saat itu head of engineering langsung kepincut dengan apa yang saya lakukan, karena saya sungguh-sungguh membuat slide berisi pengalaman, cara kerja saya, visi saya tentang Quality Assurance, serta misi saya dalam membangun tim, tujuan pitch deck ini adalah memudahkan saya "menjual (keahlian) diri" dalam proses interview, saya lebih nyaman menggunakan presentasi daripada hanya bercerita secara verbal, mungkin ini ide saya mengakali interviewer saat itu yang orang India, jadi mengurangi grogi saya karena menggunakan bahasa Inggris, jadi menghindari saya melupakan topik yang harus saya bahas karena sudah direncanakan di slides.

Karena intinya interview adalah seperti mencari jodoh, bisa jadi yang dicari perusahaan sejalan dengan visi & misi pribadi kita.

Bagaimana cara menyajikan portofolio?

Google Slides/Documents

Di poin terakhir saya sudah singgung sedikit mengenai slides (pitch deck) saya, saya akan membagikan link google slides kepada interviewer sebelum proses interview (bisa sehari sebelum) agar mereka bisa melihat dahulu lalu didiskusikan/ditanyakan saat interview, kenapa menggunakan google slides? Karena itu memungkinkan saya untuk bisa memperbarui konten, hal yang tidak bisa terjadi jika saya mengirimkan lampiran file .ppt, tentu jika ada perubahan harus mengirimkan file susulan.

Bisa juga ketika kita ingin menjabarkan informasi lebih banyak untuk membuatnya berupa google documents (word) berformat seperti esai, cocok untuk konten bugs reporting yang kita temukan, ataupun cerita soal analisa bugs seperti pembahasan sebelumnya

Github

Kode automation yang sudah kita buat alangkah baiknya kita simpan di akun github, walaupun bisa juga gitlab/bitbucket tapi agak kurang populer, oia perlu diingat untuk tidak menyimpan akun kredensial di repositori ya (atau membuat repository menjadi privat)

Github ini merupakan etalase untuk pamer keahlian koding kita, namun perlu diperhatikan juga apa tujuan kamu membuat repository baru:

• Untuk membuat Proof of Concept dari tools baru

• Membandingkan pilihan library / concept secara head to head

• Mempraktikan tutorial yang sedang dipelajari

Agar akun profil kamu tidak terlalu ramai repository yang dangkal dan menambah kebingungan bagi pengunjung profil kamu.

Website

Memiliki website pribadi ibarat sebuah KTP, karena website adalah online presence kita, sebuah tempat dimana kita menunjukan pribadi seperti apakah kita, tempat kita bisa memamerkan pengalaman kita, opini serta keunikan kita.

Tentu saja, ini adalah sebuah keputusan yang sangat baik. Saya berasumsi ini akan terlihat lebih profesional, bahkan saya rasa faktor ini menentukan saya diterima kerja sebagai Software Engineer di Gojek tempo hari, karena aspirasi saya terhadap QA tertuang di website ini fachrul.id

Saya rasa ini bukanlah hal sulit kan? Web saya ini pun saya hosting di github hanya dengan static html tanpa koneksi database, bermodal sebuah domain saja, justru yang sulit adalah mengisi konten nya, ahaha

Demikian kiat singkat (walau ternyata panjang) dari pengalaman saya dan teman-teman saya, semoga bisa bermanfaat dan membantu kamu mendapatkan pekerjaan impianmu, jangan lupa sapa saya di Instagram ataupun Youtube Ngetest bareng Fachrul

Bahkan teman dekat saya pun terkenda dampak layoff dari perusahaan teknologi yang bisa dibilang paling besar di Indonesia

Berikut ini saya sudah buatkan video bocoran terkait dengan pertanyaan umum yang biasanya saya tanyakan saat saya menjadi pewawancara kerja untuk software quality assurance di kantor.

Oia ini cuma pertanyaan aja ya loh ya 😅, kenapa ga sekalian jawaban? karena banyak jawabannya bersifat subjektif, jadi alangkah baiknya kalau riset mandiri untuk mencari jawaban versi sendiri 🤩

Adalah salah satu pertanyaan yang sering saya dapatkan ketika penanya sedang aktif melamar pekerjaan #qualityAssurance. 

Ternyata banyak juga yang masih bingung untuk menyusun portfolio kerja sebagai #QA #SDET baik yang entry level ataupun yang sudah memiliki pengalaman kerja, ga mesti harus bisa #testAutomation #selenium #appium juga sih 

Berikut ini kiat beradasarkan pengalaman saya, silahkan tambahkan kiat kamu di komentar juga ya 🙏🏻😄