[ShijiemiS]

อ่านแล้วๆๆ ...น่าสนใจ...แต่ตอนนี้ยังทำอย่างนี้ไม่ได้ค่ะ ShijaemiS ต้องไปฝีกเป็นโปรแกรมเมอร์ก่อน เริ่มต้นทำงานก็ทำเทสมาตลอดเลยไม่เก่งด้าน Coding เท่าไหร่ค่ะ แต่จริงก็คิดว่าถ้าเป็นโปรแกรมเมอร์มาก่อนคงมองอะไรได้เยอะขึ้นอย่างที่ทุกคนบอกอ่ะค
่ะ มีแต่ Business เต็มหัวไปหมดเลยแต่ เขียนโปรแกรมไม่ได้ เวลาเจอเคสที่เทสไม่ผ่านมีปัญหาก็พอมองออกบ้างว่าต้องแก้ตรงไหน แก้ยังไง แต่ให้ทำเองทำไม่เปงหง่ะเศร้าไหมหล่ะ ไอ้ครั้นจะกลับไปเอาดีทาง โปรแกรมเมอร์จะทันกิน เหมือนชาวบ้านเค้าไหมเนียะในเมือ่เค้ายึดประสบการณ์การทำงานเป็นหลัก เฮ้อยิ่งคิดยิ่งไกลแต่ก็จะไปให้ได้ค่ะ แม้นไม่เก่งเท่าใครแต่ขอรู้เยอะกว่าที่เคยเป็นก็ Ok แล้วเอาชนะตัวเองได้ก็ดีแล้ว อิอิปลอบตัวเองไปวันๆๆ


ขอบคุณมากนะค่ะ คงมีสักวันได้ลองใช้วิธีของคุณ juacompe ค่ะ ถ้ามีอะไรใหม่ๆเกี่ยวกับงานเทสมาเล่าสู่กันฟังอีกนะค่ะอยากฟังมากๆๆค่ะ ตอบมาได้เลยค่ะเด๋วระบบจะส่งเมลล์ไปบอก แล้วจะรีบมาอ่านนะค่ะ

[rino]

อยากทราบว่า จะค้นหาความรู้ได้ ที่แหล่งใดบ้าง เช่นพวกหนังสือ web หรือการเรียนการสอน
รบกวนท่านสมาชิก แนะนำหน่อย จักเป็นนพระคุณอย่างสูง
tester มือใหม่

[minimalist]

สวัสดีครับ

ไว้จะหาเว็บไซต์ document หนังสือมาแนะนำให้นะครับ

=======================================================

Software Testing ตอนนี้เป็นวิกฤตในเมืองไทยอย่างหนึ่งทีเดียว หลายองค์กรเริ่มให้ความสนใจมากขึ้น
แต่ยังเป็นเพียงความสนใจเท่านั้น การดำเนินการอย่างถูกต้องจริง ๆ มีทำกันน้อยมาก คนมีความรู้ด้านนี้จริง ๆ น้อยมาก
เมืองไทยตอนนี้ขาดบุคลากรผู้เชี่ยวชาญด้านนี้มาก และที่แย่กว่าด้านอื่น ๆ (Programming, Design,
Project Management, ฯลฯ) คือ บุคลากรที่จะสอนจริง ๆ จัง ๆ 'ไม่' มี (ไม่นับหลักสูตร Testing ของเวนเดอร์)

Software Testing คือการผสมผสานกันระหว่าง Theory + Tool ทำให้ไม่ค่อยมีคอร์สอบรมด้านนี้เท่าไหร่
เพราะสอนแต่ทฤษฏีก็ไม่ได้ คอร์สอบรมส่วนมากจึงสอนทฤษฏีส่วนหนึ่งและจำเป็นต้องสอนการใช้ Tool ส่วนหนึ่ง
เลยเป็นข้อจำกัดและภาคบังคับเรื่องการใช้ Tool ไป ผู้เรียนกลับไปทำงานไม่ได้ใช้ Tool ยี่ห้อนี้หรือตัวนี้ก็ไม่ค่อยได้ประโยชน์
คอร์สพวกนี้จึงมักเป็นคอร์สสำหรับลูกค้าที่ซื้อ Tool ไปแล้วแล้วค่อยมาเรียนวิธีใช้และเรียนภาคทฤษฏี
หรือหากเป็นพวกคอร์สที่ใช้ Tool พวก OpenSource ก็ลำบากนิด เพราะมันมีให้เลือกใช้เยอะ ต้องจับโน่นมารวมกับนี่
หากจะทดสอบแอพพลิเคชั่นชนิดนั้นก็ต้องใช้ตัวนี้กับตัวนั้น หากจะทดสอบอีกชนิดก็ต้องใช้ตัวโน้นกับตัวนู้น

เมื่อไรก็ตามที่คนส่วนใหญ่มองการพัฒนาซอฟต์แวร์เป็นอุตสาหกรรมการผลิตสินค้าชนิดหนึ่
ง เหมือนอุตสาหกรรมการผลิต
สินค้าชนิดอื่น ๆ ทั่วไปให้ได้ ไม่ใช่มัวแต่มองว่าซอฟต์แวร์เป็นสินค้าที่ High Touch and High Technology
(จริง ๆ ไม่ค่อยจะ High Return นะ นอกจากว่ามี 'อะไร ๆ' พร้อมสรรพ)
เมื่อนั้นคนส่วนใหญ่คงให้ความสำคัญกับคำว่า Quality มากขึ้น เพราะการทดสอบ ต้องทดสอบหมดทุกจุดทุกช่วงของกระบวนการ
พัฒนา (ผลิต) ซอฟต์แวร์ ไม่ใช่ทอสอบซอฟต์แวร์อย่างเดียว และไม่ใช่มานั่งทดสอบกันเอาตอนท้าย ๆ และยังต้องทดสอบ
อย่างต่อเนื่อง (Continually Verify Quality) อีกด้วย

