Tag Archives: Software Tester
วิธีสลัดเรื่องไร้สาระออกจากใจ
ห่างหายไปนานเลยที่ไม่ได้มาเขียนเรื่องลงใน We Love Bug แต่ยังมิได้ล้มหายตายจากไปไหนนะครับ ทั้งผู้เขียนเอง และสมาชิกท่านอื่นๆ ต่างติดภาระหน้าที่ทั้ง งานราษฎร์ และงานหลวง จึงไม่ได้เข้ามาเขียนเรื่องต่างๆ ให้ท่านผู้อ่านทุกๆ ท่าน เลยจะดูเหมือนว่า We Love Bug เริ่มจะแผ่วๆ แล้ว แต่ไม่เป็๋นเช่นนั้นนะครับ เราจะมีเรื่องต่างๆ มาลงอยู่เรื่อยๆ ครับ
ระหว่างนั่งทำงานอยู่นั้น MSN ก็แจ้งว่ามีเมล์ใหม่เข้ามา ก็เลยกวาดสายตาดู ก็ไปสะดุดตาที่อีเมล์ฉบับหนึ่ง “FW: วิธีสลัดเรื่องไร้สาระออกจากใจ” ก็เลยลองเปิดอ่านดู อ่านแล้วก็แบบ เออ…น่าสนใจดี เลยหยิบมาแบ่งปันให้ทุกๆ ท่านได้อ่านกัน และแนบไฟล์ PDF มาให้ด้วย เผื่อว่าอยากจะได้เอาไปเผยแพร่ หรือส่งต่อให้กับเพื่อนพ้องน้องพี่ทั้งหลายในโอกาศต่อๆ ไป
วิธีสลัดเรื่องไร้สาระออกจากใจ
Don’t Sweat the Small Stuff
บทความที่นำเสนอจากหนังสือเรื่อง Don’t Sweat the Small Stuff แต่งโดย Richard Carlson
ผู้แต่งเชื่อว่านิสัยเกิดจากการกระทำสิ่งใดสิ่งหนึ่งครั้งแล้วครั้งเล่า
นิสัยเหล่านี้จะเกิดขึ้นเองตามสภาวะธรรมชาติและเกิดขึ้นบ่อยครั้งเสียจรเราไม่รู้สึก
ว่าเป็นสิ่งผิดปกติหรือเป็นสิ่งที่ต้องแก้ไข
แต่หารู้ไม่ว่านิสัยที่ไม่ดีของเราเหล่านี้จะเป็นตัวบั่นทอนพลังชีวิต
ทำให้เราหมดกำลังใจ และทำให้เราเป็นคนมองโลกในแง่ร้าย ดังนั้น
ผู้แต่งจึงชี้ให้เห็นนิสัยที่ไม่ดี และทิจฉาทิฏฐิที่ควรแก้ไข ดังนี้
We Love Bug Cafe: วันจันทร์ที่ 10 มีนาคม 2551
ห่างหายไปนานเลยที่ไม่ได้เข้ามาเขียนบทความลงใน We Love Bug ไม่ต้องตกใจนะครับว่าเหล่าผู้เขียนต่างๆ หายไปไหน ต่างก็ติดงานติดการที่จะต้องรับผิดชอบกันตามหน้าที่อยู่ แต่เมื่อทุกๆ คนมีเวลาว่างก็จะมาแบ่งปันประสบการณ์ และความรู้ต่างๆ ของ Software Testing
ในรอบสองอาทิตย์ที่ผ่านมาก็มีบทความใหม่ๆ จากเหล่าผู้เขียน
- Behavior Driven Development (PunNeng)
- Test first tools (PunNeng)
- Software Testing Life Cycle ตอนที่ 1 (Zyracuze)
และก็มีบทความที่ไม่เกี่ยวกับ Software Testing อยู่บ้าง เพื่อไม่ให้รู้สึกว่ามีแต่เรื่องของ Software Testing แต่เพียงอย่างเดียว
- กว่าจะมาเป็นโลโก้ กูเกิล (Zyracuze)
เพิ่มเติมขึ้นมาก็ในส่วนของประวัติของสมาชิก เพื่อจะได้รู้จักที่มาที่ไปกันมากขึ้น เผื่อจะต้องพึ่งพาอาศัยกัน ก็เปิดประเดิมด้วยประวัติย่อๆ ของผมเอง และคุณอ๋อง
ก็จะมีประวัติย่อๆ พอหอมปากหอมคอ ของเหล่าสมาชิกเพิ่มเติมเข้ามาเรื่อยๆ ในคราวต่อๆ ไป
ขอพลังจงสถิตย์อยู่กับเหล่า Software Tester ทั้งหลายครับ (May the Force Be With Software Tester)
Zyracuze
We Love Bug Cafe: วันจันทร์ที่ 10 มีนาคม 2551
Volume 01 Number 03
Testing Doesn’t Finish…It’s Just STOP! 
Software Testing Life Cycle ตอนที่ 1
สืบเนื่องจากคำถามที่คุณ Pooky มาฝากไว้ในบทความเรื่อง Test first is not hard
ใครก็ได้ช่วย Guide หน่อยว่า Scope and Step ของการทํางานตําแหน่ง Tester เนี้ย ต้องทําอะไรบ้าง
รบกวนช่วยเรียงลําดับเป็นข้อๆ เอาแบบละเอียดๆ หน่อยนะค่ะ พอดีงานที่เคยทํามาทําควบคู่ 2 ตําแหน่งค่ะ
คือ ป็น Project Coordinate and Tester แต่ตอนนี้กําลังจะเริ่มทํางาน Tester โดยตรง
อยากทราบว่างานที่ควรทําก่อนและหลัง(เป็นลําดับ) ของ Tester มีอะไรบ้าง และ Tester ต้องเข้าไป
มีส่วนเกี่ยวข้อง Part ไหนของ วงจร SDLC
Software Testing Process ที่ผู้เขียนนำเสนอนั้น ถูกพัฒนาและปรับเปลี่ยนมาในช่วงระยะเวลา 3 ปีที่อยู่ในงานด้าน Software Testing ซึ่งเริ่มต้นจากการตั้งทีม Test , ตั้ง Process ของ Software Testing และหาสมาชิกเข้ามาร่วมทีม ประเภทของ Software ที่ถูกส่งเข้ามา Test เป็์น Website และ Software ที่ทำงานกับ Website
บทความชุด Software Testing Life Cycle นี้จะแบ่งออกเป็น 5 ตอน ซึ่งผู้เขียนจะนำเสนอตั้งแต่ภาพรวมของ Life Cycle จรถึงรายละเอียดของส่วนต่างๆ เพื่อให้เห็นภาพ และสามารถนำไปประยุกต์ หรือเป็นตัวอย่างได้ไม่มากก็น้อย สำหรับผู้เยี่ยมชมที่ทำงานในสายงาน Software Testing เช่นเดียวกัน
กว่าจะมาเป็นโลโก้ กูเกิล
ห่างหายไปเกือบสองอาทิตย์ที่ไม่ได้มาเขียนบทความลงใน We Love Bug นะครับ ต้องขอโทษด้วยจริงๆ เนื่องจากติดภาระกิจร้อยแปดพันเก้า แต่ก็แอบดีใจที่ยังมีผู้สนใจเข้ามาเยี่ยมชม และมีสมาชิกใหม่ๆ สมัครเพิ่มเติมขึ้นมา รวมทั้งน้องเหน่ง (PunNeng) เข้ามาเขียนบทความลงเรื่อยๆ ทุกๆ วันพุธ ขอบคุณน้องเหน่ง ณ ที่นี้ด้วยนะครับ
หลังจากพูดคุยกับคุณอ๋อง (Leeyongson) ก็เลยเห็นชอบกันที่จะเปิดหนึ่งหมวดสำหรับเรื่องที่น้องเหน่งเขียน เลยจัดหมวด “Unit Testing” ขึ้นมาให้กับบทความที่เกี่ยวกับการทำ Unit Testingก็ขอเชิญทุกๆ ท่านที่สนใจเรื่องของ Unit Testing สามารถแวะเข้าไปเยี่ยมชมได้ รวมทั้งผู้ที่ต้องการจะแบ่งปันประสบการณ์ในส่วนของการทำ Unit Testing ด้วยเช่นกันครับ
ขณะที่เขียนบทความนี้อยู่ กำลังอยู่ใน Mode อู้งาน แอบเบียดบังเวลางานมาเขียนเรื่องลง We Love Bug ซะงั้นครับ กลับเข้าเรื่องเลยละกัน พอดีได้รับ Forward Mail มาจากพี่ที่รู้จักกันคนหนึ่ง ซึ่งไม่ได้เกี่ยวอะไรกับ Software Testing เลย แต่ก็หยิบมาฝากทุกๆ ท่านดูครับ
Google คงไม่มีใครไม่รู้จักคำนี้ และไม่มีใครเคยใช้บริการของเค้า ลองมาดูซิว่า กว่าจะมาเป็น Logo Google ตัวที่ใช้อยู่บนเว็บของเค้านั้น มี Design ออกมากี่แบบ
We Love Bug Cafe: วันจันทร์ที่ 18 กุมภาพันธ์ 2551
เข้าสู่วันจันทร์ของสัปดาห์ที่ 8 ของปี พ.ศ. 2551 ก็หวังว่า Software Tester ทุกๆ ท่าน คงจะมีพลังเต็มเปี่ยมที่จะพร้อมไล่จับแมลงทั้งน้อยใหญ่นะครับ เนื่องด้วยช่วงเสาร์อาทิตย์ที่ผ่านมาค่อนข้างจะยุ่ง เลยไม่ได้มีเวลาเข้ามาเขียน ก็เลยแอบอู้ ใช้เวลาในงาน มานั่งเขียน Cafe ก่อนที่จะลืมไปนะครับ
ในรอบสัปดาห์ที่ผ่านมาก็มีบทความใหม่เข้ามาอีก 2 บทความจาก คุณอ๋อง (Leeyongson ) และเหน่ง (PunNeng) ก็ลองติดตามอ่านกันดูนะครับ
- “What is User Acceptance Test” “มาทำความรู้จัก กับ User Acceptance Test กันเถอะ” (Leeyongson )
- Test first is not hard (PunNeng)
ในสัปดาห์นี้ก็น่าจะมีบทความใหม่ๆ เพิ่มเติมขึ้นมาประมาณ 2 -3 บทความโดยหลักๆ เป็นเรื่องของ Performance Testing และ User Acceptance Testing ก็ลองเข้ามาติดตามดูกันได้นะครับ
เช่นเดิม
สำหรับผู้ที่มีคำถามต่างๆ เกี่ยวกับ Software Testing ที่ต้องการให้ทีมงาน We Love Bug ช่วยเหลือ หรือต้องการให้นำเสนอ
บทความใดๆ สามารถเข้าส่ง Email มาถึงเราได้ที่ welovebug@sanook.com หรือแจ้งไว้ที่ส่วนของ แสดงความคิดเห็น ได้เช่นกัน
สำหรับผู้ที่อยู่ในสายงานของ Software Testing หรือผู้ที่สนใจ สามารถเข้ามาร่วมใน We Love Bug เพียงแค่ สมัครสมาชิก และต้องรบกวนแจ้งมาที่ทีมงานในกรณีที่ท่านต้องการที่จะร่วมเข้าเขียนบทความ โดยส่ง Email มาที่ welovebug@sanook.com
สำหรับผู้ที่สนใจรับข่าวสารเมื่อมีบทความใหม่ๆ สามารถสมัครรับข่าวสารผ่าน Email ที่ส่วนของ Side Bar > STAT
ขอให้สนุกสนานกับงานการที่รออยู่ในวันจันทร์นี้ครับ :#1:
Zyracuze
We Love Bug Cafe: วันจันทร์ที่ 18 กุมภาพันธ์ 2551
Volume 01 Number 02
Testing Doesn’t Finish…It’s Just STOP!
“What is User Acceptance Test” “มาทำความรู้จัก กับ User Acceptance Test กันเถอะ”
หลังจากที่ทิ้งท้ายกันไว้คราวก่อน ก็ถึงเวลาแล้วที่จะมารู้จักความหมายของ User Acceptance Test รวมถึงประเด็นสำคัญที่น่าสนใจอะไรบ้าง
What is “User Acceptance Test”
จากประสบการณ์การทำงานของผู้เขียนโดยตรงในงาน UAT ผู้เขียนจึงได้กลั่นกรองและขอนำเสนอความหมายของ UAT ว่าเป็นอย่างนี้ค่ะ
“User Acceptance Test” เป็นกระบวนการทดสอบระบบขั้นตอนสุดท้ายเพื่อให้แน่ใจว่า ระบบที่พัฒนาพร้อมที่จะใช้งานได้จริง ตรงตามกระบวนการทาง ธุรกิจ (Business Process) และความต้องการของผู้ใช้งานที่ได้กำหนดไว้ (Software Requirements) โดยผลลัพธ์การทดสอบจะต้องเป็นไปตามเงื่อนไขความสมบูรณ์ของระบบที่ควรจะเป็นและสามารถยอมรับได้(Acceptance Criteria) ซึ่งได้ร่วมกันกำหนดขึ้นระหว่างผู้ใช้งานระบบกับทีมงานพัฒนาระบบรวมถึงส่วนงานอื่นๆ ที่เกี่ยวข้อง
การทดสอบระบบในขั้นตอนนี้มีจุดที่สำคัญซึ่งแตกต่างจากการทดสอบขั้นตอนอื่นคือ ผู้ใช้งานระบบจริงจะต้องเข้ามามีส่วนร่วมในกระบวนการทดสอบโดยเริ่มตั้งแต่ กำหนดกรณีทดสอบ(Test Case/Scenario) ร่วมทดสอบระบบ(Executes Test) จนถึง การประเมินและสรุปผลการทดสอบ(UAT Result and Evaluation) และตัดสินใจว่าระบบดังกล่าวจะสามารถนำไปใช้งานจริงได้หรือไม่ ถ้าได้ก็จะมีการลงนามอนุมัติจากผู้ใช้งานเป็นลายลักษณ์อักษร(UAT Sign Off) เพื่อนำระบบไปใช้งานจริง แต่ถ้าไม่ได้ ระบบจะถูกนำไปปรับปรุงแก้ไข แล้วจะกลับเข้าสู่กระบวนการ UAT อีกครั้ง จนกระทั่งเป็นที่ยอมรับของทุกฝ่ายว่าสามารถนำระบบใช้งานจริงได้
โดยที่สภาพแวดล้อมในการทำ UAT (UAT/Test Environment) จะต้องเป็นสภาพแวดล้อมที่เหมือนหรือใกล้เคียงมากที่สุด กับสภาพแวดของการใช้งานจริง (Hardware/Software/Data on Production Environment) เพื่อให้การทดสอบใกล้เคียงกับการทำงานจริงมากที่สุดและได้ผลผลการทดสอบที่น่าเชื่อถือ
ผู้เขียนจะขอขยายความและพูดถึงรายละเอียดในส่วนต่างๆ ที่กล่าวมา ในตอนต่อๆ ไปนะค๊า :flirty:
“A journey of a thousand miles begins with a single step”
A good start is half of the success
LeeFong…
บทความที่เกี่ยวข้อง
We Love Bug Cafe: วันอาทิตย์ที่ 10 กุมภาพันธ์ 2551
นับไป นับมา 14 กุมภาพันธ์ 2551 นี้ We Love Bug ก็จะอายุครบ 1 เดือน พอดิบ พอดี ก็ต้องขอขอบคุณเหล่าผู้เขียนทุกๆ ท่าน
ที่ได้สละเวลาจากงานประจำ มาร่วมแบ่งปันความรู้ ประสบการณ์ เทคนิคต่างๆ ที่เกี่ยวกับ Software Testing เพื่อช่วยกันสร้าง
ชุมชนคนรักแมลง ในประเทศไทยของเราให้เกิดขึ้น เพื่อแลกเปลี่ยนความรู้ ให้คำปรึกษา และช่วยเหลือกันในสายงานของ Software Testing รวมทั้ง Software Development Process ด้วยเช่นกัน เพื่อให้ Software ที่ถูกพัฒนาขึ้นมีคุณภาพที่ดี
สมาชิกรุ่นแรกที่เข้ามาร่วมด้วยช่วยกัน ณ ตอนนี้ ก็ประกอบไปด้วย Tester, Test Leader, Test Manager และล่าสุดเราก็ได้ต้อนรับสมาชิกใหม่อีก 1 ท่าน ที่เป็น Developer มาร่วมแบ่งปันประสบการณ์
ถือโอกาส ณ ตรงนี้ขอกล่าวต้อนรับสมาชิกทุกๆ ท่านอย่างเป็นทางการณ์ สู่ We Love Bug: Testing Doesn’t Finish…It’s Just STOP!
Programmer can test
programmer ก็ช่วย test ได้ครับ
ผมทำงานในทีมเล็กๆ ไม่มีเงิน หรือคนมากพอที่จะไปจ้าง หรือสร้างทีม tester เพราะฉะนั้น โปรแกรมเมอร์นี่แล จะต้องแบ่งเบาภาระการ test ให้กับทีม
สิ่งที่ programmer ช่วยได้ คือการใช้ Test driven development(TDD) เป็นตัวช่วย
สิ่งที่ผมเคยฟาดฟันมาก่อน คือการใช้ unit test ทำการ test source code ในทุกๆ unit ไม่ว่าจะเป็นตัวแปรเอย method(หรือบางคนจะเรียกว่า function)เอย หรือ integration test ที่เขียนยังไงก็ไม่ครอบคลุม จนมีฝรั่งใจดี สร้างสิ่งที่เรียกว่า Behavior driven development(BDD) นี่แหละ ใช่เลย แทนที่เราจะมองให้เป็น unit ทำไมเราไม่มองให้เป็นพฤติกรรม(behavior) ทดสอบที่พฤติกรรมไปเลย มันก็เลยเป็นการรวมกันของ unit test กับ integration test นี่แหละ ใช่เลย!!
แล้ว programmer จะไปเขียน test ตอนไหน ?? หลายๆ คนที่เคยทำ ก็อาจจะบอกว่า ก็เขียน code ไปก่อน แล้วไปเขียน test ทีหลังไง แต่ผมไม่ได้ทำแบบนั้น ผมใช้แนวคิดเรื่อง test first เป็นแนวทาง ก็คือเขียน test ไปก่อนนั่นแหละ แล้วค่อย implement ทีหลัง จริงๆ ต้องบอกว่า test ไป implement ไป มากกว่า
ตอนที่ใช้ Unit test มันจะทำ test first ยากหน่อย เพราะเวลา test มันจะต้อง test จาก code ที่เรา implement จริงๆ แต่พอได้ BDD มาช่วย การทำ test first ก็ดีขึ้น เพราะมันมีสิ่งที่เรียกว่า Mock/Stub เข้ามาช่วย เราเขียน test ได้นานขึ้น แล้วค่อยไป implement ทีเดียว
แน่นอนว่า การทำ test first จะช่วยให้การ test ง่ายขึ้น ดัก runtime error หรือ bug ที่เราคาดไม่ถึงมาก่อนได้มากขึ้น ถ้าเราใช้ unit test มันก็คงจะ test ได้แค่ unit นั้นๆ ที่เราพิจารณา ถึงแม้ integration test จะ test โดยรวมได้ แต่ผมก็ยังว่ามันไม่ครอบคลุมอยู่ดี ถ้าใช้ BDD จะช่วยเรื่องนี้ได้เยอะ เพราะเรามองเป็นพฤติกรรม(เดี๋ยวมาลุยกันตอนถัดไปครับ) ถ้าพฤติกรรมที่เรากำลัง test ผ่าน runtime error ก็จะหายไปเยอะเลย
ฟังดูเหมือนว่าการเขียน test จะเป็นสิ่งดี แต่มันไม่ค่อยสนุกเท่าไหร่ ปัญหามันก็มีบ้างครับ ส่วนใหญ่จะเป็นเรื่องของเวลาครับ เพราะเราจะเสียเวลาไปกับการเขียน test เพิ่มขึ้น แล้วเวลา coding เราจะน้อยลง และต้องเสียเวลาในการเรียนรู้อยู่นานครับ แต่ก็ยังพอมีสิ่งที่ผมเห็นว่าเป็นข้อดีในข้อเสียนี้ ก็คือ เราเสียเวลาในการเขียน code ก็จริง แต่ถ้าเขียน test ให้ครบหมดทุกกรณี(โดยเฉพาะ BDD คือ ทุกกรณีของพฤติกรรมของงานของเรา) เราจะมองเห็นทุก requirement และเป็น flow chart แบบคร่าวๆ
โดยส่วนตัวแล้วผมว่าเสียเวลาสักหน่อย กับการเขียน test เพื่อแลกกับความถูกต้องของงาน ผมว่าคุ้มครับ ทั้งนี้ ยังช่วยให้ tester ทำงานได้ง่ายขึ้นด้วย
“Get To Know The Writer” “มาทำความรู้จักกับผู้เขียนกันเถอะ”
ได้ฤกษ์งามยามดีเสียทีนะคะ สำหรับการเข้ามาเจิม คอลัมน์ UAT: User Acceptance Test หลังจากที่ซุ่ม(โป่ง) มาหลายอาทิตย์แล้ว แต่ก็ถือว่าโชคยังเข้าข้างอยู่บ้าง ที่ยังไม่โดนประธานของเว็บ ตัดหางปล่อยวัดไปเสียก่อน อันเนื่องจากไม่ยอมแบ่งปันเรื่องราว ดีๆ ให้ชาว Tester แห่งสยาม เสียที
ก่อนที่จะประเดิม เรื่องแรกให้กับ We Love Bug ก็จะถือ โอกาสนี้ เปิดตัว คอลัมน์ UAT เป็นทางการ แล้วก็ อยากจะเชิญชวน พี่ ๆ น้องๆ ชาว Tester แห่งประเทศสยาม เข้ามาร่วมจอยกับเราด้วย ไม่ว่าจะเป็นการแชร์ประสบการณ์จากการทำงาน หรือมาร่วม แบ่งปัน เพิ่มพูน ความรู้ และวิธีการ ในการทำ Test ไม่ว่าจะเป็น Test ประเภทไหนก็ตาม ผ่าน We Love Bug แห่งนี้ค่ะ
เนื่องจากผู้เขียนเองก็ทำงานในวงการไอทีสาย Software Development มาประมาณเกือบ ๆ สิบปี เริ่มงานตั้งแต่ Junior Programmer, Analyst programmer, Software Architect, Senior software engineer etc… ซึ่งส่วนใหญ่ ก็ล้วนเป็นองค์กรประเภท software industry อย่าเพิ่งแปลกใจว่า ทำไมต้องกล่าวถึงสายงานเหล่านั้น ก็เพราะว่า ต้องเกี่ยวข้องและคุ้นเคยกับการ Test ทั้งสิ้น ไม่ว่าจะเป็น Unit Test, System Test, Integration Test, Performance Test … แล้วเมื่อมองย้อนไปในอดีตประมาณสัก 5- 6 ปี ในงานเทสที่ผู้เขียนเคยผ่านมานั้น ก็ต้องยอมรับกันตรงๆ ว่าความเข้มข้น หรือจริงจังในการทำเทสในสายงานยังมีไม่มากพอ หรือพูดอีกอย่างคือ ให้ความสำคัญน้อยกว่า การที่จะ code program หรือ design ระบบให้เสร็จทันกับ timeline ซึ่งโดยสถิติส่วนตัวแล้ว เป็นไปได้น้อยมากที่จะเทสได้ครบทุก case ที่วางไว้หรือทำได้ดีที่สุดก็คือเลือกเทสได้บางเคสเท่านั้น แล้วผลก็คือ เมื่อต้องไปส่งมอบระบบแล้วต้องไปทำ UAT ร่วมกับลูกค้า ก็มักจะพบเจอกับ ดีเฟคที่คาดไม่ถึงเสมอๆ ไม่ว่าจะเป็น บั๊คที่ไม่ควรจะให้ลูกค้าเจอ (unwanted defect) หรือควรจะหาเจอตั้งแต่ในกระบวนการพัฒนาแล้ว และอีกประเภทคือ ระบบไม่สามารถรองรับการทำงานในปัจจุบันของลูกค้าได้อย่าง 100% ซึ่งปัญหานี้ โดยส่วนตัวมองว่า เป็นดีเฟคที่มีโอกาสที่จะเจอได้ในทุกๆ ระบบ หรือทุกบริษัทผู้ผลิตซอฟแวร์ตามสั่ง ซึ่งอาจจะเกิดจากกระบวนการ requirement ซึ่งเป็นต้นทางของการพัฒนาไม่สมบูรณ์ หรือปัญหาจากการ design ที่ไม่สอดคล้องกับความต้องการของลูกค้า ทั้งนี้ทั้งนั้นส่วนหนึ่ง ก็ขึ้นอยู่กับว่าลูกค้าจะสามารถยอมรับระบบนั้นได้ในเงื่อนไขอะไรบ้างเช่น ใช้งานขนานกับระบบเดิมตามช่วงเวลาที่กำหนด เพื่อเก็บดีเฟค เป็นต้น เพราะจะให้ไม่มีดีเฟคเลยนั้น คงเป็นไปได้ยากส์ (no defect free)
และประสบการณ์ต่อจากนั้นของผู้เขียนในช่วงประมาณหกปีหลังนี้ก็เริ่มเข้าใกล้ คำว่า Software Quality มากขึ้น เมื่อมีโอกาสได้เป็นส่วนหนึ่งในการทำงานในส่วนการวางระบบกระบวนการพัฒนาระบบอย่างมีแบบแผนหรือตอนนั้นก็คือ CMM (ปัจจุบัน CMMI) ซึ่งก็ยังต้องทำงานด้าน develop ไปด้วย(พูดง่ายๆ งานเพิ่มขึ้น) ซึ่งตรงนี้ล่ะได้มีโอกาส เรียนรู้ และได้เขียนโพรเซสการทำงานอย่างมีขั้นตอนในเฟสที่ตัวเองรับผิดชอบ รวมถึงการได้เข้าใจและให้ความสำคัญของการ Test เพราะเราได้มีการก่อตั้ง Unit ของการ Test ขื้นมาอีกด้วย และด้วยนโยบายจากเบื้องบนในเรื่องการให้ความสำคัญใน quality ของ ซอฟต์แวร์ ในทุกเฟสของการ develop เราในฐานะ SA ตอนนั้น ก็ต้องควบคุมคุณภาพในระบบที่ตัวเองรับผิดชอบ ไม่ว่าจะ ออกแบบเทสเคสเอง หรือลงมือเทสเพื่อตรวจสอบผลการ unit test ของ PG เองก่อนที่จะส่งออกไปยัง Test Team ก็ทำให้ SA หลายๆ คน alert กันพอสมควรเพราะเท่ากับงานเพิ่มนะเนี่ย(คิดตอนนั้น) แต่ก็สนุกและได้เพิ่มมุมมอง เพราะจากการได้ลองเทส หรือ รีวิว code ของคนอื่นนั้น ก็ทำให้เห็นสไตล์การเขียน โปรแกรมหรือการจัดวางรูปแบบ กระบวนการคิดของแต่ละคนต่างๆกัน อีกอย่างนะคะ ถึงแม้ว่าจะมีการรีวิวกันแล้ว ส่งออกไปให้ Test Team ยังอุตส่าห์ หาบั๊คเจออีก (งานยิ่งเร่งๆ อยู่ ต้องมา ประกอบระบบใหม่อีกละ) ก็มีบ้างที่ SA กับ Test Lead จะไม่ค่อยจะลงรอยกัน (เฉพาะเวลางานนะ)
แต่ ณ วันนี้ ผู้เขียนได้มานั่งอยู่ในมุมอีกมุมหนึ่งของสายงาน คือ IT Test Management ในฐานะ Test Lead ซึ่งโฟกัสการทำเทสใน ส่วน UAT and E2E ใน industry Telco มาได้ เกือบๆจะ สามปีละ เพื่อนๆ พี่ๆ ที่รู้จัก ก็มีถามไถ่ในตอนแรกๆ ว่าเราตัดสินใจดีแล้วหรือ จะเหมาะกับเราเหรอเพราะอาจจะคิดว่าผู้เขียนน่าจะเหมาะที่จะทำสายเดิม คำถามและความห่วงใยมากมายตามมาระยะนึง แต่ก็เข้าใจทุกๆคนที่เป็นห่วงค่ะ แต่จะขอบอกว่าถึงแม้จะหนัก แต่รู้สึกว่าเนี่ยล่ะใช่เลยที่อยากทำ เพราะได้เรียนรู้ระบบใหญ่ๆ ใหม่ๆ หลากหลาย (เพราะว่าทีมนี้รับเทสทั่วราชอาณาจักร 555) บางระบบก็เชื่อมโยงกันซับซ้อน(ซ่อนเงื่อน ไม่ให้เพื่อนรู้) ท้าทายในการทำเทส และท้าทายกับโรคกระเพาะเหลือเกิน และนอกจากจะมี In-house develop แล้ว ก็ยังต้องทำงานกับ supplier มากมายที่ต้องการใบผ่านด่านจากทีมเรา(จะจ่ายเงินหรือไม่ก็ทีมนี้ก็เป็นส่วนหนึ่งล่ะ) ว่าแล้วก็ต้องย้อนกลับไปสมัยเป็น supplier เอง ก็มียากบ้างง่ายบ้าง ในการ ทำ UAT ยิ่งบริษัทไหนไม่มี IT Team เคี่ยวๆ ล่ะก็ สบายไปเลย ได้ sign-off มาง่ายดาย (อิอิ) แต่ตอนนี้มาอยู่ในมุมนี้ ได้มีส่วนในการ ตรวจรับระบบที่มีคุณภาพให้กับบริษัท รู้สึกปลื้มใจจริงๆ ว่าแล้วก็ไม่รอช้า พยายามหาทางงัดกลยุทธิ์ เท่าที่ตัวเองมี หรือจากประสบการณ์ มาใช้ทำงานโดยด่วนเลย ไม่ว่าจะเป็นการ วางแผนการเทส การออกแบบเทสเคส การบริหารจัดการทีม กับ user ที่เชิญมาร่วมกันทำ UAT แล้วไหนจะ มีเรือ่ง test process improvement อีก สนุกนะคะขอบอก
ก็ได้รู้จักกับผู้เขียนไปแล้วนะคะ หวังว่าจะมีผู้สนใจและคอยติดตามผลงานของผู้เขียนและทีมงานท่านอื่นๆกันต่อไป และหวังเป็นอย่างยิ่งว่าเราจะสามารถสร้างสังคมแห่งการเรียนรู้ Software Testing ในประเทศไทย เพื่อยกระดับ คุณภาพของบุคลากรในสายงานนี้ให้ทัดเทียมกับนานาประเทศ
เตรียมตัวพบกับสาระและประสบการณ์ที่น่าสนใจเกี่ยวกับ UAT เร็วๆ นี้ ในหัวข้อ
“มาทำความรู้จัก กับ User Acceptance Testing กันเถอะ“
Coming next, we are going to take a closer look at “What is User Acceptance Testing”
“A journey of a thousand miles begins with a single step” Let’s take the first step
LeeFong..
ถ้าเวลามีจำกัดจะ Test อย่างไงดีให้ครอบคลุม
“Test อย่างไรให้ครอบคลุม?” ถ้าสำหรับผมละก็เป็นคำถามสุดฮิตแทบจะว่าได้ ไม่ว่า Project Plan จะทำออกมาสวยหรูขนาดไหน แต่ระหว่างการพัฒนา Software ไปเรื่อยๆ ก็จะมี Revise กันอย่างน้อยก็ 3 รอบ เกิดอะไรขึ้นหลังจากนั้นบ้าง
“วัน Launch Project ขยับไม่ได้จริงๆ”
“Scope กับ Requirement มันเพิ่ม เลยต้องขยับ Plan ของ Development Team ออก”
“ทีม Test ลดวันลงหน่อยได้ไหม ช่วยๆ กันนะ”
โอวววว…แม่เจ้า…พูดกันเหมือนยังกับขายของเลย แต่สุดท้ายถ้า Project Owner หรือ Project sponsor ฟันธงลงมาแล้วว่าห้ามขยับวัน Launch Project เท่าที่ประสบพบเจอมา หวยจะมาออกที่ขั้นตอนของ Software Testing Phase
หัวอกของ Tester, Test Lead หรือแม้แต่ Test Manager จะทำไงได้ เมื่อเบื้องบนฟันธงลงมาแล้วแบบนั้น?
