Project Management : Software - Pembuatan Test Script

Pembuatan Test Script merupakan salah satu aspek kegiatan Software Project Management yang ditujukan untuk memberikan batasan cakupan pekerjaan yang akan dilakukan melalui berbagai contoh variasi kasus. Seluruh perwakilan user dari setiap unit/bagian/divisi harus menghadiri meeting test script, terutama untuk sistem yang mempunyai flow proses yang bergerak dari satu unit/bagian/divisi ke unit/bagian/divisi lain. Pembuatan test script dilakukan setelah proses Desain System. Requirement Gathering & Analysis beserta dengan FSD memberikan batasan yang jelas mengenai cakupan project secara keseluruhan, namun seringkali hal ini belum mengantisipasi variasi kasus yang dihadapi operasional sehari-hari.

Test script dibuat berdasarkan variasi proses yang terjadi sehari-hari dengan menggunakan mekanisme manual atau menggunakan sistem lama yang sudah berjalan saat ini. Variasi proses bisa dilihat dari transaksi-transaksi yang terjadi dan tercatat selama ini. Variasi transaksi juga bisa diperkirakan oleh user yang menangani sistem manual atau sistem lama selama ini. Tugas konsultan adalah memancing/men-trigger user untuk memastikan jenis transaksi yang mungkin terjadi. Untuk memudahkan gambaran, misalnya untuk sistem piutang variasinya adalah : pencairan piutang, pembayaran piutang secara full, pembayaran piutang yang dicicil berapa kali, piutang yang sudah jatuh tempo tapi belum terbayarkan, pembayaran piutang yang dicicil tapi sebagian dst. Kelengkapan variasi ini akan memberikan keakuratan pada software yang sedang dikembangkan. Ketidaklengkapan variasi kasus transaksi akan menyebabkan fitur software menjadi tidak lengkap dan pada akhirnya akan mengurangi nilai software itu sendiri dan mengurangi tingkat kepuasan user.



Tantangan konsultan dalam mengorganisasi pembuatan test script ini adalah bahwa user harus meluangkan waktunya untuk mengumpulkan semua variasi kasus transaksi dan juga membuat simulasi kasus secara detail mulai dari data input sampai dengan output yang akan dihasilkan. Proses pembuatan simulasi kasus harus dilakukan dengan cara manual. Biasanya menggunakan spreadsheet sebagai alat untuk melakukan perhitungan. Untuk mendapatkan dukungan penuh dari tim user atas proses pembuatan test script, konsultan harus terus mengingatkan konsekuensi atas tidak lengkapnya test script yang akan menyebabkan tidak lengkapnya fitur software yang akan dibangun.

Dalam kasus Test Script Sistem Account Receivable pada gambar di atas terlihat ada 3 bagian utama dari tabel test script. Kelompok pertama adalah jenis kasus yang akan diujicobakan, kelompok kedua adalah nilai-nilai yang diinputkan pada sistem dan kelompok ketiga adalah hasil-hasil yang diharapkan.

Test Scenario adalah variasi kasus yang disepakati, pada kolom ini kita dapat melihat bahwa untuk pembayaran AR akan terdapat berbagai macam variasi pembayaran, ada yang membayar penuhm membayar dengan dicicil, menunggak bahkan sampai dengan yang di write off karena sudah terlal lama menunggak. Apabila salah satu dari variasi tidak dituliskan di test script misalnya untuk penanganan menunggak pembayaran yang sudah jatuh tempo, maka fitur ini kemungkinan akan terlewat atau karena sudah ada di Functional Spesification Document kemungkinan akan dibuat secara akurat pada software yang sedang dikembangkan.

Pada bagian input terdapat No Tx, Nama, Nilai AR, Tenor yang merupakan data awal dari suatu transaksi AR. Tim harus memasukan data-data ini sebagai rujukan untuk perhitungan nilai output. Nilai yang diisikan harus bervariasi antara satu kasus dengan kasus lainnya. Seringkali kita harus 'menitipkan' variasi-variasi kecil dan tidak major di kasus-kasus yang ada di test script. Contohnya adalah ada yang nilai AR nya di bawah 10 juta tapi ada juga yang di atas 10 juta, ada yang tenornya 1 (sekali bayar), 4 tapi ada juga yang tenornya 18 .

