หลังจากได้พบปะกันไปวันอาทิตย์ที่แล้ว ไฟในตัวผมก็แรงขึ้น เพราะได้มีการเปิดประเด็นที่น่าสนใจหลายอย่าง ตอนแรกผมกะจะ post สรุปเป็น comment แต่ไปๆมาๆ เขียนใน notepad แล้วยาวมาก เลยคิดว่าเอามาเปิดเป็นอีก post น่าจะเหมาะกว่า

เอาเป็นว่าขอสรุปมุมมองของผมจากประสบการ์ณตรง ดังนี้ครับ

แบบย่อ

1. ทำทุกอย่างเพื่อ ลดโอกาสข้อผิดพลาดและประหยัดเวลาที่อาจจะเสียไป

2. Make use of time efficiently

3. Integrate with dev team สองหัว ดีกว่าหัวเดียว

4. Record ทุกอย่างให้ได้มากที่สุด เพื่อเป็นหลักฐานสำหรับการexecute และอาจต้องใช้ภายหลัง

…

แบบถึงพริกถึงขิง … (มาดูกัน)

1. ทำทุกอย่างเพื่อ ลดโอกาสข้อผิดพลาดและประหยัดเวลาที่อาจจะเสียไป
 หลายคนมองว่าเวลาเหลือน้อย เราไม่มีเวลามา check โน่นนี่ เพราะต้องเริ่มทำ test เพื่อที่จะ pump test stat ขึ้นมา

ว่า execute ได้กี่ test case แล้ว ผมกลับมองว่า คนเราเวลายิ่งรีบยิ่งพลาด และการพลาดเล็กๆน้อยๆ อาจจะทำให้เราเสียเวลาทั้งวันเลยก็ได้

สิ่งที่ควรจะต้องตรวจสอบก่อนเริ่มทำ test ก็มีความสำคัญไม่แพ้การลงมือทำ test เลย

 1. Make sure you are using the right build
  -> นี่ใช่ version ที่มีสิ่ง fix และ feature ที่เราต้องใช้ test ครบรึเปล่า … confirm กับ ผู้เกี่ยวข้อง ให้แน่นอน
 2. Make sure you are using the right configuration (system parameters, data , etc)
  -> เอา build มาแล้ว เรา set config ถูกมั๊ย ระบบบางอันอาจจะมี configuration parameters ที่ซับซ้อน และ
  หาก set ผิด อาจจะทำให้เกิดหนึ่งในสองอย่างนี้
   - งมและเถียงกับ dev อยู่นานว่าทำไมมันไม่ work …bug ไม่ bug กันแน่ บางคนถึงกับ log bug เสร็จเรียบร้อยไปแล้ว เพิ่งมารู้
   - ได้ผล ถึงแม้จะ match กับ expected result แต่ก็เอาไปใช้ไม่ได้ เพราะมันไม่ใช่ setting ที่ต้อง test
 3. Make sure the build you use is healthy
  -> ถึงแม้ว่า 1 กับ 2 จะ ok แล้ว แต่บางครั้ง fix บางตัวอาจจะทำให้ function หลักของระบบเสียหาย หรืออาจเกิดข้อผิดพลาด

บางอย่างใน process  ของการ build ซึ่งทำให้เมื่อคิดโดยรวมแล้ว build นี้ไม่น่าคุ้มเลยที่จะเอามาใช้ test เพราะมันขาดบางส่วนที่สำคัญไป

 และถึงจะ test ไปบน build นี้ ยังไงก็ต้อง test ใหม่ด้วย  build ที่สมบูรณ์กว่าอยู่ดี หลังจากเตรียม env เสร็จ ควรจะมี test case พื้นๆ

ที่จะยืนยันว่า environment เรา stable พอที่จำทำ test ต่อไป

หากใครสามารถหา tools หรือ process ที่efficient เพื่อที่จะมา prove สามอย่างนี้ได้โดยมี manual step น้อยที่สุดจะเลิศมากๆ

2. Make use of time efficiently
 ส่วนใหญ่แล้วเราเหลือเวลาน้อยลง เพราะ dev delay, build process มีปัญหา, server หรือ network down
 เวลาของเรามีค่า เพราะฉะนั้น ต้องใช้มันอย่างเกิดประโยชน์สูงสุด ถึงแม้จะเริ่มทำ test ไม่ได้ในช่วงนี้

