MPPL - Kuis 1 (Setelah UTS)

Panduan membaca ringkasan ini (eaa):
nomor yang ditulis = nomor dari kuis pak Pane
info setelah tanda ':' = jawaban kuis yang bener
tanda '>' = catatan tambahan dari slide
tanda '(?)' = jawaban masih diragukan

nb.
- ada beberapa soal kuis yang gw modif, misalkan 'berikut ini yang tidak termasuk ...' bs diubah jadi 'yang termasuk dalam ... adalah'
- jawaban belum tentu benar, tolong dicocokin lagi sama kunci jawaban/slide, soalnya gw bikin ini sambil belajar jg jd ga sepenuhnya liat dr kunci jawaban
Happy studying~

1. Secara sederhana, kualitas adalah: kesesuaian terhadap kebutuhan produk
    > testing tidak membuat software menjadi sempurna
    > jika requirement awal tidak diketahui dengan baik, maka akan sulit memberikan software yang sesuai dengan kebutuhan konsumen, karena kebutuhan tersebut tidak jelas diketahui.

2. Rencana uji / test plan sebaiknya memuat hal-hal berikut:
    1. Kasus uji/test case
        > test case adalah deskripsi dari interaksi tertentu yang dilakukan tester untuk menguji sebuah behaviour dari software.
   2. Mekanisme eksekusi pengujian
   3. Poin kebutuhan yang ingin diuji

3. Istilah triage dalam defect tracking system mengacu kepada hal-hal berikut:
    1. kaji ulang defect, khususnya sumber timbulnya defect tersebut
    2. strategi penulihan piranti lunak/ defect yang ditemukan setuntas mungkin
    3. prioritisasi defect berdasarkan dampaknya terhadap fungsionalitas piranti lunak secara keseluruhan

4. Smoke test adalah uji untuk: menguji representasi tipikal dari fungsionalitas piranti lunak yang ada
    > smoke test bukan merupakan pengganti untuk uji fungsionalitas piranti lunak yang aktual

5. Masalah yang umumnya timbul terkait dengan kegiatan estimasi adalah: waktu/effort dimark-up untuk kepentingan pribadi (?)

6. Broken build merupakan masalah yang muncul terkait dengan kegiatan programming dan dapat diatasi dengan: mengembangkan code berbasis test-driven (?)
    > broken build = programmer memberikan build yang doesn't work (kayanya maksudnya disini itu build versi lama, build yang ada syntax error, dll. kayanya ya), sehingga tester tidak mampu melakukan uji terhadapnya.

7. "Piranti lunak yang terinstalasi baik di sisi pengembang ternyata tidak dapat terinstalasi di sisi pengguna" adalah contoh masalah yang terkait dengan: Testing
    > masalah testing lainnya =
       1. missing requirement: sulit untuk ditemukan tester karena bahkan programmer yang membuat code-nya tidak dapat menemukannya saat melihat hasil kerjanya sendiri
       2. Obvious Bugs slipped through: bisa karena tester yang tdk berpengalaman, tester berpengalaman yang kurang cukup waktu untuk membuat test plan, dan release software yang dilakukan berdasarkan jadwal, bukan kualitas

   > masalah selain testing = requirements problems & programming problems
   > requirement problems antara lain = iteration abuse (programmer kirim build after build, user & stakeholder cuma make small changes to each build); scope creep (user & stakeholder membuat perubahan requirement setelah programming dimulai. perubahan biasanya kecil sehingga programmer setuju" saja untuk mengubah. padahal, hal tsb bisa memperlambat project)
   > cara handle requirement problems = requirement dibuat sejelas mungkin sebelum mulai dikerjakan; menggunakan change control process untuk handle changes yang masih ada

   > programming problems = haunted by old problems (old bugs suddenly reappear without warning), broken builds, spaghetti code (source code yang memiliki struktur kontrol kompleks dan berbelit-belit; kemungkinan terjadi karena me-maintain old code).
   > cara handle programming problems = menggunakan version control; menggunakan unit tests dan test-driven development; refactoring

8. Penyebab gagalnya perubahan dilaksanakan dalam suatu organisasi:
    1. pada dasarnya, perubahan bukanlah sesuatu yang nyaman untuk diterima
    2. perubahan dikonotasikan sebagai konsekuensi dari kesalahan di masa lalu
    3. tidak mudah meyakinkan bahwa perubahan akan membawa efek/akibat yang positif

9. Sindrom "not invented here" adalah dalih umum yang disalahgunakan untuk menolak: inovasi eksternal karena bukan ciptaan internal

10. "Gagal dengan cara konvensional lebih baik daripada sukses dengan cara inkonvensional" adalah anggapan untuk cari aman akibat manifestasi dari common excuse: it's too risky (?)

11. Jelaskan maksud dari pernyataan berikut ini = "testing does not make the software perfect"
     : jika requirement awal tidak diketahui dengan baik, maka akan sulit memberikan software yang sesuai dengan kebutuhan konsumen, karena kebutuhan tersebut tidak jelas diketahui.

12. Jelaskan 3 faktor yang dapat mendorong suksesnya penerapan perubahan di dalam suatu organisasi!
1. prepare your organization
    > ambil hal positif dari work yang sudah lewat
    > buat change terlihat straightforward
    > dapatkan dukungan dari tim
    > tunjukkan bahwa change dapat menyimpan lebih banyak waktu dan tenaga
    > tetap berpegang pada fakta
2. plan for change
    > buat dokumen vision & scope, yang mendeskripsikan scope of change
    > inspect & approve dokumen untuk mendapatkan konsensus
    > masukkan changes pada schedule
3. push for consensus
    > bantu organisasi untuk menyadari bahwa mereka memiliki masalah, dan tunjukkan bahwa anda memiliki solusinya.