Pada bagian output terlihat Nilai Pembayaran Angsuran dan Sisa AR secara rinci, sehingga benar-benar bisa menjadi rujukan keabsahan perhitungan lewat software nantinya. Personal yang melakukan test cukup mengentry nilai-nilai input dan melihat apakah hasil Nilai Pembayaran Angsuran dan Sisa AR yang dimunculkan sistem, sama dengan hasil perhitungan manual yang ada di test script, bila sama artinya mekanisme kalkulasi software sudah benar dan juga sebaliknya. Pembuatan test script memang melelahkan, namun bila dilakukan secara detail dan terstruktur akan memberikan kualitas software yang sangat bagus dan sesuai dengan kebutuhan user.

Project Management : Software - Weekly Meeting

Dalam suatu Project Software, perlu disepakati adanya Weekly Meeting untuk memastikan seluruh progress berjalan dengan baik. Dengan weekly meeting ini, masalah-masalah yang ditemukan di lapangan selama seminggu dapat diutarakan dan dicarikan solusinya bersama-sama. Weekly meeting biasanya memakan waktu 1 sampai dengan 2 jam. Pihak konsultan biasanya yang lead meeting ini. Weekly meeting harus disepakati pada saat Project Kick Off di saat awal, agar setiap personal yang terlibat di project dapat mengatur waktunya setiap minggu untuk menghadiri meeting ini. Waktu meeting sebaiknya disepakati di depan, sehingga setiap orang setiap minggu nya tidak perlu bertanya lagi kapan waktu meeting minggu ini akan dilaksanakan. Namun demikian, sehari sebelum meeting tetap harus dikirimkan undangan resmi ke setiap personal yang terlibat di project ini untuk menghadirinya.

Weekly meeting biasanya dibuka oleh perwakilan dari User dan kemudian di lead oleh Project Manager atau Business Analyst. Isi dari weekly meeting adalah :
1. Progress Report
2. Review Tahapan Sebelumnya
3. Outstanding Issue : Technical
4. Outstanding Issue : Non - Technical
5. Persiapan Tahapan Selanjutnya
6. Schedule Project : Overall (Reminder)

Progress Report 

Bagian ini memaparkan apa saja yang sudah dilakukan semenjak Project Kick Off sampai dengan hari ini. Hal ini perlu dilakukan untuk me-refresh informasi kepada semua peserta meeting, bahkan beberapa peserta meeting adalah orang yang belum pernah mengikuti weekly meeting sebelumnya.

Activity menunjukan kegiatan yang sudah dilakukan sampai dengan hari ini. Tanggal di sana menunjukan tanggal start nya. Di bagian keterangan, kita bisa mencantumkan keterangan atas kegiatan yang sudah dan sedang dilakukan. Keterangan biasanya diperlukan untuk mengisi status atas On Going activity, sehingga semua peserta meeting dapat segera memahami sampai dimana kegiatan yang sedang berjalan. Contoh di atas tahap Coding/Development sedang berlangsung, akan lebih baik bisa tambahkan dengan prosentase progress dan sudah sejauh mana coding yang sudah dilakukan. Misahlnya dari 12 modul yang sedang dikerjakan saat ini sudah 8 modul yang siap, tinggal 4 modul lagi, sehingga dengan tenggat waktu yang ada, peserta meeting dapat menduga tahapan ini akan still on time atau akan delay.

Review Tahapan Sebelumnya

Saat meeting dilaksanakan, seringkali tahapan sebelumnya baru saja selesai, sehingga peserta meeting perlu mengetahui secara detail atas hasil penyelesaian tahap tersebut, untuk memastikan agar hasil dari tahapan sebelumnya, sesuai dengan yang diharapkan.

Outstanding Issue : Technical

Bagian ini menampilkan issue-issue technical apa yang sudah done dan issue apa yang masih dalam progress penyelesaian. Bagian ini terutama untuk mendiskusikan item yang masih pending dan berpotensial delay. Untuk schedule yang sudah delay, pembahasan langsung ditujukan pada issue yang menyebabkan schedule menjadi delay.

