วางถุงกาวลงแป๊ป ก่อนจะไป Automate Testing กัน

automate-testing-post-on-facebook

สวัสดีเช้าวันจันทร์ที่ 21 มีนาคม พ.ศ. 2559 เช้าวันนี้มาพล่ามเรื่อง Automate Testing ที่ผมพล่ามขึ้นบน Facebook ส่วนตัวเมื่อวันพฤหัสบดีที่ 17 มีนาคม พ.ศ. 2559 เพราะอะไรถึงต้องพล่ามแบบนั้น เหตุผลก็คือ หลายๆ บริษัทเริ่มมองหา ตั้งงบ หรือจัดซื้อ Automate Testing Tool มา และก็อยู่ในการครอบครองของทีม Software Tester กลายเป็นว่า เอ้า…Automate Testing เป็น งาน และความรับผิดชอบของ Software Tester!!! ซึ่งสำหรับผมส่วนตัวแล้วไม่ใช่แบบนั้นนะ ก็เลยมาพล่ามไปบน Facebook แล้วก็ขอมาขยายความต่อบน Blog ในเช้าวันนี้

คำออกตัวแบบล้อฟรี

สิ่งที่จะได้เสพหลังจากอยู่บนพื้นฐานของ ทฤษฎีต่างๆ เท่าที่ผมเสพมาทั้งจกการอ่าน ฟัง และเรียน ผสมกับประสบการณ์ที่เจอมา และความคิดเห็นส่วนตัวนะจ๊ะ

ก่อนอื่นเลยที่จะไปสู่ Automate Testing นั้น เราควรจะวางถุงกาวลง แล้วเรียกสติมาก่อน กลับมา ณ จุดเริ่มต้นก่อนว่า คำว่าคุณภาพของซอฟต์แวร์นั้นคืออะไร ผมแนะนำให้ไปเสพ Blog นี้ของ Microsoft

หลายๆ คนใช้คำว่า คุณภาพ แทนความหมายของ การทดสอบ (Testing) ซึ่งจริงๆ แล้วไม่ใช่ นั่นคือเหตุผลว่าทำไมผมถึงพล่าม

1. Software Quality และ Software Testing คืออะไร?

การทดสอบซอฟต์แวร์นั้น (Software Testing) เป็นเพียงแค่ติ่งหนึ่งของการควบคุมคุณภาพของซอฟต์แวร์ และกระทำการได้เพียงอย่างเดียวคือ ลงมือทดสอบ ไม่ว่าจะ แรงคน (Manual Testing) หรือแรงเครื่อง (Automate Testing) และต้องดำเนินการกับ ซอฟต์แวร์ ที่ถูกพัฒนาออกมาแล้วเท่านั้น ซึ่งหากระหว่างการเดินทางจาก ความต้องการเชิงธุรกิจ (Business Requirement) มาเป็น ความต้องการของซอฟต์แวร์ (Software Requirement Specification) ยาวมาเรื่อยๆ จนมาเป็น ซอร์สโค้ด (Source Code) นั้น รายละเอียด และความครบถ้วนของเนื้อหาไม่ดีพอที่จะนำมาใช้ในการวิเคระาห์ ออกแบบ และพัฒนา ทำใจได้เลยว่า คุณภาพของซอฟต์แวร์ก็แย่แน่นอน 

ดังนั้น กลับไป ณ จุดเริ่มต้น ลงไปดูว่า คุณภาพซอฟต์แวร์ (Software Quality) และการทดสอบซอฟต์แวร์ (Software Testing) คืออะไร? และคำเตือนอย่าไปลอกของคนอื่นๆ มาให้กลับมานั่งสุมหัว (Brainstrom) คิด และหาข้อตกลงร่วมว่า บริษัทเรา องค์กรเรา และลูกค้า คำว่า คุณภาพ หน้าตาอย่างไร เพื่อให้ทุกคนเห็นภาพตรงกัน จะได้ไม่ต้องมาตบตี จิกกัดกัน แล้วยกคำว่า คุณภาพ ขึ้นมาพูดลอยๆ หล่อๆ แต่อธิบายกันไม่ได้ว่า หน้าตาของคุณภาพเป็นเช่นไร

