Menjadi Software Tester Katanya Gampang? (RPL ULBI)

1. susah cari/rekrut tester handal

1.1. ga diajarin di kampus

1.2. CV asal asalan

1.3. gagal di interview

1.4. susah di uji dengan 1 jam interview

1.5. kebanyakan subjektif

2. wajib pinter ngatur waktu

2.1. perburuan ke akar rumput

2.1.1. debugging

2.2. reproduce-able bug

2.2.1. > 2x

2.3. ga ketahuan ujung nya dari sini

2.3.1. estimasi

2.3.2. budgeting waktu

2.4. sisa buat belajar

2.4.1. mengasah pisau

2.4.1.1. ga cuma diabisin buat ngeTest doank

2.4.1.1.1. nulis report

2.4.1.1.2. konfirmasi

2.4.1.1.3. kolaborasi

3. jadi harapan bangsa

3.1. plis jangan ada bugs ya

3.2. waktunya mepet nih, test nya yg cepet aja

3.3. loh kok bisa ada issue di production

3.4. kok ga tau fitur ini ada perubahan

3.4.1. meeting aja ga diajak

4. mesti sabar

4.1. kurang di apresiasi

4.1.1. klo fitur bagus lancar di production

4.1.1.1. keren dev nya nih koding nya gada issue

4.1.2. klo ada issue di production

4.1.2.1. kenapa di integration ga ketemu ya?

4.2. bugs susah di reproduce

4.2.1. mungkin harus ini dulu

4.2.2. akun spesifik

4.2.3. ilang timbul

4.2.4. detektif dadakan

4.2.5. debug aplikasi

5. masa iya?

5.1. under estimate

5.2. NgeTest asal-asalan emang lebih gampang daripada ngeDevelop asal-asalan

5.3. tapi ngeTest yang bener-bener bagus lebih susah dicapai daripada develop yang bener-bener bagus

5.3.1. rispek dev handal

6. harus punya keahlian yang luas

6.1. core skill tester

6.1.1. teliti

6.1.2. berfikir kreatif

6.1.3. cepat tanggap

6.1.4. menerawang bugs

6.1.5. komunikasi bagus

6.1.5.1. nanti di bahas lagi

6.1.6. harus cepat belajar

6.1.6.1. banyak yang mesti dipelajarin

6.2. teknis

6.2.1. bisa baca kode

6.2.1.1. MR dev

6.2.1.2. unit test

6.2.1.3. full stack?

6.2.1.3.1. FE

6.2.1.3.2. BE

6.2.1.3.3. Mobile

6.2.2. bisa nulis kode

6.2.2.1. automated test

6.2.2.1.1. clean code

6.2.2.1.2. DRY

6.2.2.1.3. design pattern

6.2.2.1.4. git/collaboration

6.2.2.2. data generator

6.2.2.2.1. SQL

6.2.2.2.2. scripting

6.2.3. CI/CD

6.2.3.1. continuos testing

6.2.3.2. pipeline

6.2.3.2.1. gitlab

6.2.3.2.2. bitbucket

6.2.3.2.3. github actions

6.2.3.2.4. circleci

6.2.4. non functional test

6.2.4.1. performance test

6.2.4.2. accessibility

6.2.4.3. usability

6.2.4.4. UI/UX

6.2.4.4.1. android guideline

6.2.4.4.2. apple guideline

6.3. business

6.3.1. paham modul A, B, C

6.3.2. paham integrasi 3rd party

7. mesti ngelotok itu business process

7.1. module A dan B saling terkait

7.2. proses sebelum ini

7.3. proses setelah ini

7.4. integrasi dengan partner / 3rd party

7.5. ga bisa kepake klo ngelamar kerja di bidang lain

8. menelisik berbagai sudut pandang

8.1. dev

8.1.1. technical constraint

8.1.2. kenapa approach nya harus gini

8.2. end user

8.2.1. klo anak muda

8.2.2. klo akses di desa

8.2.2.1. internet lemot

8.2.2.2. device lama

8.3. product owner/stakeholder

8.3.1. gimana cara menyajikan informasi

8.3.2. apa yang mungkin mereka perlu tau

8.4. jadi embrace overthinking

8.4.1. beli sayur

8.4.1.1. bisa diapain aja ini bahan

8.4.2. naek bus

8.4.2.1. faktor apa aja yang bisa bikin delay sampai tujuan

8.4.3. naek KRL

8.4.3.1. berapa kapasitas maksimum satu gerbong di jam padat

8.4.4. pake aplikasi kompetitor

8.4.4.1. masa iya sih gada bug

9. jago komunikasi

9.1. report bugs yang mudah dipahami

9.2. dokumentasi yang informatif

9.3. jago menyampaikan berita buruk

9.3.1. ada bugs di akhir jam kerja/sprint/sebelu liburan

9.3.2. reopen issue

9.3.3. issuenya ketinggalan

10. ga sebanding

10.1. rasio dev : qa

10.1.1. jumlah lowongan

10.1.2. less of a voice