Issu ID merupakan kode nomor urut issue. Description menjelaskan issue tersebut secara detail. Created by merupakan personal yang memunculkan issue tersebut. Date Assign adalah tanggal saat dimunculkan nya issue tersebut pertama kali, due date adalah target waktu penyelesaian atas issue tersebut. Module adalah modul dari software yang sedang dikerjakan. Severity adalah peringkat pentingnya penanganan issue mulai dari critical, major, urgent, important dan nice to have. Status menunjukan posisi penyelesaian issue saat ini yang terdiri dari : new, on going, done, re-open, out of scope, drop.

Outstanding Issue : Non Technical 


Setelah issue technical, dilanjutkan dengan issue-issue non technical yang menyebabkan pekerjaan menjadi delay atau berpotensi menyebabkan delay. Contoh dari issue ini adalah pengaturan prioritas waktu dari user yang terlibat di pekerjaan, penentuan user pengganti bila personal utama nya berhalangan, penyiapan data-data yang dibutuhkan. Issue ini biasanya bersifat koordinatif.

Persiapan Tahapan Selanjutnya

Hal biasanya memastikan agar orang-orang yang terlibat di tahap selanjutnya sudah dipastikan availabilitynya, dan dilanjutkan dengan mengirimkan undangan ke setiap orang yang terlibat di tahap tersebut. Selain itu juga memastikan ruangan atau infrastruktur yang nantinya diperlukan. Sebagai contoh, untuk memasuki tahap UAT, hal -hal yang harus disiapkan adalah : kepastian jadwal tester, kesiapan test script, ruangan testing, komputer untuk test, apakah aplikasi sudah diinstal pada komputer yang bersangkutan, apakah user account dan password sudah di sediakan, apakah undangan resmi sudah dikirimkan dengan cc atasan masing-masing. Bila salah satu item di atas terlewakan, maka pelaksanaan UAT kemungkinan akan mendapat masalah.

Schedule Project : Overall (reminder)

Schedule project perlu selalu ditunjukan pada weekly meeting untuk mengingatkan semua personal kapan seluruh pekerjaan akan tuntas, apa tahap selanjutnya dan persiapan apa yang perlu dilakukan. Dalam pelaksanaan project software, seringkali jadwal harus disesuaikan dengan situasi yang ada. Misalnya ada suatu pekerjaan yang bersifat urgent yang diprioritaskan oleh perusahaan user, sehingga project menjadi delay, untuk itu schedule project harus disesuaikan dengan jadwal yang baru. Namun demikian harus selalu diperhatikan bahwa perubahan jadwal ini harus mendapat persetujuan semua pihak dan semua pihak mengetahui persis konsekuensi dari perubahan jadwal tersebut. Project management yang baik seharusnya bisa mengantisipasi keseluruhan project dengan baik dan selalu menerapkan "no suprises policy".

Project Management : Pengembangan Software

Software Project Management merupakan bidang yang menarik untuk dipelajari dan tulisan saya di sini lebih difokuskan kepada apa yang telah saya lakukan selama ini. Suatu Software Project dapat dilakukan oleh Konsultan atas permintaan User atau juga bisa merupakan Suatu Internal Development Project , dan dalam tulisan ini, yang dibahas adalah Software Project yang dilakukan oleh Konsultan yang telah ditunjuk oleh User.

Apa yang saya lakukan dalam suatu software project management selama ini adalah dengan menerapkan SDLC (software development life cycle) yang tediri dari :
1.  Project Kick Off
2.  Project Plan : menentukan jadwal dan resource
3.  Requirement Gathering & Analysis
4.  Design
5.  Development / Coding
6.  Sistem Integration Test
7.  User Acceptance Test
8.  Data Migration
9. Go Live

Berikut adalah penjelasan singkat terkait hal-hal tersebut di atas :

Project Kick Off