แต่เราก็ทำอะไรเพื่อลด effort ในการทำ test เมื่อมี env พร้อมไว้ล่วงหน้าได้
 
 -> วางกลยุทธ์เพื่อจะ test ด้วยการจัดกลุ่ม จัดลำดับ การ test เพื่อที่จะจับ bug ให้ได้มากที่สุดในเวลาที่สั้นที่สุด
  คนที่ test แบบพื้นฐานคือจะไล่ test ไปตาม test case id แต่ในความเป็นจริงแล้ว การจัดลำดับ จัดกลุ่มใหม่

หลังจากเขียน test case รอบแรกเสร็จแล้ว  เป็นสิ่งที่จะเพิ่มคุณค่าของ test script ได้มาก

การ execute test ที่ดีจะต้องเป็นการผสมผสานการ test ในแนวราบและในแนวดิ่งเข้าด้วยกัน

 หาก focus แนวดิ่งอย่างเดียว  จะทำให้เราได้ view ที่ช้ามากว่าสรุปแล้ว version ที่กำลัง test อยู่มันใกล้ความจริง

ที่จะพร้อมใช้โดยลูกค้าแค่ไหน และอาจทำให้เราเจอ bug basic  แต่สำคัญในบาง module ช่วงโค้งสุดท้ายก่อน test เสร็จ

หากเป็นกรณีนี้ ถือว่าเราทำให้ dev ทีมไม่ได้ utilize เวลาอย่างเต็มที่เช่นกัน เพราะเค้าอาจจะรอแก้ bugเราตั้งแต่วันที่ dev เสร็จ
  แต่เราไม่ได้ test component นั้นเลยจนกระทั่งเรา test module อื่นเสร็จหมดก่อน 

 -> คิดเป็นหลายๆoption ไว้ล่วงหน้าเลยว่าจะตัดอะไรออกบ้าง หากเวลาหายไปกี่วัน

 -> ทำยังไงก็ได้เพื่อให้การ execute step และ check result เป็นไปได้เร็วที่สุด ตัวอย่างเช่นเตรียม expect result

ไว้ใน excel แล้วใช้ query หรือ copy & paste จากระบบแล้วมาใช้ excel formula เพื่อเปรียบเทียบค่า

 -> อย่าไปมัวแต่ focus ที่ negative test จนเกินไป เพราะถ้า positive case ยังไม่ work … negative test bug ก็แทบไม่มีค่าอะไร
 
 -> ใช้เวลามากขึ้นตามลำดับสำหรับ module ที่ complex หรือเคยมี bug เยอะ หรือมีมานานแล้วซึ่งอาจจะทำให้แก้ code แล้วเกิด regression
 หรือคิดว่าจะมีการใช้งานบ่อย หรือเป็น area ที่ dev คนที่ทำอาจจะยังไม่เชี่ยวมาก
 
 -> upgrade by design, not by default ในระหว่างการทำ test จะมี build มาใหม่เรื่อยๆ เพราะมี fix จ่อรอมาให้ test

การ upgrade เปลี่ยน build แต่ละครั้งมีทั้งความเสี่ยงต่อความผิดพลาด และoverhead ในการ re-verify environment

ควรจะพิจารณาให้ดีว่าจะ upgrade เมื่อไหร่ ถี่แค่ไหนจึงจะ efficient ที่สุด ถ้าทิ้งห่างของช่วงการ upgrade นานเกินไป

ก็ทำให้มีความเสี่ยงที่เราจะ test build ที่เก่าไปแล้ว

3. Integrate with dev team สองหัว ดีกว่าหัวเดียว
 -> คุยกับ dev เพื่อดูว่าส่วนไหนที่คลุมโดย unit test ไปบ้างแล้ว
 -> คุยกับ dev ว่าส่วนไหนที่เขามั่นใจ ไม่มั่นใจ บางครั้งที่ไม่มั่นใจเพราะอาจเป็น area ที่ไม่คุ้นเคย 
 -> คุยกับ dev เพื่อให้แน่ใจว่า ถ้ามี issue อะไรที่เค้ารู้ เจอเองหรือเจอจาก unit test แล้วกำลังจะแก้ หรือแก้อยู่