เมื่อไม่กี่ปีก่อนในรัฐบาลชุดที่ผู้นำหลายคนจบปริญญาเอกด้านการตลาด การจัดการ บริหาร ฯ จากเมืองนอก และหลายคนเป็น
นักธุรกิจชั้นเซียน และอีกหลายคนเป็นลูกศิษย์ของกูรูชั้นนำระดับโลก ได้เจียดเงินภาษีประชาชนจ้างกูรูด้านกลยุทธ์ระดับโลก
อย่าง Michael E. Porter มาบรรยาย Porter ได้วิเคราะห์และกำหนดยุทธศาสตร์ด้าน Cluster สำหรับเมืองไทยไว้
5 Cluster หนึ่งในนั้นคือ อุตสาหกรรมซอฟต์แวร์ ในรูปกราฟที่ได้มีการเปรียบเทียบกับ Cluster อื่น ๆ ทำให้ผู้ได้พบเห็น
ทราบว่าอุตสาหกรรมซอฟต์แวร์เป็นอุตสาหกรรมที่มีความเสี่ยงสูงที่สุดและเข้าถึง (เข้าใจ) (High Touch) ได้ยากที่สุดใน
5 Cluster ไม่แปลกที่รัฐบาลชุดดังกล่าวจึงไม่ทุ่มเทกับอุตสาหกรรมนี้เท่าไร แต่สร้างภาพด้วยการทุ่มกับ Segment หนึ่ง
เป็นหลักนั่นคือด้าน Animation เพราะเป็นรูปธรรมที่สุดและลูกหลานบางคนก็ทำธุรกิจด้านนี้อยู่ ทั้ง ๆ ที่อุตสาหกรรมย่อยอย่าง
แอนิเมชั่นนั้นเทียบไม่ได้เลยกับ Value ทั้งหมดที่มีในอุตสาหกรรมซอฟต์แวร์บ้านเรา สิ่งที่ควรสนับสนุน ส่งเสริม และขับเคลื่อน
อย่างแท้จริง ๆ ควรเป็นรถไฟทั้งขบวนมากกว่า ไม่ใช่แค่โบกี้เดียว
* Cluster อื่นเช่น Detroit of Asia รู้สึกว่าจะล่มไปแล้ว เพราะการเมือง และมัวแต่เน้นให้เมืองไทยเป็นฐานการผลิต
และการประกอบ (แรงงานฝีมือดี... อีกแล้ว) ตอนนี้เขาเริ่มเบนเข็มไปจีนไปเวียดนามกันแล้ว เพราะการเมืองมีเสถียรภาพ
และนโยบายภาครัฐชัดเจน หรือแม้แต่ Cluster 'ครัวไทย... ครัวโลก' เพียงแค่ปัญหาข้าวหอมมะลิกับผัดไทถูกแอบจดลิขสิทธิ์
ยังวิ่งไล่แก้ปัญหากันแทบตาย โถ... แต่อย่างน้อยอาหารไทยก็ติดอันดับโลกนะ...


Software Testing เป็นศาสตร์และศิลปเช่นกัน มีมิติและระดับความลึกที่ซับซ้อน การทดสอบซอฟต์แวร์แบ่งได้เป็นหลัก ๆ 3 มิติคือ
1. Functional Testing คือ การทดสอบเชิงฟังก์ชั่น หรือ ทดสอบ Functional Requirements นั่นเอง
2. Reliability Testing คือ การทดสอบเชิงความน่าเชื่อถือ เช่น การคำนวณ การใช้ทรัพยากรหรือเข้าถึงข้อมูลพร้อม ๆ กัน เป็นต้น
3. Performance Testing คือการทดสอบเชิงประสิทธิภาพ มักเกี่ยวกับเวลา ซึ่งแบ่งออกเป็น
3.1 Application Performance Testing คือ ประสิทธิภาพของโปรแกรมของเราเอง
3.2 System Performance Testing คือ ประสิทธิภาพของโปรแกรมเมื่อทำงานบนสภาพแวดล้อมจริง หรือ Simulate ให้เหมือนจริง

การทดสอบเชิง Reliability และ Performance เป็นการทดสอบ Non-Functional Requirements

ดังนั้นการเขียน Test Case สำหรับการทดสอบเชิง Functional นั้นไม่ต่างจากการเขียน Use Case Specification นัก
เพราะเป็นการทดสอบ Main Flow / Basic Flow และ Alternative Flow(s) / Exceptional Flow(s) ตามที่ได้ระบุ
ใน Use Case Specification ลำดับขั้นตอนต่าง ๆ ก็ล้อกันมา เพียงแต่เพิ่มเติมรายละเอียดที่จำเป็นเข้าไปเพื่อให้เป็น Test Case

การเขียน Test Case ในลักษณะนี้จึงไม่ยากนัก แต่การเขียนสำหรับการทดสอบเชิง Reliability และเชิง Performance นั้นก็จะเขียนยากขึ้นมา

การเขียน Test Case ที่ดีต้องเป็กนักจำลองเหตุการณ์ (Scenario) ที่ดี ใน 1 Scenario อาจมี 1 Case หรือหลาย Case
หรืออธิบายอีกอย่างได้ว่า 1 Test Case อาจใช้สำหรับทดสอบเหตุการณ์เดียว หรือ นำหลาย ๆ Test Case มารวมกัน
เพื่อทดสอบหลาย ๆ เหตุการณ์ที่เป็นส่วนหนึ่งของเหตุการณ์ที่ใหญ่ขึ้น อาจเรียกว่า Test Suite หรือมอง Test Case เปรียบเหมือนอ็อบเจ็คต์ในหลัก Object-Orientation ก็ได้

ตัวอย่างเช่น มีการจำลองการทดสอบเหตุการณ์ใหญ่อยู่ 1 เหตุการณ์คือ 'สั่งซื้อหนังสือออนไลน์' เรียกว่า Test Suite
ประกอบด้วย การทดสอบเหตุการณ์ย่อย ๆ หรือ Test Case คือ
1. 'สมัครสมาชิก' ถือเป็น Prerequisite หรือ Precondition
2. 'ค้นหาและดูรายละเอียดหนังสือ'
3. 'หยิบหนังสือใส่ตะกร้า' มีเงื่อนไขว่ากลับไปทำเหตุการณ์ 'ค้นหาและดูรายละเอียดหนังสือ' ได้อีก
4. 'Check Out' คือการแสดงรายการสรุปหนังสือที่ต้องการซื้อ
5. 'ชำระเงิน'
5.1 'ชำระเงินผ่านระบบ Payment System' ซึ่งเป็น Extension Point หรือเงื่อนไข อาจเป็น Test Case ย่อย ซึ่ง
เหตุการณ์นี้ไม่ใช่ Functional Testing ในมุมมองที่มีปฎิสัมพันธ์ (Interactive) กับผู้ใช้ แต่เป็น Functionality Mechanism
ซึ่งเป็นกลไกทางด้าน Functional ในระดับสถาปัตยกรรม การเขียน Test Case สำหรับเหตุการณ์ย่อยนี้ก็จะแตกต่างไปบ้าง

