Videos → All about testing from 0 to 7 (คิดก่อนทำ หรือ ทำแล้วค่อยคิด .. ที่จะ Test)

เริ่มการบรรยายและแนะนำตัว0:00

พี่ปุ๋ยพร้อมมั้ยครับ โอเคพร้อมแล้วครับผม ขอเรียนเชิญเลยครับผม ขอส่งไมค์ให้กับพี่ปุ๋ยเลยนะครับ โอเคนะครับ เดี๋ยวจับเวลาแป๊บนึงนะครับ ครับผม สวัสดีทุกท่านนะครับ ก็ชื่อสมเกียรตินะครับ ก็วันนี้นะครับเรามาพูดเรื่อง testing นะ JavaScript testing เนาะก็ 0-7 อะไรก็ไม่รู้ ก็คือ everyday นั่นเองนะครับ ก็มาดูกันเนาะ เขียน blog อะ จบละนะครับ

คำถามเกี่ยวกับการทดสอบซอฟต์แวร์และความสำคัญ0:24

เริ่มที่คำถามเนาะ พอดีเพิ่งมีคำถามที่สมาคมโปรแกรมเมอร์ นี่ใช่ไหม คำถามนี้ ตอบไงดีครับ

อันนี้ใครตอบอะไรบ้างครับ ที่บริษัททำกันมั้ยครับ มีคำถามนี้มั้ย เป็นคำถามอะไรเค้าเรียกว่าอะไรนะ ไก่กับไข่ใช่มั้ย ไม่รู้จะตอบอะไรดีนะครับ ผมว่าแต่ละที่ แต่ละ business เนาะ มีคำตอบที่อาจจะเหมือนหรือแตกต่างกันก็ว่าไปนะครับ แต่ผมว่าเห็นก่อนว่านี่คือคำถามที่ในองค์กรจะถามนะครับ แต่ถ้ามีปัญหา เค้าจะไม่ถามละ เค้าจะถามว่า ทำไมมี bug ใช่ไหม ถูกไหมนะครับ ก็ลองดูเนาะ นะครับ เราจะทำอย่างไรนะครับ

การเลือกระหว่างคุณภาพและปริมาณในการพัฒนาซอฟต์แวร์1:04

ประเด็นคือ ผมจะถามเสมอคือ ระหว่าง quality กับ quantity เราเลือกอะไรครับ ปัจจุบันที่บริษัทเรา quality คือคุณภาพนะครับ quantity คือทำให้เสร็จมากที่สุดเท่าที่ทำได้ เค้าเรียกว่าอะไรครับ มีเวลาสร้างเนาะ แต่ไม่มีเวลาทำให้ดี ใช่ไหม เพราะอะไรครับ เราจะสร้างให้เสร็จเพื่อตรงเวลาใช่ไหม นะครับ เสร็จแล้วก็เราจะมีเวลามาแก้ bug ใช่ไหม แต่ไม่มีเวลาทำให้ดี นะครับ มันดูขัดแย้งใช่ไหม เค้าเรียกว่า ขว้างงูไม่พ้นคอ เนาะ อันนี้ นะครับ ก็ลองดูนะครับ ดังนั้น หลายๆ คนจะเป็นคนกลุ่มนี้ไหม ใคร We Love Bug บ้างครับ ใครชอบครับ ใครรัก

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

แล้วที่สำคัญคือเรื่อง bug เนาะ นะครับ

ต้นทุนของข้อผิดพลาดและความสำคัญของการทดสอบ1:55

มันมีคำว่า cost of bug เนาะ นะครับ คือ bug นะครับ มันมีค่าใช้จ่าย คำถามก็คือ bug ปัจจุบันเราเจอที่ไหนเยอะสุดครับ เจอที่ dev เนาะ ใช่ไหมครับ ส่วน production ไม่ค่อยเจอหรอก แต่พอเจอปุ๊บ บรรลัยใช่ไหม ถูกไหมครับ เพราะอะไรครับ ถึงแม้คุณจะมี bug น้อย แต่ bug นั้นอาจจะก่อให้เกิดเค้าเรียกว่าค่าใช้จ่ายมหาศาล ถูกไหม แล้วก็จะโดนด่าเนาะว่า ทำไมงานขึ้นเร็วใช่ไหม แต่ bug เยอะ มีคุ้นๆ มั้ย time to market ใช่ไหม แต่พอ time to market ดีปุ๊บ bug ก็เยอะ ใช่ไหม อันนี้ก็ต้อง trade off เนาะ แต่ในแง่ของการจัดการเนาะ เราอยากได้อะไรครับ คุณภาพดีเนาะ เร็ว แล้วก็คุณภาพดี เร็ว แล้วก็ถูก ใช่ไหม นะครับ

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

ความสำคัญของคุณภาพและการทดสอบในการพัฒนาซอฟต์แวร์3:25

หนึ่งในคุณภาพคือเรื่องของอะไรครับ เรื่องของ testing เนาะ ของเราเป็นอะไรครับ JavaScript นะครับ เราจะพูดถึงเรื่องของ JavaScript testing นะครับว่า ในแง่ของการเทส ที่เซคชั่นก่อนหน้าพูดถึงเรื่องของพวก pyramid testing เนาะ

ใครยังทำแบบรูปนี้บ้าง ยกมือครับ manual เยอะๆ automate น้อยๆ

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

ในองค์กรใหญ่ๆ ชอบรูปนี้ อะไรหวานๆ จะไม่ค่อยดีใน software development เนาะ ลองดูนะครับ อันนี้ pyramid เนาะ ไม่ค่อยมีใครทำ นี่เราชอบทำแบบนี้ใช่ไหม นะครับ เรามี manual test เรามีนักพัฒนา ใช่ไหมครับ เรามีอะไรครับ automation ดังนั้นมี 3 ทีมเลยใช่ไหม ทดสอบเคสเดียวกันนี่แหละ 3 ทีม จะได้ไม่ฮั้วกันนะครับเนาะ แล้วพอผ่าน 3 ทีมปุ๊บ ทุกอย่างผ่านหมด ยกเว้น production ใช่ไหม แล้วค่าใช้จ่ายคูณ 3 เป็นหรือเปล่า ไม่แน่ใจ หลังๆ มา ผมชอบรูปนี้เนาะ

