Monthly Archives: April 2012

QA first and Specification by Example Book

เมื่อหลายเดือนก่อน เกิดตะหงิดๆ ใจ กับอาการตีปิงปอง story ระหว่างทีม Dev กับ QA คือ มีหลายๆ ครั้งที่ story เปลี่ยนสถานะ จาก กำลังทำ -> เสร็จ -> reject -> กำลังทำ -> … วนไปวนมาอยู่หลายรอบ

ปัญหามักไม่ได้เกิดจาก bug ในการ implement แต่เกิดจากทีม dev ไม่สามารถเก็บครบทุก edge case, corner case ของ story นั้นได้

ด้วยความรู้นิดหน่อยของไอเดีย outside-in และคิดว่ามันน่าจะเป็นคำตอบของปัญหานี้ เลยไปหาหนังสือเกี่ยวกับเรื่องนี้มาอ่าน ก็ได้ Specification by Example มา

คอนเซปของเรื่องนี้ มีหลายชื่อเรียกมาก ทั้ง Acceptance Test Driven Development(ATDD), Behavior Driven Development(BDD), User Story Driven Development และ Specification by Example (เชื่อว่ายังมีอีกแต่ได้ยินมาแค่นี้)

หลักการของมันคือ ถ้าเราเอาการตรวจสอบคุณภาพไปอยู่หลังการพัฒนา สิ่งที่มักเกิดขึ้นคือเราพัฒนาไปผิดทาง เพราะฉะนั้นแล้ว ก็กลับเอาการตรวจสอบคุณภาพ (QA process) มาอยู่ข้างหน้าซะ

สิ่งที่เกิดขึ้นคือ แทนที่เราจะตีปิงปองกับการ manual test ของ QA เราก็ไปตีปิงปองกับ acceptance test ที่ QA เขียนไว้แทน

ผลที่ได้คือ

  • Dev หลงทางน้อยลง
  • QA มีเวลาไปทำการ test ท่าประหลาดๆ มากขึ้น

มากไปกว่านั้นแล้ว ยังมีการพยายามนำฝ่าย business เข้ามาร่วมในขั้นตอนการเขียน test ของ QA ด้วย เพื่อให้ตรงความต้องการมากขึ้น

สำหรับตัวหนังสือ มีเรื่องราวที่น่าสนใจดังนี้

  • เค้าใช้วิธีการสร้างตัวอย่าง(ตามชื่อหนังสือ)ในการคุยกับฝ่าย business เช่น ยกตัวอย่าง input นี้มา ต้องการ output แบบนี้ใช่มั้ย
  • มีตัวอย่างสถาณการณ์เยอะมาก แต่ละสถานการณ์ก็แนะนำต่างวิธีไป เช่น ถ้ามี TOR ก็เอา TOR นั่นแหละมาสร้าง example
  • ผลจากการทำ เค้าเน้นว่าการได้ living document เป็นประโยชน์มากกว่า automate validation เสียอีก
  • ไม่แนะนำให้ใส่ workaround ไปใน example ให้ใส่เฉพาะ business requirement
  • เน้นให้เขียน example ไม่ผูกกับการ implement test เพราะจะทำให้ example ถูกต้องตลอดการ และไม่มีผลต่อการเปลี่ยน test, implementation หรือเปลี่ยน platform
  • เราควรเข้าใจถึงความต้องการตั้งต้นของฝ่าย business ที่เป็นที่มาของ feature ที่เค้าให้เราทำ เพราะบางครั้งเราอาจเสนอวิธีทำที่ง่ายกว่า และตรงความต้องการกว่าได้

วิธีการนี้ใช้ได้กับทุก process นะครับ ไปลองกันดูได้

[Presentation note] Does pair programming have to suck?

ช่วงนี้ติดตาม podcast ของ Ruby Rouges อยู่เป็นประจำ เค้าคุยกันเรื่องสัพเพเหระของ software development เกี่ยวกับ Ruby บ้างไม่เกี่ยวกับ Ruby บ้าง แต่เข้าใจว่าผู้ร่วมรายการส่วนใหญ่เป็นคนที่ใช้ Ruby

แล้วได้ฟังตอน 049 RR Agile Communication with Angela Harms ได้ยินผู้ร่วมรายการคนหนึ่งชม presentation ของแขกรับเชิญในเทปนั้นเรื่อง pair programming มาก บวกกับยังมีอารมณ์ค้างจาก session Pair Programming Done Right ใน CITCON อยู่ เลยตามไปดู presentation นั้นซะหน่อย

