We Love Bug Biz — 1/5 Saturdays Basic of Test Engineer Program.
จาก Developer หน้าโง่ๆ สู่การเทรนกระบวนการ test
หลังจากที่เขียน ‘Review การทำงาน 6 เดือน ที่ KPC’ ก็ไม่ได้เขียนอะไรอีกเลย วันนี้ก็เลยมีสิ่งดีๆ มานำเสนอ นั่นคือ ‘5 Saturdays Basic of Test Engineer Program’
ปัญหาในการทำงาน
เริ่มต้นของการไปเรียนโปรแกรมนี้พี่หนุ่มได้ให้ โจทย์มา 2 ข้อ
1. ปัญหาที่เกิดขึ้นในกระบวนการพัฒนาซอฟต์แวร์?
2. ปัญหาที่เกิดขึ้นในเรื่องที่เกี่ยวข้องกับการทดสอบซอฟต์แวร์
ของเน็ตก็มีปัญหาพื้นฐานทั่วๆ ไปเช่น เทสงานไม่ทัน data ไม่ครบ Requirement ไม่เคลียร์ แต่พอได้ไปฟังคนอื่นๆ มาบอกปัญหาของตัวเอง ก็มีหลายปัญหาซึ่ง พอได้ฟังจาก QA , Tester ส่วนใหญ่จะเป็นปัญหาที่ว่า Developer ไม่เข้าใจ Requirement หรือไม่เข้าใจ Business หรือมีบางที่ Developer เปลี่ยน function ให้ลูกค้าไปเลย (อันนี้พีค ฮ่าๆ) เป็นประสบการณ์ที่ดีนะ ได้รู้มุมมอง QA และปัญหาของเพื่อนๆ เพื่อนำมาพัฒนาทั้งตัวเราเองและทีมของเราให้พัฒนายิ่งขึ้น
Agile หรือ Mini Waterfall ?
ก่อนที่ไปเรียนก็เรียกได้เลยว่าไม่มีความรู้ทางด้าน Methodology Model เลย รู้จักแค่ Agile กับ Waterfall แต่พอหลังจากที่ไปฟังแล้วก็ได้รู้ว่า มันมีสิ่งที่เรียกว่า extreme programming (โอ้โหความรู้ใหม่สุดยอด) ในช่วงนี้ก็อึนๆ ตามไม่ค่อยทันงงกับ Time line แต่ละช่วง และในช่วงนี้ก็ได้เห็นความแตกต่างระหว่าง scrum กับ mini waterfall ก็ทำให้เห็นภาพของการทำงานสองแบบนี้ได้ชัดมากขึ้น
จากภาพจะเป็น ฟีเจอร์ที่ 1 เข้ามา Coding ส่งไปให้ QA เทส ระหว่างนั้นก็ทำงาน ฟีเจอร์ที่ 2 พอ QA เทส ฟีเจอร์ที่ 1 เจอ Defect ก็ต้องกลับมาแก้ ฟีเจอร์ที่ 1 อีกที แล้วก็ส่งให้เทสอีกครั้ง กว่าจะได้เทสเสร็จก็หมด ก็ใกล้หมด sprint บางฟีเจอร์ก็ไม่ได้เทสอีกครั้งเพราะว่าเสียเวลากับการแก้ Defect
Programmer กับการ Test
Developer หลายคนอาจจะคิดว่างานของชั้นแค่การ Code เท่านั้นทำไมต้องเทสด้วย เทสก็ต้องเป็นหน้าที่ของ Tester ซิ! ถ้ายังทำแบบนั้นกันอยู่ก็จะเป็นภาพบนจ้า ก็จะเป็น mini-waterfall แบบไม่มีสิ้นสุดไป เราสามารถลดปัญหาเหล่านี้ได้ด้วย การเทสค่ะ (อ่าวก็เทสอยู่ดี) แต่ไม่ใช่การเทสแบบ manual test จะเป็นการที่ Programmer เขียน Unit test ไม่จำเป็นจะต้องทำเป็น tdd (test driven development) ก็ได้ แต่ถ้าเราเขียน unit test ที่ครอบคลุม business requirement ก็ช่วยลดเวลาการ manual test ของ Tester ได้
จากที่เน็ตทำงานมาปีกว่าๆ ก็มีเขียน unit test (แบบโหด เอา test coverage ตั้ง 60% ฮื่อ) ด้วย เน็ตว่าเวลาส่วนที่เขียน unit test ไม่ได้ทำให้เสียเวลามากขนาดนั้น บางเคสใช้เวลาแค่ 2–3 นาทีแค่นั้นเอง มันไม่ได้ยากแล้วโปรแกรมเมอร์ก็สามารถเขียนได้
อ่านมาถึงตรงนี้หลายคนอาจจะเริ่มเลิกลั่กว่าเอ๊ะหรือว่าที่เราทำงานอยู่ใช้ mini waterfall กันนะ? จริงๆ ไม่ว่าจะเราจะใช้ scrum หรือ mini waterfall ถ้ามันอยู่กับทีมว่าทีมเราโอเคกับแบบนี้ ทำงานแบบนี้ไม่เหนื่อยเกินไป และสามารถส่งงานให้ลูกค้าได้ ตรงตามเวลา ทำงานได้ถามแผนก็ไม่เห็นเป็นไรเลยว่าเราจะเลือกใช้แบบไหน
ไม่ว่าทีมเราใช้ Methodology Model แบบไหน แต่เราส่งงานที่มีคุณภาพได้ตรงตามเวลาเน็ตว่านั่นมันก็ Success แล้วแหละ :)
