ถนนสู่การทดสอบที่คล่องตัวยิ่งขึ้น

รายงานคุณภาพโลกประจำปีที่สร้างโดย Capgemini แสดงให้เห็นว่า 42% ของผู้ตอบแบบสำรวจระบุว่า "ขาดความเชี่ยวชาญในการทดสอบอย่างมืออาชีพ" เป็นความท้าทายในการใช้การทดสอบกับการพัฒนา Agile ในขณะที่การถือกำเนิดของ Agile ได้นำมาซึ่งความเร็วที่เพิ่มขึ้นของการทำซ้ำสำหรับการพัฒนาซอฟต์แวร์ ในบางกรณี สิ่งนี้ได้นำมาซึ่งต้นทุนด้านคุณภาพ

การแข่งขันที่ดุเดือดกำลังกดดันให้ทีมนำเสนอการอัปเดตผลิตภัณฑ์ใหม่อย่างต่อเนื่อง แต่บางครั้งสิ่งนี้ก็มาพร้อมกับต้นทุนของตัวเอง ซึ่งรวมถึงความสนใจในการทดสอบที่ลดลงด้วย บางคนเช่น Rob Mason ไปไกลกว่านั้นและโต้แย้งว่า Agile กำลังทำลายการทดสอบซอฟต์แวร์ เมื่อเร็ว ๆ นี้ Facebook ได้เปลี่ยนคำขวัญจาก "ย้ายอย่างรวดเร็วและทำลายสิ่งต่าง ๆ" เป็น "ย้ายอย่างรวดเร็วด้วยโครงสร้างพื้นฐานที่เสถียร" เพื่อพยายามแก้ไขสิ่งล่อใจที่จะเสียสละคุณภาพ

แล้วการทดสอบจะรวมเข้ากับโลกใหม่ของการพัฒนาซอฟต์แวร์ Agile ได้ดีขึ้นได้อย่างไร การทดสอบที่คล่องตัว

การทดสอบแบบดั้งเดิมค่อนข้างยุ่งยากและขึ้นอยู่กับเอกสารประกอบจำนวนมาก การทดสอบ Agile เป็นแนวทางในกระบวนการทดสอบที่เลียนแบบหลักการของการพัฒนาซอฟต์แวร์ Agile โดย:

• การทดสอบทำบ่อยขึ้นมาก
• การทดสอบอาศัยเอกสารน้อยลงและการทำงานร่วมกันของสมาชิกในทีมมากขึ้นและ
• กิจกรรมการทดสอบบางอย่างไม่ได้ดำเนินการโดยผู้ทดสอบเท่านั้น แต่ยังดำเนินการโดยนักพัฒนาด้วย

ตลอดเจ็ดปีที่ผ่านมา ฉันได้เปลี่ยนหลายทีมมาใช้การทดสอบแบบ Agile และทำงานเคียงข้างกับผู้ทดสอบเพื่อช่วยให้กระบวนการของพวกเขาเข้ากับวิธีการใหม่ ในบทความนี้ ฉันจะแบ่งปันเคล็ดลับที่ได้ผลที่สุดบางส่วนที่ฉันได้เรียนรู้ตลอดเส้นทางสู่การทดสอบ Agile ที่ดีขึ้น แม้ว่าจะมีความขัดแย้งระหว่างความเร็วและคุณภาพภายในแนวทางปฏิบัติแบบ Agile ก็ตาม บทความนี้จะกล่าวถึงเทคนิคบางประการที่สามารถนำมาใช้เพื่อเพิ่มคุณภาพการทดสอบโดยไม่กระทบต่อความคล่องตัว คำแนะนำส่วนใหญ่ที่ระบุไว้ในที่นี้จะต้องอาศัยการมีส่วนร่วมจากทีมงาน ดังนั้นจึงเป็นประโยชน์ที่จะให้ทั้งนักพัฒนาและผู้ทดสอบมีส่วนร่วมในการวางแผน

กำหนดกระบวนการรอบการทดสอบการเปิดตัวอย่างเป็นทางการ

ปัญหาหนึ่งของการทดสอบคือการไม่มีรอบการทดสอบการวางจำหน่าย ไม่มีกำหนดการเปิดตัว หรือคำขอทดสอบที่ผิดปกติ คำขอทดสอบตามต้องการทำให้กระบวนการ QA ยากขึ้น โดยเฉพาะอย่างยิ่งหากผู้ทดสอบกำลังดำเนินการหลายโครงการ

หลายทีมสร้างเพียงครั้งเดียวหลังจากการวิ่งแต่ละครั้ง ซึ่งไม่เหมาะสำหรับโครงการ Agile การย้ายไปใช้การเผยแพร่สัปดาห์ละครั้งอาจเป็นประโยชน์ โดยค่อยๆ เปลี่ยนไปใช้หลายบิลด์ต่อสัปดาห์ ตามหลักการแล้ว บิลด์การพัฒนาและการทดสอบควรเกิดขึ้นทุกวัน หมายความว่านักพัฒนาจะพุชโค้ดไปที่ที่เก็บทุกวัน และบิลด์มีกำหนดการให้ทำงานในเวลาที่กำหนด เพื่อก้าวไปอีกขั้นหนึ่ง นักพัฒนาจะสามารถปรับใช้โค้ดใหม่ได้ตามต้องการ ในการดำเนินการนี้ ทีมงานสามารถใช้กระบวนการบูรณาการอย่างต่อเนื่องและการปรับใช้อย่างต่อเนื่อง (CI/CD) CI/CD จำกัดความเป็นไปได้ของบิลด์ที่ล้มเหลวในวันที่มีการเปิดตัวครั้งใหญ่

เมื่อรวม CI/CD และระบบอัตโนมัติในการทดสอบเข้าด้วยกัน การตรวจหาจุดบกพร่องที่สำคัญตั้งแต่เนิ่นๆ ก็เป็นไปได้ ทำให้นักพัฒนามีเวลาเพียงพอในการแก้ไขจุดบกพร่องที่สำคัญก่อนการเปิดตัวไคลเอ็นต์ตามกำหนดการ หลักการประการหนึ่งของ Agile ระบุว่าซอฟต์แวร์ที่ใช้งานได้คือการวัดความก้าวหน้าเบื้องต้น ในบริบทนี้ วงจรการเปิดตัวที่เป็นทางการทำให้กระบวนการทดสอบคล่องตัวมากขึ้น

มอบอำนาจให้ผู้ทดสอบด้วยเครื่องมือการปรับใช้

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

ตัวอย่างเช่น ในหนึ่งในทีมของฉัน เราใช้ Git สำหรับการควบคุมเวอร์ชัน และ Slack สำหรับการสื่อสาร นักพัฒนาได้สร้าง Slackbot ที่สามารถเข้าถึง Git สคริปต์การปรับใช้ และเครื่องเสมือนหนึ่งเครื่อง ผู้ทดสอบสามารถ ping บอทด้วยชื่อสาขาที่ได้มาจาก GitHub หรือ Jira และนำไปปรับใช้ในสภาพแวดล้อมการแสดงละคร

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

ทดลองกับ TDD และ ATDD

Test-driven development (TDD) เป็นกระบวนการพัฒนาซอฟต์แวร์ประเภทหนึ่งที่ให้ความสำคัญกับคุณภาพเป็นอย่างมาก ตามเนื้อผ้า นักพัฒนาซอฟต์แวร์จะเขียนโค้ด จากนั้นจึงมีผู้ทดสอบและรายงานว่าพบจุดบกพร่องหรือไม่ ใน TDD นักพัฒนาจะเขียนการทดสอบหน่วยก่อนที่จะเขียนโค้ดใดๆ ที่จะทำให้เรื่องราวของผู้ใช้สมบูรณ์ การทดสอบเริ่มต้นล้มเหลวจนกว่านักพัฒนาซอฟต์แวร์จะเขียนโค้ดขั้นต่ำเพื่อผ่านการทดสอบ หลังจากนั้น โค้ดจะถูกปรับโครงสร้างใหม่เพื่อให้เป็นไปตามข้อกำหนดด้านคุณภาพของทีมงาน

การพัฒนาที่ขับเคลื่อนด้วยการทดสอบการยอมรับ (ATDD) เป็นไปตามตรรกะที่คล้ายคลึงกันกับ TDD แต่ตามที่ชื่อบอกไว้ มุ่งเน้นไปที่การทดสอบการยอมรับ ในกรณีนี้ การทดสอบเพื่อการยอมรับจะถูกสร้างขึ้นก่อนการพัฒนาร่วมกับนักพัฒนา ผู้ทดสอบ และผู้ขอ (ลูกค้า เจ้าของผลิตภัณฑ์ นักวิเคราะห์ธุรกิจ ฯลฯ) การทดสอบเหล่านี้ช่วยให้ทุกคนในทีมเข้าใจความต้องการของลูกค้าก่อนที่จะเขียนโค้ดใดๆ

