[สรุปหนังสือ] How Google Tests Software : Chapter 1
บทความนี้เราจะขอมาสรุปหนังสือที่มีชื่อว่า How Google Tests Software ที่พี่หนุ่มได้แนะนำให้ทีม We Love Bug อ่านกัน จากตอนแรกที่ต้องอ่านพร้อมกับทุกคนทุกเช้า กลายเป็นต้องล้มเลิกไปก่อน เราจึงถือโอกาสวันหยุดยาวลองหยิบมาอ่านดูค่ะ ดังนั้นทั้งหมดที่เขียนสรุปไว้ในบทความนี้ เกิดขึ้นมาจากการทำความเข้าใจและการแปลของตัวผู้เขียนเอง หากมีข้อผิดพลาดยังไง ผู้เขียนก็ขออภัยล่วงหน้าไว้ก่อนนะคะ
Chapter 1 Introduction to Google Software Testing
— James Whittaker —
ที่ Google มีนักทดสอบ หรือ Tester ที่เป็นประจำน้อยกว่าบริษัทอื่น ๆ ที่เป็นคู่แข่ง ซึ่งทีมนักทดสอบของ Google เป็นเหมือนหน่วยรบพิเศษขนาดเล็กแต่ก็เก่งมาก และต้องพึ่งพากลยุทธ์ที่เหนือกว่าและอาวุธที่ทันสมัย เพื่อให้มีโอกาสต่อสู้เพื่อความสำเร็จ สูตรลับอยู่ที่การขาดแคลนคน เหมือนที่ Larry Page กล่าว “ความขาดแคลน นำมาซึ่งความชัดเจน” และความขาดแคลนนี้ยิ่งทำให้ทรัพยากรการทดสอบมีค่าสูงขึ้น
คำแนะนำแรกเมื่อมีคนถามถึงกุญแจสู่ความสำเร็จกับเรา นั่นคือ อย่าจ้าง Tester มากเกินไป
แล้ว Google ทำยังไงเมื่อมี Tester น้อย? คำตอบก็คือ เขายกภาระหน้าที่ด้านคุณภาพให้กับคนที่เขียน Code นั่นเอง เพราะทุกคนใน Google ที่เขียน Code ก็เป็น Tester และมันทำให้การควบคุมคุณภาพเป็นปัญหาของคนกลุ่มนี้มากกว่า
ถ้าคุณคือ Engineer คุณก็คือ Tester
หรือ
ถ้าคุณคือ Engineer ที่มีคำว่า Test ที่ชื่อตำแหน่ง แปลว่า คุณคือผู้ที่ให้คำแนะนำหรือสนับสนุนเกี่ยวกับการทดสอบ ให้กับ Engineer คนอื่น ๆ ที่ไม่มีความรู้หรือไม่ได้เชี่ยวชาญเรื่องนี้
Quality ≠ Test
“คุณภาพไม่สามารถทดสอบได้”
Google มีเป้าหมายชัดเจนว่าต้องการให้การพัฒนาและการทดสอบเกิดขึ้นไปด้วยกัน เหมือนรวมกันเป็นหนึ่งเดียว จะเกิดขึ้นอย่างใดอย่างหนึ่งไม่ได้ เช่น ถ้าสร้างนิดเดียวก็ต้องทดสอบ ถ้าสร้างเพิ่มก็ต้องทดสอบเพิ่ม และคนที่จะทำการทดสอบหรือหาข้อผิดพลาดได้ดีที่สุดจะเป็นใคร ถ้าไม่ใช่คนที่สร้างมันขึ้นมานั่นเอง เพราะถ้าเราเจอข้อผิดพลาด เราก็ต้องส่งต่อให้คนที่สร้างข้อผิดพลาดนั้นขึ้นมา แทนที่จะเป็น Tester
นั่นหมายความว่าคุณภาพเป็นการป้องกันมากกว่าการตรวจจับ และคุณภาพเป็นปัญหาของการพัฒนา ไม่ใช่ปัญหาของการทดสอบ ในการรีวิว Code ของ Google จะต้องมีคำถาม “การทดสอบของคุณอยู่ไหน?” อยู่เสมอ และกระทั่งในห้องน้ำของพนักงานก็ยังมีป้ายติดผนังเกี่ยวกับการทดสอบเอาไว้ทุกห้อง
โครงการนี้เรียกว่า “Testing on the Toilet”
Roles
The software engineer (SWE)
SWEs ใช้เวลาส่วนใหญ่ไปกับการเขียนและตรวจทาน Code รวมถึงการออกแบบ Architecture เอกสารประกอบต่าง ๆ และเขียน Unit Test ทดสอบ Code ของตัวเอง ไม่ว่าจะมีการเปลี่ยนหรือดัดแปลง Code ยังไง คนที่ต้องเขียนการทดสอบก็คือตัวเขาเองทั้งหมด
The software engineer in test (SET)
SETs จะมุ่งเน้นไปที่การทดสอบ ดูแลเรื่องคุณภาพและความเสี่ยงของ Code ทั้งด้าน Performance และ Security เขายังต้อง Refactor code เพื่อให้ทดสอบได้มากขึ้น และเขียน Automated ของ Unit Test ดังนั้น SETs จะใช้เวลาในการเขียน Code เกือบ 100% แต่ก็เพื่อคุณภาพของ Code มากกว่าเรื่องของฟีเจอร์
The test engineer (TE)
TEs จะเป็นนักทดสอบที่มองในมุมมองของผู้ใช้งานเป็นหลัก จะต้องเป็นผู้เชี่ยวชาญด้าน Domain หรือ Product บางคนใช้เวลาส่วนใหญไปกับการเขียน Test Script ของ Automation มีทั้ง API และ UI ซึ่งจะเขียนตาม Scenario ของผู้ใช้งาน หรือบางคนก็จะเขียน Test Script น้อยมาก
Organizational Structure
องค์กรส่วนใหญ่ที่เขาเคยทำงานด้วย จะมี Dev และ Tester เป็นส่วนหนึ่งของทีม Product เดียวกัน และมีผู้จัดการทีมคนเดียวกัน ทุกคนจะมาจากทีมเดียวกันตั้งแต่ต้น
แต่ที่ Google จะใช้ Engineering Productivity วิเคราะห์ว่า Tester จะได้อยู่ทีม Product อะไร วิเคราะห์จากลำดับความสำคัญ ความซับซ้อน และความต้องการของ Product มากน้อยเท่าไหร่ เพื่อให้เกิดความสมดุลกัน และวิธีนี้ถูกนำไปใช้ทั่วทั้งบริษัท
สถานะ On-loan ของ Testers ที่ Google
สถานะการยืมนี้ ช่วยให้ง่ายต่อการย้าย Software Engineer in Test (SETs) และ Test Engineer (TEs) จาก Project หนึ่ง ไปอีก Project หนึ่ง และยังช่วยให้พวกเขาได้เจอสิ่งใหม่ ๆ อยู่ตลอด และได้มีส่วนร่วมกับหลาย ๆ Project และทำให้ได้ใช้เทคนิคหรือเครื่องมือการทดสอบที่ดีทั่วทั้งบริษัท
Crawl, Walk, Run
สิ่งสำคัญที่ทำให้ Google ได้ผลลัพธ์ที่ดี และมี Testers น้อยกว่าหลาย ๆ ที่ นั่นคือ พวกเขาไม่ค่อยออก Feature ชุดใหญ่ ๆ พร้อมกัน จะได้รับ Feedback กลับมาแล้วนำไปพัฒนาต่อเรื่อย ๆ ทำให้ได้ดำเนินการทดสอบและทดลองใช้กับแอปพลิเคชันที่ถูกสร้างขึ้นตั้งแต่แรก ๆ และวิธีนี้ทำให้ได้รับ Feedback จากผู้ใช้งานจริง ๆ อีกด้วย
ก่อนที่ Google จะเปิดตัวเวอร์ชั่น Beta ได้นั้น Product แต่ละตัวจะต้องผ่าน Channel ต่าง ๆ หลาย Channel เพื่อพิสูจน์ว่า Product ที่พัฒนาขึ้นมานั้นมีความคุ้มค่ามากน้อยเพียงใด ยกตัวอย่างเช่น Chrome ในระยะเวลา 2 ปีแรกที่เจมส์ทำงานอยู่ที่ Google พวกเขาก็ได้ใช้หลาย Channel กับ Product นี้ ขึ้นอยู่กับความเชื่อมั่นในคุณภาพของ Product ว่าจะใช้ช่องทางใดบ้าง เรียงลำดับช่องทาง ดังนี้
Canary Channel
ใช้สำหรับการทดลองและ Code ในแต่ละวันที่เราคิดว่ายังไม่เหมาะกับการ Release เราจึงจำเป็นต้องตรวจสอบงานของเราใหม่อีกครั้ง ผู้ที่จะใช้ Channel นี้ส่วนมากจะเป็นวิศวกร (นักพัฒนา และนักทดสอบ) และ ผู้จัดการที่เกี่ยวข้องกับ Product
Dev Channel
นักพัฒนาจะใช้ Channel นี้ในการทำงานประจำวันของเขา โดยทั่วไปจะเป็นงานที่ต้อง build รายสัปดาห์ ที่สามารถใช้งานได้อย่างต่อเนื่อง และผ่านการทดสอบบางชุดมาบ้างแล้ว วิศวกรทุกคนจำเป็นต้องใช้ Channel ในการใช้งานจริง เพื่อการทดสอบอย่างต่อเนื่อง และหาก Dev Channel build ไม่เหมาะกับงานจริง จะต้องกลับไปที่ Canary Channel และทีมวิศวกรจะต้องประเมินมันอีกครั้ง
Test Channel
Testers ใช้สำหรับการทดสอบ และยังใช้สำหรับการทดลองใช้งานจริงภายในบริษัทด้วยกันเอง โดยที่ยังไม่ได้มีการเผยแพร่ หรือที่เรียกว่า Dogfooding สามารถให้ Test Channel เป็นตัวแทนของ Beta Channel ก่อนที่จะเผยแพร่จริงได้ หรือในบางครั้งก็จะให้บุคคลภายนอกที่ทำงานร่วมกันกับบริษัท หรือผู้ที่เป็นพันธมิตรที่จะได้ประโยชน์จากการทดลอง Product ก่อนกำหนด
Beta Channel หรือ Release Channel
สำหรับ Channel นี้ จะเป็น build ที่ Test Channel เสถียรแล้ว ผ่านการทดลองใช้งานภายในมาแล้ว และผ่านการทดสอบคุณภาพทุกอย่างที่ทีมได้ตั้งไว้ จะเป็นงานที่ถูกเผยแพร่สู่ภายนอก
Types of Tests
Google ไม่ได้แยกการทดสอบระหว่าง Code, Integration และ System testing แต่แบ่งการทดสอบออกเป็น 3 ประเภท ซึ่งมีทั้ง Manual และ Automated testing
- Small Tests: ถูกเขียนและใช้โดย Software Engineer (SWE) และ Software Engineer in Test (SET) มุ่งเน้นไปที่ Single Module
- Medium Tests: ถูกเขียนและใช้งานโดย Software Engineer in Test (SET) มุ่งเน้นไปที่การ Integration 2 Feature ขึ้นไป
- Large Tests: ถูกเขียนและใช้งานโดย Test Engineer (TE) มุ่งเน้นไปที่สถานการณ์จริงของผู้ใช้ (Real User Scenarios)
#readwithnat