2. ประเภทและระดับของการทดสอบมีอะไรบ้าง?
3. ใครที่ต้องมีส่วนร่วมรับผิดชอบในเรื่องคุณภาพ การดูแลและทดสอบซอฟต์แวร์

การทดสอบซอฟต์แวร์นั้นผมขอแบ่งออกเป็น 2 ส่วนคือ

  • Functional Testing
  • Non-Functional Testing

ทั้งสองส่วนนี้ทีมีก็มาจาก ความต้องการของฝั่งธุรกิจ ส่วนใหญ่จะจัดเก็บมาเฉพาะ Functional Requirements เท่านั้น และจะละเลยเรื่อง Non-Functional Requirements ถ้าเรายังไม่เคยบาดเจ็บมาก่อนจากเรื่องของพวก Security เอย Performance เอย และอื่นๆ ในอดีตที่ผ่านมา ซึ่งหาเสพเรื่องประเภท (Testing Type) และระดับของการทดสอบ (Testing Level) ได้ ซึ่งผมขอสรุปเบื้องต้นว่าด้วยรูปนี้

Agile-Testing-Quadrants

ภาพนี้ถูกใช้ใน Agile Testing แต่สำหรับผมแล้ว SDLC แบบอื่นๆ ก็ใช้รูปนี้ได้ด้วยเช่นกันในส่วนของการทดสอบ (Testing)

Quadrant  ที่ 1

ในส่วนนี้ก็คือการทดสอบในกลุ่มของ Functional Testing ส่วน Unit Tests และ Component Tests รวม Integration Testing เข้าไปด้วย ผมขอเรียกว่า Development Test (Development Test คือ การทดสอบส่วนที่ทีมพัฒนาจะต้องร่วมกันรับผิดชอบดูแล) โดยในส่วนนี้ขอยก Unit Testing ว่า

ถ้า Programming Language ที่ใช้พัฒนาซอฟต์แวร์ให้ลูกค้า เป็น Java แล้วนั้น Unit Testing ก็เป็นหน้าตาเป็นภาษา Java เช่นเดียวกัน ซึ่งมันเป็น Automate Testing อยู่แล้ว

เป็นหน้าที่ของ Programmer และ/หรือ Developer

เสพเรื่องนี้เพิ่มเติมได้ที่เว็บ Somkiat.cc link นี้ Unit Testing

Quadrant  ที่ 2

ในส่วนนี้ก็เป็นการทดสอบในกลุ่มของ Functional Testing ส่วนของ System Testing รวม Acceptance Testing ด้วย ผมยังจัดอยู่ในระดับของ Development Test อยู่เช่นกัน ทำได้ทั้ง Automate Testing และ Manual Testing

เป็นหน้าที่ของ ทุกๆ คนที่อยู่ในทีมพัฒนา และส่งมอบซอฟต์แวร์ให้ลูกค้า

Quadrant  ที่ 3

ในส่วนนี้ก็ยังคงเป็นการทดสอบในกลุ่มของ Functional Testing อยู่เช่นกันซึ่งครอบคุลมในการทดสอบแบบ Acceptence Testing เต็มๆ รวมไปถึง Exploratory Testing ด้วยเช่นกัน ผมจัดไว้ในส่วนของ Customer Test ซึ่งดำเนินการด้วย Manual Testing

เป็นหน้าที่ของลูกค้า หรือตัวแทนลูกค้า ที่จะต้องดำเนินการทดสอบเพื่อตรวจรับ ซึ่งเรานิยมเรียกขานว่า User Acceptance Testing

Quadrant  ที่ 4

ในส่วนนี้เป็นบริเวณของ Non-Functional Testing ต่างๆ ซึ่งต้องอาศัยผู้เชี่ยวชาญเฉพาะทาง ยกตัวอย่างเช่น Security Testing หรือ Performance Testing หรือ Capacity Testing เป็นต้น ในบริเวรนี้ต้องใช้เครื่องไม้เครื่องมือเข้ามาช่วยในการดำเนินการทดสอบ เก็บรวบรวมผล รวมทั้งวิเคราะห์

