ว่าด้วยเรื่องของ Regression Test การจัดการ มุมมอง และสิ่งต้องระวัง

Blog นี้คุยกันเรื่อง Regression Test นะครับ เนื่องจากที่สัมผัสมา แต่ละที่มีนิยาม สิ่งที่มีอยู่ และการจัดการกับ Regression Test ไม่เหมือนกันเลย เกริ่นไว้ก่อนว่า สิ่งที่จะเขียนต่อไปนี้ มิได้มีหนังสืออะไรมารองรับ มาจากประสบการณ์และมุมมองส่วนตัวเป็นหลักละกันนะ

เรามาเริ่มจาก Regression Test คืออะไรก่อนละกันครับ ตามนิยามแล้ว

Regression Test คือการ Test เพื่อหา Impact หรือ Side effect จาก Change

ซึ่งคำว่า Change เนี่ย สามารถเป็นได้ทั้งการ Change ที่ตัว Software ของเราเอง หรือแม้แต่การ Change ของ component/system รอบข้างมัน หรือแม้แต่ Environment หรือ Platform ที่ตัว Software รันอยู่นะ ถ้ามองแบบนี้ก็จะเห็นภาพง่ายขึ้น ก็คือ มี change อะไรเกิดขึ้นก็ตาม เรามา test ดูซิ ว่ามี impact กับ software หรือ feature ต่างๆของเรารึเปล่า เช่น มีการเพิ่ม feature หรือ fix bug มา นั่นก็คือการ change หรือ มีการ upgrade version ของ API ที่ software เราไปต่ออยู่ ก็คือการ change หรือแม้แต่มี OS หรือ mobile device model ใหม่ๆ มี browser version ใหม่ๆออกมา ก็คือการ change ที่ทำให้เราต้องรัน regression test ซึ่งถ้าในตัวอย่างหลังเนี่ย บางทีเค้าก็จะเรียกมันตามชื่อเฉพาะของมันว่า Compatibility Test หรือ Qualification Test

ทีนี้พอเข้าใจนิยามแล้ว คำถามถัดมาที่มักจะเกิดขึ้นคือ แล้วเราต้อง Test อะไรบ้างหล่ะ ซึ่งอันนี้แหล่ะ แต่ละที่แต่ละคนทำไม่เหมือนกันเลย (ส่วนใหญ่แล้วก็คือรับมรดก Regression Test case มาจากคนอื่นหรือคนที่อยู่โปรเจคมาก่อนหน้าเราแล้วฉันก็ต้องมาดูแลมรดกนั้นแบบงงๆ ก็ execute test ตาม test case ที่มีไปเรื่อยๆ) จากประสบการณ์ส่วนตัวแล้วเราสามารถมอง Regression Test ได้สองสามแบบนะ