รูปแบบการทดสอบแบบต่างๆ และการเลือกใช้4:34

นี่คุ้นๆ มั้ย ผมเรียกว่าแปลเป็นไทยคือ ทดสอบจนได้ถ้วย ใช่ไหม ประเด็นคือเค้ากำลังโฟกัสที่อะไรครับ integration กับ end-to-end ให้มากเนาะ เพราะว่าระบบงานของเราเนาะ ใช่ไหมครับ ที่นี่ใครเขียน unit test บ้าง ยกมือหน่อย การันตีไหม ว่ารวมแล้วจะ work นะครับ coverage 100% ใช่ไหม ที่ไหนมีบ้างครับ coverage เราต้อง 100% ใช่ไหม ก็ 100% นะ แต่เขียนไม่ครบใช่ไหม เขียนโค้ดไม่ครบ requirement ถูกไหม เออเนอะ แต่เทส แต่ coverage 100% ก็มี bug ใช่ไหม ถูกไหม เออเนอะ ดังนั้น ตรงนี้แหละนะครับ คุณเขียน unit ปุ๊บ มันคือเร็วใช่ไหม แต่เราไม่การันตีว่ามันจะเวิร์กหรือเปล่า ดังนั้น ในการ deliver ซอฟต์แวร์

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

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

การทดสอบเป็นระดับของความเชื่อมั่น6:06

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

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

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

การทดสอบควรเป็นกิจกรรมต่อเนื่องตลอดกระบวนการพัฒนา7:11

หลายๆ ครั้งการทดสอบคือ phase นั่นหมายความว่าอะไรครับ ถ้านักพัฒนาบอกว่าเสร็จ ค่อยทดสอบ ถูกไหม ใครทดสอบ นักพัฒนาบอกว่าทดสอบเนอะ ในนี้นักพัฒนาใช่ไหม ทดสอบโค้ดตัวเองไหม ว่าเวิร์ก ทดสอบไหมครับ ทดสอบโค้ดตัวเองเนอะ ยกตัวอย่าง ตอนนี้เรามี feature ประมาณ 10 feature เนอะ แล้วเวิร์กบน production ไม่เคยมี bug เลยนะ เรากำลังเพิ่มอีก 5 feature เป็น 15 feature เนอะ คำถามคือ 5 feature ของเราเสร็จเมื่อไหร่ครับ คำว่าบอกว่า 5 feature นี้เสร็จคืออะไร 1 คือ deadline ใช่ไหม ถูกไหม จะถึงแล้ว ต้องส่งใช่ไหม เสร็จใช่ไหมครับ 2 คือเราทดสอบ 5 feature ไหมว่า work

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

การทดสอบที่ดีควรมีคุณสมบัติอะไรบ้าง8:56

แล้วอย่างที่บอกก็คือ เรื่องของการทดสอบที่ดีครับ 1 คือเร็ว

2 คือ อันนี้ยากมากครับ เราจะทดสอบแต่ละระบบอย่างไรครับ ให้เป็นอิสระแก่กัน เค้าเรียกว่า isolate หรือว่า independent คือเป็นอิสระ 3 คือ การทดสอบครับ หลายๆ ครั้ง repeat ไม่ค่อยได้ครับ ใช่ไหม รันตอนเช้าผ่านใช่ไหม ตอนสาย อุ๊ย ทำไมไม่ผ่าน ตอนบ่ายผ่านซะงั้น ตอนเย็นไม่ผ่านอีกครับ แล้วรันบนเครื่องเราโอเค เครื่องเพื่อนไม่โอเคครับ มีเหมือนไม่มีใช่ไหม ไอ้ตรงนี้ก็เรื่องของ repeat ทำได้ไหมครับ แล้วอีกเรื่องนึงคือเรื่องของอะไรครับ แต่ละ case ครับ เราทำการ verify ครอบคลุมรึเปล่าครับ ไอ้ตรงนี้เป็นมุมมองที่เกิดขึ้น ที่เราจะต้องวิเคราะห์ หรือว่าเลือกที่จะทำครับ เพราะเป็นอย่างนี้แล้ว เทสที่ดีเป็นยังไงครับ สิ่งที่อยากให้ดูต่อคือ แล้วคุณเทสตอนไหนครับ ไม่รู้นะ คุณจะเขียนโค้ดแบบไหน มันจะมีคำว่า test first แล้วก็ test last

การเลือกระหว่าง Test First และ Test Last10:01

นะครับ 2 คำนี้ไม่รู้แปลเป็นไทยว่าอะไรเนาะ แต่ผมแปลแบบนี้ นั่นหมายความว่าอะไรครับ คุณคิดเนาะ คุณทำก่อนเนาะ คือเขียน code ก่อน แล้วค่อยคิดว่าจะ test ยังไง กับคิดก่อนว่าจะ test ยังไง แล้วค่อยเขียน code ปกติเราทำแบบไหนครับ หรือเขียนให้เสร็จก่อนใช่ไหม แล้วค่อยมาดูว่า โอเค เสร็จแล้ว ค่อยคิดว่าจะทดสอบอย่างไร เราจะพบว่าอะไรครับ มันยากเนาะ พอยากปุ๊บ อะไรที่ยากเราจะบอกว่า เดี๋ยวก่อนใช่ไหม เดี๋ยวก่อนปุ๊บก็เพิ่ม feature ไปเรื่อย เดี๋ยวๆ สุดท้ายคืออะไรครับ โอเค ผ่านไป 1 เดือนหรือ 2 เดือน ค่อยให้ทดสอบละกัน แล้วมาคิดกันว่าอะไรครับ จะทดสอบกันอย่างไร นะครับ ก็ชิบหายแน่นอนใช่ไหม เออเนาะ ยิ่งอะไรครับ code เมื่อเวลาเนาะ

