[บันทึกเด็กข้างห้อง] Holistic Testing: Strategies for Agile Teams Day 2 #LearningWithSCK

ก่อนจะเข้า Module 3: Making Automation Work ก็เกริ่นก่อนว่า การทำงานแต่ละแบบของลุงทั้ง 17 ท่าน มีความเกี่ยวเนื่องเรื่อง Iterative and Incremental

เลยเล่าเรื่อง Iterative Development Model ให้ฟังก่อน 🔄

จากภาพ จะเห็นว่า เราต้องทำหลายสิ่งอย่างให้เสร็จใน 1 รอบการทำงาน จึงจำเป็นต้องเปลี่ยนบริเวณการทำการทดสอบให้เป็นอัตโนมัติ เพื่อผลักดันให้เราทำงานเสร็จในรอบ ไม่สามารถใช้คนทำได้ เพราะจะทำการทดสอบไม่ทัน

Product Owner ไม่ได้ถูกสร้างมาให้เขียน REQs อย่างเดียว ต้องให้น้ำหนักของ Technical Works ด้วย (Bugs ต่างๆ ก็ต้องมารวมใน Backlog เดียวกัน)

Iterative and Incremental Development ภาพเดิม ที่บอกเล่าคนละเรื่องราว

การทำ CI ไม่ต้องมี Jenkins ก็ได้ เพราะทุกเครื่องต้องรัน unit test และ E2E Business Test scenarios ได้

การอธิบายการทำงานของ Continuous Integration (CI) แบบที่คุณเม้งเป็น Repository

Module 3: Making Automation Work

🤖 ทำไมต้องทำ Automation? 🤖

1. Manual checking takes too long — การทดสอบแบบ Manual มันใช้เวลานานมาก กว่าจะรู้ผลลัพธ์
2. Manual checks are error prone — พออะไรมันขึ้นกับคน มันก็เกิด Human Error ได้
   ลองคิดถึงเครื่องซักผ้าที่บ้าน ว่ามี Burnout ไหม เวลาทะเลาะกับแฟนมีความเศร้าไหม ซึ่งสิ่งเหล่านี้มันเกิดกับคน
3. Frees people to do their best work (testing) — เอาศักยภาพไปทำอย่างอื่น ถ้ามันต้องทำการทดสอบซ้ำๆ ก็เอาคนออก แล้วเอาเครื่องมือเข้าไปช่วย
4. Provides ‘living documentation’ — การทดสอบล้อไปกับ REQs ถ้า REQs เปลี่ยน Test Scenarios ต้องเปลี่ยนตาม
5. Repeatable — ทำซ้ำได้
6. Saves time — ลดเวลาลง

แต่มันไม่ได้ง่าย เพราะ

• มีเรื่องของความกลัวเกิดขึ้น กลัวว่าจะทำงานไม่ทัน กลัวการใช้เครื่องมือ เพราะมันยาก หรือเพราะต้อง Coding
• เปลี่ยน UI ปุ๊บ ก็ต้องเขียน Test Script ใหม่ปั๊บ
  - Tool ที่ฮิตตอนนี้คือ Robot framework ซึ่งตัวนี้ Test Web ไม่ได้ ต้องติดตั้ง Selenium library เพิ่ม
  - ซึ่งถ้าทีม UX/UI ไม่ได้ใส่ ID มา ทาง FE และ QA ก็ต้องใช้ Figma ให้เป็น แก้ได้ หรือถ้า FE ก็ไม่ใส่มา ความยากลำบากก็จะตกกับ QA ต่อในการหา Location
  - UI มีอายุขัยสั้น ถ้าเอา object ออกไปเลย ก็คือทิ้ง Script แล้วเขียนใหม่
  - UI บางหน้ามีหลาย Layer ซ้อนทับๆ กันไปอีก
  - UI Test ลงทุนเวลาเยอะมาก แต่ผลตอบแทนต่ำ เพราะมันช้า เนื่องจากต้องเปิดหน้าจอและรัน Integration ทั้งหมด
  - แต่ถ้าจำเป็นต้องทำ ก็ทำเฉพาะ Success Scenario เดียวพอ

