Working at I**

Yak, setelah berbulan bulan menganggur, dan banyak orang yang suka tanya “kerjaan lo disana ngapain?”, mari ditulis aja. Sebenernya udah agak lama pengen nulis tentang ini, tapi terkadang mikir juga gimana nulisnya karena tentu ada term term yang ga boleh disebut karena merupakan confidential information.

Kerjaan

Kerjaan gua disana adalah sebagai Functional Verification Tester (FVT) untuk produk DB2, buat yang enggak tau, DB2 adalah DBMS untuk versi enterprise, saingan beratnya si “peramal”. Biasanya kalo gua bilang tester ke orang indo, mereka agak bingung, sepertinya memang kerjaan sebagai quality assurance agak kurang di indo, yang paling banyak adalah programmer dengan kualifikasi segudang, yang ngerjain dari desain, coding, testing, ampe dokumentasi  Sebenernya kerjaan quality assurance sangat penting, untuk memastikan quality dari suatu software. Lebih baik ketemu defect sebelom dirilis, dari pada ada customer yang komplain ada defect.

Sesuai namanya, FVT bertugas ngetes fungsionalitas, hal yang dites tentunya tergantung kepada item apa yang dikerjakan. Tes fungsionalitas berarti lu harus memastikan bahwa behaviour program yang dibuat oleh developer adalah sesuai dengan design yang dibuat sebelumnya. Untuk itu harus mempertimbangkan banyak hal, terutama adalah corner case, gimana handling error, dll.

Penting untuk memastikan “coverage” ato lingkup dari suatu test, tentunya tidak memungkinkan untuk mencoba semua possible scenario, maka umumnya developer sebagai pembuat akan memberikan informasi tentang hal hal yang harus dipertimbangkan. Coverage harus dipastikan tidak terlalu besar, namun cukup baik untuk mengetes bagian besar dari suatu code. Dari sebuah desain yang dibuat oleh developer, FVT akan membuat test plan, dan memastikan coverage dari test plan dengan developer. Setelah semua pihak pihak terkait setuju dengan coverage dari test plan, baru testcase akan mulai dibuat. Tester memiliki kebebasan untuk mengimplementasikan test plan, tentunya dari sebuah definisi scenario pada testplan, tester harus membuat berbagai variasi. Sebagai contoh pada aspek tipe data, meskipun sebuah test plan tidak menulis secara eksplisit tentang tipe data yang akan digunakan, tentunya akan merupakan hal baik jika test case yang dihasilkan memiliki berbagai variasi tipe data.

Kerjaan sebagai tester, meliputi bikin test plan, bikin test case, maintain test case lama (tambah ato modify testunit), execute test case, dan laporin defect ke developer. Umumnya kalo anak intern baru bakalan kebagian dari bikin test case, karena bikin test plan itu lebih susah. Test case yang dibuat umumnya adalah tipe automatic self checking testcase, dengan menggunakan bahasa cryptic, yaitu PERL. Automatic self checking testcase artinya setelah dieksekusi, testcase tersebut dapat mengecek dan melaporkan apakah sukses atau gagal, dan juga testunit mana saja yang gagal. Untuk yang belum tau, testcase itu adalah file yang berisi testunit testunit, dan testunit adalah skenario testing. Sebagai contoh : testcase A berisi skenario skenario untuk mengetes berbagai tipe data. Di dalamnya terdapat berbagai testunit, testunit 1 mengetes tipe data int, testunit 2 mengetes tipe data double, testunit 3 mengetes tipe data string, dst.

Selama 16 bulan disana, gua paling banyak ngerjain tentang query, gua kerja di proyek yang bertujuan mempercepat eksekusi query selama 11 bulan. Selama di proyek ini gua ikut ngerjain 4 item (read:subproyek) dari total sekitar 8 atau 9 item di dalam proyek ini, 2 item gua cuma implementasi semua testcase, 1 item gua kerjain beberapa testcase, dan 1 item lagi gua buat testplan sekaligus buat testcase. Karena latar belakang dari kompetisi pemrograman, selama bekerja di area ini gua sangat excited, karena selama disini, banyak desain yang berkaitan secara langsung atau tidak langsung teknik algoritma, misalnya bagaimana manfaat hashing secara real world. Hal lain yang dipelajari adalah proses yang terjadi ketika sebuah query di run, ternyata, query itu dicompile terlebih dahulu jadi executeable. Secara kasar prosesnya kira kira  Query -> Rewrite -> optimization ->  compile.  Dalam beberapa kasus gua harus ngebohongin optimization so far, selalu berhasil. Kalo ga salah inget, skor terakhir 2 – 0 untuk kemenangan gua. Gimana cara bohongin optimization? gampang, maenin berbagai aspek yang digunakan oleh optimizer untuk melakukan estimasi cost. Faktor umum yang terkait yaitu resources (CPU speed, berbagai memory size mis : sortheap, network speed, dll) dan statistik (jumlah row, ukuran column, dllllll)!! Note : ketika melakukan optimisasi, ada 2 pilihan yang dapat dilakukan oleh optimizer, greedy atau dynamic programming, hal ini ditentukan oleh optimization level pada database configuration.

