Pilar Ketiga Agile Software Development: Kualitas Teknis yang Tinggi & Terjaga (bag. 1)

Navigasi esai: Intro & Pilar 1 | Pilar 2 | Pilar 3 (bagian 1) | Pilar 3 (bagian 2)


Jika hanya membaca pilar 1 & pilar 2, programmer pemula pasti langsung khawatir,

“kalau requirement bisa berubah drastis—apalagi dipaksa rilis setiap minggu—pasti fase testing dikorbankan. Kode juga jadi berantakan. Agile ini lebih neraka dari waterfall.” ~ seorang programmer pemula

Mereka tahu 3 bulan lagi, kode program mereka sendiri akan seperti sphagetti. Cukup berantakan hingga mereka kesulitan menulis kode fitur baru.

Mereka tahu akan dibangunkan tengah malam, karena harus memperbaiki bug fitur pembayaran yang merugikan kas perusahaan.

Jangan sampai ketangkasan Agile Software Development justru membuat perusahaan rugi milyaran rupiah, karena bug yang krusial, serta penurunan performa developer. Lebih-lebih, membuat developer mengundurkan diri. Ingat pilar 1? Makin lambat tim developer berkerja, makin sulit untuk tangkas.

Untuk itu, Agile Software Development butuh pilar ketiga. Pilar yang umumnya diketahui & dikuasai programmer tingkat ahli.

Pilar 3: Kualitas Teknis yang Tinggi & Terjaga

“Semua binatang yang tangkas, pasti punya kaki & tangan yang kuat, juga paru-paru besi.”

Navigasi:

Masalah i: Deskripsi Pekerjaan yang Besar & Abstrak

Bug & miss-estimasi tidak selalu 100% salah programmer.1 Kadang programmer menerima deskripsi pekerjaan yang kurang jelas & detail, sehingga programmer:

  • a) membuat asumsi yang salah, atau
  • b) luput memikirkan skenario-skenario munculnya bug, atau
  • c) terlewat banyak hal dalam mengestimasi lama waktu pengembangan.

Solusi:

  • Sebagaimana solusi masalah e (bos yang semua maunya harus dituruti), menulis deskripsi pekerjaan dengan format User Story adalah awal yang baik. Karena ditulis dari sisi manfaat pengguna, proses memperkecil ukuran user story jadi lebih mudah. Contoh: user story ‘pembayaran’ bisa dipecah-pecah, yang mana salah satunya adalah ‘pembayaran dengan bank ABC via transfer ATM’.
  • Salah satu
  • Dengan diperkecilnya lingkup user story, penggambaran detail pekerjaan jadi lebih mudah. Eksplorasi segala kemungkinan skenario pengguna di fitur tersebut. Dokumentasikan sebagai acceptance criteria dari user story terkait.
  • Terima pekerjaan user story dari developer hanya jika sudah memenuhi acceptance criteria.
  • Jika ada perubahan detail user story—bahkan di tengah pengerjaan—segera perbarui acceptance criteria.

Masalah j: Tes yang Manual

Kenapa programmer pemula di atas memprediksi bahwa fase testing akan dikorbankan? Itu karena fase testing makan waktu. Kenapa makan waktu? Karena banyak sekali skenario yang harus dijalankan oleh seorang tester. Mulai dari skenario positif (tidak error) sampai negatif (error). Selain lama, peluang tester melakukan kesalahan juga meningkat.2

Di sisi lain, setiap dua minggu sekali, tim developer dikejar-kejar orang bisnis. Mereka menagih fitur-fitur baru yang harus sudah siap dikirim ke App Store & Play Store. Mereka ragu masih sempat untuk testing.

Solusi:

  • Biarkan komputer yang mengetes

Bagaimana komputer bisa mengetes software? Kuncinya ada di user story, lebih tepatnya di acceptance criteria-nya yang detail. Ternyata, acceptance criteria bisa ditulis dalam format yang ramah-komputer, lalu dimasukkan ke software penguji (KatalonSelenium, dll). Dengan begitu, tinggal tekan satu tombol, software penguji langsung menilai apakah software kita bermasalah atau tidak. Dan ini yang penting: bukan tester yang menjalankan software penguji, melainkan developer—sepanjang pengembangan pula!

Tidak heran, timbul paradigma baru dalam mengembangkan software: test-first-development. Tulis dulu test scenarios & test cases di software penguji, baru tulis kode programnya. Ada perubahan? Permintaan baru? Bug? Perbarui test scenarios & test cases.

Acceptance criteria (test scenarios & test cases) tumbuh beriringan bersama software.

Hasilnya? Software yang berkualitas. Karena terjaga dari bug-bug akibat tangkasnya pengembangan. Tidak lagi perlu takut, kalau perubahan di iterasi ini akan merusak jalannya fitur yang diselesaikan di sepuluh iterasi lalu.

Berikut contoh user story—meski tidak lengkap karena tidak ada Why—yang ditulis tester dalam format ramah-komputer:

Terlihat kalau tidak ada test case yang negatif. Sumber: KMS Technology

Solusi:

  • Wajibkan menulis acceptance criteria pekerjaan dalam format yang bisa dibaca software penguji. Pekerjakan test engineer.

Masalah k: Integrasi & Rilis Kode yang Sulit

Dua masalah sebelumnya (i & j) bisa terjadi saat programmernya hanya satu. Masalah ini, baru muncul saat programmernya lebih dari satu. Familiar dengan keluhan-keluhan berikut?

  • “Tahu gak sih? Bug kemarin itu cuma gara-gara si Jihan update library X.”
  • “Iya bos. Kerjaan aku udah beres dan siap rilis. Tapi karena si Jojon belum selesai, jadinya harus nunggu.”
  • “Pusing aku waktu itu. Di staging jalan, di production tidak. Ternyata eh ternyata, biang keladinya adalah hotfix-nya Jodi di production kemarin malam.”

Solusi:

Bersambung ke bagian 2.

  1. Tentu programmer juga punya andil di masalah ini, karena menerima begitu saja pekerjaan yang masih besar & abstrak. Mereka terlalu takut untuk bicara. Sesuatu yang sering terjadi di perusahaan yang punya masalah h (budaya pasif).
  2. Tes yang manual oleh manusia tetap penting. Karena—setidaknya sampai saat ini—hanya manusia yang cukup akurat menguji kemudahan software saat digunakan manusia lain. Jadi ranahnya lebih ke UI dan UX. Namun, jika kita bicara tentang pengujian ribuan—bahkan jutaan—skenario input-output software, mulai dari dibukanya aplikasi sampai ditutup, komputer jauh lebih efisien & efektif dibanding manusia.
  3. Setuju dengan pembaruan Mark dari Microsoft atas The Joel Test, menurut saya saat ini version control sudah jadi norma. Meski begitu masih  saya masukkan di tulisan, karena masih ada institusi pendidikan yang kurang dalam mengajarkannya.

Product Manager dari Learn.AgileCampus.org

Ada pertanyaan atau pendapat?