ดังนั้นหน้าที่ความรับผิดชอบของการควบคุมดูแลคุณภาพและทดสอบซอฟต์แวร์มิใช่งานของ Software Tester เท่านั้น พูดปรโยคนี้ทีไรหลายๆ คนที่เจอมาก็จะบอกว่าเข้าใจ เข้าใจ เข้าใจ แต่ไม่เห็นว่าจะกระทำการใดๆ ตามที่บอกว่าเข้าใจเลย

4. ทำไมต้อง Automate Testing ต้องลงทุนอะไรบ้างในการสร้าง และการดูแลรักษา
5. Automate Testing ไม่ใช่เรื่องของ Software Tester

Automate Testing ที่กำลังตามหา และพยายามจะทำกันมันมิใช่หน้าที่ความรับผิดชอบของแค่ Software Tester เท่านั้นนะจ๊ะ ส่วนตัวผมไม่เห็นด้วยกับการตั้งทีม Automate Testing ขึ้นมาเพราะก็จะกลายเป็นคอขวดในไม่ช้า เพราะคนจะแห่กันมาให้ทำ Automate Testing

Automate Testing ต้องกลับมาคิดตั้งแต่จุดเริ่มต้นเสียก่อนพร้อมกับวางถุงกาวลง หยุดดึงดาว แล้วคิดทบทวนเรื่องเหล่านี้

  • ทำไมเราถึงต้องนำ Automate Testing มาใช้?
  • Automate Testing ที่นำมาใช้จะเป็นภาระอีกหรือไม่ในอนาคตในการดูแลรักษา?
  • Automate Testing ==> การเขียน Code เช่นเดียวกับการพัฒนาซอฟต์แวร์
  • หันกลับไปมองในทีม Software Tester ว่า มีกี่คนที่ยังสนุกกับการเขียน Coding หากจะมอบหมายให้มาดูแลในการสร้าง Automate Testing Script
  • ต้องเก็บ Source Code ของ Automate Testing ไว้บน Source Code Management ด้วยไม่ว่าจะเป็น SVN หรือ Git หรืออื่นๆ ที่ใช้งานกันอยู่
  • สร้าง Automate Testing Script ขึ้นมาแล้วนั้น มันจะสามารถนำกลับมาใช้ได้บ่อยแค่ไหนกับการลงทุนทำ Script แต่ละตัวไป เช่น ใช้ครั้งเดียวทิ้ง หรือเมื่อไรเปลี่ยนหน้าเว็บ หรือหน้าจอ Mobile Application ใหม่ Script เดิมก็ใช้ไม่ได้ มันคุ้มทุนหรือเปล่า?
  • Automate Testing มีได้กี่ระดับของการทดสอบ ให้กลับไปดู Agile Testing Quadrant อีกรอบ
  • ถ้าจะเริ่มทำ Automate Testing ในระดับของ Unit Testing จะต้องทำอะไรกับ Programmer และ/หรือ Developer บ้าง ต้องสอน ต้องฝึก ต้องประกบ ต้องช่วย และต้องอะไรอื่นๆ อีก

เบื้องต้นตามด้านบน ส่วนตัวผมถือว่าทั้งหมดนี้อยู่ในความรับผิดชอบของ Test Manager หากมีเขาอยู่ในบริษัท หรือ IT Development Manager หากมีเขาอยู่ในบริษัท หรือ CIO/CTO หากมีเขาอยู่ในบริษัท ที่จะต้องลงรายละเอียด ทำความเข้าใจ และกำหนดสิ่งที่เรียกว่า แผนกลยุทธ์ ออกมา รวมทั้งวิเคราะห์เรื่อง ความคุ้มทุน (ROI) ที่จะได้กลับมาด้วย เพราะ Autoamte Testing คือ การลงทุน ทั้ง บุคลากร เวลา เครื่องมือ และโครงสร้างพื้นฐานทาง Architecture ด้วย