เทคนิคอย่าง TDD และ ATDD ทำให้การทดสอบมีความคล่องตัวมากขึ้นโดยการย้ายขั้นตอนการทดสอบไปยังช่วงเริ่มต้นของวงจรการพัฒนา เมื่อเขียนสถานการณ์ทดสอบตั้งแต่เนิ่นๆ นักพัฒนาจำเป็นต้องเข้าใจข้อกำหนดเป็นอย่างดี ซึ่งช่วยลดการสร้างโค้ดที่ไม่จำเป็นและยังช่วยแก้ไขความไม่แน่นอนของผลิตภัณฑ์ในช่วงเริ่มต้นของวงจรการพัฒนา เมื่อคำถามหรือข้อขัดแย้งเกี่ยวกับผลิตภัณฑ์ปรากฏขึ้นเฉพาะในขั้นต่อมา เวลาในการพัฒนาและต้นทุนจะเพิ่มขึ้น

ค้นพบความไร้ประสิทธิภาพด้วยการติดตามการเคลื่อนไหวของการ์ดงาน

ในหนึ่งในทีมของฉัน เรามีนักพัฒนาที่ทำงานเร็วมาก โดยเฉพาะอย่างยิ่งกับฟีเจอร์เล็กๆ เขาจะได้รับความคิดเห็นมากมายระหว่างการตรวจสอบโค้ด แต่ฉันกับ Scrum master ของเราเขียนว่าขาดประสบการณ์ อย่างไรก็ตาม เมื่อเขาเริ่มเขียนโค้ดคุณลักษณะที่ซับซ้อนมากขึ้น ปัญหาก็ชัดเจนขึ้น เขาได้พัฒนารูปแบบการส่งต่อรหัสเพื่อทดสอบก่อนที่มันจะพร้อมอย่างเต็มที่ รูปแบบนี้มักพัฒนาขึ้นเมื่อขาดความโปร่งใสในกระบวนการพัฒนา—เช่น ไม่ชัดเจนว่าแต่ละบุคคลใช้เวลานานแค่ไหนกับงานที่กำหนด

บางครั้ง นักพัฒนาซอฟต์แวร์เร่งทำงานเพื่อพยายามนำคุณลักษณะออกโดยเร็วที่สุดและ "เอาท์ซอร์ส" ที่มีคุณภาพให้กับผู้ทดสอบ การตั้งค่าดังกล่าวจะขยับคอขวดต่อไปตามการวิ่ง การประกันคุณภาพ (QA) เป็นเครือข่ายความปลอดภัยที่สำคัญที่สุดที่ทีมมี แต่นั่นอาจหมายความว่าการมีอยู่ของ QA ทำให้นักพัฒนาสามารถละเลยการพิจารณาด้านคุณภาพได้

เครื่องมือการจัดการโครงการที่ทันสมัยจำนวนมากมีความสามารถในการติดตามการเคลื่อนไหวของการ์ดงานบนกระดาน Scrum หรือ Kanban ในกรณีของเรา เราใช้ Jira เพื่อวิเคราะห์ว่าเกิดอะไรขึ้นกับงานของนักพัฒนาที่เป็นปัญหาและทำการเปรียบเทียบกับนักพัฒนาคนอื่นๆ ในทีม เราพบว่า:

• งานของเขาใช้เวลาเกือบสองเท่าในคอลัมน์การทดสอบของกระดานของเรา
• งานของเขาจะถูกส่งคืนจาก QA บ่อยขึ้นมากสำหรับการแก้ไขรอบที่สองหรือสาม

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