• เงินมีให้ไหม เพราะเราต้องรวยระดับหนึ่ง ต้องใช้ Tools ต้องมีการเตรียม Infra และให้ผู้เชี่ยวชาญข้างนอกมาช่วย
• มีเวลาไหม โครงการเร่งขนาดไหน เวลาไม่พอ ทำ Manual ก่อนแล้วค่อยมาตามเก็บ Automation ซึ่งไม่ช่วยอะไร

ทุกอย่างคือการลงทุน

• ในช่วงต้น ช่วงไต่เขา จะต้องเจอกับ การปรับแก้โค้ด ยิ่งโค้ดเป็นของเดิมอยู่มานาน ก็ต้องแกะ ซึ่งบาง Technology Stack ก็อาจจะยากมาก หรือไม่เหมาะ
• การใช้เครื่องมือ ที่ต้องรู้จักมากกว่าหนึ่งตัว
• Infra พร้อมไหม ที่จะให้ทดสอบซ้ำๆ ได้ ระบบต้องมีการเพิ่ม/ลบฐานข้อมูล เราสามารถเข้าไปจัดการได้ไหม นอกจากระบบเราเองแล้ว ถ้าเราต้องต่อเชื่อมกับคนอื่น เราเข้าไปจัดการด้วยได้ไหม
• มีเวลาให้ทำไหม
• จุดคุ้มทุนคือช่วงท้ายๆ ที่ทำมาระยะหนึ่งแล้ว ซึ่งจากที่พี่หนุ่มเคยทำให้บริษัทลูกค้า ใช้เวลาประมาณ 7 เดือน
• แต่ถ้าทุกอย่างถูกเก็บไว้กับ QA คนเดียว มันจะค่อยๆ หายไปตามกาลเวลา เพราะไม่มีใครใช้งาน ไม่มีใครดูแลต่อ
• จาก Production สู่ Operation แล้วก็ตายจากไป

คำนวณความคุ้มทุน ในการลงทุนทำ Automation

🔺Test Automation Pyramid 🔺 — Mike Cohn

https://www.luxoft-training.com/news/the-test-automation-pyramid/

• สามเหลี่ยมเป็นตัวแทนของ Test Scenarios ที่ต้องมี แปลว่า UI ข้างบนต้องน้อยมากๆ ถ้ามี เอาแค่ 1 Test Scenario — Success
• ก่อนจะลงมือทำ ต้องขอดู High level Architecture ก่อน

• แล้วต้องรู้ End-to-End Business Process ด้วย หาได้จาก Swimlane หรือ Sequence Diagram ที่มีก่อน (เปิดตัวอย่างงานจริงให้ดู)
• ซึ่ง E2E จะแยกออกเป็นสองส่วน คือ ผ่านทาง UI และ ผ่านทาง API

• Tester ไม่ใช่คน Test UI ต้อง Test เงื่อนไขทางธุรกิจ ด้วย Test source code
• การทดสอบประเภท กรอกอะไรได้ไหม Validation ต่างๆ อักขระนู่นนี่ได้ไหม อันนี้หน้าที่ FE ที่ต้องเป็นคนทำ Unit Test มา แต่ทั้งนี้ก็ขึ้นกับหัวหน้างานและบริษัทที่สังกัดอยู่ด้วย
• ถ้าจะทำ Automation แนะนำให้ลงทุนทำที่ API ⭐ ทั้ง Success และ Alternatives
• Unit Tests คือหน้าที่ของ Function ( ) มีหน้าที่คำนวณ หรือมีหน้าที่ทำงานตามตรรกศาสตร์ True/False ต่างๆ

“ดันการทดสอบทุกอย่างลงมาให้ต่ำที่สุด”

Test Structure ทั้ง UI และ API

ต้องเข้าใจโครงสร้างพื้นฐานของเครื่องมือทุกตัว

องค์ประกอบของมันจะมีอยู่ 3 ส่วน

Tests / Examples (Test Scenarios)