ดังนั้น Automate Testing มิใช่เพียงแค่ตั้งตุ๊กตาขึ้นมา แล้วส่งให้ทีม Software Testing นะจ๊ะ

Screen-Shot-2015-06-09-at-11.51.06-AM
ภาพตัวอย่างการของการวางกลยุทธ์ สำหรับ Automate Testing

6. Software Tester ไม่ได้มีหน้าที่รับผิดชอบ ข้อ 1 ถึง ข้อ 5 มีไม่มี Software Tester ข้อ 1 ถึง ข้อ 5 ยังต้องคงมีอยู่

ผมทำงานสายควบคุมดูแลคุณภาพ และทดสอบซอฟต์แวร์ มาตั้งแต่เริ่มเป็น Software Tester และพูดได้เต็มปาก บวกตะโกนขึ้นฟ้าเลยว่า งานทดสอบซอฟต์แวร์ (Software Testing) ไม่ใช่หน้าที่เฉพาะของ Software Tester!!!

ทำไม Programmer หรือ Developer ถึงทดสอบซอฟต์แวร์ไม่ได้ ส่วนใหญ่จะเจอคำตอบว่า

“Tester มีมุมมองที่หลากหลายกว่า เราทพดสอบซอฟต์แวร์ที่เราเขียนเองยังไงก็ไม่เจอ Bug”

ผมยกตัวเองเป็นตัวอย่าง ปัจจุบันผมก็ยังมีร่างทรงเป็น Software Tester

  1. ผมจบวิศวกรรมซอฟต์แวร์ ผมเรียนเขียนโปรแกรมมา ผมเรียนออกแบบโครงสร้างฐานข้อมูลมา ผมเรียน Computer Network มา ผมเรียน Data Structure มา ต่างอะไรกับ Programmer หรือ Developent ที่จบวิศวกรรมซอฟต์แวร์ หรือวิทยาการคอมพิวเตอร์ หรือสาขาอื่นๆ ที่เกี่ยวข้องกับคอมพิวเตอร์?
  2. ผมเริ่มงานแรกเป็น Freelance Programmer (คำภาษาไทยคือ รับจ้างเขียนโค้ดทั่วไป) ก็เขียนโค้ดเอง ทดสอบเอง และทดสอบได้กากมาก
  3. ผมเปลี่ยนงานมาเป็น Software Tester ผมก็ยังใช้การทดสอบแบบสมัยที่ผมรับจ้างเขียนโค้ดทั่วไป
  4. ผมเริ่มศึกษาเพิ่มเติมว่างาน Software Testing มันคืออะไร? ย้อนหลังไปเมื่อ 10 ปีที่แล้วไม่มีศาสตร์ความรู้เรื่องนี้ฉบับภาษาไทย ก็ต้องไปควานหาจากบน Internet เอามาปรับประยุกต์ใช้
  5. ผมสวมหมวกหลายใบเวลาที่ร่วมฟังความต้องการที่ลูกค้าอยากจะให้ทีมไอทีพัฒนา ทั้งหมวกลูกค้าเอง ทั้งหมวกทีมพัฒนาเอง ทั้งหมวกคนที่ต้องดูแลเรื่องคุณภาพ แล้วก็

คิด ออกแบบ วิเคราะห์ ถามคำถามเมื่อไม่เข้าใจ ไม่มโน ไม่คิดเออออ ไม่คาดการ ทุกอย่างต้องชัดเจน เห็นภาพตรงกัน

เฮ้ย ผมเก่งมาตั้งแต่เกิดเลยหรือเปล่าถึงทำไอ้ที่พูดข้างบนนี้ได้ ไม่ล้มเหลว ผิดพลาดมาเยอะ พร้อมกับหยุดคิดเพื่อไม่ให้เกิดขึ้นอีก หรือเกิดน้อยที่สุด

ดังนั้น ส่วนตัวผม Programmer/Developer หรือ Software Tester เองนั้น มิต่างกัน มันแค่คุณตีกรอบตัวเองด้วยงานที่ทำ เงินเดือนที่ได้ คนอื่นอุปโลกน์คุณขึ้นมาเองทั้งนั้น