ในการแก้ไขปัญหานี้ เราเริ่มต้นด้วยการพูดคุยอย่างตรงไปตรงมากับนักพัฒนาซอฟต์แวร์รายนี้ ในกรณีของเรา เขาไม่ทราบว่ารูปแบบการทำงานของเขาเสียหายเพียงใด มันเป็นเพียงวิธีที่เขาเคยชินในการทำงานในบริษัทเดิมของเขา ซึ่งมีข้อกำหนดด้านคุณภาพที่ต่ำกว่าและกลุ่มผู้ทดสอบที่ใหญ่กว่า หลังจากการสนทนาของเราและด้วยความช่วยเหลือจากเซสชันการเขียนโปรแกรมคู่กับ Scrum Master ของเรา เขาก็ค่อยๆ เปลี่ยนไปใช้แนวทางการพัฒนาคุณภาพสูงขึ้น เนื่องจากความสามารถในการเขียนโค้ดที่รวดเร็วของเขา เขาจึงยังคงเป็นผู้ที่มีประสิทธิภาพสูง แต่ "ความสูญเปล่า" ของกระบวนการ QA ที่ถูกกำจัดออกไป ทำให้กระบวนการทดสอบทั้งหมดคล่องตัวขึ้นมาก

เพิ่มระบบทดสอบอัตโนมัติให้กับ QA Team Skillset

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

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

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

จัดการลำดับความสำคัญในการทดสอบ

ด้วยการพัฒนาซอฟต์แวร์ที่ไม่คล่องตัว โดยปกติผู้ทดสอบจะได้รับการจัดสรรตามโปรเจ็กต์ อย่างไรก็ตาม ด้วยการถือกำเนิดของ Agile และ Scrum จึงกลายเป็นเรื่องธรรมดาที่ผู้เชี่ยวชาญด้าน QA เดียวกันต้องดำเนินการในหลายโครงการ ความรับผิดชอบที่ทับซ้อนกันนี้สามารถสร้างความขัดแย้งในตารางเวลา และนำไปสู่ผู้ทดสอบที่พลาดพิธีสำคัญ เมื่อผู้ทดสอบจัดลำดับความสำคัญของการทดสอบการเปิดตัวของทีมหนึ่งมากกว่าเซสชันการวางแผนการวิ่งของอีกทีมหนึ่ง

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

ฝ่ายสนับสนุนลูกค้า

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

การจัดการผลิตภัณฑ์

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

ทดสอบระบบอัตโนมัติ

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

สรุป: การทดสอบคุณภาพเปรียว

การทำให้การทดสอบมีความคล่องตัวมากขึ้นเป็นสิ่งที่หลีกเลี่ยงไม่ได้ที่ทีมพัฒนาซอฟต์แวร์จำนวนมากกำลังเผชิญอยู่ในขณะนี้ อย่างไรก็ตาม คุณภาพไม่ควรประนีประนอมโดยใช้ความคิดที่ "ทดสอบให้เร็วที่สุดเท่าที่คุณจะทำได้" จำเป็นอย่างยิ่งที่การเปลี่ยนผ่านแบบ Agile รวมถึงการเปลี่ยนไปใช้การทดสอบแบบ Agile และมีสองสามวิธีในการบรรลุเป้าหมายนี้:

• กำหนดกระบวนการรอบการทดสอบการวางจำหน่ายอย่างเป็นทางการ
• เพิ่มขีดความสามารถให้กับผู้ทดสอบด้วยเครื่องมือการปรับใช้
• ทดลองกับการพัฒนาที่ขับเคลื่อนด้วยการทดสอบและการพัฒนาที่ขับเคลื่อนด้วยการทดสอบเพื่อการยอมรับ
• ค้นพบความไร้ประสิทธิภาพด้วยการติดตามการเคลื่อนไหวของการ์ดงาน
• เพิ่มการทดสอบอัตโนมัติให้กับชุดทักษะของทีม QA
• จัดการลำดับความสำคัญของผู้ทดสอบ

ทุกๆ ปี ซอฟต์แวร์ดีขึ้นเรื่อยๆ และความคาดหวังของผู้ใช้ก็เพิ่มขึ้น นอกจากนี้ เนื่องจากลูกค้าคุ้นเคยกับผลิตภัณฑ์คุณภาพสูงของแบรนด์ซอฟต์แวร์ชั้นนำ เช่น Google, Apple และ Facebook ความคาดหวังเหล่านี้จึงส่งต่อไปยังผลิตภัณฑ์ซอฟต์แวร์อื่นๆ ด้วย ดังนั้น การเน้นที่คุณภาพจึงน่าจะมีความสำคัญมากขึ้นในอีกไม่กี่ปีข้างหน้า การทดสอบและการปรับปรุงกระบวนการพัฒนาโดยรวมเหล่านี้สามารถทำให้การทดสอบคล่องตัวมากขึ้นและรับประกันคุณภาพของผลิตภัณฑ์ในระดับสูง