Dua hal tersulit yang pernah gua kerjakan menyangkut masalah memory error  dan costing. Pada memory error, intinya gua haru membuat sebuah operator di disable pada saat runtime dikarenakan ukuran SORTHEAP yang tidak mencukupi. Orang umumnya akan berpikir “oh gampang, kecilin aja SORTHEAP nya terus run sebuah query yang row nya banyak!!” YAK selamat, jawaban anda salah total, dengan cara demikian sampai jaman komputasi udah di galaksi (bukan awan lagi) tidak akan pernah terjadi. Kenapa bisa?? Karena pada proses optimization, optimizer akan melihat bahwa memang tidak ada memory yang mencukupi, maka optimizer tidak akan memilih plan yang mengandung operator tersebut Intinya yang harus dilakukan adalah, membuat optimizer (pada saat planning) berpikir ada memory yang cukup sehingga access plan dengan operator tersebut akan dipilih, tetapi ketika di eksekusi ternyata tidak ada cukup memory

Hal lain yang sulit adalah ketika gua mengerjakan testcase mengenai costing. Gua ga nyangka bakal kena testcase ginian, karena ini susah. Di item pertama yang gua kerjain, bagian costing dikerjain oleh coworker gua yang merupakan regular employee. Dalam testcase yang gua kerjain, intinya adalah gua harus membuat berbagai macam kasus JOIN dan memastikan suatu low level operator dijalankan dengan lancar. Tipe join disini yang gua maksud disini misalnya inner join, inner join with early out, right outer join, right early out, dll. Dan karena tujuannya adalah mengetes perhitungan optimizer, gua tidak diijinkan, menggunakan join guideline, melainkan harus murni berdasarkan perhitungan optimizer. Alhasil harus menipu compiler dengan mengatakan “hoi ini table ada 1 juta row loh!!”, padahal isinya cuma 10 row ato “oi, kolom ini unik bisa untuk early out” nah bagian nipu nipu ini yang susah, karena dalam beberapa kasus cara optimizer menghitung tidak diketahui secara detil, jadi, coba lagi dan coba lagi. Seriusan, kasus tersusahnya adalah membuat right outer join (secara runtime). Mungkin ada yang berpikir “loh kan tinggal tulis select … from a right outer join b” sayangnya cara ini likely bakalan gagal. Kenapa? karena si optimizer bilang bakalan lebih untung jadi b left outer join a, maka plan yang didapat akan jadi b left outer join a, smart eh?

Intinya query yang lu tulis, lom tentu persis sama dengan yang dieksekusi, untuk melihatnya dapat dilakukan dengan explain facility untuk melihat access plan. Sebagian besar query lambat, dapat diatasi dengan jalanin runstat untuk mengupdate statistik. Sebenernya update statistik bisa diset otomatis dengan autorunstat, namun akan lebih berat ketika terjadi perubahan data karena harus update statistik.

Kutu kutu yang gua temukan cukup beragam, dari yang sangat silly (cuma create schema dan crash, muka manager langsung mengkerut begitu denger ini), manggil fungsi untuk alokasi dan kurang tanda &, alhasil null mulu dan crash, hasil yang tidak konsisten, dll. Ketemu kutu merupakan sebuah prestasi bagi seorang tester (we found a way to blame developer!), semua kutu sekecil apapun harus di track keberadaannya. Namun belum tentu akan langsung di fix. Kutu yang severity nya high atau impactnya besar merupakan prioritas utama. Sedangkan kutu kecil kalo ga keburu diberesin sebelum release, biasanya akan di fix di service pack.

Halaman-halaman: 1 2 3