คำถามสำหรับ Programmer หรือ Developer

ณ วันหนึ่งเราลาออกจากงานเดิม ฉันเป็น Programmer ไปสมัครงานที่ไหนก็ไม่มีใครรับ แถมไม่มีเงินจะกินข้าว มีแค่ตำแหน่งงาน Software Tester เปิดรับอยู่ สมัครปุ๊ป รับปั๊ป ทำงาน 30 วันได้เงินกินข้าวเลย

จะไปสมัครเป็น Software Tester ไหม? หรือจะอดอยากรองาน Programmer?

คำถามสำหรับ Software Tester

ณ วันหนึ่งเราลาออกจากงานเดิม ฉันเป็น Software Tester ไปสมัครงานที่ไหนก็ไม่มีใครรับ แถมไม่มีเงินจะกินข้าว มีแค่ตำแหน่งงาน Programmer เปิดรับอยู่ สมัครปุ๊ป รับปั๊ป ทำงาน 30 วันได้เงินกินข้าวเลย

จะไปสมัครเป็น Programmer ไหม? หรือจะอดอยากรองาน Software Tester?

จริงๆ แล้วที่เราแยกส่วนงานนี้ใครรับผิดชอบ หน้าที่ฉัน หน้าที่แก ฉันเลยไม่เอามือไปแตะตรงนั้น เพราะไม่ใช่หน้าที่ฉัน ถ้าไปแตะแล้วนายมาเจอว่าทำงานเกินหน้าที่จะหักเงินเดือน หรือ เพราะ Mindset เราเอง นายเอง เพื่อนเอง ทั้งนั้นที่ตีกรอบหน้าที่ความรับผิดชอบ แล้วก็ทำๆ ต่อกันมาว่างาน Testing เป็นหน้าที่ของ Software Tester เท่านั้น

7. เปลี่ยนการทำงานของ Software Tester จากนั่งเอาตะแกรงตักขี้ออกจากสายน้ำ มาเป็นป้องกันอย่างไรไม่ให้ท้องเสียขี้แตกเลอะเทอะเรี่ยราด
8. มี Software Tester ไม่ได้ช่วยให้งานดีมีคุณภาพนะ

สมัยที่ยังดำรงตำแหน่งเป็น มนุษย์เงินเดือน ก็ได้มีโอกาสสัมภาษณ์เพื่อรับคนเข้ามาทำงานในหน้าที่ Software Tester เชื่อไหมว่าคำตอบที่ได้จากคำถามที่ถามว่า

“ทำไมมาสมัครเป็น Software Tester?”

“จบคอมมา ไม่ชอบเขียน Code เลยหางานที่ไม่ต้องเขียน Code”

ผมไม่ได้สัมภาษณ์แค่คนสองคน ผ่านมาไม่ต่ำกว่าสามสี่สิบคน และก็ได้พบเจอผู้คนอื่นๆ เลยทำให้กล้าพูดเลยว่า

อย่าฝากผีฝากไข้เรื่องคุณภาพไว้ที่ Software Tester เลย

และทำความเข้าใจใหม่ว่าการมี Software Tester อยู่นั้นไม่ได้ช่วยทำให้งานมันมีคุณภาพขึ้นเลย หากยังทำงานเช่นเดิม ยกตัวอย่างเช่น

  • เอาเอกสารความต้องการ และเอกสารอื่นๆ มานั่งเขียน Test Cases เงียบๆ อยู่คนเดียว
  • เขียน Test Cases ไปเรื่อยๆ ทั้งๆ ที่ไม่รู้ด้วยว่าจะมีจำนวนเท่าไร แล้วจะทดสอบได้หมดไหม
  • เตรียม Test Data ไปเอง
  • เดินไปหา Programmer หรือ Developer ก็มีแต่ข่าวร้ายไปบอกเขา ซ้ำร้ายอัญเชิญวิญญาณ มนุษย์ป้า ลงมาเข้าร่างอีก เลยแย่ไปกันใหญ่
  • Test Cases และ Test Data ก็ไม่เคยส่งให้ใครดู หรือเคยส่งให้ดูก็ไม่ตามผลว่าทุกคนเห็นด้วยหรือไม่เห็นด้วย
  • นั่งทดสอบไปเรื่อยๆ ทั้งๆ ที่รู้ว่ามีปัญหาตลอด ทดสอบไปก็เจอ Bug จิ้มตรงไหนก็พัง
  • นั่งก้มหน้าก้มตาเขียน Bug Report ลงไปวันวัน เพราะพิธีกรรมความเชื่อที่กระทำตามๆ กันมาเขาว่าไว้แบบนั้น
  • แล้วก็ไปจบที่ทะเลาะตบตีกันกับ Programmer หรือ Developer ว่านี่ Bug หรือไม่ Bug

