จะทดสอบอย่างไรให้รู้ผลได้ภายใน 10 นาที ก่อนไปมองหา Automate Testing Tools

V-and-V

 

สวัสดีเช้าวันอังคารที่ 8 กันยายน พ.ศ. 2558 วนเวียนกลับมานั่งเขียน Blog ลงใน WeLoveBug อีกครั้งซึ่งสัญญาต่อหน้าฟ้าดินว่าจะมาเขียนให้บ่อยและสม่ำเสมอขึ้นเรื่อยๆ อีกครั้งเหมือนครั้ง WeLoveBug สมัยเยาว์วัยและเช้าวันนี้ขอหยิบยกสิ่งที่เพื่อนและหนึ่งในผู้เขียนของ WeLoveBug ได้แบ่งปันออกมาผ่านโลกของ Social และผมชอบนะกับคำพูดนี้

เราจะทดสอบทั้งหมดให้เสร็จภยาใน 10 นาทีได้อย่างไร?

ที่หยิบเรื่องนี้มาเขียนเพราะว่าสองปีที่ผ่านมาผมจะเจอคำถามเรื่องของ Automate Testing ว่าใช้ Tool อะไร? และพอมาเจอคำพูดของนัทที่แบ่งปันมาก็เลยเอามารวบรวมแล้วเขียนออกมาเป็น Blog นี้เพื่อแบ่งปันมุมมองจากประสบการณ์ของตัวผมเอง

เหนื่อยไหมกับ Re-Test และ Regression Testing ด้วย Manual Test?

 

ในชีวิตการเดินทางบนเส้นทางของ สิ่งมีชีวิตที่คิดว่าตัวเองมีคุณภาพมากที่สุดในโลก หรือ Software Tester เราก็ต้องพบเจอกับการทำ Re-Test และ Regression Testing ด้วย หนึ่งสมองและสองมือ ซึ่งถ้านับตั้งแต่วันแรกของตัวเองที่เริ่มทำงานในสายงานทดสอบซอฟต์แวร์นั้น หนึ่งสมองและสองมือ ยังคงไหวอยู่ในการทำ Re-Test และ Regresison Testing แต่พอซอฟต์แวร์มันใหญ่ขึ้นหรือมี Bug เกิดขึ้นเรื่อยเรื่อย เรื่อยเรื่อยและเรื่อยเรื่อย ดังนั้นก็เลยมองไปหาว่าจะมีอะไรเข้ามาช่วยได้เพื่อให้การทดสอบซ้ำเดิมให้ทดสอบได้ไวขึ้น ณ ตอนนั้นก็มองไปที่มีเครื่องไม้เครื่องมืออะไรที่ แล้วก็ไปจบ Automate Testing Tool หนึ่งตัว

เหมือนจะเจอทางสว่างแต่จริงๆ แล้วไม่เลย เพราะก็ยังคงต้องทดสอบแบบ Manual Test เท่าเดิม!!!

ทำไม?!?!? เราก็มี Automate Testing Tool แล้วนี่!!!

ณ ตอนนั้น ก็ยังคงเหนื่อยเหมือนเดิมกับ Manual Test นะจ๊ะ เพราะ

  • ซอฟต์แวร์ที่ทำงานในตอนนั้นไม่ได้ถูกออกแบบมาให้ทดสอบด้วย Automate ได้ง่าย
  • Automate Testing Tool เท่ากับ การเขียน Code ณ ตอนนั้นการเขียนโค้ดก็ละทิ้งไปบ้างแล้ว
  • ทำ Automate Testing Script มาแล้ว ไม่สามารถนำกลับมาใช้ในการทำ Re-Test และ Regression Testing ได้เรื่อยๆ เพราะเป็นการบริหารจัดการโครงการแบบ Project Base ไม่ใช่ Product Base

มันเลยใช้เวลานานสำหรับการทำ Automate Testing Script ก็เลยต้องหันหน้ากลับไปที่ Manual Test แต่ก็ยังใช้ Automate Testing Tool สำหรับการจัดเตรียมข้อมูลในการทดสอบเท่านั้นเอง

Automate Testing มิใช่หน้าที่ความรับผิดชอบของ Test Team

ผมเชื่อว่าเมื่อไรที่บริษัทและองค์กรใดๆ เริ่มชายตามามอง Automate Testing ก็จะเริ่มจาก Tool อะไร? และก็ไม่พ้นกับความเข้าใจว่า Automate Testing เป็นหน้าที่ความรับผิดชอบของ Test Team และก็ต้องถือครองดูแล Automate Testing Tools ไปด้วย งานเข้าสิครับแบบนี้สำหรับ Test Team!!!

กลับมาดูก่อนนิดนึง ผมขอยก V&V Model แบบพื้นๆ มาดูกันหน่อยว่า

  • ความต้องการของลูกค้า จะถูกตรวจสอบและทดสอบด้วย Acceptance Testing
  • การออกแบบการสร้างซอฟต์แวร์ จะถูกตรวจสอบและทดสอบด้วย System Testing และ Integration Testing
  • Source Code ของซอฟต์แวร์ จะถูกตรวจสอบและทดสอบด้วย Unit Testing

ซึ่งทั้ง 4 ระดับของการทดสอบนั้นสามารถนำ Automate Testing เข้าไปปรับประยุกต์ใช้ได้ทั้งสิ้นมากน้อยเพียงใดผมขออ้างอิงไปถึง Agile Testing Quadrant จากหนังสือ Agile Testing: A Practical Guide for Testers and Agile Teams เขียนโดย Crispin, Lisa และ Gregory, Janet

agile-testing-quadrant

Acceptance Testing อยู่ใน Quadrant ที่ 2 ซึ่งเราสามารถออกแบบวิธีการทดสอบได้จากการที่คุยตกลงกับลูกค้าโดย Software Tester หรือ Analyst ทั้งหลายสามารถใช้เทคนิคเช่น Acceptance Test Driven (ATDD) หรือ Behavior Driven Development (BDD) หรือ Specification by Example (SbE) เป็นต้นเข้ามาช่วยสร้าง Test Scenarios ตามความต้องการและข้อตกลงในการตรวจรับพร้อมทั้งได้ตัวอย่างของกลุ่มข้อมูลออกมาด้วยโดยสามารถนำไปสร้างเป็น Automate Testing ได้แต่ก็ยังคงจะต้องมีเรื่องของ Manual Testing อยู่ด้วย

Unit Testing, Integration Testing และ System Testing นั้นในส่วนนี้อยู่ใน Quadrant ที่ 1 เลย สามารถใช้ Automate Testing เข้าไปได้แบบเต็มๆ แต่ต้องมาปรับให้เท่ากันก่อนว่า Unit Testing ของฝั่งพวกกระผมคืออะไร ซึ่งขอให้ไปเสพเรื่องของ Unit Testing ที่ somkiat.cc ตาม Link นี้

บทความเรื่อง Unit Testing ที่ Somkiat.cc

ดังนั้น Automate Testing ขอสรุปความตามประสบการณ์ของผมว่า

  • ไม่ได้ถือครองโดย Software Tester
  • ไม่ใช่ Tools
  • ทำเท่าที่จำเป็น

โดยขอให้เริ่มต้นด้วยคำถามง่ายๆ ว่า ความต้องการของลูกค้าข้อนี้จะทดสอบได้อย่างไรบ้าง?

10 นาที

เขียนเปิดบทความไว้แบบสุดโต่งมากๆ เลยว่า จะทดสอบอย่างไรให้รู้ผลได้ภายใน 10 นาที ก่อนไปมองหา Automate Testing Tools นะจ๊ะ

ถ้าสงสัยว่า แล้วไอ้ 10 นาที นี่มันเป็นตัวเลขที่มาจากไหน? คำตอบของผมคือ ไม่รู้ 🙂 หยิบมางั้นแหละ