เมื่อแบ่งการทดสอบเป็นเหตุการณ์ย่อย ๆ ได้แล้ว อยากจะทดสอบบางเหตุการณ์ก็สามารถทำได้ หรือจะทดสอบเหตุการณ์ใหญ่ก็ทำได้
โดยทดสอบเรียงลำดับหรือตามเงื่อนไขกันไป

อีกตัวอย่างให้ลองนึกดูเล่น ๆ ว่า คุณต้องการเขียน Test Case เพื่อทดสอบ Reliability สำหรับเหตุการณ์คือ
'ตรวจสอบจำนวนอ็อบเจ็คต์และทรัพยากรที่ใช้ (Memory กับ CPU) ในระหว่างการประมวลผลงานของผู้ใช้ทั้งหมด ณ เวลาหนึ่ง'
ซึ่งเป็น Test Case หนึ่งในการทดสอบตาม Non-Functional Requirement และ Need (Business Requirement) ข้อหนึ่งชื่อ
'ณ ช่วงเวลาที่ Peak ที่สุดที่มีผู้ใช้เข้ามาสั่งซื้อหนังสือออนไลน์ ระบบฯ ต้องสามารถรองรับได้โดยใช้ทรัพยากร (Memory กับ CPU) ที่มีอยู่'
แล้วลองเขียน Test Case ดูว่าควรจะมีหน้าตาอย่างไร จากตัวอย่างประเด็นที่ต้องพิจารณาคือ ช่วงเวลาที่ Peak ที่สุดนี้
โดยเฉลี่ยมีผู้ใช้ทั้งหมดกี่คน และทรัพยากรที่มีอยู่ มีอยู่เท่าไหร่
การจำลองการทดสอบใน Test Case นี้เพื่อต้องการตรวจสอบดูว่าจะมีการสร้างและใช้อ็อบเจ็คต์ทั้งหมดกี่ตัวต่องานหรือต่
อผู้ใช้หนึ่งคน
แล้วมาคำนวณ และการทำงานของแต่ละอ็อบเจ็คต์ใช้หน่วยความจำเท่าไหร่และใช้ CPU กี่ Cycle และอีกหลายวิธีการ
ดังนั้นนอกจาก Tester ต้อง เขียน Test Case แล้ว SA อาจต้องเข้ามาช่วยเขียน Object Story Board
โดยใช้ Object Diagram ใน UML เพื่อจำลองแต่ละ State ในช่วงเวลาต่าง ๆ ที่อ็อบเจ็คต์ทำงาน และเวียนว่ายตายเกิดอยู่ในระบบฯ

ในการเขียน Requirements แบบการจำลองเหตุการณ์ (Scenario) ตามแนวทางของการวิเคราะห์และออกแบบสถาปัตยกรรม
ของ SEI (Software Engineering Institute) ได้มีระบุไว้น่าสนใจมาก ลองเข้าไปหาดูได้ที่ http://www.sei.cmu.edu/architecture
แล้วจะกล่าวถึงต่อไปครับ

ส่วนแนวคิด Test Driven Development นั้นน่าสนใจและดีมาก ๆ ทีเดียว หากมองเปรียบกับอุตสาหกรรมการผลิตสินค้า
อื่น ๆ ทั่วไป มันก็ต้องเป็นแบบนี้ล่ะครับ จะสร้างอะไร จะคิดอะไร จะทำอะไร จะซื้ออะไร เมื่อมีโจทย์ (Requirements) ปั๊บ
ต้องหาทางทดสอบ (Qualify) ก่อนเลย แต่หากนำมาใช้กับการพัฒนาซอฟต์แวร์ในบ้านเรา มันเป็นการเปลี่ยนวัฒนธรรม (Culture)
ของนักพัฒนาซอฟต์แวร์ไทยพอสมควร จริง ๆ จะว่าไปไม่ใช่ที่นักพัฒนาซอฟต์แวร์เสียทีเดียว แต่เปลี่ยนวัฒนธรรมของเหล่า SA,
Project Manager, Project Leader และที่สำคัญ หัวหน้าหรือผู้บริหารเสียมากกว่า
ขืนอยู่ ๆ เขาเดินเข้ามาถาม...

"เขียนโปรแกรมไปถึงไหนแล้ว"

"ยังไม่ได้เขียนเลยครับ ตอนนี้กำลังเขียน Test Case โปรแกรมส่วน Test อยู่"

หัวหน้าหรือผู้บริหารที่ไม่เข้าใจส่วนมากคงหัวฟัดหัวเหวี่ยงกลับไป
แต่ของแบบนี้มันต้องค่อยเป็นค่อยไป เดี๋ยวคนก็เริ่มใช้ขึ้นเยอะเอง ด้วยแนวคิดและการกระทำของพวกหนุ่มสาวหัวก้าวหน้า
แล้วค่อย ๆ ลบล้างแนวคิดของพวก Generation เก่าไป ที่ว่า 'เสร็จแล้วค่อยตรวจ'

สำหรับ Test Driven Development เองก็เป็นแนวทางที่สอดคล้องกับ Agile Software Development ได้
เป็นอย่างดี เพราะแฝงปรัชญาเอาไว้ด้วย และตัว Agile เองก็มีปรัชญาของตนอยู่เหมือนกัน (ประมาณ 10 ข้อ)
เป็นแนวทางที่ไม่ต้องมีพิธีรีตรองอะไรมากเหมือน Software Testing ในกระบวนการพัฒนาซอฟต์แวร์ใหญ่ ๆ อย่าง
CMMI, RUP (Rational Unified Process) ทำให้เรียนรู้และทำความเข้าใจได้ง่าย และโฟกัสไปที่นักพัฒนาซอฟต์แวร์เป็นหลัก
เพื่อทำให้นักพัฒนาซอฟต์แวร์เขียนโปรแกรมเก่งขึ้น เพราะงานหลายส่วนตัวเองก็ต้องเป็นคนเขียน Test เองและทดสอบเอง
ดังนั้นการฝึกให้คำนึงถึงการทดสอบและตรวจสอบ ก่อนเขียนโปรแกรมหรืออิมพลีเม้นต์เป็นสิ่งที่ดี ทำให้รู้จักรอบคอบ
ระมัดระวัง และไม่รีบบ้าคลั่งตะลุยเขียนโปรแกรมหน้าตั้ง พอเจอปัญหาทีก็อาจตามแก้หน้าตั้งเช่นกัน ดังนั้นการคำนึงถึงการ
ทดสอบก่อน แล้วพอเขียนโปรแกรมไปประมาณหนึ่งก็ทดสอบตามกรอบหรือ Test Case ที่วางไว้ เห็นว่าไม่ถูกไม่ดี
ไม่มีประสิทธิภาพก็ทำ Refactor เสีย เป็นกระบวนการแบบ Iterative ทำซ้ำไปซ้ำมาไปเรื่อย ๆ แต่ต้องระวังเรื่อง Interface
เพราะโค้ดและงานออกแบบที่เกี่ยวข้องชุดนั้นอาจแชร์กับนักพัฒนาฯ คนอื่นอยู่ด้วย แต่การแก้ Interface ไม่ใช่เรื่องผิด
และเป็นไปไม่ได้ แต่ต้องอยู่ภายใต้การจัดการที่ดี โดยเฉพาะ Interface ในระดับสถาปัตยกรรม (Architectural Interface)
ต้องใส่ใจเป็นพิเศษ รายละเอียดเรื่อง Test Driven Development ลองหาอ่านเพิ่มเติมหรือในเว็บนี้ก็ได้

นอกจากนี้หลักการด้านสถิติก็สำคัญเช่นกัน เพราะเมื่อทดสอบแล้วต้องรู้จักบันทึกข้อมูลเป็นรายงานเชิงสถิติ พอทำการทดสอบ
ครั้งต่อไป ๆ ก็เอามารวมเอามาวิเคราะห์ เช่น วิเคราะห์พวกส่วนเบี่ยงเบน ค่าเฉลี่ย การเปลี่ยนแปลง จนถึงวิเคราะห์แนวโน้ม เป็นต้น
ยิ่งหากใช้ Tool ทำการทดสอบ ผลการทดสอบมักออกมาเป็นรูปรายงานเชิงสถิติ Software Tester ต้องวิเคราะห์ผลเป็น
ประเด็นที่ยากยิ่งนัก โดยเฉพาะการทดสอบเกี่ยวกับพวก Performance เพราะผลการทดสอบหลาย ๆ ครั้งไม่ได้บอกแค่ว่า
'ถูกต้อง' หรือ 'ผิด' เท่านั้น ดังนั้นต้องรู้จักวิเคราะห์ผลการทดสอบแล้วเอาไปให้สมาชิกในทีม เช่น SA, Developer เป็นต้น
เอาไปปรับปรุงหรือหาโซลูชั่นใหม่หรือเซ็ต Factor ใหม่ แล้วค่อยนำมาทดสอบใหม่ แล้ววิเคราะห์ผลดูว่าการทดสอบครั้งไหนที่ให้ผลที่ 'โดน' ที่สุด
(ไม่ใช่ 'ดี' ที่สุด) ซึ่งหมายถึงให้ผลที่ใกล้ (Meet) กับ Requirement มากที่สุด

มีหนังสือแนะนำเล่มหนึ่ง ชื่อ Effective Software Testing, 50 Specific Ways to Improve Your Testing
โดย Elfriede Dustin อ่านง่ายสนุก น่าสนใจ แต่ก่อนใคร ๆ อาจรู้จักการทดสอบแบบ Black Box ในหนังสือเล่มนี้มีทั้ง
ทดสอบแบบ White Box, Gray Box และอีกหลายอย่าง เป็นหนังสือที่ดีมาก ๆ เล่มหนึ่งและไม่หนานัก เหมาะแก่การวางไว้ข้างตัว
เวลานึกไม่ออกว่าจะทดสอบอะไรบ้าง อย่างไรก็เปิดเล่มนี้เอา

อีกเล่มชื่อ A Practical Guide to Testing Object-Oriented Software โดย John D. McGregor
และ David A. Sykes หากใครพัฒนาซอฟต์แวร์แบบอ็อบเจ็คต์ เช่น ใช้ภาษา Java, C#, VB.NET เป็นต้น แล้วอยากรู้ว่า
ออกแบบและเขียนโปรแกรมตรงตามหลักการของ Object-Orientation หรือไม่ก็ลองอ่านเล่มนี้ดู เล่มนี้มีประโยชน์มาก
เอาไว้เป็น 'เครื่องมือ' จำผิดคนออกแบบและคนเขียนโปรแกรมที่ดีมาก ๆ ว่าแม่นเรื่องอ็อบเจ็คต์แค่ไหน และออกแบบและเขียนโปรแกรม
ได้เหมาะสมกับงานหรือไม่

ส่วนแอพพลิเคชั่นใหญ่ ๆ หากมาเขียน Test Case เองและทดสอบเองไปทุกอย่างอาจเสียเวลาได้ โดยเฉพาะกับทีมเล็ก ๆ
แต่ทำงานใหญ่ อาจลองศึกษาเรื่องการทำ Automated Testing ดูด้วย สำคัญมาก เจ้าตัวนี้ล่ะที่ต้องพึ่ง Tool พอสมควร
แต่ประหยัดเวลาได้เยอะทีเดียว

ส่วนเล่มอื่น ๆ และแหล่งอ้างอิงอื่นไว้จะเอามาฝากครับ เรื่องเกี่ยวกับ Software Testing มีแตกย่อย ๆ ไปหลายประเด็น
ไม่ว่าจะเป็น Process, Method, Tool, Theory, Management ฯลฯ
ช่วงนี้ขอไปสังสรรค์หน่อย ปีใหม่แล้ว เย้!

- อีกทักษะของนักตรวจสอบที่ดี คือ ช่างสังเกต ช่างจับผิด รู้จักมองโลกในแง่ร้ายบ้าง และเป็นนักสถิติ -

minimalist (ณรงค์)
29 ธันวาคม 2549

This post has been edited by minimalist: 29 December 2006 - 06:38 PM

[siros]

minimalist, on Dec 29 2006, 05:51 PM, said:

... ไม่แปลกที่รัฐบาลชุดดังกล่าวจึงไม่ทุ่มเทกับอุตสาหกรรมนี้เท่าไร แต่สร้างภาพด้วยการทุ่มกับ Segment หนึ่ง
เป็นหลักนั่นคือด้าน Animation เพราะเป็นรูปธรรมที่สุดและลูกหลานบางคนก็ทำธุรกิจด้านนี้อยู่ ทั้ง ๆ ที่อุตสาหกรรมย่อยอย่าง
แอนิเมชั่นนั้นเทียบไม่ได้เลยกับ Value ทั้งหมดที่มีในอุตสาหกรรมซอฟต์แวร์บ้านเรา ...

นี่ถ้ายังเป็นรัฐบาลเก่าอยู่ คุณ minimalist อาจะถูกกล่าวหาว่า "ไม่รักชาติ" ได้นะครับ (โทษฐานพูดความจริง) อิอิอิ

ผมมีโอกาสได้อ่านหนังสือทั้งสองเล่มที่คุณ minimalist แนะนำมา (เล่ม Effective Software Testing นี่ยังอ่านไม่จบซะที) ... ยืนยันว่า ควรจะอ่านทั้งสองเ่ล่มครับ
จริงๆ แล้ว .. เท่าที่ผมได้อ่านหนังสือที่เกี่ยวกับ Software Testing มา ... ยังไม่มีเล่มไหนที่ควรอ่านข้ามไปเลยครับ
ขออนุญาตแนะนำเพิ่มนะครับ
Software Testing Techniques (2nd Edition) ของ Boris Beizer
Testing Object-Oriented Systems: Models, Patterns, and Tools (The Addison-Wesley Object Technology Series) ของ Robert V. Binder
Software Testing : A Craftman's Approach (2nd Edition) ของ Paul C. Jorgensen

[Bomber]

เรื่องของ Test-Driven Development (TDD) นั้น ช่วงแรกผมรู้สึกว่ามันไม่น่าจะ work ได้เลย เป็นสิ่งที่ดูทำแล้วจะดีจริงหรือ รู้สึกว่าเสียเวลา ทำไมไม่เขียนโปรแกรมแล้วค่อยทำ Test ละ

แต่หลังจากศึกษาเรื่อง XP development process แล้ว ความคิดเริ่มเปลี่ยนไป เพราะการ Design ใน XP จะทำแค่ระดับ Overview ที่เป็น CDC (Class, Responsibilities, and Collaboration) เท่านั้น แต่พึ่งการ Refactoring แทน ซึ่งการจะทำ Refactoring นั้น Unit-Test เป็นหัวใจสำคัญ ดังนั้นผมจึงต้องลอง

และหลังจากลองทำกับ Project เล็กๆ project หนึ่ง ปรากฏว่า ผมไม่สามารถกลับไปเขียนโปรแกรมแบบเดิมได้อีกต่อไป การทำ Unit-Test เป็นการช่วยทำให้เราเติมเต็มในส่วนของการทำ Detail Design ที่ CDC ขาดไป เพราะมันจะต้องคิด Input และ Output ให้ชัดเจนก่อน ต้องคิดถึง flow ของข้อมูลก่อนเสมอ และเมื่อเขียนไปถึงจุดหนึ่งเอะ โค๊ดชักไม่สวย design เริ่มดูไม่ดี ทำใหม่ดีกว่า ความสุดขอดของ Unit-Test จะบังเกิดขึ้นทันที เมื่อก่อนเวลารื้อโค๊ดที่จะไม่ยากทำเลย เพราะทำแล้วมันจะไปเจ๊งที่อื่นแทน แต่หลังจากทำ Unit-Test ก่อน ไม่ต้องกลัวแม้แต่นิดเดี๋ยว มันทำให้ code ของเรามี Bug น้อยลงมาก (ยังพอมีอยู่เวลา integrate โค๊ด)

ลองสิครับ แล้วจะติดใจ

[ShijiemiS]

Bomber, on Dec 29 2006, 07:31 PM, said:

แต่หลังจากศึกษาเรื่อง XP development process แล้ว ความคิดเริ่มเปลี่ยนไป เพราะการ Design ใน XP จะทำแค่ระดับ Overview ที่เป็น CDC (Class, Responsibilities, and Collaboration) เท่านั้น แต่พึ่งการ Refactoring แทน ซึ่งการจะทำ Refactoring นั้น Unit-Test เป็นหัวใจสำคัญ ดังนั้นผมจึงต้องลอง

ขอถามเพิ่มเติมค่ะ ถ้าเราพัฒนา Software โดยใช้ XP มันมีข้อจำกัด หรือป่าวค่ะว่าต้องเป็น Java หรือพวกที่เป็น Object Oriented เท่านั้น แล้วถ้าเป็นภาษาอื่นๆเช่นพวก PHP มันจะสามารถนำไปประยุกต์ใช้ได้หรือป่าวค่ะ

[Bomber]

XP นั้นจะเหมาะกับพวกภาษาที่เป็น object-oriented มากครับ แต่ว่ามันก็สามารถประยุกต์ใช้กับภาษาที่ไม่ใช่ OO ได้เหมือนกัน แต่จะทำ TDD และ Refactoring ลำบาก โปรเจ็คที่ผมทำอยู่ก็ไม่ได้ใช้ภาษาที่เป็น OO แต่ก็ใช้ XP เป็น development process ก็ลำบากอยู่บ้างแต่ก็ work ดีครับ

[ShijiemiS]

Bomber, on Dec 30 2006, 12:25 AM, said:

XP นั้นจะเหมาะกับพวกภาษาที่เป็น object-oriented มากครับ แต่ว่ามันก็สามารถประยุกต์ใช้กับภาษาที่ไม่ใช่ OO ได้เหมือนกัน แต่จะทำ TDD และ Refactoring ลำบาก โปรเจ็คที่ผมทำอยู่ก็ไม่ได้ใช้ภาษาที่เป็น OO แต่ก็ใช้ XP เป็น development process ก็ลำบากอยู่บ้างแต่ก็ work ดีครับ

อิอิ ขอบคุณมากค่ะคุณ Bomber วันนี้ไม่ไปฉลองปีใหม่เหรอค่ะมีเวลาแวะมาตอบด้วย
ตอนแรกนึกว่าจะได้คำตอบหลังปีใหม่ซะอีกค่ะ พอดีตามอ่านเรื่องการใช้ xp ของคุณ bomber กับคุณ kluak110 อยู่เหมือนกันค่ะ ฟังทั้งสองท่านพูดแล้วดูน่าสนุกดี ไม่น่าเชื่อว่ามันจะได้ผลดีขนาดนั้น และก็พึ่งรู้ว่าโปรเจคที่คุณ bomber ทำอยู่ก็ไม่ได้เป็นแนว OO เหมือนกันค่ะ แต่ทำไมพี่ๆทำแล้วดูมันน่าสนุก แต่ทำไมเราทำแล้วยิ้มทั้งน้ำตาหล่ะเนียะ ทำไรติดไปหมดเยย ยากเจงๆคะ...

1.ถามเพิ่มอีกนิด และคาดว่าจะหลายๆนิดด้วยค่ะ ไม่ทราบว่าเคยมีใครนำ xp ไปใช้กับโปรเจคขนาดใหญ่บ้างหรือเปล่าค่ะ แล้วคิดว่าถ้าใช้กับโปรเจคขนาดใหญ่มันจะ WOrk ไหมค่ะดูเหมื่อนเค้าคิดมาเพื่อโปรเจคขนาดเล็ก ไม่ซับซ้อนมากนัก เป็นโปรเจคที่ต้องการความรวดเร็วมากกว่าด้วยหลักการและวิธีการของ xp มันค่อนข้าง Work ในเรื่องของงานคือได้สิ่งที่ user ต้องการจริงๆถูกต้องมาตั้งแต่การทำงานข้างในเลยด้วยซ้ำ..แถม user มีส่วนร่วมในการพัฒนาตั้งแต่ต้นๆเห็นความเป็นไปทั้งหมดรู้ว่าสิ่งไหนใช่หรือไม่ใช่ discuss กันณ ตอนนั้นเลย..

2 แต่ดูเหมือน XP เค้าไม่ได้ Require ในส่วนของ Tester ใช่ไหมค่ะเพราะดิฉันมองไม่เห็นช่วงจังหว่ะที่ Tester จะเข้าไปทำงานได้เลย เหมือนกับว่า Programmer จัดการเองหมดเลยคือ Code เองเทสเองและเทสไปพร้อมๆกับ User เลยแล้วถ้าทุกคนหันมาทำ xp หมด Tester ไม่ตกงานกันหมดเหรอเนียะ . ..(นี่มันคงเป็นผลจากกลุ่มผู้คิดค้น xp ใช่ไหมคะเนียะ.. )

[minimalist]

สวัสดีครับ

ปีใหม่ไม่ได้ไปไหนเลย ฉลองขำ ๆ อยู่แต่ในกรุงเทพฯ

==================================

ก่อนอื่นต้องขอบคุณคุณ Bomber มากจริง ๆ ที่มาแชร์ประสบการณ์เกี่ยวกับ XP และ TDD ให้
ผมกำลังลองนำ TDD มาใช้ในโปรเจ็คต์เล็ก ๆ ตัวหนึ่งของผมอยู่พอดี
เอาไว้ติดตรงไหนแล้วจะขอคำปรึกษาหน่อยนะครับ

สำหรับคุณ ShijaemiS ลองเข้าไปดูในลิงค์นี้ดูนะครับเกี่ยวกับ Principles ของ Agile Software Development
http://www.agilemani...principles.html
ความคิดเห็นก่อนหน้านี้ผมบอกไปว่าเป็นปรัชญาและแนวคิดประมาณ 10 ข้อ (กว่า ๆ)
เพราะ XP (ExTreame Programming) เองก็เป็นแนวทางหนึ่งของ Agile ได้เช่นกัน

ส่วนใน XP นั้นเน้นให้โปรแกรมเมอร์ทำ Unit Testing เองครับ เพราะไม่ว่ากระบวนการใหญ่ ๆ อย่างพวก CMMI, RUP
ก็มี Best Practice ว่าโปรแกรมเมอร์ควรเขียนและทำ Unit Test เอง ส่วน Test อื่น ๆ เช่น Integration Test
ควรมีทีมหรือคนกลางทำหรือ Coordinate

minimalist (ณรงค์)

[Bomber]

ShijaemiS, on Dec 30 2006, 12:24 PM, said:

1.ถามเพิ่มอีกนิด และคาดว่าจะหลายๆนิดด้วยค่ะ ไม่ทราบว่าเคยมีใครนำ xp ไปใช้กับโปรเจคขนาดใหญ่บ้างหรือเปล่าค่ะ แล้วคิดว่าถ้าใช้กับโปรเจคขนาดใหญ่มันจะ WOrk ไหมค่ะดูเหมื่อนเค้าคิดมาเพื่อโปรเจคขนาดเล็ก ไม่ซับซ้อนมากนัก เป็นโปรเจคที่ต้องการความรวดเร็วมากกว่าด้วยหลักการและวิธีการของ xp มันค่อนข้าง Work ในเรื่องของงานคือได้สิ่งที่ user ต้องการจริงๆถูกต้องมาตั้งแต่การทำงานข้างในเลยด้วยซ้ำ..แถม user มีส่วนร่วมในการพัฒนาตั้งแต่ต้นๆเห็นความเป็นไปทั้งหมดรู้ว่าสิ่งไหนใช่หรือไม่ใช่ discuss กันณ ตอนนั้นเลย..

คำว่า Project ขนาดใหญ่ของแต่ละคนอาจจะไม่เหมือนกันนะครับ ผมไม่แน่ใจว่าขนาดไหนเรียกว่าใหญ่ ขนาดไหนเรียกว่าเล็ก

ShijaemiS, on Dec 30 2006, 12:24 PM, said:

2 แต่ดูเหมือน XP เค้าไม่ได้ Require ในส่วนของ Tester ใช่ไหมค่ะเพราะดิฉันมองไม่เห็นช่วงจังหว่ะที่ Tester จะเข้าไปทำงานได้เลย เหมือนกับว่า Programmer จัดการเองหมดเลยคือ Code เองเทสเองและเทสไปพร้อมๆกับ User เลยแล้วถ้าทุกคนหันมาทำ xp หมด Tester ไม่ตกงานกันหมดเหรอเนียะ . ..(นี่มันคงเป็นผลจากกลุ่มผู้คิดค้น xp ใช่ไหมคะเนียะ.. )

extremeprogramming.org said:

Quality assurance (QA) is an essential part of the XP process. On some projects QA is done by a separate group, while on others QA will be an integrated into the development team itself. In either case XP requires development to have much closer relationship with QA.

สรุปว่าไม่ตกงานนะครับ

[ShijiemiS]

extremeprogramming.org]Quality assurance (QA) is an essential part of the XP process. On some projects QA is done by a separate group, on while on others QA will be an integrated into the development team itself. In either case XP requires development to have much closer relationship with QA.[/quote, said:

สรุปว่าไม่ตกงานนะครับ

เอ..ชักไม่แน่ใจแล้วค่ะ
เพราะว่าลักษณะการทำงานของ QA กับ Tester มันทำงานกันคนละอย่างเลยนะค่ะ
Quality assurance (QA) : ทำหน้าที่วัดและตรวจสอบกระบวนการผลิตซอร์ฟแวร์เพื่อนำผลที่ได้นั้นมาประเมินว่า Process นั้นมันดีแล้วเหมาะสมแล้วหรือยัง เพื่อพัฒนาให้ดีขึ้นต่อไป

Tester : ทำหน้าที่ในการค้นหา Bug ให้ได้มากที่สุดเท่าที่จะทำได้ และรายงานผลแก่คนที่เกี่ยวข้อพร้อมทั้ง ensure ได้ว่า Bug นั้นได้รับการแก้ไขแล้ว แต่ไม่ได้มีหน้าที่ในการแก้ไข Bug แต่อย่างใด

ดังนั้นโดยธรรมชาติของ xp ที่มันถูกคิดขึ้นมาโดยกลุ่มโปรแกรมเมอร์เอง ซึ่งในการทำงานจริงดูเหมือนไม่จำเป็นต้องมี Tester ก็ได้หรือป่าวอันนี้ไม่แน่ใจเพราะปกติเวลาที่โปรแกรมเมอร์เค้าทำการ ทดสอบระบบก็ทำไปพร้อมๆกับ user อยู่แล้วดังนั้นในความคิดของดิฉัน Tester ในกระบวนการของ xp อาจจะมีแต่ไม่ค่อยมีบทบาทเท่าที่ควรหรืออาจจะไม่จำเป็นด้วยซ้ำ..โดยเฉพาะในสภาวะเร่ง
ด่วน
เว้นแต่ว่าโปรแกรมเมอร์จะไม่ว่างทำ regression test เองเพราะโปรแกรมเมอร์แต่ละคนต้องทำ Unit test ในส่วนที่ตนเองรับผิดชอบอยู่ ซึ่งจังหวะนี้อาจเป็นจังหวะที่ Tester จะได้ทำหน้าที่ของตัวเองได้บ้าง แต่ว่ามันก็ยังไม่จำเป็นเพราะโปรแกรมเมอร์ก็ทำได้ในส่วนนี้
ซึ่งอันนี้มันก็เป็นแค่ความคิดเห็นส่วนตัว ไม่แน่ใจว่าเข้าใจถูกต้องหรือเปล่า ยังไงรบกวนท่านผู้รู้ช่วยแนะนำและช่วยกันหาคำตอบให้ด้วยนะค่ะ... (นำพาความฉงน มาสู่ทุกท่านอีกแล้วครับท่าน เห่อๆ..)

This post has been edited by ShijaemiS: 30 December 2006 - 09:09 PM

[teferi]

หาอยู่ตั้งนานแน่ะค่ะ ว่าที่พี่ Bomber quote มานั้น อยู่หน้าไหนในเว็บที่อ้างถึง ^^" ที่พยายามหา ก็เพราะอยากรู้ว่า คำจำกัดความของ QA ในเว็บนั้นเขาให้ไว้ว่าอย่างไร อาจจะไม่ได้หมายถึง ผู้ที่คอบควบคุมการทำงาน ให้เป็นไปตาม Process ก็ได้ ซึ่งคำจำกัดความนี้ เป็นคำจำกัดความ ของ CMMI

ปรากฏว่า หาไปหามา ไปเจอในหน้าที่เป็นเรื่อง Acceptance Test (http://www.extremepr...ionaltests.html) ลองอ่านดูแล้ว ก็รู้สึกว่า ในคำจำกัดความของเขา QA ก็คือ Tester ในความหมายของคุณ ShijaemiS นี่แหละค่ะ (สำหรับ CMMI นั้น การทำ Acceptance Test นั้น อยู่ใน Process Area ชื่อ "Validation" ซึ่งไม่เกี่ยวกับ QA ในความหมายของคุณ ShijaemiS)

ในความเห็นส่วนตัว คิดว่า ใน XP นั้น การ Test ด้วย Developer นั้น ก็ทำได้ในระดับหนึ่งเท่านั้น เช่นการทำ Unit Test สำหรับการ Test ในส่วนที่ครอลคลุมกว่านั้น ไม่ว่าจะเป็นการทำ Functional Test, Integration Test, System Test น่าจะยังเป็นบทบาทของ Tester อยู่ค่ะ

[ShijiemiS]

teferi, on Dec 30 2006, 09:16 PM, said:

หาอยู่ตั้งนานแน่ะค่ะ ว่าที่พี่ Bomber quote มานั้น อยู่หน้าไหนในเว็บที่อ้างถึง ^^" ที่พยายามหา ก็เพราะอยากรู้ว่า คำจำกัดความของ QA ในเว็บนั้นเขาให้ไว้ว่าอย่างไร อาจจะไม่ได้หมายถึง ผู้ที่คอบควบคุมการทำงาน ให้เป็นไปตาม Process ก็ได้ ซึ่งคำจำกัดความนี้ เป็นคำจำกัดความ ของ CMMI

ปรากฏว่า หาไปหามา ไปเจอในหน้าที่เป็นเรื่อง Acceptance Test (http://www.extremepr...ionaltests.html) ลองอ่านดูแล้ว ก็รู้สึกว่า ในคำจำกัดความของเขา QA ก็คือ Tester ในความหมายของคุณ ShijaemiS นี่แหละค่ะ (สำหรับ CMMI นั้น การทำ Acceptance Test นั้น อยู่ใน Process Area ชื่อ "Validation" ซึ่งไม่เกี่ยวกับ QA ในความหมายของคุณ ShijaemiS)

ในความเห็นส่วนตัว คิดว่า ใน XP นั้น การ Test ด้วย Developer นั้น ก็ทำได้ในระดับหนึ่งเท่านั้น เช่นการทำ Unit Test สำหรับการ Test ในส่วนที่ครอลคลุมกว่านั้น ไม่ว่าจะเป็นการทำ Functional Test, Integration Test, System Test น่าจะยังเป็นบทบาทของ Tester อยู่ค่ะ

อิอิ ขอบคุณมากค่ะคุณ teferi ที่ให้ความกระจ่าง ที่แท้ QA ในความหมายของคนทั่วๆไปก็คือ Tester นี่เองพอดีเคยได้ยินแต่คำจำกัดความตามที่ได้เขียนไว้ข้างต้นค่ะ เลยไม่แน่ใจและสับสนมานาน สรุปว่า XP จำเป็นต้องมี Tester ด้วยดังนั้นเราไม่ตกงานแล้วใช่ม๊า...

เอ แต่รู้สึกขัดๆกับข้อความนี้จังค่ะ

"(สำหรับ CMMI นั้น การทำ Acceptance Test นั้น อยู่ใน Process Area ชื่อ "Validation" ซึ่งไม่เกี่ยวกับ QA ในความหมายของคุณ ShijaemiS)"

เพราะถ้าอ้างอิงกับ CMMI ส่วนงานของ Test กับส่วนงานของ QA มันแยกกันค่อนข้างชัดเจนในเรื่องของหน้าที่รับผิดชอบดังนั้นมันไม่เกี่ยวกันจริงๆค่ะ
และก็ไม่น่าจะเทียบกันได้อยู่แล้วค่ะ ยิ่งถ้าพูดถึง Process Area ชื่อที่ชื่อ Validation มันอยู่ใต้การทำงานของ QA ด้วยซ้ำเพราะยังไงก็ต้องโดน Audit โดย QA ส่วน QA ที่ให้ความหมายไปเพราะไม่แน่ใจว่าเค้าหมายรวมถึงส่วนใหนกันแน่ค่ะ ยังไงก็ขอบคุณมากค่ะทีให้ความกระจ่าง

[teferi]

ShijaemiS, on Dec 30 2006, 10:12 PM, said:

เอ แต่รู้สึกขัดๆกับข้อความนี้จังค่ะ

"(สำหรับ CMMI นั้น การทำ Acceptance Test นั้น อยู่ใน Process Area ชื่อ "Validation" ซึ่งไม่เกี่ยวกับ QA ในความหมายของคุณ ShijaemiS)"

เพราะถ้าอ้างอิงกับ CMMI ส่วนงานของ Test กับส่วนงานของ QA มันแยกกันค่อนข้างชัดเจนในเรื่องของหน้าที่รับผิดชอบดังนั้นมันไม่เกี่ยวกันจริงๆค่ะ
และก็ไม่น่าจะเทียบกันได้อยู่แล้วค่ะ ยิ่งถ้าพูดถึง Process Area ชื่อที่ชื่อ Validation มันอยู่ใต้การทำงานของ QA ด้วยซ้ำเพราะยังไงก็ต้องโดน Audit โดย QA ส่วน QA ที่ให้ความหมายไปเพราะไม่แน่ใจว่าเค้าหมายรวมถึงส่วนใหนกันแน่ค่ะ ยังไงก็ขอบคุณมากค่ะทีให้ความกระจ่าง

ขออภัยค่ะที่เขียนไม่ค่อยชัดเจน ใน CMMI นั้น ทุก ๆ Process Area จะต้องถูกควบคุมโดย "Process and Product Quality Assurance" (PPQA) Process เหมือนกันหมดทุก Process (เนื่องจาก Generic Practice 2.9 ที่เป็น Common ของทุก ๆ Process Area นั้นพูดถึงเรื่องนี้ รวมถึง PPQA Process เองด้วยค่ะ)

ว่าแล้วที่เขียนไปข้างบนก็น่างงจริงด้วย

ที่เขียนไปอย่างนั้น ตั้งใจจะให้หมายความว่า ใน quote ของพี่ Bomber นั้น QA ของเขา ไม่เหมือน QA ของ CMMI น่ะค่ะ ^^"

This post has been edited by teferi: 30 December 2006 - 10:24 PM

[ShijiemiS]

teferi, on Dec 30 2006, 10:19 PM, said:

ShijaemiS, on Dec 30 2006, 10:12 PM, said:

เอ แต่รู้สึกขัดๆกับข้อความนี้จังค่ะ

"(สำหรับ CMMI นั้น การทำ Acceptance Test นั้น อยู่ใน Process Area ชื่อ "Validation" ซึ่งไม่เกี่ยวกับ QA ในความหมายของคุณ ShijaemiS)"

เพราะถ้าอ้างอิงกับ CMMI ส่วนงานของ Test กับส่วนงานของ QA มันแยกกันค่อนข้างชัดเจนในเรื่องของหน้าที่รับผิดชอบดังนั้นมันไม่เกี่ยวกันจริงๆค่ะ
และก็ไม่น่าจะเทียบกันได้อยู่แล้วค่ะ ยิ่งถ้าพูดถึง Process Area ชื่อที่ชื่อ Validation มันอยู่ใต้การทำงานของ QA ด้วยซ้ำเพราะยังไงก็ต้องโดน Audit โดย QA ส่วน QA ที่ให้ความหมายไปเพราะไม่แน่ใจว่าเค้าหมายรวมถึงส่วนใหนกันแน่ค่ะ ยังไงก็ขอบคุณมากค่ะทีให้ความกระจ่าง

ขออภัยค่ะที่เขียนไม่ค่อยชัดเจน ใน CMMI นั้น ทุก ๆ Process Area จะต้องถูกควบคุมโดย "Process and Product Quality Assurance" (PPQA) Process เหมือนกันหมดทุก Process (เนื่องจาก Generic Practice 2.9 ที่เป็น Common ของทุก ๆ Process นั้นพูดถึงเรื่องนี้ รวมถึง PPQA Process เองด้วยค่ะ)

ว่าแล้วที่เขียนไปข้างบนก็น่างงจริงด้วย

ที่เขียนไปอย่างนั้น ตั้งใจจะให้หมายความว่า ใน quote ของพี่ Bomber นั้น QA ของเขา ไม่เหมือน QA ของ CMMI น่ะค่ะ ^^"

ว่าแล้วเชียวแปลกๆ...เอาเป็นว่าเราเข้าใจตรงกันแล้วนะค่ะ คริๆขอบคุณมากๆค่ะวันหลังมาแชร์ความรุ้กันอีกนะค่ะสนุกดีค่ะ อิอิ