Tahap ini merupakan awal dari project. Tahapan ini dilakukan dalam suatu rapat yang dihadiri oleh Tim User dan Konsultan. User menyiapkan summary cakupan project serta tahapan serta deliverables yang diharapkan. Tahap ini dilakukan dalam bentuk rapat resmi disertai dengan notulensi. Catatan rapat ini akan didistribusikan ke seluruh  pihak yang terkait dengan project dan menjadi landasan kegiatan selanjutnya. Pada tahap ini juga ditentukan Person In Charge (PIC) baik dari sisi User maupun dari sisi Konsultan. Project Kick Off dilakukan dengan merujuk kepada kontrak atau SPK yang telah ditandatangani.

Project Plan

Perencanaan project merupakan tahap yang sangat penting. Pada tahap ini, project manager membuatkan draft jadwal atas keseluruhan kegiatan project, sehingga dapat memberikan gambaran kepada setiap orang yang terlibat di project. Project manager juga menyiapkan resource yang akan dilibatkan pada project. Sehingga target utama dari Plan Project ini adalah untuk mendapatkan gambaran kapan setiap tahapan project dilakukan dan kapan selesainya serta siapa saja personal yang terlibat dalam project. Hal ini dapat dibuat berdasarkan kontrak pekerjaan yang telah dibuat dan ditandangani sebelumnya.

Business Requirement Gathering and Analysis

Pendefinisian masalah merupakan hal yang esensi dari sebuah Software Project. Setiap bagian/unit/divisi yang akan menjadi pengguna software, wajib mengirimkan perwakilannya pada proses ini.  Tanpa keterwakilan dari salah satu bagian/unit/divisi, assesment kebutuhan menjadi tidak tepat yang pada ujungnya akan memberikan solusi software yang tidak sesuai dengan kebutuhan.

Pada tahap ini sering kali terjadi konflik kepentingan antara pekerjaan operasional dengan menghadiri meeting requirement assessment, untuk itu sangat diperlukan dukungan penuh dari pimpinan perusahaan dari sisi User untuk memberikan prioritas utama pada project ini. Solusi konflik kepentingan ini sering kali dengan menetapkan minimal satu orang perwakilan dari setiap bagian/unit/divisi yang terlibat secara penuh project ini dari awal sampai akhir. Jadi walaupun masih ada tanggung jawab operasional, PIC ini tetap memprioritaskan waktunya di project. Untuk melengkapi hal tersebut, penentuan PIC sebaiknya juga disertai dengan penetapan KPI (Key Performance Indicator) tambahan atas karyawan tersebut atas keterlibatannya di Project Software ini.

Konsultan biasanya akan mengirimkan Project Manager, Business Analyst dan System Analyst nya ke meeting ini. Project Manager memastikan meeting ini berjalan tepat waktu, dihadiri oleh peserta meeting yang diharapkan, menentukan target meeting dan memastikan agar target pertemuan tercapai. Business Analyst mempelajari kebutuhan User, membuat hipotesis awal, menyiapkan daftar pertanyaan dan menanyakannya ke User, mencatat jawaban-jawaban yang diterima, melakukan analysis kebutuhan, menyiapkan minutes of meeting. System Analyst memberikan konfirmasi kesanggupan teknis saat dibutuhkan oleh Business Analyst. Hal-hal kritikal akan sangat ditentukan dari kesanggupan teknis yang dikonfirmasi oleh System Analyst dalam menjawab kebutuhan User.

Konsultant akan menganalisis seluruh hasil interview dengan pihak user ini. Produk dari tahap ini adalah dibuatkannya Functional Spesification Document (FSD). FSD akan menjadi rujukan semua pihak yang terlibat di Project ini. FSD akan menjadi rujukan utama programmer dalam pembuatan program dimana salah satu isi utama dari FSD adalah desain screen-screen dari software yang akan dikembangkan. FSD yang salah akan berdampak pada solusi software yang tidak salah.

Design