• ที่ SCK เราจะเรียก Test cases เมื่อเป็นระดับ unit test หรือ Integration test

• Test Scenarios คือ สิ่งที่ร้อยเรียงเป็นเรื่องราว การเอา Test cases ย่อยๆ มารวมกันเป็นเซ็ต
• Test Scenarios มาจากการวิเคราะห์และออกแบบโดย QA หรือ Software Tester หรือ xA (เช่น BA, SA)

Tests Method

• ถ้าใช้คน ‘Passes to’ คือใช้คนทำงาน 🧑‍💻
• แต่พอเป็น Automation คือเอาคนออก แล้วใช้เครื่องมือทำงานแทน 🤖
• ถ้ามีประสบการณ์ ทำซ้ำๆ ใช้หลายๆ Tools แล้วเข้าใจภาพนี้ เราสามารถสร้าง Automation Tools ขึ้นมาใช้เองได้
• ต่างประเทศจะมีตำแหน่ง Software Development Engineer in Test (SDET) คือตำแหน่งที่เขียน Tool มาใช้ให้ง่าย และให้เข้ากับบริบทของธุรกิจ เช่น สร้างผลิตภัณฑ์แว่น AR ก็จะมีคนนี้แหละ มาเขียนเครื่องมือเพื่อให้เกิดการทดสอบได้ ในต่างประเทศมีนานแล้ว แต่ในไทยยังเห็นไม่ชัด

System Under Test (SUT)

• เราต้องรู้โครงสร้างของระบบเราก่อน เราจะทดสอบระบบเรา หรือทดสอบระบบอื่น
• จะต้องเตรียมระบบที่มีรูปร่าง หน้าตา ที่มีโครงสร้างที่ใครบางคนออกแบบขึ้นมา
• ถ้าเป็นเว็บไซต์ ต้องรู้ URL
• ถ้าเป็น API หรือ Service ต้องรู้ end point ของ API นั้นๆ
• SUT จะมาพร้อมกันกับ Tests / Examples (Test Scenarios) มันต้องเอารายละเอียดพวกนี้ไปอยู่ในเอกสารด้วย
• ปัญหาที่เจอคือ Testers ระบุ URL ไม่ได้ตั้งแต่ต้น เพราะ Infra ยังไม่ทำ หรือเพราะไม่รู้ต้องเอาจากใคร

🎯 เป้าหมายของ Automation Tests 🎯

Structure of Automated Testing

3A เป็นโครงสร้างของ Unit Test แต่พี่หนุ่มเอามาปรับใช้กับ Layer อื่นด้วย

Arrange

• ต้องทำการ setup ระบบ xUT ขึ้นมา (x under test) ต้องใช้ Tool หนึ่งตัวในการสร้างมันขึ้นมา
• ต้องทำ Test Data ทิ้งไว้ มีการโยน Data ที่สัมพันธ์กับ Test Scenarios เข้าไปทุกครั้ง ก็ Tool อีกตัว
• เตรียม Dependencies ที่เราต้องไปเชื่อม ก็ใช้ Tool อีกตัว

Act

• ทำการทดสอบที่ xUT

Assert

• เทียบ Expected Results กับ Actual Results

อธิบายโครงสร้างของ Automated Testing

• เอา Tool เข้ามาช่วยในส่วนของการเตรียมการ Infra as a source code
• Tester ผู้ไม่รู้หรอกว่า ด้านหลังมีโครงสร้างการทำงานอย่างไร รู้แค่ว่า เข้าแบบนี้ต้องออกแบบที่อยากได้ แล้วตรวจดูว่า Expected = Actual ไหม
• พอจะไปทำ Automation สิ่งที่เราต้องรู้ก่อนคือ Version ของ FE และ BE เรากำลังทำการทดสอบกับ Version ไหนอยู่ และโครงสร้างของ Database (หากมีการปรับเปลี่ยน)
• จากนั้น Test Scenarios จาก Excel จะถูกเปลี่ยนเป็น Test Source code
• Test Scenarios ของที่ SCK มีทั้ง Success และ Alternatives ที่ไม่ตรงตามเงื่อนไขธุรกิจ และ Failed เพราะ System ด้วย