เมื่อ code เกิดขึ้นมาแล้วอะไรครับ เราปล่อยไว้นาน ปล่อยไว้นานๆ แล้วค่อยมาทดสอบ มันจะทดสอบยาก

นะครับเนาะ แต่อะไรครับ เขาบอกว่าคน IT เนาะ ชอบอะไร มักจะไม่ทำ ถูกไหม นะครับ เกลียดอะไร มักจะทำ ไปดูได้ครับที่บริษัทเรานะเนาะ เราเกลียดอะไรครับ เราเกลียด bug ใช่ไหม แต่เราสร้างทุกวัน ถูกป่ะ เราอยากจะ deploy ทั้งวันใช่ป่ะ ตอนไหนก็ได้ แต่ลองดูนะครับ เราส่วนใหญ่หลายๆ ที่ชอบ deploy ตอนไหน หลังเที่ยงคืนใช่ป่ะ แล้วก็อะไรครับ ก่อน 6:00 น. ทำไมอ่ะ ไม่มีใครใช้ เราไงใช้อยู่ เราไม่ใช่คนใช้หรอก ถูกป่ะ นะครับ ดังนั้น นี่คือมุมมองเนาะที่ผมอยากให้เห็นว่า คุณจะ test first หรือ test last มันคืออยู่กระบวนการคิด ถูกป่ะ นี่คือไอเดียที่ผมให้เห็นเนาะ ดังนั้น เวลาที่เราจะเริ่มกระบวนการพัฒนาเนี่ย สิ่งที่เกิดขึ้นคือเราต้องรู้ก่อนว่าเราทำอะไร คำว่าทำอะไรคือต้องเขียนออกมาให้ชัดว่าอะไรครับ สุดท้ายแล้วจะต้องเกิดอะไรขึ้นบ้าง จากนั้นคุณค่อยลงมือทำ

นี่คือมุมมองที่ผมอยากให้เห็นก่อน เพราะเป็นแบบนี้ ในแง่ของการพัฒนา software เนี่ย

การพัฒนาแบบ Iterative และ Incremental12:03

ที่บอกว่าเราเขียน 1 เดือนแล้วค่อยมาทดสอบเนี่ย น่าจะต้องเริ่มเปลี่ยนวิธีการใหม่เนาะ หนึ่งในวิธีการนั้นที่ผมชอบใช้คือ iterative and incremental ผมไม่รู้นะใครจะใช้อะไร แต่ผมบอกว่า ผมโฟกัสที่การส่งมอบ feature ไม่ว่าคุณจะเขียน unit test กี่เคส เป็นหมื่นเคส แสนเคส นั่นคือเรื่องของคุณถูกป่ะ แต่สุดท้าย feature คุณต้อง meet ตาม requirement ถูกป่ะ ดังนั้น สิ่งที่เกิดขึ้น เราควรจะต้องค่อยๆ สร้างถูกป่ะ

แต่ละ feature ไม่ว่าเล็กหรือใหญ่เนาะ บางคนเรียกว่า story บางคนเรียกว่า flow ก็ว่าไป feature เสร็จ คำว่าเสร็จคืออะไรครับ 1. เขียน code เสร็จถูกป่ะ 2. ทดสอบเสร็จ ถึงจะบอกว่าเสร็จ เค้าเรียกว่าอะไรครับ done และ done ส่วนใหญ่จะเป็น done และ undone ถูกป่ะ คืออะไรครับ เขียน code เสร็จ ที่ไหนมี board ทำงานบ้างครับ มี coding แล้วก็ ready to test, prepare to test, waiting to test แล้วก็ tested ใช่ป่ะ

คุ้นๆ มั้ย แสดงว่างานที่เราเขียนแล้ว งานที่เราทำไม่เคยเสร็จเลยครับ เพราะอะไรครับ waiting to test ทำไมคนทำไม่ test อ่ะ

ถูกป่ะ แล้วเราบอกว่าเสร็จได้ไง แสดงว่าเรากำลังโกหกกันใช่ป่ะ หรืออะไรฮะ ถ้าแน่จริงหา bug ให้เจอ เดี๋ยวแก้ให้ใช่ป่ะ ใครเป็นบ้างฮะ ถ้าแน่จริงใช่ป่ะ เราสายซ่อนใช่ป่ะ นะฮะ ซ่อนเก่งนะ เออเนาะ แต่ถ้าเจอปุ๊บ อ๋อ น่าจะมีปัญหานิดหน่อย อธิบายไม่ได้ด้วยนะฮะ เออเนาะ คนอะไร debug ไม่เป็นแต่โค้ดที่เราเขียนเองนะฮะ เออเนาะ ใครเป็นบ้างฮะ โค้ดชุดนี้ใครเขียน เรา แต่เราไม่รู้ว่ามันทำงานอย่างไร ถูกป่ะ เออเนาะ ดังนั้นไอ้ตรงนี้ครับเนาะ พอ feature เพิ่มขึ้นเรื่อยๆ ด้วย นะครับ

การทดสอบแบบ Feature-based และการพัฒนาทีละขั้นตอน13:51

เราจะค่อยๆ ทำไป เค้าเรียกว่า feature base เนาะ

feature by feature เดินไปข้างหน้าทีละก้าว นะครับ เราจะไปข้างหน้าโดยที่ไม่ย้อนกลับถูกป่ะ ไม่ห่วงหน้าพะวงหลังนะครับ นะ นี่คือหลักการที่ผมให้เห็นเนาะว่า เราจะทำแบบนี้นะครับเนาะ แต่ประเด็นคือ การทำแบบนี้ไม่ได้บอกว่า ต้องเป็น manual หรือ automation นะครับ ประเด็นคือคุณทำแบบนี้ซ้ำๆ ได้หรือเปล่า นะครับ ถ้าทำซ้ำไม่ได้ นี่คือสิ่งที่ คุณจะต้องเริ่มทำ ยกตัวอย่าง

