Budi Rahardjo wrote: > On 5/17/06, m.c. cptrwn <[EMAIL PROTECTED]> wrote: > > > Pak Budi, apakah ini maksudnya "kalau codenya ternyata buggy, pecat > > saja orang QAnya" ? :) > > Ya dong. M > > Kalau dia meloloskan kode tersebut, berarti dia ikut tanggung jawab. > > -- budi
btw, ada satu pertanyaan dalam konteks pak budi ini : 1. apakah persh XYZ dapat proyek untuk mereview kode ini good quality atau tidak ? -atau- 2. apakah persh XYZ membeli source code, jadi code ini akan dipakai dia nantinya ? > ,engapa kode yang buruk diloloskan untuk menjadi > sebuah produk? Kalau QA sudah tahu bahwa programmer > (developer) membuat program yang dodol, mestinya dia tolak! > reject! (kemudian salahkan programmernya ... ha ha ha.) ini dalam konteks build release sehari2 untuk produk delivery ya Pal Budi : Biasanya memang QA selalu menolak bad builds. Kalau punya proses yang bagus, software management pasti ada code check quality dan must-fixed bugs kriteria untuk alpha-beta-release , biasanya gak boleh ada major show stopper bugs, priority 2 dan priority 3 masih okelah, jadi biasanya yang priority 2 dan priority 3 didokumentasikan di release notes. Jadi benar kata pak budi, kalau programnya dodol dan banyak showstoppernya, itu tanggung jawab QAnya. Tapi sering kali yg saya lihat, bukan hanya qa yang salah tapi managernya ... ha ha ha :)) ini kalau managernya clueless jadi dia "dont know what they're doing" , contoh clueless ini seperti jika sw/qa manager gak punya proses. biasanya di team yang hebat, pasti punya manager yang tangguh juga :)) -mcp ps: ada beberapa buku bagus untuk hal ini (jika ada yg tertarik). --~--~---------~--~----~------------~-------~--~----~ http://teknoblogia.blogspot.com/2005/02/tata-tertib-milis-v15.html -~----------~----~----~----~------~----~------~--~---
