how-to-write-test-cases-feature-image
how-to-write-test-cases-feature-image

สำหรับเหล่า QA / Software Tester / Software Engineer in Test หรือใครก็ตามที่ต้องการจะทําการทดสอบระบบอะไรซักอย่าง สิ่งแรกที่ควรทําเลยไม่ใช่ไปสนใจว่าเราจะใช้เทคโนโลยีอะไรในการพัฒนาระบบ เช่น สมมุติให้มีระบบจัดการลูกค้าบนมือถือ Application เป็น WebView  ของมือถือนั้นๆ สิ่งแรกที่ควรทําไม่ใช่เราไปคิดฟุ้งซ่านว่า เราจะต้องลง Jenkins ทํา pipeline เอา docker มา initialize application นั้นในการทํา test เพื่อตัด dependencies อื่นๆๆออกทั้งหมด หรือ กระทั่งออกแบบ Cloud เพื่อจัดการ devices ต่างๆ

แต่สิ่งที่เราต้องเริ่มศึกษาก่อนเลยคือ

  1. เข้าใจ Business Logic ของ Application (ระบบจัดการลูกค้า สิ่งที่ต้องทําได้คืออะไร และ business logic ต่างๆคืออะไร เช่น ระบบจัดการลูกค้าต้องสามารถ แก้ไขข้อมูลส่วนตัวลูกค้าได้ เชื่อมต่อกับตารางงานของลูกค้า ส่งเมลล์ได้ รวมไปถึง import/export ซึ่งพวกนี้จะทําให้ลูกค้าใช้งานง่ายและกลับมาใช้ระบบของเราอีก)
  2. เข้าใจ Technology ที่ Application นั้นใช้ (เราต้องมีความรู้เรื่อง Application นี้รองรับกี่ platform มือถือ?เว็ป? ใช้ framework อะไร? plugins อะไร? Architecture เป็นยังไง? Database อยู่ตรงไหน? Field เป็นยังไง? connection ส่งกันแบบไหน? ก็ควรที่จะต้องรู้เพราะบาง plugins ที่ Developer เพิ่มเข้ามา มันให้ผล behavior เปลี่ยนไปเมื่อมีการทํา automation script)

หลังจากที่เราจะมาสู่ส่วนที่สําคัญที่สุดนั้นก็คือ Test Cases Design นั้นเอง! สิ่งนี้สําคัญกว่าอื่นๆเลยล่ะ เพราะการจะตรวจสอบว่าโปรแกรมของเราทํางานได้ถูกต้องหรือไม่ มันก็มาจากตรงนี้ ไม่ใช่การทํา automate script หรอกน่ะ

เสริมๆๆๆเรื่อง Automation Script เคยมีบทความนึงพูดถึง โลกของ QA สมัยนี้ว่ามันจะถูกแทนที่ด้วย Automation มั้ย? เพราะ Automation มาแรงมากๆ แต่บอกเลยว่าไม่จริง 🙂 ตอนนี้ QA น่ะสําคัญกว่าเดิมเป็นไหน เพราะเราสามารถ Focus ที่ Quality ได้จริงๆไม่ต้องมานั่งทดสอบ regression test ซำ้ไปมายันดึกดื่น แล้วสนใจ quality ไม่ได้เท่าที่ควร

