Test Last VS Test First

Dalam sebuah tim Project Development saya sering melihat hahwa terjadi permushan antara kubu Programmer dan Tester.  Tester merasa banga bila menemukan bug dan Programmer merasa terhina bila hal tersebut terjadi.  Bila ditelaah lebih lanjut dan dilihat dari Software Development Life Cycle (SDLC) yang menggunakan waterfall.  Bila dilihat dari tahapan waterfall adalah sebagai berikut:

1. Requirements specification
2. Design
3. Construction
4. Validation (Testing and debugging)
5. Maintenance

Dan bila kita melihat project plant bisanya seperti berikut.

Dengan menggunakan cara diatas maka bila terjadi fail pada saat verfiikasi akan menyebabkan project terlambat karena harus memperbaiki Bug.  Perbaikan bug ini bisanya cukup mejebalkan karena.  Programmer akan lebih stress bila mengerjakan perbaikan bug daripade coding baru hal inilah yang mengikatakan kemungkian lembur pada saat Validation. Untuk mengurahi efek stress bagi tim kami  coba menerapkan sedikit modifikasi dari project plan diatas menjadi sebagai berikut.

Pada strukur project plan yang baru aktifitas berhubungan dengan testing dialakukan beriringan dengan prosess task  yang dilakukan programmer. Yang menarik ada aktifias Test Script Construction. Aktifitas ini melakkan konversi dari scrip yang manual hasil dari Test Design menjadi Automatic Test, Computer Executed Manual Test. Computer Executed Manual Test adalah sebuah script yang di jalankan oleh aplikasi tertentu atau robot tapi yang mentukan bahwa test tesebut fail atau success adalah manusia. Model ini untuk menguragi labor work pada saat validation. Sehingga bisa lebih cepat dalam melakukan exekusi.

Automatic Test dan Computer Executed Manual Test script dapat digunakan oleh programmer untuk melakukan validasi atas pekerjanya pada fase konstruksi. Hal ini cukup menguntukan karena programmer dapat lebih awal mengetahui kesalahan programm sebelum benar-benar dilakukan fase berikutnya.  Gaya ini sedikit banyak dipengaruhi oleh Test-First dibandingkan Test-Last.

Keuntungan dari cara ini adalah Tester tidak akan bangga bila mekea menemukan bug pada saat verifikasi.  Hal tesebut dikarenakan Tester mepunyai andil terhadap hal tersebut. Dengan cara ini Tester dan Programmer dapat lebih solid karena mereka saling medukung untuk menghidari verifikasi yang gagal. Walaupun demikian labor work pada saat validation masih diperlukan karena ada beberapa hal.

Nilai dari anggota tim

Sebuah diskusi singkat dalam ruang pengasapan kemarin sampai saat ini masih menjadi pemikiran saya.  Diskusi tersebut adalah bagaimana caranya agar kita dapat menilai anggota tim dengan fair. Dalam tim kami terbentuk menjadi dua kelopok sub tim yaitu Programmer dan Tester.
Saat itu saya ditantang untuk membuat sebuah sekema penilaian agar kedua kelopok ini dapat berkerja bersama agar men-deliver project yang dapat diterima oleh pengguna. Menurut opini saya skema tersebut haruslah menpunyai karakterisitik seperti berikut.
1. Mondorong untuk meningkatkan pencapaian pribadi.
2. Memberikan kontribusi maksimum pada tim.
3. Menghidari efek menjatuhkan panter (karana umunya Programmer dan Tester bermusuhan).
4. Menghidari untuk mencari kambing hitam (pointing finger).
5. Menjadi pembelajaran untuk fase project berikutnya.
Sampai tulisan ini di turunkan skema tersebut masih samar-samar.  Karena ada beberapa sekenario yang harus di uji sehingga dapat diterima dalam 5 buah karateristik diatas.

Pengen koding di blog

Tadi siang saya lihat sebuah blog (http://codeformatter.blogspot.com/) yang dapat melakukan format koding. Akhirnya saya mencoba sedikit  programm Hello World.  Dan luar biasa ternyata bagus juga.

 package helloword;  
 public class HelloWord {  
   public static void main(String [] str) {  
     System.out.println("Hello World !!!");  
   }  
 }  

Setelah tau hal ini saya jadi lebih semangat untuk coding di blog.