More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Basic software testing v2.20
Similar to Basic software testing v2.20 (20)
Basic software testing v2.20
- 1. Basic Software Testing Guide for starting of tester career SAND 2014
- 2. Implementation Project Management Solution Integrator E2E Tester Technical Support Product Owner QA Eng. PA Project Deployment Consultant Tier-1 24x7 V-Model (software development) Tier-2 8x5 Tier-3 8x5 #1 #2 #3 #4 #5 #6 #7
- 3. Agenda 1. Software testing WHAT & WHY ? 2. Fundamentals 3. Requirement traceability matrix 4. Test Estimation & Planning 5. Test Cases, Scripts, Data 6. Test Execution 7. Classic Testing Mistake 8. Improvement 9. Workshop
- 4. Software testing WHAT & WHY?
- 5. WHAT IS SOFTWARE TESTING? • Software testing is a process of verifying and validating that a software application or program –1. Meets the business and technical requirements that guided its design and development –2. Works as expected. • Software testing also identifies important defects, flaws, or errors in the application code that must be fixed.
- 6. WHY DO SOFTWARE TESTING? • Software testing is focused on finding defects in the final product. • Software testing answers questions that development testing and code reviews can’t.
- 7. Purpose of Testing • Verification • Validation • Defect finding
- 8. Cost of fixing a defect
- 9. Testing skills and knowledge Test knowledge ▪ test principles ▪ techniques ▪ tools, etc. IT knowledge ▪ software development ▪ requirements ▪ configuration management Domain knowledge ▪ business process ▪ user characteristics Soft skills ▪ communication ▪ critical mind-set ▪ presentation and reporting
- 10. Fundamentals
- 11. Testing Principles • All tests should be traceable to customer requirements • Tests should be planned long before testing begins • Testing should begin “in the small” and progress toward testing “in the large” • To be most effective, testing should be conducted by an independent third party
- 12. Test Approach • Black box testing (Internals NOT known) • White box testing (Internals Fully known) • Grey box testing (Internals Relevant to testing known)
- 14. Aims of Black Box Testing • Find – Incorrect or missing functionality – Interface errors – Errors in data structures used by interfaces – Behaviour or performance errors – Initialization and termination errors
- 16. Aims of White Box Testing • Internal security holes • The flow of specific inputs through the code • Expected output • The functionality of conditional loops • Testing of each statement, object and function on an individual basis
- 17. Grey-box testing
- 18. Aims of Grey Box Testing • Combination of Black & White box testing • Search for improper usage of application • Search for improper structure • Tester can handle intelligent test scenario for example, data type handling, communication protocol
- 19. Methodologies • Boundary testing • Equivalence classes • Decision tables • State transitional diagrams • Risk Analysis
- 20. Boundary testing
- 22. Decision tables
- 24. Risk Analysis
- 25. Types of Testing • Unit Testing • Functional Testing • System Integration Testing • User Acceptance Testing (UAT) • Regression Testing • Beta Testing
- 26. Summary Testing Type Specification General Scope Approach Who generally does it? Unit Low-Level Design Actual Code Structure Small unit of code no larger than a class White Box Programmer who wrote code Functional High Level Design Whole product Black Box Independent tester System Requirements Analysis Whole product In representative Environments Black Box Independent tester User Acceptance Requirements Analysis Whole product in customer’s Environment Black Box Customer Beta Ad hoc Whole product in customer’s Environment Black box Customer Regression Changed Documentation High-Level Design Any of the above Black Box White Box Programmer(s) or independent testers
- 29. Traceability matrix (example) Requirement ID Requirement description TC 001(user login) TC 002 (add user) TC 003 (delete user) SR-1.1 User should be able to login using LDAP user x SR-1.2 User should be able to see error message when fail to login x SR-1.3 Admin user should be able to add user on admin page x SR-1.4 Admin user can not add duplicate user on admin page x SR-1.5 ….. x x SR-1.6 ………. x SR-1.7 ………… x
- 30. Benefits of using Traceability Matrix • To make sure that all requirements included in the test cases • To make sure that developers are not creating features that no one has requested • Easy to identify the missing functionalities.
- 31. Testing without Requirements • Tester must do the following tasks at the same time – get clarifications, understand the product's features, document test cases and testing • It is better to create checklist – All the tests to be conducted. – Proper sequence in which to execute the test cases. The correct flow will help to focus the thinking of tester at the time of execution of test cases. • Testing Approach – Ad hoc Testing – Exploratory Testing Source: http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=ART&ObjectId=6443
- 33. Estimation for Testing • Questions to be asked – Requirements finalized. If not, frequency of change – Types of Testing – Test Assets & Team are available and clear – Assumptions/Risks
- 34. Test Planning • Test Plan • Test Procedure • Test Report
- 36. Test Case
- 37. Test Cases Contents • Purpose • Pre-condition • Test Data • Action • Expected response • Comment • Post Condition
- 38. Sample test case
- 39. Test Data • Test data can be said. to be ideal if for the minimum size of data set all the application errors get identified • Prepare test data that will incorporate all application functionality, but not exceeding cost and time constraint for preparing test data and running tests • Poorly designed testing data may not test all possible test scenarios which will hamper the quality of the software. • Good test data will help us; – Rely on the result of testing – Reduce the testing schedule and effort
- 40. Test execution
- 41. Test Execution • Execute the test cases • Logging Defects • Re-execute test cases after every change – Automate as much as possible for instance, after each refactoring • Regression testing – Testing that everything that used to work still works after changes are made to the system – rerunning test cases from existing test suites to build confidence that software changes have no unintended side-effects
- 43. Defect flow
- 44. What if there isn’t enough time for testing?
- 46. Classic testing mistakes • The developer should not be testing at all – Test before you code • Testers get only involved once software is done – Testers should be involve since project start • Toss the software over the wall for testing – Testers and developers collaborate in developing the test suite • Testing team is responsible for assuring quality – Quality is assured by a good software process
- 47. Improvement
- 48. Become a Better Tester • Test for quality over quantity • Practice and improve • Learn from your own mistakes and from others too • Be objective and professional • Don’t be humble with software… think out of the box • Question. Everything • Think like the user • Increase the effectiveness of bug reports • Be Passionate!
- 49. Personal attributes of highly effective testing professionals • Curiosity • Cautious • Good work ethic • Desire to make a difference • Discipline • Quality focus and orientation • Personal organization • Quick learner • Desire to share information • Communication skills • Team player
- 50. Achieve in S/W Testing •Keep your eye open •Avoid the work and relax, you may miss some bugs •Look at the application in the negative way, you will always find the bugs. •Bugs are in many places, don’t skip your testing. Client does not know a defect is small or big. •Think of the persons who use the application, define scenarios (Test cases) and execute them
- 51. Defect Management • Thorough understanding • Adhere to processes • Verify defects before distribute • Capture Screenshot and steps • Raise every bugs in the defect tracking tool • Always use the facts • Keep track of impact of bugs and associate to the risks • Some defects may not resolve, prepare for these • Never close the defects because of your feeling or not finding by developer
- 52. Workshop
- 53. Workshop1 : ประโยคด ้านล่างถูกหรือผิด (True/False) B. ก่อนที่กระบวนการ Test จะเริ่มขึ้น ต ้องรอให ้ Software พัฒนา เสร็จเรียบร ้อยก่อน A. การทา Unit Testing อยู่ในขั้นตอนการ Develop Software (Construction Phase) C. การ Develop และการ Test ควรทาโดยบุคคลคนเดียวกัน D. การทา Software ต ้องมีกระบวนการ Test เข ้ามาเกี่ยวข ้องเสมอ
- 54. Workshop2 : จับคู่ข ้อมูลที่สัมพันธ์กัน ความหมาย คาที่เกี่ยวข้อง 1 เลือกตัวแทนของข ้อมูลในแต่ละกลุ่มมาทดสอบ Testing from formal specifications 2 การทา Test Case จะเลือกค่าขอบบน และขอบ ล่างของชุดข ้อมูล Equivalence Partitioning 3 พิจารณาทุก ๆ ค่าที่เป็นไปได ้ของข ้อมูลที่จะ inputs, actions และ outputs ที่จะได ้ Finite state machine-based 4 การทดสอบที่ครอบคลุมเรื่อง Transition Boundary value analysis 5 สิ่งที่ใช ้ในการการันตีว่า Software ถูกต ้อง Decision Table
- 55. Workshop3 : คิดจานวน Test Case แบบ Equivalence Partitioning ตู้ATM จะจ่ายเงินเป็นธนบัตรครั้งละ 20$ โดยสามารถจ่ายธนบัตร ได ้จานวนเงินตั้งแต่ 20$ ถึง 300$ หากทาการทดสอบจะมีจานวน Test Case แบบ Equivalence ทั้งหมดเท่าไหร่ A. 15 B. 3 C. 6 D. 5
- 56. Workshop4 : คิดจานวน Test Case แบบ Boundary value analysis ตู้ATM จะจ่ายเงินเป็นธนบัตรครั้งละ 20$ โดยสามารถจ่ายธนบัตร ได ้จานวนเงินตั้งแต่ 20$ ถึง 300$ หากทาการทดสอบจะมีจานวน Test Case แบบ Boundary ทั้งหมดเท่าไหร่ A. 15 B. 3 C. 6 D. 5
- 57. Workshop5 : คิด Test Case แบบ White box ได ้กี่แบบ จาก Flow ด ้านล่าง ถ ้าต ้องการทดสอบ White box Testing จะมี จานวน Test Case อย่างน้อยกี่ Test Case A. 3 B. 4 C. 5 D. 6
- 58. Answer
- 59. Answer1 : ประโยคด ้านล่างถูกหรือผิด (True/False) A. การทา Unit Testing อยู่ในขั้นตอนการ Develop Software (Construction Phase) True B. ก่อนที่กระบวนการ Test จะเริ่มขึ้น ต ้องรอให ้ Software พัฒนาเสร็จ เรียบร ้อยก่อน False C. การ Develop และการ Test ควรทาโดยบุคคลคนเดียวกัน False D. การทา Software ต ้องมีกระบวนการ Test เข ้ามาเกี่ยวข ้องเสมอ True
- 60. Answer2 : จับคู่ข ้อมูลที่สัมพันธ์กัน ความหมาย คาที่เกี่ยวข้อง 1 เลือกตัวแทนของข ้อมูลในแต่ละกลุ่มมาทดสอบ Equivalence Partitioning 2 การทา Test Case จะเลือกค่าขอบบน และขอบ ล่างของชุดข ้อมูล Boundary value analysis 3 พิจารณาทุก ๆ ค่าที่เป็นไปได ้ของข ้อมูลที่จะ inputs, actions และ outputs ที่จะได ้ Decision Table 4 การทดสอบที่ครอบคลุมเรื่อง Transition Finite state machine-based 5 สิ่งที่ใช ้ในการการันตีว่า Software ถูกต ้อง Testing from formal specifications
- 61. Answer3 : คิดจานวน Test Case แบบ Equivalence Partitioning ตู้ATM จะจ่ายเงินเป็นธนบัตรครั้งละ 20$ โดยสามารถจ่ายธนบัตร ได ้จานวนเงินตั้งแต่ 20$ ถึง 300$ หากทาการทดสอบจะมีจานวน Test Case แบบ Equivalence ทั้งหมดเท่าไหร่ A. 15 B. 3 C. 6 D. 5
- 62. Answer4 : คิดจานวน Test Case แบบ Boundary value analysis ตู้ATM จะจ่ายเงินเป็นธนบัตรครั้งละ 20$ โดยสามารถจ่ายธนบัตร ได ้จานวนเงินตั้งแต่ 20$ ถึง 300$ หากทาการทดสอบจะมีจานวน Test Case แบบ Boundary ทั้งหมดเท่าไหร่ A. 15 B. 3 C. 6 D. 5
- 63. Answer5 : คิด Test Case แบบ White box ได ้กี่แบบ จาก Flow ด ้านล่าง ถ ้าต ้องการทดสอบ White box Testing จะมี จานวน Test Case อย่างน้อยกี่ Test Case A. 3 B. 4 C. 5 D. 6 L-node+2 = 10-8+2 = 4
Editor's Notes
- Description : จุดประสงค์ของ course นี้ เพื่อต้องการปูพื้นฐาน การ test ให้กับพนักงานในองค์กร และเพื่อให้ทุกคนตระหนักและเห็นความสำคัญของการ Test อย่างถูกต้อง และมีกระบวนการ
- Description : ตัวอย่างของ Process ที่ควรจะมีในกระบวนการพัฒนา software โดยยกตัวอย่าง V-Model Trainer : อ่านเพิ่มเติมได้ที่ Wikipedia : V-Model (software development) ตรงนี้ให้ อธิบายให้ผู้เข้าเรียน เข้าใจกระบวนการทำ software development เบื้องต้น โดยทุกกระบวนการต้องมี Input และ Output เนื่องจากถ้ากระบวนการทำ software ไม่ดี การ Test ที่ดีแค่ไหนก็ไม่สามารถทำให้ software สำเร็จแบบมีคุณภาพได้ Concept of Operations & Implement Project Management จะเป็นการ รวบรวม requirement และ ทำให้ละเอียดลงเป็น feature ย่อยๆ รวมถึงการกำหนดหน้าที่ต่างๆของ Project Members. Requirement & Architecture เมื่อได้ requirement ย่อยแล้วสามารถทำ Use Case Diagram ของ Feature ต่างๆรวมถึงออกแบบ architecture เพื่อให้นำไปทำ Detailed Design ต่อได้ รวมกันเป็นข้อมูลตั้งต้นให้ E2E Tester สามารถนำไปใช้ออกแบบ Test Case สำหรับ E2E Detailed Design ออกแบบ Technical Spec เพื่อให้ Programmer สามารถเริ่ม coding และ QA Engineer สามารถเริ่มเขียน Test Plan/ Test Case ได้พร้อมๆกัน Implementation Programmer ทำการ coding ตาม spec ที่ได้รับ จนได้ software ที่ต้องการออกมา เมื่อ Software เสร็จแล้วก็ส่งเข้ากระบวนการ Test ในกรณีที่ software นั้นต้องการ Functional หรือ Integration Test เมื่อ Software เสร็จแล้วก็ส่งเข้ากระบวนการ Test ในกรณีที่ software นั้นต้องการ E2E Test เมื่อผ่านการ Test แล้วทำการ Rollout ได้เลย ฝั่งขวาสุดเป็น Operation support ซึ่งสามารถใช้เอกสารต่างๆที่จัดทำไว้ใน step 1,2,3,5,6,7 เพื่อ support product ได้ ตรงนี้นำมาใส่เพื่อให้เห็นทั้ง Life Cycle ว่ามี O&M ด้วย และควรคิด O&M ตั้งแต่เริ่มทำ software
- Description : หัวข้อในการสอน Trainer : อธิบาย Agenda อย่างย่อของแต่ละหัวข้อ ว่ามีอะไรบ้าง ใช้เวลาเท่าไหร่ Software testing WHAT & WHY ? การอธิบายเหตุผลและประเป็นหลักว่าเพราะอะไรและทำไมจึงทำการ Test Software 2. Fundamentals อธิบายทฤษฎีพื้นฐานต่างๆที่ควรรู้ก่อนการมาเป็น Programmer, SA, PM และ Tester เนื่องจากการ Test นั้นต้องทำกับทุกๆ software ในกระบวนการผลิต 3. Requirement traceability matrix : อธิบายถึงความสำคัญของการทำ traceability matrix 4. Test Estimation & Planning : การประเมินการ Test และวางแผนการ Test ให้มีประสิทธิภาพ 5. Test Cases, Scripts, Data : อธิบายความหมายและการใช้งาน Test Case, Test Script, Test Data ให้เกิดประโยชน์สูงสุด 6. Test Execution : การ Run Test ควรทำอย่างไรบ้าง 7. Classic Testing Mistake : ความเข้าใจผิดๆเกี่ยวกับการ Test 8. Improvement : จะเป็น Tester ที่ดีกว่า ต้องพัฒนาความสามารถด้านไหนบ้าง 9. Workshop
- Description : เริ่มด้วย คำถามเพื่อเกริ่นนำ การสอน , Test เพื่ออะไร, ทำไมต้อง Test, และ ใคร Test Trainer : เริ่มกล่าวแนะนำ What is software testing
- Description : Software testing เป็นกระบวนการ Verify และ Validate Software โดยสามารถหา Software Defect ต่างๆเพื่อทำการแก้ไข Trainer : อธิบายตาม Slide ได้เลย
- Description : ทำไมต้อง Test, 1. เพราะต้องหา Defect ให้ได้มากที่สุดก่อนสินค้าจะถูกปล่อยออกสู้ท้องตลาด 2. นอกจากนั้น Software Testing ยังสามารถตรวจสอบ software ได้จากการ run ที่ไม่สามารถตรวจสอบจาก code ได้ เช่น – Does it really work as expected? ทำงานได้ตามคาดหวังหรือไม่ – Does it meet the users’ requirements? ตรงตามที่ user ให้ requirement มาใช่ไหม – Is it what the users expect? ตรงตามที่ user ต้องการใช่ไหม – Do the users like it? User ชอบมันหรือเปล่า? – Is it compatible with our other systems? เข้ากับระบบอื่นๆที่เรามีได้หรือไม่ เช่น ชนิดของ web browser. – How does it perform? คสามรวดเร็วในการใช้งาน – How does it scale when more users are added? เมื่อไหร่ที่ต้องขยายระบบ – Which areas need more work? มีตรงไหนอีกบ้างที่ต้องปรับปรุง – Is it ready for release? ตอนนี้พร้อมสำหรับการส่ง software ให้ลูกค้าแล้วหรือยัง 3. Who? ใครเป็นคน Test : Tester หรือสมาชิกในทีมที่ไม่ใช่คนเขียน Program นั้นๆ Trainer : อธิบายตาม note
- Description : • Verification – meets its technical specifications คือ การตรวจสอบว่า application ทำงานได้ถูกต้องตาม Technical Spec ไหม • Validation – meets the business requirements คือ การตรวจสอบว่า application ทำงานได้ถูกต้องตาม requirement หรือไม่ • Defect finding – A defect is a variance between the expected and actual result คือการตรวจสอบว่า result จริงๆต่างจาก expect result หรือไม่ Trainer : อธิบายตาม Note เพื่อให้เข้าใจจุดประสงค์การ Test. คือ Verification, Validation and Defect Finding
- Description : จาก Chart จะเป็นค่าใช้จ่ายในการแก้ Defect ที่เจอตอน Software ขึ้นไปแล้วในแต่ละ Stage ของการทำ software ถ้าเจอปัญหาเร็วก็จะมีค่าใช้จ่ายในการแก้ไขน้อย ซึ่งค่าเสียหายส่วนมากเป็น Brand Image Trainer : อธิบายถึงผลกระทบของการเจอ Defect ในแต่ละช่วงเวลาของการทำ Software ว่า เมื่อเจอในขั้นตอนที่ Launch ไปแล้ว cost ในการแก้ไขจะสูงมาก โดนเฉพาะค่า Brand Image ซึ่งไม่สามารถประเมินได้ ยกตัวอย่าง CRV, รถยนต์ต่างๆที่ต้อง Recall.
- Description : Skill ที่ Tester ควรมีแบ่งออกเป็นสี่ส่วน โดย course นี้จะสอนเฉพาะ Test Principles & techniques. Trainer : อธิบายการใช้งาน skill ต่างๆในชีวิตประจำวัน ว่าทำไม่ต้องใช้เพื่อให้งานเดินต่อไปได้ ควรจะเน้นย้ำว่าการรับคนมาทำงานด้าน Test ควรมีพื้นฐานข้างต้นให้มากที่สุด
- Description : Trainer : บทนี้ให้อธิบายพื้นฐานการ Test
- Description : Testing Principles – หลักการในเชิงทฤษฎีสำหรับการ Test เพิ่มเติม exhaustive testing - Executing a program with all possible combinations of inputs or values for program variables. ถ้าทำ Exhaust Test ไม่ได้ก็ให้แบ่งการ Test เป็นส่วนๆ Trainer : อธิบายตาม slide • All tests should be traceable to customer requirements : ถ้า Test แล้ว Trace ไม่ได้ก็ไม่สามารถบอกได้ว่าที่เรา Test นั้นถูกต้องหรือไม่ • Tests should be planned long before testing begins : การวางแผนสามารถทำให้เขียน test case ได้ดี เก็บรายละเอียดได้ครบ และ มีความสุขในการทำงาน • Testing should begin “in the small” and progress toward testing “in the large.” : เริ่มจากเล็กไปใหญ่ จะดีกว่าเสมอ • To be most effective, testing should be conducted by an independent third party : ต้องไม่ใช่ทีม Develop Test คน Test ควรเป็นคนอื่นเพื่อป้องกัน การลำเอียง
- Test Approach คือ ประเภทการ Test ในแบบต่างๆ Description : • Black box testing (also called functional testing) is testing that ignores the internal mechanism of a system or component and focuses solely on the outputs generated in response to selected inputs and execution conditions. • White box testing (also called structural testing and glass box testing) is testing that takes into account the internal mechanism of a system or component. • Grey box testing Testing software while already having some knowledge of its underlying code or logic. It implies more understanding of the internals of the program than black box testing, but less than white box testing Trainer : อธิบายความแตกต่างของการ Test ทั้งสามแบบพร้อมทั้ง ยกตัวอย่างงาน Test ของผู้เข้าเรียนว่าเป็นแบบไหน
- Description : Trainer :
- Description : - incorrect or missing functionality ตรวจสอบการ function ว่าทำงานผิดปกติหรือไม่ – interface errors ตรวจสอบ Interface หรือ Gui ต่างๆว่าตรงตามที่ออกแบบไว้หรือไม่ – errors in data structures used by interfaces ตรวจสอบความถูกต้องของโครงสร้างข้อมูล – behaviour or performance errors ตรวจสอบปัญหาพฤติกรรมการใช้งานหรือ performance – initialization and termination errors ปัญหาการเปิด ปิด application Trainer : อธิบายจุดประสงค์การ Test แบบ Black Box
- Description : Trainer :
- Description : จุดมุ่งหมายของการทำ whitebox testing Trainer : อธิบาย Aim แต่ละแบบว่าเพื่ออะไร ทำไมถึงต้อง Test และเมื่อไหร่ต้องใช้ • Internal security holes ตรวจสอบช่องโหว่ของ security (อ้างอิงความรู้จาก SSDLC ได้เลย) • The flow of specific inputs through the code ตรวจสอบ input ที่เข้ามา process ใน code • Expected output ตรวจสอบ output ที่คาดหวังไว้ • The functionality of conditional loops ตรวจสอบปัญหา looping เช่น มากหรือน้อยไป ซึ่งอาจจะกระทบกับ Performance • Testing of each statement, object and function on an individual basis ตรวจสอบระดับ object, statement , function จนถึง line of code
- Description : Grey Box Testing (grey สะกดแบบอังกฤษ) Trainer : คำอธิบายอยู่ slide ถัดไป
- Description : จุดมุ่งหมายของการทำ Greybox testing Trainer : อธิบาย Aim แต่ละแบบว่าเพื่ออะไร ทำไมถึงต้อง Test และเมื่อไหร่ต้องใช้ • Combination of Black & White box testing เป็นการรวมเทคนิคการ Test ของทั้งสองแบบเข้ามาด้วยกันเพื่อให้การ Test มีความละเอียดมากยิ่งขึ้น • Search for improper usage of application – ตรวจสอบว่า Software ทำงานผิดหรือไม่. • Search for improper structure – สามารถตรวจสอบโครงสร้าง software หรือ โครงสร้างฐ่นข้อมูลได้ • Tester can handle intelligent test scenario for example, data type handling, communication protocol ตรวจสอบการจัดการ error ต่างๆ, ตรวจสอบการจัดการใช้ชนิดของข้อมูลว่าถูกต้องหรือไม่
- Description : อธิบายทฤษฎีการ Test แต่ละแบบว่าเพื่ออะไร เมื่อไหร่ต้องใช้ • Boundary testing : Test ขอบเขตของsoftware เช่น min/max value • Equivalence classes : Test โดยใช้ข้อมูล input ต่างๆ ที่คลอบคลุม เหมาะสมมา test โดยจะทำให้ Test case น้่อยที่สุด • Decision tables : Test เพื่อทดสอบการทำงานของ software ว่าตัดสินใจตาม action และ input ที่วางไว้ และครอบคลุมทุก condition หรือไม่ • State transitional diagrams : ในการตรวจสอบดูจาก status เป็นหลัก ว่า state ในแต่ละ event ถูกต้องหรือไม่ • Risk Analysis : ใช้เพื่อประเมินว่า case ไหรมีความสำคัญในการ Test มากกว่ากัน (ใช้ในกรณีที่ Test ไม่ทันแล้วต้องเลือกสิ่งที่สำคัญมาก Test ก่อน) Trainer : อธิบายตาม description, ส่วนของรายละเอียดจะอยู่ใน slide ต่อไปของแต่ละ methodology Methodology = วิถีแห่งการ Test
- Test ขอบเขตของsoftware เช่น min/max value
- Test โดยใช้ข้อมูล input ต่างๆ ที่คลอบคลุม เหมาะสมมา test โดยจะทำให้ Test case น้่อยที่สุด แต่คลอบคลุม requirement ทั้งหมด
- Test เพื่อทดสอบการทำงานของ software ว่าตัดสินใจตาม action และ input ที่วางไว้หรือไม่ เพื่อให้ครอบคลุม condition ต่างๆทั้งหมด
- เป็นการ Test การเปลี่ยนแปลง state ในแต่ละเหตุการณ์ ว่ามีผลตรงตามที่คาดหวังหรือไม่ จากตัวอย่างเป็นระบบการฝาก-ถอนเงินของบัญชีธนาคาร * Overdraft เบิกเงินเกินบัญชี
- The process of assessing identified risks to estimate their impact and probability of occurrence (likelihood). Likelihood = The probability or chance of an event occurring (e.g., the likelihood that a user will make a mistake and, if a mistake is made, the likelihood that it will go undetected by the software) Impact = The damage that results from a failure (e.g., the system crashing or corrupting data might be considered high impact) คือการหา ค่าความเสี่ยง และ การประเมินผลกระทบ จากความเป็นไปได้ต่างๆ เพื่อเป็นข้อมูลในการเลือก Test สิ่งที่สำคัญมากๆก่อน
- Description : Unit Testing : การ Test Function ส่วนย่อยๆบน software โดย developer Functional Testing : การ Test Function ที่ระบุใน requirement ว่าสามารถใช้งานได้ตรงตาม requirement หรือไม่ System Integration Testing : test การเชื่อมต่อระหว่าง Software แต่ละส่วนว่าสามารถต่อแล้วใช้ได้หรือไม่ User Acceptance Testing (UAT) : Test โดยลูกค้า ว่าลูกค้าพอใจ และผ่านหรือไม่ Regression Testing : Test เพื่อทดสอบว่าการแก้ไข software นั้นมีผลกระทบต่อ function อื่นๆหรือไม่ Beta Testing : ใช้ลูกค้าจริง ใช้งานระบบที่เกือบสมบูรณ์แล้ว เช่น Angry Birds เปิดให้เล่นฟรีสำหรับ Beta version Trainer : อธิบาย type ของการ Test ต่างๆอย่างละเอียด
- Description : ตารางเปรียบเทียบการใช้ Approach ต่างๆกับ Testing Type Trainer :
- Description : Process การ Test Trainer : อธิบายตาม process ได้เลย
- Description : มีเพื่อให้สามารถดูว่า Test Case ทั้งหมดนั้นครอบคลุม requirement แล้วใช่ไหม และยังมีไว้ใช้สำหรับ track หา bug ว่าเกิดจาก test case ไหน และสามารถใช้เชื่อมโยงไปถึง requirement ได้รวดเร็ว
- • To make sure that all requirements included in the test cases • To make sure that developers are not creating features that no one has requested • Easy to identify the missing functionalities.
- Description : • Tester must do the following tasks at the same time – get clarifications, understand the product's features, document test cases and testing • It is better to create checklist – All the tests to be conducted. – Proper sequence in which to execute the test cases. The correct flow will help to focus the thinking of tester at the time of execution of test cases. • Testing Approach – Ad hoc Testing คือการ Test โดยไม่มี plan และ document ซึ่งมีประโยชน์คือสามารถหา defect ที่สำคัญได้อย่างรวดเร็ว – Exploratory Testing คือการที่คน Test แต่ละคนมีอิสระในการ test ตามที่ตัวเองต้องการ โดยการเรียนรู้ software ไปแล้ว test ไป โดยมีจุดมุ่งหมายคือให้งานออกมามีคุณภาพมากที่สุด Trainer :
- Description : การวางแผนเพื่อ plan งานและประเมินการ Test รวมถึงการแก้ปัญหาเฉพาะหน้า
- Description : Trainer : – Is the Infrastructure for Testing ready? If Test Assets are available, What Stage they are in? *Test assets คือสิ่งต้องมีเพื่อทำให้การ Test สำเร็จลุล่วง
- Description : การทำ Test Planning ต้องประกอบไปด้วยอะไรบ้าง Trainer : • The Test Plan – defines the scope of the work to be performed. เราจะวางแผนอย่างไร, ใช้วิธีการ Test แบบไหน • The Test Procedure –a container document that holds all of the individual tests (test scripts) that are to be executed •The Test Report –documents what occurred when the test scripts were run
- Description : การวางแผนเพื่อ plan งานและประเมินการ Test รวมถึงการแก้ปัญหาเฉพาะหน้า
- A test case in a practical sense is a test-related item which contains the following information: – A set of test inputs. These are data items received from an external source by the code under test. The external source can be hardware, software, or human. – Execution conditions. These are conditions required for running the test, for example, a certain state of a database, or a configuration of a hardware device. – Expected outputs. These are the specified results to be produced by the code under test. Test Case ที่ดีต้องสะท้อนความเป็นจริง, ตรวจสอบความถูกต้องของ requirement ได้แม่นยำ และมุ่งเน้นการหาจุดบกพร่องของ software ให้ได้มากที่สุด A good Test Case is one which is more realistic, validates requirements and intends to find maximum defects.
- Purpose: Short sentence or two about the aspect of the system is being tested. If this gets too long, break the test case up or put more information into the feature descriptions. Pre-conditions: Assumptions that must be met before the test case can be run. E.g., "logged in", "guest login allowed", "user test user exists". Test Data: List of variables and their possible values used in the test case. You can list specific values or describe value ranges. The test case should be performed once for each combination of values. These values are written in set notation, one per line. E.g.: loginID= {Valid loginID, invalid loginID, valid email, invalid email, empty} password = {valid, invalid, empty} Action: 1.Steps to carry out the test. See step formatting rules below. visit Login Page 2.enter user ID 3.enter password 4.click login 5.see the terms of use page 6.click agree radio button at page bottom 7.click submit button 8.see Personal Page 9.verify that welcome message is correct username Expected Response : What actions or information that will be happened after finish all those steps? Comment : Any information that need to be considered during test execution process. Post-conditions:
- ใส่ตัวอย่าง Test case ตามตาราง sample
- อธิบายการเตรียม data ให้เหมาะสมกับการ Test
- Description : อธิบายถึงการเริ่มลงมือ test, อธิบาย process การ test เบื้องต้น
- Description : Trainer : – Automate as much as possible for instance, after each refactoring ควรทำ automate test ให้มากที่สุดหลังจากการปรับปรุง code.
- Description : Trainer :
- Description : Trainer :
- Description : • Here are some points to be considered when you are in such a situation: – Find out Important functionality is your project? – Find out High-risk module of the project? – Which functionality is most visible to the user? – Which functionality has the largest safety impact? – Which functionality has the largest financial impact on users? – Which aspects of the application are most important to the customer? – Which parts of the code are most complex, and thus most subject to errors? – Which parts of the application were developed in rush or panic mode? – What do the developers think are the highest-risk aspects of the application? – What kinds of problems would cause the worst publicity? – What kinds of problems would cause the most customer service complaints? – What kinds of tests could easily cover multiple functionalities? • Considering these points you can greatly reduce the risk of project releasing under less time constraint. Trainer :
- Description : อธิบายถึงการเริ่มลงมือ test, อธิบาย process การ test เบื้องต้น
- Description : Trainer : ให้เสริมเรื่องความเข้าใจผิดบ่อยๆ ที่เกี่ยวกับการ Test
- Description : เมื่อเป็น Tester แล้ว เราจะปรับปรุงตัวอย่างไรให้เก่งขึ้น Trainer : อธิบายตามความชำนาญและประสบการณ์
- Description : เลือกเฉพาะข้อเด่นๆ เพื่ออธิบาย Trainer : อธิบายตามความชำนาญและประสบการณ์ • Don’t be humble with software… think out of the box อย่ากลัว software ให้พยายามคิดนอกกรอบเข้าไว้
- Description : เลือกเฉพาะข้อเด่นๆ เพื่ออธิบาย Trainer : อธิบายตามความชำนาญและประสบการณ์ Curiosity – ขึ้สงสัย Cautious – ระมัดระวัง Good work ethic – มีจรรยาบรรณในการ test Desire to make a difference – หามุมมองที่แตกต่าง, ทำให้ดีขึ้นเรื่อยๆ
- Description : เลือกเฉพาะข้อเด่นๆ เพื่ออธิบาย Trainer : อธิบายตามความชำนาญและประสบการณ์
- Description : เลือกเฉพาะข้อเด่นๆ เพื่ออธิบาย Trainer : อธิบายตามความชำนาญและประสบการณ์
- Description : Trainer :