จาก post อันนี้ ผมก็เจอ comment 2 อัน คือ
ความหมายใช่เลย..แต่บางทีใน software requirement อาจจะระบุไม่ละเอียดมาก เลยทำให้พอถึงช่วง UAT ที่ผู้ใช้งานระบบ(ที่ละเอียดหน่อย) เข้ามาทดสอบแล้วบอกว่ายังขาดโน่น ขาดนี่ ทำงานไม่ได้ตาม business ต้องการ ก็ต้องกลับไปเริ่มต้นใหม่อีก
และ
เทสไปเทสมา พบว่ามีหลายอย่างที่ทาง developer ยังทำไม่เรียบร้อยเลยครับ ส่งมาได้ไง
มาดูว่า test first จะช่วยอะไรกับสองปัญหาข้างบนได้บ้าง
เริ่มแรกหลังจากได้ requirement มา programmer อย่างผม ก็ต้องอ่านๆๆ แล้วก็อ่าน แล้วก็สรุป ว่าต้องเขียนอะไรบ้าง(ผมจะเรียกว่า spec ละกัน หรือจะเรียกว่า test case ใน TDD ก็ได้) แล้วก็เขียนลงใน spec file
ตัวอย่างด้านล่างคือ Ruby code ที่ใช้ใน Ruby on Rails นะครับ
เป็นตัวอย่างการเขียน spec ทดสอบ login module ฝั่ง admin
describe AdminController, “authentication:” do
describe “handling POST /admin/login [PASSED]“ do
it “should authenticate [PASSED]“
it “should not remember user”
it “should redirect to admin page”
end
describe “handling POST /admin/login [PASSED] with remember me” do
it “should authenticate [PASSED]“
it “should remember user”
it “should redirect to admin page”
end
describe “handling POST /admin/login [FAILED]“ do
it “should authenticate [FAILED]“
it “should not remember user”
it “should render login page”
end
describe “handling GET /admin/login” do
it “should not authenticate user”
it “should render login page”
end
end
นี่คือ spec คร่าวๆ ของผม(ยังไม่ได้ implement spec ในส่วนนี้นะครับ) จะเห็นได้ว่ามันแสดงสิ่งที่ควรจะทำในทุกๆ กรณี อยากให้มันทำอะไร ใส่ไปให้มด ถ้า requirement ที่เราได้รับมามีไม่เพียงพอ หรือกำกวม มันจะโผล่มาตั้งแต่ตอนนี้ครับ แล้ว project manager ก็จะไปตีรันฟันแทงกับลูกค้าเอง ในการทำให้มันชัดเจน แล้วก็กลับมาเขียน spec ใหม่อีกที
ปัญหาใน comment ข้อแรก มันจะโผล่มาตั้งแต่ก่อน coding ไม่ต้องรอไปจนถึงการทำ UAT ครับ เริ่มต้นใหม่เหมือนกัน แต่ก็ไม่ต้อง code ให้เสียแรง และไม่ต้อง test ให้เปลืองพลัง
หลังจากนั้น ผมก็ต้อง implement ในส่วนของ spec(testing) กับ business logic และต้อง test ให้ spec ผ่านหมดทุกกรณี ถ้าเราเขียน spec ละเอียด และ test ให้ผ่านหมดทุกกรณี ปัญหาใน comment ข้อที่สอง ก็จะหมดไป(ต้องให้ผ่านหมดทุกกรณีนะครับ และ programmer ก็ห้ามหลอกตัวเองด้วย เหอๆ)
test ผ่านหมด ก็แสดงว่า implement หมดพอดี ต่อไปก็จัดการฝั่งหน้าตาให้มันสวยงาม เราก็ไม่ต้องไปกังวลกับฝั่ง business logic ให้มากความ ถึงต้องกลับไปซ่อม ก็ไม่เหนื่อยมาก
แต่ก็ใช่ว่าเขียน test แล้ว จะไม่มีปัญหาเลย ยังไงๆ ก็ยังมีปัญหาที่คาดไม่ถึงอยู่อีก แต่มันก็ทำให้ฝั่ง tester ทำงานได้สบายขึ้น เวลา test ก็น้อยลง งานก็เสร็จเร็วขึ้น(ถ้าไม่ไปตายตอนเรียนรู้การเขียน test เสียก่อน)
Test first ที่ผมใช้งานอยู่ ไม่ยากเลย 
ปล. ผมใช้ BDD ครับ คำศัพท์อาจจะไม่ค่อยคุ้นเท่าไหร่ ไว้ค่อยๆ เขียนอีกทีในครั้งต่อๆ ไป
ปอ. ผมจะลอง BDD ฝั่ง PHP ละกัน ดูเหมือนจะไม่ค่อยมีใครใช้ Ruby :p
ปฮ. เอ๊ะ ถ้าคนเขียน spec เป็น tester จะเขียนได้ละเอียดกว่า programmer ไหม??
February 14th, 2008 at 6:48 pm
:clap: :clap:
เยี่ยมค่ะ Quality งานระดับต้นๆ ได้ดีทีเดียว ก่อนถึง UAT แล้วจะติดตาม BDD นะคะ
:worship:
February 14th, 2008 at 7:04 pm
“ปฮ. เอ๊ะ ถ้าคนเขียน spec เป็น tester จะเขียนได้ละเอียดกว่า programmer ไหม??”
อืมม…ขอกลับไปคิดก่อนค่ะ..แล้วจะมาแสดงความเห็นต่อ..อิอิ
February 17th, 2008 at 10:08 pm
ถ้าคนเขียน spec เป็น tester จะเขียนเอกสาร spec ได้ละเอียดกว่าค่ะ และจะ test ได้ละเอียดกว่าด้วย พอดีว่าทำงานในส่วนของ SA และ tester ด้วย คือเริ่มจากไป get requirement กับลูกค้า ทำเอกสาร RS, FS, Design UML รวมถึงมีส่วน review prototype และ database ดังนั้นสามารถพูดคุยกับ programmer ได้ในกรณีที่อ่านเอกสารแล้วยังไม่เข้าใจ หรือสามารถย้ำเตือนในบางจุดที่คิดว่า programmer จะลืมได้ (ก่อน test จริง) ก็จะสามารถลด bug ลงได้บ้าง แต่คงไม่ทั้งหมดนะคะ บางครั้งการสื่อความกับ programmer ก็เป็นสิ่งสำคัญ ที่ว่าเข้าใจอาจจะเข้าใจคนละอย่างก็ได้ ต้องระวังดีๆ ค่ะ :dance:
February 18th, 2008 at 6:38 pm
เอกสาร spec <- ไม่ค่อยเข้าใจกับคำนี้ครับ
spec ในที่นี้ ไม่เชิงเป็นเอกสารครับ แต่มันเป็น code ของภาษานั้นๆ ที่เรากำลังทำงานด้วย
แต่ฝรั่งเขาก็เอาไปใส่ในเอกสารเหมือนกัน
February 25th, 2008 at 3:03 pm
สวัสดีค่ะ พอดีพึ่งมาเจอเว็บนี้ค่ะ เป็นเว็บที่หามานานแระ อยากพูดคุยกับคนที่ทํางานด้าน Software Tester โดยตรงค่ะ ฝากเนื่้อฝากตัวด้วยนะค่ะ
มีเรื่องจะรบกวนค่ะ ใครก็ได้ช่วย Guide หน่อยว่า Scope and Step ของการทํางานตําแหน่ง Testerเนี้ย ต้องทําอะไรบ้าง รบกวนช่วยเรียงลําดับเป็นข้อๆ เอาแบบละเอียดๆ หน่อยนะค่ะ พอดีงานที่เคยทํามาทําควบคู่ 2 ตําแหน่งค่ะ คือ เป็น Project Coordinate and Tester แต่ตอนนี้กําลังจะเริ่มทํางาน Tester โดยตรง อยากทราบว่างานที่ควรทําก่อนและหลัง(เป็นลําดับ) ของ Tester มีอะไรบ้าง และ Tester ต้องเข้าไปมีส่วนเกี่ยวข้อง Part ไหนของ วงจร SDLC ไม่รู้โพสผิดห้องหรือเปล่า ยังไงรบกวนช่วยตอบให้ทีนะค่ะ จะคอยติดตามบ่อยๆ ค่ะ
February 25th, 2008 at 3:08 pm
อ้อ!! เห็นคุณ PunNeng เขียน Spec เลยสงสัยว่า Tester ต้องเขียน Code แบบนี้ด้วยเหรอค่ะ
February 26th, 2008 at 7:44 pm
Pooky: ไม่จำเป็นครับ กระบวณการนี้ มักจะเป็น programmer ครับ ที่ต้องเขียน แนวคิดมันมาจากกระบวณการที่เรียกว่า extreme programming ครับ แล้วปรับปรุงมาจนมาเป็น BDD ใน agile software development
agile software development -> http://en.wikipedia.org/wiki/Agile_software_development
February 29th, 2008 at 6:05 pm
ขอบคุณค่ะ คุณปั้นเหน่งค่ะ รบกวนอีกนิดนะค่ะ ช่วยตอบคําถามนี้ให้ด้วยค่ะ
ใครก็ได้ช่วย Guide หน่อยว่า Scope and Step ของการทํางานตําแหน่ง Testerเนี้ย ต้องทําอะไรบ้าง รบกวนช่วยเรียงลําดับเป็นข้อๆ เอาแบบละเอียดๆ หน่อยนะค่ะ พอดีงานที่เคยทํามาทําควบคู่ 2 ตําแหน่งค่ะ คือ เป็น Project Coordinate and Tester แต่ตอนนี้กําลังจะเริ่มทํางาน Tester โดยตรง อยากทราบว่างานที่ควรทําก่อนและหลัง(เป็นลําดับ) ของ Tester มีอะไรบ้าง และ Tester ต้องเข้าไปมีส่วนเกี่ยวข้อง Part ไหนของ วงจร SDLC
ขอบคุณล่วงหน้าค่ะ
March 1st, 2008 at 12:51 am
ผมไม่รู้ครับ ผมเป็นโปรแกรมเมอร์
March 2nd, 2008 at 9:53 pm
คำถามของคุณ Pooky, ผมจะจัดให้ละกันนะครับ เป็นในส่วนของ Process งาน Test ที่ office ผมละกัน จะได้เห็นภาพว่า Tester จะเข้าไปใน SDLC ตอนไหน และทำอะไรบ้างครับ :#1: