กลับมาแล้วค่ะ หลังจากที่ห่างหายไปนานเนื่องจากอาการกังวลเรื่องสถานการณ์โควิด19😂
เอาใหม่ตั้งสติและกลับมาเขียนบทความดีๆเพื่อเป็นแนวทางสำหรับเพื่อนๆ น้องๆ ที่เป็น Software tester ดีกว่า จากครั้งที่แล้ว เราจบกันที่หน้าจอ และ Requirement ของระบบอย่างย่อ สามารถกลับไปดูตอนที่ 1 ได้ที่ URL ตามด้านล่างนี้นะคะ
เทสเคสระบบสมัครสมาชิก ตอนที่1
https://softwaretesterknowledge.blogspot.com/2021/08/Testcase-Member.html
เชื่อว่าหลายคนคงค้นเคยกับการสมัครสมาชิก ไม่ว่าจะเป็น เว็บไซต์หางาน หรือใดๆก็แล้วต่อ
วันนี้ถือโอกาสเอาหน้าจอระบบสมัครสมาชิกของระบบหนึ่งมาให้ลองฝึกเขียนเทสเคสกันดู
ขอบคุณหน้าจอ จาก :https://sites.google.com/site/bc83funds/home
หมายเหตุ:มีการปรับเพิ่มหน้าจอจากต้นฉบับ
จากหน้าจอนี้ จะออกแบบเทสเคสอย่างไรดี
เราจะมากำหนดตัวอย่าง Requirement อย่างคร่าวๆดังนี้
กำหนดให้
1.รหัสสมาชิกขึ้นต้นด้วย อักษรภาษาอังกฤษ แบ่งเป็น
V คือสมาชิก VIP
N สมาชิกทั่วไป
2.ชื่อ-นามสกุลพนักงาน เป็นภาษาไทยเท่านั้น
3.ไม่ต้องระบุคำนำหน้าชือ
4.รหัสประจำตัวประชาชน เป็นตัวเลขเท่านั้น
5.หมู่ที่เป็นตัวเลขเท่านั้น
6.รหัสไปรษณีเป็นตัวเลขเท่านั้น
7.วันที่สมัครสมาชิก Default เป็นวันที่ปัจจุบัน แต่สามารถเลือกเป็นวันที่ย้อนหลังได้
8.วันที่สมัครสมาชิกไม่สามารถเลือกเป็นวันที่ในอนาคตได้
9.จำเป็นต้องกรอกข้อมูลให้ครบทุกฟิลด์
10.ปุ่ม บันทึก คือการบันทึกข้อมูล สมาชิกเข้าไปในระบบ
11.ปุ่ม ยกเลิก คือการยกเลิกบันทึกข้อมูลสมาชิก และจะเคลียร์หน้าจอเป็นค่าว่างทุกฟิลด์
ลองคิดเล่นๆ กันดูนะคะ ว่าจะเขียนเทสเคสยังไงดี
ไว้คราวหน้า เจอกันค่ะ
การล็อกอินเข้าระบบ[ Login ]
หลายคนอาจจะเห็นหน้าจอการlogin เข้าใช้งานระบบ หลายๆครั้ง
ถ้าเราจะเขียนเทสเคสเกี่ยวกับการ Login เข้าใช้งานระบบ เราจะเขียนอย่างไรดีน้าาาา
ก่อนอื่นต้องดูก่อนว่า Design ของ หน้าจอการ Login นั้นเป็นอย่างไร ตัวอย่าง หน้าจอ login ตามด้านล่างนี้
1. มี 2 ฟิลด์ คือ Username , Password
2. ปุ่มกด [Button] มี 2 ปุ่ม คือ Login ,Forgot password
จาก 2 ข้อ ด้านบนเรามาช่วยกันวิเคราะห์นะคะ เริ่มต้นจาก
ฟิลด์ Username , Password
- ค่าไหนบ้างที่ระบบต้องการให้กรอกทุกครั้ง
- ถ้าไม่ระบุค่าที่ระบบต้องการจะแสดงอะไรให้ User หรือ ผู้ใช้งานเห็น
- ระบุค่ามา แต่ไม่ถูกต้อง จะแสดงอะไรให้ User หรือ ผู้ใช้งานเห็น
ปุ่มกด [Button]
- แต่ละปุ่ม มีไว้ทำอะไร
- กดปุ่ม แต่ละปุ่ม แล้วทำอะไร ใน Step ต่อไป
ถ้าเราวิเคราะห์ 2 หัวข้อหลักนี้ได้แล้ว จะทำให้เราเขียน หรือ ออกแบบเทสเคสได้ดี
ตัวอย่างดังนี้นะคะ
กำหนดให้
1.ตาราง Customer เป็นดังข้างล่าง
ข้อมูลเพิ่มเติม
1) ลูกค้าสามารถกรอกรหัสผ่านผิดได้ 3 ครั้ง
2)ลูกค้ากรอกรหัสผ่านผิด 3 ครั้งติดต่อกันระบบจะทำการ locked ไม่ให้สามารถlogin เข้าใช้งานระบบได้อีก ต้องติดต่อเจ้าหน้าที่เพื่อปลดล็อค
ดังนั้นแล้ว จะขอยกตัวอย่างเทสเคส ดังรูปด้านล่าง
ไว้เจอกันครั้งต่อไปนะคะ จุ๊บปปปปปปป
ต่อจากครั้งที่แล้วค่ะ DOPA 5 Fields กับการเขียนเทสเคส แบบ Verify ความถูกต้องของข้อมูล
ตามที่เกริ่นไว้ว่าการเขียนเทสเคสนั้น จะมี 2 มุมมอง คือ การ validate data และ verify data
Verify data คือเมื่อทำการกรอกข้อมูลมาอย่างถูกต้องแล้ว แล้วข้อมูลมีอยู่จริงในระบบไหม
เช่น นางสาวสวยงาม ไทยแท้ มีอยุ่จริงในระบบ DOPA หรือไม่ ถ้ามีอยู่จริง จะต้องตรวจสอบข้อมูลส่วนอื่นๆด้วยหรือไม่ เช่น วันเดือนปีเกิด Laser ID หลังบัตร
หน้าจอ DOPA ตามรูปภาพด้านบน จากการวิเคราะห์ เราสามารถเขียนเทสเคสในมุมการ Verify data โดยมี Scenario หลักๆดังนี้
1.ตรวจสอบความถูกต้องชื่อ-สกุล
2.ตรวจสอบความถูกต้อง เลขบัตรประชาชน
3.ตรวจสอบความถูก เลขหลังบัตรประชน[Laser ID]
4.ตรวจสอบวันหมดอายุของบัตรประชาชน
5.ตรวจสอบวัน/เดือน/ปี เกิดของลูกค้า
จ้าาา มาแล้ว มาต่อจากตอนที่แล้วนะคะ ที่เราให้ข้อมูลเกี่ยวกับ DOPA ไปบ้างแล้ว
ทีนี้ ถ้าเราจะเขียนเทสเคส นี่เราจะเขียนยังไงกันดี ขอเพิ่มเติมรายละเอียดหน้าจอกันนิดหน่อยนะคะ เพื่อให้มี Requirement มากขึ้นกว่าเดิม โดยจะเพิ่มข้อมูลการกรอกข้อมูลประเภท วัน/เดือน/ปี ให้
ตรวจสอบการกรอกชื่อ-สกุล เป็นภาษาอังกฤษตรวจสอบการกรอก วัน/เดือน/ปีเกิดตรวจสอบการกรอก เลขบัตรประชาชนตรวจสอบการกรอก เลขหลังบัตรประชน[Laser ID]ตรวจสอบการกรอก วันหมดอายุบัตร
ตัวอย่างการเขียนเทสเคส
DOPA 5 Fields คืออะไร
ก่อนอื่นมาทำความรู้จักกับ ก่อนนะคะ
DOPA:ย่อมาจาก Department Of Provincial Administration กรมการปกครอง กระทรวงมหาดไทย ส่วนใครอยากรู้รายละเอียดว่าหน่วยงานนี้เขาทำอะไร อันนี้ลองไปค้นข้อมูลเพิ่มเติมได้จาก www.dopa.go.th เลยจ้าาาา
ต่อจากตอนที่แล้ว ที่ได้นำเสนอเรื่อง การเขียนเทสเคส เรื่องการค้นหาข้อมูล โดยได้นำเอาหน้าจอ ตัวอย่างหน้าจอ การตรวจสอบสถานะของ โครงการเราชนะ ซึ่งในนั้นจะให้เราระบุข้อมูล ส่วนตัว ถ้าสังเกตุดีๆ มันคือข้อมูลจริงของเราบนบัตรประชาชนนั่นเองค่ะ
แล้วเจ้า 5 Fields ที่ว่านี้ประกอบด้วยอะไรบ้างเอ่ย
5 Fields ที่ว่านี้ประกอบด้วย
- คำนำหน้าชื่อ
- ชื่อ
- นามสกุล
- วัน/เดือน/ปีเกิด
- เลขบัตรประชาชน
- เลขหลังบัตรประชน[Laser ID]
- วันหมดอายุบัตร
เอ๋.... ทำไมเกิน 5 fields หล่ะ ตกลงยังไงกันแน่น้าาาาา ลองคิดเล่นๆกันดูนะคะ และคราวหน้าจะพาเขียนเทสเคสกันค่ะ
มาแล้วๆๆ หายไปซะหลายวันเลย พึ่งกลับมาจาก ตจว ค่ะ
ว่าแล้วมาต่อกันเลยดีกว่า
จากตอนที่ 1 เรามีหน้าจอ และได้วิเคราะห์ถึงความต้องการของระบบเบื้องต้นแล้วนะคะ ทีนี้เรามาทำการ เขียนเทสเคสกันดีกว่า มาเลยๆๆ
Test Scenario จะมีประมาณ 3 หัวข้อ ได้แก่
1) กรอกข้อมูลไม่ครบ
- Test case ที่เกี่ยวข้องกับ Test Scenario จะมีประมาณ 5 หัวข้อ
-ไม่กรอกข้อมูลใดๆ
-กรอก CID ไม่ครบ 13 หลัก
-ไม่กรอกข้อมูล ข้อมูลชื่อภาษาไทย
-ไม่กรอกข้อมูล นามสกุลภาษาไทย
-ไม่กรอกข้อมูล วัน/เดือน/ปีเกิด
2)กรอกข้อมูลไม่ถูกต้อง
- Test case ที่เกี่ยวข้องกับ Test Scenario จะมีประมาณ 4 หัวข้อ
-กรอก CID ครบ 13 หลัก แต่ไม่ถูกต้อง
-ข้อมูลชื่อภาษาไทย ไม่ถูก
-ข้อมูลนามสกุลภาษาไทย ไม่ถูก
-กรอกข้อมูล วัน/เดือน/ปีเกิด ไม่ถูกต้อง
3)กรอกข้อมูลถูกต้องครบถ้วน
- Test case ที่เกี่ยวข้องกับ Test Scenario จะมีประมาณ 1 หัวข้อ
-กรอกข้อมูลถูกต้องครบถ้วน
รวมๆแล้วมี 10 เคสถ้วนค้าาา
ออกแบบเทสเคสเรื่อง การค้นหาข้อมูล [ Searching]
จากประสบการณ์จริงในการลงทะเบียนของรัฐโครงการหนึ่ง😅😅 และหลังจากนั้นได้ติดตามผล โดยเข้าไปค้นหาข้อมูล
เห็นหน้าจอแล้ว ทำให้เกิดความสงสัยว่า เอ๊ะ เอ ... ถ้าจะต้องออกแบบเทสเคสในการทดสอบหน้าจอ การตรวจสอบสถานะ
จะออกแบบเทสเคสอย่างไรดีน้าาา ว่าแล้วก็ลองมาออกแบบเทสเคสกันเถอะค่ะ
เริ่มจากวิเคราะห์ความต้องการของระบบ[Requirment], แล้วความต้องการของระบบ[Requirment]คืออะไรหละ จะเอามาจากไหน
ในที่นี้ขอใช้หน้าจอ ตามด้านล่างนี้ เป็น ความต้องการของระบบ[Requirment] นะคะ และขอขอบคุณ หน้าจอ จาก rights.เราชนะ.com ด้วยค่ะ
1.Text box สำหรับกรอกข้อมูล จำนวน 3 Text box ได้แก่
1.1 ฟิลด์ หมายเลขประชาชน [ 13 หลัก]
1.2 ชื่อภาษาไทย
1.3 นามสกุลภาษาไทย
2. วัน/เดือน/ปีเกิด * [โปรดเลือกการกรอกข้อมูลหน้าบัตรประชาชน]
2.1 Choice ตัวเลือกแบบ Redio button จำนวน 4 ตัวเลือก ได้แก่
2.1.1 มีวัน/เดือน/ปีเกิด
2.1.2 มีเฉพาะวันและปีเกิด
2.1.2 มีเฉพาะเดือนและปีเกิด
2.1.3 มีเฉพาะปีเกิด
2.2 Choice ตัวเลือกข้อมูล วัน/เดือน/ปีเกิด แบบ Dropdown list จำนวน 3 ตัวเลือก ได้แก่
2.2.1 ปี
2.2.2 เดือน
2.2.3 วัน
**หมายเหตุ จากการสังเกตุ พบว่า การแสดงผล ตัวเลือกข้อมูล วัน/เดือน/ปีเกิด แบบ Dropdown list นี้ ขึ้นอยู่กับ การเลือกในข้อ 2.1 ดังนั้นจะได้เป็นข้อมูลในหัวข้อต่อไป
2.3 การแสดงผล Choice ตัวเลือกข้อมูล วัน/เดือน/ปีเกิด แบบ Dropdown list จะต้องสัมพันธ์กันกับการเลือกในข้อ 2.1
3.ปุ่มกด "ตรวจสอบสถานะ"
โปรดติดตามตอนต่อไปนะคะ
มาแล้วๆๆ วันนี้วันหยุด มีเวลามาเขียนบทความต่อจากตอนที่แล้ว
มาต่อกับตัวอย่าง Test Case / Test Script กันเถอะ
ตัวอย่าง โจทย์ หรือ Requirement
ตัวอย่าง Requirement
1) ทำการจัดเก็บข้อมูลสมาชิก
1.1 รายละเอียกการกรอกข้อมูลสมาชิก ตามตารางด้านบน
1.2 หากกรอกข้อมูลไม่ถูกต้อง เมื่อกดปุ่ม Next ระบบจะแจ้งข้อความเตือน
2)สมาชิกสามารถล็อกอินเข้าใช้งานระบบได้
2.1 หากลูกค้ากรอกข้อมูล login Username ,Password ไม่ถูกต้อง จะแจ้งข้อความเตือนลูกค้า
2.2 ลูกค้าสามารถกรอกข้อมูล login ผิดได้2 ครั้ง โดยที่กรอกผิดครั้งที่ 3 จะโดนlocked
2.3 ลูกค้ากรอกข้อมูลถูกต้อง จะสามารถเข้าใช้งานระบบได้
3)กรณีที่ลูกค้าลืมรหัสผ่านสามารถสอบถามหรือ reset passwordได้จาก เมนู Forgot password
Test Case / Test Script
Test case คือ กรณีที่ใช้ในการทดสอบ โดยหลักการทำ Test Case นั้น จะต้องอยู่บนพื้นฐานของ Business Requirement และวัตถุประสงค์ของระบบ การทำ Test case นั้นสามารถออกแบบ Tempate ของ Test case ได้หลากหลาย ไม่ได้กำหนดตายตัว แล้วแต่ลักษณะงานหรือ Template กลางของแต่ละบริษัท ซึ่ง Test case นั้น จะระบุถึง Step / procedure รวมถึงวิธีการ Set up อย่างละเอียด เพื่อที่ผู้ที่ Run Test ตาม Test Case ได้
Test script คือ ขั้นตอนในการทดสอบ หรือการบอก Step ของ Activity ต่าง ๆ ที่จะกระทำกับระบบแล้วเกิดผลลัพธ์ เช่น User ต้องกรอกข้อมูลลงในฟิลด์ Username และ Password ก่อน แล้วคลิกปุ่ม login
หลักการของการคิด Test Case ที่ควรคำนึงถึง
Negative Case / Invalid Case คือสถานการณ์ที่ลูกค้าทำงานไม่ถูกต้อง แล้วเราจะจัดการกับสถานการณ์นั้นอย่างไร เพื่อจะสื่อสารกับลูกค้าให้เข้าใจ และทำให้ลูกค้าทำงานบนระบบอย่างถูกต้อง
ตัวอย่าง ระบบ login ก็จะเป็นเคสที่ ลูกค้ากรอก Username หรือ Password ไม่ถูกต้อง ระบบจะต้องมีการแจ้งข้อความเตือนลูกค้าให้ทราบเพื่อที่ลูกค้าจะได้ทำการกรอกข้อมูล login อย่างถูกต้อง ต่อไป
Positive Case / Valid Case หรือบางทีเรียกว่า happy case หรือ normal case
ตัวอย่างเช่น ระบบ login ก็จะเป็นเคสที่ ลูกค้ากรอกข้อมูล username และ password ถูกต้องจะสามารถเข้าใช้งานระบบได้
Test Case ควรประกอบไปด้วย
-ชื่อ Test Case โดยปกติแล้วจะตั้งชื่อให้สื่อ เช่น การ login เข้าระบบ
- คำอธิบาย Case ต่างๆ ว่าต้องการ Test กรณีใดบ้าง
-ข้อมูล Input ที่จะใช้ทดสอบใน Case ต่างๆ เช่น data ที่จะต้องใช้ในเคสนั้นๆ , เงื่อนไขในการทดสอบ (prerequisite)
- Test Step หรือ บางทีผู้เขียนเรียกปนๆไปกับ Test script
- Expected Result (ผลลัพธ์ที่คาดหวังว่าจะได้ออกมา ซึ่งจะต้องตรงกับ Requirement)
- Actual Result (ผลลัพธ์ที่ได้จาก Program ) ซึ่งควรจะได้เหมือนกันกับ Expected result ถึงจะ Pass ถ้าได้ Actual result ที่ไม่ตรงกับ Expected result นั้น แสดงว่าเทสเคสข้อนั้นๆ Fail และจำต้องมีการ raise defect ในลำดับต่อไป
- Test Result เพื่อระบุว่า Test case ข้อนี้ PASS หรือ FAIL ผู้เขียนชอบเรียกว่า Test status ค่ะ
ข้อควรทราบ: ในการเขียนเทสเคสนั้น อาจจะไม่ได้ครบทุก event / case ตั้งแต่แรก เราสามารถเพิ่มเติมได้ในระหว่างการทำงาน
Test Scenario
เป็นเอกสารที่จัดทำขึ้นเพื่อร้อยเรียง flow ต่างๆของระบบเข้าไว้ด้วยกัน เหมือนเรียบเรียงไว้เป็น
storyboard เพื่อเอาไว้ใช้สำหรับแตกออกมาเป็น Test Case ในขั้นตอนต่อไป โดยจะบอกใน
ภาพรวมว่า การจะเกิดรายการขึ้นมาได้ 1 รายการนั้น จะต้องผ่านขั้นตอนตั้งแต่เริ่มต้น จนกระทั่ง
สิ้นสุด อย่างไร
เพื่อให้เห็นภาพมากขึ้น ขอจำลองเรื่อง การสมัครสมาชิก
ตารางสมาชิก
1) ทำการจัดเก็บข้อมูลสมาชิก
1.1 รายละเอียกการกรอกข้อมูลสมาชิก ตามตารางด้านบน
1.2 หากกรอกข้อมูลไม่ถูกต้อง เมื่อกดปุ่ม Next ระบบจะแจ้งข้อความเตือน
2)สมาชิกสามารถล็อกอินเข้าใช้งานระบบได้
2.1 หากลูกค้ากรอกข้อมูล login Username ,Password ไม่ถูกต้อง จะแจ้งข้อความเตือนลูกค้า 2.2 ลูกค้าสามารถกรอกข้อมูล login ผิดได้2 ครั้ง โดยที่กรอกผิดครั้งที่ 3 จะโดนlocked
2.3 ลูกค้ากรอกข้อมูลถูกต้อง จะสามารถเข้าใช้งานระบบได้
3)กรณีที่ลูกค้าลืมรหัสผ่านสามารถสอบถามหรือ reset passwordได้จาก เมนู Fogot password
สถานะของการทดสอบ [Test Execution Status]
• Passed = Test Scenario has been tested as planned and application works as expected result
Passed = ผลทดสอบผ่าน ถูกต้อง ตรงกับความต้องการของระบบ
• Failed = Test Scenario has been tested as planned but application does not works as expected result (the issue will be raised in HPQC as a defect)
Failed = ผลทดสอบไม่ผ่าน ไม่ตรงกับความต้องการของระบบ และจะต้องมีการ Raise defect ไว้ เช่น Raise ไว้ที่ Jira ,HPQC, Spira
• Blocked = Test Scenario could not be tested as planned because there is an outstanding defect in related functional area
Blocked = เป็น สถานะเทสเคสที่เกิดขึ้นระหว่างการสอบนั้นมีบางDefect ที่ส่งผลกระทบต่อเคสอื่นๆที่เกี่ยวข้อง หากไม่แก้ไข defect ข้อนี้จะส่งผลให้ไม่สามารถทดสอบเคสอื่นๆที่เกี่ยวข้องได้ เช่น จากรูปภาพด้านล่างเป็นภาพของเครื่องคิดเลข จากภาพนี้ จะสมมุติให้ มี defect อยู่ 1 ข้อคือ
ยังไม่สามารถกดปุ่มตัวเลข 7 4 1 0 ได้ ดังนั้น โปรแกรมเครื่องคิดเลขนี้ ก็จะยังเป็นการทดสอบที่ไม่สามารถทดสอบผลได้อย่างสมบูรณ์ และ ส่งผลให้ เทสเคสที่เกี่ยวข้องกับการ บวก ลบ คูณ หาร หรือการคำนวนณ์อื่นๆ นั้นโดน blocked
• Not Complete = Test Scenario has been tested as planned but not yet finished due to awaiting test result e.g. require EOD batch
Not Complete = สถานะเทสเคสที่ผลสอบยังไม่สมบูรณ์ เช่น การตรวจสอบรายงานบ้างอย่าง ที่ต้องรอ End Of Day batch ดังนั้นแล้ว เคสลักษณะนี้จะต้องใช้เวลาอย่างน้อย 2 วันทำการ โดยที่วันแรก เป็นการทำ Activity เพื่อให้ได้ข้อมูลในการออกรายงาน เมื่อสิ้นวันจะมีการ รัน End Of Day batch (EOD batch) และวันที่สอง จะต้องมาดูผลรายงานว่าถูกต้องหรือไม่
• No Run = Test Scenario has not been tested as planned
No Run =สถานะเทสเคสที่ยังไม่เริ่มทดสอบ
• N/A = Invalid Test Scenario or valid but could not be tested as planned due to limitation of test data/environment
N/A = สถานะเทสเคสไม่สามารถเทสได้แล้ว ณ ตอนนี้ ซึ่งอาจจะเกิดขึ้นได้หลายสาเหตุ เช่น
- Requirement ที่เปลี่ยนไปแล้ว
-ไม่มีข้อมูลทดสอบ
-เป็นเทสเคสที่ไม่สามารถเทสได้
ขอบคุณภาพหน้าจอการคำนวนเลขจาก www.desmos.com
Defect Severity จะจัดความสำคัญของ Defect แต่ละตัวที่พบอย่างไร
Defect Severity 1:
The defect results in the complete failure of the System under test. No further testing can be conducted until the defect is resolved or mitigated.
Example :
- TCB is down, unable to access test environment , unable to connect to database/Application.
- EOD Batch running fails. This impacts test execution schedule.
Defect Severity 2:
Defect results in financial loss/regulatory breach/customer impact and/or cannot continue (block) in specific area with or without solution workaround.
Example :
- Unable to perform cash deposit transaction.
- Incorrect calculation
- Wrong calculation of fee/interest of any transaction
- User is allowed to perform remittance with amount above authorization level, etc.
Defect Severity 3:
Defect that does not result in failure of the functions, modules or interfaces but causes incorrect, incomplete, or inconsistent results with solution workaround.
Example :
- Report generated with incorrect file extension.
- Wrong error message
Defect Severity 4:
Defect that does not affect on the testing result. The test has passed, however a non-critical element of the functions, module or interface has an error.
Example :
- Cash deposit is successful, but validation line printing is misaligned.
- Date shown on statement in Thai instead of English
-Typing error
Credit:
www.softwaretestinghelp.com/
www.guru99.com
Hot Fix กับ Hot Issues มาทำความรู้จัก คำ2คำนี้เถอะ ว่าเขาใช้กันตอนไหนบ้าง
Hot Fix:ในมุมและประสบการณ์ของผู้เขียน โดยส่วนมากจะพบตอนที่ product นั้นๆ ได้ถูกนำไปใช้งานจริงๆแล้วพบว่า การทำงานบางฟังก์ชันงานนั้นยังไม่ถูกต้อง ส่งผลกระทบต่อลูกค้า ดังนั้นแล้วจึงต้อง มีการรีบแก้ไขและ deployขั้นไปใหม่เพื่อให้ระบบทำงานได้อย่างถูกต้อง ลดผลกระทบที่จะเกิดขึ้นกับลูกค้า/ผู้ใช้งาน Hot Fix: is a critical bug fix that needs to go live before the next scheduled release date.
Hot Issues : คำนี้จะเกิดขึ้นในระหว่างการทดสอบ ว่ามี defect เรื่องอะไรที่เราเจอ และ มี level ของ defect ตั้งแต่ระบบ major ขึ้นไป และในสิ้นวันเราจะทำการสรุปประเด็น ปัญหา หรือ Defect ที่พบในแต่ละวัน รายงานให้ผู้เกี่ยวข้องทราบ บางที อาจจะใช้คำอื่นแทนได้ แล้วแต่การจะเลือกเล่นคำ เช่น Hot issues ,Highlight Issues
คำศัพท์ทีเกี่ยวข้องกับงาน Software tester ตอนที่ 1
ในตอนที่ 1 นี้ขอเล่าเกี่ยวกับ Defects, Bug แต่ลำคำ จะมีความหมาย หรือ ความแตกต่างกันอย่างไรนั้น มาดูกันเลยค่ะ
Defects:ในมุมและประสบการณ์ของผู้เขียน คือ การที่โปรแกรมทำงานและได้ผลลัพท์ที่ไม่ถูกต้องตามที่ควรจะเป็น หรือ ตามที่ requirement กำหนดไว้ เช่น
Requirement ระบุไว้ว่า ต้องสามารถค้นหาข้อมูลลูกค้าได้จาก ชื่อ, นามสกุล
นั่นคือ
Expected result : สามารถค้นสามารถค้นหาข้อมูลลูกค้าได้จาก ชื่อ, นามสกุล และแสดงผลได้อย่างถูกต้อง
แต่ผลการทดสอบรอบแรก คือสามารถค้นหาจากชื่อ ได้ แต่ ค้นหาจาก นามสกุลไม่ได้
นั่นคือ
Actual result :
- สามารถค้นหาจากชื่อ ได้ แสดงผลได้อย่างถูกต้อง
- ไม่สามารถค้นหาจาก นามสกุล ได้
ซึ่ง Defect ที่เกิดขึ้นก็คือ ยังไม่สามารถค้นหาจาก นามสกุล ได้
Defects: are issues within an app or site that don’t meet the acceptance criteria (see above). For example, maybe a background is the wrong shade of blue. This wouldn’t necessarily seem like a “bug” to real users. But because it doesn’t match the company requirements for the design, it would be a “defect.”
Bugs:ในมุมและประสบการณ์ของผู้เขียน คือ สิ่งที่เกิดขึ้น หรือ ผลลัพท์ ที่ไม่ได้เกิดจากrequirement ของระบบ ,ส่ิงที่ไม่ได้คาดว่าจะเกิดขึ้น
เช่น
- เปิดใช้งาน application แล้ว เกิด crash หรือปิดตัวเองอัตโนมัติ
- เกิดการ Error บางอย่างในขณะที่โปรแกรมทำงาน และ Error ดังกล่าวprogrammer ยังไม่ได้ handle อย่างถูกต้อง
Bugs: are problems with an app or website. Sometimes they’re obvious issues, such as a crash or unexpected error message. Other times, they’re considered problematic because they don’t match the company’s expectations.
Credit :mindfulqa.com/qa-vocabulary
มาหาความรู้เกี่ยวกับเอกสารที่จำเป็นในงานของ Software tester กันเถอะค่ะ
Documents ที่เกี่ยวข้องกับงาน Software tester
Input Document
- Requirement (มีชื่อเรียกที่แตกต่างกันในแต่ละองค์กร เช่น Project Proposal, High Level Architecture Design etc.)
- Program Specification (มีชื่อเรียกที่แตกต่างกันในแต่ละองค์กร Software Requirement Specification, Program Specification, - Functional Specification etc.)
- Work flow process
ส่วนนี้ Tester จะต้องทำความเข้าใจในรายละเอียดของงานหรือproject นั้นๆจากเอกสารเหล่านี้ เพื่อจะได้นำไปใช้ในการเขียนเทสเคสต่อไป
Output Document (deliverable document)
- Test Plan
- Test Specification / Test Design
- Test Scenario
- Test Case / Test Script
- Requirement traceability matrix
- Test Summary Report
- Defect Log
- Test Result
ส่วนนี้ผู้เขียน ขอเรียกว่า อาวุธประจำกายของเทสเตอร์ละกัน haha ต้องเรียนรู้และใช้งานให้เป็นทุกตัวนะคะ และปรับใช้ให้เหมาะสมกับงานค่ะ
รายละเอียดของแต่ละหัวข้อ รอติดตามอ่านกันในบทความต่อไปนะคะ
Credit :e-Learning PSRUelearning.psru.ac.th
Software tester เป็นคนแบบไหนกันนะ มาดูกันค่ะว่า การจะเป็น Tester นี้ควรฝึกหรือทำตัวอย่างไรกันบ้าง
คุณสมบัติที่ Software tester ควรมี
1)อันดับแรกต้องเป็นคนที่มีใจรักในงานที่ทำ หากเราทำอะไรแล้วมีความชอบในงาน เราจะสามารถทำงานนั้นๆออกมาดีและมีความสุขค่ะ
2)เป็นคนช่างสังเกตุ
Software tester เป็นคนช่างสังเกตุ ไม่ว่าจะเป็นหน้าจอที่เขานำมาเสนอ หรือพูดคุยในห้องประชุม
3)อยากรู้อยากเห็น กระตือรือร้น ที่จะได้รู้ได้เห็นสิ่งต่างๆ
4)สงสัยแล้วก็กล้าถาม
การตั้งคำถามเป็นทักษะ และเป็นคุณสมบัติที่ดีของ Software tester เพราะ คำถามที่ถามนั้นบ่งบอกว่า เราเข้าใจเนื้อหา Project ที่กำลังจะทำหรือไม่ รวมถึงจะบอกได้ว่า สิ่งที่มีอยู่คืออะไร สิ่งที่ขาดและต้องเพิ่มเติมมาคืออะไร อย่าลืมฝึกทักษะการตั้งคำถามที่ดีนะคะ
5)ชอบลองผิดลองถูก
ในการทดสอบอาจจะมีหลายวิธี วิธีที่ 1 ,2,3 เวลาทดสอบแล้วได้ผลเป็นอย่างไร เหมือนกันหรือต่างกัน
6)คิดต่าง คิดนอกกรอบ ทำให้เทสเคสที่ได้นั้นมีประสิทธิภาพมากขึ้น
7)รักที่จะเรียนรู้สิ่งใหม่ๆ
โดยเฉพาะสายงาน IT นั้นมีการพัฒนา และแข่งขันสูงมาก Software tester ที่ดีต้องมีการพัฒนาตนเองตลอดเวลา
ในการทำงานแต่ละproject , บาง project เราอาจจะไม่เคยทำมาก่อน จะต้องมีการศึกษาข้อมูลเพิ่มเติมด้วยตนเอง
8)ไม่รังเกียจที่จะทำงานเอกสาร
ส่ิ่งที่ต้องมีเอกสารหรือต้องทำเป็นประจำคือ Test scenario , test case, test script และ test report
9)ต้องมีมนุษย์สัมพันธ์ที่ดี เพราะการทำงาน Software tester นี้ต้องติดต่อประสานงานกับ Programer ,BA,PM และคนอื่นๆที่เกี่ยวข้องในโปรเจ็ค ตลอดทั้้งในการทดสอบโปรแกรมนั้น ในช่วงแรกๆนั้นจะพบปัญหามากมาย เช่น Enviroment test ยังไม่พร้อมเทส หรือ Test ได้บ้างไม่ได้บ้าง , สามวันดี สี่วันไข้ ชวนหงุดหงิดมาก ทั้งนี้ต้องทำความเข้าใจลักษณะปัญหา และงานที่ตัวเองทำ
10) อารมณ์ดี haha อันนี้ทุกคนควรมีนะคะ จะได้ไม่เครียด มีความสุขกับงานที่ทำค่ะ 👸💓
หน้าที่ Software Tester
1)วิเคราะห์ความต้องการของระบบหรือซอฟต์แวร์ที่กำลังจะทดสอบ
ขั้นตอนนี้สำคัญมากๆ โดยปกติแล้ว เมื่อมีโปรเจ็คที่จะทำ จะต้องมีการประชุมกันว่า จะทำโปรเจ็คอะไร ทำเกี่ยวกับอะไร
ซึ่งจะมีการนำเอาหน้าจอ + Requirement ต่างๆมาพูดคุยกัน
ซึ่งในระหว่างการประชุมหาก Tester มีคำถาม อย่าได้ลังเล เขินอายที่จะถามนะคะ สงสัยให้ถามเลย เพราะจะทำให้มีความเข้าใจในระบบมากยิ่งขึ้น
ซึ่งจะเป็นประโยชน์ในขั้นตอนการเขียนเทสเคส
2)วางแผนสำหรับการทดสอบเพื่อให้เป็นไปตามเป้าหมายที่วางไว้
เมื่อทราบความต้องการของระบบทั้งหมดแล้ว รวบทั้ง Scope ของงานที่จะทำในแต่ละ release หรือ sprint แล้วแต่จะเรียก
เราต้องทำการประเมินเวลาในการทำงาน โดยเอา Scope of work เป็นตัวกำหนด ว่าด้วย Scope งานเท่านี้ จะต้องใช้เวลาทำงานกี่วัน
3)คิดและออกแบบวิธีการทดสอบที่เหมาะสม ทั้ง Test Case, Test Scenario, Test Data และ Test Environment
4)สร้างและจัดเตรียมสิ่งที่จำเป็นต้องใช้ในการทดสอบ เช่น Test Case และ Test Scenarios เป็นต้น
5)เตรียม Test Data และ Test Environment
5.1 Test data ต้องมีการจัดเตรียม data ตาม Test Scenarios หรือ Test Case อย่างเหมาะสม
5.2 Test Environment เช่น PC , mobile , Android , IOS
6)ลงมือทดสอบ
การลงมือทดสอบ ควรดูว่า ลำดับเหตุการณ์ของการทำงานนั้นอะไรเกิดก่อนหลัง ให้ทำการเทสตาม work flow อย่างถูกต้อง เพราะจะทำให้มีการทำงานที่ต่อเนื่องกัน
ทำการ Group งาน หรือเทสเคส ที่เกิดต่อเนื่องกัน และทำการเทส
7)บันทึกปัญหาที่เจอ
การบันทึกปัญหาที่เจอ นั้นจะต้องบอกว่าเราเจอปัญหาขั้นตอนไหน รายละเอียดปัญหาที่พบคืออะไร ถ้ามีภาพ หรือ วิดีโอประกอบ , Error log จะดีมาก เพราะจะช่วยทำให้ Programmer นั้นวิเคราะห์ปัญหาและแก้ไขได้เร็ว
Tool ที่ใช้ในการบันทึกปัญหา หรือ เรียกกันว่า log defect นั้น เช่น jira ,SpiraTest ,HPQC
8)เขียนสรุปผลการ test เพื่อรายงานให้ผู้ที่เกี่ยวข้องรู้ – produce test report
Tester หรือ Software tester หรือ Quality Assurance Engineer หรือ Quality Engineer ,Test engineer (หลายชื่อจริงๆ แล้วแต่บริษัทจะเรียกชื่อ) คือ คนที่มีหน้าที่ตรวจสอบคุณภาพของ software/Application ที่ถูกผลิตขึ้นมาโดย programmer หรือ developer โดยใช้วิธีการ test ต่างๆ ไม่ว่าจะเป็น manual test , automate test เพื่อให้มั่นใจว่า software หรือ Application ที่จะไปถึงมือลูกค้า ( end user) มีคุณภาพและปราศจากข้อผิดพลาดหรือมีข้อผิดพลาดน้อยที่สุด ข้อผิดพลาดเรารู้จักกันว่า bug นั่นเอง
กลับมาแล้วค่ะ หลังจากที่ห่างหายไปนานเนื่องจากอาการกังวลเรื่องสถานการณ์โควิด19😂 เอาใหม่ตั้งสติและกลับมาเขียนบทความดีๆเพื่อเป็นแนวทางสำหรับเ...