ผมให้เห็นสไลด์ชุดนี้ ตัวนี้ dev กับ test ทุกที่ส่วนใหญ่จะมี dev ใช่ไหม แล้วก็มี tester QA ถูกไหม หรือใครก็ตาม ประเด็นคือ 2 คน เค้าเรียก 2 กลุ่มนี้ จะมี effort เท่าเดิมเสมอ ใช่ไหม ถ้าโปรเจคไม่ทันทำไง อยู่ดึกหน่อยนะน้อง ใช่ไหม เสาร์อาทิตย์เข้าได้ไหม อะไรประมาณนี้ เดี๋ยวสักพักเดี๋ยวพี่หาคนเพิ่มให้ อะไรประมาณนี้ ใช่ไหม อันนี้คือมุมมองที่เกิดขึ้น แต่ประเด็นคือ effort เท่าเดิม สิ่งที่เปลี่ยนแปลงคือ feature ที่โตขึ้น คำถามก็คือ feature ที่โตขึ้น เราทดสอบครบไหม ส่วนใหญ่ไม่ครบ เค้าเรียกว่า unstable คือ feature ที่ไม่เสถียรเลย ทำงานได้บ้างไม่ได้บ้างก็ว่าไป พอเวลาผ่านไปเรื่อยๆ เกิดอะไรขึ้น ไฟไหม้ถูกไหม เพราะอะไร เรา late มันไปเรื่อยๆ นะครับ ดังนั้น สิ่งที่ตามมาคือ ถ้าเราบอกว่าค่อย incremental ไปเรื่อยๆ การทดสอบน่าจะเริ่มเข้ามา automation นี่คือมุมมองผมให้เห็น นี่คือธรรมชาติ นะครับ แต่หลายๆ ที่ ชอบฝืนธรรมชาติไหม ถูกไหม ก็ต้องลองดู เพราะเป็นแบบนี้ นะครับ เราก็จะเอา automation เข้ามาใช้เรื่อยๆ แต่ automation คุณจะทำเลเวลไหน

อันนี้คือกลับไปที่ความเชื่อมั่นอีกแล้ว

การทดสอบใน JavaScript: เครื่องมือและวิธีการ15:49

ว่า test เลเวลไหนที่คุณจะทำ โดยที่ การ test นะครับ ไม่ว่าจะเลเวลไหนก็ตาม นะครับ ทุกครั้งนะครับ เราเป็นนักพัฒนา ทุกครั้งที่คุณ add หรือ commit หรือว่า push คำถามคือ commit ของคุณ คุณผ่านการ verify ไหม หรือเอาง่ายๆ คือบนเครื่อง git add นะครับ git add แล้วไม่ใส่ commit ใครไม่ใส่ commit บ้าง commit message คงต้องใส่ 1 commit คงไม่มี 100 change ใช่ไหม คงไม่มี ใช่ไหม มีใครเป็นบ้าง 1 commit มี 100 ไฟล์ คงไม่มีเนาะ แล้วมีคำว่าอะไรครับ commit นั้นชื่อว่า update เพราะอะไรครับ เป็นค่า default ของเครื่องมือใช่ไหม คุ้นๆ มั้ย อันนี้คงไม่มีเนาะ ดังนั้น พอเราทำ test ปุ๊บเนี่ย สิ่งที่เกิดขึ้นคือมันต้องเกิดอะไรครับ เค้าเรียกว่า continuous testing ทั้งบนเครื่องเราหรือเราจะมีพวก CI/CD เนาะ ที่ทำให้เราเห็นอยู่ตลอดเวลานะครับ นี่คือหลักการ

กลับมานะครับ นี่คือ testing เนาะ กลับมาที่ JavaScript ประเด็นคือ อ้าว แล้ว JavaScript มีอะไรบ้างเนาะ เมื่อกี้มีเขียนอะไรนะ โอ้โห test เยอะเลยใช่ไหมครับ ก่อนนี้นะครับ มาดูว่าที่ผมทำมีอะไรบ้างนะครับ ใน JavaScript มันโหดร้ายป่าเถื่อนมากนะครับ เพราะว่าอะไรครับ library มันเยอะนะครับ คำถามคือเลือกอะไร เอาที่สบายใจนะครับ ผมก็เลือกให้ไม่ได้นะครับ มันอยู่ที่รสนิยมถูกไหม แต่นี่คือสิ่งที่ผมใช้เนาะ อันนี้ผมเอามาจาก guideline จากที่นี่นะครับ อันนี้ยังขาดภาษาไทยเนาะ ใช่ไหม ใครเคยเข้ามั้ยครับอันนี้ เคยเนาะ ใช่ไหม

เข้าไปปุ๊บก็ปิดใช่ไหมนะครับ แอดบุ๊คมาร์คไว้ซักหน่อย แล้วก็ปิดไป แล้วก็ดูว่า คือเหี้ยอะไรวะ ใช่ไหม ประมาณนั้นนะครับ แต่ผมให้เห็นว่า อันที่นี่นะครับ ผมก็ reference เนาะ แล้วเอามาใช้คือ ในตัวอะไรครับ ของ JavaScript เนี่ย มันมีทั้ง frontend และ backend เนาะ มันมีบาง library ใช้ได้ทั้ง front และ back บาง library ใช้ได้แค่ front บาง library ใช้ได้แค่ back นะครับ มาดูว่าสิ่งที่ผมใช้เนาะ มีอะไรบ้าง ยกตัวอย่างเนาะ front กับ back คุยกันประมาณนี้

back จะโหดร้ายเนาะ front ก็จะกลางๆ หน่อยใช่ไหม จะแยกกันลักษณะนี้นะครับ

ความท้าทายในการทดสอบระบบ Frontend และ Backend แยกกัน17:58