Does pair programming have to suck?

เค้าก็พูดถึงประโยชน์ของ Pair Programming และเล่าถึงเหตุการณ์ไหนที่มักทำให้คนไม่อยาก pair เช่น

  • ฝ่ายนึงอ่อนไป
  • ฝ่ายนึงเก่งไป
  • อยากรีบทำให้เสร็จ
  • อยากทำอย่างมีสมาธิ
  • งานหน้าเบื่อ
  • ต่างคนต่างเขียนโปรแกรมคนละสไตล์กัน

แต่การที่ pair ไม่ได้ด้วยเหตุผลข้างต้นนี้ อาจจะมองได้ว่าเรามีปัญหาหรือไม่อยาก communicate หรือเปล่า ซึ่งจริงๆแล้วสิ่งนี้เป็นสิ่งที่สำคัญที่สุดสำหรับ software development นะ

Screen_shot_2012-04-23_at_10

CITCON Asia 2012 at Singapore

มันย่อมาจาก Continuous Integration Testing Conference ซึ่งเริ่มตั้งแต่เมื่อวานตอนเย็น และวันนี้ทั้งวัน มีคนไทยมาร่วมงานนี้ด้วยอีก 2 คน คือ พี่ @kluak110 กับพี่ @sinapam ครับ

ในส่วนของเมื่อวานตอนเย็นเป็นช่วงเปิดงาน ทำความเข้าใจสไตล์ของงาน สิ่งที่ควรทำและไม่ควรทำในงาน แล้วก็ประกาศหัวข้อกัน สามารถติดตามอย่างละเอียดได้ที่ blog ของพี่ Kulawat ได้นะครับ

Openspace

หัวข้อโดยคร่าวๆ ก็เป็นตามนี้  http://citconf.com/wiki/index.php?title=CITCONAsia2012Sessions แต่ในระหว่างวันก็โดนผู้ร่วมงานสลับสับเปลี่ยนกันตามใจ เลยทำให้งานจริงๆ ต่างจากนี้ไปบ้าง บางหัวข้อคนพูดไม่อยากพูดแล้วเพราะเวลาชนคนที่เค้าอยากเข้าฟัง ก็ไปถอดออกจากบอร์ดเลยก็มี

Session ที่ผมเข้าฟังก็มีตามนี้ครับ

CI In A System Of Systems Environments 

หัวข้อนี้คนพูดทำอยู่ในสายเกี่ยวกับการวางระบบเน็ตเวิร์คของ Australia การทำ test ของงานเค้ามันดูยากมากเลย ทั้งต้อง test คลุมตัวอุปกรณ์ของบริษัทอื่นๆ ที่เอามาใช้ด้วย ทั้งมีอุปกรณ์เก่าที่ใช้งานอยู่แล้วอีกไม่รู้กี่พันกี่หมื่นตัว ฟังแล้วคิดไม่ออกเลยว่าจะทำยังไงให้มันมี feedback cycle ที่สั้นๆ ได้ยังไง

TDD vs BDD
หัวข้อนี้คนเริ่ม topic ตั้งใจจะนำไปคนละทางกับบทสนทนาที่เกิดขึ้นจริงในห้องเลย เค้าอยากคุยเรื่องใครใช้สไตล์การเขียน test แบบไหนใคร stub, mock, fake object แต่มันกลายไปเป็นหัวข้อที่พูดถึงเรื่องต่อไปนี้แทน

  • สไตล์การพัฒนาโปรแกรม outside-in, middle-out(?) แล้วก็ inside-out ซึ่งก็พอได้ข้อสรุปว่างานส่วนมากเหมาะกับ outside-in เพราะช่วยให้เราลดการเขียน code แล้วไม่ได้ใช้น้อยลง แต่มีงานบางอย่างที่มีคุณสมบัติว่า requirement ไม่ได้สำคัญมากเท่า technical limitation ซึ่งงานแบบนั้นก็เหมาะกับ inside-out มากกว่า
  • พบว่า ATDD, BDD, User story driven development และ Specification by Example มันคือสิ่งเดียวกัน มันคือ TDD + business requirement นั่นเอง ข้อเสียของการเกิดเหตุการแบบนี้คือ แต่ละค่ายทำ tool ของตัวเองที่สุดท้ายแล้วมันก็คือสิ่งเดียวกัน เช่น robotframework (ของค่าย ATDD) และ cucumber (ของค่าย BDD) ซึ่งทำให้เสียโอกาสในการพัฒนาไป