• เอา Tool ก็ไปทำหน้าที่ตรงส่วนความฉลาดที่เป็น Logic (Web Server) เลย

Automation ไม่ใช่แค่การใช้ Tool
ทุกคนต้องเป็นเจ้าของในการสร้างและดูแล ต้องมี coding standard
ถ้าทำ Automation ดี ก็ไม่ต้องเขียน Defects Report

อะไรบ้างที่เราควรต้อง Automate?

1. Task อะไรที่มันทำซ้ำๆ
2. อะไรที่มนุษย์ทำแล้ว มีความน่าจะเป็นที่จะเกิด error
3. Builds และ Deployments
4. Smoke Tests ในชีวิตจริง คือ ติดตั้งเครื่องดูดควัน จุดธูปเพื่อให้มันมีควัน ใน software testing ของพี่หนุ่มคือ cut ตัวแทนของ scenarios ที่คิดว่า รันแล้วน่าจะสบายใจ มักจะใช้ในการ deploy production (อาจจะเคยได้ยิน rehearsal)
5. Parsing, Comparing output การเปรียบเทียบข้อมูล ถ้าใช้เครื่องมือจะช่วยตรวจ whitespace ได้ ถ้าตรวจด้วยตาอาจจะมองไม่เห็น
6. Automating tasks for business พวก RPA ทั้งหลาย เช่น ปั๊ม Stat, Data Input

อะไรที่เราไม่ควรพยายามทำให้เป็นอัตโนมัติ

1. Tests that are really expensive ทำไปแล้วแพงมาก ไม่คุ้มทุน
   สิ่งที่ไม่ควรทำอย่างมากคือ Authentication OTP (ให้มัน bypass ไปเลยได้ไหม?)
2. One-off tests ทำไปแล้วใช้ครั้งเดียว
3. Tests covered elsewhere
4. Usability tests / look and feel
5. Exploratory testing
6. Customer ad-hoc testing

สิ่งที่ต้องพึงระวัง

Automating end to end tests

1. การทดสอบผ่าน User Interface มันช้า (มากๆ)
   ถ้ามันช้า ก็หาสาเหตุ แก้ที่มันช้า ไม่ใช่ใส่ Wait รอ
2. การทดสอบที่ต้องไปต่อกับ Database ก็ช้า
3. Aim for minimum feature coverage
4. Don’t go overboard, automating every path

เรื่องสำคัญคือ Test Data

เพราะเวลาที่เรา Test สิ่งที่มันเกิด จะมีเรื่องการ Select Data ขึ้นมาแสดง แต่ถ้ามี เพิ่ม/ลด/ปรับ/แก้ มันจะทดสอบซ้ำไม่ได้ ดังนั้น สิ่งที่ต้องทำก็คือ

1. หลีกเลี่ยงการต่อ Database เท่าที่จะทำได้ ในระดับ Unit test หรือ API test สามารถใช้ memory database แทน
2. ต้องมีการเตรียม Data เซ็ตเริ่มต้นของแต่ละ Scenarios พอทำการทดสอบเสร็จแล้ว Data มีการเปลี่ยน ก็ต้อง Set กลับมาให้เป็นจุดเริ่มต้น ที่เรา Design ไว้ตาม Test Scenarios ทุกครั้ง
3. ให้ใช้ Data เหมือน หรือเทียบเท่า Production (เพื่อไม่ให้ผิด PDPA อย่าลืม Masking Data ด้วย)
   ในเชิง functional อาจจะตัดข้อมูลลงมาทำ ปริมาณไม่เท่าไหร่
   แต่ถ้าจะทำ performance test ปริมาณข้อมูลต้องเท่าๆ กันกับ Production และต้องเพิ่ม Growth rate ในอนาคตที่เราคาดหมายด้วย (ต้องรวย!)

System Impacts

การทำ Automation ต้องดู System Impacts กับ ระบบภายในของเราเอง และ ระบบรอบข้างที่ต่อเชื่อมกับเราด้วย