พอเป็นอย่างงี้ปุ๊บ คำถามก็คือ เราเทสไงวะ ใช่ไหมนะ อันนี้เอาแบบ minimal เนาะ นี่คือ happy meal เนาะ ชีวิตจริงนรกกว่านี้ใช่ไหม ประเด็นคือมีแค่นี้ ทดสอบไงครับ คนจริงก็นี่เลย ง่ายตายใช่ไหม

มี frontend กับ backend ใช่ไหม ก็ deploy ทั้งคู่ไง แล้วก็ทดสอบไง ใช่ไหมนะ คำถามคือมึงแยก front กับ back ทำโล่อะไรใช่ไหม อยู่คนละ repo อีกใช่ไหม หรือว่า mono repo นะ หรือ poly repo เดี๋ยวนี้ ใช่ไหม เดี๋ยวนี้มี microservice แม่งแยกเลยครับ มี 100 service แยก 100 repo ใช่ไหม นะครับ แล้วรวมกันยังไง แล้วแต่เวรแต่กรรมใช่ไหม ก็ว่ากันไป ประเด็นคือ อันนี้คือง่ายที่สุด ประเด็นคือ ทดสอบแบบนี้ดีไหม ดีที่สุดครับ เพราะอะไรครับ เลเวลของความเชื่อมั่นสูงมาก ถูกไหม แต่ความสนุกคือ คุณต้องทำอะไรบ้างถูกไหม ต้อง setup external system ใช่ไหม setup database, deploy backend, deploy frontend ทดสอบซ้ำได้ไหม ขอเวลาสักอาทิตย์ รีเซ็ต data หน่อย แล้วก็ทดสอบใหม่ ใช่ไหม มันทำอะไรครับ การทดสอบ นะครับ ไอ้ที่ 1 2 3 4 5 นี่คืออะไรครับ โปรเซสปกติ

แล้วเราก็ทดสอบ อาจจะเป็น manual หรืออะไร เอาเครื่องมือมาใช้ถูกไหม เครื่องมือก็อะไร นี่เลยใช่ไหม 3 ทหารเสือใช่ไหม สาย frontend นะ ที่บอกว่าอะไรครับ เค้าเรียกว่า frontend developer ต้องมีอะไรครับ 2 หน้าจอใช่ไหม หน้าจอนึงเอาไว้อะไรครับ เปิด test ใช่ไหม หน้าจอนึงเขียนโค้ด เซฟปุ๊บ test ออโต้ใช่ไหม ไม่ใช่นะครับ อีกหน้าจอยังเอาไว้ดูผลแค่นั้นเอง แค่ feature ที่เรากำลังพัฒนา แล้ว feature อื่นล่ะ ปล่อยมันไป อันนี้คือสิ่งที่เกิดขึ้น ดังนั้น เพราะเป็นแบบนี้ คำถามคือ ความเชื่อมั่นสูงครับ นะครับ ความเร็วล่ะ

ต้องคุยกัน ที่ผมใส่สีเขียวผมก็ไม่รู้ เพราะแต่ละคนไม่เหมือนกัน isolate คือเป็นอิสระไหม คำตอบคือไม่ใช่แน่นอนใช่ไหม เพราะอะไรครับ คุณต้อง setup ทุก element นะครับ repeat ได้ไหม อันนี้ก็เป็นเรื่องเป็นราว ว่าถ้าเราทำ end-to-end test repeat เราต้องทำตั้งแต่เนิ่นๆ นะครับ แต่ถ้าคุณมาทำช่วงท้าย น่าจะมีประเด็น นะครับ อันนี้คือไอเดียถูกไหม นะครับ แล้วประเด็นคือ การ test ทุกเลเวลนะครับ มันจะมีสิ่งนี้ คือ flaky test ใช่ไหม นะครับ คืออะไรครับ ไม่ได้เปลี่ยนอะไรเลย แต่รัน test ซ้ำ ผ่านบ้าง ไม่ผ่านบ้าง ใช่ไหม พอไม่ผ่านปุ๊บนะครับ มันมี feature นึง ignore ใช่ไหม ignore ไปเรื่อยๆ จากมี 1,000 เคส ignore ไป ignore มา เหลือ 100 เคส นะครับ เพื่อให้อะไรครับ เพื่อให้ test ผ่านก็ว่าไป ซึ่งตรงนี้แหละครับ จะเป็นปัญหา ของ dependency ของการทดสอบระบบเรา ที่มีประเด็นนะครับ ดังนั้น

การแยกทดสอบ Frontend และ Backend อย่างอิสระ20:54

ถ้าเราทำ end-to-end test แล้วมีปัญหาเหล่านี้นะครับ เราก็ต้องปรับปรุง หรือมีทางอื่นมั้ย ลองดูนะ ไม่ใช่บอก end-to-end ไม่ดี end-to-end ดีที่สุดนะครับ แต่เราทำซ้ำได้มั้ย มีความน่าเชื่อถือรึเปล่า ดังนั้นผมต้องการอะไร ความน่าเชื่อถือ แล้วก็อะไร feedback นะครับ ที่เร็ว ดังนั้นทำไงดี แยกมั้ยนะครับ

แยก 2 ส่วนออกจากกันใช่ป่ะ ทำอะไร ทำให้เราสามารถทดสอบอะไร front-end และ back-end โดยที่ไม่ต้องเกี่ยวข้องกัน คืออะไร ก่อนที่คุณจะมา integrate กัน แยกกันให้รอดก่อนมั้ย ถูกป่ะ เพราะอะไร ถ้าต่างฝ่ายต่างอะไร แยกกันแล้วทดสอบแล้ว work เอามารวมกันอาจจะ work ถูกป่ะ แต่ถ้าเราไม่เคยทดสอบ 2 ฝั่ง เอามารวมกันเลย ความไม่ work สูงมากๆ นะครับ ดังนั้น isolate คือแยกกัน ทำไงดี กลายเป็นอะไร front-end กับ back-end หลายๆ คนอาจจะถามว่าแล้วเราแยก front กับ back ทำไมวะ ใช่ป่ะ แล้วมันจะเกิดคำถาม ทำไมเราต้องแยกด้วย ทำไมไม่รวม ใช่ป่ะ ดังนั้น front-end test กับ back-end test isolate กันทำยังไง ถูกป่ะ front-end คุณออกไปอะไร back-end ใช่ป่ะ ผ่าน API ผ่าน REST gRPC tRPC อะไรก็ว่าไป ถูกป่ะ whatever นะครับ