CI In A Lean Startup World ผู้พูดเสนอแนวคิดดังนี้

  1. Continuous Integration เป็น process เพื่อทดสอบว่าการรวมกันของ code เราสามารถทำได้
  2. Continuous Deployment เป็น process ต่อจาก CI เพื่อทดสอบว่า deployment ที่เกิดจาก code เราสามารถทำงานได้ไม่มีปัญหา
  3. Lean Startup เป็น process ต่อจาก CD เพื่อทดสอบว่า product ที่เกิดจาก code เรา user ชอบ

ซึ่งในโลกความเป็นจริง แล้วมันก็ไม่สามารถเทียบได้โดยตรงแบบนั้น มีคนนึงแสดงความเห็นว่าเพราะในขั้น Lean Starup เราทดสอบกับ user ซึ่งคือคนจริงๆ ที่เป็นสิ่งที่มี state มีการจดจำสิ่งที่เคยเกิดขี้นมาก่อน แต่ใน CI กับ CD เราทดสอบกับ test ที่เราพยายามเขียนให้ไม่มี state ผลที่ได้จาก Lean Statrup จึงไม่ได้เที่ยงตรงและ revert ได้เหมือน CI, CD แต่อย่างไรก็ตาม พบว่าการพยายามสร้างความสัมพันธ์นี้เป็นความคิดที่น่าสนใจทีเดียว

Pair Programming Done Right
session นี้ผมเข้าเพราะที่บริษัทผมทำ pair programming อยู่แล้ว และผมมีคำถามคาใจอยู่

pair programming ทำเพื่อป้องกัน bus effect (รถบัสชนคนที่รู้ code นั้นคนเดียวตาย)
คำตอบของคนที่ไม่ชอบ pair มีสองเรื่องที่ถูกตอบบ่อยมากคือ เบื่อขี้เกียจรออีกคน และอีกคนไม่รอทำอะไรไม่รู้
ผู้พูดเสนอ pattern การทำ pair programming มี 3 แบบ

  • Ping-pong A เขียน 1 test, B ทำให้ test ผ่าน และเขียนอีก 1 test ส่งกลับให้ B, … เหมาะสำหรับคู่ pair ที่เท่าเทียมกัน
  • Board and mouse คนรู้มากกว่าใช้ mouse คนรู้น้อยกว่าใช้ keyboard ใช้แก้ปัญหาคนรู้ไม่รอคนไม่รู้
  • pattern ที่สาม(ฟังชื่อภาษาอังกฤษไม่ออก) เหมือนกับการซ้อมตี Baseball โดยคนรู้เขียน test อย่างเดียว คนไม่รู้เขียน production code อย่างเดียว ใช้สำหรับให้คนรู้สามารถสร้างกรอบทางเดินให้คนไม่รู้ได้

Frameworks Dont Make Testing Easy Enough
session นี้เหมือนรวมญาติ เพราะคนที่ร่วมเป็นคนที่ทำๆ งานด้วยกันเกินกว่าครึ่งห้อง

คนเริ่มหัวข้อเค้าแสดงความเห็นว่า framework ที่เค้าได้เคยใช้ (Rails และ Android) มันรัน test ช้า ทำให้มีปัญหากับ TDD cycle เค้าเลยได้ลองคิดว่าจะพัฒนา หรือทำใหม่ควรจะต้องทำอะไร

แต่พอคุยกันไปมาพบว่าตัว Rails จริงๆ ตอนใช้แรกๆ ก็เร็วเพียงพอ แต่มันมาช้าเพราะ gem ที่ load เข้าไปเยอะๆ มากกว่า การจัดการระบบ module ที่ดีขึ้นอาจจะช่วยได้ แต่ก็จะไปขัดกับเจตนาที่ให้ feature ทั้งหลายมันออกมาแบบ out-of-the-box อย่าง magic อีก

ปิดงานด้วยการพูดรายคนว่าใครมี AHA moment อะไรในงานนี้กันบ้าง

ชอบมากครับงานนี้ ไม่เคยไป conference ไหนที่ไม่มีช่วง session ที่รู้สึกไม่อยากเข้าห้องไหนเลยมากก่อน

 

ขออภัยที่ไม่ได้ลงรูป ไม่ได้ถ่ายเยอะเท่าไหร่ และที่ถ่ายมาเบลอมาก
สามารถติดตามรูปได้จาก Facebook ของ Stanly คนจัดประจำของ Agile Singapore meetup
และจาก Facebook ของ agile66 group ที่พี่ๆ เค้าถ่ายละกัน (กด previous)