Nội dung

Testing Process nttthuy@hcmuaf.edu.vn Content • Process lab – Project Management – Software Development Management • Testing Process • Tools – Bug zilla Purpose • To verify that all requirements have been correctly implemented • To verify the proper integration of all components of the software • To validate that the product, as provided, will fulfill its intended use when placed in its intended environment • To determine how well a system meets its original objectives Defect • Any type of undesired result is a defect. • The failure meets one of the acceptance criteria of your customers. • A defective unit may have one or more defects. • A defect is a failure to conform to requirements' (Crosby, 'Quality Is Free'), whether or not those requirements have been articulated or specified. • The non-conformance intend usage requirement Bug • It is a problem in software. The part of code that makes the program behaves in an unwanted manner. • The sooner a bug is detected in the Software Lifecycle, lesser would be the cost involved in fixing it. • The term bug came from the fact that a moth flew into an early computer that ran on vacuum tubes. Error • It is a mistake, a wrong action attributable to bad judgment or ignorance or inattention Severity • After the bug is opened, it has to be classified as the severity and make the priority for those bugs • Critical: Any bug/defect/error that stops the standard functionality of program from working as designed, no work around is available. It may get to rework with big cost or can not acceptable by customer or it is inconsistent with the requirement. • Major: Any bug/defect/error that affects standard program functionality from working as designed, a work around is available Severity • Normal: Any bug/defect/error that affects enhanced program features from working as designed, a work around is available • Minor: The product is not working as it was designed, but this is a cosmetic or trivial problem that has little or no business impact on the customer. • Trivial: Fix if possible Priority Root cause • The root cause of the bug/defect/error is also to locate for getting the experience and make the “lesson learn” Test types • Unit Test: ensures that each piece of code that has been written performs the function that it is designed to do – Black Box Testing: concrete box or functional testing does NOT require knowledge of internal logic or code structure. Tester only gives the “legal” inputs and verifies the outputs – White Box Testing: requires knowledge of internal logic or code structure. • This examines the program structure and derives test data from the program logic • This includes not only correct inputs, but also incorrect inputs. Test types • Integration – Integration testing is performed as the next level of unit testing. This focuses on testing the integration of “units of code” or components to ensure that the unit test of developers is OK – It is the testing of a partially integrated application to cause failures resulting from defects involving the interaction of tested components. • Assembly – Assembly testing is to ensure that all modules within the application are functioning as per the requirements and design as a seamless entity Test types • Functional – Functional testing is to validate that the application designed functions as per the business requirements and business rules of the client. – Functionality of the system will consider positive and negative scenarios. • Interface – The purpose of interface testing is to ensure that the application operates efficiently and effectively outside the application boundary with all interface systems • Regression – Testing is done to ensure that the applied changes to the application have not adversely affected previously tested functionality Test types • System Integration – System Integration testing is the black box testing of an integrated application against its requirements. To ensure that – Validate the application (i.e., to determine if it fulfills its requirements). – Identify defects that are not efficiently identified during unit and integration testing. – Determine the extent to which the system is ready for launch. – Provide project status metrics (e.g., percentage of use case paths successfully tested). Test types • Performance test – Identify inefficiencies and bottlenecks with regard to application performance: Capacity, Latency, time, transaction • Stress test/Load test – Ensure the application attempts to cause failures involving how the performance of a system varies under normal conditions of utilization: Functional Variants, Internationalization (e.g., multiple languages, currencies, taxes and tariffs, time zones, etc.), Personalization Test types • Timing test – Test the order of operations and the response time of application • Security test – Ensure the application against its security requirements: Identification, Authentication, Authorization, Content Protection, Integrity, Intrusion Detection, Non repudiation, Privacy, System Maintenance Test types • Sandwich – Sandwich testing is to ensure that the application will be tested as an incremental testing strategy in which tester test the top layers and bottom layers, and finally test the integrated system • Sanity – Sanity testing t is performed whenever a cursory testing is sufficient to prove the application is functioning according to specifications. It is also set of core tests of basic GUI functionality to demonstrate connectivity to the database, application servers, printers, etc Test types • Environment test – Test the application in other environment: platform, OS, software bases • Installation test – Ensure that the installation guide and packet of application be developed correctly • Configuration test – Ensure the application under different hardware and software configurations to determine an optimal system configuration Test types • UAT – The purpose of user acceptance testing is to confirm that the system is developed according to the specified user requirements and is ready for operational use Testing Process • Describe Testing process • Related documents – Project Management • Test Plan – Software Development Management • • • • Unit Test Guideline System Test case Test Report Peer Review Report & Tracking Testing process REQs document Software REQs Specification Test procedure Test Test Test Test Plan; Case/Test procedure; scripts, Builds; Data Plan test Design test Implement test Execute test Evaluate test Test plan Test case Test Script Test Summary Report Defect Tracking Report Plan Test Output: Test plan Design Test Output: Test case Implement test • Test Scripts: are produced that define how the Test Cases will be executed • Test data: The actual (set of) values used in the test or that are necessary to execute the test. The data sets will include multiple scenarios for a wide coverage on data attributes and positive and negative scenarios • Test log: The Test Data section identifies any existing test data that will be used during the testing, either as is or with modifications. It also identifies any test data that will need to be created for testing • Guidelines, checklists that use in testing Execute Test Output: Test report Evaluate test • Fulfill Defect Tracking report • Summary the Testing • Make the lesson learnt Q&A Thank you