คุณต้องจำลองมั้ย ถูกป่ะ จำลองยังไง นี่ ชีวิตมาแล้ว เครื่องมือสาย front-end ใช่ป่ะนะครับ ไม่ว่าคุณจะใช้อะไร Cypress Playwright ใช่ป่ะ Selenium ด้านหลัง คุณสามารถ mock แหลกลานได้ใช่ป่ะนะครับ ด้วยเครื่องมือต่างๆ เหล่านี้ หน้าตาเป็นยังไง ผมให้ดู นี่คือตัวอย่างของ Playwright นะครับ ในนี้มีใครใช้ Playwright บ้าง ผมเพิ่งอะไร migrate จาก Cypress

การใช้ Playwright สำหรับการทดสอบ Frontend22:42

มา Playwright ประมาณ 4 โปรเจคแล้วนะครับ ถามว่าทำไม migrate อยาก migrate แค่นั้นเอง ไม่มีอะไร แล้วมันแค่เร็วขึ้นแค่นั้นเอง นะครับ back ได้มั้ย ก็ไม่ค่อยมีประเด็นนะครับ อันนี้คือ ผมลองอะไร test ด้วย Playwright เสร็จแล้วอันนี้คือเปิดด้วยอะไร Chromium นะครับ จากนั้นก็อะไร นะครับ อันนี้ผมก็ mock API ของตัว front

ด้วย Playwright ลองดูนะครับ จากนั้นก็เขียน test case นะครับ ซึ่งตรงนี้ผม hard code ก็แยกออกมา อันนี้คือเป็นการ refactor ปกติอยู่แล้วถูกป่ะ ว่ามันรวมๆ เราคนจริงเราคงไม่ hard code ใช่ป่ะ เราคนจริงก็แยกออกมาว่าจะแยกแบบไหนก็ว่ากันไปนะครับ พอเป็นแค่นี้ เราสามารถที่จะทดสอบฝั่ง front end โดยการเปิด browser แล้วเมื่อไหร่ก็ตามยิงไปหลังบ้านจำลอง ใช่ป่ะ เพื่อให้มั่นใจว่า behavior ของฝั่ง front end โอเคนะครับ จากนั้นทำไงดี ฝั่ง front end น่ะมันจะมี snapshot ใช่ป่ะ Playwright ก็ snap เลยใช่ป่ะ แล้วเอารูปมาเอามา compare แล้วเซตพวก threshold พวก difference ต่างๆ ได้ว่า จะให้มันต่างกันกี่เปอร์เซ็นต์ก็ว่าไป แล้วสามารถ snap ได้ทั้งหน้าหรือว่า per component ก็ได้นะครับ อันนี้คือฝั่งของ front end test โดยที่ยิงจริงมั้ย ไม่ยิงจริง แต่เราแก้โค้ดฝั่ง front end มั้ย ไม่ได้แก้นะครับ นี่คือหลักการที่เกิดขึ้น ซึ่งตรงนี้มันทำให้เร็วขึ้นมั้ย isolate แล้วถูกป่ะ repeat ได้นะครับ แต่แน่นอนว่าความเชื่อมั่นดรอปลง เห็นป่ะนะครับ

อันนี้คือมีเป็น trade off นะที่ผมอยากให้เห็นนะครับ หรือ back end ก็เช่นกันใช่ป่ะ คุณก็ต้องจำลองว่า

การทดสอบ Backend ด้วย Supertest และการ Mock24:21

back end เช่นเราเป็น REST API ถูกป่ะ REST API เราต้องยิงด้วยอะไร นี่เนาะ Postman เนาะ ยาสามัญประจำบ้านใช่ป่ะ หลายๆ คนใช้นะครับ มี SuperTest Cypress ก็มี Playwright ก็มาถูกป่ะ จะจำลองหลังบ้านนะครับ มีพวกอะไรบ้าง พวก node mock HTTP mock อะไรอย่างเงี้ย บางคนใช้ Docker เลย ถูกไหมครับ หรือว่า test container ก็ว่าไปนะครับ นี่คือฝั่งของ backend ที่เราสามารถทำได้ ตัวอย่างคือผมใช้ Supertest ยิง start Express ขึ้นมาตู้มนะครับ จากนั้นก็อยากให้มันยิงออกไปไหน mock มันเลย mock ใช่ไหม

เห็นไหม mock ยิงไปที่นี่ใช่ไหม ไม่ให้ออก return ค่านี้กลับเลย อยากให้ช้าใช่ไหม อยากให้ fail mock มันเลยนะครับ เราต้องแก้โค้ดไหม ไม่ต้องแก้โค้ด เพราะเรารู้อยู่แล้วว่ามันออกไปที่ไหนถูกไหม ให้มัน return กลับเลยนะ บางคนไปใช้ JSON ไฟล์ จากเรียก HTTP client ใช่ไหม ไปเรียกจาก Axios เปลี่ยนเป็นอ่านไฟล์ มันเหมือนกันไหมพฤติกรรม HTTP กับ read ไฟล์ ไม่เหมือนกันถูกไหม ดังนั้นเราทำแบบนี้ได้ แล้วก็เขียน test สังเกตนะ นี่คือ front กับ backend test ถูกไหม ซึ่งแต่ละส่วนเป็นอิสระแก่กัน