• การล่ม การร่วง
• ข้อมูลที่เราทดสอบ มันจะซ้ำๆ เรื่อยๆ ยัดเข้าไปใน Database เขา ต้องดูว่าระบบเขาเอาไปทำ Report ต่อหรือเปล่า
• ถ้ามันทำไม่ได้ อาจจะต้องทำการจำลองใน Dev และ SIT แล้วค่อยต่อจริงตอน UAT ซึ่งก็ต้องคุยกันตอนต้นว่าจะจัดการเรื่องพวกนี้อย่างไร
• เลยเป็นที่มาว่า ทำไมเราต้องรู้ Architecture Design ด้วย
• นอกจากนี้ก็ต้องรู้ connection ต่างๆ เช่น มีการต่อไปหาดาวเทียม มันต่อจริงไม่ได้ แล้วต้องจำลองอย่างไร
• เราต้องรู้พฤติกรรมของระบบที่เราไปต่อเชื่อมด้วย เช่น low peak, high peak เพราะตอนที่เราทดสอบ เราก็ต้องทำให้เหมือน (สร้าง Stunt Man มาทำงานแทนตัวจริง เพราะฉะนั้นทุกอย่างต้องใกล้เคียงตัวจริงมากที่สุด)

Synchronous and Asynchronous

https://www.koyeb.com/blog/introduction-to-synchronous-and-asynchronous-processing

https://www.freecodecamp.org/news/tcp-vs-udp/

• Asynchronous สั่งแล้ว ไม่รอฟังผล
• Synchronous สั่งแล้ว แสดงผลลัพธ์ให้เห็น (หรือรับคำสั่ง)
• UDP มีการสั่ง แต่ไม่ระบุตัวตน ซึ่งพี่บอย Assume ได้ว่า UDP คือ Asyn

แสดงการใช้งาน Tools ต่างๆ

พี่บอยใช้ command line ในการสั่ง start ส่วนต่างๆ ขึ้นจากเครื่องตัวเอง ทำให้พร้อมใช้ก่อนเริ่มงานใน Sprint 1 (หรือถ้าเอาแบบสุดโต่ง ต้องได้ตั้งแต่วันแรกของการเริ่มต้นโครงการ)

Unit Test

• การทดสอบ function หรือ method เป็นการทำงานส่วนเดียว เอาโค้ดชิ้นเล็กๆ มารัน
• เป็นการลงทุนที่คุ้มค่าที่สุด เพราะมันทำงานเร็วมาก ไม่มีค่าใช้จ่ายเพิ่ม เพราะเหมารวมในการจ้างงาน Dev อยู่แล้ว
• ต้องดูว่า Dev ที่เรามี ดีไซน์และเขียนเป็นไหม ถ้าไม่เคยทำ ก็ต้องใช้เวลาในการบ่มและฝึก ให้ทำทุกวัน วันละชั่วโมง เป็นเวลาอย่างน้อย 3 เดือน ฝึกคนเดียวไม่รอด แนะนำฝึกเป็นฝูงกับเพื่อนในทีม (Coding Dojo)
• ถ้าในบริบทของ Scrum คนฝึกทีมต้องเป็น Scrum Master ที่เป็น Dev มาก่อน เคยทำแบบนี้อยู่แล้วเป็นปกติ มาฝึกให้ทีมทำเป็น ทำให้ทีมเก่งขึ้น ถ้าที่ออฟฟิศปกติก็คือชาว Tech Lead

ยกตัวอย่าง Unit Test (ไม่ได้ง่ายนะครับบบบบ) เขียนแยกส่วนย่อย เขียนให้รู้เรื่องว่าเราต้องการทำอะไร จากภาพ บรรทัดที่ 81–98 = Arrange

บรรทัดที่ 100–103 = ส่วนที่ทำการทดสอบ (Act) | บรรทัดที่ 105 = ส่วนเทียบ Expected กับ Actual (Assert)

Unit Test Result ที่รันเร็วแบบจัดๆ

Robot Framework