แต่ขอไล่ลำดับตามแบบนี้นะครับ

  • Unit Testing เป็น Automate Testing หน่วยที่สร้างง่ายที่สุดและใช้เวลาในการทดสอบและได้ผลลัพธ์ต่อหนึ่ง Test Case เร็วที่สุดประมาณ milli-second
  • Integration Testing และ System Testing แบบ Automate Testing นั้นซึ่งต่อยอดมาจาก Unit Testing ในการทดสอบและได้ผลลัพธ์ต่อหนึ่ง Test Case เร็วที่สุดประมาณ milli-second ถึง second
  • Acceptance Testing แบบ Automate Testing นั้น ระบบที่เคยเข้าไปช่วยในหนึ่ง Test Case ให้เวลาในการทดสอบประมาณ Minute

เลยเป็นที่มาของตัวเลข 10 นาที ที่ผมนำมาใช้ในการตั้งเป็นตุ๊กตาไว้ แล้วก็กลับมาถามทีมเราว่าระบบที่เราสร้างหรือรับมอบต่อมาเพื่อดูแลนั้น เราสามารถที่จะทำการทดสอบทุกๆ ระดับของการทดสอบให้ได้ผลลัพธ์ภายใน 10 นาที ได้หรือไม่? โดยขอแบ่งขั้นตอนตามนี้

  1. ช่วยกันคิด วิเคราะห์และออกแบบมาว่าจะทำยังไงได้บ้างเพื่อให้เราสามารถรู้ผลของการทดสอบได้เร็วขึ้น
  2. มองหาว่าเราจะ Automate Testing ในบริเวรณของกลุ่มชุดการทดสอบได้อย่างไรบ้าง
  3. จากเทคโนโลยีที่ใช้ในการพัฒนาระบบมรเครื่องไม้เครื่องมืออะไรที่เหมาะสมไหมที่สามารถนำมาช่วยในการสร้าง Automate Testing หรือเราสามารถสร้าง Automate Testing ขึ้นมาเองได้ด้วยการเขียน Code ขึ้นมาเอง
  4. ลองทำดูแล้วใช้งานหาว่าช่วยลดเวลาในการทดสอบลงเพื่อให้เราได้รู้ผลลัพธ์มากขึ้นเท่าไร
  5. ปรับปรุงอย่างต่อเนื่องอยู่เรื่อยๆ เพื่อให้ Automate Testing ของเราใหม่สดเสมอและหากมีจุดใดที่จะลดเวลาลงได้เพื่อให้เรารู้ผลการทดสอบได้เร็วขึ้นจงทำ

สรุป

Automate Testing นั้นมีประโยชน์มากสำหรับ ทีมพัฒนาและดูแลบำรุงรักษาซอฟต์แวร์ ซึ่งไม่ใช่หน้าที่ความรับผิดชอบและดูแลโดยทีม Test นะจ๊ะ Automate Testing เป็นของทุกๆ คนที่เกี่ยวข้องโดย

  • รู้ก่อนว่าเราจะทดสอบอะไร
  • คิดและออกแบบการทดสอบ
  • มองหาว่าจะสามารถ Automate ได้ยังไงบ้าง
  • มองหาเครื่องไม้เครื่องมือเข้ามาช่วยทั้งแบบที่มีอยู่แล้วและสร้างขึ้นเอง

Automate Testing คือการลงทุน ดังนั้นให้พิจารณาด้วยอย่างมีสติว่า ระบบที่เราสร้างและดูแลอยู่นั้น คุ้มหรือไม่คุ้มที่จะลงแรงสร้างชุด Automate Testing ขึ้นมานะจ๊ะ

วันจันทร์ที่ 21 กันยายน พ.ศ. 2558 เวลา 10:50น.
หลักสี่  กรุงเทพมหานคร

Leave a Reply

Your email address will not be published. Required fields are marked *