is-qa-dead-article
is-qa-dead-article (https://www.thoughtworks.com/insights/blog/qa-dead)

เพราะฉะนั้นบอกเลย “Automation is good but not that smart” มันแค่ทําตามที่ test cases บอกให้ทํา และมันรู้อยู่แล้วว่าทํายังงี้จะผ่าน ถ้าไม่ผ่านมันจะฟ้องออกมา เพราะฉะนั้นหัวใจของการทดสอบจริงๆคือเรื่องของ Test case design นั้นเอง

แล้วเราจะออกแบบ Test Cases ยังไง?

หลายๆคนก็คงเคยที่จะนั่งกดๆๆ Application กับออกแบบเทสเคสกันลง excel file ยาวๆหลายๆพันบรรทัด สร้าง column แบบ approve by, scenario flow, report to ไรแบบนั้น แล้วก็มานั่ง highlight สีเขียว-แดง ว่าทดสอบยังหรือไม่ ตาลายแน่ๆบอกเลย (จริงๆถ้าได้ออกแบบ flow การ test ดีๆ เราจะไม่ต้องเสียเวลามานั่งทําไรแบบนั้นเลย แต่ไว้โม้รอบหน้า)

ซึ่งไอ้การเขียน test cases ลงใน excel ไฟล์ไรพวกนั้นน่ะ จริงๆแล้วมันมีหลักการณ์วิธีคิดอยู่ ไม่ใช่แค่เรากดๆๆแอพแล้วนึกไรขึ้นได้ก็ใส่ลง excel ไฟล์ไปครับ 🙂

ซึ่งหลักการณ์ที่ใช้ในการคิดวิเคราะห์และเขียน test cases นั้นก็คือ

  1. Equivalent Partition
  2. Boundary Value Analysis
  3. State Transition
  4. Decision Table
  5. Flow Chart

เจ้าพวกนี้เป็น Black Box Testing Technique น่ะ….ความหมายคือเราไม่รู้หรอก code หน้าตาเป็นยังไง แต่เราดูจาก behavior ซึ่งก็ business logic ที่ต้องการเอา แต่ถ้าเราเข้าใจ technique พวกนี้ มันจะช่วยให้เราออกแบบ test cases ได้ดีขึ้น ไม่ต้องซำ้ซ้อนมากมาย หรือเข้าใจวิธีคิดมากขึ้น

มาดูตัวอย่างการใช้ Black Box Testing Technique กันแบบเห็นภาพ

โดยต่อไปนี้จะยกตัวอย่างจาก Business Logic ง่ายๆ อย่างเจ้าตัวนี้

example-business-logic-elevator
example-business-logic-elevator

ง่ายๆเลย ทดสอบระบบหน้าจอของการเรียก Elevator นั้นเอง สบายๆ ไม่ซับซ้อน จะได้เข้าใจ concept กัน 🙂

Equivalent Partition

ขออธิบายง่ายๆ ภาษาบ้านๆเลยน่ะ Equivalent Partition คือ การแบ่ง Input ที่จะใช้ในการเทส ออกเป็นสองส่วนก็คือ Negative และ Positive Value แล้วทําการทดสอบค่านั้น โดยเลือกออกมาในแต่ละ Partition

เหมือนเรามีชุดของข้อมูลยาวๆ เช่น 1-100 ข้อมูล 1-20 และ 80 – 100 จะ Fail เพื่อไว้เทส เราคงจะไม่เขียน test cases แบบค่า 1 ได้ผลแบบนี้ ค่า 2 ได้แบบนี้ ค่า 3 …. จนถึง ค่า 100 ใน test cases design กันหรอกน่ะ เพราะแบบนั้นตลกสิ้นดี

สิ่งที่ทํากันคือเราติด Partition หรือขอบให้มัน!! แล้ว สมมุติให้มันว่าค่าที่อยู่ในนั้นจะเป็น Negative หรือ Positive นั้นเอง เช่น สมมุติแบบเดิม 1-100 เมื่อกี้เราจะแบ่งเป็น 3 ส่วนคือ

positive-negative-equivalent-partition
positive-negative-equivalent-partition

เห็นแล้วใช่มั้ยว่า เราแบ่งชุดข้อมูลเป็น 3 ส่วน และจาก technique นี้จะแปลว่าเราจะได้ test cases ออกมา 3 เคส

  1. input data อยู่ระหว่าง 1-20
  2. input data อยู่ระหว่าง 21-79
  3. input data อยู่ระหว่าง 80-100

แค่นั้นเอง โดยสมมุติว่าตัวเลขที่อยู่ระหว่างนั้นจะถูกและผิดตามที่เรามีข้อมูล ลดความซำ้ซ้อนของ test cases ไปได้เยอะเลย….บางคนคงลืมไปแล้ว ว่ามันเกี่ยวไรกับรูป Elevator ที่ส่งให้ดูล่ะ?

example-business-logic-elevator
example-business-logic-elevator

ถ้ายกตัวอย่างกับการเทสเจ้าตัวนี้ก็คือ มันจะมีการแบ่ง Positive และ Negative อยู่โดย Partition ที่แบ่งก็คือ

elevator-equivalence-partition
elevator-equivalence-partition

หลังจากนั้น test cases ก็ไม่ต่างกันหรอก เพราะถ้าเราเดินไปกดลิฟ ชั้น 1-15 กับ elevator console ตัวนี้ ต้องไม่มีทางได้ชั้นนั้นแน่ๆ จะได้ error กลับมา ชัน 27-50 ก็เหมือนกัน เพราะฉะนั้น 16-26 จะเป็นค่าที่ Positive นั้นเองครับ 🙂

ถ้ามองเป็น Application ซักตัวนึงอย่าง แอพสมัครงานก็ได้ ถ้าให้กรอกอายุ มันก็น่าจะกรอกได้ที่ 22-60 ปี (เทียบอายุคนทํางาน) แล้วเราก็สามารถลดความซับซ้อนของการออกแบบ test cases ได้ล่ะ

Boundary Value Analysis

บางคนจะชอบเขียนว่า Equivalent Parition & Boundary Value Analysis เวลาอธิบายเรื่องพวกนี้ ซึ่งไม่แปลกน่ะ เพราะว่า …. มันมีความเกี่ยวเนื่องกัน

Equivalent Parition อย่างที่บอกคือการแบ่งค่าออกมาเป็น partition ๆ และจะได้กลุ่มของค่ามา ส่วนเจ้า Boundary Value Analysis คือการทดสอบค่าระหว่าง Partition นั้นๆนั้นเอง

elevator-equivalence-partition
elevator-equivalence-partition

มาดูค่าของ Elevator กันอีกทีน่ะ เห็นใช่มั้ยว่ามี 3 กลุ่ม? และเราบอกว่าเราเขียนได้ 3 test cases แต่จริงๆแล้วเราจะต้องทดสอบเพิ่มน่ะ!! ก็คือทดสอบเรื่องของ Boundary Value Analysis และจุดที่จะทดสอบก็คือ

  • 15 ( expected คือ fail )
  • 16 ( expected คือ pass )
  • 26 ( expected คือ pass )
  • 27 ( expected คือ fail )

เพราะว่าถ้าเราใช้แค่ Equivalent Parition เพียงอย่างเดียว เราจะมองข้ามจุดที่ต้องเทสตรงนี้ไปนั้นเอง 🙂

นี้แหละง่ายๆการใช้ Equivalent Parition & Boundary Value Analysis ด้วยกันนั้นเองงงงงง ที่นี้เรายังมองเรื่องของการใส่ Input เข้าไปด้วยค่าเพียงค่าเดียวอยู่ แต่ถ้าเป็น multiple input เราอาจจะต้องทําการสร้าง Decision Table ขึ้นมา แต่ก่อนหน้านั้นไปเรียน State Diagram กันก่อน

State Diagram

เจ้าตัวนี้เข้าใจไม่ยากเท่าไร เพราะมันคือแค่การเข้าใจถึงภาพรวมของระบบ โดยการใช้ Input ที่ใส่เข้าไปในระบบเป็นตัวที่ทําให้ state ของโปรแกรมเปลี่ยนไปในแต่ละขั้นตอน ฟังแล้วอาจจะยังไม่เห็นภาพ แต่ให้ลองดูภาพนี้

atm-machine-state-diagram
atm-machine-state-diagram (http://moneymatters101.com/banking/atm.asp)

อยากให้ลองนึกถึงภาพเวลาเราไปกดเงินที่ตู้ ATM …. เวลาเราไปกดเงินสิ่งที่เราต้องทําอย่างแรกเลยก็คือการใส่บัตรเข้าไปแล้วก็กดรหัสหรือ PIN code ของเรา ซึ่งถ้ากดถูกก็จะสามารถกดเงินสดได้ ถ้ากดผิดก็ไม่สามารถกดได้ และโดยปกติกดผิด 3 ครั้งนี้คือโดนกินบัตรเลยล่ะ 🙂

เพราะฉะนั้น scenario ที่พูดไปเมื่อกี้การที่เราจะเขียน test cases ที่ดีได้ เราต้องรู้ว่าแต่ละ state ที่เราทํา ทําให้เกิดอะไรบ้าง ดังนั้นเราจึงควรที่จะเขียน state diagram ออกมาเพื่อใช้ในการวิเคราะห์และออกแบบเทสนั้นเอง

โดยง่ายๆเลยคือ ดูจาก state diagram ข้างล่างนี้

atm-machine-state-diagram
atm-machine-state-diagram (http://istqbexamcertification.com/what-is-state-transition-testing-in-software-testing/)

ในที่นี้ก็จะพูดถึงเรื่อง Input ที่เข้ามาทําให้ State ของ เจ้าตู้ ATM หรือจะมองเป็น Application Under Test (AUT) ก็ได้ โดย state จะเปลี่ยนไปนั้นเกิดจากการใส่ PIN ถูก หรือ ผิดนั้นเอง

ซึ่งเจ้า Diagram ข้างบนแสดงให้เห็นว่า เราสามารถแบ่ง test cases ออกมาได้เป็น 4 cases หลักๆ

  1. Positive Flow – ลูกค้าใส่ PIN ถูก ทําให้ access to account ได้เลย
  2. Negative Flow – ลูกค้าใส่ PIN ผิดหมด ทําให้ eat card ไปเลย
  3. Positive Flow – ลูกค้าใส่ PIN ผิดครั้งแรก และ ถูกครั้งสอง แล้วถึง access to account ได้
  4. Positive Flow – ลูกค้าใส่ PIN ผิดครั้งแรก และ ครั้งสอง แต่ถูกครั้งสาม แล้วถึง access to account ได้

ด้วยการมองแบบภายใต้ state ที่เปลี่ยนไปทําให้เราออกแบบ test cases ได้ดีมากขึ้น 🙂

เสริมๆๆ: แต่ในชีวิตจริงเราอาจจะต้องทดสอบเรื่องของ connection ของตู้ ATM ด้วยว่าค่าที่ส่งไปมาระหว่างการใส่ PIN ถูกต้องมั้ย? Database เป็นยังไง?

Decision Table

มาดูตัวสนุกกันเถอะ 🙂 หลังจากเรียนเรื่อง Equivalent Parition & Boundary Value Analysis  ไปแล้ว จะสังเกตุว่ามันเป็นเรื่องของ Single Input แต่ถ้าเป็น Combinations Input มันจะไม่สามารถใช้งานได้

คําว่า Multiple Input หรือ Combinations Input คืออะไร? (ช่น dropdown เลือก จังหวัด แล้วมันถึงจะ โชว์ เขต เป็นต้น ตัวอย่างๆ

example-multiple-input
example-multiple-input (http://www.itangmo.com/file/demo/21082013/dropdown/)

จะเห็นว่าเราจําเป็นต้องมีการเลือกค่าจังหวัดก่อนแล้วอําเภอจะขึ้นจากนั้นถึงเป็นตําบล ต้องทําให้ครบทั้ง 3 อย่างก่อนถึงจะกดตกลงได้ 🙂 พวกนี้แหละ เป็นเหตุผลที่เราต้องทํา Decision Table ในการออกแบบ test cases

decision-table-province
decision-table-province

จะเห็นว่านี้มันจะได้ตารางออกมายังงี้ ซึ่งสีเขียวแปลว่าเราเลือก แดงแปลว่าไม่เลือก ส่วนผลลัพธ์ออกมาคือปุ่มจะ enable เพื่อ submit

ซึ่งมันแปลว่า Test Cases ของ Combinations จะเป็น 2 ^ n ซึ่ง n คือจํานวนของ input ที่ใส่เข้าไป ในกรณีนี้คือ n ^ 3 = 8 test cases นั้นเอง 🙂

ฟังดูเยอะมั้ยล่ะ 55555 การเขียน test cases แต่ไม่ได้ยากเกินไปหรอก พวกนี้เป็นวิธีช่วยเราคิดนั้นเอง

Flow Chart

สุดท้ายตัวนี้ไม่ได้เป็นการเขียน test cases หรอก แต่ชอบเขียนเมื่อเวลาจะพยายามเข้าใจอะไรซักอย่าง เช่น

login-flowhcart
login-flowhcart

จะเห็นได้ว่าการเขียน flowchart ทําให้เข้าใจว่า Login ทําอะไรบ้าง มีขั้นตอนอะไรบ้าง 🙂 แล้วเราจะได้มาวิเคราะห์แล้วออกแบบ test cases ได้ถูกต้องนั้นเอง 🙂

สรุปแล้ว

หลังจากอ่านมาอย่างยาวนานนนนนนนนนนนนนน สรุปได้ว่าเทคนิคเป็นสิ่งที่ควรจํา และเอาไปใช้ในการเขียน test cases ให้ได้ง่ายขึ้น โดยไม่ได้มั่วเห็นอะไร ก็เขียนออกมา มันจะได้มีหลักการณ์เขียนนั้นเอง 🙂

จําไว้แล้วเอาไปใช้กันน่ะครับ บางที่เป็นข้อสอบด้วยล่ะ ฮรี่ๆ

ref:

  1. http://www.guru99.com/software-testing-techniques-1.html
  2. http://www.guru99.com/software-testing-techniques-2.html
  3. http://www.guru99.com/equivalence-partitioning-boundary-value-analysis.html

1
Leave a Reply

avatar
1 Comment threads
0 Thread replies
0 Followers
 
Most reacted comment
Hottest comment thread
0 Comment authors
Recent comment authors

This site uses Akismet to reduce spam. Learn how your comment data is processed.

newest oldest most voted