Lesson Learned
Testing Doesn’t Finish It’s just STOP Episode 1
Jun 5th
ทกสอบการเขียนบทความผ่าน App WordPress บน iPhone ณ ร้านข้าวต้ม ริมถนน ก็เลยประเดิมด้วยประโยคที่ผมชอบมาก
“Testing Doesn’t Finish It’s just STOP”
ผู้คนส่วนใหญ่มักจะพูดกันติดปากอยู่บ่อยๆ ว่า “Test เสร็จ”
แต่เพื่อนพ้องน้องพี่ที่ทำงานทำการเกี่ยวข้องกับ Software Quality จะรู้ดีว่า “มันไม่ใช่นะ มันไม่ใช่”
Testing ไม่มีมีคำว่า “เสร็จ” หรือ “จบ” มีแต่ “หยุด”
พูดกันแบบง่ายๆ เราจะหยุดการ Testing เมื่อตรงตาม Exit Criteria
Software Testing ช่วยลด Defect ให้เหลือน้อยที่สุด และเพิ่มความมั่นใจ
ขอจบตอนที่ 1 ของ Testing Doesn’t Finish It’s just STOP ไว้ ณ ร้านข้าวต้มริมถนนครับ
Case Study: How MySpace tested their live site with 1 million concurrent users
Mar 30th
สวัสดีเช้าวันอังคารที่ 30 มีนาคม 2553 ครับเพื่อนพ้องน้องพี่ ห่างหายจากการเขียนบทความลงใน welovebug ไปเกือบ 3 สัปดาห์ เนื่องจากมีภารกิจนิดหน่อย เช้าวันนี้ก็เลยหยิบยก Case Study ของการทำ Performance Testing มาฝากเพื่อนพ้องน้องพี่กันครับ
Case Study Performance Testing ที่นำมาเสนอวันนี้มีชื่อว่า How MySpace tested their live site with 1 million concurrent users ซึ่งผมได้รับการแนะนำบทความต้นฉบับมาจาก คุณภูวดล (@AuntiSPAM) ณ addmoremem.com ขอขอบคุณ คุณภูวดล ณ addmoremem.com ไว้ ณ ที่นี้ด้วยครับ 
ลองตามไปดูก่อนหน่อยครับว่า MySpace ทำยังไงในการที่จะทดสอบ Performance Testing 1 ล้าน concurrent users
รูปจาก http://www.albertsmusicgifts.com
มารู้จักกับ MySpace กันสักหน่อย
MySpace เป็นเว็บไซต์ในรูปแบบของเครือข่ายชุมชนออนไลน์ ชื่อดังเว็บหนึ่ง ให้บริการทำเว็บส่วนตัว บล็อก การเก็บ ภาพ วิดีโอ ดนตรี และเชื่อมโยงเข้ากับกลุ่มคนอื่น MySpace ก่อตั้งเมื่อ สิงหาคม พ.ศ. 2546 โดย ทอม แอนเดอร์สัน และ คริสโตเฟอร์ เดอโวล์ฟ ในปัจจุบัน MySpace มีพนักงานกว่า 300 คน และในตัวเว็บไซต์มีผู้ลงทะเบียนมากกว่า 100 ล้านคน และมีผู้ลงทะเบียนใหม่ประมาณ 200,000 คนต่อวัน (รายละเอียดเกี่ยวกับ MySpace สามารถอ่านเพิ่มได้ที่ Wikipadia)
Site: http://myspace.com
Case Study: สู้รบปรบมือกับการทดสอบที่มี IP Address มาเกี่ยวข้อง
Mar 13th
สวัสดียามค่ำของวันเสาร์ที่ 13 มีนาคม 2553 ครับ เปิดหัวเรื่องของวันนี้ด้วยคำว่า Case Study เนื่องด้วยเรื่องที่จะแบ่งปันในค่ำคืนนี้เป็น Case ที่เกิดขึ้นจริง หรือที่ฝรั่งมักจะใช้คำว่า Base on True Story ครับ และเกิดขึ้นใน ห้องน้ำ อ้าว งง งง งง กันเลยทีเดียวครับ ถ้าอยากรู้ว่า Software Testing ไปเกี่ยวข้องอะไรกับ ห้องน้ำ อ่านกันต่อไปครับ
Case Study นี้เกิดขึ้นเมื่อเกือบจะ 2 ปีแล้วครับ และติดตึงอยู่ในสมองน้อยๆ ของผมมานานเลยทีเดียว ว่าจะเขียน ว่าจะเขียน และว่าจะเขียน ลง welovebug มานานสองนาน แต่จนแล้วจนรอดก็ไม่ได้เขียนสักที ค่ำคืนนี้เลยตั้งใจว่าจะเขียนมันออกมา เผื่อจะได้เป้นประโยชน์ไม่มากก็น้อยสำหรับเพื่อนพ้องน้องพี่ทั้ง Software Tester, Programmer และ Developer ครับ
โจทย์ที่เจอจนต้องเอาต้องเอา ตีx ก่ายหน้าผาก
เพื่อนพ้องน้องพี่ทั้งหลายน่าจะคุ้นเคยกับการ Vote ให้คะแนนบน website ต่างๆ ไม่ว่าจะ Vote ให้คะแนนรูปที่ชอบ หรือ ช่วย Vote ให้เพื่อนๆ ที่ประกวดโน้นนี่นั่นบน website หรือ แสดงความคิดเห็น หรือ Comment บน Webboard หรือ Forum หรือ Discussion ที่มีอยู่เยอะแยะมากมายตาม website ต่างๆ ซึ่งเจ้า Vote และ Comment นี่แหละ ที่ทำให้ผมถึงกับต้องนอนเอา ตีx ก่ายหน้าผาก อยู่นานหลายเดือน
โจทย์ที่ได้รับมาเป็น Project ที่จะต้องทำการทดสอบ Function การ Vote ให้คะแนนกับบทความที่เขียน และมี Business Requirement หลักคือ
1 IP Address สามารถ Vote ได้ 1 ครั้ง ทุกๆ 1 ชั่วโมง
หลายคนอาจจะทำหน้า งง งง ว่า แค่ Business Requirement ข้อเดียว ถึงกับทำให้ผมต้องนอนเอา ตีx ก่ายหน้าผาก ได้อย่างไร?
More >
แบ่งปันประสบการณ์เตรียมตัวสอบ Certified Software Tester CSTE
Oct 17th
สวัสดียามค่ำคืนวันเสาร์กลางเดือนตุลาคม 2552 ขณะที่เขียนเรื่องอยู่นี้ อุณหภูมิ 28 องศา (ไม่ได้เกี่ยวอะไรกับเรื่องที่จะเขียนครับ) สองวันที่ผ่านมาผมได้เห็น comment หนึ่ง จากเพื่อนสมาชิกของ welovebug เรา เกี่ยวกับเรื่องของประสบการณ์ และการเตรียมตัวในการสอบ Certified Software Tester หรือที่รู้จักกันในชื่อเล่นว่า CSTE
ในสายงานของ Software Testing เราก็มีการสอบ Certificate เหมือนๆ กับสายงานอื่นนะครับ เพื่อนพ้องน้องพี่ท่านใดที่สนใจก็ติดตามข้อมูลได้จาก http://www.softwarecertifications.org/
เข้าเรื่องเลยละกัน วันนี้ผมนำ comment ของคุณ Nick มาเขียนเป็นเรื่องไว้ เพื่อจะได้เป็นประโยชน์สำหรับเพื่อนพ้องน้องพี่ที่กำลังเตรียมตัวในการสอบ CSTE
More >
ตัวอย่างผลกระทบต่อธุรกิจจาก Bug ที่เกิดขึ้นใน Software
Sep 8th
เมื่อเร็วๆ นี้ (วันที่ 5 กันยายน 2552) เพื่อนผมท่านหนึ่งได้ส่งข่าวมาให้อ่าน “ตลาดหุ้นเสีย วอลุ่ม ทันที 4 พันล้านบาท ” ในเนื้อข่าวไม่ได้บอกอะไรมากในแง่ของข้อมูล Technical แต่เพื่อนผมที่เคยทำงานอยู่ ณ ที่บริษัทที่ทำ Software ซื้อขายหุ้นตัวทีมีปัญหาตามข่าว บอกว่าเป็นปัญหาเรื่องของระบบ และการทดสอบที่ไม่ครบถ้วน หรือ ถ้าเพื่อนพ้องน้องพี่ยังจำข่าวเมื่อราวๆ ปีกว่าๆ ได้ที่มี ชาวนาที่อยุธยา เติมเงินเข้ามือถือ แต่พอเช็คยอดแล้วมีเงินในมือถือตัวเองหลักล้านบาท ทั้ง 2 กรณีที่ผู้เขียนยกขึ้นมานั้นถ้ามองในแง่ของธุรกิจ เกิดความเสียหายขึ้นทันที ผลที่เกิดขึ้นนั้นมาจาก Bug ที่เกิดขึ้นใน Software
ตลอดระยะเวลาเกือบ 5 ปี ที่ผู้เขียนทำงานเกี่ยวกับ Software Testing ก็พบเหตุการณ์ที่ก่อให้เกิดความเสียหายกับธุรกิจ อันเนื่องมาจาก Bug ของ Software ด้วยเช่นกัน ไม่ว่าจะประสบมากับตัวเอง หรือจากการเล่าสู่กันฟังของเพื่อนพ้องน้องพี่ที่ทำงานในสายงานเดียวกัน แต่ทั้งนี้ทั้งนั้นก็มิได้จะหมายความว่าเราจะชี้นิ้วด่าลงไปที่ Programmer หรือ Developer หรือแม้แต่ Tester ว่าทำงานไม่ดี ทำงานไม่ได้เรื่อง เสียทีเดียว มันมีหลายๆ ปัจจัย ที่เกี่ยวข้อง มีคนเคยบอกไว้ว่า “Quality is Expensive” ทำให้หลายๆ องค์กร มองข้ามเรื่องนี้ไป หรือไม่ค่อยให้ความสำคัญสักเท่าไรนัก แต่พอเกิดปัญหาขึ้น ก็พยายามหาที่ Landing หรือ แพะ ทันที ซึ่งส่วนมากก็จะมาลงที่ทีม Development หรือไม่ก็ทีม Test (ความเห็นส่วนตัวครับ)
ผู้เขียนจำได้ว่าเคยอ่านข้อมูลมาจาก Website หนึ่ง สมัยเริ่มทำงานด้าน Software Testing ใหม่ๆ คลับคล้ายคลับคลา ว่ามีหัวข้อที่ยกตัวอย่างผลกระทบที่เกิดขึ้นกับธุรกิจอันเนื่องมาจาก Bug ของ Software ดังนั้นจึงลองไปค้นๆ เอกสารดู และก็เจอจนได้ ข้อมูลอ่านจะเก่าไปสักหน่อย เพราะวันที่ที่ผู้เขียนสั่งพิมพ์ไว้ ลง วันที่ 27/3/2549 16:47 บทความเขียนขึ้นเมื่อไรนี่ไม่รู้นะครับ เดชะบุญที่ยังมี URL ของบทความอยู่บนกระดาษ ผู้เขียนเลยตามเข้าไปดู URL ยังสามารถเข้าได้ และมีข้อมูล Update ล่าสุดเมื่อ February 23, 2009 ซึ่งต้นฉบับเป็นข้อมูลภาษาอังกฤษ ดังนั้นผู้เขียนจึงขออนุญาตินำเสนอเป็นข้อมูลภาษาอังกฤษด้วยเช่นกัน
[Forum] มักจะได้คำตอบจาก Developer ว่า Out of Scopes ทำไงดีค่ะ!!!
Jun 29th
สวัสดียามค่ำคืนวันจันทร์ที่ฝนตกโปรยปรายครับ อากาศเย็นสบาย แต่ก็ระมัดระวังที่จะไม่สบายกันด้วยนะครับ เข้าเรื่องเลยละกันนะครับ ได้มีเพื่อนพ้องน้องพี่ของเราได้ไปถามไว้ที่ Software Testing Forum ไว้ ดังนี้ครับ
ตอนนี้กำลังสับสนว่า เวลา Log Issue ไป มักจะได้คำตอบจาก Developer ว่า Out of Scopes.
ในมุมมอง QA ที่ถ้าเจอ Issue ก็จะ Log เพราะ Concern ในเรื่อง Quality
แต่ ในมุมมอง Developer หรือ Project Team ถ้าเรื่องที่เจออยู่นอกเหนือ Scopes งานที่ต้องแก้ไข ในโปรเจคที่มีเรื่อง Budget และ เวลาเป็นเงื่อนไข ที่เขาต้องใช้ไปในการ Investigate งานที่นอกเหนือ Scopesเราจะมีวิธีการจัดการกับปัญหานี้อย่างไรดี รบกวนช่วยแนะนำด้วยคะ
ยกตัวอย่างเคส เช่น ลูกค้าทำการ Upgrade ระบบจาก Version 1.0 เป็น 2.0
ปัญหาหนึ่ง
Tester แจ้ง Bug ที่ Developer ตรวจสอบแล้วพบว่าเป็น Bug ที่เกิดจาก Core Product ไม่ได้เกิดจากการ Customization ซึ่งนโยบายของบริษัทจะไม่ทำการแก้ไข Bug ที่เกิดจาก Core Productเนื่องด้วยเวลาที่จำกัด ทำให้ Tester ไม่สามารถพิสูจน์ว่า Issue ที่เจอเป็น Issue จาก Core Product หรือไม่
Developer ก็ต้องเสียเวลาในการพิสูจน์ Issue ที่หากเป็น Issue ที่เกิดจาก Core Product ก็จะไม่ Fix ซึ่ง 60% ของ Issue ที่ทำการรายงาน เกิดจาก Core Product ทั้งนั้นเราจะมีวิธีการอย่างไรที่จะทำให้ Tester สามารถเรียนรู้ว่า Issue ที่เจอ เกิดจาก Core Product ของแต่ละเวอร์ชั่น ซึ่งแน่นอนว่าจะมีการรายงาน Bug ใหม่ๆ อยู่เสมอ
ปัญหาสอง
ด้วย เวลาที่จำกัด Tester จึงถูกจำกัดให้เน้นเทสในส่วนที่เป็น Customization แทนที่จะทำการทดสอบระบบโดยรวม เช่นนี้แล้วเราจะรับประกันคุณภาพของ Software นี้ได้อย่างไร
เลยหยิบยกมาให้เพื่อนพ้องน้องพี่ของเราได้ร่วมด้วยช่วยกันแสดงความคิดเห็น และคำแนะนำดีๆ ครับ
ที่มา: http://forum.sanook.com/forum/2848317_Out_of_Scopes.html
Test ไปเพื่ออะไร? แล้วใคร Test อะไร?
Jun 26th
ขึ้นหัวโปรยแบบออกแนวหาเรื่องเล็กๆ แต่มันเป็นสิ่งที่ผู้เขียนเองเจอมากับตัวเองเลยครับ จากหลายๆ คนที่ยังไม่เข้าใจ ในเรื่องของ Software Testing แต่ก็ไม่ผิดนะครับ เพราะในประเทศไทยเราเองยังไม่ค่อยมีการสอนในเรื่องของ Software Testing อย่างเป็นจริงเป็นจังมากนัก แต่ในสองสามปีหลังนี้ เริ่มที่จะได้ยินว่าตามสถาบันการศึกษาหลายๆ แห่ง เริ่มที่จะเปิดการเรียนการสอนแล้ว แอบดีใจครับ
“Test ไปเพื่ออะไร?” และ “ใคร Test อะไรบ้าง?” ผู้เขียนเองเจอคำถามเหล่านี้อยู่เป็นระยะๆ ก็เลยหยิบมันมาเขียนละกัน แต่ขอบอกก่อนว่าเป็นเรื่องของมุมมองจากประสบการณ์การทำงานในด้าน Software Testing และจากตำรับตำราที่ได้ไปอบรมมา มานะครับ
Testing
ขอปรับความเข้าใจพื้นฐานเกี่ยวกับ Software Testing แบบไวไว ในหนึ่งย่อหน้าก่อนที่จะเข้าไปสู่ “Test ไปเพื่ออะไร?” และ “ใคร Test อะไร?” เข้าใจว่าๆ เพื่อนพ้องน้องพี่ทั้งหลายจะอยู่กับกระบวนการพัฒนา Software หรือ Application ที่ฝรั่งมั่งค่าคิด และตั้งชื่อว่า Systems Development Life Cycle (SDLC) ซึ่ง Testing อยู่ใน Phase เกือบท้ายๆ ของ SDLC
Testing and Recording Defect with Video Clip
May 18th
สวัสดียามค่ำคืนครับ จะได้มีเวลาเข้ามาเขียนเรื่องลงใน welovebug ก็เวลาหลังเลิกงานแล้วครับ แต่ก็แอบดีใจที่มีสมาชิกหลายๆ ท่านเข้ามาร่วมด้วยช่วยกันเขียนเรื่องต่างๆ ลงใน welovebug ของเรา ก็ขอขอบคุณไว้ ณ ที่นี้ สำหรับบทความดีๆ และความคิดเห็นต่างๆ ครับ
photo by Blacknight Solution
ค่ำคืนนี้ก็ขอเล่าสู่กันฟังถึงประสบการณ์ในส่วนของ Defect Management ที่เคยผ่านมาในการทำ Software Testing ซึ่ง Tester หลายๆ ท่านอาจจะประสบปัญหาอยู่ ณ ตอนนี้ และในเวลาเดียวกัน Tester หลายๆ ท่านก็น่าจะใช้วิธีการเดียวกันกับที่ผู้เขียนใช้ด้วยเช่นกัน
Defect หรือ Bug เหมือนเป็นเพื่อนสนิทมิตรสหายกับ Tester ทั้งหลาย ที่จะต้องประสบพบเจอกันอยู่ในทุกๆ ครั้งที่ลงไม้ลงมือทดสอบ Software หรือ Application ต่างๆ ซึ่งเมื่อเราได้เจอะเจอกับเจ้า Defect หรือ Bug ในระหว่างดำเนินการ Test เราก็จะทำการ Log รายละเอียดของ Defect ที่พบลงในระบบ Defect Management ที่แต่ละ Tester นั้นใช้งาน โดย Tester ก็จะบอกรายละเอียดต่างๆ ที่เกี่ยวข้องกับ Defect นั้นๆ ซึ่งโดยทั่วๆ ไป Tester ทั้งหลาย ก็จะแจ้งรายละเอียดเบื้องต้น ดังนี้
More >
[Forum] แนวทางการออกแบบ Plan for Testing
Mar 6th
ยังไม่จบครับสำหรับวันศุกร์แห่งชาติวันนี้ 555 มีของปล่อยเยอะ หลังจากไม่้ค่อยได้ update บทความลงใน We Love Bug มาซะหลายอาทิตย์เลยครับ
“แนวทางการออกแบบ Plan for Testing” มีพี่น้องของเราตั้งกระทู้ถามไว้ที่ Software Testing Forum เมื่อวันที่ 26 ก.พ. 09, 03:14 น โดยเจ้าของกระทู้ใช้ชื่อว่า นักออกแบบระบบ
ดูแล้วน่าสนใจก็เลยหยิบยกมาให้เพื่อนพ้องน้องพี่ช่วยกันระดมสมองกันหน่อยนะครับ
สามารถแสดงความคิดเห็นได้ทั้งบน We Love Bug หรือ ที่ Software Testing Forum ก็ได้ครับ
แนวทางการออกแบบ Plan for Testing
เรามาช่วยกันระดมความคิด แนวทางการออกแบบ plan for testing กันดีกว่ามั้ย เผื่อมีใครสนใจหรือทำงานด้านนี้ จะได้นำไปใช้ให้เกิดประโยชน์ได้และเป็นการพัฒนาบุคลากรด้าน tester ของเรากันด้วย
http://forum.sanook.com/forum/2687353_แนวทางการออกแบบ_plan_for_testing.html
Developing Life Cycle ตีแผ่ความจริงของวงการ Developer
Apr 18th
แต่นแต๊น…..วันนี้เป็นฤกษ์งามยามดีที่จะขอนำเสนอความจริงที่ถูกปิดบังมานานในวงการ Software ฮิฮิ แต่คิดว่าน่าจะมีบางคนพอรู้ความจริงเรื่องนี้ อยู่บ้างแล้ว พอดีเข้าไปเจอกระทู้ใน web ที่มีชื่อเสียงแห่งหนึ่ง ซึ่งอ่านแล้วรู้สึกว่าเป็นการตีแผ่ที่กระจาย กระจ่างแจ้ง ดีจริงๆ เลยอยากเอามาเผยแผ่ได้อ่านกันขำ ๆ แต่ก็มิได้นำพา….
ที่มา : http://www.thaimacdev.com