ถ้า Software Tester ยังทำงานอะไรแบบนี้ ก็มิต่างจาก

Software Tester จากนั่งเอาตะแกรงตักขี้ออกจากสายน้ำ

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

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

เบื้องต้นตามด้านบน ส่วนตัวผมถือว่าทั้งหมดนี้อยู่ในความรับผิดชอบของ Test Manager หากมีเขาอยู่ในบริษัท หรือ IT Development Manager หากมีเขาอยู่ในบริษัท หรือ CIO/CTO หากมีเขาอยู่ในบริษัท ที่จะต้องลงรายละเอียด ทำความเข้าใจ และกำหนดสิ่งที่เรียกว่า แผนกลยุทธ์ ออกมา รวมทั้งวิเคราะห์เรื่อง ความคุ้มทุน (ROI) ที่จะได้กลับมาด้วย เพราะ Autoamte Testing คือ การลงทุน ทั้ง บุคลากร เวลา เครื่องมือ และโครงสร้างพื้นฐานทาง Architecture ด้วย

ซึ่งให้ไปเสพ พร้อมกับศึกษาเพิ่มเติมเรื่อง Test First Development โดยเฉพาะอย่างยิ่ง Programmer และ Developer นะ ไปเสพที่นี่เพื่อเริ่มต้นเดินทาง

http://www.extremeprogramming.org/rules/testfirst.html

และไปตามต่อที่ www.SOMKIAT.cc

สรุป

Automate Testing มันดีจริงๆ แต่อย่ามาคิดจะมีมัน แล้วลงทุนไปเยอะๆ ซื้อ Tools มา ซื้อ License มาแล้วก็นั่งมองหน้ากันว่ามันจะใช้อย่างไร วางถุงกาวลงแล้วคิดสักนิดว่า

  1. ทำไมเราถึงต้องมี Automate Testing เกิดขึ้น
  2. ใครต้องทำอะไรบ้างเพื่อให้เกิด Automate Testing
  3. จะดูแลให้มันยั่งยืนได้อย่างไรเจ้า Automate Testing

และจากประสบการณ์ผม Automate Testing มิได้เกิดจากการตั้งงบประมาณซื้อ หรือเทคนิคต่างๆ อย่างเช่น Test-Driven Development หรือ Acceptance-Test Driven Development แต่เกิดจาก สมอง ของคนเรานี่แหละว่าที่คิดทบทวน พินิจพิเคราะห์ หาให้เจอว่า ปัญหาของเราคืออะไรที่จะนำ Automate Testing เข้าไปช่วย พร้อมทั้ง Automate Testing เราสร้างขึ้นมาเองก็ได้นะจ๊ะ ไว้ถึงคืนพระจันทร์เต็มดวงจะมาพล่ามต่อ

Automate Testing มันช่วยให้เราเร็วขึ้น ได้ Feedback กลับมาเร็วขึ้น แต่ทำใจที่จะช้าก่อนในช่วงแรกได้ไหม Management ทั้งหลายที่สั่งให้ทำ และเซ็น อนุมัติงบให้ซื้อ

วันจันทร์ที่ 21 มีนาคม พ.ศ. 2559 เวลา 12:53 น.
บางรัก กรุงเทพมหานคร

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *