View stunning SlideShares in full-screen with the new iOS app!Introducing SlideShare for AndroidExplore all your favorite topics in the SlideShare appGet the SlideShare app to Save for Later — even offline
View stunning SlideShares in full-screen with the new Android app!View stunning SlideShares in full-screen with the new iOS app!
Software Requirement Specifications IEEE 830 : Software Requirement Specification is a means of translating the ideas in the minds of the clients(the inputs) into a set of formal document (the output) of the requirement phase The Role Bridge the communication gap between the client the user and the developer
Conventional Testing Process Design Build Test & Fix * Here testing was happening only towards the end of the life cycle Spec
Distribution of Defects in the life cycle Source: IBM/TRW/Mitre 27% 7% 10% 56%
Software development life cycle Operational Testing Ongoing Support Requirement Analysis High level design Detailed Specifications Coding Unit Testing Integration Testing Review/Test
STLC-V Model Requirement Req. Review Design Design Review Code Code Review Develop Unit Test Review Unit Test Execute Unit Test Execute Integration tests Execute System Tests Develop integration Tests Review Integration Tests Develop Acceptance Tests Review Acceptance tests
Test Process :- The project under development or incorporation of accepted changes in the project or project under maintenance which implemented changes, use the testing process. Based on the nature of the project, adequate testing shall be arrived at the project level.
The Test Approach
sets the scope of system testing
the overall strategy to be adopted
the activities to be completed
the general resources required
the methods and processes to be used to test the release.
details the activities, dependencies and effort required to conduct the System Test.
valid, invalid and limit data input; screen & field
look and appearance, and overall consistency
with the rest of the application.
Vertical First Testing : - When the complete set of functionality is taken for one module and tested it is called Vertical First testing. Horizontal First Testing : - If a similar function is taken across all the modules and it is tested, it is called horizontal-first testing. Vertical Horizontal
Top-Down is an incremental approach to testing of the program structure. Modules are integrated by moving downward through the control hierarchy, beginning with the main control module, this could be done as depth- first or breadth-first manner.
Both normal cases and exceptions should be tested on both sides of the interface (if both sides exchange data). The interface should be tested for handling the normal amount and flow of data as well as peak processing volumes and traffic.
If appropriate, the batch processing or file transmission “window” should be tested to ensure that both systems complete their processing within the allocated amount of time.
If fixes or changes need to be made to either side of the interface, the decisions, deadlines and re-test procedures should be documented and distributed to all the appropriate organizations.
“ Selective retesting to detect faults introduced during modification of a system or system component, to verify that modifications have not caused unintended adverse effects, or to verify that a modified system or system component still meets its specified requirements.”
“ ...a testing process which is applied after a program is modified.”
During Y2K code changing, regression testing was the essence of the transition phase. What was typically done, was that code was changed at multiple places (it did not turn the original logic upside down, but made subtle changes). Now Regression testing was very important for the fact that even one small piece of code lying untested could lead to huge ramifications in the large amounts of data that is typically handled by these mainframe computers / programs.
Regression testing might even be required when one of the business associates changes his systems (might be new hardware). Since our system is hooked on to this transition system, our test engineers are also required to do regression testing on our system which has NOT been changed.
This example brings to light another fact with Regression testing, i.e., sometimes, even an unchanged system needs to be tested!
Includes a greater focus on regression testing, on keeping the users informed of specific fixes or changes that were requested.
Test process should be described in terms of the periodic release cycles that are part of the change control process.
Also describe a set of minimum tests to be performed when emergency fixes are needed (for instance, due to failed hardware or recovering from a database crash).
Test Strategy: Inputs & Deliverables Test Strategy Priority & Criticality Types of Applications Project Success Criteria Time Required for Testing No. & Levels of Resources Rounds of Testing Exit Criteria Test Suspension Criteria Resumption Criteria Deliverables Time Required for Testing No. & Levels of Resources Rounds of Testing Exit Criteria Test Suspension Criteria
Typical Test Issues Test Participation Test Environments Approach to Testing External Interfaces Approach to Testing COTS products Scope of Acceptance Testing Verification of Un-testable Requirements Criteria for Acceptance of the System Pilot of Field Testing Performances and Capacity Requirement/Testing Test Issues
Common Test Related Risks and Considerations Test Related & Risks & Considerations Poor Requirements Stakeholder Participation Test Staffing Testing of COTS External Interfaces Performance and Stress Testing Schedule Compression Requirement Testability Acceptance
Test planning process is a critical step in the testing process. Without a documented test plan, the test itself cannot be verified, coverage cannot be analyzed and the test is not repeatable Importance
Test plan To support testing, a plan should be there, which specifies
Scripts and test cases will be needed for most tests
Structure 1. Test plan identifier 2. Introduction 3. Test items / integration components 4. Features to be tested 5. Features not to be tested 6. Test Approach 7. Item pass/fail criteria 8. Suspension criteria and resumption requirements Continue.. * As defined by the IEEE 829 Test documentation Std
Structure 9. Test deliverables (PPlan) 10. Environmental needs (H/w & S/w) 11. Responsibilities (PPlan) 12. Staffing and Training needs (PPlan) 13. Schedule (PPlan) 14. Risks and Contingencies (PPlan) 15. Approvals Ref : Test Plan Template IEEE 829
Test Case Sheet To Capture Details: 1.Testcase ID (should be unique, e.g.: c_01.1, c_01.1a, c_01.2,…) 2.Feature functionality to be tested (each Requirement/feature could be from Usecase/COMP) 3.Test Description/ test input details (test input, test data, action to be performed to test the feature, complex test cases be split to more than one) 4.Expected behavior ( in messages, screens, data, to be with correct details) 5.Actual and Status
To evaluate a software program, check conformance to standards, guidelines and specifications
Educating / Training participants
Improve software program
Consider alternative implementation if required (not done in inspections)
Difference between Inspections and Walkthroughs Walkthrough process includes Overview, little or no preparation, examination (actual walkthrough meeting), rework and follow up. Inspection process includes Overview, preparation, inspection, rework and follow up. No checklist used in walkthroughs Checklist is used to find faults Usually team members of the same project take participation in the walkthrough. Author himself acts the walkthrough leader. A group of relevant persons from different departments participate in the inspection.
Difference between Inspections and Walkthroughs Contd. Shorter time is spent on walkthroughs as there is not formal checklist used to evaluate the program. Inspection takes longer time as the list of items in the checklist is tracked to completion. No formalized procedure in the steps. Formalized procedure in each step.