พอเป็นอิสระแก่กันปุ๊บ คำถามคือความเชื่อมั่นเป็นอย่างไร โอเคไหมนะ แน่นอนคือความเชื่อมั่นที่ผมบอก มันดรอปลงถูกไหม แล้วหนักกว่านั้น คำถามตามมาคือคุณแยก front กับ backend ใช่ไหม เคยเจออันนี้ไหม แยก front กับ backend แล้ว สิ่งที่ตามมาคือ เมื่อกี้ mock เยอะใช่ไหม mock bubble mock เยอะชิบหาย ถูกไหม กลับไปที่ architecture คุณเลย มันจะแยกกันอะไรกันเยอะขนาดนั้น ถูกไหม อย่าคิดทำแล้วค่อยมาหา กลับไปที่ root cause นะ หนักกว่านั้น นี่เลย เรามี front กับ backend ใช่ไหม วันดีคืนดี backend เปลี่ยน front รู้ไหม? ใครเป็นบ้าง ในทีมยังพอทน ต่างทีมหรือต่างบริษัท มันแก้แล้วเอาขึ้น production เพิ่งมาบอกว่า อ้อกูแก้ ถูกไหม แล้วเรากำลังขึ้นโปรดักชั่นทุกอย่างผ่าน UAT มาเรียบร้อย ใครเป็นบ้างครับ ทุกอย่างมาเจอรวมกันเนาะ นะครับ สิ่งที่เกิดขึ้นคือมันเกิดอะไรครับ breaking ถูกป่ะ นะครับ ตอนที่เราขึ้น เรารู้มั้ย รู้ตอนไหน ถูกป่ะ เออ นะ ดังนั้น สิ่งที่ผมไม่เห็นเนาะ อีกตัวนึง test ของอะไรครับ

การใช้ Contract Testing เพื่อรักษาความสอดคล้องระหว่าง Frontend และ Backend26:42

ฝั่งของ JavaScript ที่ผมใช้นะครับ ผมใช้ contract test แปลเป็นไทยคือ สัญญาว่าจะ test นะครับ เออเนาะ นะ อันนี้แปลเป็นไทยนะ ไม่ใช่หรอก ผมมั่วนะครับ ดังนั้น ฝั่ง front-end กับ back-end หรือใดๆ ก็ตามเนาะ จับมือกันแล้วใช่ป่ะ ปกติเราจับมือกันด้วยอะไรนะ API spec ใช่ป่ะ ถูกป่ะ ใครมีบ้างครับ ใช้อะไร Swagger OpenAPI ใช่ ใครใช้บ้างครับ หลายๆ คนใช้เนาะ แต่เจนเอาใช่ป่ะ เจนเอาคือไม่ใช้ เพราะอะไรครับ เค้าอยากให้มี ก็เจนมันมา ใช่ป่ะ เพราะถ้าไม่มี ส่งไม่ได้ ใช่ป่ะ ใครเป็นอย่างงั้นบ้างครับ ยกมือหน่อย อ่า โอเค นะครับ เพราะฉะนั้นเหมือนไม่มีแล้วกัน นะ เพราะอะไรครับ เพิ่มโค้ดมาทัดเดียวก็ได้แล้วอะ ใช่ป่ะ เออเนาะ ดังนั้น ตรงนี้ครับ จาก API spec เราจับมือร่วมกันนะครับเนาะ

ดังนั้น พอจับมือกันปุ๊บนะครับ สิ่งที่ใช้เนาะ ผมใช้ Pact เนาะ จับมือกัน จะเป็นแบบนี้เนาะ จับมือด้วย API spec นะ พอ สิ่งที่ผมทำคืออะไรนะครับเนาะ ตัว Pact นี่ นะครับเนาะ จาก API spec เนาะ ที่ผมเขียนแบบนี้ สามารถแปลงออกมานะครับ ในรูปแบบของ contract ได้ ประเด็นคือ contract คืออะไรครับ ระหว่าง front-end กับ back-end เนาะ เค้าเรียกว่า consumer กับ provider นะครับเนาะ จะต้องอะไรครับ จะต้องจับมือกัน แล้วแปลง spec ตัวนี้ นะครับ มาเป็นตรงกลางนะครับเนาะ จะต้องอะไรครับ generate ออกมาเป็น contract เนาะ เป็นอะไรครับ เหมือนสัญญาเนาะ ระหว่าง 2 ส่วนนะครับเนาะ การเขียนนะครับ อันนี้คือผมให้ดูตัวอย่างเนาะ นะครับว่า กำหนด consumer กับ provider นะครับเนาะ ว่า เฮ้ย provider ชื่ออะไร consumer ชื่ออะไร คือคนเรียกกับคนถูกเรียก จากนั้น เอา spec เมื่อกี้ครับ มาสร้างเป็นอะไรครับ มาสร้างเป็น contract

ด้วย Pact นะครับ แต่ละภาษาไม่เหมือนกัน แต่ละ framework ไม่เหมือนกันเนาะ แต่ อันนี้คือเหมือน spec เลยเมื่อกี้ นะครับ จากนั้น นะครับ generate อะไรครับ contract ออกมา อันนี้คือคำสั่งเนาะ ในการ generate contract แล้วก็ test ฝั่งของ consumer จะได้ contract หน้าตาประมาณนี้ นะครับ เป็นไฟล์ของ contract นะครับ ดังนั้น ทุกครั้งที่เราไปเรียกใครก็ตาม จะมีการจับมือร่วมกัน สร้าง contract คือสัญญาขึ้นมา ทั้ง success case และ fail case ซึ่งสัญญานี้จะไม่อยู่ที่ใดที่หนึ่งนะครับ จะเอามาไว้ตรงกลาง ผมเรียกว่า broker Pact จะมี broker ให้

จะเก็บทุกสัญญา โอเคไหมครับ จากนั้น

ประโยชน์ของ Contract Testing และการใช้ Pact Broker29:04

พอเก็บทุกสัญญาปุ๊บ แน่นอนคือวันดีคืนดี backend เปลี่ยนใช่ไหม backend เปลี่ยนปุ๊บ รู้ไหมว่าสิ่งที่เปลี่ยนกระทบใครบ้าง นะครับ ถ้าไม่รู้ มาดึง contract จาก Pact ที่มีคนใช้ โอเคไหมครับ ดึงไปปุ๊บ ทุกสัญญา เอามา verify

