Test plans. Test Plans A test plan states: What the items to be tested are At what level they will be tested What sequence they are to be tested in How.

Slides:



Advertisements
Similar presentations
TWO STEP EQUATIONS 1. SOLVE FOR X 2. DO THE ADDITION STEP FIRST
Advertisements

©2011 1www.id-book.com Evaluation studies: From controlled to natural settings Chapter 14.
By D. Fisher Geometric Transformations. Reflection, Rotation, or Translation 1.
Aviation Security Training Module 4 Design and Conduct Exercise II 1.
Business Transaction Management Software for Application Coordination 1 Business Processes and Coordination.
Jeopardy Q 1 Q 6 Q 11 Q 16 Q 21 Q 2 Q 7 Q 12 Q 17 Q 22 Q 3 Q 8 Q 13
Jeopardy Q 1 Q 6 Q 11 Q 16 Q 21 Q 2 Q 7 Q 12 Q 17 Q 22 Q 3 Q 8 Q 13
0 - 0.
DIVIDING INTEGERS 1. IF THE SIGNS ARE THE SAME THE ANSWER IS POSITIVE 2. IF THE SIGNS ARE DIFFERENT THE ANSWER IS NEGATIVE.
MULTIPLYING MONOMIALS TIMES POLYNOMIALS (DISTRIBUTIVE PROPERTY)
ADDING INTEGERS 1. POS. + POS. = POS. 2. NEG. + NEG. = NEG. 3. POS. + NEG. OR NEG. + POS. SUBTRACT TAKE SIGN OF BIGGER ABSOLUTE VALUE.
SUBTRACTING INTEGERS 1. CHANGE THE SUBTRACTION SIGN TO ADDITION
MULT. INTEGERS 1. IF THE SIGNS ARE THE SAME THE ANSWER IS POSITIVE 2. IF THE SIGNS ARE DIFFERENT THE ANSWER IS NEGATIVE.
Addition Facts
1 Drafting a Standard n Establish the requirements n Agree the process n Draft the Standard n Test the Standard n Implement the Standard.
SERVICE MANAGER 9.2 PROBLEM MANAGEMENT TRAINING JUNE 2011.
1 Dr. Ashraf El-Farghly SECC. 2 Level 3 focus on the organization - Best practices are gathered across the organization. - Processes are tailored depending.
Project Scope Management
Quality Assurance/Quality Control Plan Evaluation February 16, 2005.
Chapter 13 Overall Audit Plan and Audit Program
Information Technology Project Management – Third Edition
AS9102 First Article Inspection Report
Testing Workflow Purpose
O X Click on Number next to person for a question.
© S Haughton more than 3?
5.9 + = 10 a)3.6 b)4.1 c)5.3 Question 1: Good Answer!! Well Done!! = 10 Question 1:
Developing a Public Involvement Plan Why Develop a PI Plan? PI Plan Format Public Involvement Training Class – Presented by the Office of Environmental.
Linking Verb? Action Verb or. Question 1 Define the term: action verb.
1 CS 446 – Tutorial 6 Frid. Nov. 6 th, 2009 Implementation Tutorial.
1 Human Factors Course Session 4 Eric Davey Crew Systems Solutions 2007 March 28.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 5 Slide 1 Project management.
Lecture 8: Testing, Verification and Validation
Lecture 5: Requirements Engineering
Past Tense Probe. Past Tense Probe Past Tense Probe – Practice 1.
Addition 1’s to 20.
25 seconds left…...
Test B, 100 Subtraction Facts
System Testing 2  Effective March 3, 2014, new requirements for system testing were implemented  State Agencies are now required to provide to FNS:
Week 1.
We will resume in: 25 Minutes.
O X Click on Number next to person for a question.
 Acceptance testing is a user-run test that demonstrates the application’s ability to meet the original business objectives and system requirements and.
Software Quality Assurance Plan
1 Test Planning CSSE 376, Software Quality Assurance Rose-Hulman Institute of Technology March 9, 2007.
Software Testing and Quality Assurance
(c) 2007 Mauro Pezzè & Michal Young Ch 24, slide 1 Documenting Analysis and Test.
Project Documentation and its use in Testing JTALKS.
CSE Senior Design II Test Planning Mike O’Dell Based on an earlier presentation by Mike O’Dell, UTA.
Software Testing Prasad G.
… and after unit testing …
Software Testing Lifecycle Practice
Software Engineering Chapter 15 Construction Leads to Initial Operational Capability Fall 2001.
RUP Fundamentals - Instructor Notes
Independent User Acceptance Test Process (IUAT)
FCS - AAO - DM COMPE/SE/ISE 492 Senior Project 2 System/Software Test Documentation (STD) System/Software Test Documentation (STD)
ISM 5316 Week 3 Learning Objectives You should be able to: u Define and list issues and steps in Project Integration u List and describe the components.
What is Testing? Testing is the process of exercising or evaluating a system or system component by manual or automated means to verify that it satisfies.
Software Testing. Software testing is the execution of software with test data from the problem domain. Software testing is the execution of software.
Software Testing and Quality Assurance Practical Considerations (4) 1.
Chair of Software Engineering Exercise Session 6: V & V Software Engineering Prof. Dr. Bertrand Meyer March–June 2007.
1 test10b Software Testing Necessary to measure and certify quality in software.
Software Test Plan Why do you need a test plan? –Provides a road map –Provides a feasibility check of: Resources/Cost Schedule Goal What is a test plan?
Test Plan IEEE Explained by Nimesh Vadgama - QA.
Testing throughout Lifecycle Ljudmilla Karu. Verification and validation (V&V) Verification is defined as the process of evaluating a system or component.
1 March 19, Test Plans William Cohen NCSU CSC 591W March 19, 2008.
SOFTWARE TESTING TRAINING TEST MANAGEMENT Chapter 5 immaculateres 1.
Chapter 10 Software Quality Assurance& Test Plan Software Testing
Manfred Huber Based on an earlier presentation by Mike O’Dell, UTA
Test Planning Mike O’Dell (some edits by Vassilis Athitsos)
Software Testing Lifecycle Practice
Presentation transcript:

Test plans

Test Plans A test plan states: What the items to be tested are At what level they will be tested What sequence they are to be tested in How the test strategy will be applied to the testing of each item A description of the test environment.

What to consider for the Test Plan From IEEE 829 Standard for Software Test Documentation: 1. Test Plan Identifier 2. References 3. Introduction 4. Test Items

What to consider for the Test Plan 5. Software Risk Issues 6. Features to be Tested 7. Features not to be Tested 8. Approach 9. Item Pass/Fail Criteria 10. Suspension Criteria and Resumption Requirements

What to consider for the Test Plan 11. Test Deliverables 12. Remaining Test Tasks 13. Environmental Needs 14. Staffing and Training Needs 15. Responsibilities 16. Schedule 17. Planning Risks and Contingencies 18. Approvals 19. Glossary

What I want included in the test plan List of responsibilities (and who does them) Who runs the test Who approves the results Unit tests to be run with expected results Objectives Approach Include a description of the type of data used for unit testing and why that data is being used Pass/fail criteria When the tests are to be run (timeline)

What I want included in the test plan Integration tests to be run with expected results Objectives Approach Include a description of the type of data used for integration testing and why that data is being used Pass/fail criteria When the tests are to be run (timeline)

What I want included in the test plan Systems/Acceptance tests to be run with expected results Objectives Approach Include a description of the type of data used for systems/acceptance testing and why that data is being used Pass/fail criteria When the tests are to be run (timeline)

What I want included in the test plan Alpha testing to be done Objectives Approach Features to be tested Pass/fail criteria When the tests are to be run (timeline)

What I want included in the test plan Beta testing Objectives Approach Who is participating in the beta testing Pass/fail criteria What I want included in the test plan

Deliverables Test Design Specification: detailing test conditions and the expected results as well as test pass criteria. Test Case Specification: specifying the test data for use in running the test conditions identified in the Test Design Specification

Deliverables Test Procedure Specification: detailing how to run each test, including any set-up preconditions and the steps that need to be followed Test Item Transmittal Report: reporting on when tested software components have progressed from one stage of testing to the next

Deliverables Test Log: recording which tests cases were run, who ran them, in what order, and whether each test passed or failed

Deliverables Test Incident Report: detailing, for any test that failed, the actual versus expected result, and other information intended to throw light on why a test has failed. These include the expected results being wrong, the test being run wrongly, or inconsistency in the requirements meaning that more than one interpretation could be made.

Deliverables- Test Incident Report The report consists of all details of the incident such as actual and expected results, when it failed, and any supporting evidence that will help in its resolution. The report will also include, if possible, an assessment of the impact of an incident upon testing.

Deliverables- Test Summary Report Test Summary Report: A management report providing any important information uncovered by the tests accomplished, and including: Assessments of the quality of the testing effort The quality of the software system under test, and statistics derived from Incident Reports.

Deliverables- Test Summary Report The report also records: What testing was done How long it took in order to improve any future test planning. This final document is used to indicate whether the software system under test is fit for purpose according to whether or not it has met acceptance criteria defined by project stakeholders

IEEE Standards IEEE Standard for Software Test Documentation IEEE Standard for Software Unit Testing IEEE Standard for Software Verification & Validation Plans IEEE Guide for Software Verification & Validation Plans

Sample Test Plans solutions/testing-a-sample-test-plan solutions/testing-a-sample-test-plan-3283