Seorang pengembang perangkat lunak dari tim Be on Time berbagi pengalaman menakutkan setelah menemukan empat bug kritis dalam fitur ekspor XLSX aplikasi manajemen sumber daya berbasis Jira Forge mereka. Aplikasi ini menangani perencanaan kapasitas, timesheet, dan ekspor faktur — di mana bug terakhir bukan sekadar kesalahan tampilan, melainkan kesalahan penagihan yang berdampak finansial nyata bagi pelanggan. Tim tersebut menjalani proses Quality Assurance (QA) ketat selama beberapa bulan, fokus pada jalur ekspor XLSX, dan menemukan bahwa tidak satu pun dari bug tersebut melempar pengecualian (exception) atau menampilkan kesalahan visual. Semuanya menghasilkan file yang terlihat sempurna di permukaan, tetapi mengandung data yang salah di bawahnya.
Bug pertama berkaitan dengan penanganan zona waktu pada field tanggal-saja (date-only). Saat diekspor ke Excel, setiap baris tanggal membawa komponen waktu identik — tepat tengah malam UTC — meskipun data asli tidak memiliki informasi waktu sama sekali. Masalah ini muncul karena JavaScript secara diam-diam melampirkan zona waktu saat nilai tanggal dirutekan melalui tipe `Date` atau string ISO datetime. Akibatnya, penyewa (tenant) di zona waktu UTC+3 akan melihat jam 03:00, sedangkan yang di UTC-5 kembali ke hari sebelumnya. Filter tanggal Excel berperilaku tidak terduga, perbandingan `=DATE()` gagal diam-diam, dan sistem downstream mewarisi waktu hantu ini. Solusinya bukan menambahkan offset zona waktu — yang justru menciptakan bug baru saat pengguna dari zona lain memasang aplikasi — melainkan menulis nomor serial integer Excel murni tanpa bagian pecahan, memastikan field tanggal-saja tidak pernah direpresentasikan oleh tipe yang sadar zona waktu.
Bug kedua mengungkap bahwa kolom numerik seperti total jam, lembur, dan total biaya ternyata disimpan sebagai string (teks) di dalam file XLSX. Di Excel, sel bertipe data: angka disimpan sebagai nilai numerik, sedangkan string — bahkan yang terbaca persis "1250.00" — adalah tipe sel yang berbeda sepenuhnya. Akibatnya, fungsi `SUM()` mengabaikannya, pivot table mengabaikannya, dan bagan menurunkannya menjadi nol. Penyebabnya sederhana: sebagian besar pustaka ekspor menulis apa pun yang diberikan ke mereka. Jika nilai sudah diformat untuk tampilan di hulu — melalui `toFixed()`, template literal, atau helper mata uang — tipe numeriknya sudah hilang sebelum mencapai penulis file. Perbaikan dilakukan dengan casting eksplisit ke tipe angka saat penulisan, dan pelajaran utamanya: jangan percaya pada spreadsheet yang terrender, baca file mentahnya menggunakan `openpyxl` atau bahkan ekstrak XML mentah dari arsip ZIP `.xlsx` untuk memverifikasi tipe data sel secara langsung.
Bug ketiga dan keempat saling terkait dan paling berbahaya secara bisnis. Aplikasi mengalikan jam kerja dengan tarif efektif sumber daya. Jika tidak ada tarif terkonfigurasi, tarif menjadi nol, dan biaya menjadi nol — menghasilkan faktur yang terformat sempurna di mana sebulan kerja seseorang bernilai nol, tanpa kesalahan, asterisk, atau petunjuk apapun. Ini adalah kelas bug yang paling ditakuti: bukan kegagalan sistem, melainkan angka yang masuk akal tapi salah. Stack trace adalah hadiah; faktur salah diam-diam adalah pelanggan marah enam minggu kemudian. Tim memperbaikinya dengan menambahkan peringatan jelas yang menamai setiap sumber daya dengan tarif hilang.
Namun, peringatan itu sendiri ternyata berbohong — bug keempat. Dialog mengumumkan "Tarif efektif tidak dikonfigurasi untuk: [nama]. Ekspor menggunakan 0 untuk tarif dan biaya mereka" — padahal file yang baru dihasilkan justru mencantumkan tarif sumber daya tersebut, menerapkannya, dan menagihkan total non-nol. Peringatan kontradiktif dengan dokumen di folder unduhan pengguna. Tim hampir mengabaikannya, mengira disebabkan data uji absurd (tarif 1e16), tetapi setelah diuji dengan tarif biasa, peringatan tetap muncul. Akar masalahnya: dua jalur kode independen masing-masing menjawab pertanyaan "apakah sumber daya ini memiliki tarif efektif?" — satu menggerakkan peringatan, satu menghitung biaya. Keduanya tidak sepakat. Jalur biaya menemukan tarif dan menagihkannya; jalur deteksi tidak menemukan, dan berteriak tentang hal itu. Perbaikan: menggabungkan keduanya ke dalam satu resolusi tarif efektif yang dikonsumsi kedua jalur.
Polanya universal dan layak diinternalisasi jauh di luar domain faktur atau Jira Forge: jika dua bagian sistem Anda secara independen menjawab pertanyaan yang sama, mereka *akan* akhirnya memberikan jawaban yang berbeda. Dan ketika salah satunya adalah peringatan tentang yang lain, Anda mendapatkan hasil terburuk — sistem yang dengan percaya diri salah tentang dirinya sendiri. Pengguna yang mempercayai banner peringatan akan percaya faktur mereka dinilai nol, padahal sebenarnya tidak. Kepercayaan terhadap alat bantu (tooling) hancur bukan karena alat itu gagal, tapi karena alat itu berbohong tentang kegagalan dirinya sendiri.
Kasus ini menyoroti pentingnya *observability* yang jujur dan konsistensi sumber kebenaran (single source of truth) dalam arsitektur perangkat lunak modern, terutama untuk aplikasi B2B yang menangani data finansial. Di ekosistem Atlassian Forge, di mana aplikasi berjalan di infrastruktur terkelola dan batasan eksekusi ketat, bug semacam ini sulit dideteksi melalui pengujian unit konvensional karena tidak melanggar kontrak tipe atau melempar error. Pendekatan *contract testing* pada file output, validasi skema XML mentah, dan *property-based testing* untuk kasus batas zona waktu menjadi krusial. Bagi tim pengembang Indonesia yang membangun aplikasi SaaS atau ekstensi platform, pelajaran ini mengingatkan bahwa kualitas data ekspor bukan fitur tambahan, melainkan kebutuhan kepatuhan dan kepercayaan pelanggan.