สวัสดีครับ รับปากคุณ Zyracuse ไว้ตั้งแต่วันงานแล้วว่าจะเขียนเล่าสรุป งาน software testing ของ Thailand Spin เมื่อวันที่ 14 ต.ค. ในหัวข้อ Defining Your Test Strategy แต่ติด priority ด่วนจริงๆของ software release เลยเพิ่งจะมาเขียนได้คืนนี้ ยังไงก็ไปดูกันเลยครับ

Concept โดยรวมของงานนี้ที่ทาง working group วางกันไว้ก็คืออยากจะคุยกันถึงภาพรวมว่า test strategy คืออะไร มีประโยชน์อย่างไร และเวลาทำtest strategy จะต้องคำนึงถึงอะไรบ้าง ก่อนที่จะมีงานครั้งต่อๆไปตามมาโดยเจาะหัวข้อการทำ test เจาะจงในเชิงลึก เช่น performance testing, UAT เป็นต้น …

พอคุยกันได้ซักพัก ก็เห็นตรงกันว่า test strategy แต่ละที่ ก็อาจจะมีความแตกต่างกันที่เกิดขึ้นจากหลายปัจจัยได้ โดยเฉพาะหาก business model หรือ application nature มีความแตกต่างกัน ทางเราก็คิดว่าน่าจะเชิญคนมาร่วมเสวนาที่สามารถ share แง่มุมได้หลากหลาย ก็เลยเป็นที่มาของ buffet ความรู้ Testing (แบบไม่จำกัดความรู้ แต่จำกัดที่เวลา ^-^ ) ที่เราได้รับเกียรติจากผู้มีประสบการณ์ 4 ท่าน ซึ่งมาจาก KBank (testing software developed by other organization), Avalant (Project based solution provider), Wealth Management (Product based), และ Sanook (Services based) ซึ่งทั้ง 4 ท่านก็ได้มาเล่าเรื่องแลกเปลี่ยนความคิดเห็นกันอย่างเข้มข้น และมีคำถามจากผู้เข้าร่วมงานเข้ามาอย่างต่อเนื่องเลยทีเดียวครับ

สำหรับคนที่พลาดงานนี้ไป ผมเขียนสรุปไว้คร่าวๆให้ ดังนี้ครับ …………

ตอนเริ่มงานก็มีการกล่าวถึงคำนิยามกลางๆที่จะใช้ร่วมกันสำหรับงานครั้งนี้ว่า

Test Strategy : เอกสารที่เล่าถึงการทำactivityที่เกี่ยวข้องกับ testing อย่างมีประสิทธิภาพเพื่อที่จะนำพาให้เราสามารถบรรลุเป้าหมายที่จะได้มาซึ่ง software ที่มีคุณภาพนั่นเอง

Test Strategy ต่างกับ Test plan อย่างไร? ตัว Test Strategy เองส่วนใหญ่จะพูดในapproach ภาพกว้างและ generic ซึ่งจะไม่เจาะจงรายละเอียดลงไปให้ specific กับ technology, product, people … ส่วนตัว test plan นั้นจะลงไปในระดับ operation ว่าสิ่งที่ต้องทำมีอะไรบ้าง scope ของงาน, ใคร (ลงไปถึงระดับรายชื่อคน) จะต้องทำอะไร ให้เสร็จภายในเมื่อไหร่ แล้วก็มีอะไรที่เราplanที่อาจจะทำต่างจากตัว Test strategy กลางไป และเพราะอะไร

หลายๆคนอาจจะยังสับสนระหว่าง test strategy กับ test plan ได้ ในวันงานเรามีเวลาค่อนข้างจำกัด เราเลยไม่ไดุ้คุยกันเรื่องนี้ละเอียด ผมเลยอยากจะขอใช้โอกาสนี้ยกตัวอย่างให้เห็นภาพขึ้น

Test Strategy อาจจะระบุไปว่า cycle ของการทำ test มีอะไรบ้าง, role ไหนในองค์กรณ์เป็นคนรับผิดชอบแต่ละ cycle, expected output ของแต่ละ cycle คืออะไร และเราจะทำยังไงให้แต่ละ cycle เราได้สิ่งที่ดีที่สุดสำหรับ quality สุดท้ายของ software ที่ balance กับ effort ที่เสียไป, entry และ exit criteria แบบกลางๆเป็นต้น การที่ระบุว่า tester ควรจะต้องมีส่วนร่วมใน life cycle ตั้งแต่ต้นๆ เช่นการ review design และ ควรจะ estimate effort ในการทำ test อย่างไร เมื่อถึงเวลาอันเหมาะสมใน life cycle ก็ถือว่าเป็นส่วนนึงที่จะ document ไว้ใน test strategy ได้ และอาจมีการพูดถึง guideline เวลาทำ defect management …  ส่วน Test Plan เองจะระบุชัดเจนไปเลยว่า scope ของงานมี module ไหนบ้าง แต่ละ module ใครรับผิดชอบอะไร ต้องเสร็จเมื่อไหร่ เมื่อเกิดคำถามหรือประเด็นในหัวข้อไหนควรจะต้องติดต่อใคร และหาก application นั้นๆมีลักษณะเด่นเฉพาะตัวเช่นมีการคำนวณตัวเลขที่สำคัญล้วนๆ ก็อาจจะมีการตั้งguideline ในการให้ priority ของ bug ไว้เพื่อที่จะทำให้ทุกคนเข้าใจตรงกันว่าคำนวณผิดตรงไหนแบบไหนจะให้ priority อย่างไรและสามารถที่จะจัดลำดับความสำัคัญในการ fix bug ได้อย่างเหมาะสม สุดท้ายนี้ใน test plan อาจจะมีการกำหนด acceptance criteria ว่า software จะ release ได้ก็ต่อเมื่ออะไรทำงานได้ถูกต้องมากน้อยแค่ไหน รวมถึง non functional aspect ด้วยก็เป็นได้ครับ

หลังจากเท้าความไปนาน เรามาดูสรุปผลของ panel discussion ทั้ง4 ท่านกันเลยดีกว่าครับ

Part 1 : Conceptualize

ประโยชน์ของ Test Strategy ?

1. ทำให้การทำ test เป็นไปอย่างมีระบบแบบแผนและมีประสิทธิภาพ

2. เป็นการคิดกลยุทธ์ในเชิงรุกไปถึง defect prevention ไม่ใช่แค่ detection

3. เืืพื่อให้ทุกstakeholder เข้าใจบทบาทของตัวเองและstrategyเป็นแนวทางใช้ร่วมกันให้เพื่อบรรลุเป้าหมายของ quality

4. เป็นเครื่องมือในการสื่อสาร ลดปัญหาความสับสนและเข้าใจผิดในการสื่อสารได้ (ทุกฝ่ายจะรู้ความรับผิดชอบของตน และเข้าใจภาษาเดียวกัน (เช่นพวกตัวย่อต่างๆเป็นต้น)

ปัจจัยอะไรบ้างที่ทำให้ test strategyต่างกันออกไปได้?

1. Business model (เช่น product based, service based, acquirer, etc)

2. Nature of software (web based, desktop based, SOA, mission critical software, trend of technology, etc.)

3. Organization/Team structure (dedicated test team or pair testing, etc.)

4. Organization direction/Policy/Culture

(อันนี้ขอเพิ่มเติมนอกรอบ development methodology ก็ส่งผลได้ครับ เช่นหากที่ไหนใช้ agile development รูปแบบการทำ testing ก็จะต้องสอดคล้องกันไปครับ)

Possible scope/scale of test strategy?

ส่วนใหญ่จะวางในระดับองค์กรณ์ บางที่ก็จะมีแยกเจาะจงลงไปสำหรับ type of testing เช่น performance test strategy, automated regression test strategy และสำหรับบาง business model การทำ test strategy ระดับ project based ก็อาจจะตอบโจทย์ได้ดีที่สุด

ตัวอย่างของส่วนประกอบใน Test Strategy document

1. Testing cycle and responsibiilty of each cycle (as well as entry and exit criteria)

2. Defect management guideline

3. Test improvement based on experience/historical data

4. Approach to ensure good coverage

5. การเลือกใช้ test data และ test environment ในแต่ละ test cycle

6. Checkpoint to keep track of test progress and software quality

7. Defect prevention strategy

(ยังมีอื่นๆอีกมากมาย) …

Part 2 : Getting started

หลังจากมี test strategy แล้วเห็นความแตกต่างยังไงบ้าง?

การทำงานมีระบบมากขึ้น แต่ละคนเข้าใจบทบาทกับ expectation ของตัวเองดี และเห็นภาพรวมว่าจะต่อยอดไปสู่เป้าหมายเดียวกันอย่างไร ส่งผลให้ความมั่นใจในคุณภาพดีขึ้น และปัญหาการสื่อสารในองค์กรณ์ลดลง

หากจะเริ่มต้นทำ test strategy ควรต้องคำนึงถึงอะไรบ้าง?

1. ควรคำนึงถึงว่ามีใครที่มีส่วนเกี่ยวข้องในการทำ test บ้าง, get input จากคนเหล่านั้น และ agreement จากคนเหล่านั้น

2. ควรคำนึงถึงว่า business model และ software nature ของตนเองเป็นอย่างไร และพยายามออกแบบ test strategy ให้ตอบโจทย์หรือ challenge หลายๆอย่างในมุมนั้นๆให้มากที่สุด

3. เมื่อมี test strategy แล้วอย่าวางไว้บนหิ้ง เอามาใช้, review และ update เป็นครั้งคราว สื่อสารให้คนรู้จัก aware ให้ทั่วถึง assignความรับผิดชอบหลักให้กับกลุ่มคนกลุ่มนึง (เช่น test manager) เพื่อที่จะ promote และนำ strategy ไป implement และปรับใช้ตามเหมาะสม

เกร็ดเล็กเกร็ดน้อย …

1. กลยุทธ์ไม่มีถูกหรือผิด พยายามหาว่าอะไรที่ตอบโจทย์คุณมากที่สุดและค่อยๆเรียนรู้ไป

2. กลยุทธ์ไม่ควรหยุดอยู่นิ่ง ควรจะต้องมีการปรับเปลี่ยนให้สอดคล้องกับปัจจัยภายนอกที่เปลี่ยนไปเป็นครั้งคราว

3. แต่ละองค์กรณ์อาจมีการใช้คำศัพท์ที่เรียก test strategyแตกต่างกันไป (อาจะเรียก test practice, test handbook, test methodology, หรืออื่นๆ) ไม่จำเป็นต้องยึดติดกับชื่อมาก ตราบใดที่ทุกคนเข้าใจจุดประสงค์ของมันและเอาไปใช้อย่างเหมาะสม

4. Test strategy เมื่อได้นำมาใช้สื่อสารกับstakeholderอย่างเหมาะสมและถูกเวลา จะเป็นเครื่องมือที่ช่วย manage expectation ของ stakeholder ได้และอาจช่วยทำให้ทีม test ของเรามีำenvironmentหรือสภาวะในการทำงานที่ดีขึั้นได้ครับ

………………………………

… ขอขอบคุณ …

Panelists ทั้ง4 ท่าน : คุณ Prom จาก KBank, คุณ Piyamed จาก Avalant, คุณ Wimonrat จาก Wealth และที่ขาดไม่ได้ คุณประธาน (คุณ Zyracuse แห่ง welovebug ของเรานั่นเอง) จาก Sanook สำหรับ ข้อมูล testing buffet 4 รส 4 style ครั้งนี้

Co-moderator มือ pro : พี่ Pook Jarunee จาก Reuters

Software Testing Working Group ทุกท่าน คุณต่อ คุณนล อาจารย์หนู อ๋อง คุณหนุ่ม … ที่ช่วยกันออกแบบงานนี้ให้ออกมาดี

Software Park คุณจิ๋ว คุณอ้อม สำหรับการประสานงานมืออาชีพอย่างต่อเนื่อง

Microsoft และมหาวิทยาลัยรังสิต ที่เอื้อเฟื้อสถานที่่

HP ที่สนับสนุน หน้งสือดีๆเป็นรางวัลสำหรับผู้เข้าร่วมงาน

และสำคัญที่สุดผู้เข้าร่วมงานทุำกท่าน สำหรับเวลา feedback และคำถามที่ผลัดกันเข้ามาอย่างต่อเนื่อง

Link to official site of the event and full names of the panelists/moderators below ….

http://www.thailandspin.com/ThailandSPINCalendar/tabid/63/articleType/ArticleView/articleId/32/Default.aspx