• โดยใช้ selenium library
• เปลี่ยน Test Scenarios ที่อยู่ใน Excel เป็น Source Code
• รันแบบเปิด browser พี่หนุ่มเรียกบาป ให้ใช้ headlesschrome เข้าไป
• จะเปิด หรือไม่เปิด ก็ได้ผลลัพธ์ออกมาเหมือนกัน
• เป็น Tool ที่ใช้ Learning Curve น้อยสุด (ไม่เทียบกับ Katalon — แต่ตัวนี้ก็มีข้อจำกัดของมันอยู่)

ฝั่งซ้ายเขียนให้รู้เรื่อง ให้ Business User อ่านได้ | ส่วนฝั่งขวา เป็นหน้าที่ของ Dev, QA — ในเว็บ robot framework ก็บอกให้เขียนแบบนี้

• ถ้า UI ใช้ robot framework แล้ว API ก็ควรใช้ robot framework เช่นกัน
• ยิ่งใกล้ code มากเท่าไหร่ การเขียน automation จะเป็นภาษา programming มากขึ้นเท่านั้น

การทดสอบระดับ API โดยใช้ request library

Postman

• หน้าสดของ postman คือ Code ที่อ่านยาก เขาก็เลยทำออกมาให้เป็น GUI
• ตอนนี้ที่เราเจอคือ ทำ 1 collection แล้ว test เส้นใครเส้นมัน แต่ที่ SCK ทำ collection ให้เป็น flow ของ test scenarios
• Mock time คือให้ วัน/เวลา เป็นตัวเดิมเสมอ ต้องคุยกับ Dev ก่อนทำการเขียนโค้ด เพื่อให้ทำการทดสอบซ้ำได้ และต้องคุยกับ Infra กับ Security ของบริษัทด้วย
• ถ้า Test Mode = True ก็ Inject เวลาเข้าไป แต่พอขึ้น Production ก็เปลี่ยน Test Mode = False
• Input ของ Postman มีสองส่วนคือ Test Scenarios และ API Specification
• Postman ถ้าจะให้คุ้ม เขียน Script เดียวแล้วหมุน Data เอา

รู้ก่อนว่าเราทำงานกับอะไร Tech Stack อะไร ควรใช้ Automation Tools อะไร ไม่ต้องไปตามชาวบ้านเขา

Mock/Stub จำลองพฤติกรรมระบบข้างเคียง

Mountebank

• เป็น open source มีหนังสือให้อ่าน
• คนทำ Tool นี้ขึ้นมา เคยใช้ตัวอื่นมาแล้วแต่ไม่ตอบโจทย์ เพราะงานของเขาเป็นการทำเกี่ยวกับ Legacy เช่น SOAP, ต่อ Socket ก็เลยสร้างเองซะเลย
• ต้องรู้ก่อนว่า แต่ละเส้นจากระบบเราที่เชื่อมต่อไประบบอื่นต่อกันรูปแบบใด (Protocol, Port, Method, Path, Status, API Spec เป็นต้น) พฤติกรรมของระบบเขา และ Test Scenarios
• พอองค์ประกอบครบ ก็โยนของพวกนี้เข้าไปในเครื่องมือ
• โครงสร้างเป็น JSON
• Environment เดียวกัน ต่อที่เดียวกัน เช่น SIT-SIT, UAT-UAT

Docker และ Docker Compose

• Tool ที่อยู่เบื้องหลังการรันซ้ำได้
• Initial แล้วเอา Data ใส่เข้า สั่งรัน Newman, Postman อะไรต่อมิอะไรอีกที
• พอ Start อะไรต่างๆ มาเรียบร้อยแล้ว ก็ค่อยยิงคำสั่งการทดสอบจาก Tool อื่นเข้าไป
• ตอนนี้พี่บอยกำลังทำ CI แบบเนียนๆ ไปแล้ว

การทำงานแบบ Agile หรือ Scrum ที่ทำงานเป็น Sprint ด้วยกลไกของการทำงานที่รอบการทำงานเหลือแค่ 10 วัน มันเลยไม่สามารถทำการทดสอบโดยใช้คนได้ เลยต้องเอา Tools เข้ามาช่วยให้ได้มากที่สุด