Tahap desain sangat menentukan kualitas atas software yang akan dibuat. Pada tahap desain dilakukan pembuatan Flow Process, Data Flow Diagram, Entity Relationship Diagram, Program Framework dan Struktur Class dan aspek teknis lainnya. Seluruh pekerjaan pada tahap disain dibuat berdasarkan FSD yang telah disepakati pada tahap sebelumnya. Desain solusi  yang baik akan sangat memudahkan dalam pembuatan program yang akan dikembangkan. Data Flow Diagram yang efektif dan efisien akan membuat solusi menjadi lebih cepat dan lebih mudah direalisasikan. Entity Relationship Diagram menentukan kualitas database yang akan dibangun. Kesalahan yang sering terjadi adalah ERD tidak dibuat secara akurat sehingga menghasilkan kualitas database yang redundan dan tidak efisien. DFD merupakan alur data dari business process yang sedang dipelajari, sedangkan ERD merupakan tipe hubungan antara 2 atau lebih entitas di dalam business process tersebut.

Coding/Development

Inti dari project software adalah coding/developmen program. Umumnya, kualitas dari program sering berdasarkan pada kualitas si programmer yang bersangkutan. Software Project Management yang baik akan membuatkan struktur class yang lengkap dan stabil sebagai framework utama. Dengan pembuatan struktur class dan framework yang baku, variasi dan kesalahan programmer dapat diminimilisasi. Tanpa itu akan terjadi tingkat variasi dan kesalahan yang sering kali tinggi dan mengurangi kualitas software yang dibangun, untuk itu peran senior developer dalam suatu project software akan sangat penting, terutama

Saat ini banyak sekali pilihan bahasa program beserta Integrated Development Environment-nya (IDE), namun yang saat ini banyak digunakan adalah Java, PHP, Miscrosoft Visual Studio. Net, serta pengembangan untuk platform mobile seperti Android, Apple dan Blackberry. Terlepas dari perbedaan pemilihan tools development, penerapan konsep Object Oriented Programming (OOP) merupakan seuatu keharusan dan tetap dijaga untuk memberikan kualitas software yang efektif dan efisien, konsep class dan framework yang baik akan memberikan kemudahan dan keseragaman dalam pengembangan software.

Pembuatan Test Script

Tahap ini dilakukan bersamaan dengan tahapan coding/Development yang dilakkan oleh Business Analyst bersama tim User, tujuannya adalah membuat suatu skenario test yang lengkap dan komprehensif sesuai dengan proses real yang diinginkan oleh user sehingga bisa menggambarkan kondisi proses sebenarnya. Test script ini harus benar-benar mewakili cerita sebenarnya yang dilengkapi dengan contoh nilai-nilai masukan beserta hasil yang diharapkan. Dengan adanya test script yang lengkap dan komprehensif, maka testing bisa dilakukan oleh siapa saja, walaupun tidak terlibat di tahap awal project software, dimana orang yang akan melakukan testing, cukup memasukan nilai awal sesuai test script dan melihat apakah nilai yang dihasilkan sudah sesuai dengan hasil perhitungan manual yang tercantum pada test script. Kasus-kasus test script harus divariasikan sesuai dengan kemungkinan variasi pada proses sebenarnya.

Sistem Integration Test (SIT)

Pada tahap ini, modul-modul yang telah dikembangkan akan diintegrasikan menjadi suatu solusi lengkap. Setelah diintegrasikan, sistem akan diujicobakan dengan menggunakan test script yang sudah dibuat sebelumnya. Pengujian ini dilakkukan oleh internal konsultan tanpa melibatkan user, namun test script yang digunakan tentunya sudah disesuaikan dengan keinginan user dan disetujui user. Bila hasil dari ujicoba tidak sesuai dengan hasilyang tertera di test script, maka program masih salah dan perlu diperbaiki. SIT telah selesai apabila seluruh input test script telah diujicobakan dan hasilnya juga telah sesuai dengan yang ada di test script. Business Analyst adalah PIC yang melakukan testing pada proses SIT ini. Programmer akan melakukan perubahan yang diperlukan sampai diperoleh hasil yang diharapkan sesuai test script.

User Acceptance Test (UAT)