ให้รีบบอกเรา เราจะได้ยังไม่ test ส่วนนั้น
 -> อย่าดอง bug ไว้ log ทีเดียว เจอแล้วให้รีบ log เพื่อที่จะให้ dev มีเวลาแก้มากที่สุด หากมีเวลาน้อยที่จะเตรียมหลักฐานให้สมบูรณ์

ให้ใช้วิธีคุยกันคร่าวๆก่อน เผื่อ dev อาจจะปิ๊งได้ว่า issue น่าจะเกิดจากอะไร
ต้องไป check ตรงไหน แล้วเรื่องความสมบูรณ์ของ bug log ค่อยมาเก็บกันทีหลัง

4. Record ทุกอย่างให้ได้มากที่สุด เพื่อเป็นหลักฐาน
 -> บางทียิ่งรีบทำ จะทำให้เราดูผลผิดพลาดได้ ให้เก็บ screenshot และ log file ไว้ให้ดี
 อาจจะยังไม่ต้องจัดเก็บสวยงามแต่ให้มีพอที่เราจะกลับมาดูเพื่อยืนยันผลหรือ analyze issue

ที่มองไม่เห็นตอน execute ตอนนั้น ในภายหลังได้

(For leader/manager)
1. Make sure priority is clear
 -> ในกรณีคับขันแบบนี้ ในฐานะกัปตัน จะต้องแน่ใจว่าเรารู้ว่าเราต้องการอะไร และต้องสื่อสารให้ทั่วถึง

คำถามตัวอย่างง่ายๆ คือระหว่างทำ execute test ให้ได้มากที่สุดกับ
 เจอ issue แล้วให้รีบ log เร็วที่สุด คุณอยากได้อย่างไหนก่อน เพราะอะไร
 -> คุณให้ความสำคัญกับ module ไหนมากกว่ากัน เพราะอะไร
 (นี่เป็นแค่ตัวอย่าง ในความเป็นจริง คุณต้องสื่อสารทุกอย่างออกมาว่าคุณให้ความสำคัญกับอะไรก่อนหลัง เพราะอะไร)

2. Monitor status of software and prepare to put the red flag
 -> คอยดูว่าเมื่อเวลาผ่านไปเรื่อยๆ defect injection rate ลดลงหรือไม่ หากยิ่งทำยิ่งเจอ bug มากขึ้นๆ

เป็นสัญญาณให้รีบเตรียมข้อมูลยกธงแดง นัด meeting เพื่อหารือโดยด่วน
 การหารือนี้ เราต้องเตรียมตัวพอควร ว่าเราเจออะไรบ้าง และตอนนี้มี module ส่วนไหนที่ดู stable แล้ว

และส่วนไหน ที่ยังห่างไกลความจริง ควรจะคิด option ไว้คร่าวด้วยว่า เราคิดว่าควรจะทำอย่างไรกันดี

3. Be the gate keeper for fixes to go in
 -> some fixes do more harm than good … ส่วนใหญ่แล้ว dev กับ PM จะอยากใส่ fix เข้าไปให้ได้มากที่สุด

 ไม่ชอบเหลือ outstanding bug when release เพราะต้องทำ release note เพิ่ม
 และรู้สึกว่า ดูไม่ดีเหมือนงานไม่เสร็จจริง ในฐานะ QA เราจะต้องทำตัวเป็นประตู วัดความเสี่ยงว่า fix ตัวไหนควรเข้าไม่ควรเข้าเมื่อไหร่

 และคอย provide input ตลอด เพราะ fix บางตัวเข้าไปอาจทำให้เกิด regression issue ได้

ในช่วงอาทิตย์สุดท้ายหากไม่มี business impact จริงๆ แนะนำว่าอย่าเอาเข้าเลย อาจจะทำให้สิ่งที่ทำดีมานานเสียเปล่า

 แล้วเวลาเลือก อย่าเลือกแค่จากเบอร์ severity เท่านั้น

 บาง bug severity สูงแต่โอกาสเกิดน้อยมากๆ แล้วถ้าเกิดก็สามารถแก้ไขได้ด้วย manual workaround ไม่ยาก

 แต่บาง bug ที่ severity ต่ำอาจจะสำคัญต่อภาพลักษณ์อย่างมหาศาล เช่นชื่อหรือlogo ลูกค้า หรือของบริษัทตัวเองสะกดไม่ถูกเป็นต้น