1.4.3 Studi Perbandingan: Daily Standup dan QA Involvement di E-Commerce vs Fintech

Apa itu Daily Standup Meeting?

Daily standup meeting adalah salah satu praktik utama dalam metodologi Agile, khususnya kerangka kerja Scrum. Pertemuan ini dilakukan setiap hari dan biasanya berlangsung singkat, sekitar 15 menit. Tujuan utamanya adalah untuk memfasilitasi komunikasi antar anggota tim lintas fungsi, terutama terkait perkembangan pekerjaan, rencana harian, serta hambatan yang sedang dihadapi.

Meskipun sering dianggap sebagai rutinitas formal, daily standup yang dijalankan dengan efektif memiliki dampak besar terhadap kelancaran koordinasi tim dan kesuksesan sprint. Dalam tim pengembang perangkat lunak modern, keterlibatan QA (Quality Assurance) dalam daily standup memegang peran strategis yang sering kali belum dimaksimalkan. QA tidak hanya bertugas untuk menguji setelah pengembangan selesai, tetapi juga merupakan bagian aktif dari proses pengembangan yang harus selalu mengikuti dinamika perubahan, risiko, dan prioritas setiap hari.

Mengapa QA Memiliki Peran Penting dalam Daily Standup Meeting?

        Keterlibatan QA dalam daily standup bukan hanya formalitas, melainkan bagian penting dari kerja kolaboratif dalam Scrum. Melalui forum ini, QA dapat menyampaikan informasi penting yang berdampak langsung terhadap kualitas produk dan keberhasilan sprint. Berikut adalah beberapa alasan mengapa peran QA sangat penting dalam daily standup:

●   QA sebagai penghubung antara spesifikasi dan implementasi. QA memahami konteks requirement serta konsekuensi teknis yang mungkin muncul di lapangan. Saat QA menyampaikan temuan dalam stand up, tim bisa segera mengantisipasi kemungkinan bug, regresi, atau kekurangan dalam acceptance criteria.

●    Deteksi dan eskalasi hambatan lebih cepat. QA sering kali mengalami kendala seperti environment yang tidak bisa diakses, kegagalan automation test, atau fitur yang belum bisa diuji karena adanya bug blocker. Jika QA tidak menyampaikan ini secara langsung, hambatan tersebut bisa terlambat ditangani.

●      Meningkatkan rasa tanggung jawab bersama terhadap kualitas. Ketika QA rutin melaporkan progres dan tantangan yang dihadapi, tim menjadi lebih sadar bahwa kualitas bukan hanya tugas QA, melainkan tanggung jawab seluruh tim.

Jika QA hanya hadir sebagai “pendengar pasif” atau bahkan tidak hadir, maka tim akan kehilangan wawasan penting yang berpotensi memperlambat sprint atau menurunkan kualitas produk.

●      Menyampaikan hasil pengujian hari sebelumnya.
Contoh: “Kemarin saya menyelesaikan pengujian fitur Top-Up Wallet dan menemukan 2 bug minor di validasi input.”

●      Menjelaskan rencana pengujian hari ini.
Contoh: “Hari ini saya akan fokus melakukan regresi pada fitur QRIS karena ada perubahan dari backend.”

●      Mengangkat blocker yang menghambat pengujian.
Contoh: "Saya tidak bisa akses environment staging sejak kemarin sore. Mohon bantuan dari tim DevOps.”

●      Berbagi wawasan atau observasi kualitas.
Contoh: “Setelah menjalankan 50 skenario pengujian, saya melihat waktu respons API menjadi lebih lambat dari sebelumnya.”

●      Memberikan masukan kritis terkait produk yang berkualitas.

Contoh: "Tombol checkout terlalu kecil, sebaiknya diperbesar agar lebih mudah di klik oleh pengguna."

2.    Risiko Jika QA Tidak Terlibat atau Pasif

Jika QA pasif atau tidak hadir dalam daily standup, maka tim akan menghadapi sejumlah risiko berikut:

●      QA tidak mengetahui progres pengembangan, sehingga sulit mempersiapkan tes lebih awal.

●      Bug baru terdeteksi mendekati akhir sprint, padahal waktu pengujian sudah sangat terbatas.

●      Developer merasa fitur sudah “selesai”, padahal belum divalidasi oleh QA.

●      Masukan  QA terhadap persyaratan atau edge case tidak masuk ke dalam diskusi teknis.

●      Tumpukan pekerjaan pengujian di akhir sprint bisa menyebabkan keterlambatan rilis.

3.      Praktik Terbaik untuk QA dalam Daily Standup

Agar peran QA lebih maksimal dalam daily standup, berikut beberapa praktik yang bisa diterapkan:

●      QA wajib aktif menjawab 3 pertanyaan:

○      Apa yang saya kerjakan kemarin?

○      Apa yang akan saya kerjakan hari ini?

○      Hambatan apa yang sedang saya hadapi?

●      QA ikut menandai fitur yang sudah “siap diuji” dan mana yang masih “butuh revisi” secara real-time.

●      QA dan developer dapat langsung berdiskusi singkat setelah standup jika ada hal teknis yang perlu ditindaklanjuti.

●      Scrum Master membantu mendorong QA untuk lebih aktif berbicara di dalam forum ini.

 

Kebiasaan dalam Standup:

Studi Kasus: Peran QA dalam Daily Standup di Tim Fintech dan E-Commerce

1. Tim A (Fintech) - Praktik Ideal: QA Aktif Sejak Hari Pertama Sprint

Tim A merupakan tim pengembang aplikasi mobile finansial. Tim ini terdiri atas 1 QA automation engineer, 1 QA manual, 3 developer, 1 PO, dan 1 Scrum Master.

Kebiasaan dalam Standup:

●      QA ikut standup setiap pagi dan menyampaikan dengan detail terkait test progress, blocker, dan test data yang dibutuhkan.

●      QA meminta klarifikasi dari developer jika ada perubahan teknis yang mempengaruhi test case.

●      QA menyarankan regresi terhadap fitur yang terdampak oleh perubahan logika di sisi backend.

●      Untuk fitur yang kompleks, QA dan developer bekerja bersama secara langsung (pairing) guna memastikan pemahaman yang sama.

Hasil yang Dicapai:

●      Regression dilakukan di tengah sprint, bukan di akhir.

●      Setiap fitur yang diuji secara menyeluruh dan bug berhasil ditemukan lebih awal.

●      Kepercayaan antar anggota tim meningkat karena terjadi komunikasi dua arah.

2. Tim B (E-Commerce) - Praktik Kurang Efektif: QA Hanya Dilibatkan Saat Akhir Sprint

Tim B merupakan bagian dari proyek pengembangan sistem ERP untuk perusahaan e-commerce. Tim ini memiliki 1 QA yang hanya bergabung di minggu ke-2 sprint.

Kebiasaan dalam Standup:

●      QA tidak dilibatkan sejak awal sprint, dan baru diajak bergabung ketika fitur sudah dinyatakan “siap diuji”.

●      Karena tidak mengikuti perkembangan dari awal, maka QA tidak mengetahui adanya perubahan struktur data dan tidak sempat menyesuaikan test case.

●      QA tidak menyampaikan blocker karena tidak diberi kesempatan berbicara oleh Scrum Master.

Akibatnya:

●      Regression testing tidak sempat dijalankan.

●      Bug kritikal baru ditemukan saat sehari sebelum demo sprint.

●      Developer menganggap QA “lambat” padahal QA tidak diberi ruang sejak awal.

Kesimpulan dari Perbandingan:
Keterlibatan QA yang aktif dan sejak hari pertama sprint terbukti menciptakan kolaborasi tim yang lebih baik serta proses pengujian yang bersifat proaktif, bukan hanya reaktif. Kehadiran QA sejak awal memungkinkan identifikasi masalah lebih cepat, penyusunan skenario uji yang relevan, serta mendukung kualitas produk yang lebih tinggi.