Tahap ini kurang lebih sama dengan yang dilakukan pada tahap SIT, hanya saja yang melakukan adalah User dari bagian/unit/divisi terkait. Tantangan yang muncul pada tahapan ini adalah memastikan agar user terkait dapat menghadiri jadwal UAT sesuai dengan waktu yang disepakati. Suatu sistem yang diintegrasikan biasanya melibatkan beberapa  bagian/unit/divisi, sehingga ketidakhadiran salah satu perwakilan dari bagian/unit/divisi tertentu akan memundurkan jadwal UAT sehingga jadwal keseluruhan juga jadi terganggu. Untuk itu perlu dilakukan pendeketan secara dini ke setiap pimpinan bagian/unit/divisi terkait sehingga mempunyai kesadaran dan persepsi yang sama mengenai pentingnya software yang sedang dikembangkan. Walaupun batasan pekerjaan dan batasan proses ujicoba sudah digariskan dengan testscript yang disepakati sebelumnya, namun demikian tidak jarang pada saat UAT, user menemukan suatu variasi testing yang ternyata tidak ada di test script dan hal terburuknya adalah feature yang tidak tersedia tersebut harus di develop oleh programmer. Hal ini tentunya akan menunda penyelesaian UAT, namun apabila hal itu memang harus terjadi, maka harus mendapat persetujuan dari kedua belah pihak. Masalah yang sering terjadi adalah pihak konsultan sering disalahkan pada saat terjadi kemunduran jadwal karena tidak mendokumentasikan dengan detail hal-hal yang menjadi new request selama proses UAT. Proses UAT biasanya adalah proses yang paling sibuk/ramai dibanding tahap lainnya di SDLC, karena pada tahap ini seluruh pihak terkait biasanya langsung saling berinteraksi, jadi adalah sangat bijaksana bila seorang Project Manager mengantisipasi hal ini sedini mungkin, salah satunya adalah pada saat requirement gathering dan pembuatan test script yang seakurat mungkin. Selain itu, dengan penanganan new request yang baik, masalah keterlambatan penyelesaian UAT dapat diselesaikan dengan baik.

Data Migration

Software dibuat dengan tujuan untuk menggantikan proses manual yang selama ini terjadi menjadi suatu proses yang otomatis, atau mengganti sistem lama dengan sistem baru yang dianggap lebih baik, atau melakukan penambahan program atas existing program. Jenis manapun dari pengembangan software tersebut di atas harus melalui tahap yang dinamakan Data Migration atau Migrasi Data. Untuk pelaksanaan data migration, beberapa hal harus dipersiapkan yaitu : penyiapan existing data yang digunakan secara manual atau yang digunakan oleh sistem yang lama, pembuatan script untuk melakukan one time migration dimana data yang lama akan diupload ke sistem baru dengan menggunakan script migrasi tersebut. Selain itu yang harus disiapkan adalah cut off dimana data migration akan dilakukan, pemberitahuan ke seluruh pengguna sistem lama kapan cut off data akan dilakukan dan berapa lama sistem akan off, pembuatan panduan step by step dalam melakukan migrasi data, dan terakhir adalah pembuatan Fall Back Plan dimana bila proses migrasi ini gagal, maka data lama akan dikembalikan lagi ke enviroment production, sistem baru diangkat kembali dan sistem lama di kembalikan lagi. Setelah semua data terbukti berhasil dimigrasikan dan user sudah melakukan final cek atas data hasil migrasi di sistem baru, maka migrasi data selesai dilakukan.

Go Live

Ini adalah suatu tahap dimana semua proses SDLC sudah selesai dan user sudah bisa menggunakan sistem baru dengan existing data. Setelah Go Live bukan berarti tidak ada problem lagi, sering kali suatu sistem akan terlihat masalahnya pada saat sistem Go Live di production server, namun dengan penanganan proses project management yang handal, problem ini seharusnya dapat diminimalisasi.

Support

Untuk menjamin agar sistem berjalan bagus dan stabil setela production, diperlukan mekanisme support yang efektif, dengan Service Level Agreement (SLA) yang disepakati oleh User dan Vendor.  Issue biasanya digolongkan menjadi Critical/Stopper, Urgent, Important dan Nice to Have, dan masing-masing kriteria issue ini akan disolusikan dengan SLA yang berbeda-beda


Sementara demikian dulu penjelasan singkat mengenai Software Project Management, tulisan berikutnya akan membahas mengenai setiap tahapan dengan lebih detail beserta dengan template-template yang sering digunakan.