Profil de krittikaTomiko VanPhotosBlogListesPlus  |  Outils Aide |
Tomiko VanJust tryin' to get through this life~ |
|||||||||||||||||||||||||
|
8 août ...**บทกลอนของเด็กอัฟริกัน ผู้ได้รับรางวัลยอดเยี่ยมจากUN **
Nominated by UN as the best Poem of 2006 - Written by an African Kid
When I born, I black : เมื่อผมเกิด ผมผิวดำ
When I grow up, I black : เมื่อผมโตขึ้น ผมก็ยังผิวดำอยู่ When I go in Sun, I black : เมื่อผมอยู่ใต้แสงแดด ผมก็ยังคงผิวดำ When I scared, I black : เมื่อผมกลัว ผมก็ผิวดำ When I sick, I black : เมื่อผมป่วย ผมก็ยังผิวดำ And when I die, I still black : และเมื่อผมตาย ผมก็ยังคงผิวดำ And you white fellow : และคุณ...เพื่อนมนุษย์ผิวขาว When you born, you pink : เมื่อแรกเกิด คุณมีผิวสีชมพู When you grow up, you white : เมื่อคุณโตขึ้น คุณมีผิวสีขาว When you go in sun, you red : เมื่อคุณอยู่ใต้แสงแดด คุณมีผิวสีแดง When you cold, you blue : เมื่อคุณหนาว คุณมีผิวสีน้ำเงิน When you scared, you yellow : เมื่อคุณกลัว คุณมีผิวสีเหลือง When you sick, you green : เมื่อคุณป่วย คุณมีผิวสีเขียว And when you die, you grey : เมื่อคุณตาย คุณมีผิวสีเทา And you calling me colored?? : และคุณเรียกผมว่า ....คนผิวสี?? 25 juillet วันนี้เจอ พอลล่า เทย์เลอร์ด้วยลัลล้า~
เหตุเกิด เมื่อตอนเที่ยง วันนี้
ขณะที่ประตูลิฟท์กะลังเปิด
ลิฟท์ฝั่งตรงข้ามก็เปืดพร้อมกันทันที
ทันใดนั้นเห็นกลุ่มปิศาจแดง(ใส่เสื้อแดง) เดินออกมาหลายคนมาก
หนึ่งในนั้นก็ครือ พอลล่า!!!! เดินยิ้มแฉ่ง~ง น่ารักมากๆ ตัวจริงๆ ตัวเป็นๆ ตัวเล็กๆ นาา~
รู้สึกว่าจะมาโปรโมต บัตรเครดิต visa ที่มีโลโก้แมนยู
ที่บริษัท New Hampshire Insurance Companyเป็นบริษัทลูกของ AIG
เหมือนบัตรเครดิตทั่วไป เพียงแต่จะมีสิทธิพิเศษสำหรับสาวกปีศาจแดง
(พอลล่า มาที่ชั้น 20 บริษัท AIG Card)
ปล. ทำไมวันนี้ว่างงานจังเรยว่ะ - -ล 1 juillet วิธีทำ Autoshutdown ให้ WindowsWindows XP Auto-Shutdown
2) Type SHUTDOWN –s –t 01 (zero one), click next
3) Type a name for the auto-shutdown shortcut, click finish
5) Double click Add Scheduled Tasks icon, click next
6) Browse for shortcut that just created
7) Select shortcut and click open
8) Chose option that you want then click next
9) Set time, click next
11) You can change icon after finished by click right button >>property ,then select your icon
26 mars test test...part 2Software Testing ตอนนี้เป็นวิกฤตในเมืองไทยอย่างหนึ่งทีเดียว หลายองค์กรเริ่มให้ความสนใจมากขึ้น แต่ยังเป็นเพียงความสนใจเท่านั้น การดำเนินการอย่างถูกต้องจริง ๆ มีทำกันน้อยมาก คนมีความรู้ด้านนี้จริง ๆ น้อยมาก เมืองไทยตอนนี้ขาดบุคลากรผู้เชี่ยวชาญด้านนี้มาก และที่แย่กว่าด้านอื่น ๆ (Programming, Design, Project Management, ฯลฯ) คือ บุคลากรที่จะสอนจริง ๆ จัง ๆ 'ไม่' มี (ไม่นับหลักสูตร Testing ของเวนเดอร์) Software Testing คือการผสมผสานกันระหว่าง Theory + Tool ทำให้ไม่ค่อยมีคอร์สอบรมด้านนี้เท่าไหร่ เพราะสอนแต่ทฤษฏีก็ไม่ได้ คอร์สอบรมส่วนมากจึงสอนทฤษฏีส่วนหนึ่งและจำเป็นต้องสอนการใช้ Tool ส่วนหนึ่ง เลยเป็นข้อจำกัดและภาคบังคับเรื่องการใช้ Tool ไป ผู้เรียนกลับไปทำงานไม่ได้ใช้ Tool ยี่ห้อนี้หรือตัวนี้ก็ไม่ค่อยได้ประโยชน์ คอร์สพวกนี้จึงมักเป็นคอร์สสำหรับลูกค้าที่ซื้อ Tool ไปแล้วแล้วค่อยมาเรียนวิธีใช้และเรียนภาคทฤษฏี หรือหากเป็นพวกคอร์สที่ใช้ Tool พวก OpenSource ก็ลำบากนิด เพราะมันมีให้เลือกใช้เยอะ ต้องจับโน่นมารวมกับนี่ หากจะทดสอบแอพพลิเคชั่นชนิดนั้นก็ต้องใช้ตัวนี้กับตัวนั้น หากจะทดสอบอีกชนิดก็ต้องใช้ตัวโน้นกับตัวนู้น เมื่อไรก็ตามที่คนส่วนใหญ่มองการพัฒนาซอฟต์แวร์เป็นอุตสาหกรรมการผลิตสินค้าชนิดหนึ่ง เหมือนอุตสาหกรรมการผลิต สินค้าชนิดอื่น ๆ ทั่วไปให้ได้ ไม่ใช่มัวแต่มองว่าซอฟต์แวร์เป็นสินค้าที่ High Touch and High Technology (จริง ๆ ไม่ค่อยจะ High Return นะ นอกจากว่ามี 'อะไร ๆ' พร้อมสรรพ) เมื่อนั้นคนส่วนใหญ่คงให้ความสำคัญกับคำว่า Quality มากขึ้น เพราะการทดสอบ ต้องทดสอบหมดทุกจุดทุกช่วงของกระบวนการ พัฒนา (ผลิต) ซอฟต์แวร์ ไม่ใช่ทอสอบซอฟต์แวร์อย่างเดียว และไม่ใช่มานั่งทดสอบกันเอาตอนท้าย ๆ และยังต้องทดสอบ อย่างต่อเนื่อง (Continually Verify Quality) อีกด้วย เมื่อไม่กี่ปีก่อนในรัฐบาลชุดที่ผู้นำหลายคนจบปริญญาเอกด้านการตลาด การจัดการ บริหาร ฯ จากเมืองนอก และหลายคนเป็น นักธุรกิจชั้นเซียน และอีกหลายคนเป็นลูกศิษย์ของกูรูชั้นนำระดับโลก ได้เจียดเงินภาษีประชาชนจ้างกูรูด้านกลยุทธ์ระดับโลก อย่าง Michael E. Porter มาบรรยาย Porter ได้วิเคราะห์และกำหนดยุทธศาสตร์ด้าน Cluster สำหรับเมืองไทยไว้ 5 Cluster หนึ่งในนั้นคือ อุตสาหกรรมซอฟต์แวร์ ในรูปกราฟที่ได้มีการเปรียบเทียบกับ Cluster อื่น ๆ ทำให้ผู้ได้พบเห็น ทราบว่าอุตสาหกรรมซอฟต์แวร์เป็นอุตสาหกรรมที่มีความเสี่ยงสูงที่สุดและเข้าถึง (เข้าใจ) (High Touch) ได้ยากที่สุดใน 5 Cluster ไม่แปลกที่รัฐบาลชุดดังกล่าวจึงไม่ทุ่มเทกับอุตสาหกรรมนี้เท่าไร แต่สร้างภาพด้วยการทุ่มกับ Segment หนึ่ง เป็นหลักนั่นคือด้าน Animation เพราะเป็นรูปธรรมที่สุดและลูกหลานบางคนก็ทำธุรกิจด้านนี้อยู่ ทั้ง ๆ ที่อุตสาหกรรมย่อยอย่าง แอนิเมชั่นนั้นเทียบไม่ได้เลยกับ Value ทั้งหมดที่มีในอุตสาหกรรมซอฟต์แวร์บ้านเรา สิ่งที่ควรสนับสนุน ส่งเสริม และขับเคลื่อน อย่างแท้จริง ๆ ควรเป็นรถไฟทั้งขบวนมากกว่า ไม่ใช่แค่โบกี้เดียว * Cluster อื่นเช่น Detroit of Asia รู้สึกว่าจะล่มไปแล้ว เพราะการเมือง และมัวแต่เน้นให้เมืองไทยเป็นฐานการผลิต และการประกอบ (แรงงานฝีมือดี... อีกแล้ว) ตอนนี้เขาเริ่มเบนเข็มไปจีนไปเวียดนามกันแล้ว เพราะการเมืองมีเสถียรภาพ และนโยบายภาครัฐชัดเจน หรือแม้แต่ Cluster 'ครัวไทย... ครัวโลก' เพียงแค่ปัญหาข้าวหอมมะลิกับผัดไทถูกแอบจดลิขสิทธิ์ ยังวิ่งไล่แก้ปัญหากันแทบตาย โถ... แต่อย่างน้อยอาหารไทยก็ติดอันดับโลกนะ... Software Testing เป็นศาสตร์และศิลปเช่นกัน มีมิติและระดับความลึกที่ซับซ้อน การทดสอบซอฟต์แวร์แบ่งได้เป็นหลัก ๆ 3 มิติคือ 1. Functional Testing คือ การทดสอบเชิงฟังก์ชั่น หรือ ทดสอบ Functional Requirements นั่นเอง 2. Reliability Testing คือ การทดสอบเชิงความน่าเชื่อถือ เช่น การคำนวณ การใช้ทรัพยากรหรือเข้าถึงข้อมูลพร้อม ๆ กัน เป็นต้น 3. Performance Testing คือการทดสอบเชิงประสิทธิภาพ มักเกี่ยวกับเวลา ซึ่งแบ่งออกเป็น 3.1 Application Performance Testing คือ ประสิทธิภาพของโปรแกรมของเราเอง 3.2 System Performance Testing คือ ประสิทธิภาพของโปรแกรมเมื่อทำงานบนสภาพแวดล้อมจริง หรือ Simulate ให้เหมือนจริง การทดสอบเชิง Reliability และ Performance เป็นการทดสอบ Non-Functional Requirements ดังนั้นการเขียน Test Case สำหรับการทดสอบเชิง Functional นั้นไม่ต่างจากการเขียน Use Case Specification นัก เพราะเป็นการทดสอบ Main Flow / Basic Flow และ Alternative Flow(s) / Exceptional Flow(s) ตามที่ได้ระบุ ใน Use Case Specification ลำดับขั้นตอนต่าง ๆ ก็ล้อกันมา เพียงแต่เพิ่มเติมรายละเอียดที่จำเป็นเข้าไปเพื่อให้เป็น Test Case การเขียน Test Case ในลักษณะนี้จึงไม่ยากนัก แต่การเขียนสำหรับการทดสอบเชิง Reliability และเชิง Performance นั้นก็จะเขียนยากขึ้นมา การเขียน Test Case ที่ดีต้องเป็กนักจำลองเหตุการณ์ (Scenario) ที่ดี ใน 1 Scenario อาจมี 1 Case หรือหลาย Case หรืออธิบายอีกอย่างได้ว่า 1 Test Case อาจใช้สำหรับทดสอบเหตุการณ์เดียว หรือ นำหลาย ๆ Test Case มารวมกัน เพื่อทดสอบหลาย ๆ เหตุการณ์ที่เป็นส่วนหนึ่งของเหตุการณ์ที่ใหญ่ขึ้น อาจเรียกว่า Test Suite หรือมอง Test Case เปรียบเหมือนอ็อบเจ็คต์ในหลัก Object-Orientation ก็ได้ ตัวอย่างเช่น มีการจำลองการทดสอบเหตุการณ์ใหญ่อยู่ 1 เหตุการณ์คือ 'สั่งซื้อหนังสือออนไลน์' เรียกว่า Test Suite ประกอบด้วย การทดสอบเหตุการณ์ย่อย ๆ หรือ Test Case คือ 1. 'สมัครสมาชิก' ถือเป็น Prerequisite หรือ Precondition 2. 'ค้นหาและดูรายละเอียดหนังสือ' 3. 'หยิบหนังสือใส่ตะกร้า' มีเงื่อนไขว่ากลับไปทำเหตุการณ์ 'ค้นหาและดูรายละเอียดหนังสือ' ได้อีก 4. 'Check Out' คือการแสดงรายการสรุปหนังสือที่ต้องการซื้อ 5. 'ชำระเงิน' 5.1 'ชำระเงินผ่านระบบ Payment System' ซึ่งเป็น Extension Point หรือเงื่อนไข อาจเป็น Test Case ย่อย ซึ่ง เหตุการณ์นี้ไม่ใช่ Functional Testing ในมุมมองที่มีปฎิสัมพันธ์ (Interactive) กับผู้ใช้ แต่เป็น Functionality Mechanism ซึ่งเป็นกลไกทางด้าน Functional ในระดับสถาปัตยกรรม การเขียน Test Case สำหรับเหตุการณ์ย่อยนี้ก็จะแตกต่างไปบ้าง เมื่อแบ่งการทดสอบเป็นเหตุการณ์ย่อย ๆ ได้แล้ว อยากจะทดสอบบางเหตุการณ์ก็สามารถทำได้ หรือจะทดสอบเหตุการณ์ใหญ่ก็ทำได้ โดยทดสอบเรียงลำดับหรือตามเงื่อนไขกันไป อีกตัวอย่างให้ลองนึกดูเล่น ๆ ว่า คุณต้องการเขียน Test Case เพื่อทดสอบ Reliability สำหรับเหตุการณ์คือ 'ตรวจสอบจำนวนอ็อบเจ็คต์และทรัพยากรที่ใช้ (Memory กับ CPU) ในระหว่างการประมวลผลงานของผู้ใช้ทั้งหมด ณ เวลาหนึ่ง' ซึ่งเป็น Test Case หนึ่งในการทดสอบตาม Non-Functional Requirement และ Need (Business Requirement) ข้อหนึ่งชื่อ 'ณ ช่วงเวลาที่ Peak ที่สุดที่มีผู้ใช้เข้ามาสั่งซื้อหนังสือออนไลน์ ระบบฯ ต้องสามารถรองรับได้โดยใช้ทรัพยากร (Memory กับ CPU) ที่มีอยู่' แล้วลองเขียน Test Case ดูว่าควรจะมีหน้าตาอย่างไร จากตัวอย่างประเด็นที่ต้องพิจารณาคือ ช่วงเวลาที่ Peak ที่สุดนี้ โดยเฉลี่ยมีผู้ใช้ทั้งหมดกี่คน และทรัพยากรที่มีอยู่ มีอยู่เท่าไหร่ การจำลองการทดสอบใน Test Case นี้เพื่อต้องการตรวจสอบดูว่าจะมีการสร้างและใช้อ็อบเจ็คต์ทั้งหมดกี่ตัวต่องานหรือต่ อผู้ใช้หนึ่งคน แล้วมาคำนวณ และการทำงานของแต่ละอ็อบเจ็คต์ใช้หน่วยความจำเท่าไหร่และใช้ CPU กี่ Cycle และอีกหลายวิธีการ ดังนั้นนอกจาก Tester ต้อง เขียน Test Case แล้ว SA อาจต้องเข้ามาช่วยเขียน Object Story Board โดยใช้ Object Diagram ใน UML เพื่อจำลองแต่ละ State ในช่วงเวลาต่าง ๆ ที่อ็อบเจ็คต์ทำงาน และเวียนว่ายตายเกิดอยู่ในระบบฯ ในการเขียน Requirements แบบการจำลองเหตุการณ์ (Scenario) ตามแนวทางของการวิเคราะห์และออกแบบสถาปัตยกรรม ของ SEI (Software Engineering Institute) ได้มีระบุไว้น่าสนใจมาก ลองเข้าไปหาดูได้ที่ http://www.sei.cmu.edu/architecture แล้วจะกล่าวถึงต่อไปครับ ส่วนแนวคิด Test Driven Development นั้นน่าสนใจและดีมาก ๆ ทีเดียว หากมองเปรียบกับอุตสาหกรรมการผลิตสินค้า อื่น ๆ ทั่วไป มันก็ต้องเป็นแบบนี้ล่ะครับ จะสร้างอะไร จะคิดอะไร จะทำอะไร จะซื้ออะไร เมื่อมีโจทย์ (Requirements) ปั๊บ ต้องหาทางทดสอบ (Qualify) ก่อนเลย แต่หากนำมาใช้กับการพัฒนาซอฟต์แวร์ในบ้านเรา มันเป็นการเปลี่ยนวัฒนธรรม (Culture) ของนักพัฒนาซอฟต์แวร์ไทยพอสมควร จริง ๆ จะว่าไปไม่ใช่ที่นักพัฒนาซอฟต์แวร์เสียทีเดียว แต่เปลี่ยนวัฒนธรรมของเหล่า SA, Project Manager, Project Leader และที่สำคัญ หัวหน้าหรือผู้บริหารเสียมากกว่า ขืนอยู่ ๆ เขาเดินเข้ามาถาม... "เขียนโปรแกรมไปถึงไหนแล้ว" "ยังไม่ได้เขียนเลยครับ ตอนนี้กำลังเขียน Test Case โปรแกรมส่วน Test อยู่" หัวหน้าหรือผู้บริหารที่ไม่เข้าใจส่วนมากคงหัวฟัดหัวเหวี่ยงกลับไป แต่ของแบบนี้มันต้องค่อยเป็นค่อยไป เดี๋ยวคนก็เริ่มใช้ขึ้นเยอะเอง ด้วยแนวคิดและการกระทำของพวกหนุ่มสาวหัวก้าวหน้า แล้วค่อย ๆ ลบล้างแนวคิดของพวก Generation เก่าไป ที่ว่า 'เสร็จแล้วค่อยตรวจ' สำหรับ Test Driven Development เองก็เป็นแนวทางที่สอดคล้องกับ Agile Software Development ได้ เป็นอย่างดี เพราะแฝงปรัชญาเอาไว้ด้วย และตัว Agile เองก็มีปรัชญาของตนอยู่เหมือนกัน (ประมาณ 10 ข้อ) เป็นแนวทางที่ไม่ต้องมีพิธีรีตรองอะไรมากเหมือน Software Testing ในกระบวนการพัฒนาซอฟต์แวร์ใหญ่ ๆ อย่าง CMMI, RUP (Rational Unified Process) ทำให้เรียนรู้และทำความเข้าใจได้ง่าย และโฟกัสไปที่นักพัฒนาซอฟต์แวร์เป็นหลัก เพื่อทำให้นักพัฒนาซอฟต์แวร์เขียนโปรแกรมเก่งขึ้น เพราะงานหลายส่วนตัวเองก็ต้องเป็นคนเขียน Test เองและทดสอบเอง ดังนั้นการฝึกให้คำนึงถึงการทดสอบและตรวจสอบ ก่อนเขียนโปรแกรมหรืออิมพลีเม้นต์เป็นสิ่งที่ดี ทำให้รู้จักรอบคอบ ระมัดระวัง และไม่รีบบ้าคลั่งตะลุยเขียนโปรแกรมหน้าตั้ง พอเจอปัญหาทีก็อาจตามแก้หน้าตั้งเช่นกัน ดังนั้นการคำนึงถึงการ ทดสอบก่อน แล้วพอเขียนโปรแกรมไปประมาณหนึ่งก็ทดสอบตามกรอบหรือ Test Case ที่วางไว้ เห็นว่าไม่ถูกไม่ดี ไม่มีประสิทธิภาพก็ทำ Refactor เสีย เป็นกระบวนการแบบ Iterative ทำซ้ำไปซ้ำมาไปเรื่อย ๆ แต่ต้องระวังเรื่อง Interface เพราะโค้ดและงานออกแบบที่เกี่ยวข้องชุดนั้นอาจแชร์กับนักพัฒนาฯ คนอื่นอยู่ด้วย แต่การแก้ Interface ไม่ใช่เรื่องผิด และเป็นไปไม่ได้ แต่ต้องอยู่ภายใต้การจัดการที่ดี โดยเฉพาะ Interface ในระดับสถาปัตยกรรม (Architectural Interface) ต้องใส่ใจเป็นพิเศษ รายละเอียดเรื่อง Test Driven Development ลองหาอ่านเพิ่มเติมหรือในเว็บนี้ก็ได้ นอกจากนี้หลักการด้านสถิติก็สำคัญเช่นกัน เพราะเมื่อทดสอบแล้วต้องรู้จักบันทึกข้อมูลเป็นรายงานเชิงสถิติ พอทำการทดสอบ ครั้งต่อไป ๆ ก็เอามารวมเอามาวิเคราะห์ เช่น วิเคราะห์พวกส่วนเบี่ยงเบน ค่าเฉลี่ย การเปลี่ยนแปลง จนถึงวิเคราะห์แนวโน้ม เป็นต้น ยิ่งหากใช้ Tool ทำการทดสอบ ผลการทดสอบมักออกมาเป็นรูปรายงานเชิงสถิติ Software Tester ต้องวิเคราะห์ผลเป็น ประเด็นที่ยากยิ่งนัก โดยเฉพาะการทดสอบเกี่ยวกับพวก Performance เพราะผลการทดสอบหลาย ๆ ครั้งไม่ได้บอกแค่ว่า 'ถูกต้อง' หรือ 'ผิด' เท่านั้น ดังนั้นต้องรู้จักวิเคราะห์ผลการทดสอบแล้วเอาไปให้สมาชิกในทีม เช่น SA, Developer เป็นต้น เอาไปปรับปรุงหรือหาโซลูชั่นใหม่หรือเซ็ต Factor ใหม่ แล้วค่อยนำมาทดสอบใหม่ แล้ววิเคราะห์ผลดูว่าการทดสอบครั้งไหนที่ให้ผลที่ 'โดน' ที่สุด (ไม่ใช่ 'ดี' ที่สุด) ซึ่งหมายถึงให้ผลที่ใกล้ (Meet) กับ Requirement มากที่สุด มีหนังสือแนะนำเล่มหนึ่ง ชื่อ Effective Software Testing, 50 Specific Ways to Improve Your Testing โดย Elfriede Dustin อ่านง่ายสนุก น่าสนใจ แต่ก่อนใคร ๆ อาจรู้จักการทดสอบแบบ Black Box ในหนังสือเล่มนี้มีทั้ง ทดสอบแบบ White Box, Gray Box และอีกหลายอย่าง เป็นหนังสือที่ดีมาก ๆ เล่มหนึ่งและไม่หนานัก เหมาะแก่การวางไว้ข้างตัว เวลานึกไม่ออกว่าจะทดสอบอะไรบ้าง อย่างไรก็เปิดเล่มนี้เอา อีกเล่มชื่อ A Practical Guide to Testing Object-Oriented Software โดย John D. McGregor และ David A. Sykes หากใครพัฒนาซอฟต์แวร์แบบอ็อบเจ็คต์ เช่น ใช้ภาษา Java, C#, VB.NET เป็นต้น แล้วอยากรู้ว่า ออกแบบและเขียนโปรแกรมตรงตามหลักการของ Object-Orientation หรือไม่ก็ลองอ่านเล่มนี้ดู เล่มนี้มีประโยชน์มาก เอาไว้เป็น 'เครื่องมือ' จำผิดคนออกแบบและคนเขียนโปรแกรมที่ดีมาก ๆ ว่าแม่นเรื่องอ็อบเจ็คต์แค่ไหน และออกแบบและเขียนโปรแกรม ได้เหมาะสมกับงานหรือไม่ ส่วนแอพพลิเคชั่นใหญ่ ๆ หากมาเขียน Test Case เองและทดสอบเองไปทุกอย่างอาจเสียเวลาได้ โดยเฉพาะกับทีมเล็ก ๆ แต่ทำงานใหญ่ อาจลองศึกษาเรื่องการทำ Automated Testing ดูด้วย สำคัญมาก เจ้าตัวนี้ล่ะที่ต้องพึ่ง Tool พอสมควร แต่ประหยัดเวลาได้เยอะทีเดียว ส่วนเล่มอื่น ๆ และแหล่งอ้างอิงอื่นไว้จะเอามาฝากครับ เรื่องเกี่ยวกับ Software Testing มีแตกย่อย ๆ ไปหลายประเด็น ไม่ว่าจะเป็น Process, Method, Tool, Theory, Management ฯลฯ ช่วงนี้ขอไปสังสรรค์หน่อย ปีใหม่แล้ว เย้!  - อีกทักษะของนักตรวจสอบที่ดี คือ ช่างสังเกต ช่างจับผิด รู้จักมองโลกในแง่ร้ายบ้าง และเป็นนักสถิติ - test test ..part 1[ที่มา : minimalist (ณรงค์) http://www.narisa.com/forums/index.php?showtopic=17888&hl=software+testing]
Software Testing
จุดประสงค์หลักคือการหาข้อบกพร่องและลดข้อผิดพลาดจากการทำงานของซอฟต์แวร์ให้เหลือน้อยที่สุด
ทฤษฏีมันมีหลากหลายนะครับ แต่สำหรับผมขออธิบายประมาณนี้ละกัน การทดสอบแบ่งออกเป็น 3 มิติ (Dimension) คือ 1. Reliability Test คือ การทดสอบด้านความน่าเชื่อถือในการทำงาน 2. Functional Test คือ การทดสอบด้านฟังก์ชั่นการทำงานที่ต้องตรงตาม Requirements โดยเน้นว่าต้องตรงตาม Requirements ประเภท Functional Requirements 3. Performance Test คือการทดสอบด้านประสิทธิภาพของการทำงาน ซึ่งแบ่งออกเป็น 3.1 Application Performance Test คือ การทดสอบด้านประสิทธิภาพการทำงานของตัวซอฟต์แวร์เอง 3.2 System Performance Test คือ การทดสอบด้านประสิทธิภาพการทำงานของซอฟต์แวร์ร่วมกันสภาพแวดล้อมจริงหรือสภาพแวดล้อม ที่ Simulate ขึ้นมาใกล้เคียงสภาพแวดล้อมจริง โดยทั้ง 3 มิติ ลองนำมาวาดเป็นรูป 3 เหลี่ยมด้านเท่า โดยด้านทั้ง 3 ต้องตอบสนอง (reflect) ซึ่งกันและกัน โดยการทดสอบทั้ง 3 ด้านนี้ต้องเป็นอันหนึ่งอันเดียวกัน สอดคล้องกัน การทดสอบจึงต้องพิจารณาประกอบกัน Reliability Test เช่น - เขียนโปรแกรมแล้วคอมไพล์ผ่าน - ไม่มี error พวก Runtime Error (Exception) เช่น การคำนวณตัวเลขไม่ควรมีการหารเลขจำนวนเต็มด้วยศูนย์ - อ็อบเจ็คต์หรือตัวแปรที่ไม่ใช้แล้วไม่ควรก่อให้เกิดปัญหาภายหลังได้ เช่น กรณีลืมไว้ใน Application / Global Scope แล้วลืมลบ ทำให้ผู้อื่น access อ็อบเจ็คต์หรือตัวแปรตัวนี้ได้ อาจตั้งใจและไม่ตั้งใจ - การจัดการ Transaction เช่น การ commit / rollback ถูกต้องตาม business process - การจัดการ concurrency control ผู้ทำหน้าที่ทดสอบคือโปรแกรมเมอร์เอง เพราะเขียนโปรแกรมเองก็ต้องคอมไพล์เอง ทดสอบเบื้องต้นเอง อาจใช้การทำ Unit Test ประกอบ Functional Test เช่น ที่คนส่วนใหญ่มักทำกันคือ ทดสอบบนหน้าจอ เช่น ป้อนข้อมูลบนฟอร์ม คลิ้กปุ่ม แล้วดูผลลัพธ์ว่าถูกต้องหรือไม่ หรืออาจเขียนโปรแกรมพวก Unit Test แยกต่างหากขึ้นมาเพื่อทดสอบ Performance Test มักเกี่ยวกับพวกเวลา ทรัพยากร เช่น - ทดสอบการใช้งาน Database Connection Pool - การส่งข้อมูลผ่านเน็ตเวิร์คไปให้อีกระบบที่อยู่คนละเครื่อง - อัลกอริธึมที่ใช้มีประสิทธิภาพรวดเร็ว ไม่ใช่ทรัพยากรมาก เช่น การเขียน Loop การเช็คพวก If...Else เรื่อง Performance Test นี่มีศัพท์เทคนิคอยู่เยอะ เช่น response time, responsiveness, through put, latency....... ยกตัวอย่าง เช่น การกดเงินผ่านตู้เอทีเอ็ม Functional Test คือ 1. เสียบบัตร ได้หรือไม่ 2. กดรหัส แล้วตรวจสอบถูกหรือไม่ ถ้าตรวจสอบว่ารหัสไม่ผ่านแล้วแจ้ง error ถูกต้องหรือไม่ 3. กดเมนูเลือกถอนเงิน และเลือกบัญชี ได้หรือไม่ 4. กดจำนวนเงินที่ต้องการ ได้หรือไม่ 5. ตรวจสอบได้ว่าเงินในบัญชีพอให้ถอนได้หรือไม่ ถ้าไม่พอแล้วแจ้ง error ถูกต้องหรือไม่ 6. ถ้าถอนได้ แล้วเงินไหลออกมาหรือไม่ แล้วจำนวนเงินครบตามที่ต้องการถอนหรือไม่ 7.ถ้าถอนได้ แล้วมีสลิปออกมาให้ได้หรือไม่ รายละเอียดในสลิปถูกต้องหรือไม่ 8. บัตรไหลคืนออกมาหรือไม่ ถ้าไม่แสดงว่าบัตรโดนยึด (ผมโดนยึดบ่อยแถวมอเตอร์เวย์ 555 เซ็งเลย ตู้ซังกะบ๊วย) Reliability Test คือ 1. ตรวจสอบบัตรว่าเป็นบัตรเอทีเอ็มจริง ไม่ใช่บัตรประเภทอื่น 2. ตรวจสอบว่าหากเป็นบัตรเอทีเอ็มแต่ใส่สลับด้านหรือไม่ 3. อ่านข้อมูลจากแถบแม่เหล็กได้ถูกต้อง 4. คำนวณหักลบจำนวนเงินในบัญชีกับจำนวนเงินที่ต้องการถอนได้ถูกต้อง และคำนวณเลขทศนิยมได้ถูกต้อง เป็นต้น.... Performance Test คือ 1. ตรวจสอบบัตรว่าถูกหรือผิด กลับด้านหรือไม่ ได้ภายในเวลาไม่เกิน 2 วินาที (เวลาสมมตินะ ของจริงไม่รู้เท่าไหร่) 2. พอกดจำนวนเงินที่ต้องการถอนแล้ว ข้อมูลถูกส่งไปเซิร์ฟเวอร์ที่ธนาคารและตรวจสอบและส่งผลกลับมา ต้องไม่เกิน 2 วินาที (เวลาสมมตินะ ของจริงไม่รู้เท่าไหร่) 3. หากเงินในบัญชีพอถอนได้ แล้วทำการหักเงินในบัญชีไปแล้วข้อมูลกำลังถูกส่งมาแจ้งที่ตู้เอทีเอ็ม แต่บังเอิ๊ญญญ... สึนามิถล่มเมือง ลูกเห็บตกพร้อมกัน แผ่นดินไหวพร้อมกันอีกต่างหาก สายเน็ตเวิร์คพังกระทันหัน หน้าจอก็ไม่มีอะไรแจ้งเตือน เงินก็ไม่ไหลออกมา แล้วจะทำยังไงดี.... ต้อง Handle ตรงนี้ได้ เป็นต้น จากตัวอย่างมันจะมีประเด็นที่สำคัญมาก ๆ เข้ามาเกี่ยวข้องคือ Requirements ซึ่งแบ่งออกเป็น 2 ประเภทใหญ่ ๆ คือ Functional Requirements และ Non-Functional Requirements ซึ่งต้องพิจารณาประกอบเวลาออกแบบการ Test ก็ต้องพิจารณาประกอบ และแตกเป็นประเด็นในการทดสอบย่อย ๆ ๆ ๆ ๆ ไปอีก ในแง่การออกแบบการ Test การเขียน Test Case, Unit Test, Test Suite ฯลฯ ไม่ขอกล่าวถึงนะครับ ยาวเฟ้ย ไว้ให้เพื่อน ๆ ในนี้มาเล่าสู่กันฟังต่อละกันนะครับ เพราะการเขียนผมไม่ถนัดนัก ส่วนเทคนิคการ Test นี่ ต้องบอกว่าโอ้โห!..... มีเพียบเป็นร้อยเลย แต่เทคนิคการ Test หรือการเป็น Tester ที่ดีนะครับคือ - รู้จักมองโลกทั้งในแง่ดี และในแง่ร้าย คนที่ไม่รู้จักมองโลกในแง่ร้ายบ้างมักมองไม่เห็นปัญหาที่แท้จริง - ช่างสังเกตุ - ช่างจับผิด แต่อย่าจับผิดไปซะทุกเรื่อง เดี๋ยวไม่มีใครรัก - ชอบหาปัญหา หาสาเหตุ และหาวิธีแก้ปัญหา - ละเอียด รอบคอบ - พูดคุย อ่านเขียน สื่อสารกับเพื่อนร่วมงาน และทีมงานในหลากหลายระดับบทบาทได้ดี - ไม่ขี้เบื่อ และมีความอดทนสูง เพราะการ Test งานนาน ๆ บางทีมันน่าเบื่อมาก เรื่องเดิม ๆ test ได้เป็นอาทิตย์ ๆ ก็มี - คำนึงถึงผลประโยชน์ของผลิตภัณฑ์หรือซอฟต์แวร์ และของบริษัทเป็นสำคัญ ห้ามคำนึงถึงผลประโยชน์หรือความรู้สึกของทีมงานและโปรแกรมเมอร์เชียว เดี๋ยวจะเกิดความเห็นอกเห็นใจกัน กลายเป็นรักต้องห้าม... ว่าไปนั่น 22 décembre Hand in my pocket ....อยากแนะนำเพลงดีดีให้ฟังกัน... เวอร์ชั่น original...
I'm broke but I'm happy
I'm poor but I'm kind I'm short but I'm healthy, yeah I'm high but I'm grounded I'm sane but I'm overwhelmed I'm lost but I'm hopeful baby  What it all comes down to Is that everything's gonna be fine fine fine I've got one hand in my pocket And the other one is giving a high five  I feel drunk but I'm sober I'm young and I'm underpaid I'm tired but I'm working, yeah I care but I'm restless I'm here but I'm really gone I'm wrong and I'm sorry baby What it all comes down to
Is that everything's gonna be quite alright I've got one hand in my pocket And the other one is flicking a cigarette  And what it all comes down to Is that I haven't got it all figured out just yet I've got one hand in my pocket And the other one is giving the peace sign  I'm free but I'm focused I'm green but I'm wise I'm hard but I'm friendly baby I'm sad but I'm laughing I'm brave but I'm chickenshit I'm sick but I'm pretty baby And what it all boils down to
Is that no one's really got it figured out just yet I've got one hand in my pocket And the other one is playing the piano And what it all comes down to my friends Is that everything's just fine fine fine I've got one hand in my pocket And the other one is hailing a taxi cab [ไม่มีอารัย แค่ชอบ เนื้อหาจริงใจดี]
เพลงนี้ใช้คำง่ายๆ ท่อน verse ใช้คำตรงข้ามกันมาแต่งเป็นเนื้อ
แต่ความหมายมันช่างคมซ๊~าเหลือเกิน
ฟามหมาย :
[เชิงเปรียบเทียบ อ้อมๆ ]
มือที่มองเห็น คือสิ่งที่ ฉาบฉวย แค่ภายนอก คือสิ่งที่คนเรามอง และตัดสินกันและกันจากสิ่งที่เห็น คือสิ่งที่เราแสร้งทำก็ได้
แต่มือที่มองไม่เห็น คือตัวตน คือ สิ่งที่เป็นเราเอง ไม่ว่าจะดีหรือไม่ดีก็ตาม..
[ฟามหมายที่สื่อให้เห็นโต้งๆ จะจะ]
ทุกคนมีด้านนอกด้านใน ทุกคนยังมีตัวเองอยู่ในใจ
ยังมีอีกด้านที่ใครยังไม่รู้ คือตัวเราที่เราดำรงไว้ เป็น role model เหนือกว่าใครๆ สุดท้ายทุกคนก็นับถือตัวเองนะ มันเป็นสิ่งที่ดี เราทำอะไรทำไปเหอะเพื่อให้เข้ากับสังคมได้ แต่เราก็ยังมีตัวเราอีกคนที่เรายังยึดถืออยู่ บางทีมันอาจจะทำให้เราฟุ้งซ่าน ทำให้เป็นบ้า เพราะมันขัดกันไปหมด แต่ถ้าจริงๆ เรายังนับถือตัวเราเองคนนั้นอยู่ มันก็จะไม่เป็นไร [อีกฟามหมาย..]
การควบคุมการแสดงออก เป็นสิ่งที่ทำให้มนุษย์ต่างจากสัตว์อื่นๆ
ยังไงซะ เราก็อยู่ในโลกที่ต้องสนใจสายตารอบข้างอยู่ดี จะให้คิดแต่ว่า "รู้สึกแบบนี้ ก็ต้องแสดงออกแบบนี้สิ" ไปตลอดก็คงไม่ได้
อย่างน้อยที่สุด เรามีแค่ใครสักคนไว้แสดงความรู้สึกที่แท้จริงทุกอย่างของเราโดยไม่ต้อง"ควบคุมอารมณ์"เลย ก็น่าจะเพียงพอแล้ว
21 décembre pause ...again..วันที่เวียนเปลี่ยน วันที่เลยผ่าน
...รักคงมั่น เราไม่เคยห่าง เคียงคู่ชิดใกล้ ...ทุกเวลา ยอมทิ้งความฝัน ยอมทุกๆอย่าง ...ให้กันและกัน เพียงได้เคียงข้าง เพียงได้ร่วมทาง โอ้รักนิรันดร์ " ก่อนเคยคิดว่ารักต้องอยู่ด้วยกันตลอด
เติบโตจึงได้รู้ความจริง.." ...หากเคียงชิดใกล้
แต่เธอต้องทิ้งทุกอย่างเพื่อฉัน ...ประโยชน์ที่ใด
หากรักทำร้ายตัวเอง ...หากเดินแนบกาย
มีพลั้งต้องล้มลงเจ็บ ด้วยกัน ...ห่างเพียงนิดเดียว
ให้รักเป็นสายลมผ่านระหว่างเรา " แบ่งที่ว่างตรงกลางไว้คอย เพื่อให้เธอได้ตามหาฝัน ของเธอ .." เรียนรู้รักอย่าง รู้คุณค่า
...ฝันไม่ไกล บินไปตามทาง หาดวงตะวัน ...ที่เธอต้องการ ไม่มีฉุดรั้ง ไม่มีดึงดัน ...เราเข้าใจ รักยังแสนหวาน รักยังไม่เปลี่ยน เคียงคู่กัน วันเวลาที่เราห่างไกล ความเข้าใจจะทำให้เราใกล้กัน
กลับกลายเปลี่ยนเป็นพลัง ...หากเคียงชิดใกล้ แต่เธอต้องทิ้งทุกอย่างเพื่อฉัน ...ประโยชน์ที่ใด หากรักทำร้ายตัวเอง ...หากเดินแนบกาย
มีพลั้งต้องล้มลงเจ็บ ด้วยกัน ...ห่างเพียงนิดเดียว
ให้รักเป็นสายลมผ่านระหว่างเรา แบ่งที่ว่างตรงกลางไว้คอย เพื่อให้เราได้ถึงดั่งฝัน ร่วมกัน
.. คนสองคน ถ้ากลายเป็นคนเดียว แล้วอีกคนจะมีค่าอะไร..
20 décembre Today's hor[r]o[r]scope[For Aries zodiac]
Becoming you
The Sun, ruler of the human ego, gets together with Pluto, planet of transformation. เมื่อดาวอาทิตย์ ซึ่งเป็นดาวแห่งอัตตา (การถือตนเองเป็นสำคัญ) โคจรมาพบกับดาวพลูโต ซึ่งเป็นดาวแห่งการเปลี่ยนแปลง Changing for the better is often more about getting others to accept that you have changed.
ซึ่งทำให้ต้องมีการเปลี่ยนแปลงเพื่อสิ่งที่ดีกว่าเดิมอยู่บ่อยๆ โดยจะต้องอาศัยการยอมรับจากคนอื่นด้วย Will a lover finally accept what you have become?
สุดท้ายนี้ หวังว่า คนรัก ของคุณคงจะรับได้กับสิ่งที่คุณกำลังเป็น ทฤษฏี.......ฝากถึง.....
เก็บทฤษฎีเอาไว้ก่อน ไม่ต้องมีขั้นตอนหรอกตามสบาย แค่วัดตัวฉันด้วยหัวใจ ไม้บรรทัด คงวัดกันไม่ได้ เก็บทฤษฎีไว้ที่เก่า เค้าว่ากันยังไงให้เก็บมันไป กับฉันที่ยากเกินเข้าใจ งั้นเธอไม่ต้องเข้าใจก็ได้
ไม่ต้องไปเปิดหา ในตำราก็คงไม่มี
ฉันไม่ได้หวังให้มันเลิศเลอ จะขาดจะเกินช่างมัน
ไม่ต้องคอยเดินตามอ่ะไรทั้งนั้น กับเรื่องบางเรื่องไม่สำคัญ " ขอเราแค่ได้คบกัน " ง่ายๆ
เก็บทฤษฎีไว้ที่อื่น " ฉันไม่มีแนวทางอย่างกับใครๆ " เท่าไร
รักไม่ขอเหตุผลเลยก็ได้
12 décembre ...ใครกันที่จะสามารถวัดได้ว่า
"ใครคือคนที่จะเข้าใจโลกได้มากที่สุด ?"
มนุษย์ พระเจ้า มนุษย์ต่างดาว ? เมื่อต่าง คน ต่างเชื้อชาติ ศาสนา
ต่างก็ใช้ไม้บรรทัดที่สเกลไม่เหมือนกัน ...
|
||||||||||||||||||||||||
|
|