1. Test มันทุก functions ทุก features ที่มีของระบบ อันนี้คือ ดีที่สุดในแง่ Quality เพราะว่าเรา test มันทุกสิ่งซึ่งจำเป็นหรือไม่จำเป็นก็ไม่รู้ เสี่ยงรึเปล่าไม่สน test มันให้หมด แต่ว่าวิธีนี้ในอีกแง่นึงคือ ห่วยที่สุด ในแง่การใช้ effort และ efficiency เพราะการ test แบบนี้โดยส่วนใหญ่คือการ test เกินความจำเป็นไปเยอะ อย่างไรก็ตาม วิธีนี้เอาจริงๆก็คือวิธีที่เป็นที่นิยม และเป็นวิธีที่ส่วนใหญ่ใช้กัน เพราะว่ามันง่าย ไม่ต้องคิดหรือวิเคราะห์มาก มี test case suite อยู่แล้วก็หยิบมาใช้ มา execute เลย
2. แบบที่สองคือทำ Impact Analysis และเลือก test case ที่จำเป็นเท่านั้นมา execute ซึ่งโดยส่วนตัวแล้วแนะนำวิธีนี้ (ในกรณีที่ไม่มี test automation) เนื่องจากใน step แรก เราจะมีการทำ impact analysis ก่อนเพื่อดูว่า change ที่เกิดขึ้นนั้นดูมี impact กับส่วนไหนบ้าง ตัวอย่างง่ายๆเช่น ถ้าสิ่งที่ change คือการ fix bug หน้า cart payment และเราไปคุยไป confirm กับ dev แล้ว เราก็น่าจะสามารถ skip หรือไม่เลือก test case ส่วนของ product search หรือว่า product page/category และ feature อื่นๆอีกมากมาย มาอยู่ใน regression test ของ change นี้ได้.. แต่ แต่ แต่ แต่ว่า การทำ impact analysis นั้นนอกจาก analyze ว่า change เกิดขึ้นที่ตรงไหนแล้วนั้น สามารถรวมไปถึง การ analyze Dev ที่เราทำงานด้วย หรือจากประสบการณ์ที่ผ่านมาได้ด้วยนะ เช่น เพื่อนเด็ปคนนี้ของตรู merge ผิดประจำ สิ่งที่ไม่ควรจะไปเกี่ยวกับ change นี้ แต่เพื่อนชอบหลุดเอา code ส่วนอื่นที่ไม่ได้ตกลงกันไว้มาแทรก มาแฝงประจำ ดังนั้นจาก impact analysis ก็อาจจะบอกว่า ยังไงชั้นก็ต้องมี test search มารวมด้วย แต่อาจจะเลือกข้อหลักๆมาแค่ 1–2 ข้อแทนที่จะมาทั้ง set อะไรแบบนี้เป็นต้น การทำ impact analysis นั้นทำให้เราลดจำนวน test case ที่จะ execute ไปได้เยอะนะ ในสถานการณ์ปกติ แต่เอาจริงๆก็ไม่ใช่สิ่งที่ทำกันได้ง่ายนัก ต้องใช้ประสบการณ์ และการพูดคุยกับ Dev ประมาณนึงว่า แก้ตรงไหน มีโอกาสกระทบตรงไหน หรือไปแตะ share component ตรงไหนบ้าง พอมันยากก็เลยเป็นสาเหตุให้คนส่วนใหญ่ยังเลือกทำแบบข้อ 1 คือ test ทุกสิ่งอยู่เยอะนั่นแหล่ะ มีเทคนิคให้หน่อยนึงสำหรับน้องๆที่อยากลอง move จากวิธีที่ 1 มาวิธีที่ 2 คือการที่เราลองทำ impact analysis แบบฝึกคิด แล้วก็เลือก test case มา ถ้ายังใจไม่กล้าพอก็เลือกแล้วแค่ทดไว้ แล้วก็รัน test ทั้งหมดแบบ 1 แบบที่เราทำมาตลอดนี่แหล่ะ ทีนี้สิ่งที่อยากให้ทำเพิ่มคือมาดูสิว่า bug ที่เราเจอตอน run full regression เนี่ย มี bug ที่อยู่นอก test case ที่เราเลือกจาก impact analysis บ้างรึเปล่า ถ้าทำแบบนี้ไป 2–3 รอบแล้วก็จะทำให้เรามั่นใจขึ้นได้ว่า เออ test case ที่เราเลือกมาจริงๆก็ดีพอนี่หว่า ก็หาจังหว่ะลอง run แค่ test case พวกนั้นดู แล้วเปลี่ยนตัวเองมาทำแบบ 2 ซะ พูดง่ายๆ เป็น step การซ้อมแบบวัดผลเพิ่มความมั่นใจให้ตัวเองก่อนเปลี่ยนจริงๆนั่นเอง
3. แบบสุดท้าย ยอดนิยม in trend (แต่หาที่ทำแบบดีๆจริงๆยากหน่อย) คือ ใช้ Automation Test คือจะลดปัญหาจากข้อหนึ่งกับข้อสองไปได้ประมาณนึงคือ ถ้าจะ test มันทุกสิ่ง แต่ให้ automate ทำให้ ก็ไม่เสีย effort แล้วก็ไม่เจอปัญหากับการต้องมาทำ impact analysis ซึ่งไม่ได้ทำกันง่ายๆ แต่ แต่ แต่ แต่ว่า ถึงจะมี Automation ก็ยังอยากให้ทำ impact analysis อยู่ดีนะ การ run automation เยอะๆ บางทีก็ใช้เวลานานอยู่ดี (ถ้าไม่ได้มี farm device/browser ให้รัน parallel กันได้เยอะๆ) หรือบางที run เยอะเกินความจำเป็นก็เจอ script flakiness ได้เยอะกว่า run เท่าที่จำเป็น เลือกหน่อยดีกว่า และยังไงก็ตาม เราก็ต้อง implement automate อยู่ดีนะ การ implement กับ maintain automate regression ให้ดีก็ไม่ใช่เรื่องง่าย อาจจะยากกว่าสองแบบแรกด้วยซ้ำ ถึงได้บอกในวงเล็บด้านบนไว้ว่า หาที่ทำแบบดีๆจริงๆยากหน่อย

ถัดจากการพูดถึง Regression Test แบบต่างๆแล้ว มาพูดถึงวิธีคิด การจัดการ และสิ่งที่ต้องระวังกันหน่อยดีกว่า อย่างแรก ถึงจะบอกว่า Regression Test แบบง่ายสุดคือการ test ทุกสิ่งอย่าง แต่คำว่าทุกสิ่งอย่างก็มีระดับของมันนะ ทุกสิ่งอย่างแบบ extreme ยกตัวอย่างเช่น scenario ที่เปลี่ยนประเภทบัตร หรือ payment method 20 อย่าง กด back ไปมาไปเปลี่ยนบัตร 20 รอบ (ซึ่งการ test แบบนี้อาจจะทำให้เราเจอ bug ก็ได้นะ) อันนี้ก็ถือเป็น scenario ที่ test ได้ แต่เอาจริงๆ ถ้าเราไม่ได้ test มันแล้วมี bug ตัวนี้หลุดไป อาจจะไม่มีลูกค้าคนไหนมีโอกาสเจอ bug นี้ในชีวิตจริงเลยก็ได้ หรือถ้าจะมีลูกค้าคนนึงเจอ bug นี้หนึ่งครั้งในรอบปีในชีวิตจริง ถ้าเราจะ test หลุด case แบบนี้ก็ช่างมันเหอะ ไม่ได้เสียหายอะไรมากมาย เทียบกับการที่เราต้อง test case แบบนี้ในทุกๆครั้งแล้ว (แต่ถ้า test product พวกที่เสี่ยงไม่ได้เช่นเกี่ยวกับการแพทย์ รถยนต์ เครื่องบิน ยานอวกาศ อาจจะคิดแบบนี้ไม่ได้นะ)

ที่อยากแนะนำให้ลองฝึกคิดคือใช้หลักการ 80:20 คือ โดยปกติแล้วเนี่ย การทำอะไรก็ตามให้ cover 80% เนี่ย ไม่ได้ยากเท่าไหร่และเป็นสิ่งที่เราควร focus มากที่สุด ให้ลองคิดดูง่ายๆว่า ปกติเราเข้าเวป shopping เวปนึงเนี่ย เราทำอะไรกับมันมั่ง ส่วนใหญ่ก็เข้าไป login แล้วก็ search สินค้าที่ตัวเองกำลังหา เข้าไปดู product จาก search result ซักสามสี่ชิ้น ก็เลือกซักชิ้นนึงแล้วไปต่อที่หน้า payment จ่ายตังค์จบ ซึ่ง scenario แบบเนี๊ย เดาว่า จะเหมือนกับ 50–60% ของประชาชนคนอื่นๆที่เข้ามาในเวป shopping เดียวกันนั้น พูดง่ายๆว่า Test แค่ scenario เดียวเนี่ย coverage สูงมากแล้วในมุมของ impact ดังนั้น test case หลักสิบหรือหลักร้อยต้นๆ น่าจะ cover 70% — 80% ของ scenarios หลักๆที่เราไม่อยากพลาดก่อนที่จะ release product แล้วหล่ะ (ถ้ามี bug หลุดคือไม่เจ็บหนักถึงตาย) ทีนี้ ส่วน 20% สุดท้ายนี่แหล่ะที่อาจจะต้องใช้ test case อีกเป็นพันเป็นหมื่นข้อเพื่อให้มัน cover ให้ครบ 100% หรือใกล้เคียง 100% จริงๆ เพราะต้อง cover ทุก scenarios หรือ features ที่มันซับซ้อนต่างๆ (ที่อาจจะแทบไม่มีคนใช้ หรือเจอปัญหาถึงแม้ว่าจะมี bug อยู่ก็ตาม)

จากที่อธิบายไปข้างบน พอมานึกๆดูแล้ว QA ที่เก่งอาจจะไม่ใช่ QA ที่รู้ว่าต้องทำหรือต้องเทสอะไรบ้าง (Know what to test) แต่น่าจะเป็น QA ที่รู้ว่า test อะไรที่ควรจะตัดออกไปบ้าง (Know what not to test)

เพราะสุดท้าย QA สมัยใหม่คือ QA ที่ไม่ได้มีเป้าหมายในการหา bug แต่เป็น QA ที่มี mindset ในการ deliver product ที่มี quality ดี (หรือดีพอ) ขึ้นไปบน production เพื่อให้บริษัทได้ business value ได้เร็วที่สุด ดังนั้นถ้า QA จะทำงานได้ effective และ efficient นั้นต้องเป็นคนที่เลือกเป็น ตัดเป็น ไม่ใช่ทำเยอะ ทำครบไว้ก่อนซะอย่างเดียว

จริงๆแล้ว regression test ไม่ได้มีได้แค่ set เดียว เราสามารถเตรียม regression test ไว้หลายชุดได้ด้วยนะ เช่น lightweight set หรือ sanity test set ก็เป็นคำที่หลายๆคนใช้กัน แต่สรุปแล้วมันคือ set ที่เราเตรียมไว้เพื่อ optimize ระหว่าง test coverage กับ risk กับ เวลาที่ใช้ในการทำ test นั่นแหล่ะ เช่น ตัว lightweight test อาจจมี test case แค่ 10 ข้อ เพื่อตั้งใจจะ cover 60% ของ main customer scenarios และให้ใช้เวลา execute test ไม่เกินครึ่งชั่วโมง อะไรแบบนี้ อาจจะเอาไว้ใช้ execute ก่อนเลยตอนได้ package มา คือถ้า set นี้ไม่ผ่านไม่ต้อง test อะไรต่อหล่ะ เพราะ main feature จริงๆใช้ไม่ได้ หรือเอาไว้ใช้ตอนจำเป็นต้อง test hotfix ด่วน ที่ไม่มีเวลาพอสำหรับการ execute full regression ก็ได้ มีเสริมไว้หน่อยนึง ถ้าเราจะเริ่มทำ test automation เนี่ย ก็เริ่มทำจาก set นี้ก่อนเพราะสำคัญสุด และใช้บ่อยสุด

สิ่งที่ต้องระวังอย่างสุดท้ายคือการดูแลและ maintain regression test มีสองกรณีที่เห็นบ่อยๆและมักจะเกิดขึ้น

1. ทีมทำ product ใหม่เริ่มตั้งแต่ 0 ทีนี้แต่ละ sprint เราก็ทำ test case สำหรับการ test feature ใหม่ๆนั้น มี test case ครบทั้ง positive/negative มี detail กับ scenarios มากมายเหมาะสมกับการ test feature พอมี test case ก็ test ไปตามประสา พอจบ sprint หรือจบ phase ก็ deploy (หรือไม่ deploy ก็ตามแต่) ทีนี้พอขึ้น sprint ใหม่ ก็ออกแบบ test case สำหรับ sprint นั้นๆอีก พอ test feature ใหม่ผ่านปุ๊บ ก็อ่ะ feature เก่าเมื่อ sprint ก่อนหน้ายังใช้งานได้มั๊ยนะ ก็เอา test case จาก sprint ที่แล้วทั้งหมดมา execute (เสมือนว่าเป็น regression test นั่นแหล่ะ) ทีนี้ลองคิดดู สมมติว่า มี test case สำหรับ new feature ซัก sprint ละ 100 test cases ผ่านไป 10 sprints เนี่ย จำนวน regression test case (แบบที่เราไม่บริหารจัดการ) มันก็กลายเป็น 1,000 test cases ไปแล้วนา ไปๆมาๆ ก็จะถึงจุดที่ execute ไม่ไหว…. สิ่งสำคัญที่อยากย้ำคือ regression test case ไม่เท่ากับ test case ทั้งหมดที่เราทำเพื่อ test feature ต่างๆ แต่เราต้องเลือก เลือกตาม 80:20 ที่อธิบายไปด้านบนก็ได้ คือ จาก test case 100 ข้อที่เรามี เลือก test case ที่สำคัญๆ มี impact เยอะๆ สำหรับ feature นั้นมา 5 ข้อ 10 ข้อก็ได้ ไม่จำเป็นต้องเลือกแต่ positive case นะ เลือก negative case ที่สำคัญๆ หรือคนมักจะใช้ระบบผิดแบบนี้มาอยู่ใน regression test ก็ได้ ไม่ผิดกติกาแต่อย่างใด แล้วเราก็เริ่มสร้าง regression test suite ของเราขึ้นมาจากจุดนั้น ค่อยๆเลือกเพิ่มในแต่ละ sprint ในแบบที่จำเป็น
2. ทีมที่เข้าไปรับงาน หรือ product ที่เสร็จแล้วประมาณนึง บางทีอาจจะต้องมีการ build regression set ขึ้นมาใหม่ (จาก product ที่เสร็จแล้ว) ก็ใช้เวลาเขียน regression test กันไป (อย่างตรากตรำลำบาก) พอทำเสร็จ จุดพลุฉลอง นี่คือคัมภีร์ไบเบิลของทีมฉัน ใช้ regression set นี้กับหลายๆ release หลังจากนั้น แต่ แต่ แต่ แต่ว่า ลืม เอา test case ของ feature ใหม่ๆ ไปอัปเดตใน regression set ที่เราสร้างขึ้นมาอย่างตรากตรำ ไปๆมาๆ กลายเป็นว่าใช้แต่ regression set ที่ไม่อัปเดต ไม่มี test case ที่ cover feature ใหม่ๆของ product เลย แบบนี้ก็เจอบ่อย

เสริมให้เป็นสิ่งสุดท้าย ถ้าทีมที่เริ่มทำ automation test แล้ว อย่างน้อยนะ อย่างน้อยคือ ต้องหาเวลาใน sprint มาเขียน automate ของ regression test case ที่เราเลือกมาจาก sprint หรือ phase ก่อนหน้าด้วยเน้อ แต่สำหรับทีมที่ mature และคล่องกับการทำ automate แล้ว ถ้าสามารถเลือก regression test (ของ feature ใน sprint) ใน sprint นั้นเองแล้วเขียน automation ได้เลยใน sprint คือถือว่าหรูเลิศ แต่นั่นแหล่ะ ถ้ายังไม่ไหว ทดไว้ 1 sprint ก็พอได้แต่ทำให้เสร็จก่อน execute regression ละกันเพื่อให้ regression test execution เป็น automate 100% ได้ตลอดเวลา

คำเตือน เนื้อหาเหล่านี้มาจากความเห็นและประสบการณ์ส่วนตัว มิได้มีหนังสือหรือบทความทางวิชาการใดๆมาอ้างอิง โปรดพิจารณาและปรับเชื่อตามความเหมาะสมนะจ๊ะ

Doppio Tech — We Build And Serve Expertise

www.doppiotech.com

Log in or sign up to view