verify ทุก contract เราจะเห็นว่า contract ไหนผ่านไม่ผ่าน แล้วที่สำคัญคือเอา contract มารวมกันใช่ไหม มันมี consumer กับ provider ใช่ไหมครับ เอามา generate เป็น dependency graph ว่าใครเรียกใคร ตอนนี้ของเรา ใครเรียกใครรู้ไหม หรือต้องไปดูใครบอก เดี๋ยวเราไปขอดู log ก่อน ว่าใครเรียกเราบ้าง ใช่ไหม มีไหม คงไม่มีนะ ใช่ไหม tail -f grep อะไรสักอย่าง คงไม่มีใครทำนะ ใช่ไหม ดังนั้น เราจะเห็นแบบนี้คือ dependency graph ใช่ไหม นะครับ จากนั้นก็ verify ถูกไหมครับ เราก็จะรู้ว่า contract ไหน ที่มีการเปลี่ยนแปลง กระทบใครบ้าง นี่คือ side effect นะ

ซึ่งพอผมมี test 3 เลเวลแบบนี้ ลองดูนะครับ confidence ความเชื่อมั่นเราดีขึ้นไหม ลองดูนะครับ ความเชื่อมั่นดีขึ้นไหม แต่ละส่วนแยกเป็นอิสระจากกัน แต่ยังคุยกันถูกไหม แต่อยู่ที่ว่าจะคุยกันแบบจริงๆ หรือเปล่า หรือเราจะมีตัวกลาง ที่ทั้ง 2 ฝั่งเชื่อมั่น นะครับ อันนี้คือมุมมองที่เกิดขึ้น และสุดท้ายมันคือเรื่องของ repeat คือทำซ้ำ นะครับ

ความสำคัญของการทดสอบทางธุรกิจและการเพิ่มมูลค่าโดยนักพัฒนา30:37

ดังนั้น นี่คือการ test ณ ฝั่งไม่ใช่ developer test เลยนะครับ การ test เหล่านี้เป็น business test ล้วนๆ ครับ เพราะว่า business test มันคือการบอกว่าแต่ละ feature แต่ละ function ส่งมอบได้ไหมถูกไหม meet requirement หรือเปล่า แต่นักพัฒนาไม่ได้หยุดอยู่แค่นี้ นักพัฒนาบอกว่าเราต้อง add value เข้าไปใช่ไหม นะครับ เพราะเราเป็น professional ถูกไหม เราจะทำแบบกระดาษแค่นี้ได้ไง ดูน้อยเกินไป เราต้องโค้ดทุกบรรทัด นะครับ โค้ดทุกบรรทัด ทุกอย่างของเรา เราต้องเชื่อมั่นถูกไหม จะไม่มีโค้ดบรรทัดไหนเลยที่เราไม่ทดสอบ ใช่ไหมครับ มีมั้ย มีโค้ดท่านไหนบ้างที่เราก็อปเข้ามาแล้วมันรันได้ ก็ถือว่าจบ หรือมัน generate ให้แล้วรันได้ก็ถือว่าจบแล้ว ใครเป็นบ้างครับ ไม่เป็นเนาะ เพราะเราเป็น professional ถูกป่ะ ดังนั้น โค้ดทุกบรรทัดของเราต้องอะไรครับ ต้องเด็ดใช่ป่ะ ต้องทำงานได้ แล้วใครมาต่อโค้ดจากเราจะไม่ด่าเนาะ เหมือนเราไปด่าโค้ดของชาวบ้านใช่ป่ะ ที่เราไปแก้ไขว่า โค้ดใครวะ มีใครเป็นบ้างครับ พอไปดู commit ปุ๊บ โค้ดกูนี่หว่า ใช่ป่ะ มีมั้ย ไม่น่ามีเนาะ ไม่น่ามีหรอก โค้ดเราเราก็ต้องจำได้สิ ใช่ป่ะครับ

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

สรุปและคำแนะนำสุดท้ายเกี่ยวกับการทดสอบ31:57

ก็คือ คุณต้องรู้ว่าคุณจะ test ไปทำไมก่อนครับ

กลับไปคำถามแรกเนาะ มันช่วย business มั้ย มันช่วยเรามั้ย ถูกป่ะ จากนั้น คุณจะ test อะไร และหลังจากนั้น เมื่อไหร่คุณควรต้อง test นะครับเนาะ และ test อย่างไร นะครับ นี่คือสิ่งที่อยากให้เห็นแล้วก็อะไรครับ การ test ผมปิดด้วยสไลด์นี้นะ คือเราจะต้องเรียนรู้จากความอะไรครับ ผิดพลาด มันเลยเกิดคำนี้นะ bug driven development นะครับเนาะ ยิ่งเราเจอ bug บ่อย test เราจะอะไรครับ มากขึ้นเรื่อยๆ ถ้าใครไม่เจอ bug แสดงว่าอะไรครับ เราจะไม่มี test โอเคนะครับ ขอบคุณทุกคนครับผม อันนี้ โอ้เลยมา 2 นาที นะครับ โอเคนะครับ ขอบคุณทุกคนครับผม ใครมีข้อสอบถาม ระหว่างเค้ายังไม่ขึ้นมาเนาะ สอบถามได้นะ โอเค ใครมีคำถามมั้ยครับ ใครมีคำถามเกี่ยวกับ strategy BDD บ้างนะครับ BDD ครับ Bug driven development นะครับ

หรือมีพาร์ทไหนที่เกี่ยวกับการ testing ที่อยากจะสอบถามมั้ยครับ มีมั้ยเอ่ย ระหว่างเรารอ transition

ยังไม่มี ไม่มีนะครับ ขอบคุณครับผม โอเคครับ ขอบคุณมากเลยครับ ครับผม ขอเสียงปรบมือด้วยครับผม ครับ