Jenkins

• เป็น CI Tool หนึ่งตัวในหลากหลายตัวที่มี
• ถ้าทำ CI นี่คือขั้นตอนต่างๆ ที่ควรต้องมี (ยกตัวอย่างในภาพ พี่บอยบอกว่า ลอกจากหนังสือ CI/CD มา) จะสังเกตได้ว่า จากด้านซ้ายไปด้านขวา ความเร็วจะต่างกัน อันไหนเสร็จเร็วกว่าจะมาอยู่ด้านซ้าย เพื่อให้ได้ Feedback Loop ที่เร็ว และต้นทุนต่ำ
• ขั้นตอนอะไร ควรมี ไม่มี ขึ้นอยู่กับงานที่เราทำว่าต้องการทดสอบอะไรส่วนไหน ซึ่งต้องคุยกันตั้งแต่ช่วงต้นโครงการ
• ซึ่งกว่าจะออกมาหน้าตาดูง่าย ก็ต้องผ่านการเขียนโค้ดก่อน

Jenkins (CI)

Azure DevOps และ Pipeline

• ก็เป็น CI Tool อีกตัวหนึ่ง
• คุณเม้งบอกว่าไม่ได้รันจัดเต็มเท่าพี่บอย เลือกว่า เราต้องการทดสอบอะไร เราอยากเห็น Information อะไร
• ถ้าขั้นตอนไหน Fail โดยปกติ ขั้นต่อไปจะไม่ทำงานต่อ
• สามารถดู Report ได้ว่าเคสไหนที่ไม่ผ่าน
• รันที่เครื่องผ่าน → Push → CI Server เป็น Information กลางของทีม ถ้าเจอว่ามี Bugs ก็ย้อนกลับมาดู Source Code ที่ Change ได้

Reflect ตัวเอง

• ก่อนจะลงมือทำอะไร ต้องรู้จักระบบของตัวเองก่อนว่าทำอะไร ต้องการได้ผลลัพธ์อะไรจากการทำ Automation Test ความคุ้มทุนในการทำ สภาพปัจจัยอะไรต่างๆ เอื้อต่อการทำหรือไม่ ถ้าคิดจะทำ ทุกอย่างต้องมีการวางแผนล่วงหน้า ต้องมีการสร้างข้อตกลงร่วมกัน ต้องไปคุยกับชาวบ้านที่เกี่ยวข้อง เพื่อให้การลงทุนทำมันได้ใช้งานจริงๆ และมีความยั่งยืน
• มีความ “เอ๋อ” เยอะกว่าเมื่อวานมากๆ บางทีก็สงสัยว่า ความรู้ที่เคยได้เรียนมา สมัยมหาวิทยาลัยนั้น มันหายไปไหนหม้ดดดด แต่หากพูดกันตามจริง เมื่อครั้งกระนู้น เทคโนโลยีมันก็ไม่ได้มีเยอะแยะอะไรขนาดนี้ ช่วงเวลาเปลี่ยนผ่านสิบปีนี่ เป็นอะไรที่หน้ามือเป็นหลังมือมาก (คอนเฟิร์มโดยพี่บอย)
• ตั้งแต่เรียน จบมา ทำงาน ยังไม่เคยเจอการทำ Automation Test แบบจริงจังเลย มาเจอที่ SCK นี่แหละ (แต่ถ้า Manual Test นี่ของถนัด แม้จะเน้นกดไปกดมาแล้วระเบิดก็ตาม) วันนี้ถือว่า “ได้แค่รู้จัก” แต่ยังทำเองไม่ได้ ทำไม่เป็นต่อไป
• ถ้ายังอยู่ในวงการนี้ ก็ต้องเรียนรู้ พัฒนาตัวเองกันอยู่เรื่อยๆ นะทุกคน เป็นกำลังใจให้ตัวฉันเอง

บทความของ Day1 อยู่ตรงนี้