เนื้อหาหลักๆของบทความนี้ก็ตามหัวข้อเลยครับ เรามาดูกันว่าจริงๆแล้ว Software Quality Assurance ทำงานกันยังไง...? เอาเป็นว่าพูดถึง QA ก่อนละกันหลายคนอาจจะคุ้นกันบ้าง ที่หลายๆคนรู้จักก็คือ QA มีหน้าที่ตรวจสอบคุณภาพของ Product ต่างๆว่าได้ตรงตามที่ตกลงกันมั้ย จริงๆแล้วที่คนส่วนมากเข้าใจก็จะมีแค่นี้แหละครับ แต่บทความนี้จะมาลงลึกถึงหน้าที่ของ Software Quality Assurance ขอเรียกสั้นๆว่า Software QA ละกันครับว่าคนที่ทำงานตำแหน่งนี้เค้าทำอะไรกันบ้าง ป่ะเริ่มม...

        จริงๆก่อนที่ผมจะมาทำงานตำแหน่ง Software QA เนี่ย ผมเคยมีช่วงเวลาสั้นๆได้ไปฝึกงานตำแหน่ง Tester ด้วย อ้าววว...ละมันต่างกันยังไง 2 ตำแหน่งนี้ ไปอ่านบทความความแตกต่างระหว่าง QA และ Tester นี้ละกันนะครับ เดี๋ยวยาว 555 มันมีทั้งส่วนที่เหมือนและต่างกันซึ่งขึ้นอยู่กับองค์กรและ Product ที่รับผิดชอบด้วยแหละ มาลงรายละเอียดการทำงานของ Software QA ดีกว่าครับ

        สมมติว่าทางองค์กรมี Project มาให้ทำชิ้นนึง Flow การเริ่มต้นก็ต้องเริ่มมาจาก Product Development หรือ PD เป็นฝ่ายที่ไปเก็บ Requirement จากผู้ใช้มาเพื่อมาจัดทำ Condition ซึ่งก็จะมาแบ่งส่วนของงานเป็น MVP(Feature อย่างน้อยที่สุดของ Product ที่คุณสามารถใช้งานได้ ซึ่งบางองค์กรอาจจะมีการจัดการในรูปแบบอื่นนะครับ) ซึ่งส่วนแรกที่ได้รับงานมาทำเนี่ยเป็น MVP1 ส่วนของ Feature A ต้องทำไงกันบ้าง ง่ายๆตามรูปด้านบนเลย ซึ่งมีรายละเอียดประมาณนี้ครับ

• อันดับแรกเลย Grooming Requirement วิเคราะห์ Requirement เพื่อนำมาออกแบบการทดสอบ
• ต่อมาคือ Planning จะมีทั้งรอบ Planning ร่วมกับทีม Dev และ Planning เฉพาะในทีม QA โดยจะ Estimated Time ร่วมกับทีม Dev
• เมื่อ Grooming และ Planning เรียบร้อยแล้วมาถึงขั้นตอนที่สำคัญในการทดสอบนั่นก็คือการเขียน Test Case เพราะไม่ว่าเราจะ Test แบบ Manual Test หรือ Automated Test เราก็ต้องทดสอบตาม Test Case ที่เราสร้างและผ่านการ Review มาแล้ว
• ขั้นตอนต่อมา Define ID คือการกำหนด ID ของแต่ละ Element ส่วนของหน้า UI ให้กับทีม Dev เพื่อจะได้เข้าใจตรงกันระหว่าง Sofeware QA และ Dev ว่าแต่ละ Element บนหน้า UI มี ID เป็นอะไร ขั้นตอนนี้อาจจะมีหรือไม่มีก็ได้ แต่ที่ทางทีมเรามีเพราะว่าต้องการลดระยะเวลาการทำงาน เพราะเมื่อมีความเข้าใจตรงกันแล้วว่าแต่ละจุดชื่อ ID อะไรทางทีม Sofeware QA ก็สามารถเขียน Test Script พร้อมกับทีม Dev ที่เริ่ม Implement feature นั้นๆเลย ตอนที่ถึงเวลาส่งงานตามที่ Estimated ไว้ก็จะได้ Run และใช้เวลา Refactor Test Script อีกนิดหน่อยซึ่งจะใช้เวลาน้อยกว่าเริ่มเขียน Test Script หลังจาก Dev Implement เสร็จ
• มาถึงเวลาเริ่มทำ Automated Test เขียน Test Script ใน Case ที่เรา Planning กันมาว่าเขียนแล้วคุ้ม ส่วนเคสไหนที่เขียนแล้วทดสอบเพียงครั้งเดียวหรือ Case ที่ผลลัพธ์ที่ได้มาไม่คุ้มกับการเขียน Test Script เราก็จะ Manual Test ในระหว่างนี้เราก็มีการ Review Test Script ในทีมเรื่อยๆ

photo credit : https://www.besthostingpro.com/wp-content/uploads/2018/06/rr.png

• ต่อมา Dev ส่ง Local site มาให้เราทดสอบเราก็ได้ลอง Run Test Script ที่เรา Implement มาละแต่มันจะเกิดปัญหาเรื่อง Element ไม่ตรง Fail เพราะหา Element ไม่เจอบ้างซึ่งช่วงเวลานี้เราก็จะทำการ Refactor Test Script เพื่อให้ Case ที่ Fail ไม่ได้มาจากความผิดพลาดของ Test Script เรา
• เมื่อ Refactor เรียบร้อยเราก็มา Run Test Script พร้อมกับ Manual Test ตาม Test Case ที่เราเขียนไว้ตอนแรกถ้ามี bug เราก็ Report ให้ Dev แก้จนกว่าจะ Run ผ่านทั้งหมดและทดสอบตาม Test Case เรียบร้อยก็ส่งงานเลยยย...

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